Demystifying ICS Cyber Risk with FAIR Analysis
Posted on 20 Aug 2019 by John McDonald
When it comes to cybersecurity, organizations that use Industrial Control Systems (ICS) tend to be at a disadvantage. There are unique factors that affect managing risk for such systems.
In this blogpost, find out what makes managing risk a slippery slope for Industrial Control Systems. See how using FAIR methodology to quantify risk can help you pinpoint your biggest cybersecurity vulnerabilities — and spend budget intelligently. Find out how using FAIR methodology can help you focus the right amount of time and money to prepare for the likelihood of cyber attacks, just as you prepare for the likelihood of systems failures.
ICS has unique challenges that map to increased risk. With ICS, the landscape is opening up for operating systems and networks to connect with systems far beyond plant operations. Let’s consider the unique challenges of ICS and how they map to increased risk. In the figure below, see the summary of challenges and how they heighten risk in an industrial setting.
Challenge 1: Moving from ‘closed’ systems to ‘open’ systems – In the past, ICS systems tended to use very specialized software and operating systems, with very limited and controlled network interfaces. Most ICS vendors have migrated their system to general purpose operating systems such as embedded Microsoft Windows, with much broader and deeper network interfaces, significantly increasing their attack surface.
Challenge 2: For operational or financial reasons, many ICS organizations are stuck with using older in-place technology, which may not have up-to-date security features.
Challenge 3: Migrating to more modern and (potentially) more secure ICS system can be expensive.
Challenge 4: Unlike many other organizations, realized ICS cybersecurity risks can have an immediate and significant negative impact to a large number of people outside of the organization itself.
Challenge 5: – Organizations that use ICS tend to have numerous complex relationships and interconnections with other organizations, providing a large number of potential attack vectors.
Challenge 6: Minimal regulatory requirements to drive the necessary investments in cybersecurity (although that’s changing).
Check list approach ticks boxes, but does not quantify risk
Many ICS organizations have adopted the common checklist approach to cybersecurity. People will use a regulation (such as NERC/FERC) or a framework (such as NIST CSF) as a check list, and qualify any gaps in their controls as a “risk.” Additionally, people may use tools such as vulnerability scanners to identify potential configuration or systemic vulnerabilities and add those to their risk register, then use that list to drive their cybersecurity investments.
Organizations may also incorporate some form of subjective quantification to rate their risks, utilizing scales such as 1-5 or colors such as red, yellow and green. The problems with such an approach are that a) it only shows that gaps and vulnerabilities exist, not what their actual impact might be, and b) the subjective scale only rates the potential significance of the gaps/vulnerabilities relative to each other, and not the impact to the overall organization. So what can an ICS organization do to mature their cybersecurity risk management program to make it more relevant to the organization?
A look to the past helps focus on future
Ironically, organizations that use ICS technology figured out decades ago that in order to effectively focus their limited resources, they needed to understand the financial impact of events that affect their ICS systems. Most such organizations already know the what the financial impact would be if a pump fails, a transformer is destroyed by lightning or a component overheats and shuts down a process. These organizations know how to plan for system failure and allocate their resources to address such scenarios.
To gain the same level of consideration in the corporate planning process as potential system failures, the cybersecurity risk management team needs to leverage similar methodologies to describe the risk of potential failure caused by cybersecurity attack. The cybersecurity team needs to define their risks in terms of expected events, instead of discrete gaps and vulnerabilities, and quantify those possible events financially utilizing the Factor Analysis in Information Risk (FAIR) methodology.
First component: Defining risk. The first component, defining risks in terms of events, is actually how risk is already defined by both the NIST Risk Management Framework (RMF) and ISO 31000 Risk Management Guidelines. The goal is to define threat sources and target assets, identify potential impact scenarios from those sources, then determine the likelihood and impact of such an event being realized. These risks should be entered into a formal risk register, and reviewed and updated as circumstances change.
Second component: FAIR analysis. The second component can be a little more complicated, but because FAIR is an open standard (see https://publications.opengroup.org/guides/open-fair) and can be learned and applied easily in most organizations, implementing the FAIR methodology can be fairly straightforward for anyone with a decent foundation in risk management.
FAIR analysis can be done manually or with a spreadsheet tool, but in order to utilize it on an on-going basis for anything more than one or two risks you should consider acquiring a tool such as RiskLens, or leverage Cyber Risk Quantification as a Service from TUV Rheinland OpenSky. If your company is considering FAIR, chat with our experts in person at FAIRCON19
When an organization has identified and financially quantified their cybersecurity risks, it allows management to confidently leverage the same decision-making process to allocate resources for cybersecurity that they use for other ICS-related risks.