Risk is a measure of the extent to which an entity is threatened by a potential circumstance or event. It is typically a function of two factors. The first is the adverse impacts that would arise if the circumstance or event occurs. The second is the likelihood of occurrence.  

Source:NIST 800-30

Protecting and defending the ICS network from threats and malicious adversaries is not straightforward. It requires a structured approach. Additionally, a well laid out risk assessment strategy is necessary. Each organization has a different risk appetite. In order to know yours, you need to perform a phase wise risk assessment. This assessment should target each IACS asset in the network to evaluate SL-T (service level target) ratings.

Performing risk assessment helps us understand the potential consequences in the event when the IACS network is compromised. The purpose of high level risk assessment is to identify and evaluate the worst case unmitigated risk to IACS. Whereas detailed risk assessment purpose is to identify and evaluate credible risks to IACS.

IEC62443-3-2 standard assists the asset owners, engineers, and security professionals to scope SuC (system under consideration). It helps in partitioning assets in zones and designing conduits. The standard supports evaluating security risks. It aids in establishing SL-Ts (service level target) and identifying security requirements. Once the activity is completed the residual SL-T for each zone and conduit can be documented.

Please note that IEC 62443 references back to other related standards. These include frameworks available such as NIST CSF, NERC-CIP, and NIS Directive, etc. So, we will also reference to the best standard available for planning and conducting risk assessment i.e. NIST 800-30. As per NIST, risk assessments can support wide variety of risk-based decisions and activities such as.

1. Development of information security architecture
2. Definition of interconnection requirements for information systems
3. Design of security solutions for information systems
4. Implementation of security solutions
5. Operation and Maintenance of security solutions

As per IEC after the risk assessment activity and evaluation of SL-T ratings, the foundational requirements (FR) are identified. This is followed by the evaluation of security requirements (SRs) and requirement enhancements (REs) based on different security levels (SL), as follows.

The Risk Assessment Process

Doing risk assessment in ICS is a simple process. Most of us often get overwhelmed with the details involved with the task. This leads to an unstructured approach and inadequate SLTs. Below is risk assessment process flow from NIST-30, depicting various stages.

Step 1 the preparation phase of the risk assessment consists of activities;

• (i) Identify and define the purpose of the assessment
• (ii) define the scope
• (iii) Identify assumptions and constraints, if any
• (iv) identify communication channels, sources of information, stakeholders to be used during the assessment
• (v) Identify sources of threat, vulnerability, and impact information to be used in the risk assessment.
• (vi) Identify the organizational risk model to be employed during the assessment.

Step 2 is the execution phase. We need to develop and utilize threat modeling techniques. We also need to draft custom risk scenarios for each IACS asset. There are numerous threat modeling techniques available such as MITRE, STRIDE, DREAD, OCTAVE, MORDA, etc. which can be used to understand the tactics, techniques and procedures (TTPs) utilized by adversaries.

To get the most credible rating for your IACS asset, you need to develop custom risk scenarios. These scenarios should be based on real-world threats targeting specific assets. Remember the scenarios should be based on the assumption that an adversary can penetrate system security. They should also maintain persistent access. One of the previous blog can help you to structure your threat modelling approach.

Below risk and threat identification process flow developed by NIST depicts how threat sources turn to events. These events lead to the exploitation of vulnerabilities, followed by impacts and organizational risk.

Now, as part of Step 2 of the risk assessment process, we will learn how to utilise IEC 62443-3-2. This standard can be used to perform high and detailed level risk assessment.

To start building custom threat scenarios, we need the asset inventory. We will utilize the asset inventory from previously published blog. The asset inventory needs to have basic details. These include OS type, OS version, services/protocols, and applications installed. (Assets listed below are fictional like superman 😃). Such Information will help us develop custom scenarios based on real-world threats. For e.g. It is highly likely that a malicious adversary can exploit an unpatched Windows 7. They can also exploit Windows 2008 R2 and Windows 2012 operating systems using MS17-010 Eternal Blue exploit.

Below is our sample detailed asset inventory with all the information we would need for building custom scenarios.

If you do not have the detailed asset inventory, you can opt to execute automated scans. This is possible given you have the authorization. Alternatively, you can manually enumerate each device at a time. This will help you collect information such as operating system, applications installed, services running, protocol, etc.

I will be using the risk scenario template provided in NIST 8286A. I will also use the threat sources taxonomy detailed in NIST 800-30 to record the output during the execution phase. Below is the reproduction of the sheet. I have also prepared below sample risk matrix which will help me to rate the scenarios prepared.

Information such as Risk Category, Likelihood, Impact will be based on a corporate risk matrix. Data from business impact assessments will also be used. Please note that the information listed above is only for illustration purposes. The ratings assessed during the execution phase are mostly subjective. Each asset owner and security engineer would rate the above scenarios in a different way. This is totally acceptable. Also, remember while conducting high level risk assessment we are open to consider worst case without considering existing controls.

During the detailed risk assessment the same risk scenarios can be utilized to evaluate the residual SL-T ratings. You can also customize the scenarios to a more sophisticated risk. For e.g. Post exploitation of EWS installed using MS17-010 Eternal blue exploit, adversary utilizes PsExec exploit from Metasploit for lateral movement.

The only difference this time would be that we will consider the existing security controls/ countermeasures. These include network segmentation, which blocks lateral movement. Also, anti-malware services to block ransomware attempts. Authentication and access control will block unauthorized access attempts. Power backups protect against infrastructure failures. Physical security mechanisms defend against direct access attacks to our network. The SL-Ts might look different as the likelihood and impact of the cyber attacks would changes. Below is the updated sheet based on our detailed risk assessment.

Step 3 The third step would be to share the risk assessment results. It is also important to communicate these results to the management. This is necessary to support decision making and risk management activities. While preparing the report, it is critical to include key items. These include an executive summary for the management. It should also contain a detailed technical report showcasing each risk scenario and their output. Additionally, an optional dashboard can depict the current risk scenario.

The report output from the high level risk assessment and initial security zones & conduits provides an overview. It highlights operation critical systems. Whereas, detailed risk assessment provides in-depth understanding with respect to traffic flow, asset behavior and security technologies.

Step 4 continuously monitor the risk ratings and update as needed. It will evolve with technological advances and updates to your existing environment over a period of time. It will also change with threat capabilities and evolving APTs, etc.

Conclusion

Risk assessment is a critical element for every organization’s cyber security maturity program. It should be performed by the asset owners for each IACS asset. Security engineers and asset owners need to practice risk assessment on a continuous basis to know their environment better. Below is a pictorial and summarized version of risk assessment stages as per NIST 800-30 for your reference.

References:

• IEC 62443-3-2: https://webstore.iec.ch/publication/30727
• NIST Guide for Conducting Risk Assessments: https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final
• NIST Integrating Cybersecurity and Enterprise Risk Management: https://csrc.nist.gov/publications/detail/nistir/8286/final
• SANS Managing ICS Security with IEC 62443 https://www.sans.org/reading-room/whitepapers/networksecurity/managing-ics-security-iec-62443-39990
• SANS Effective ICS Cybersecurity Using the IEC 62443 Standard: https://www.sans.org/reading-room/whitepapers/analyst/effective-ics-cybersecurity-iec-62443-standard-39960
• IEC 62443: https://syc-se.iec.ch/deliveries/cybersecurity-guidelines/security-standards-and-best-practices/iec-62443/
• Leveraging ISA 62443-3-2 For IACS Risk Assessment and Risk Related Strategies: https://gca.isa.org/leveraging-isa-62443-3-2-for-iacs-risk-assessment-and-risk-related-strategies
• MITRE Cyber Threat Susceptibility Assessment (TSA): https://www.mitre.org/publications/systems-engineering-guide/enterprise-engineering/systems-engineering-for-mission-assurance/cyber-threat-susceptibility-assessment
• Schneider Practical Overview of Implementing IEC 62443 Security Levels in Industrial Control Application :https://download.schneider-electric.com/files?p_Doc_Ref=998-20186845
• How to define zones and conduits: https://gca.isa.org/blog/how-to-define-zones-and-conduits
• System Segmentation: http://www.app5.unisys.com/library/cmsmail/SCO/BR_170722_SystemSegmentationAFundamentalConcept.pdf
• OT Systems Management: https://verveindustrial.com/resource_subject/ot-systems-management/
• Using IEC 62443 to improve system security: https://www.tofinosecurity.com/sites/default/files/common/white-papers/Using-ISA_IEC-62443-Standards-WP-v1.2%20(May%202014).pdf