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.
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16772
PUBLISHED: 2019-12-07
The serialize-to-js NPM package before version 3.0.1 is vulnerable to Cross-site Scripting (XSS). It does not properly mitigate against unsafe characters in serialized regular expressions. This vulnerability is not affected on Node.js environment since Node.js's implementation of RegExp.prototype.to...
CVE-2019-9464
PUBLISHED: 2019-12-06
In various functions of RecentLocationApps.java, DevicePolicyManagerService.java, and RecognitionService.java, there is an incorrect warning indicating an app accessed the user's location. This could dissolve the trust in the platform's permission system, with no additional execution privileges need...
CVE-2019-2220
PUBLISHED: 2019-12-06
In checkOperation of AppOpsService.java, there is a possible bypass of user interaction requirements due to mishandling application suspend. This could lead to local information disclosure no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVers...
CVE-2019-2221
PUBLISHED: 2019-12-06
In hasActivityInVisibleTask of WindowProcessController.java there?s a possible bypass of user interaction requirements due to incorrect handling of top activities in INITIALIZING state. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction ...
CVE-2019-2222
PUBLISHED: 2019-12-06
n ihevcd_parse_slice_data of ihevcd_parse_slice.c, there is a possible out of bounds write due to a missing bounds check. This could lead to remote code execution with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-8.0 Android...