The exposure of industrial facilities to cybersecurity threats has never been higher. An analysis performed by IBM security found that the number of attacks on SCADA systems increased 636% from 2012 to 2014, with 675,816 cybersecurity incidents in January 2014 [1]. Finding an effective method for evaluating the current level of risk in a facility and implement additional security risk reduction as needed is becoming an essential part of managing the safety, security, and operability of industrial systems.

The three fundamental activities for the analysis of cybersecurity risk are High-Level Risk Assessments, Detailed Risk Assessments, and Security Level Verification. This is the final installment of a three-part blog series breaking down the IEC 62443 lifecycle steps for evaluating cybersecurity risk.

The Security Level Verification is the third cybersecurity analysis, which reviews the conceptual design of the network and its countermeasure to verify that it adequately mitigates the cybersecurity risk identified during the earlier risk assessments. This verification is conducted against all previous lifecycle steps and ensures that not only have the risk assessment results been considered, but also that all requirements documented in the CSRS have been followed during the initial design.

The steps for completing security level verification for a network zone are detailed in the following workflow.

SL Verification Inputs

The security level verification is conducted during the implementation phase, after the conceptual design of the IACS and associated countermeasures has been completed. In addition to the design information, the key inputs are from the high-level and detailed risk assessments. Together, the risk assessments provide a comprehensive zone and conduit diagram, documenting the boundary devices used to segment higher security zones, as well as finalized security level targets for each of these zones. This, combined with the organization’s tolerable risk criteria, is used to determine the tolerable frequency of successful attacks of varying severity. These are the risk targets that are used to evaluate if a current design meets the security level requirements for a zone.

Additionally, the list of countermeasures and the determined frequency of initiating cybersecurity events determined as part of the detailed risk assessment are direct inputs into the SL verification work process. 

Transferring Existing Cybersecurity Events and Countermeasures

The first step in the security level verification is to compile a list of all initiating cyber events that could lead to a hazardous scenario and document the countermeasures identified for each scenario. The detailed list of countermeasures and the granularly defined frequency for initiating cyber events (both completed as part of the detailed risk assessment) provide a strong foundation for this step. This information transfer can be completed accurately and efficiently by using a tool such as exSILentia cyber, which allows information from the detailed risk assessment to automatically populate the SL worksheet per hazardous scenario.

Evaluate Target Attractiveness, Kill Chain Relevance, and Conditional Modifiers

Once the initiating cyber events and countermeasures have populated the security level worksheet, the next step is to determine what factors will affect the overall likelihood of a successful cybersecurity attack.

The first factor to consider is the target attractiveness of the facility under consideration. The target attractiveness is a modifier greater than 1 that is multiplied by the threat likelihood to determine how likely a facility is to be targeted. The target attractiveness is determined based on several criteria, including facility size, type of facility/industry, owner/operator of facility, location of facility, current political climate/public opinion. One way to maintain the consistency of target attractiveness evaluation within an organization is to define a target attractiveness matrix that can be used to determine the overall appeal for each site.

The second factor to consider is the Kill Chain® relevance to a specific attack. Lockheed Martin developed the cybersecurity kill chain to identify the key steps necessary for a successful attack leading to hands-on keyboard access in cybersecurity attacks. Identifying how far along the chain an attacker needs to go to be successful and identifying what other targets must be compromised as part of the overall attack can provide important guidance on what the overall likelihood of a successful complex engineered attack would be for a given control system.

The final factors to consider are any conditional modifiers that would impact the likelihood of a given consequence to occur. The use of conditional modifiers in industrial cybersecurity analysis is roughly analogous to the use of conditional modifiers during Layer of Protection Analysis in functional safety. A common conditional modifier is occupancy: what is the probability that an operator will be in the area when a hazardous situation occurs?

Determine Countermeasure Effectiveness and Applicability

The next step is to determine what independent countermeasures apply to which specific threat vectors, and how effective those countermeasures are. The key principle for cybersecurity countermeasures is defense in depth: this provides many independent barriers of defense between potential threats and the control network so that even if an attacker can bypass or overcome some layers, there are still more protections in place, making it time-consuming and difficult to access the control system. This approach has been used for physical security for thousands of years; castles were defended by layers of protection from moats, strong outer walls, guard houses, to locked gates, and many more. 

To be effective, each of these protections or countermeasures must be independent so an attacker isn’t able to overcome all measures with a single effort. As such, care should be taken to avoid crediting multiple countermeasures that can be overcome by a single attack type. For example, access control is a good method of improving the security of access accounts to industrial control systems, but credit for active account management and the least-privilege method of assigning accounts should not both be credited during SL verification, because one set of stolen credentials would allow an attacker to bypass both. Instead, they should be looked at together as one strong countermeasure.

After a countermeasure has been determined to be independent from other listed countermeasures, the next step is to evaluate how effective the countermeasure is at reducing the likelihood of a successful cybersecurity attack. Unlike in functional safety where there is a wealth of data leading to reliable failure rates for safeguards, currently no significant data exists on the likelihood of countermeasure failures. Instead, conservative estimates must be made to provide a good understanding of how much cybersecurity risk is reduced. 

One method for this is to credit well-designed, managed, and maintained active countermeasures: the ability to prevent a successful attack from occurring without operator intervention (e.g., well-managed firewall, hard-coded endpoints in controller code) with a probability of countermeasure failure of 0.1. For well-designed, managed, and maintained passive countermeasures, it’s the ability to prevent an attack if the operator takes defined action in sufficient time to prevent ultimate consequence (e.g., review firewall log, periodic review of controller code); a probability of countermeasure failure of 0.2 is credited.

The last step in crediting countermeasures is to determine which specific threat vectors a countermeasure applies to. This can be important when multiple threat vectors lead to the same hazardous scenario—i.e., stolen credentials, and third-party integrators both can provide access to the system leading to an attack resulting in unexpected downtime. 

A countermeasure such as improved operator cyber hygiene training that reviews Phishing and other techniques used to steal operator/administrator credentials would be effective for reducing the likelihood that credentials are stolen but would not reduce the likelihood of an attacker getting in through third-party access.

Target Likelihood Met?

Having the granular information for countermeasure effectiveness, including relevance to specific threat vectors, allows additional countermeasures to be designed specifically for the threat vectors limiting the overall risk reduction, ensuring that additional measures for cybersecurity are addressed in an optimal manner.

In addition to taking steps to meet the risk reduction requirements, it is also important to meet the systematic capabilities for cybersecurity. Key steps for this include:

• Ensuring physical and personnel security are consistent with SL-T for assets located within a zone.
• Ensuring the development of devices and systems within a zone meet the security requirements 62443-4-1 and 62443-2-4 respectively.

Outcome

The Security Level verification represents a review of all previously completed cybersecurity lifecycle tasks. After the design has been verified to meet the appropriate security level, a project moves to the construction and subsequent operations and maintenance phases of the lifecycle. The activities performed for cybersecurity risk assessment and verification outline the key metrics for monitoring the performance of the system and countermeasures throughout the life of the facility.

Furthermore, if it is determined that the security level for a zone is not met, the SL verification supports the comprehensive evaluation of the added security benefits for additional countermeasures versus the additional costs of these measures consistent with the As Low as Reasonably Practicable (ALARP) approach as determined by corporate risk criteria. As such, the security level verification provides the granular view of remaining cybersecurity risk necessary for effective decision-making.

To learn more about security level verification or ask questions, register for our upcoming webinar.

Go back to Part 1

Missed the beginning of the series? Catch up on:

• High-Level Risk Assessment
• Detailed Risk Assessment

 [1] McMillen, D., Security Attacks on Industrial Control Systems, IBM Security, 2015, https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=SEL03046USEN.