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.

Partner Perspectives  Connecting marketers to our tech communities.
SPONSORED BY
11/30/2017
09:00 AM
Lori MacVittie
Lori MacVittie
Partner Perspectives
50%
50%

The Good News about Breaches: It Wasn't You this Time

Somewhere in every application there is a vulnerability waiting to be exploited. You can attack the problem by having the right mindset and answering two simple questions

This year, it seems like you can hardly turn around without bumping into some commentary on a breach. There’s expert analysis on every blog. The trade press eats up controversy stirred up by responses. Twitter trends. My inbox fills up with quotes and offers to hear more about the breach.

It’s all bad news, so it seems. But every cloud has its silver lining, and in the face of most breaches, the good news is pretty simple: It wasn’t you.

The reality is that a significant number of high-profile (and target-rich) organizations rely on the same vulnerable software that caught whoever the latest victim was with its security pants down. Many more outside that list probably do, too. You, for example.

But even if you have already inventoried your applications and breathed a sigh of relief at not finding anything potentially dangerous lurking under the surface, you aren’t out of the proverbial woods. There are tons of research reports about vulnerabilities and, no matter which you look at it, there is always a gap between the time a vulnerability is disclosed and when an organization applies the appropriate patches.

Some of those vulnerable systems are likely to be running in your data center right now.

Go ahead, I’ll wait while you check.

While you’re checking, you should also take stock of your application protection strategy. You see, at the heart of the many of vulnerabilities lies the truth that it could have been prevented by a comprehensive application protection strategy. We can argue all day about the existence of the vulnerability and the security practices employed by open-source software, but the reality is that a whole lot of software — third-party, open-source, closed-source, custom developed — is vulnerable. And we’ve seen many of those vulnerabilities lie dormant in software for years before being exploited. Shellshock, anyone?

In fact, just as you ought to assume you will be subjected to a DDoS attack, you ought to operate on the assumption that somewhere in an application there is a vulnerability waiting to be exploited. With that in mind, you can attack the problem by having the right mindset and answering two questions:

  1. How do I prevent the vulnerability from being exploited?
  2. If it is exploited, how do I detect it?

Prevention: Proactive Security
The answer to question one is to embrace a proactive approach. Patching is table stakes. It’s probably past time you audited your policies and processes with respect to patching, so if you haven’t done that lately, do it now. In addition, you should also be putting into place protections that help you strictly adhere to Security Rule Zero:

THOU SHALT NOT TRUST USER INPUT. EVER.

We’ve seen too many breaches that were ultimately triggered by unfiltered, unsanitized user input. In other words, the developers simply pass user input to frameworks, libraries, and even other code of their own without ever giving it a second glance. That’s how SQL injection happens. That’s how cross-site scripting happens. That’s how breaches happen.

The number of breaches that can be traced to the violation of Security Rule Zero boggles my mind. To prevent it, you need to seriously focus on secure development practices and—because we know that can fail, too—employ a Web application firewall (WAF) to assist in sanitizing data. Here’s a helpful tip from Lori: the WAF has to be active. Learning mode is great for, well, learning the app and fine-tuning policies. But if you don’t actually let the thing do its job, you’re not mitigating risk.  You’re just helping to encourage a false sense of security.

Be proactive. Adopt Security Rule Zero and enforce it everywhere.

Detection: Reactive Security
Question two (If it is exploited, how do I detect it?) assumes that even if you faithfully follow Security Rule Zero, still somehow an attacker made it through and has managed to obtain sensitive data. That’s data like account numbers and personal identifiable information (PII) such as social security numbers and login credentials.

There is still time to stop the breach from happening because a breach doesn’t actually happen until that data leaves your network. Inspecting outbound data is a critical component of a comprehensive app protection strategy. That means inspecting outbound responses for sensitive data. That’s data leak prevention solutions. A WAF can do it. A programmable proxy can do it. And I’m sure there are other solutions out there that lie in the data path and can detect the presence of sensitive data indicative of a breach in progress.

Inspecting outbound responses for size of content can also be a boon in detecting a successful exploit. If you know the response to a given URL is supposed to return exactly one record with approximately 4K of data, then a content response size of 64K ought to raise an alarm somewhere. Again, a WAF or programmable proxy can detect this kind of anomalous behavior and more importantly, do something about it.

The good news is (hopefully) you weren’t breached, and you have time to do something about the existential possibility that you will be at some point. Not being a "high profile" site doesn’t protect you anymore. Automation and the rise of botnets means attackers are getting more efficient in seeking out and exploiting more and more organizations because, these days, it costs them almost nothing to scan and attack.

You absolutely should patch everything you can. But just as importantly, you should have a serious and actionable application protection strategy that covers both directions — in and out. Security Rule Zero is not an option anymore. 

Be proactive. Be reactive. Most of all, be active and involved in securing your apps and the platforms they rely on.

Get the latest application threat intelligence from F5 Labs.

Lori MacVittie is the principal technical evangelist for cloud computing, cloud and application security, and application delivery and is responsible for education and evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Why Cybersecurity's Silence Matters to Black Lives
Tiffany Ricks, CEO, HacWare,  7/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
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
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...