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?
12 Free, Ready-to-Use Security Tools
Steve Zurier, Freelance Writer,  10/12/2018
Most IT Security Pros Want to Change Jobs
Dark Reading Staff 10/12/2018
6 Security Trends for 2018/2019
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/15/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
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-18374
PUBLISHED: 2018-10-16
XSS exists in the MetInfo 6.1.2 admin/index.php page via the anyid parameter.
CVE-2018-18375
PUBLISHED: 2018-10-16
goform/getProfileList in Orange AirBox Y858_FL_01.16_04 allows attackers to extract APN data (name, number, username, and password) via the rand parameter.
CVE-2018-18376
PUBLISHED: 2018-10-16
goform/getWlanClientInfo in Orange AirBox Y858_FL_01.16_04 allows remote attackers to discover information about currently connected devices (hostnames, IP addresses, MAC addresses, and connection time) via the rand parameter.
CVE-2018-18377
PUBLISHED: 2018-10-16
goform/setReset on Orange AirBox Y858_FL_01.16_04 devices allows attackers to reset a router to factory settings, which can be used to login using the default admin:admin credentials.
CVE-2018-17534
PUBLISHED: 2018-10-15
Teltonika RUT9XX routers with firmware before 00.04.233 provide a root terminal on a serial interface without proper access control. This allows attackers with physical access to execute arbitrary commands with root privileges.