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.

As Director of Developer Engagement, Peter Chestna provides customers with practical advice on how to successfully roll out developer-centric application security programs. Relying on more than 10 years of direct AppSec experience as both a developer and development leader, ... 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.
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.