The blame game is something all of us practice from time to time, when something goes badly wrong we don’t want to get caught holding the bag. And when we’re accused of being the culprit, our natural reaction is to raise our hands and say, “Not me!” So it’s not unusual when a security breach happens that the business or organization immediately tries to shift the blame to the vendor. “It’s the software’s fault” is an easy way of alleviating your company of any fault in the matter. But how often is it really true?
In my view, this kind of reaction is almost always shown to be wrong once a full internal audit of the situation has been completed by the company or organization. Usually what happens as the audit proceeds the assignment of blame for a security breach gets progressively shifted as follows:
- Bam — you’re hacked!!!
- Blame the software!
- We also need to confiscate the server that software is running on!
- It looks like the admin is really the one we should blame — he went rogue.
- Wait — who hired this guy in the first place? What kind of controls did we have over him and why weren’t they applied consistently?
- I think we all failed here, it’s clearly a failure of our corporate culture. We need to do a full review of our security policies and processes for applying them.
- Let’s move on, what’s done is done. We just need to make sure it never happens again.
Notice the progression here from blaming tools (software and systems) to placing the blame on individuals (usually an administrator) to recognizing that inadequate businesses processes (security breach policies and controls) as being the true culprit. Unfortunately, as the blame gets shifted around its energy also dissipates, and while the end result is typically a tightening of security controls, the issue of how those controls got weakened in the first place is usually not addressed.
Reasons of convenience
How does an organization that has developed a carefully crafted security policy, effective controls, and clearly defined processes end up getting hacked? Often it happens for reasons of convenience, for example when an administrator needs to “bend the rules” in order to “get the job done.” But the initiative behind such rule-bending is often not from the administrators themselves but from someone in corporate management above who informs the administrator that such-in-such is “high priority” and “don’t tell me about proper process” but “just do it.”
Because of this, the administrator often has to violate the organization’s own carefully crafted security policies and bypass those effective controls and jump over some of those clearly defined processes to satisfy the demands of his or her superiors. And so a firewall exception is made for that one corporate machine, or the permissions on those sensitive documents are relaxed so they can be copied, or an inexperienced person is added to a global security group, or … you get the picture.
The Fourth Protocol
Here indeed is the crux of the problem as far as IT is concerned: Is there a solution that can prevent such things from happening? What makes this difficult is that it’s not really an IT problem at all, it’s an issue of corporate governance and responsibility. When it comes to options on how IT can respond to such demands, they can choose to:
- Complain loudly. Unfortunately, you might get fired if you do this.
- Complain in writing. Now you’re giving management even more ammunition in case they want to fire you.
- Shut up and obey. You’ll still get fired if the requested action results in the organization getting hacked.
Or you can try the Fourth Protocol and simply try and be reasonable. (For those of you who are in-the-know film buffs you’ll realize I’m referring here to the movie of this title that starred Pierce Brosnan and Michael Caine, and the protocol being referred to is one of last resort: the nuclear option.) What I mean by this is that you simply try to do the following:
- Explain in a relaxed voice why the requested action can endanger not just the organization but the career of the individual who originally requested the action.
- Describe how your IT systems work and why the security controls you’d need to circumvent have been established in the first place.
- Ask the individual making the request to carefully weigh the risks of the action with the apparent urgency of its need.
- Seek understanding concerning why the requested action is viewed as high priority and urgent.
- Suggest some possible alternatives to the requested action that might be performed that would not circumvent the organization’s security policy, controls, and processes.
Affective management after a security breach
I might be tempted to try and turn this bullet list into a mnemonic like EDASS, but that really doesn’t work, does it? Really what I’m talking about here though is managing the expectations of the person or persons you’re dealing with through focusing on the affective domain. Or simply controlling your emotions. In other words, dialing down the confrontation. Mr. Spock, played by Leonard Nimoy, in the original Star Trek series on TV was an expert in dialing things down because no matter how stressful a crisis became he never let his emotions overcome his logic. And since IT is a highly stressful profession, Spock might just be the right model for us to imitate for those of us who work as IT professionals and IT managers, especially after a security breach.
Cool, reasonable logic that neither attacks nor defends is the best way of identifying and resolving the root problem behind an IT crisis such as a privacy or security breach. By learning to control your emotions you’ll be able to live long and prosper in your profession. The alternative, of course, is to flame out and crash. Which outcome would you prefer?
Photo credit: Shutterstock
