Applying the Irari Rules to a risk-based security program
To summarize, the Irari Rules say that an attack is not sophisticated if any of the following conditions apply:
All well and good, say the critics, but these rules don't take risk into consideration. For example, a company might not use multifactor authentication for systems that ended up being targeted in an attack, because it made a conscious decision that the information in those systems is not valuable enough to warrant that level of protection.
That would be a legitimate and defensible decision to make (assuming that the value of the information was properly assessed). But in the end, it is irrelevant to what the Irari Rules are meant to do. The rules are supposed to help us judge whether an attack can truly be deemed "sophisticated." If a company has made a risk assessment and decided not to use multifactor authentication, and subsequently is hit by an attack that could have been prevented with multifactor authentication, there is nothing in the attack that raises it to the level of "sophisticated." The risk assessment basically came to the conclusion that certain available countermeasures would not be deployed to prevent what is really a preventable attack. The attack itself need not be sophisticated.
Our feeling in formulating the Irari Rules was that we need to be able to assess the validity of claims, made repeatedly in the media, by companies that have been attacked, and even by law enforcement agencies, that an attack was sophisticated and, by implication, unstoppable. Those claims distort reality and can make us feel more resigned to the inevitability of successful cyberattacks than we should.
The Irari Rules are intended to give someone with minimal technical competence --as is the case with most people in the media -- the ability to ask, "Does this attack really meet the criteria of a sophisticated' attack Was this an unpreventable attack, or the sign of an unsophisticated security program"
And though the Irari Rules don't specifically take risk into account, a security professional looking at them should evaluate which of the countermeasures implied by the rules are really too difficult or too expensive to implement. Keeping anti-malware signatures up to date Having a good password policy Not having proper network segmentation When looked at that way, we would argue, most of the implied countermeasures should be mandatory.
But some countermeasures might be subject to risk considerations. So yes, some security programs may decide that the cost of multifactor authentication is not worth the benefit. That can be a legitimate and defensible decision, as long as it arises from a truly objective risk assessment, which includes asking, "What is the impact if there was a compromise"
Unfortunately, a lot of decisions about the level of security deployed are not conscious weighings of the risks involved. The reality is that such risk-based decisions are relatively rare in industry. Many decisions regarding implementing specific countermeasures are made by default due to either budget concerns or a lack of knowledge about the potential need for the countermeasures on the part of the people implementing the systems.
We would actually be happy if every security program looked at the Irari Rules and made a conscious evaluation of the applicability of each countermeasure. Conscious decisions, hopefully involving approval by some risk committee, would be a vast improvement.
We also endorse organizations doing more to prevent successful cyberattacks. As we said in concluding our previous article, more-than-trivial attacks are the new normal, but security programs have not kept pace. Although the Irari Rules imply fundamental countermeasures, those countermeasures are not necessarily comprehensive for all organizations. They are a starting point for organizations that are targeted by more than random attacks.
Ira Winkler is president of Secure Mentem and author of the book Spies Among Us. Ira and Araceli Treu Gomescan be contacted through Ira's Web site, securementem.com. They will be doing a full presentation on these rules at the RSA Conference this Friday, April 24.