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?
When Your Sandbox Fails
Kowsik Guruswamy, Chief Technology Officer at Menlo Security,  4/11/2019
Julian Assange Arrested in London
Dark Reading Staff 4/11/2019
8 'SOC-as-a-Service' Offerings
Steve Zurier, Freelance Writer,  4/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-1840
PUBLISHED: 2019-04-18
A vulnerability in the DHCPv6 input packet processor of Cisco Prime Network Registrar could allow an unauthenticated, remote attacker to restart the server and cause a denial of service (DoS) condition on the affected system. The vulnerability is due to incomplete user-supplied input validation when...
CVE-2019-1841
PUBLISHED: 2019-04-18
A vulnerability in the Software Image Management feature of Cisco DNA Center could allow an authenticated, remote attacker to access to internal services without additional authentication. The vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vuln...
CVE-2019-1826
PUBLISHED: 2019-04-18
A vulnerability in the quality of service (QoS) feature of Cisco Aironet Series Access Points (APs) could allow an authenticated, adjacent attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper input validation on QoS fields within Wi-Fi fra...
CVE-2019-1829
PUBLISHED: 2019-04-18
A vulnerability in the CLI of Cisco Aironet Series Access Points (APs) could allow an authenticated, local attacker to gain access to the underlying Linux operating system (OS) without the proper authentication. The attacker would need valid administrator device credentials. The vulnerability is due...
CVE-2019-1830
PUBLISHED: 2019-04-18
A vulnerability in Locally Significant Certificate (LSC) management for the Cisco Wireless LAN Controller (WLC) could allow an authenticated, remote attacker to cause the device to unexpectedly restart, which causes a denial of service (DoS) condition. The attacker would need to have valid administr...