There are multiple industry frameworks to help create and maintain a secure ICS environment. Some of the industrial cybersecurity standards include IEC 62443 (International Electrotechnical Commission), NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection), and NIST 800-82 (National Institute of Standards and Technology - Guide to Industrial Control Systems (ICS) Security). IEC 62443 is a series of standards and technical reports developed by the International Society of Automation (ISA) and the International Electrotechnical Commission (IEC). This is the recommended framework to follow for the DVD for Manufacturing Edge with PTC and was used as a reference when validating components of this solution. This series of standards provides a road map for improving the overall cyber security posture of an ICS environment. The scope of IEC 62443 is defined as any software, hardware, personnel, and policies that are involved in or have influence over the safety, security, and reliability of the ICS operations. Since ICS components can be physical systems, IEC 62443 stresses the importance of safety. Specifically, a compromise of these physical systems can lead to risk of human life or safety, damage to machinery, financial impact, and harm caused to the environment.
IEC 62443 is broken up into documents and technical reports that are grouped into four families of standards: 1) General, 2) Policies and Procedures, 3) System, and 4) Component. Additionally, IEC 62443 defines roles of those who are involved in the overall operations of an ICS. These roles are comprised of the Asset Owner, Maintenance Service Provider, Integration Service Provider, and the Product Supplier. In addition, listed below are some of the fundamental concepts within IEC 62443:
- Security program—Specific to Part 2-1, this program covers details on policies and procedures, technical capabilities, and maintenance of personnel within ICS.
- Risk Management—Specific to Part 3-2, this program starts with a risk assessment to help understand the current level of risk within the ICS environment. Going through the risk assessment will help identify how to manage the risk through tasks such as identifying assets, Security Levels or by establishing Zones and Conduits.
- Security Levels—Measure of how well an ICS component is protected from a certain level of threat and potential vulnerabilities. The following table gives an overview of each security level with some examples of potential threats and their associated skills and effort.
|Threat actor example
|Threat actor skills
|Threat actor resources
|Threat actor means
|Threat actor motivation
|Casual or coincidental events or violations
|Accidental, or casual
|Simple or none
|Low, usually an individual
|Simple and sometimes non-intentional
|Low or mistakes
|Intentional violation by using simple means
|Low, usually individual with resources
|Intentional violations using sophisticated means of attack
|Terrorist or hacktivist
|Moderate, can be a group
|Sophisticated attack with extended resources
|High, can be highly trained teams
|Sophisticated and coordinated attack
- Zones and conduits—Zones are groups of physical or logical assets based upon criteria such as risk, function, or physical/logical location. Conduits are logical groupings of communications channels that share common security requirements when connecting zones.
- Defense-in-depth—A principle in which multiple layers of security are built into the overall system architecture so that if one level of security is broken, the rest of the system is not compromised. An example of this is if physical security is compromised, all communication over the network is encrypted so it cannot be easily read.
As mentioned previously, IEC 62443 is broken up into a family of standards that applies to different areas of industrial control systems. For example, IEC 62443-3-3 (System security requirements and security levels) describes overall requirements for an ICS based system and mainly targets asset owners, suppliers, or integrators of the system. On the other hand, there are standards IEC 62443-4-1 and IEC 62443-4-2 which are at the component level. Since this is at the component level, both standards provide more detailed and specific applicable controls. IEC 62443-4-1 is a standard that focuses on the security development lifecycle requirements for control system suppliers. On the other hand, IEC 62443-4-2 focuses on components within the ICS and is broken up into different categories such as embedded devices or host devices.
As an example, to align with IEC 62443-3-3, the organization must go through a certain set of steps. The steps can include the organization having identified their OT assets and conducted an organizational risk analysis to help identify criticality of system components. Once this is done, the organization can leverage this information to create zones and conduits. Security target levels (SL-T) can then be assigned to each zone and conduit, identifying how secure each should be. The organization assesses achieved security levels (SL-A) to then obtain a list of systems where the SL-A is less than the SL-T, which translates to the capability level (SL-C). The SL-C describes to what security level a system can be configured to. If an SL-T can not be achieved, the organization should consider compensatory controls such as changing equipment.
Security Levels help narrow down the scope for what security controls to apply. The following table is an example of a set of controls and their associated security levels for a component’s identification and authentication capabilities. This table shows how higher security levels, which will be mapped to components/systems with higher criticality levels, apply more stringent security controls. It is important to note that a higher security level (SL-2 or SL-3 in this case) assumes application of lower security levels. In summary, this section aims to provide an overview of the different components of IEC-62443 and an introduction of how to understand it and start to leverage the family of standards.
|Identification and authentication of all users
|All users are identified (example: username) and then authenticated (example: password) prior to gaining access to the system.
|Users must be uniquely identified and authenticated
|Each user has a unique identifier such as a username that can only be used for a single user.
|Use multifactor authentication
|All users must be authenticated using multifactor authentication such as providing something they know (example: password) and something they have (example: token).