In chess, a key ability is to see moves several steps ahead. With every move, the player should (ideally) assess the possibilities and probabilities of the opponent’s scenarios and, hence, his future moves. Otherwise, the player might find himself in a very predictable situation, with no backup plan and without being able to protect the king (and the queen).
I tend to look at risk-assessment process the same way. The identification of risks—and thereafter the design of the respective controls—are affected by the level of the examination steps. Just like in the film “Inception,” planning the deeper levels might be a bit overwhelming, but nonetheless beneficial.
The problem with most risk-assessment approaches is that only the first levels of scenarios get examined, which can result in the failure of identifying critical risks. Usually, the process involves establishing a list of scenarios that represent risks, then mapping each identified risk to its respective control.
The downside of this process is that it lacks the second-level risk assessment, namely: the control is not compromised and the scenario still occurs. Let us use as an example the “password compromise” scenario, in which risk might be mitigated by encrypting (hash-ing) the passwords. However, if the organization avoids examining the next possible scenario (chess move), such as the hacker using the Rainbow Tables, the initial control becomes ineffective and the risk remains.
The importance of multi-level risk assessment becomes crucial, especially when we are witnessing increased use of zero-day attacks (attacks that exploit previously unknown vulnerabilities). We might assume that segregating the corporate network by implementing DMZ architecture with firewalls and IDSs effectively protects internal communication. However, as long as the organization has several entry points such as emails, USBs, remote connections and even a possible internal hacker, we have to consider the scenario in which the corporate network is fully compromised and all the traffic inside is exposed.
In most cases the mitigating controls that can be implemented for second-level scenarios are pretty straightforward, available and have already proven their efficiency. For the Rainbow Tables, the organization can implement a strong password policy and salted hash.
For the exposure of corporate network traffic, the organization can implement the SSL protocol in corporate applications (according to Google’s researchers: creating less than 2 percent of network overhead). Of course as we go deeper, the complexity and the cost-effectiveness can turn into noticeable issues, but in most cases, organizations do not reach the second level, which usually economically mitigates the risks of the first level.
The main idea is that performing multi-level hierarchical risk assessment helps ensure that all consequences are taken into consideration and that critical impact on the organization will be prevented. Also, the customers of the organization should be better protected, keeping recent information security events in mind. It might lead to the creation of some rather complex Excel spreadsheets, but it is definitely worth it.
Tal Yampolsky (@pingtal), CISA
Entrepreneur, technologist and auditor, Israel
ISACA Communities Committee Member
Continue the conversation…engage with your peers in the Risk Assessment topic in ISACA’s Knowledge Center.