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.
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. 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
- Controls evaluation
- 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. Risks don’t necessarily arise from lack of technology, a lot of the time they are hidden in faulty business practices. Assessing these practices and what kind of impact they have on the business has to be a first step. Every aspect of the business impact needs to be assessed and have a financial impact associated with it. For example:
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. 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.
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 and adoption each control has can change quite a bit. This has to be specific to your organization’s needs and concerns – not all controls will be top priority to you.
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.
Understanding the Attacker’s Motivations, Not Just Compliance
When having a risk assessment, it’s 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 important to avoid fines and fill out vendor assessments, but it doesn’t give an accurate depiction of your risk register.