In contrast with IT, the security of an industrial control system (ICS) is also called OT Security, and it started with critical infrastructures such as electricity, gas, and water. With the move towards open systems and changes in threats in line with the trend of IIoT and Industry 4.0, efforts in various fields go into full swing. It is said that Stuxnet in 2010 acted as a global trigger. During the past decade, various countries and industries have actively developed guidelines and frameworks, but they seem to lack coherence. Recently, multiple guidelines have been integrated, and it can be said that two remarkable standards as global standards are IEC62443 and the NIST CSF, SP800 series, from the viewpoint of security in smart factories. In this series, as typical examples of general-purpose guidelines for ICS and OT security, we explain the overviews of IEC62443 and NIST CSF, in order to understand their concepts required for security in smart factories. Many people think that it is too late. However, for people who have heard the names but not experienced them so far, it is very beneficial that such people understand the existing industrial standards and their concepts.
Criteria and standards have been actually developed as general-purpose criteria and standards. Of course, some criteria and standards have compelling force by means of the legal system and regulations, but we expect that this blog posts will help you execute your responsibility properly when you achieve accountability for your own businesses and situation, or when you review your businesses appropriately.
■ Overall picture of IEC62443
IEC62443 is a set of 14 documents that provide specifications for security technologies in general-purpose industrial control systems (IACS: which are called Industrial Automation Control System in this standard). This standard has been developed by the International Society of Automation (ISA) and the International Electrotechnical Commission (IEC), and 8 of the 14 documents have been released so far, and the revision and development are in progress.
IACS, which is the subject of this document, includes not only technical aspects including the system and equipment constituting a system, but also organizational and process aspects. It is also said that organizations and processes around technologies are considered to be part of a system. The 14 documents are separated into sub-documents with sub-numbers as follows: 1-1~4 General, 2-1~5 Policies & Procedure, 3-1~3 System, and 4-1~2 Component. For example, in 4 Component, the requirements for the processes in an organization developing a product and requirements for product itself are specified separately as follows: 4-1 Security product development lifecycle requirements and 4-2 Technical security requirements for IACS.
Fig. 1: Whole Picture of IEC62443 (by Trend Micro, based on IEC documents)
1-1: Concepts and models*
1-2: Main glossary of terms and abbreviation
1-3: System security conformance metrics
1-4: IACS security lifecycle and use-case
<2: Policies & Procedures>
2-1: Security Program requirements for IACS asset owners*
2-2: Security Protection Rating
2-3: Patch Management in the IACS environment*
2-4: Requirements for IACS service provides *
2-5: Implementation guidance for IACS asset owners
3-1: Security technologies for IACS*
3-2: Security risk assessment and system design
3-3: System security requirements and security levels *
4-1: Security product development lifecycle requirements*
4-2: Technical security requirements for IACS *
Documents marked with * have already been released.
These subjects can be classified into three classes, each of which must be performed by the following three parties: a user company that manages/operates a system (called an Asset owner in this standard), a system integrator/service provider that designs/constructs a system, and a product supplier that develops/provides the devices and instruments constituting a system. <1: General> includes overall concepts and reference models. <2: Policies & Procedure> includes organizations and processes for asset owners. <3: System> includes system design procedures and functional requirements for system integrators. <4: Component> is for product suppliers. This classification is a general idea, and in actual cases, there may be cases where the role of a system region in 3 is performed by the user company, and there may be cases where the process in 2 is handled by a system integrator or service provider, from the viewpoint of operation and maintenance.
Asset owners cover policies, organizations, the operation of management systems and patch management, including processes, and specification requirements for system integrators. System integrators cover process and system requirements for designing and constructing systems. Product suppliers cover requirements for development life cycle and products. This standard covers all of them.
Fig. 2: Asset Owner, System Integrator, and Product Suppliers (by Trend Micro, based on IEC documents)
As shown in the overview that has been described so far, the scope of IEC62443 is very wide. Although more than 10 years have passed since the release of the first version of 1-1 in 2009, the whole version has not been released. It can be understood why the whole version has not been released so far. In this series, we focus on points, and mainly deal with Management system (2-1) in Part 1 and then System design and requirements (3-2 and 3-3) in Part 2.
■ Concept: Defense in Depth
IEC62443-1-1 deals with multiple concepts and models that should be referred to. Here, we focus on Defense in Depth. Defense in Depth, which is also a well-known concept in the information security world, does not mean a simple measure using multiple countermeasure technologies together. The point is to separate measures into layers according to security aspects and then to stack them into independent layers. In addition to technology, measures for human resources, organizations, and processes are measures that should be implemented in different layers. The important thing is to implement cyber security in all areas. In a technological aspect, it is also recommended to separate the network environment of IACS into zones and conduits for connecting the zones, and then manage assets by separating them into groups with common security levels. This subject will be explained in Part 2.
■ Management system: Cyber Security Management System (CSMS)
IEC62443-2-1 specifies the framework of management and operation for asset owners. It is a so-called PDCA cycle, which starts with the analysis of higher-level risks. Then, it is necessary to repeat the risk analysis of specific cases, design of policies, restructuring of organizations, training, implementation of management measures, audit, and review. A mechanism for maintaining/managing this security is called CSMS, and a certification system has also been established.
The relationship between IEC62443-2-1 and CSMS certification is the same as the relationship between ISO27001 and ISMS certification in information security. Since CSMS has been developed based on ISMS, there are many common parts between them, and it is said that the framework where a PDCA cycle is continued systematically is the same. On the other hand, the different point is their targets. The targets of ISMS are all of the information assets, but for CSMS, not only information but also IACS are also included in its targets. Next, as a difference of the incident that is presupposed, ISMS considers that the important matter is the loss of the Confidentiality, Integrity, and Availability (CIA) of information, and CSMS considers that the A of CIA is especially important. Additionally, it is said that CSMS presupposes influence on Health, Safety, and Environment (HSE).
For an organization that has already acquired ISMS certification, it is considered that the concept of CSMS is familiar. However, it depends on the individual situation whether certification can be acquired. As for the risk analysis, how many risks are there, excluding the loss of the CIA of information? Is the management for maintaining the A of CIA appropriate? It is necessary to integrate physical risks, cyber-security risks, and HSE risks.
Fig. 3: CSMS (by Trend Micro, based on IEC documents)
■ IEC and ISO
Here, we describe general explanations of IEC and ISO, which are international standards. As its name suggests, the International Electrotechnical Commission (IEC) provides standards for technological fields in electrical and electronics engineering, and the International Organization for Standardization (ISO) is in charge of the other fields. As familiar examples, standards for dry-cell batteries are IEC, and standards for screws are ISO. In manufacturing industry-related fields, there are many standards for safety. For example, in IEC, safety standards for electrical equipment (IEC60204), standards for functional safety (IEC61508), and in ISO, the general principles for the safety design of machinery (ISO12100) and standards for systems and parts (ISO13849) are systematically defined. In addition, in ISO, as an item in the “Others” category, the rules and mechanisms of an organization are also standardized as a management system. In addition to ISO27001 (information security management), well-known subjects such as ISO9001 (quality management system) and ISO14001 (environment management), and more generic themes such as ISO31000 (risk management) are also handled.
In IEC and ISO, there are many industrial technology-related safety standards, and guides for describing these standards have also been released (ISO/IEC Guide 51: 2014 “Safety aspects - Guidelines for their inclusion in standards”). In these standards, risk is defined as the “combination of the probability of occurrence of harm and the severity of that harm,” and safety is defined as “freedom from risk which is not tolerable.” The basic stance on risks may be as follows: on the supposition that risk never becomes 0, determine which risks can be accepted, and until which level a risk is acceptable. Then, consider what should be performed to reduce unacceptable risks down to an acceptable level.
IEC and ISO standards have been continuously revised/developed with changes in technology and society. For the definition of risk, the example described above is a conventional definition. In a relatively new guide (ISO Guide 73: Risk management), risk is defined in an expression that can be interpreted more extensively as follows: “The effect of uncertainty on an object.” In the industrial world, it is also a big issue how Safety and Security should be integrated and managed, and a new standard has also been proposed (IEC TR 63069: Industrial-process measurement, control and automation - Framework for functional safety and security).
It can be said that IEC62443 has been developed/systematized for the security of IACS in cooperation by referencing other standards for various elements such as the management system of an organization, the safety design of systems and devices, and risk management as well as information security. It is expected that user companies, system integrators, and product suppliers will refer to and practice the same concepts from their perspectives, which contributes to the improvement of the overall security level in their industry.
Part 1 has described the overall picture of IEC62443 and the management system. Part 2 will deal with the system design and security level in IEC62443.