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.

And even if you have already inventoried your applications and breathed a sigh of relief at not finding it under the surface of your applications, 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 that need to be asked:

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.