Sony and Chase: Don't blame the CISO

07.01.2015
Over the last couple of weeks, I have read numerous news stories about the widely publicized security breaches at Sony and JPMorgan Chase. It seems as if everybody is a Monday-morning quarterback, with every other reporter voicing an opinion on how these breaches should have been prevented. In particular, I read two articles that specifically blamed the information security organizations at those companies for failing to properly stop the attackers. That's not fair.

What bothers me is the assumption that the "security guy" has a magical ability to stop attackers in their tracks. Those of us in the profession know that it's not that simple.

Attackers have always had their choice of vectors for attacking networks. Microsoft operating systems and products, for example, are full of security holes, not all of which are patchable. The same is true for Web servers and other Internet-facing software and servers. Firewalls have lots of ports opened up to allow various services to work, and remote access systems are prevalent in every organization. It only takes one security hole for an attacker to gain a foothold in any network. And even in the best-defended networks, there are always several security holes.

How can an information security team effectively block every possible attack, when the technologies we use are never going to be 100% secure

One article I read last week specifically blamed Chase's information security team for "failing to upgrade" a server to two-factor authentication. I don't know how it is in your organization, but at my company, I don't upgrade servers. My information security team does a lot of things, but not hands-on management of data center servers. IT does that. And the dynamics are complicated. I find vulnerabilities and notify my company's IT team about them, and then follow up over time to convince the IT guys to make the changes I want. It's not easy, and it's not always successful. Implementing two-factor authentication, in fact, is one of my current challenges.

So it's hard for me to see how blaming the chief information security officer is the right way to look at these breaches. It is highly likely that the IT organizations in companies that suffered significant breaches over the last year should bear some of the responsibility.

Another article I read said Sony's CISO chose a relatively high level of risk regarding the company's information security posture.

This strikes me as even less fair. I can't believe that the CISO "chose" a high level of risk. The much more likely explanation is that the level of risk was imposed by outside forces. There are always other factors in play, such as resource availability, funding and general organizational support for information security risk reduction. I can name many things that I would change at my company, and the reason I haven't done them yet is not that I have "chosen" to leave them the way they are. Sometimes, change requires a lot of patience, persistence and effort. We can't always just flip a switch and make things happen. I think it's fairer to say that the company as a whole has chosen a specific risk posture.

And even if we could make all of the changes that we want to, how can we expect CISOs to make every network 100% attack-proof This is a question I think about every day. No matter how many servers I harden, how many security technologies I bring in to my network, and how many "best practices" I implement, vulnerabilities will always be present in the operating systems and software my company uses. What this seems to imply is that determined attackers will always be able to break into targets of their choice, because they have so many vectors to choose from. In other words, it's not possible to be 100% secure. And where does that leave us We do our best with what we have, and hope for the best.

This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at jf.rice@engineer.com.

Join in

Click here for more security articles.

(www.computerworld.com)

By J.F. Rice

Zur Startseite