Application Security

11:08 AM
Jeff Williams
Jeff Williams
Connect Directly
E-Mail vvv

In AppSec, Fast Is Everything

The world has shifted. The SAST and DAST tools that were invented over a decade ago are no longer viable approaches to application security.

Development organizations interpret delays as damage and route around them. Yet the application security program in most organizations is a centralized team that attempts to force software projects through a series of “gates.” A few brave organizations are stepping away from the bottleneck model to something better.

It’s easy for organizations to fall into the trap of thinking that AppSec is too burdensome to undertake over and over throughout the lifecycle. So they wait until the end of the development process and attempt one big application security review. And that’s the problem. Waiting until the end has disastrous consequences for security.

Using Brakeman at DevOps speed
What if the burden of application security verification could be lowered to almost zero? There would be no reason not to conduct reviews continuously throughout the software development lifecycle.

Justin Collins at Twitter created a static analysis tool for Ruby on Rails called Brakeman that significantly reduces the burden of static analysis. Despite the name, Brakeman was designed to accelerate software development, not slow it down. It calls to mind the old saying, “Why do cars have brakes? So they can drive fast!” And it’s actually Brakeman’s speed that allows it to be cleanly integrated within the software development process and not get bypassed.

We know that the cost of application security defects increases the longer they are allowed to stay in a software baseline. But it takes a really fast and accurate AppSec tool to be used early in the lifecycle to truly reduce the cost and complexity of finding and fixing vulnerabilities. Otherwise, organizations will just save up the burden until the last possible minute.

So what does it mean for an application security tool to be “fast?”

Instant feedback. Of course, fast means that results are produced immediately, not the next day, and certainly not in two weeks. Developers are used to getting instant feedback from their compiler, and security needs to work the same way. The best and simplest feedback leverages and relies on existing channels of communication, like bug trackers, IDE warnings, and email alerts.

No experts. Anyone can install and use Brakeman without being an application security expert. This is absolutely critical for speed, because centralized application security teams are always a bottleneck. They have to be as the demand for their expertise far outweighs their available time and budget.

Run continuously. You don’t have to remember to run a Brakeman scan. A related tool called Guard::Brakeman takes care of running Brakeman automatically every time you save a file. A fast tool can’t expect any changes in the software development process. It must be completely compatible and run without requiring any additional configuration or tuning.

Run everywhere. Brakeman can be used easily and at any stage of the software development lifecycle. It can be used during development, on an integration server, during testing, or even as a part of deployment. Having double-checks throughout the lifecycle ensures that mistakes are caught even when running at high speed.

Accuracy. False alarms are a huge time waster, so being fast requires accuracy. Spending time proving that a security warning is a false alarm produces no value and undermines the credibility of every other warning, so accuracy is critical.

IAST -- beyond static (SAST) and dynamic (DAST)
Fortunately, there is a new approach to application security automation that leverages the power of instrumentation to go fast. Really fast. Instrumentation means that security information is gathered directly from an application as it runs. Software instrumentation is similar to the instrumentation in your car that continuously monitors the engine temperature, washer fluid levels, tire pressure, and so on. Gartner calls this technique IAST for “Interactive Application Security Testing” and named it one of their Top 10 Technologies for Information Security in 2014.

IAST tools can analyze the code like a static tool and examine HTTP traffic like a dynamic tool. But they can also access the runtime data flow, the libraries and frameworks in an application, all the configuration files, and even the actual backend connections made by an application. All this information leads to broad coverage and high accuracy.

The beauty of IAST is that it takes advantage of all the context available in the running application so that it can run insanely fast. It’s easy to set up an IAST tool to run in development, integration, test, and even production all at the same time. IAST doesn’t require experts and can run continuously without any extra hardware. At Gartner's 2014 Security & Risk Management summit, Joseph Feiman called IAST a “breakthrough technology” and urged organizations to start evaluating and deploying IAST solutions.

The world’s first free IAST tool
Just recently, Contrast Security released the world’s first free IAST tool. It’s a plugin for Eclipse and you can find it for simple installation in the Eclipse Marketplace. Any developer can be up and running with Contrast for Eclipse in a matter of minutes. Click “Start with Contrast” on your application server and watch the vulnerabilities roll in as you browse your application. The plugin finds almost all of the OWASP Top Ten with excellent results.

Rolling Contrast for Eclipse out to your development team means that they will be able to find their own vulnerabilities and solve them immediately. This is the most satisfying and cost-effective way to do security as it saves all the downstream work of finding, triaging, fixing, testing, and releasing vulnerabilities.

The Future of AppSec tools
It might be possible to force development organizations to use slow tools, but they won’t like it. In fact, they’ll probably go out of their way to prevent these automation efforts from interfering with their software development, especially if those tools cause them to perform unnatural acts to use them, or when they start to regularly miss their launch windows.

The world has shifted. The SAST and DAST tools that were invented over a decade ago are no longer viable approaches to application security. Being “fast” is now what it takes to be successful as a security technology in the fast-paced world of software development. Being “fast” doesn’t only mean speed and scale. Fast application security tools are culturally compatible with the way modern software is developed, which turns out to be critical.

The future is unquestionably going to demand better application security, and that means that software development organizations must cultivate a culture and technology stack that encourages developers and security specialists to work together to build great software. And that means tools must be “fast.”

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Author
10/20/2014 | 3:29:06 PM
Re: Fast Trumps It All
It's easy to think that Agile/DevOps are going to result in worse application security, because short release cycles don't allow for full application security reviews to occur.  But this thinking is wrongheaded for two reasons.

First, there's nothing you can do about it.  High speed software development is happening and it's very unlikely that security can make it stop (not that you'd want to).  If you try you will make yourself extremely unpopular and get marginalized. Ultimately, you'll end up hurting security by getting yourself cut out of the loop.

Second, these movements are a *massive* opportunity to do security better. These efforts are establishing the infrastructure necessary to do security at high-speed.  Security folks just need to learn about the tools being used for software development -- tools like Jenkins, Sonar, JIRA, Puppet, and others are easy to leverage to do realtime application security at scale.

Try the free Contrast for Eclipse with your Java developers, and see what a huge difference *fast* can make.  It really does change everything.

Robert McDougal
Robert McDougal,
User Rank: Ninja
10/17/2014 | 11:17:26 AM
Re: SCRUM Tactics and Ingrained Security
@RyanSepe The problem I have ran into when dealing with SCRUM and Agile programming is that the execs expect to receive quicker 'releases' by using the Agile methodolgy.  It has been a difficult road to get them to understand that security still must play a part in each sprint.  Have you seen this in your organization as well?
Marilyn Cohodas
Marilyn Cohodas,
User Rank: Strategist
10/13/2014 | 3:33:30 PM
Re: SCRUM Tactics and Ingrained Security
Ryan, sounds like you are following similar tactics where you work. 
User Rank: Ninja
10/13/2014 | 12:32:25 PM
SCRUM Tactics and Ingrained Security
It is always best to have security in mind at the beginning stages of development. By ingraining app security at each step you will have a product that is honed not only towards user features but also provides the most secure implementation at rollout.

Its also important to think of this from a Scrum methodology standpoint. If app development is broken into sprints each level of the application will have an individual layer of security. A traditional approach will definitely leave certain holes within the product.
User Rank: Apprentice
10/13/2014 | 12:06:31 PM
Fast Trumps It All
So it sounds like AppSec is a viable tool that could prevent security defects from even happening in the first place. It also seems cost effective in the long run. The fact that app security defects increases the longer they are permitted to stay in the software baseline makes total sense, but it is something I never really thought about. Thank you for the information. I did not hear about AppSec prior to reading your article. You gave me something to think about.
The Case for Integrating Physical Security & Cybersecurity
Paul Kurtz, CEO & Cofounder, TruSTAR Technology,  3/20/2018
A Look at Cybercrime's Banal Nature
Curtis Franklin Jr., Senior Editor at Dark Reading,  3/20/2018
City of Atlanta Hit with Ransomware Attack
Dark Reading Staff 3/23/2018
Register for Dark Reading Newsletters
White Papers
Current Issue
How to Cope with the IT Security Skills Shortage
Most enterprises don't have all the in-house skills they need to meet the rising threat from online attackers. Here are some tips on ways to beat the shortage.
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
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 ...

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).

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...

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.

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.