In Webcasts, personal discussions, forum discussions, and professional consultations, I am often asked questions that relate to the reason for poor uptake of security practices. Anyone with an eye toward information security trends can see that there are a lot of basic, minimal standards of security that are simply ignored by many — if not most — people in a position to make decisions about security.
The answer to that question is a complex one. Usually, such discussions come with an implied answer on the part of the person asking. For instance, in Integrated Security: Simplified and Scalable Threat Management, the common question of how much of the corporate world's security failings are the fault of management came up. Unfortunately, it really isn't that simple a matter. In some organizations, management's failure to recognize the importance of certain security measures may well be the major roadblock. In others, that isn't the problem at all.
Probably the most annoying, and the most dangerous, reason for poor security that I have ever seen is the fallacious application of the principle that one should not blame the victim for the crime. Obviously, one shouldn't direct ethical or moral opprobrium toward the victim of a robbery because she forgot to lock the house, the victim of a murder because he was hanging out in a dangerous part of town, the victim of a rape because she was dressed provocatively, or the victim of a botnet infection because he didn't properly secure his computer.
On the other hand, this doesn't mean the victim of the botnet infection should not have secured his computer.
Last week's article Email advice for politicians discussed some ways one can protect oneself against security breaches such as the incident of Sarah Palin's Yahoo! email account being cracked and contents of emails being passed on to Wikileaks. The violation of her email security made for big news, and I used that news as an opportunity to explain some measures I would have employed for my own email security, had I been a Presidential candidate's running mate instead of her.
A response to that article in discussion comments suggested that the point of the article was to blame Sarah Palin for the security violation rather than the security cracker who committed the act. That could not be further from the truth; my point was not to lay blame at Sarah Palin's feet, but to help others learn from the experience, so they would be better armed against attempts to violate their email security in the future. The question of blame was never addressed in the article.
That discussion comment was emblematic of a long-standing trend, however. Any suggestion that one should protect oneself, that developers should take responsibility for the secure design of their software, and that taking a position of willful ignorance on matters of security only enables security crackers, may encounter accusations of blaming the victim dismayingly often. The most common case, in my experience, is someone reacting to the suggestion that Microsoft is too lax in its vulnerability handling policies by demanding that everyone stop "blaming" Microsoft for the behavior of malicious security crackers.
I'll spell it out for you, in no uncertain terms, on the subject of both these examples:
- Microsoft is not to blame for the behavior of malicious security crackers. The only people who should be arrested for crimes involving violation of computer security are the people who actively violated computer security or conspired to aid such violations. On the other hand, this should not prohibit anyone from keeping in mind the security characteristics of Microsoft's operating system and application software, and it does not excuse Microsoft's tendency to misrepresent its software's security to its customer base.
- Sarah Palin is not to blame for the behavior of malicious security crackers, either. It is unfortunate for her that she did not have, or follow, good advice with regard to email security, but a comprehensive understanding of information security is certainly not a prerequisite for taking public office. On the other hand, there is speculation that she uses unofficial email accounts to conduct campaign business specifically to violate the spirit of Alaskan Freedom of Information laws while abiding by their letter. Judging by the reported content of the cracked email account, it seems likely this estimation of her email policy is true, which leads to two problems:
- She may have made the classic mistake of violating what amounts to workplace security policy because she doesn't want to have to live within its restrictions — and, in so doing, she made it easier for malicious security crackers to violate her email security.
- By behaving in a manner that circumvents transparency regulations, she may have attracted more scrutiny from activist security crackers than would otherwise be forthcoming, thus in effect attracting that kind of attention in the first place.
Thus, while my previous article did not in any way blame the victim for the act, this was in part only because that wasn't the point of the article. If the speculations about the propriety of Sarah Palin's email practices are correct, however, it may in fact be appropriate to lay some small part of the blame at her feet. That isn't even the point of this article, though.
The point of this article is that, regardless of whether someone should have to shoulder any blame for being the victim of a security violation (and most of the time, the victim should not be blamed at all), the lessons one can learn from the unfortunate examples of others are still valid. If you cannot see that suggesting stricter security measures to avoid befalling the same fate as the victim of a security breach is not the same as blaming the victim, you may well leave yourself wide open to such security violations yourself.
That doesn't put you on equally low ethical ground with the malicious security crackers who violated your security, of course. It does, however, suggest that your mindset is not well oriented toward protecting yourself against the dangers of the world.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.