Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

2/10/2016
10:30 AM
Chris Wysopal
Chris Wysopal
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Simplifying Application Security: 4 Steps

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

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.

Chris Wysopal is chief technology officer at CA Veracode. He oversees technology strategy and information security. Prior to co-founding CA Veracode in 2006, Chris was vice president of research and development at security consultancy @stake, which was acquired by Symantec. ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
audrey-privateblog
50%
50%
audrey-privateblog,
User Rank: Apprentice
2/16/2016 | 2:45:39 AM
Re: Starting small
Great article very usefull and interesting, thanks a lot !
adamshostack
50%
50%
adamshostack,
User Rank: Apprentice
2/12/2016 | 8:10:56 PM
Starting small
Chris makes an excellent point about the importance of starting small, and generating quick demonstrations of value.  I might even fliip his first two steps, and start with a quick win before even a roadmap, by picking a system which meets a few simple criteria (obvious value/high visibility, not being shut down, thought to be safe) and driving a first fix into that.
How Attackers Infiltrate the Supply Chain & What to Do About It
Shay Nahari, Head of Red-Team Services at CyberArk,  7/16/2019
US Mayors Commit to Just Saying No to Ransomware
Robert Lemos, Contributing Writer,  7/16/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-14230
PUBLISHED: 2019-07-21
An issue was discovered in the Viral Quiz Maker - OnionBuzz plugin before 1.2.7 for WordPress. One could exploit the id parameter in the set_count ajax nopriv handler due to there being no sanitization prior to use in a SQL query in saveQuestionVote. This allows an unauthenticated/unprivileged user ...
CVE-2019-14231
PUBLISHED: 2019-07-21
An issue was discovered in the Viral Quiz Maker - OnionBuzz plugin before 1.2.2 for WordPress. One could exploit the points parameter in the ob_get_results ajax nopriv handler due to there being no sanitization prior to use in a SQL query in getResultByPointsTrivia. This allows an unauthenticated/un...
CVE-2019-14207
PUBLISHED: 2019-07-21
An issue was discovered in Foxit PhantomPDF before 8.3.11. The application could crash when calling the clone function due to an endless loop resulting from confusing relationships between a child and parent object (caused by an append error).
CVE-2019-14208
PUBLISHED: 2019-07-21
An issue was discovered in Foxit PhantomPDF before 8.3.10. The application could be exposed to a NULL pointer dereference and crash when getting a PDF object from a document, or parsing a certain portfolio that contains a null dictionary.
CVE-2019-14209
PUBLISHED: 2019-07-21
An issue was discovered in Foxit PhantomPDF before 8.3.10. The application could be exposed to Heap Corruption due to data desynchrony when adding AcroForm.