Talk presented by Dave Martin and Eric Blaze, both security officers from EMC.
March 2011 – RSA suffered a breach from an Advanced Persistent Threat (APT) type attack. This was big news and many customers we affect, having to replace their RSA tokens etc.
Security groups in high tech organisation, with EMC being the example – Product security group and IT security organisation. Where;
– Product security is focussed on the security of the products produced by the business, deploying patches to customers etc. This can be looked at as the products impact on the customer’s risk. They at EMC work on the premise that the customer’s network where the product will be deployed has been compromised so security is paramount. Secure development / code and application focussed.
– IT security organisation is responsible for the security of the IT enterprise itself. This can be looked at as the security impact on enterprise risk. Generally tend to be much more infrastructure and system focussed.
The environment is changing – environments much more likely to be compromised in a subtle, planned, long term manner (APT) rather than the traditionally more blunt and opportunistic attacks / compromises.
What are the characteristics of these changes?
– Single minded, determined and innovative
– Targeting individuals over systems
– Through reconnaissance will understand your processes, people & systems better than us
– Will exploit ANY weakness
– Countermeasures increase sophistication
– Custom malware, NOT detectable by signatures
– Are not in a hurry will take as long as it take
– Goal is long term & persistent access
– The perimeter has shifted, all systems now exist in a hostile environment
What are the implications of this?
Real attacks that have been publically reported have included;
– Loss of intellectual property
– Loss of cryptographic secrets
– Loss of source code
– Attacks against cloud services
Mandiant M-Trends 2012 reports that 94% of companies find out they have been compromised from law enforcement, and the median length of time from when a company is compromised to when the breach is discovered is 416 days! Do you know your network is secure, can you report with confidence to your board and shareholders that you have adequate, intelligent monitoring and solid layered defence in depth in place? Is your organisation aware of the risks at all levels?
We must assume that we are compromised! – the Security for Business Innovation Council in August 2011 stated;
“Consider that no organization is impenetrable. Assume that your organization might already be compromised and go from there.”
Technology providers must support this by adopting their product security strategy in the following ways;
– Create an integrated governance model
– Build intelligent monitoring into products
– Design layered defence into products
How do they do this? Product security and Organisational security must work more closely together to expand the SDL (Secure Development lifecycle) and collaborate on standards such as;
– Source code management
– Cloud / Hosting
– Supplier risk management
– Software integrity controls
– Make product strategy part of the enterprise risk strategy
Make logging of events more intelligent; Build attack-aware software.
– Leverage threat modelling within the software to log abuse such as Buffer Overflows and SQL Injections
– Evolve from logging to debug code issues towards logging that is much more useful for detection for example by including anomaly and behaviour logging in program logic
– Design software to integrate with and leverage the existing enterprise risk ecosystem – white lists, reputation awareness etc.
Incorporating layered defence into applications / services to resist APT type attacks can be done in various ways including;
– Utilising split-value cryptographic authentication. This is where Passwords are split and stored across two servers with one hosting part as an XOR’d random number and the other as a random number. Thus the attacker has to compromise two servers and crack both parts within a small time window as a new random number regularly refreshed.
– Assume source code is compromised – anything can be eventually reverse engineered;
- Never hard code secrets,
- Adopt a Secure Development Lifecycle,
- Threat model for source code exposure,
- Build integrity control into source code reviews
- Pay attention to comments – we should comment for best practice and code support, but make sure things like ‘To do, must add security here’ are mot left in the code!
– If you use agile methodologies, ensure you have a security based story. Review the recommendations from SAFECode;
In summary we need to develop using secure methodologies and use the assumption that all systems are or will be compromised.