Which Apps Should You Secure First? Wrong Question.

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.