There’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.
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.
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
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.