GB/T 42456-2023Security for industrial automation and control systems - Technical security requirements for IACS components (English PDF)

0 Introduction

0.1 The introduction places the document in the IEC 62443 series and lists the parts of that series already taken over in China: GB/T 33007-2016, GB/T 35673-2017, GB/T 40211-2021, GB/T 40218-2021, GB/T 40682-2021, GB/T 42445-2023 and GB/T 42457-2023, which together with this document form the national series on industrial automation and control system security.

0.1 Industrial automation and control system organisations use ever more commercial off-the-shelf network equipment, convenient, efficient and highly automated, and for sound business reasons control systems are ever more interconnected with networks outside the system. Those devices, the open network technology and the added connectivity widen the exposure of control system hardware and software to network attack, and the resulting weakness can carry through into health, safety and environmental, financial and reputational consequences for the deployed control system.

0.1 An organisation that reaches for a commercial information technology network security solution to solve a control system security problem may not have followed the consequences of that choice through. At the same time many commercial information technology applications and security solutions can be used in this setting, so they have to be applied in a way that keeps unintended consequences out; for that reason the method of defining system requirements weighs functional requirements together with risk assessment, and as a rule takes account of operational matters as well.

0.1 Security countermeasures for these systems include emergency procedures and should avoid creating the possibility of losing needed services and functions, a possibility that the usual information technology countermeasures do carry. The security objectives here centre on the availability of the control system, on plant protection and on plant operation, that is on system response that keeps to strict timing even in degraded mode, whereas information technology objectives do not usually weigh those factors equally and may be more concerned with protecting information than physical assets. Whatever the degree of plant integration, the differing objectives have to be stated plainly as security objectives.

0.1 The document gives network security requirements for the components that make up such a system, embedded devices, network components, host components and software applications in particular. Annex A describes the classification of the common devices. The requirements refer to the system security requirements of IEC 62443-3-3. The aim is to specify security functions so that a component can be integrated into a system environment at a given security level, and the tables of Annex B gather the security levels of the requirements and requirement enhancements the document defines.

0.2 The target readers within the community are asset owners, system integrators, product suppliers and the compliance bodies concerned, the last including government bodies and regulators with statutory authority, which may audit to verify that the law is being kept.

0.2 System integrators use the document to help them procure the control system components that make up a solution, stating a suitable security capability level for each component they buy. The standards they chiefly work from are IEC 62443-2-1, IEC 62443-3-2 and IEC 62443-3-3, which carry the organisational and operational requirements of the security management system and guide them through defining security zones and the target security capability level of each zone; once that target is fixed, components that supply the needed functions can reach it.

0.2 Product suppliers use the document to understand what is required of a control system component carrying a particular capability security level. A component may supply no security capability of its own and still benefit from the capability of a larger entity it is designed into: an embedded device that cannot keep a user directory may sit in a system that offers identification and authorization services, and so still meet the requirement for individual user identification, authorization and management. The document guides the supplier on which requirements may be allocated elsewhere and which have to be built into the component, and, under Practice 8 of IEC 62443-4-1, the supplier furnishes documents on integrating the component into a system correctly for a given target level.

0.2 The component requirements of this document refer to the system requirements of IEC 62443-3-3, which are derived from the overall foundational requirements defined in IEC 62443-1-1. A component requirement may carry a set of requirement enhancements, and the combination of the two settles the target security level the component can reach. Requirements are given for four types of component, software applications, embedded devices, host devices and network devices, so the component requirements are designated as software application requirements, embedded device requirements, host device requirements and network device requirements. Most of the requirements are the same for all four types and are then written once as component requirements; where a requirement is particular to one type, the general requirement says so and the requirement itself sits in the type-specific clauses.

1 Scope

The document gives detailed technical control system component requirements tied to the seven foundational requirements described in IEC TS 62443-1-1, among them the requirements for defining the capability security level of a control system and the capability security level of its components.

Under IEC TS 62443-1-1 there are seven foundational requirements in all: identification and authentication control (IAC); use control (UC); system integrity (SI); data confidentiality (DC); restricted data flow (RDF); timely response to events (TRE); and resource availability (RA).

Those seven requirements are the basis on which the security capability levels of a control system are defined. The main aim of the document is to define the security capability level of control system components; the target security level and the way a level is achieved fall outside the scope it lays down.

Note 1 states that fully reaching the security level target of a control system also calls on a set of non-technical, procedure-related component capabilities laid down in IEC 62443-2-1, and that unless stated otherwise the word security in the document means information security. Note 2 states that the trademarks and trade names mentioned are given for the convenience of users and do not amount to IEC endorsement of the products named.

2 Normative references

The clause opens with the usual formula: the content of the documents listed makes up provisions that cannot be dispensed with, dated references applying in the edition cited and undated references in their latest edition, all amendments included.

The documents listed are GB/T 35673-2017, the national standard on network and system security, system security requirements and security levels, an identical adoption of IEC 62443-3-3:2013; IEC TS 62443-1-1 on terminology, concepts and models, with a note pointing to GB/T 40211-2021 as its identical Chinese adoption; IEC 62443-3-3 on system security requirements and security levels; and IEC 62443-4-1 on secure product development lifecycle requirements, with a note pointing to GB/T 42457-2023 as its identical Chinese adoption.

3 Terms, definitions, abbreviated terms and conventions

3.1 The terms and definitions given in IEC TS 62443-1-1, IEC 62443-3-3 and IEC 62443-4-1 apply, together with those that follow. A note states that many of the definitions below rest on material from ISO, IEC and the United States National Institute of Standards and Technology, at times with small changes that make them fit control system security requirements better.

3.1.1 An asset is a physical or logical object of potential or actual value to the industrial automation and control system. Two notes add that in this particular setting the asset may be protected as part of the security management system, and that assets are not confined to the system itself but take in the physical assets under its control.

3.1.2 An asset owner is the individual or company answerable for one or more industrial automation and control systems. Notes distinguish the term from the general term end user, bring the components inside the system within it, and state that in this document the asset owner takes in the operator of the system.

3.1.3 An attack is an act arising from an intelligent threat, an attempt made without authorization to destroy the confidentiality, integrity or availability of the system. An example explains that intelligent behaviour here means a deliberate attempt, in method or in technique above all, to evade the security services and break the security policy of the system. A note sets out the common types: an active attack tries to change system resources or affect their operation; a passive attack tries to learn or make use of information in the system without affecting its resources; an inside attack is launched by an entity within the security boundary, as when an authorized entity reaches system resources but uses them in a way the authorizing party did not permit; an outside attack is launched from the periphery by unauthorized or illegitimate users outside the boundary, insiders attacking from outside included, and potential outside attackers range from amateur mischief-makers through organised criminals to international terrorists and hostile governments.

3.1.4 Authentication is the verification of the identity an entity claims; a note adds that authentication is as a rule the precondition of access to control system resources. 3.1.5 An authenticator is the means by which the identity of an entity is confirmed, a password or a token for example. 3.1.6 Authenticity is the characteristic whereby an entity matches its original declaration through authentication and its integrity can be verified; a note places the term in the context of the confidentiality of an entity identity, or of the validity of a transmission, a message or a message originator.

3.1.7 Availability is the characteristic of ensuring timely and reliable access to, and use of, control system information and functions. 3.1.8 A communication channel is a particular logical or physical communication link between assets, used to establish a connection. 3.1.13 A connection is the association between the two or more endpoints that establish a session.

3.1.9 A compensating countermeasure is a countermeasure that replaces or supplements inherent security capability so that one or more security requirements are met. Three examples are given: at component level, locking the cabinet around a controller where network access control is not adequate; at control system and zone level, physical access control over the control room, with guards, gates and firearms, restricting entry to a known group and so making up for the inability of the system to identify personnel uniquely; and at component level again, a product supplier whose programmable logic controller cannot meet the access control capability the asset owner wants, who places a firewall in front of the controller and sells the two as a system.

3.1.10 A component is an entity within the industrial automation and control system used to exhibit one or more of the characteristics of a host device, a network device, a software application or an embedded device. 3.1.14 A control system is the hardware and software components within such a system. 3.1.11 A conduit is a logical grouping of the communication channels that connect two or more zones and share security requirements; a note allows a conduit to pass through a zone so long as the security of the channels inside it is not affected by that zone.

3.1.12 Confidentiality is the assurance that information will not be disclosed to individuals, processes or devices that lack authorization; a note adds that in this setting it means protecting the data and information of the industrial automation and control system against access without authorization.

3.1.15 A countermeasure is an action, device, procedure or technique that reduces a threat, lowers a weakness or mitigates the consequences of an attack that can be caused, or detected and reported, by keeping the harm to a minimum, so that correct behaviour can be taken. A note records that the concept is sometimes described with the word control, and that the document chose the word countermeasure so as to avoid confusion with the word control in process control and control system. 3.1.16 Degraded mode is the operating mode foreseen in the design of the control system for the case where a fault appears.