Gartner Blog Network

Four Security Breaches, Four Security Lessons

by Neil MacDonald  |  May 23, 2011  |  2 Comments

There’s been a bunch of highly publicized attacks recently. Each one has a major lesson for information security.

1) Barracuda’s breach

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.

2) The attack on HBGary

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.

3) Amazon’s recent outage:

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.

Additional Resources

Five Board Questions That Security and Risk Leaders Must Be Prepared to Answer

As board members realize how critical security and risk management is, they are asking leaders more complex and nuanced questions. This research helps security and risk management leaders decipher five categories of questions they must be prepared to answer at any board or executive meeting.

Read Free Gartner Research

Category: application-security  cloud  cloud-security  security-of-applications-and-data  

Tags: application-security-testing-tools  best-practices  cloud-security  defense-in-depth  information-security  security-summit-na  

Neil MacDonald
VP & Gartner Fellow
15 years at Gartner
25 years IT industry

Neil MacDonald is a vice president, distinguished analyst and Gartner Fellow in Gartner Research. Mr. MacDonald is a member of Gartner's information security and privacy research team, focusing on operating system and application-level security strategies. Specific research areas include Windows security…Read Full Bio

Thoughts on Four Security Breaches, Four Security Lessons

  1. Ulf Mattsson says:

    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 says:


    Always think “Defense 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:

    Encryption is only as good as the key management discipline that supports it.


Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.