Neil MacDonaldThere’s been a bunch of highly publicized attacks recently. Each one has a major lesson for information security.
Major lesson: Test all of your web-enabled applications for vulnerabilities as a part of the ongoing application development and change process. This was the root cause of the breach.
Minor lesson: Web application firewalls work better when they are turned on in active mode. In addition, processes for application downtime should not leave applications exposed without active protection. Specifically, firewalls and web applications firewall protection should remain active at all times an application is accessible.
Major lesson: Test all of your web apps (in this case, a third party developed system for content management) for vulnerabilities. This was the root cause of the breach.
Minor lessons. Don’t use weak passwords and encryption algorithms. Don’t have the CEO function as the email administrator, at least not with the same weak password. The fact that the email was hosted on Google and there was a delay in getting the email deactivated was a factor, but there were many mistakes before this. Blaming the breach on Google is like blaming the sinking of the Titanic on the iceberg. Yeah it was a factor, but there were many bad decisions before this.
Major lesson: If you have a critical application, you need to plan for resiliency and this responsibility applies whether the application is kept on-premises on in the Cloud. Moving to cloud-based services hasn’t relieved you of the responsibility to plan for service unavailability.
4) The attack on EMC and subsequent loss of intellectual property
Major lesson: 100% prevention is a fallacy. Get over it. Even the best protected networks and systems will be hacked. Assume you have been breached and focus on detection. Despite hype that information security has been doing detection for years, detecting advanced intrusions is not “security 101” and is quite different than detecting attacks.
Note that the root cause of the first two were vulnerabilities in external-facing web applications. With dynamic application security testing tools and services mainstream and with prices coming down, there’s really no excuse for not proactively testing applications for security vulnerabilities during the development process.
Ideally, you’d test applications with both static and dynamic testing techniques, but at a minimum the use of DAST tools (or DAST as a service) is a straightforward way to get started.
Category: Application Security Cloud Cloud Security Information Security Tags: application security testing tools, Best Practices, Cloud Security, Defense-in-Depth, Information Security, Security-Summit-NA
2 responses so far ↓
1 Ulf Mattsson May 25, 2011 at 6:42 am
There’s been a number of highly publicized attacks recently, including Sony, Epsilon and the four mentioned here.
But starting to test legacy applications is unfortunately a very long term plan – “too little too late”:
Sensitive data should be locked down using real encryption or tokenization, it is not enough to monitor:
I would give the following advice: don’t trust your keys or seed your data to any third party, even a security vendor like RSA. If you still trust your keys or seed data to a third party you must check their security policy against your own . You also need to know what type of data security solution they are using and make sure that they are compliant.
2 Neil MacDonald May 25, 2011 at 7:40 am
@Ulf,
Always think “Defense in Depth”
http://blogs.gartner.com/neil_macdonald/2009/03/04/defense-in-depth-doesnt-mean-spend-in-depth/
So, while I agree that protecting the data would have provided DID protection, it doesn’t eliminate the need to secure applications.
On key management – absolutely agree. See this:
http://blogs.gartner.com/neil_macdonald/2010/02/22/encryption-will-be-a-key-foundation-for-cloud-security/
Encryption is only as good as the key management discipline that supports it.
Neil