Application Security

3/5/2015
10:30 AM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
100%
0%

Which Apps Should You Secure First? Wrong Question.

Instead, develop security instrumentation capability and stop wasting time on '4 terrible tactics' that focus on the trivial.

If you’re like most enterprises, there are hundreds or thousands of applications in your portfolio. Most likely, they were written, updated, and patched over the past 10- or 20 years. And you may not have done as much security work on those applications as you meant to.  If it’s any consolation, everyone we talk to is in exactly the same boat.  Somehow, the security debt piled up amazingly quickly.

Let’s examine some terrible tactics for tackling this challenge:

Terrible Tactic 1: Secure Only Externally Facing Apps
This is one of the most common tactics.  Given limited resources, your team focuses on externally facing applications. This is positively one of the worst strategies to adopt.  Whether or not an application is exposed to the Internet is only one of many factors that drive the “inherent risk” for an application.  If it’s your sole consideration, a lot of time and effort will be spent doing deep security reviews of applications that aren’t that risky to your business.  Instead, consider the sensitivity of the data, how critical the business functions are, the size and skills of the user and attacker pools, and other risk factors. 

Terrible Tactic 2: Confront One Application at a Time
Most approaches try to tackle application security one application at a time. When you perform deep security dives into applications, a lot of time is wasted focusing on trivial vulnerabilities that are unlikely to put you out of business. Every year, there are more applications and more attack vectors to consider. So every year, there is more and more work for the security team. The one-application-at-a-time approach just can’t scale. Instead, focus on how you can stamp out your most critical vulnerabilities across your entire portfolio.

Terrible Tactic 3: Conduct the Annual Security Test
Many organizations use an “annual” or “triannual” application-security testing schedule. This approach requires a complex scheduling process for new apps, old apps, cloud apps, products, etc. New vulnerabilities and attack technique are being discovered at a dizzying pace and therefore, this approach is extremely risky. A new library vulnerability could leave your apps insanely exposed until the next review comes around. New vulnerabilities are often quickly added to hacking tools and made part of widespread scanning efforts. Also, modern software development processes are releasing code weekly or daily, not annually.  Security must accelerate to keep up.

Terrible Tactic 4: Only Secure Critical Apps 
Another possibility is to focus only on the business-critical applications — the ones that will destroy the business if they are taken out. It’s smart to consider the real business damage that could be done, but typically, this is just a handful of applications.  In many organizations, the application security team is overwhelmed and understaffed, and their scanning approach can’t scale to handle any more applications. Unfortunately, many real-world breaches start with the compromise of a less important application (see Sony), and pivot to more important systems. Even the breach of a “brochureware” site will be a mess to clean up and a public relations disaster.

None of these tactics support a broader strategy of fast application security, and they are also incompatible with modern software development. We need an approach that will scale to the full size of our application portfolios, work at the speed of modern software development, and focus on the biggest risks first.  The good news is that we can take advantage of the ideas and technologies from continuous integration and continuous delivery to create a different kind of application security process that’s fast, accurate, and easy.

The Right Question: Do Your Apps Have Security Instrumentation?
Instrumentation allows you to gather security information directly from your applications without scanning, hacking, or any other extra steps. If your applications are instrumented, they test themselves and report their status continuously. This turns the scale problem in application security inside out. Instead of having to reach out and scan all your applications, they are testing themselves and reporting back to you continuously.

Here’s an example of the power of instrumentation. Let’s say that your most important security concern is SQL injection, and you have mandated that developers should only use parameterized queries. It’s easy to verify this with some security instrumentation in your database interfaces. For example, you can instrument your MySQL libraries to report the use of non-parameterized queries. Just put this version of StatementImpl on your classpath in front of the real version.

Although this is a trivial example, it’s pretty powerful. Push this instrumented version into your library repository, and soon you’ll have a complete map to all the non-parameterized queries in your organization. Imagine what you could do with full security instrumentation of your portfolio.

That’s the difference. Instrumented applications verify their own security and report issues to you. The simplest benefit is a complete application inventory. You can also verify that third party libraries are up-to-date and have no known vulnerabilities. Instrumentation can also to make sure configuration files are properly secured. More sophisticated instrumentation can figure out complex vulnerabilities, and just about anything you’d want to know about your corporate codebase. And it works continuously at enterprise scale.

Trying to figure out which applications to secure first is a waste of resources. Instead, spend your time establishing your security instrumentation capability. When the next Heartbleed or Shellshock comes out, you won’t have to scan anything. You’ll just go to your dashboard, search for the affected versions, and send an alert to the project owners of the affected applications. And you’ll be able to see exactly when they all upgrade.

Let me know in the comments how you use instrumentation to secure your comany's applications.

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
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
3/5/2015 | 4:32:41 PM
Terrible Tactics
My guess is that these "terrible tactics" are pretty embedded in many organization's standard security practices. Curious to know what people think would be the hardest to give up? Or are the really all that terrible?
'PowerSnitch' Hacks Androids via Power Banks
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/8/2018
Windows 10 Security Questions Prove Easy for Attackers to Exploit
Kelly Sheridan, Staff Editor, Dark Reading,  12/5/2018
Starwood Breach Reaction Focuses on 4-Year Dwell
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/5/2018
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
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-8651
PUBLISHED: 2018-12-12
A cross site scripting vulnerability exists when Microsoft Dynamics NAV does not properly sanitize a specially crafted web request to an affected Dynamics NAV server, aka "Microsoft Dynamics NAV Cross Site Scripting Vulnerability." This affects Microsoft Dynamics NAV.
CVE-2018-8652
PUBLISHED: 2018-12-12
A Cross-site Scripting (XSS) vulnerability exists when Windows Azure Pack does not properly sanitize user-provided input, aka "Windows Azure Pack Cross Site Scripting Vulnerability." This affects Windows Azure Pack Rollup 13.1.
CVE-2018-8617
PUBLISHED: 2018-12-12
A remote code execution vulnerability exists in the way that the Chakra scripting engine handles objects in memory in Microsoft Edge, aka "Chakra Scripting Engine Memory Corruption Vulnerability." This affects Microsoft Edge, ChakraCore. This CVE ID is unique from CVE-2018-8583, CVE-2018-8...
CVE-2018-8618
PUBLISHED: 2018-12-12
A remote code execution vulnerability exists in the way that the Chakra scripting engine handles objects in memory in Microsoft Edge, aka "Chakra Scripting Engine Memory Corruption Vulnerability." This affects Microsoft Edge, ChakraCore. This CVE ID is unique from CVE-2018-8583, CVE-2018-8...
CVE-2018-8619
PUBLISHED: 2018-12-12
A remote code execution vulnerability exists when the Internet Explorer VBScript execution policy does not properly restrict VBScript under specific conditions, aka "Internet Explorer Remote Code Execution Vulnerability." This affects Internet Explorer 9, Internet Explorer 11, Internet Exp...