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 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 ... View Full Bio
 

Recommended Reading:

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.
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7270
PUBLISHED: 2021-04-15
Exposure of Sensitive Information in the web interface in McAfee Advanced Threat Defense (ATD) prior to 4.12.2 allows remote authenticated users to view sensitive unencrypted information via a carefully crafted HTTP request parameter. The risk is partially mitigated if your ATD instances are deploye...
CVE-2020-7308
PUBLISHED: 2021-04-15
Cleartext Transmission of Sensitive Information between McAfee Endpoint Security (ENS) for Windows prior to 10.7.0 February 2021 Update and McAfee Global Threat Intelligence (GTI) servers using DNS allows a remote attacker to view the requests from ENS and responses from GTI over DNS. By gaining con...
CVE-2021-23884
PUBLISHED: 2021-04-15
Cleartext Transmission of Sensitive Information vulnerability in the ePO Extension of McAfee Content Security Reporter (CSR) prior to 2.8.0 allows an ePO administrator to view the unencrypted password of the McAfee Web Gateway (MWG) or the password of the McAfee Web Gateway Cloud Server (MWGCS) read...
CVE-2021-23886
PUBLISHED: 2021-04-15
Denial of Service vulnerability in McAfee Data Loss Prevention (DLP) Endpoint for Windows prior to 11.6.100 allows a local, low privileged, attacker to cause a BSoD through suspending a process, modifying the processes memory and restarting it. This is triggered by the hdlphook driver reading invali...
CVE-2021-23887
PUBLISHED: 2021-04-15
Privilege Escalation vulnerability in McAfee Data Loss Prevention (DLP) Endpoint for Windows prior to 11.6.100 allows a local, low privileged, attacker to write to arbitrary controlled kernel addresses. This is achieved by launching applications, suspending them, modifying the memory and restarting ...