Styles

Sunday, August 17, 2014

Who is to blame when a security breach occurs?

Last month, I wrote about how it is impossible to make software systems 100% secure. Essentially, companies trying to secure their systems should constantly be asking themselves whether spending extra money on security is worth mitigating the risk of a breach. When a breach does occur, though, people inevitably look for someone to blame. It's usually the CIO who gets blamed (and often fired). But is this reasonable? After all, the decision to spend more money on innovation and less on security is a business decision, not a technology one. So the answer is: it depends largely on the culture of the company.

To help describe company culture, I will again leverage a framework developed by two Harvard Business School scholars that defines the levels (or stages) in which manufacturing interacts with the business, which I have adapted for IT. Here is a summary:
I'll ignore Stage 3 here because it is not sustainable, but we can safely examine the cultures of the other three environments and how they pertain to blame when a security breach occurs.

Stage 1

If a company is in Stage 1, it is inclined to think that anything that goes wrong with anything technology-related is clearly IT's fault. In this case, though, nothing could be further from the truth. A true Stage 1 leadership team wouldn't have given the IT security staff enough resources to adequately secure the systems, since security is more of a risk mitigation activity than one that directly improves profitability. By placing the IT staff in a position to fail, the leadership team should take the blame for any failure. 

Stage 2

Based on my experiences in Stage 2 environments, business leadership and IT leaders probably haven't had a conversation about the risk/reward balance inherent in any discussion about how much money to spend on security. In such an environment, IT is focused on providing the services that the business requires, and the business leadership is content letting IT handle all of the "technology problems". Any discussions about the business drivers behind IT priorities are indirect at best.

Even though the communications about security issues are indirect, one can usually tell where the business priorities lie based on the tone of the communication between business and IT. If the business is excessively focused on cost-cutting or innovation, security is going to be neglected. If the signals the business leadership team is sending to the IT team are balanced and rational, then it is primarily the technology team's responsibility to ensure that infrastructure needs, such as security, are being adequately addressed.

Stage 4

In a Stage 4 environment, since IT is an integral part of the business leadership team, all parties should have agreed to resource allocations between innovation and security. Therefore, the entire business shoulders some of the blame for a security breach. This can be especially true if the leadership team (including IT) decides that cost-cutting or innovation is more important than security at the moment.

It is worth noting that there can be valid business reasons for focusing at any given moment on innovation or cost-cutting at the expense of security. It is not a wise business decision to neglect security in the long run, however.

Final Thoughts

You probably noticed that I didn't go into detail about whether the rank-and-file IT workers should be blamed. Yes, individual workers make mistakes. But companies with healthy cultures, i.e. Stage 4 companies, tend to hire better individuals and put them in situations in which they can succeed. In these situations, it is more likely that a security breach is caused by reasonable differing priorities or an honest mistake than by a fire-worthy incompetent decision. Conversely, companies with unhealthy cultures, i.e. Stage 1 companies, generally can't hire good employees, so replacing bad employees with other bad employees won't help the situation. Only fixing the culture will fix the issues.

No comments:

Post a Comment