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

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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest 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?
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
9 Tips to Prepare for the Future of Cloud & Network Security
Kelly Sheridan, Staff Editor, Dark Reading,  9/28/2020
Malware Attacks Declined But Became More Evasive in Q2
Jai Vijayan, Contributing Writer,  9/24/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15216
PUBLISHED: 2020-09-29
In goxmldsig (XML Digital Signatures implemented in pure Go) before version 1.1.0, with a carefully crafted XML file, an attacker can completely bypass signature validation and pass off an altered file as a signed one. A patch is available, all users of goxmldsig should upgrade to at least revisio...
CVE-2020-4607
PUBLISHED: 2020-09-29
IBM Security Secret Server (IBM Security Verify Privilege Vault Remote 1.2 ) could allow a local user to bypass security restrictions due to improper input validation. IBM X-Force ID: 184884.
CVE-2020-24565
PUBLISHED: 2020-09-29
An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local attacker to disclose sensitive information to an unprivileged account on vulnerable installations of the product. An attacker must first obtain the ability to execute low-privileged code on the ...
CVE-2020-25770
PUBLISHED: 2020-09-29
An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local attacker to disclose sensitive information to an unprivileged account on vulnerable installations of the product. An attacker must first obtain the ability to execute low-privileged code on the ...
CVE-2020-25771
PUBLISHED: 2020-09-29
An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local attacker to disclose sensitive information to an unprivileged account on vulnerable installations of the product. An attacker must first obtain the ability to execute low-privileged code on the ...