Where to Start — the System or the Function?

This article has been adapted verbatim from a paper accepted and presented during the International Conference on Computer Security in the Nuclear World: Securing the Future titled ‘Where To Start — The System Or The Function? How The V-Model Clarifies Effective Computer Security’ authored by Mike StJohn-Green and myself.

Abstract

IAEA guidance on computer security calls for two levels of risk management, initially a function-based analysis followed by a systems-based analysis. This concept of multiple levels of risk analysis is also present in other computer security standards (IEC 62443, IEC 62645, NRC), although they differ on the details of whether a graded approach should consider impact, adversarial-skill, or likelihood. However, the most significant practical challenge in implementing this guidance is bridging the functions-systems analyses, resulting in a struggle to translate between impacts, risks, and vulnerabilities.

Integrating this analysis directly into the engineering lifecycle, however, enables Secure-by-Design. This method resolves the issues preventing designs that are merely compliant on paper from remaining vulnerable in practice. It highlights the need to prepare for and perform risk management throughout the operational lifetime of the plant.

This paper directly addresses the transition from an analysis of functions with risks to an analysis of systems with vulnerabilities, a topic that current publications do not explore in detail. It will present an engineering lifecycle view that fosters holistic security by design, is consistent with the major publications, and harnesses complementary physical and personnel security measures that work coherently to achieve safety and security objectives. This perspective on the engineering lifecycle offers a practical interpretation of the function-based concept for those seeking to implement IAEA and other guidance.

1. Introduction

A security risk can be described in terms of the capability, motivation and opportunity of a threat actor to act on a combination of vulnerabilities to cause an adverse outcome. To fully understand what adverse outcomes are possible in a nuclear power plant calls requires a top-down function-based understanding of the entire plant. However, the threat actor has to exploit vulnerabilities, to create credible attack scenarios in order to be successful in their malicious intent. It would be disproportionate to defend against an attack that is genuinely inconceivable. For computer security, this analysis calls for very detailed knowledge of how the digital technology in a nuclear power plant works, suggesting a bottom-up approach.

Effective security requires both high-level strategy and a granular defence. A purely top-down functional analysis will ignore detailed vulnerabilities, while a strictly bottom-up asset-by-asset analysis without understanding their functional contribution and significance will lead to a disproportionate and flawed defensive architecture. Neither will deliver a graded approach on their own, as called for in IAEA guidance ¹. Therefore, whether designers are starting with a blank sheet of paper and a requirement to design a nuclear power plant or working in an operational plant, with computer-based control systems that need upgrading, it is necessary to analyse both the higher-level functional design and the lower-level system design. The need for multiple levels of risk management is reflected in IAEA guidance and in some international standards but there is a lack of consistency and consensus about how this might work in practice.

Further, computer security requirements need to be considered early in the design process, alongside those for safety, physical security and safeguards in order to achieve coherence and complementarity in the manner in which they are delivered, and achieve security-by-design.

This paper describes the relationship between the two levels of risk management and how they collectively fit into the mainstream engineering design activities of a nuclear power plant, with its multiple opportunities to reduce the consequences and risks of malicious action. This also allows for non-security risks to be managed with the same process. It suggests a closer working relationship between all the disciplines.

2. Current Computer Security Guidance

IAEA guidance in NSS 17-T (Rev 1) ² divides the risk-based approach into Facility Computer Security Risk Management (FCSRM), focused on functions, and System Computer Security Risk Management (SCSRM), focused on the implementation of those functions using computer-based systems. In Figure 1 ², the system level is shown embedded within the functional level and there is evidence of the iterative nature between the different stages. The Computer Security Programme (CSP) and the Defensive Computer Security Architecture (DCSA) are two of the enduring artefacts that provide continuity between the different stages.

Figure 1 – IAEA NSS 17-T (Rev 1) Figure 6, Overview of the computer security risk management process ²

IAEA guidance ^{1 2} recommends that the graded approach defined at the higher functional level should be based on the consequences of the adverse outcome. This involves identifying and seeking to reduce the inherent risk of the project or plant design through the establishment of barriers at an architectural level. At the system level, the defender considers the combination of the threat actor’s capability, motivation and intent to cause the adverse outcome with an understanding of the vulnerabilities in the target.

It is worth noting the operator’s perspective on the management of risk will have a much wider scope of adverse outcomes than the protection of nuclear security. For example, the operator must also manage risks to the provision of essential critical infrastructure services and business risks of profitability.

An important internationally-recognised pan-industry standard for the computer security / cybersecurity of Industrial Control Systems, IEC 62443-3-2 ³, also describes a two-level approach, see Figure 2. The language in IEC 62443-3-2 differs from IAEA guidance in that there is no mention of functions in Figure 2 but the initial cyber security risk assessment (ZCR 2 in Figure 2) based on severity of (functional) consequences leads to the partitioning into security zones. This aligns well with the output of FCSRM (i.e. the functional level) in the IAEA guidance. The detailed risk assessment (ZCR 5 in Figure 2) then seeks to reduce the residual risk for each zone to an acceptable level. This equates to SCSRM in the IAEA approach (i.e. the system level) though IEC 62443-3-2 here refers to zones that contain systems. There are other important differences in the treatment of likelihood of a successful attack when determining what strength of security measures are proportionate, and the resulting nature of the graded approach. The differences reinforce the point that there isn’t yet a consensus of guidance, but the similarity in the need for multiple levels of management of risk through a graded approach is nevertheless evident.

Figure 2 – IEC 62443-3-2, Flow diagram for Security Risk Assessment for Design ³

It is worth noting that the outputs of Process Hazards Analysis (PHA) are an input to the initial risk assessment shown in Figure 2. Similarly, the Facility Safety Report appears in Figure 1 from the IAEA. This illustrates how safety-related work informs the security risk assessment, to ensure that the output of computer security risk management supports the needs of safety. This paper argues that the relationship between the two disciplines should be close.

3. The Argument For A Single, Coherent Design Activity

It has now widely quoted that for a computer-based system “If it’s not secure, it’s not safe.” ⁴, a position supported by this paper. This means that the safety case of a system, such as the control system for a nuclear reactor, cannot be deemed valid without adequate assurance that the control system is protected from malicious action. This paper asserts that analysis of how malicious action may undermine safety must be part of the design activity. Therefore, security should be designed to support safety and both should also be designed in a coherent and mutually-reinforcing manner.

This need for complementarity also applies to physical security (e.g. tampering with sensors that have a role in safety), personnel security (e.g. the insider) and computer security (e.g. interfering with digital technology).

Computer security relies on adequate, complementary physical security and personnel security measures. For example, if an adversary can gain unconstrained and undetected access to the computer hardware or networks, a wide range of possible attacks become possible. Additionally, physical security and personnel security rely heavily on computer-based systems. For example, digital surveillance cameras connected to a network can be spoofed to mislead the Central Alarm Station staff, and delay physical security response, if computer security is inadequate. Identity and Access Management relies on the security of the information to underpin the control of personnel access for many purposes. All forms of security have a relationship with information security because trusting the confidentiality, integrity and availability of information is both a necessary foundation for and outcome of the other forms of security. This paper argues, therefore, that the means to deliver the different forms of security should therefore be designed in a coherent and mutually-reinforcing manner.

As the resilience of energy generation becomes a prominent national security issue and must be considered alongside traditional nuclear security, this argument for holistic design process extends still further, into the mainstream operational design activities.

Cost-effective construction and operation of nuclear systems also demands a coherent, holistic design that combines security requirements with other requirements as part of the options analysis. Consider, for example, the incentives on designers to use Wi-Fi in advanced reactor designs, to reduce the cost of wiring. The total savings should be offset as part of the initial design analysis by the cost of protecting the Wi-Fi from malicious action, to provide designers with an informed choice.

What is being described in this paper is a traditional engineering design process that considers the different functional, e.g. energy generation, and non-functional, e.g. safety and security, requirements together. This is not a new concept to systems engineers but is not universally recognised by security engineers, who are often taught to see security activities through their own largely independent security lifecycle ^{2 3}. However, this paper is not unique its message that “… security … must be fundamental to systems engineering, not just a specialty discipline. Security concepts must be fundamental to (an) engineering education, and security proficiency must be fundamental in development teams.” ^{5 6}

Figure 3 – Where security risk is primarily managed in a simplified engineering lifecycle model

4. The Engineering Lifecycle

Figure 3 is an interpretation of a classic engineering lifecycle, often described as a ‘V Diagram’, that has been amended for this paper to emphasise the activities of computer security risk management in that lifecycle. Figure 3 was inspired by a diagram in nuclear safety guidance ⁷, and derived from a more complex diagram at Annex 1. The following subsections step through Figure 3 to describe in more detail how computer security risk management can engage in the engineering lifecycle. This can represent an entire plant or a small project.

4.1. Project Definition

Initially, in the engineering design process, security is very much a reaction to the conceptual requirements – if you want to use nuclear material, you will need some protections. The high-level, functional design can only be practically achieved at a high level of abstraction, before refining requirements with increasing levels of detail in the design and implementation, which will likely later identify the need for and use of computer-based systems.

Security involvement should be focussed on reducing or eliminating the potential consequences of malicious action, such as by reducing the inventory of nuclear material. Because these design factors are determined by the initial concept and then reflected in the functional specification of the plant (or project), early security involvement is critical. Furthermore, the manner in which security will support safety and other organisational objectives and how the different aspects of security will work together need establishing.

By failing to address security at this stage, there are some obvious consequences: the organisation misses cost-effective opportunities to the possible consequences of malicious action and thus reduce inherent risk; and because the analysis of risk starts too late, it loses its relationship to the top-level requirements for the plant/project. Ultimately, this delay prevents security from integrating coherently with other disciplines.

4.2. Functional Design

During the functional design, the represented design teams are making choices about the plant and its control systems at a high level of abstraction. At this point, the requirements describe a set of functions and may still be entirely agnostic of the type of technology that will be used, though some constraints may already have been introduced to reduce inherent risk. Once the combined functional design has been completed, a high-level block-diagram design will be defined, with candidate systems nominated to deliver the functional requirements.

Within this phase there should be further opportunities to reduce the inherent risk, such as by reducing the quantity of sensitive information that will be exposed, by design. This focus on inherent risk and then residual and is reflected in the US NRC pre-decisional publication on Tiered Cybersecurity Analysis ⁸.  

At this point, the designers should be developing scenarios on how adversaries might cause adverse security outcomes, developing a big picture view of major consequences and identifying barriers that further reduce the inherent risk. The designers don’t yet know why a barrier might fail, just that it should exist. Failing to reduce the risk at this point means there will be a higher level of inherent risk to be managed later with a greatly reduced control set and, again, there may be a loss of relationship in the risk analysis to the top-level requirements and the missed opportunity to achieve coherence with other disciplines, to resolve contradictions and trade-offs⁹.

4.3. System Design And Iteration

Design activities then continue with requirements derived, disaggregated and assigned to be delivered by individual systems. The system level addresses the design and implementation of functional requirements and should seek to reduce the risk to those functions to an acceptable level, through the identification of requirements for security measures. Note that some of these security measures will require the addition of security devices, such as firewalls, but many will place requirements on the way the control systems are designed, built and operated, such as software assurance and supply chain provenance, requiring close engagement with their designers.

Initially, there may errors in design assumptions, conflicting requirements, misplaced trust and other latent vulnerabilities introduced through imperfect specifications ¹⁰. The more complex the combination of systems, the more likely there will be unpredictable emergent properties. Also, the system level design may identify better ways to assign functions to systems. The system and function design activities therefore need to be iterative.

In the IAEA guidance, the Defensive Computer Security Architecture is a central artefact in the design activities for computer security. It is created at a high level of abstraction during functional design and becomes more detailed in the system level ². The DCSA provides designers with a common view of the design, its requirements and constraints. Some interpretations of the DCSA describe a network diagram (see Figure 2 of NSS 17-T ²). Other industries have identified Model Based Systems Engineering (MBSE) as providing this common design view, with a set of models or views that are gradually elaborated through iterative design activities ¹⁰.

Most computer security vulnerabilities will only be identified when candidate technologies and candidate control system designs are scrutinised in detail. Consider, for example, a very high consequence safety function has requirements for security, to provide resilience and reliability in the face of malicious action. At this point in the design activity, candidate controls may be selected from catalogues of security measures. Many computer security standards offer such lists and, in some regulatory environments, there may be a set of minimum requirements or a suite of minimum controls. In the risk-based approach described in IAEA guidance and in the IEC 62443 family of standards, the designer must now assess which security measures will defend against possible adversary action to exploit known vulnerabilities. Crucially, the designer may find those requirements so stringent or so expensive that they cannot easily be met by systems using networked programmable digital technology, especially if its supply chain provenance cannot be adequately proven. This is a practical illustration that the relationship between the high-level functional design and lower-level system design must allow for iteration.

4.4. Implement Components, Systems, Functions

The step to implementation may in many projects be via a contract interface, with a detailed system requirement being implemented as a separate activity by another organisation. In general, it can reduce project risk if managers can disaggregate project activities into separate distinct tasks with well-defined scopes. Most standards reflect this natural desire to operate in this way. However, this can also often mean that the physical security, computer security design and safety design activities take place independently.

Risks can be introduced at this point due to weaknesses in requirements, in component assurance, implementation, or interface coordination, but the right-hand side of the V Diagram shown in Figure 3 relies upon conventional engineering practice to perform design acceptance, which should maintain the residual risk profile against the original design intent. Component assurance includes adequate testing and supply chain provenance to form a trusted foundation to maintain the accepted residual risk profile against the original design intent.

Figure 4 – IAEA NSS 17-T (Rev 1) Figure 7 showing verification and validation in Computer Security Risk Management on the Engineering V Diagram ⁴

As components become systems and they in turn are commissioned to implement functions, the functional acceptance criteria and commissioning should include validation against the original attack scenarios, as a further check against errors that may occur in the entire design disaggregation down the left-hand side and the implementation up the right-hand side. Figure 4 is also from NSS 17-T (Rev 1) ², illustrating how validation checks the various levels of implementation against the original intent. It is also significant that this figure uses a very similar form of Engineering V Diagram, reflecting the 2 levels of risk assessment in NSS 17-T (Rev 1).

4.5. Operations

Returning to Figure 3, once the system has become operational, the defender has to identify new vulnerabilities in computer-based systems before the adversary. This requires understanding the plant-level consequences in order to prioritise remediations, for example applying patches, thinking like an adversary only better and quicker, to manage the risk throughout the plant/project operating lifetime. The defender must know which computer-based systems support which high-level functions, and which system failures lead to adverse physical outcomes, to be able to act faster than the adversary in order to close new attack paths before the adversary can exploit them. The design of computer-based systems, and their associated commercial contracts, must acknowledge this whole-life management of risk by staff, with the necessary deep knowledge of the digital technology. This places additional demands on traditional maintenance and illustrates the need for close working between security and engineering teams.

5. Anticipating Some Questions  

5.1. Can Computer Security Risk Ever Be Managed In A Single Step Process?

Yes, but only if a system is so simple that its role in delivering high level functions can be determined in the same activity as understanding the detail of vulnerabilities that the adversary can exploit. For a trivially simple industrial activity, this may be the case. For something as complex as a nuclear power plant, this is highly unlikely to be practical and the multidisciplinary reduction in inherent risk followed by prudent management of residual risk as described earlier will deliver a more effective solution.

5.2. Can The Process Start With A List Of Computer-Based Assets And Work From There?

Yes, a project may have as its focus an existing computer-based system, e.g. to perform a limited upgrade on its constituent assets.  In this case, the functional significance of the computer-based system will already be very well documented. If the project is making a greater change to the functionality, e.g. changing system boundaries and relationships, there may need to be a reassessment of the functional analysis. The crucial point is that the risk assessment at the level of the computer-based system can only be performed with knowledge of its functional context, so at some point there needs to be an understanding of the high-level functional design ¹¹.

However, if there is too much emphasis on analysis at a system level and a failure to understand the functional level, defences will not be truly proportionate to the exposure to risk and there is an increased chance of a flawed defensive architecture, as Young and Leveson observe ¹⁰. There is also a greater chance of rework. For example, to apply security zones to an existing Instrumentation and Control (I&C) design may require extensive changes to data-flows and trust relationships, probably requiring expensive rework. This also applies to the inclusion of safeguards requirements as part of the design activity, to avoid for example the need to make holes and run wires in unhelpful places to fit unanticipated sensors.

5.3. Why Doesn’t Computer Security For It Follow This Approach?

Computer security developed as a reaction to the use of computer-based systems to process information, referred to as information technology (IT), and computer security focused almost entirely on protecting the confidentiality of information in proportion to its perceived value. The assessment of computer security risk generally started with an existing landscape of sensitive information that needed identifying, assessing and protecting. Operational Technology (OT, may also be known as SCADA or Instrumentation and Control), in contrast with IT, addresses risks to cyber-physical systems, often with risks to assets, life, and to the environment, and consequently has a close relationship with safety.

6. Conclusion

To protect nuclear facilities in the current threat environment requirements for computer security for nuclear security must be integrated with those for safety and physical protection, with those responsible for the design and operation of the plant, under a systems engineering umbrella.

This paper argues that managing the risks arising from computer-based systems should include the reduction of exposure to malicious action in the concept phase and the subsequent reduction of inherent risk in the functional design. A closer interdisciplinary relationship may be needed in some projects in the early stages of design to achieve this and thereby achieve security-by-design, and to avoid security being additive. This paper describes how this can be achieved by including computer security activities at appropriate points in the engineering lifecycle, from the earliest opportunity.

As computer-based systems are used ever more extensively, and the complexity of their designs increases, it is no longer viable to design computer security to defend the individual assets in an additive manner, independent of the overall plant design ¹⁰. Even were that not the case, additive security will more likely lead to expensive rework, and missed opportunities for cost-savings for design controls that will be more effective than the additive computer security measures.

This paper also argues that some existing standards and guidance can be easily mapped onto this lifecycle, but not all standards are yet describing the whole picture. The content of this paper is written to be consistent with current IAEA publications in the NSS series and may help fill in some gaps.

Annex 1 – A more detailed V Model for computer security

References