The 3 Most Common Problems That Nearly ALL Cyber Risk Management Programs Have, and How to Solve Them
In this article, I will discuss the 3 most common mistakes people still make when assessing and addressing OT cyber risk management (hint: most of you are still doing it backwards), and ways that you can make your process more efficient and effective (including more cost-effective).
I get it. Dealing with risk is not exciting… or easy.
Risk is a term that turns most people off. It is certainly not as exciting as “penetration testing” and “threat hunting”. More common subjects like threat monitoring, vulnerability assessments, and incident response also definitely have a greater mind-share for most of you tasked with OT cybersecurity. While every single one of these elements are important (critical, even), the truth of the matter, however, is that all these things feed into the bigger picture that is your overall risk: risk to safety, risk to production, and ultimately, risk to the business. Furthermore, not one of these things on its own gives you everything you need to see the entire picture. They each provide a different piece of the puzzle; a puzzle that, when completed, gives you what you need to (“stop me if you’ve heard this one”) create an accurate, targeted, and cost-effective risk mitigation strategy. (Eesh… I know, right? We have all heard this before…)
I think that most people probably understand this overall concept. The problem is, there are so many aspects to managing risk, and so many moving parts that, a. most organizations do not have the resources (people and/or budget) to do it all (so, they are forced to choose one or two areas that will give them the biggest “bang for their buck”), and/or b. they don’t truly understand the differences between these tasks (most notably in the assessment tasks), what information and value they should be getting out of them, and how that feeds into their risk management.
So, let’s unwrap the problems, identify solutions, and simplify this whole thing.
Problem 1: Confusion Over Assessment Terminology
I cannot tell you how many times I’ve had a customer come to me asking for a penetration test, but what they really wanted was a more comprehensive vulnerability identification (a vulnerability assessment), with risks identified and prioritized (a risk assessment). With all the different terms and types of assessments, it can be understandably overwhelming. Not understanding each of the assessment types, steps, and what you actually need can also lead to an incomplete risk assessment.
I will cover more specifics about each of the different assessment types and steps in subsequent articles, but for now, let’s break down and define all the terms commonly used to describe the different assessments.
Common Cyber Risk Assessment Terminology
- Breach Assessment (“Threat Hunting”)
A search for evidence that you have been breached. This can be performed as an initial step or as part of threat monitoring. It is also part of incident response, to identify where, how, and when a breach may have occurred.
- Vulnerability Assessment
This is an examination of your attack surface through vulnerability identification. It is sometimes incorrectly referred to as a vulnerability scan but that’s only part of it. A vulnerability scan is an automated search for technical vulnerabilities. A complete vulnerability assessment also looks for procedural/process, and human vulnerabilities.
- Vulnerability Scan
Part of a vulnerability assessment that uses an automated tool to identify technical vulnerabilities such as software bugs, configuration weaknesses, and missing patches.
- Gap Assessment (Gap Analysis)
Part of a vulnerability assessment that identifies missing security controls and procedures, which are outlined (or required) by best practices, standards, or regulations.
- Audit
A formal gap assessment often carrying penalties for failures.
- Penetration Test
Part of a vulnerability assessment and uses hands-on adversarial (“hacker”) techniques to validate findings (exploit feasibility), identify more complex vulnerabilities, or test existing security controls (breach feasibility). Note: A penetration test, on its own, is not meant to provide the level of comprehensive vulnerability identification that a complete vulnerability assessment would.
- Red Team Exercise (Red Team Test, “Red Teaming”)
An exercise that simulates a realistic cyber-attack (sometimes also deploying physical intrusion), where the red team (the attackers) deploy actual offensive techniques and strategies in an attempt to breach the target network and system(s). Such exercises are meant to test an organization’s overall security defenses, including threat monitoring and response capabilities (the blue team).
- Purple Teaming
A more recent term to better emphasize the blue team engagement during a red team exercise. (red + blue = purple)
- Risk Assessment
The entire process of identifying assets, vulnerabilities, consequences and impacts of incidents, and prioritization based on a risk score. Note: If the final result of the process does not include some level of risk scoring or prioritization, it’s not a risk assessment. Additionally, vulnerability scoring (i.e., CVE/CVSS) is not necessarily risk scoring. Risk scoring should be specific to your organization and consider the impact to your business (financial, production, safety, etc.).
Again, I will cover more specifics about each of these in subsequent articles. For now, hopefully this helps clear up some of the confusion between the different terms, assessment types, and what you actually need for your situation.
Problem 2: Most Risk Assessment Processes Are Backwards
Most risk assessment processes I see go like this: Step 1. Identify vulnerabilities (in some cases they just perform a penetration test or a gap assessment). Step 2a. Attempt to prioritize remediation based on the vulnerability CVSS score. Or Step 2b. In some cases, organizations will assign a “criticality” score to assets, and then prioritize remediation by asset risk, calculated using the asset criticality and vulnerability scores. (Good job! But you’re still doing it wrong.) In the end, you’re still left with a heap of problems to fix, but at least they’re prioritized. Right?
So, what’s wrong with this process and why am I calling it backwards? Most organizations spend too much time and money performing exhaustive vulnerability assessments on most, if not all, of their assets, prioritizing every finding, and trying to tackle all the remediation. Risk prioritization is good and should be performed. However, by reordering some of the steps normally performed in the risk assessment process, you may find that you can significantly reduce the amount of vulnerability assessment work needed, as well as the number of high priority “fixes” on your list. In doing so, saving you time and money.
Here is the process I recommend:
- Identify your assets and organize them by “criticality”.
Criticality is a term used to describe what the impact level would be for a give asset if that asset were out of service. Performing this step at the beginning of your assessment, rather than near the end, can potentially save you a lot of time and effort throughout the rest of the process. Case in point, assets with a low criticality (i.e., low risk) can be moved lower down on the list, or even eliminated from the assessment altogether in some cases. - Identify all the access vectors to each of those assets, starting with the assets with the highest criticality.
This is a step I see that is missed in most assessments. Yet, it is probably the step that could save you the most time in the long run. Access vectors are the ways in which humans or other assets can access another asset. This could be a network connection or physical access. Identifying the number and type of access vectors can lower the overall risk rating of an asset, thus, reducing the level of risk assessment and management effort needed for that asset. For example, if there are no network connections to an asset, the vulnerability assessment, and especially the remediation, for that asset only needs to take into consideration local access for now. Note: In this case we are only considering network and physical access vectors. Logical access control is not considered in this step. - Prioritize based on criticality plus the number of access vectors.
Assets with fewer access vectors and/or those inside trusted/private zones would also be lower on the priority list (requiring less attention and level or effort later) than those with more access vectors and/or in less trusted zones. Trust zones and internet access should also be considered. For example, assets without internet access and/or in more trusted zones could be lower on the list. - Perform vulnerability assessments, starting with your highest priority assets first for the technical assessments.
This step is where you should see your earlier work really start to pay off. Vulnerability assessments typically make up the bulk of the work of a risk assessment. So, by starting the prioritization process at the beginning of the assessment, you should be able to postpone, if not eliminate, some of the vulnerability assessment work here. Remember, your vulnerability assessments should include human, processes and procedures, and technical vulnerability identification. But for asset specific evaluation, especially technical inspection, you can move lower risk assets (i.e., those with lower criticality and fewer access vectors) further down on the list. Assets lower on the list can be assessed later in the process, moved to a time when resources allow it, or eliminated from the assessment process altogether in some cases. Note: I recommend avoiding automated vulnerability scanning on most production OT networks. - Prioritize risk and remediation by asset, not by vulnerability.
At the end of a vulnerability assessment, many organizations prioritize every vulnerability (usually by CVSS score) and remediate each of the vulnerabilities according to priority. Even prioritized, this can be a huge undertaking. Especially if you used automated vulnerability scanning! Instead, create a cumulative vulnerability score for each asset. I prefer to create a score based on the number and severity level of critical and high vulnerabilities, as well as the number of vulnerabilities that would allow an attacker to gain access to the systems (e.g., remote code execution, remote access, etc.).
I then use the asset critically rating and number of attack vectors as modifier values to create a final overall risk score for each asset, which I can use to provide the final asset prioritization. The details of the formula I use are not important for the purpose of this article. You can use whatever formula or calculation method that makes sense to you. The important thing is that you use the same calculation method for every asset, and the final result allows you to prioritize assets based on the values that are important to you in your prioritization.
Hint: When you’re preparing to remediate vulnerabilities and you see hundreds of them, remember that most of them all have a common fix with several other findings. A common OS patch or removing unneeded applications like Adobe, for example. I even use a spreadsheet to help simulate the amount of attack surface reduction I get by applying each fix.
In summary, prioritization should start at the beginning of the entire assessment process, not wait until the end.
Problem 3: Assessments Are Treated as a “One-Off”
Almost every organization I speak with treats vulnerability assessments, and even risk assessment, as a “one-off” project or annual occurrence. Some of those organizations are at least comparing subsequent assessments with previous ones, to hopefully show progress. That is what you should be doing at the very least. However, always having an understanding of your risk profile at any given time, and showing progress throughout the year, rather than from year to year, is much more effective. This doesn’t mean you need to be performing multiple risk assessments throughout the year. Having a framework, on the other hand, that can ingest data regularly and always provide an active “living” risk profile as you make progress, is recommended. Having such a framework also helps keep assessment data and remediation tasks organized.
Most of the top OT specific threat monitoring platforms (e.g., Forescout, Claroty, Dragos, Nozomi, Tenable.ot, Microsoft Azure Defender for IoT, etc.) have risk scoring and tracking mechanisms built in to varying degrees. However, I also recommend using a platform that is dedicated to OT risk tracking and management by correlating data from multiple sources such as SecurityGate.io and GPAidentify.
Conclusion
OT risk management isn’t easy, and for most people it probably doesn’t seem very glamorous. To make matters worse, most organizations spend more time, effort, and money on the process than they need to. By understanding all the terms and steps involved in a risk assessment, rethinking how and when you prioritize your assessments and findings, and using an ongoing process combined with a risk management framework, your risk management process and program will be more efficient, effective, and won’t tax your resources nearly as much.
About the Author
Clint Bodungen is a world-renowned industrial cybersecurity expert, public speaker, published author, and gamification pioneer. He is the lead author of Hacking Exposed: Industrial Control Systems, and creator of the ThreatGEN® Red vs. Blue cybersecurity gamification platform. He is a United States Air Force veteran, has been a cybersecurity professional for more than 25 years, and is an active part of the cybersecurity community, especially in ICS/OT. Focusing exclusively on ICS/OT cybersecurity since 2003, he has helped many of the world’s largest energy companies, worked for cybersecurity companies such as Symantec, Kaspersky Lab, and Industrial Defender, and has published multiple technical papers and training courses on ICS/OT cybersecurity vulnerability assessment, penetration testing, and risk management. Clint hopes to revolutionize the industry approach to cybersecurity education, and help usher in the next generation of cybersecurity professionals, using gamification. His flagship product, ThreatGEN® Red vs. Blue, is the world’s first online multiplayer cybersecurity computer game, designed to teach real-world cybersecurity.
About ThreatGEN
ThreatGEN bridges the “Operational Technology (OT) cybersecurity skills gap” utilizing the ThreatGEN® Red vs. Blue cybersecurity gamification platform and our OT Security Services, both powered by our world-renowned OT cybersecurity experts and published authors. The ThreatGEN® Red vs. Blue cybersecurity gamification platform uses cutting-edge computer gamification to provide an exciting & modernized approach to OT cybersecurity training, both practical and cost effective! Our OT Security Services use our decades of industry experience combined with strategically chosen partnerships to create a holistic service offering.
For more information, visit our company website at https://ThreatGEN.com, follow us on LinkedIn at https://www.linkedin.com/company/threatgenvr/, or follow us on Twitter: @ThreatGEN_RvB.
For further sales information, send an e-mail to sales@threatgen.com.
Derezzed Inc. D/B/A ThreatGEN
Sugar Land, Texas 77478
+1 (833) 339-6753
#OT #cybsersecurity #riskmanagement
###