Integrating IEC 62443 cyber security with existing industrial process and functional safety management systems

The industrial control systems’ cyber-security standard (International Electrotechnical Commission (IEC) 62443-2-1), identifies some hundred and twenty-six requirements necessary when implementing a cyber security management system (CSMS). These may seem onerous, but by integrating them with existing management systems – common throughout the oil and gas, power, petro-chemical and process industries – this need not be the case. This principle of integration applies especially in the field of process and functional safety risk management.

Go to the profile of Peter Hazell
Sep 07, 2017
1
1
Upvote 1 Comment

Author(s): Peter M.C. Hazell

Abstract 

This paper addresses how, by exploiting the synergies between IEC 62443 and existing process plant management systems, some fifty of the key requirements of the standard can be achieved at minimal cost. The paper also explores how, the three generic information security risks (CIA – confidentiality, integrity and availability) can be included in process/functional risk assessments, alongside the four generic process risks PEAR (People/safety, Environment, Asset and Reputation). A combined PEARS (‘S’ denoting security) approach puts safety in the forefront of security decisions while accurately identifying all relevant control system components, and addressing the impact of security on SIL (Safety Integrity Level) determination.

Introduction

On the basis of the premise that both cyber security (as embodied in both International Organisation for Standardisation (ISO) 27001 and IEC 62443 – information and control system security standards) and process safety are inherently risk management processes, many synergies exist between the two. This paper explains how integrating industrial control system security management with existing process safety management systems results in more robust safety and security outcomes, at a much lower cost, compared with running two independent management processes.

This approach has been successfully applied to a number of industrial facilities ranging from top tier Control of Major Accident Hazards sites to operations posing less of a risk to employees and members of the public (regrettably, for reasons of confidentiality and security, this paper cannot be more specific – e.g. identifying specific operations).

This paper is based on an examination of IEC 62443 (industrial communications networks – network and system security) which is itself derived from the de-facto information security standard ISO 27001. Whereas ISO 27001 undoubtedly has a role in the protection of engineering information that could be extracted from control systems: either to assist in an attack against the physical process (e.g. control software, operator display graphics) or for its commercial value (e.g. batch recipes used by pharmaceutical companies); this is a topic in its own right and outside the scope of this paper. Indeed, for reasons of space and complexity much of IEC 62443 is also outside of the scope of this paper, which focuses on the risk assessment and management phase of the standard, as it relates to process plant and associated facilities.

Underlying concepts and definitions

Overview of IEC 62443

By necessity, the description of IEC 62443 above is overly simplified, and ignores the fact that IEC 62443 is divided into four sections (general; policies and procedures; system and component) which in turn comprise 13 parts – roughly speaking only 50% of which are relevant to this paper.

The structure of IEC 62443 in many respects mirrors the structure of the functional safety standards IEC 61511 and IEC 61508, in so far as the standard deals with both end user management and supplier manufacturing compliance. This paper is concerned with the former, and when it refers to IEC 62443, by implication it is drawing on those parts of the standard relevant to the implementation of a cyber-security management system (CSMS), and not the system or component sections.

Asset risks under consideration

The fundamental difference between information security (as embodied in ISO 27001) and control system security is the nature of the asset and the generic risks associated with these. By definition, information security is concerned with the protection of information (computerised or paper based), the generic risks to which are confidentiality, integrity and availability (CIA). On the other hand, process and functional safety, and by extension control system security, exist to protect process plant (designated herein as processm – to distinguish it from any other use of the word ‘process’) by addressing its associated generic risks – people (safety), environment, asset and reputation (PEAR).

So, in contrast to the computer systems processing data, industrial control systems are merely components in a much larger mechanical and electrical system or processm. This is an important distinction, since ultimately it is the processm that is at risk – the control system, and associated generic CIA risks, being a vehicle to interfere with production or safe operation of the processm either by incapacitating the control system itself or by damaging mechanical and/or electrical plant.

As was the case of the Stuxnet attack in 2010 [1], this use of the control system as a mechanism to attack the processm , gives rise to the concept of an extended denial of service (DOS) attack, in which the aim is to incapacitate the processm – the consequences of which are more costly and longer term, than could be achieved by a traditional IT style DOS attack.

A fundamental problem of implementing IEC 62443-2-1 risk management therefore lies in bridging the knowledge gap between the traditional computer/information security profession (responsible for managing CIA risks) and the various engineering disciplines responsible for controlling PEAR risks. The combined people, environment, asset, reputation and security (PEARS) approach to risk management developed in this paper seeks, among other things, to address this disconnect between plant engineers with limited security knowledge and information security professions with a similar ignorance of the safe operation of processm plant.

Definition – industrial automation and control system

IEC 62443 includes two separate definitions, one for ‘control equipment’ [2] and another for ‘industrial automation and control systems’ (IACSs) [3]. The following definition both unifies these two concepts, and structures them in a way that supports the discussion in the main body of this paper.

An industrial control system comprises all programmable systems and associated equipment used:

  1. in the collection of data from the field or the operation of the final element in the field;
  2. in the control or manipulation of the final element in the field;
  3. in the relaying or displaying plant status information to the plant operators or other staff;
  4. in the communication of data between any of the above elements; or
  5. as a layer of protection identified in a functional safety PEAR risk assessment such as a hazard and operability (HAZOP), layers of protection (LOPA) or similar study.

The following provides a more detailed explanation of the above, with Fig 1 indicating how each clause (indicated by a red box) relates to a typical control system architecture.

Fig 1: Relation between the five definition clauses and a typical control system

Clause 1: Extends the definition of an IACS to cover instrumentation and would include Highway Addressable Remote Transducer (HART), wireless instruments and smart instrumentation (including field bus).

Clause 2: Extends the definition, so that it is not limited to programmable logic controllers, Distributed Control Systems (DCSs) and Supervisory Control and Data Acquisition (SCADA) systems. It includes all programmable devices used to operate final control elements such as: full field bus implementations (were the ‘process intelligence’ is distributed through smart instrumentation); embedded control systems; smart switchgear protection, control devices etc.

Clause 3: This includes all human–machine interfaces in the definition be they centrally located in a control room or embedded within the processm plant.

Clause 4: Accounts for the numerous different generic and proprietary communication protocols (e.g. Modbus, OLE for Process Control (OPC), HART, Bristol Standard Asynchronous Protocol (BSAP) etc.) used in the field of industrial control.

Clause 5: This is an important clause as it includes equipment that may not at first glance be relevant or appear on any control system topology diagrams. For example, plant condition monitoring equipment (e.g. vibration monitoring) that is used not only for remote monitoring, but also for plant protection via a hard wired input to a DCS.

Definition – security

IEC 62443 [4] gives a fairly technical definition of security, but for the purposes of this document security is defined as: securing against any malicious act initiated by a person to damage or otherwise interfere with the operation of an asset associated with the control, protection or monitoring of a processm [5].

Significantly, here are the concepts of ‘malicious’ and ‘person’ (in common with the computer misuse act [6] – ‘person’ in this context includes indirect machine attacks initiated by a person – e.g. botnets). Similarly, ‘malicious’ is important as it distinguishes security incidents from equipment failures and operator errors, in so doing drawing a line between the responsibilities accruing to the security and plant engineering professions – a boundary that is sometimes blurred in IEC 62443, for example, in its discussion of redundant power supplies in section A.3.3.3.2.7 [7] which implies that it is this security rather than plant engineering responsibility.

Overview of a combined PEARS approach to security

As already discussed, there are many areas where the implementation of IEC 62443 can be absorbed into existing plant management systems, and to cover these would be impossible in a document of this length. This is also true of those sections of IEC 62443 that focus on the implementation and management of a plant-wide CSMS; this paper therefore only covers the integration of process/functional safety and security risk assessments. That said, it is in this area where many of the most important requirements of IEC 62443 can be satisfied (key requirements such as 4.3.2.6.3 ‘Maintain consistency between risk management systems cyber-security policies and procedures that deal with IACS risks should be consistent with or extensions of policies created by other risk management systems’ [8]).

Experience shows that well run facilities have in place risk management processes necessary to quantify and then manage their exposure to PEAR risks. Central to these risk management processes is some form of risk assessment – typical of which is the hazard and operability study, or HAZOP, details of which are to be found in IEC 61411-3 [9]. Guided by the information contained on process and instrumentation diagrams (P&IDs), these risk assessments are systematically documented in a structured, traceable and auditable risk register (e.g. a database designed for the purpose), a methodology that is almost identical to those described to assess cyber risk in both British Standards (BS) ISO/IEC 2700 [10] and IEC 62443-2-1 [11], but with two important differences:

  • Security uses a 3 × 3 × 3 (27 combination) matrix of likelihood, severity and vulnerability, whereas process/functional safety uses a less complex 3 × 3 (nine combination) matrix of likelihood and severity only (Fig 2).
  • The starting point for an IEC 62443-2-1 security assessment is the network topology diagrams for the control system while process/functional safety base their assessments on process m schematics – typically P&IDs.

Fig 2: Relative complexity of a 3 × 3 and 3 × 3 × 3 risk assessment process

This first point is particularly important, as often vulnerability alone is quite incorrectly used as a measure of risk. For example, there are numerous articles written by penetration testers warning against the use of long-established industrial control protocols [12] such as Modbus and HART. Having been developed in the days before concerns over computer security, these protocols are undeniably vulnerable to CIA attacks, but as they are more often than not used to interface equipment in locked cabinets, in secure rooms, within the secured perimeter of the facility, they are rarely of high risk.

Indeed, there are circumstances whereby ‘one size fits all’, top down edicts, based on vulnerability alone can result in either:

  • a ‘realised’ cost to the organisation – where the real opportunity costs associated with inappropriate security countermeasures result in a loss of functionality that outweighs any theoretical costs associated with a cyber-attack or
  • a negative impact on PEAR – IEC 62443-2-1 quotes the example of how password policies suitable in office IT environments can be inappropriate in an industrial control environment – where they may impede an operator's ability to respond quickly to plant incident [13]).

In common with existing process/functional safety practise (e.g. as low as reasonably practical), both IEC 62443 and ISO 27001 are clear that a balance should be reached between the cost of mitigation (including opportunity costs) and the potential cost of no action. In addition, both standards agree that this balance should be based on a level of acceptable risk defined by senior management (often referred to as ‘corporate appetite for risk’).

The second point, regarding network topology diagrams and P&IDs, is also important, for two reasons. Foremost being that P&IDs (as exemplified in Fig 3 a) are the base document on which all process and functional safety assessments are made – therefore, are invaluable in assessing real risk (real risk being the risk to the processm). In addition network topology diagrams (such as the example in Fig 3 b) do not include all control system components (such as wireless instrumentation) that fall into either this documents definition of an IACS or that in IEC 62443 – as explained later, structured analysis of P&IDs is a better vehicle for identifying the entire scope of the IACS.

Fig 3: Typical P&ID and network topology diagrams

a) Typical P&ID used as the starting point for a process approach to assessing risk

b) Typical network diagram used in a non-process approach to assessing risk

Consequently, there are several benefits to be derived by building a cyber-security case on the foundations laid by a PEAR risk assessment, opposed to the IEC 62443 approach of addressing security risk first, and then considering its impact on PEAR.

For example:

  • it encourages an early dialogue between process and/or functional safety engineers and security professionals;
  • it means any security decisions are based on an understanding of real risk opposed to just cyber risk;
  • it is more likely to identify all IACS, and other control system components (not just those on the network topology diagram);
  • it simplifies the risk assessment process by splitting the process into two stages, each comprising of 3 × 3 matrices, opposed to a single 3 × 3 × 3 matrix;
  • similarly, it decouples the assessment of PEAR from security, allowing the security function to assess the impact of vulnerability independently of other risk factors;
  • it has the potential to significantly reduce CSMS implementation costs;
  • it has the potential to significantly reduce CSMS administration costs;
  • it clearly defines which responsibilities lie with the engineering and security professions; and
  • it provides a mechanism for evaluating the impact of security on safety integrity level (SIL) assessments – used to define the criticality, and associated integrity, of safety critical plant tripping equipment.

This first point of establishing an early dialogue is essential as it enables a two-way exchange of knowledge between the engineering and security fraternities – with the security professionals learning the nature of the real risk, and the engineers gaining some insights into the world of security in general, and more specifically computer security. This information exchange then feeds into the second point, in that the security professionals can only adequately design countermeasures if they have an understanding of the asset that they are protecting.

Similarly, a collaborative approach is more likely to identify the complete scope of the control system, as plant engineers should know of all the programmable systems used to control and monitor the process m – irrespective of whether or not they appear on the network topology diagrams. How exactly this collaboration should be organised depends on a number of factors, and is dealt with in detail in the next section, suffice to say for the time being that it is based on some form of walkthrough of the mechanical plant based on either P&IDs, HAZOP nodes or similar.

The simplification of the risk assessment process is best illustrated by Fig 4, which shows how a single-stage analysis of a 3 × 3 × 3 matrix is replaced by a two-stage assessment of two simpler 3 × 3 matrices. Since security is only introduced in the second stage, it allows the impact of security to be evaluated independently of first step.

Fig 4: Simplified two-stage risk assessment process

The two points regarding implementation and administrative costs are easily justified: it is easier, hence cheaper, to modify and operate existing process and functional safety management systems to incorporate cyber security, than it would be to implement a new CSMS system from scratch.

As is explained in the next section, integrating security into existing process/functional safety management processes, by default, puts the responsibility for managing security on the shoulders of the plant safety engineers, which itself has many advantages, most significant of which is it gives decisions impacting on PEAR (safety and environment) priority over security, and provides a mechanism whereby the impact of security countermeasures on PEARS can be assessed prior to their implementation.

This approach is equally relevant to assessing the impact of security on safety critical (SIL) loops. IEC 62443-3-3 [14] defines a process of allocating security levels (SLs) that mirrors the functional safety profession's methodology for assessing SILs – aligning SLs with calculated SIL probability of failure on demand figures, ensures that key safety equipment is assured a level of security based on a measure of its criticality.

In addition, a management process that unambiguously assigns roles and responsibilities limits the potential for ‘turf issues’ such as those described in IEC 62443 [13] and the negative impact that these can have on the safety, environmental and security outcomes [16].

Implementing a combined PEARS approach to security

High-level risk assessments are the common starting point for both process/functional safety management systems and CSMSs – in functional safety, a HAZOP may result in further LOPA studies; similarly, IEC 62443-2-1 identifies the need for both a high and detailed risk assessment [17]. Although, ‘HAZOPs’ have been used as an example throughout this document – it is just that – ‘an example’. IEC 61511 is not prescriptive as to the form that high-level functional safety risk assessment should take [18], neither are process safety risk assessments necessarily driven by a functional safety requirement. It is, however, by combining the high-level security risk assessment with its functional/process equivalent that the benefits identified in the last section are derived.

The first step in the process is, therefore, to define where the processm facility is in relation to completing some form of process/functional safety risk assessment, for which there are three outcomes:

  • the facility is about to embark on a plant-wide risk assessment;
  • the facility has completed a plant-wide risk assessment in the past; or
  • the facility has no plans to risk assess the plant.

Of these three scenarios the first is the easiest to accommodate, is also the entry point into Fig 5 and 6 flow diagram. As already discussed, there is little difference between a typical process/functional safety risk assessment and those described in both IEC 62443-2-1 and ISO 27001, as they all involve: a group of relevant and qualified professionals, logically analysing schematics, against a set of guided questions, and recording the outcome in a structured risk register.

Fig 5: Understanding a facilities existing PEAR risk management status

Fig 6: Flow diagram for the integrated risk management system

By including information security professionals in the processm risk assessments they are given the opportunity to understand real risk, while at the same time identifying the precise scope of control system equipment associated with each processm sub-system, by virtue of the fact that the relevant engineering disciplines, with the requisite level of knowledge required are represented in these forums.

On completion of a high-level processm risk assessment, it is usual for the actions to be cleared by the various relevant engineering discipline, overseen and coordinated by the process/functional safety profession. This approach equally applies to the inclusion of security professionals, who based on the combined PEARS risk assessment, are then able to independently undertake their next step cyber risk assessment.

IEC 62443 recommends that the cyber risk assessment process should be a two-stage process starting with a high-level risk assessment (requirement 4.2.3.3), followed by a detailed cyber risk assessment (requirement 4.2.3.9) [19]. If the combined PEARS risk assessment is suitably structured, there is no reason why it should not satisfy requirement 4.2.3.3 [20], allowing the cyber risk assessment to move onto the detailed risk assessment phase, during which the impact of factors such as CIA and vulnerability should be considered.

Having outlined how the combined PEARS risk assessment process fits together for the simple case where the PEAR and security risk assessments run concurrently, the same points need addressing for the remaining two scenarios.

The situation where the facility has been fully PEAR risk assessed ahead of any cyber risk assessment follows much the same principles as already discussed, except that the original PEAR risk register is used as a tool to guide discussion around security based on an existing understanding of real risk. The risk assessment team for this scenario would not require the same level of engineering input as was the case for scenario one, and would be much smaller – typically comprising the following disciplines: process/functional safety; security; and Control and Instrumentation (C&I) (in order to identify all relevant control system components).

The third scenario obviously does not lend itself to an integrated PEARS approach, in which case the fall-back position is to do a cyber risk assessment based on network topology diagrams. There are no statutory sanctions for not having CSMS in place, but safety and environmental bodies (e.g. the UK's Health and Safety Executive and Environment Agency) have the power to issue prohibition notices or worst still prosecute. Processm facilities may, therefore, wish to consider whether they should prioritise the management of PEAR ahead of security – in which case, they are back to scenario one (combined PEARS risk assessments).

Irrespective of how an organisation arrives at a joint PEARS approach to risk management, the overall management process is the same, and for the sake of clarity is laid out in the flow diagram (Fig 6). As discussed the methodology starts with a joint PEARS risk assessment, the outcome of which is recorded in a joint risk register, after which the process splits into two autonomous branches – process/functional safety (this is indicative only on the diagram), and the cyber security. The security team first have to decide whether the joint PEARS risk assessment satisfies the standards requirement (4.2.3.3) for a high-level risk assessment. If it does, then the process can proceed directly to the detailed risk assessment phase; otherwise, a high-level risk assessment must be completed – either way the cyber risk assessments will be based on a thorough understanding of real risk and the scope of the industrial control system. These cyber risk assessments are necessary to evaluate the impact of CIA and system vulnerability against an already graded evaluation of PEAR risk.

Once the cyber risk has been assessed, the security team are then able to design appropriate counter measures, during which it is hoped there would be a dialogue between them and the processm plant engineers, based on relationships built up during the joint PEARS risk assessment. Any such dialogue has a number of advantages: principally, that it should reduce the time taken to evaluate the impact of security on PEAR; and reducing the amount redesign work (other advantages include things such as the option to use engineering solutions to solve security problems – e.g. using non-programmable or mechanical layers of protection, instead of or as a back-up for, a vulnerable control or protection system).

IEC 62443 makes several references for the need to evaluate the impact of any security systems on PEAR [21], so having designed security counter measures, it is essential that they are evaluated by the plant engineers prior to implementation, with any conflicts designed out before they are applied and the actions closed out on the master PEARS risk register.

Conclusion

This paper examined in some detail a methodology for integrating a number of the more demanding requirements of IEC6443-2-1 with existing site-based process/functional safety management system – both simplifying their implementation and administration while delivering a more robust CSMS.

By necessity, this paper looked at this single integration methodology while ignoring the wider lesson to be learned, which is: where appropriate, there are benefits to be gained by integrating IACS requirements using existing process plant management processes. Hence, there are many more benefits to be gained by integrating other common site management processes with cyber security: such as the rather simple example of disposal mentioned in the abstract.

Nonetheless, by concentrating on a combined PEARS approach to processm risk management, this paper was able to encompass the majority of the principal requirements of IEC 62443-2-1 in a single document. This paper was also able to demonstrate the numerous advantages of this approach such as: decisions based on the assessment of real risk; the integration of security and plant operations; the avoidance of inappropriate security measures imposed on site operations; improved understanding between the engineering and security professions; a methodology for reconciling SIL and security; and reduced CSMS implementation and operating costs.

References

  1. Piggin R.: ‘Industrial control systems and SCADA cyber-security’, Eng. Technol. Mag., 2014, 9, (8), 1 p.
  2. IEC/TS 62443-1-1: ‘Industrial communications networks – network and system security – part 1-1: terminology, concepts and models’, 2009, Sec 3.2.
  3. IEC/TS 62443-1-1: ‘Industrial communications networks – network and system security – part 1-1: terminology, concepts and models’, 2009, Sec 3.2.
  4. IEC/TS 62443-1-1: ‘Industrial communications networks – network and system security – part 1-1: terminology, concepts and models’, 2009, Sec 3.2.
  5. ‘DTM component vulnerabilities expose critical control systems to cyberattacks’. Available at http://www.securityweek.com/dtm-component-vulnerabilities-expose-critical-control-systems-cyberattacks, accessed January 2017.
  6. Computer misuse act 1990. s.3(2)(d). Available at http://www.legislation.gov.uk/ukpga/1990/18, accessed January 2017.
  7. BS IEC 62443-2-1: ‘Industrial communications networks – network and system security – part 2-1: establishing an industrial automation and control system security program’, 2011, Sec A3.3.3.2.
  8. BS IEC 62443-2-1: ‘Industrial communications networks – network and system security – part 2-1: establishing an industrial automation and control system security program’, 2011, Sec 4.3.2.2.
  9. IEC 61511-3: ‘Functional safety – safety instrumented systems for the process industry sector – part 3: guidance for the determination of the required safety integrity levels’, 2012.
  10. BS ISO/IEC 27001: ‘Information technology — security techniques — information security management systems – requirements’, 2005, Sec 4.3.
  11. BS IEC 62443-2-1: ‘Industrial communications networks – network and system security – part 2-1: establishing an industrial automation and control system security program’, 2011, Sec 4.2.3.
  12. Hazell P. M. C.: ‘Integrating the requirements of IEC 62443 into existing process plant management systems as applied to industrial control systems deployed in the U.K. process, power, and oil and gas industries’. MSc thesis, University of London, 2015.
  13. BS IEC 62443-2-1: ‘Industrial communications networks – network and system security – part 2-1: establishing an industrial automation and control system security program’, 2011, Sec A3.3.6.
  14. BS IEC 62443-2-1: ‘Industrial communications networks – network and system security – part 3-3: system security requirements and security levels’, 2013.
  15. ACCA Textbook, 2000. Foundation Stage Module B – Organizational Framework. Middlesex: Foulks Lynch Ltd.
  16. BS IEC 62443-2-1: ‘Industrial communications networks – network and system security – part 2-1: establishing an industrial automation and control system security program’, 2011, Sec 4.2.3.
  17. IEC 61511-3: ‘Functional safety – safety instrumented systems for the process industry sector – part 3: guidance for the determination of the required safety integrity levels’, 2012, Sec B.3.2.
  18. BS IEC 62443-2-1: ‘Industrial communications networks – network and system security – part 2-1: establishing an industrial automation and control system security program’, 2011, Sec 4.2.3.
  19. BS IEC 62443-2-1: ‘Industrial communications networks – network and system security – part 2-1: establishing an industrial automation and control system security program’, 2011, Sec 4.2.3.
  20. BS IEC 62443-2-1: ‘Industrial communications networks – network and system security – part 2-1: establishing an industrial automation and control system security program’, 2011, Sec 4.3.4.
  21. BS IEC 62443-2-1: ‘Industrial communications networks – network and system security – part 2-1: establishing an industrial automation and control system security program’, 2011, Sec A3.2.2.

 

Go to the profile of Peter Hazell

Peter Hazell

Consultant director, Vantage Technology Ltd

1 Comments

Go to the profile of Chris Shire
Chris Shire about 1 month ago

Hello Mr Hazell a well constructed piece on cyber security and risk management. You might find the IoT Security Foundation's work on security compliance checking and vulnerability disclosure may complement, at least in part,  these ideas.