It's time to leave behind the misconceptions about the cost and effort required by effective application security. Here's how.

Chris Wysopal, Chief Technology Officer, Veracode

February 10, 2016

4 Min Read
By Jimee, Jackie, Tom & Asha (Keep It Simple) [<a href="http://creativecommons.org/licenses/by-sa/2.0">CC BY-SA 2.0</a>], <a href="https://commons.wikimedia.org/wiki/File%3AKeep_it_Simple_(3340381990).jpg">via Wikimedia Commons</a>

The past few years have seen a tremendous increase in the number and severity of successful attacks aimed at the application layer. This has been exacerbated by the fact that many organizations fail to properly secure the application layer due to time, resource, and budget constraints, and the rush to push applications to market.

It’s a problem compounded by the misconceptions of application security when compared to perimeter and network security—including the idea that embarking on an application security program requires excessive amounts of time, people, and money for less effective results. Yet, in 2014 alone, there were eight major breaches through the application layer, resulting in more than 450 million personal or financial records stolen.

Fortunately, the path to writing and deploying secure applications is not as hard as it’s made out to be. Any company can go from having an ad-hoc approach to having an advanced program, regardless of the number of applications that need securing.

Step 1: Start small

Your first step is to create a strategic roadmap that provides a situational analysis of security at the organization, and then outlines how the organization can prioritize and execute on that plan. Begin with a maturity assessment to pinpoint areas that are at risk, based on an industry-standard framework like OpenSAMM. Also, identify the Web perimeter to locate any potential entry points.  Many enterprises severely underestimate how many public Web applications they have. (As an example of how big of an issue this actually is, we found 350,000 web applications over the past 48 months that our customers didn’t know existed.)

Once that’s done, you can initiate an analysis of the top five to 10 critical systems and vulnerabilities that you discovered in order to quickly remediate risk. This will demonstrate the value of application security and generate opportunities to scale the program.

Step 2: Set policies and metrics

Your goals should make sure that all future applications are up to par, based on a set of accepted industry standards. The most commonly used guide is the OWASP Top 10. You can also find out the current typical flaw density in the organization’s applications and aim to reduce that number by a set amount per quarter.

Regardless of the metric used, it’s important to first set the baseline of your current security posture along with a set of predictable timelines for measurement. A set of established expectations for what both “success” and “need for improvement” look like is also key.

Step 3: Scale to all parts of the software development lifecycle (SDLC)

It is now time to move from mission-critical applications to every application the company has ever developed that is still in use. Although mission-critical applications may house some of the most sensitive information, cyber attackers will always be drawn to the path of least resistance. These paths are usually internal applications that are overlooked because they are not considered business-critical.

The most efficient means of integrating every application into the program is an assessment process integrated into the SDLC. This makes security part of the development process from the onset instead of just an afterthought addressed right before the application goes into production. To get buy-in and make integration happen, you’ll need to demonstrate concrete benefits for the development team—for example,  less post-production debugging.

Step 4: Scan third-party components and applications

The final step is to make sure that every application on the corporate network is secure, including those using third-party code. The particular challenge here: since the company doesn’t own the code of widely used third-party components, it cannot fix the flaws it finds. Still, it is important to make sure that none of the components or applications are creating vulnerabilities that endanger the corporate network. You do this by setting and enforcing security policies before accepting applications from outside vendors.

As part of this process, organizations should keep an inventory of all the software components in use that can be referenced, should a flaw in any of those components be disclosed. (No one wants a repeat of Heartbleed.)

A similar problem comes up when assessing and securing third-party applications, which can’t even be analyzed without breaching vendor contracts. To circumvent this issue, organizations need to hold third-party applications to the same standards as those developed internally. With such policies in place, an organization can request attestation from third-party vendors to assure the applications live up to security standards.

Every company is now a software company and, as such, they need to pivot to face the problems that come with the territory. It’s time to leave the misconceptions about the cost and effort required by application security behind, and begin adopting clear strategies and requirements that will keep your organization out of the headlines about the next big breach. 

More on this topic: 

Interop 2016 Las Vegas

Find out more about security at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Register today and receive an early bird discount of $200.

About the Author(s)

Chris Wysopal

Chief Technology Officer, Veracode

Chris Wysopal is Chief Technology Officer at Veracode. He oversees technology strategy and information security. Prior to co-founding Veracode in 2006, Chris was vice president of research and development at security consultancy @stake, which was acquired by Symantec.

In the 1990's, Chris was one of the original vulnerability researchers at The L0pht, a hacker think tank, where he was one of the first to publicize the risks of insecure software. He has testified to the US Congress on the subjects of government security and how vulnerabilities are discovered in software.

Chris received a BS in computer and systems engineering from Rensselaer Polytechnic Institute. He is the author of The Art of Software Security Testing.

Chris is often called upon to download the latest Minecraft mods for his son. An avid photographer and nature-lover, Chris spends his free time hiking the many conservation trails near his home outside Boston.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights