The blame game: Whose fault is it if your web applications are breached?

When it comes to a security breach, accepting responsibility for negligence is never a pleasant moment. It can even be a career-killer moment for a CISO. But ensuring you have (more than) adequate measures in place to protect your web assets to start with, is both a business and a security decision.

From the perspective of the CISO, their role is to protect and secure the business’s applications by asking for the resources and tools needed to do the job. And the business needs to make a financial and strategic commitment to back those recommendations. It has to agree which vulnerabilities need to be protected (and ‘all of them’ is not necessarily the right answer here), and how to protect them. Of course, the business must also decide how much it is willing or able to spend to do so effectively.

At this point, the business and security are jointly responsible for making the right decision, based on the available information at the time.

At what point does negligence creep in?

If security presents the right information to the business, and the business says ‘no’ for entirely valid reasons, only to have its web applications subsequently breached, it’s near impossible to lay the blame at anyone’s feet. Apart from the hackers. 

But if security has the tools it needs, and fails to use them, in my opinion, it’s a pretty clear-cut case of negligence.

Without the tools the CISO needs (and has asked for), being sidelined by a breach is excusable. But with the tools? There’s no excuse even remotely good enough.

Know what you own

Here's a telling comment from a CISO: “Three of the last four breaches we had were of systems I didn’t even know we had.”

Ouch.

If you have one job, and it’s protecting your systems, then at the top of your to-do list is knowing what applications you own. It’s one thing for security to have to tell the business its systems were exploited because they missed a patch. But it’s a whole new level of embarrassment to have to admit there is a system they didn’t even know about, and it has been hacked.  

When is the approach to protect all assets, at all costs, the wrong one?

While it may be tempting to throw resources and budget at every vulnerability, that’s not always the right choice. There are a lot of vulnerabilities out there that are just not worth fixing.

For example, I spent some time as a virtual CISO for a company which had a tiny exploitable software bug in their RAM. To eliminate or fix it, would have required replacing every single cell phone, printer, and server in the business. If it had the affected RAM, it would have had to go. But when I did a cost analysis, the risk potential was far smaller than the million or so dollars it would have taken to fix it.

It’s all too easy to lose sight of what is possible, and what is probable. No exploit is an exception; each one needs to be looked at in context.

More concerning are the applications that fall into the too-hard to fix basket. In fact, 60 to 80% of applications have no easy path to remediation. 

When is shielding specific vulnerabilities the right decision?

Websites are riddled with vulnerabilities, but for various reasons, not all of them are exploited. So how do you decide which vulnerabilities you can and should fix?

Yes, many can be remediated by hand without too much effort. But others are far more complex and require experience and knowledge beyond that of many non-security developers. These are prime candidates for shielding. Shielding protects known vulnerabilities more quickly, easily and completely, and they’re less likely to be bypassed.

And above all, shielding protects the business and CISO from any inference of negligence.

About the author

Robert “RSnake” Hansen is the CTO of Bit Discovery (where you can discover just about anything about your internet-facing assets).

His career started at eBay, where he was responsible for authentication as well as most anti-fraud systems and anti-phishing technologies. Since then, he has worked in nearly every bit of web application security for many of the world’s largest organizations, including over 2,100 banks, credit card processors, flight control systems, SCADA (water and power) control systems, and other security companies. In his spare time, Robert is a frequent keynote speaker and is on the speaker selection committee for Black Hat and Hack in the Box. Robert is also responsible for the creation of SlowLoris, a highly effective denial of service attack which works by ‘boring a server to death’.

Robert sits on RedShield Security’s Technical Advisory Board. Founded by penetration testers frustrated by continually finding vulnerabilities that organizations failed to address, RedShield has developed custom "shielding" technology, allowing them to shield vulnerabilities with zero code touch.