Risk is much more than a report shown to the board every quarter. It’s a major point of discussion for any CISO regardless of industry, and not just on the mitigation side. The ability to effectively assess risk is a critical part of any program – but it has to be done realistically.

The Challenges

Risk is an inherently personal aspect of security because it is tied directly to what is important to the business. This makes it very difficult to have any sort of baseline, because two organizations even in the same industry might have two very different risk registers and tolerances. Take two banks for instance. One handles a large swath of clients with average wealth, and one manages few clients with enormous wealth. While they are technically in the same industry, they have two very different focuses. Thus, they have very different risk registers and tolerances. This is why it is difficult to define an effective blanket risk framework.  Here are some (of many) of the challenges that occur in creating a risk program:

• Crafting a Risk Register ‘Power tool’ as the base for a multiyear cybersecurity plan
• Evaluating your controls
• Linking controls to “Best Practice” Frameworks
• Linking the applicable controls to each risk
• Calculating the controls effectiveness per risk automatically
• Automatically calculating the importance of each control’s domain to the organization
• Visually communicating this to the Board

Where to start

Business Impact Analysis

You can’t effectively create a risk program if you don’t have a full picture of just how large the risks are for your organization. “You can’t secure what you can’t see” so to speak. Risks don’t necessarily arise from lack of technology – oftentimes they are hidden in faulty business practices. We are well beyond the days of IT and security being segmented off in their own little world away from the business. IT and security are business drivers now in a lot of cases, which makes the risks associated with them a business impactor. The first step to crafting any successful risk program is assessing these practices and what kind of impact they have on the business. Every aspect of the business impact needs to be assessed and have a financial impact associated with it. As mentioned earlier, communicating these risks to the board or other managing bodies who do not live and breathe this every day can be difficult. Adding a dollar value to these risks helps mitigate that issue. Below is an example of this:

*Image courtesy of the author

The “Average Fog”

Domain averages can be the death of a risk program. Not only are they entirely subjective, the calculations are often intrinsically flawed. These averages can be based on several different parameters: whether something is in place, whether it’s being implemented, etc. – but those don’t really tell the whole story. For instance, if it’s being placed specifically on implementation status, you could potentially get a completely false sense of security as to where you are in your current situation. Instead of getting bogged down with averages, it is much more effective to take each domain and prioritize the criticality of them. Once that is done, weighting those percentages based on your determined criticality will give you a much different viewpoint.

Prioritization Tiers

Criticality Ratings

Giving each control a criticality milestone helps paint a much more realistic picture of what level of risk each control actually contains. Rather than looking at it as an “in place/not in place” mentality, assessing what level of implementation as well as adoption each control has can change your risk register quite a bit. For instance, if you have a secure file transfer system set up but your employees are still using their own personal cloud storage or email to transfer files, that translates to a significantly higher risk score than if you were looking at only implementation. The criticality ratings also have to be specific to your organization’s needs and concerns – not all controls will be top priority to you. Rather than focusing on every single control, find the ones that are most important to the business and get a very accurate look at where you stand.

Weighted Percentages

Once the criticality milestones are set, applying weights is the next step. Most organizations have weighted averages set up already, but they’re based on a domain average which as previously stated doesn’t always work. The criticality milestones set a maximum percentage of effectiveness to illustrate a more realistic view. For example: if you have a criticality milestone of 3, your highest possible score is 60%, and you are 76% implemented, your actual risk score is 46%. That’s a very different picture than just taking your overall average based on implementation. This works on the other side as well. If you have a control that has a low criticality milestone, you could actually be in a better place than you thought. The most important aspect of risk scoring is reality.

Understanding the Attacker’s Motivations, Not Just Compliance

When having a risk assessment, it’s also important that you or the third party who is assessing you takes into consideration the modus operandi of the attacker. Prioritization is key in risk, and if you are attempting to mold your risk register around a compliance framework, you are only getting one piece of the pie. Compliance ≠ security. It’s necessary to avoid fines and fill out vendor assessments, but it doesn’t give an accurate depiction of your risk register.

In Summary

• Prioritize your domains by criticality and weight your scores accordingly
• Focus on the business’ financial impact
• Don’t rely on averages
• Decide your criticality based on what an attacker would be looking for