{
"sRequirements": [
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.3)",
"requirementName": "CR 1.1 \u2013 Human user identification and authentication",
"requirementDescription": "Components must enable identification and authentication of all human users on interfaces accessible to them, following IEC 62443-3-3 SR 1.1. This is essential to enforce segregation of duties and least privilege, as per security policies. Authentication methods may include passwords, tokens, biometrics, physical keys, or combinations, and may consider user location. This requirement applies to both local and remote access and complements system-level identification and authentication. Interfaces include local inputs (e.g., touchscreens) and network protocols like HTTP, HTTPS, FTP, and SFTP. User identification can be role-based or group-based. Emergency actions should not be impeded. To adhere to IAC policies, the component should first verify user identity, and then enforce permissions.",
"requirementSatisfaction": "Requirement enhancement:\n1. Unique identification and authentication: Components shall provide the capability to uniquely identify and authenticate all human users.\n2. Multifactor authentication for all interfaces: Components shall provide the capability to employ multifactor authentication for all human user access to the component.\nSecurity Level: The requirements for the four security levels that relate to CR 1.1 are:\n\u2022 SL-C(IAC,component) 1: CR 1.1\n\u2022 SL-C(IAC,component) 2: CR 1.1 (1)\n\u2022 SL-C(IAC,component) 3: CR 1.1 (1) (2)\n\u2022 SL-C(IAC,component) 4: CR 1.1 (1) (2)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.4)",
"requirementName": "CR 1.2 \u2013 Software process and device identification and authentication",
"requirementDescription": "Components must identify and authenticate themselves according to IEC 62443-3-3 SR1.2. When human users are involved, their identification and authentication (IEC 62443-3-3 SR1.1) may be part of the component\u2019s process for interacting with other components. This process establishes known identities for software processes or devices (entities) before permitting data exchange to prevent unauthorized access to control system data, which could cause malfunctions. All entities, local or remote, use methods like passwords, tokens, or location-based verification. Some scenarios may find it challenging to use multiple identities, requiring alternative measures. Portable and mobile devices need special attention due to network issues, malware, or information exposure. Group-based, role-based, or entity-based identification and authentication can apply for entities that function as a group, without hindering local emergencies or control system functions. To align with IEC 62443-2-1 control policies, the control system verifies an entity\u2019s identity and enforces assigned permissions.",
"requirementSatisfaction": "Requirement enhancement: (1) Unique identification and authentication Components shall provide the capability to uniquely identify and authenticate itself to any other component. Security Level: The requirements for the four security levels that relate to CR 1.2 are:\n\u2022 SL-C(IAC,component) 1: Not selected\n\u2022 SL-C(IAC,component) 2: CR 1.2\n\u2022 SL-C(IAC,component) 3: CR 1.2 (1)\n\u2022 SL-C(IAC,component) 4: CR 1.2 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.5)",
"requirementName": "CR 1.3 \u2013 Account management",
"requirementDescription": "Components must support account management for all accounts, either directly or through integration with a system that manages accounts, as per IEC 62443-3-3 SR 1.3. Integration with a higher-level account management system is a viable approach. Alternatively, the component can provide this capability independently. A common method is for the component to delegate authentication validation to a directory server like Lightweight Directory Access Protocol (LDAP) or Active Directory, which fulfills the required account management functions outlined in IEC 62443-3-3 SR 1.3. If a component integrates with a higher-level system for account management, its resilience in the event of the higher-level system\u2019s unavailability should be considered.",
"requirementSatisfaction": "Requirement enhancement: None. The requirements for the four security levels that relate to CR 1.3 are:\n\u2022 SL-C(IAC,component) 1: CR 1.3\n\u2022 SL-C(IAC,component) 2: CR 1.3\n\u2022 SL-C(IAC,component) 3: CR 1.3\n\u2022 SL-C(IAC,component) 4: CR 1.3"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.6)",
"requirementName": "CR 1.4 \u2013 Identifier management",
"requirementDescription": "Components must integrate with an identifier management system or handle identifier management directly, per IEC 62443-3-3 SR 1.4. Accounts established under CR 1.3 - Account Management (5.5) require one or more unique identifiers to distinguish each account. These identifiers should be unambiguous and clearly associated with their respective accounts. Common identifiers include account names, UNIX user IDs, Microsoft Windows account Globally Unique Identifiers (GUIDs), and bound X.509 certificates. Components can manage identifiers locally. When integrated into a system with a system-wide security policy, it\u2019s highly recommended that identifiers consistently link to the same account across all components in the system. Components should support integration with a system-wide identifier management capability to facilitate this consistency",
"requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four security levels that relate to CR 1.4 are:\n\u2022 SL-C(IAC,component) 1: CR 1.4\n\u2022 SL-C(IAC,component) 2: CR 1.4\n\u2022 SL-C(IAC,component) 3: CR 1.4\n\u2022 SL-C(IAC,component) 4: CR 1.4"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.7)",
"requirementName": "CR 1.5 \u2013 Authenticator management",
"requirementDescription": "Components must: \u2022 Use initial authenticator content. \u2022 Recognize changes to default authenticators during installation. \u2022 Handle periodic authenticator change/refresh. \u2022 Protect authenticators during storage, use, and transmission. Authenticators, like tokens, keys, biometrics, and passwords, establish identity in control systems. Users must secure and report authenticator issues promptly. Changing default passwords and safeguarding them are vital. Key-based authentication systems require similar precautions with additional hardware protection. Authentication strength depends on authenticator strength and validation policies, which may be required for specific operations to limit component usage. Hardware mechanisms must protect used authenticators.",
"requirementSatisfaction": "Requirement enhancement: (1) Hardware security for authenticators: The authenticators on which the component relies shall be protected via hardware mechanisms. Security Level: The requirements for the four security levels that relate to CR 1.5 are:\n\u2022 SL-C(IAC,component) 1: CR 1.5\n\u2022 SL-C(IAC,component) 2: CR 1.5\n\u2022 SL-C(IAC,component) 3: CR 1.5 (1)\n\u2022 SL-C(IAC,component) 4: CR 1.5 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.9)",
"requirementName": "CR 1.7 \u2013 Strength of password-based authentication",
"requirementDescription": "Components using password-based authentication must align with internationally recognized password strength guidelines, including criteria like minimum length, character variety, and duration (with a minimum of one-time passwords). These measures bolster security in line with established practices and recommendations.",
"requirementSatisfaction": "Requirement enhancement: (1)Password Generation and Lifetime Restrictions for Human Users: Components must prevent human users from reusing a password for a set number of generations and enforce password lifetime restrictions. Password changes may be prompted before expiration. (2)Password Lifetime Restrictions for All Users: Components should enforce password lifetime restrictions for all users, including humans, software processes, and devices. Security Level: The requirements for the four security levels that relate to CR 1.7 are:\n\u2022 SL-C(IAC,component) 1: CR 1.7\n\u2022 SL-C(IAC,component) 2: CR 1.7\n\u2022 SL-C(IAC,component) 3: CR 1.7 (1)\n\u2022 SL-C(IAC,component) 4: CR 1.7 (1) (2)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.10)",
"requirementName": "CR 1.8 \u2013 Public key infrastructure certificates",
"requirementDescription": "When using PKI, components must align with IEC 62443-3-3 SR1.8. The choice of PKI should follow the organization\u2019s certificate policy, which depends on the associated confidentiality breach risk. Policy guidance can be found in established standards and guidelines like IETF RFC 3647 for X.509-based PKI. Consider factors such as CA location and the list of trusted CAs based on network architecture (see IEC 62443-2-1).",
"requirementSatisfaction": "Requirement enhancement: None. The requirements for the four security levels that relate to CR 1.8 are:\n\u2022 SL-C(IAC,component) 1: Not selected\n\u2022 SL-C(IAC,component) 2: CR 1.8\n\u2022 SL-C(IAC,component) 3: CR 1.8\n\u2022 SL-C(IAC,component) 4: CR 1.8"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.11)",
"requirementName": "CR 1.9 \u2013 Strength of public key-based authentication",
"requirementDescription": "For components using public-key-based authentication in the same IACS environment: \u2022 Validate certificates with signature checks. \u2022 Validate certificate chains or use leaf certificates for self-signed ones. \u2022 Check certificate revocation status. \u2022 Enable user control of private keys. \u2022 Map authenticated identities to users. \u2022 Comply with public key authentication standards (as per 8.5). These requirements can be met through alternative out-of-band methods, even for disconnected systems. Trust and private key security are vital in public key cryptography. Trust involves tracing certificates to trusted entities, like CAs. Securely deploy self-signed certificates to relevant peers. Use methods like CRLs or OCSP for revocation checks. Short certificate lifetimes may help but can have operational challenges. Components should integrate with the IACS for key authentication and safeguard private keys when implementing public key authentication.",
"requirementSatisfaction": "Requirement enhancement: (1) Hardware security for public key-based authentication Components shall provide the capability to protect critical, long-lived private keys via hardware mechanisms. Security Level: The requirements for the four security levels that relate to CR 1.9 are:\n\u2022 SL-C(IAC,component) 1: Not selected\n\u2022 SL-C(IAC,component) 2: CR 1.9\n\u2022 SL-C(IAC,component) 3: CR 1.9 (1)\n\u2022 SL-C(IAC,component) 4: CR 1.9 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.12)",
"requirementName": "CR 1.10 \u2013 Authenticator feedback",
"requirementDescription": "Components offering authentication must obscure feedback during the authentication process to prevent unauthorized individuals from exploiting the information. This can be achieved by displaying characters like asterisks when users enter usernames/passwords or SSH tokens and one-time passwords. The authenticating entity should not provide hints about the authentication failure reason. authentication failure, such as \u201cunknown user name.\u201d",
"requirementSatisfaction": "Requirement enhancement: None. The requirements for the four SL levels that relate to CR 1.10 are:\n\u2022 SL-C(IAC,component) 1: CR 1.10\n\u2022 SL-C(IAC,component) 2: CR 1.10\n\u2022 SL-C(IAC,component) 3: CR 1.10\n\u2022 SL-C(IAC,component) 4: CR 1.10"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.13)",
"requirementName": "CR 1.11 \u2013 Unsuccessful login attempts",
"requirementDescription": "Components with authentication capabilities must: \u2022 Limit consecutive invalid access attempts within a specified time period by any user (human, software process, or device). \u2022 Deny access for a defined duration or until an administrator unlocks it after this limit is reached. The administrator may unlock an account before the timeout expires. To avoid potential denial of service, there may be restrictions on consecutive invalid access attempts, with the system possibly resetting the count to zero after a set time. However, automatic denial of access without human intervention should be avoided for control system operator workstations or nodes, where immediate operator responses are critical in emergencies. Lockout mechanisms should consider continuous operation requirements to prevent service disruptions or safety compromises. Allowing interactive logins to critical service accounts may pose denial of service risks and other vulnerabilities.",
"requirementSatisfaction": "Requirement enhancement: None. The requirements for the four SL levels that relate to CR 1.11 are:\n\u2022 SL-C(IAC,component) 1: CR 1.11\n\u2022 SL-C(IAC,component) 2: CR 1.11\n\u2022 SL-C(IAC,component) 3: CR 1.11\n\u2022 SL-C(IAC,component) 4: CR 1.11"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.14)",
"requirementName": "CR 1.12 \u2013 System use notification",
"requirementDescription": "Components offering local human user access/HMI must display a configurable system use notification message before authentication. This message deters unauthorized access, aligns with privacy and security policies, and warns of monitoring and potential legal consequences. Elements can include ownership notification, monitoring warnings, prohibition of unauthorized use, and implied consent to monitoring.",
"requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to CR 1.12 are:\n\u2022 SL-C(IAC,component) 1: CR 1.12\n\u2022 SL-C(IAC,component) 2: CR 1.12\n\u2022 SL-C(IAC,component) 3: CR 1.12\n\u2022 SL-C(IAC,component) 4: CR 1.12"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a75.16)",
"requirementName": "CR 1.14 \u2013 Strength of symmetric key-based authentication",
"requirementDescription": "Components using symmetric keys must: \u2022 Establish mutual trust using the symmetric key. \u2022 Securely store the shared secret to maintain authentication validity. \u2022 Control access to the shared secret. \u2022 Ensure that algorithms and keys used for symmetric key authentication adhere to 8.5. Methods for key installation should be defined, including out-of-band options. Protecting symmetric keys is crucial, as their compromise can jeopardize the entire system. Authentication between devices can be achieved through asymmetric or symmetric cryptography, depending on factors like key management, trust provisioning, legacy support, and efficiency. Symmetric key authentication methods include Needham-Schr\u00f6der and Kerberos, where parties prove their identity by demonstrating knowledge of a shared secret key.",
"requirementSatisfaction": "Requirement enhancement: (1) Hardware security for symmetric key-based authentication Components shall provide the capability to protect critical, long-lived symmetric keys via hardware mechanisms. Security Level: The requirements for the four SL levels that relate to CR 1.14 are:\n\u2022 SL-C(IAC,control system) 1: Not selected\n\u2022 SL-C(IAC,control system) 2: CR 1.14\n\u2022 SL-C(IAC,control system) 3: CR 1.14 (1)\n\u2022 SL-C(IAC,control system) 4: CR 1.14 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.3)",
"requirementName": "CR 2.1 \u2013 Authorization enforcement",
"requirementDescription": "Components must enforce authorization for all authenticated users based on their assigned responsibilities, using control policies and access mechanisms to manage user interactions with assets. The system verifies a user\u2019s identity and checks if requested operations comply with security policies, ensuring segregation of duties and least privileges. Enforcement mechanisms should not hinder the control system\u2019s performance. Changes to control system components should only be initiated by qualified and authorized individuals, impacting security.",
"requirementSatisfaction": "Requirement enhancement: (1) Enforce authorization based on user responsibilities and least privilege. (2) Allow authorized roles to map permissions for human users, with flexibility in role hierarchies. (3) Support supervisor manual override for a configurable duration or sequence of events, aiding operators in reacting to unusual conditions. (4) Enable dual approval for actions with a serious impact on the industrial process, limited to critical actions requiring high confidence in reliability and correctness. Security Level: The security levels related to CR 2.1 are as follows:\n\u2022 SL-C(UC,component) 1: CR 2.1\n\u2022 SL-C(UC,component) 2: CR 2.1 (1) (2)\n\u2022 SL-C(UC,component) 3: CR 2.1 (1) (2) (3)\n\u2022 SL-C(UC,component) 4: CR 2.1 (1) (2) (3) (4)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.4)",
"requirementName": "CR 2.2 \u2013 Wireless use control",
"requirementDescription": "If a component supports wireless interfaces, it should integrate with a system enforcing industry-standard usage control. This includes utilizing mechanisms like network admission control by network devices for wireless device security. Components may vary access based on wired or wireless connections, requiring interface type detection. Certain network devices can detect unauthorized wireless activity. Deploying dedicated devices for unauthorized network activity checks is recommended to ensure control system performance.",
"requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to CR 2.2 are:\n\u2022 SL-C(UC, component) 1: CR 2.2\n\u2022 SL-C(UC, component) 2: CR 2.2\n\u2022 SL-C(UC, component) 3: CR 2.2\n\u2022 SL-C(UC, component) 4: CR 2.2"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.5)",
"requirementName": "CR 2.3 \u2013 Use control for portable and mobile devices",
"requirementDescription": "There is no component level requirement associated with IEC 62443-3-3 SR 2.3."
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.6)",
"requirementName": "CR 2.4 \u2013 Mobile code",
"requirementDescription": "The use control requirements for mobile code are component-specific and can be located as requirements for each specific component type in Clauses 12 through 15."
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.7)",
"requirementName": "CR 2.5 \u2013 Session lock",
"requirementDescription": "Components with a human user interface, whether local or network-accessible, must:\n\u2022 Activate a session lock after a defined period of inactivity or manual initiation by any user (human, software, or device).\n\u2022 Keep the session lock in place until the authorized user regains access through proper identification and authentication. Session locks prevent unauthorized access to workstations or nodes and should activate automatically after a configurable time. These locks are typically system-level settings. Remote session termination, as defined in section 6.8, may impact these session locks.",
"requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to CR 2.5 are:\n\u2022 SL-C(UC, component) 1: CR 2.5\n\u2022 SL-C(UC, component) 2: CR 2.5\n\u2022 SL-C(UC, component) 3: CR 2.5\n\u2022 SL-C(UC, component) 4: CR 2.5"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.8)",
"requirementName": "CR 2.6 \u2013 Remote session termination",
"requirementDescription": "If a component enables remote sessions, it should permit session termination either automatically due to inactivity, or manually by authorized users or local authorities. Remote sessions are typically used for component monitoring and maintenance, subject to the control system\u2019s risk assessment and security policies. However, some components may not support session termination if it\u2019s integral to their essential function.",
"requirementSatisfaction": "Requirement enhancement: None. The requirements for the four SL levels that relate to CR 2.6 are:\n\u2022 SL-C(UC, component) 1: Not selected\n\u2022 SL-C(UC, component) 2: CR 2.6\n\u2022 SL-C(UC, component) 3: CR 2.6\n\u2022 SL-C(UC, component) 4: CR 2.6"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.9)",
"requirementName": "CR 2.7 \u2013 Concurrent session control",
"requirementDescription": "Components must limit the number of concurrent sessions per interface for any user (human, software, or device) to prevent resource starvation or DoS attacks. Determining the right session limits may require guidance from product suppliers or system integrators to balance user access and resource availability effectively.",
"requirementSatisfaction": "Requirement enhancement: None. The requirements for the four SL levels that relate to CR 2.7 are:\n\u2022 SL-C(UC, component) 1: Not selected\n\u2022 SL-C(UC, component) 2: Not selected\n\u2022 SL-C(UC, component) 3: CR 2.7\n\u2022 SL-C(UC, component) 4: CR 2.7"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.10)",
"requirementName": "CR 2.8 \u2013 Auditable events",
"requirementDescription": "Components must generate security-related audit records in categories such as access control, request errors, control system events, backup and restore events, configuration changes, and audit log events. Each audit record should include a timestamp, source (device, software, or user account), category, type, event ID, and event result. This requirement covers all relevant events from these categories that the firmware or OS can generate in devices with embedded firmware or an operating system.",
"requirementSatisfaction": "Requirement enhancement: None. The requirements for the four security levels that relate to CR 2.8 are:\n\u2022 SL-C(UC,component) 1: CR 2.8\n\u2022 SL-C(UC,component) 2: CR 2.8\n\u2022 SL-C(UC,component) 3: CR 2.8\n\u2022 SL-C(UC,component) 4: CR 2.8"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.11)",
"requirementName": "CR 2.9 \u2013 Audit storage capacity",
"requirementDescription": "Components should allocate audit storage capacity based on recognized log management recommendations and implement safeguards to prevent component failure when approaching or exceeding audit storage capacity. Adequate audit storage capacity must be provided, taking into account retention policies, auditing needs, and online processing. Components can use the integrated system for most storage but should have local storage to buffer audit data before transferring it to the system. You can refer to guidelines like NIST Special Publication (SP) 800-92. The capacity should align with retention requirements from relevant policies, regulations, or business needs.",
"requirementSatisfaction": "Requirement Enhancement: (1) Warn on Audit Storage Capacity Threshold. Components must offer the ability to issue a warning when audit record storage reaches a user-configurable threshold. Security Levels: For SL levels related to CR 2.9:\n\u2022 SL-C(UC,component) 1: CR 2.9\n\u2022 SL-C(UC,component) 2: CR 2.9\n\u2022 SL-C(UC,component) 3: CR 2.9 (1)\n\u2022 SL-C(UC,component) 4: CR 2.9 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.12)",
"requirementName": "CR 2.10 \u2013 Response to audit processing failures",
"requirementDescription": "Components must safeguard essential services and functions in case of audit processing failure and implement industry-standard practices for responding to audit processing failures. Audit processing involves generating, transmitting, possibly enhancing, and storing audit records, and failures can result from various issues. When deciding how to respond to audit processing failures, you can refer to guidelines like NIST SP 800-92, which offers recommendations for computer security log management. Responding to storage capacity limits can involve overwriting older audit records or stopping log generation, but both approaches may lead to the loss of valuable forensic data. Another appropriate response to an audit processing failure is alerting personnel.",
"requirementSatisfaction": "Requirement enhancement: None Security Level: The requirements for the four SL levels that relate to CR 2.10 are:\n\u2022 SL-C(UC,component) 1: CR 2.10\n\u2022 SL-C(UC,component) 2: CR 2.10\n\u2022 SL-C(UC,component) 3: CR 2.10\n\u2022 SL-C(UC,component) 4: CR 2.10"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.13)",
"requirementName": "CR 2.11 \u2013 Timestamps",
"requirementDescription": "Components must generate timestamps (date and time) for audit records, following the format recommended in ISO/IEC 8601:2004. Ensure that system design accounts for periodic time adjustments, such as daylight savings time in specific regions.",
"requirementSatisfaction": "Requirement enhancement: 1. Time Synchronization: Components must generate synchronized timestamps using a system-wide time source. 2. Time Source Integrity Protection: The time synchronization mechanism should detect and report unauthorized alterations, triggering audit events upon detection. Security Levels: For CR 2.11, the security levels are as follows:\n\u2022 SL-C(UC,component) 1: CR 2.11\n\u2022 SL-C(UC,component) 2: CR 2.11 (1)\n\u2022 SL-C(UC,component) 3: CR 2.11 (1)\n\u2022 SL-C(UC,component) 4: CR 2.11 (1) (2)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.14)",
"requirementName": "CR 2.12 \u2013 Non-repudiation",
"requirementDescription": "For actions through a human user interface, components must ensure a specific human user completed the action, documenting any control elements unable to do so. These actions cover tasks like operator activities, configuration changes, content creation, message exchange, and approvals. Non-repudiation prevents later denials of such actions, achieved through techniques like user identification, authorization, digital signatures, digital message receipts, and timestamps, confirming the origin of information and user-specific actions.",
"requirementSatisfaction": "Requirement enhancement: (1) Non-repudiation: Components must verify if a user (human, software, or device) performed a specific action. Security Level: The requirements for the four SL levels that relate to CR 2.12 are:\n\u2022 SL-C(UC,component) 1: CR 2.12\n\u2022 SL-C(UC,component) 2: CR 2.12\n\u2022 SL-C(UC,component) 3: CR 2.12\n\u2022 SL-C(UC,component) 4: CR 2.12 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a76.15)",
"requirementName": "CR 2.13 \u2013 Use of physical diagnostic and test interfaces",
"requirementDescription": "The use of physical diagnostic and test interfaces requirements are component-specific and can be located as requirements for each specific component type in Clauses 12 through 15."
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.3)",
"requirementName": "CR 3.1 \u2013 Communication integrity",
"requirementDescription": "Components must ensure the integrity of transmitted information, as network attacks can tamper with data during transmission, posing control system risks, especially in switched or routed networks where manipulation can be hard to detect. Safeguarding information integrity depends on network type and context, with physical access control suitable for smaller networks with direct links. Commercial communication services may challenge security controls, leading to consideration of compensating measures or risk acceptance. Control systems also face environmental challenges such as particulates, liquids, vibrations, gases, radiation, and EMI. Mitigating these issues involves using sealed connectors (e.g., M12), specialized cables, and shielded twisted pair or fiber cables when necessary. In some cases, wireless spectrum analysis may be needed to assess wireless networking feasibility.",
"requirementSatisfaction": "Requirement enhancement: (1) Communication Authentication: Components must verify the authenticity of received information during communication. Security Level: The requirements for the four SL levels that relate to CR 3.1 are:\n\u2022 SL-C(SI, component) 1: CR 3.1\n\u2022 SL-C(SI, component) 2: CR 3.1 (1)\n\u2022 SL-C(SI, component) 3: CR 3.1 (1)\n\u2022 SL-C(SI, component) 4: CR 3.1 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.4)",
"requirementName": "CR 3.2 \u2013 Protection from malicious code",
"requirementDescription": "The protection from malicious code requirements are component-specific and can be located as requirements for each specific component type in Clauses 12 through 15."
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.5)",
"requirementName": "CR 3.3 \u2013 Security functionality verification",
"requirementDescription": "Security Verification: Components should support security function verification per IEC 62443-3-3 SR3.3. Guidance for testing should come from the product supplier or system integrator. Asset owners must consider operational implications. Execution details, like scheduling or notification, should be specified. Examples of security verification include:\n\u2022 Testing antivirus measures with EICAR samples to ensure detection and trigger incident handling.\n\u2022 Verifying identification, authentication, and access controls through unauthorized access attempts, potentially automated.\n\u2022 Testing IDSs with known non-malicious traffic to evaluate rule-triggered monitoring and incident response.\n\u2022 Confirming audit logging compliance with security policies, procedures, and preventing internal or external disabling",
"requirementSatisfaction": "Requirement enhancement: (1) Security Function Verification: Components should allow for security function verification during regular operations. Careful implementation is necessary to prevent adverse effects, and it may not be suitable for safety systems. Security Level: The requirements for the four SL levels that relate to CR 3.3 are:\n\u2022 SL-C(SI, component) 1: CR 3.3\n\u2022 SL-C(SI, component) 2: CR 3.3\n\u2022 SL-C(SI, component) 3: CR 3.3\n\u2022 SL-C(SI, component) 4: CR 3.3 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.6)",
"requirementName": "CR 3.4 \u2013 Software and information integrity",
"requirementDescription": "Components must support integrity checks on software, configuration, and data, along with recording and reporting the results. These checks help detect and protect against tampering if other security measures are bypassed. Recommended integrity methods like cryptographic hashes should be used. For instance, these methods can monitor field devices for configuration changes to identify security breaches, including unauthorized alterations.",
"requirementSatisfaction": "Requirement enhancement:\n1. Software and Information Authenticity: Components must support authenticity checks on software, configuration, and data, along with recording and reporting results. These checks verify the legitimacy of the information.\n2. Automated Integrity Violation Notification: If the component performs integrity checks, it must automatically notify a configurable entity upon detecting an unauthorized change.\nSecurity Level: The requirements for the four SL levels that relate to CR 3.4 are:\n\u2022 SL-C(SI, component) 1: CR 3.4\n\u2022 SL-C(SI, component) 2: CR 3.4 (1)\n\u2022 SL-C(SI, component) 3: CR 3.4 (1) (2)\n\u2022 SL-C(SI, component) 4: CR 3.4 (1) (2)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.7)",
"requirementName": "CR 3.5 \u2013 Input validation",
"requirementDescription": "Input Data Validation: Components must validate input data for industrial process control and external interfaces affecting component actions. Validation ensures data integrity and adherence to specifications, while pre-screening inputs to interpreters prevent accidental command interpretation. This requirement focuses on security, not human errors like supplying valid but out-of-range integers. Industry practices involve checking for out-of-range values, invalid characters, incomplete data, and buffer overflow. Security concerns related to invalid inputs include SQL injection, cross-site scripting, and malformed packets. Guidelines like the OWASP Code Review Guide offer additional guidance.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to CR 3.5 are:\n\u2022 SL-C(SI, component) 1: CR 3.5\n\u2022 SL-C(SI, component) 2: CR 3.5\n\u2022 SL-C(SI, component) 3: CR 3.5\n\u2022 SL-C(SI, component) 4: CR 3.5"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.8)",
"requirementName": "CR 3.6 \u2013 Deterministic output",
"requirementDescription": "Components connecting to an automation process must have the ability to set outputs to a predetermined state if normal operation, as defined by the supplier, cannot be maintained. Ensuring deterministic behavior of control system outputs when facing threats is crucial for maintaining normal operations. Ideally, the device should continue operating normally during an attack. However, if normal operation cannot be sustained, control system outputs should fail to a predetermined state. The appropriate state depends on the device and can be configured by the user to be Unpowered, Hold (last-known-good value), Fixed (defined by the asset owner or application), or Dynamic (based on the current state).",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to CR 3.6 are:\n\u2022 SL-C(SI, component) 1: CR 3.6\n\u2022 SL-C(SI, component) 2: CR 3.6"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.9)",
"requirementName": "CR 3.7 \u2013 Error handling",
"requirementDescription": "Error Handling: Components must handle errors without disclosing exploitable information to potential attackers. Error messages should be structured to provide timely, useful information without revealing sensitive details. Disclosing such information should only happen when necessary to resolve errors promptly. Guidelines like the OWASP Code Review Guide provide helpful recommendations, such as avoiding specific authentication failure details like 'invalid user or password' to prevent aiding potential attackers in targeting the IACS.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to CR 3.7 are:\n\u2022 SL-C(SI, component) 1: CR 3.7\n\u2022 SL-C(SI, component) 2: CR 3.7\n\u2022 SL-C(SI, component) 3: CR 3.7\n\u2022 SL-C(SI, component) 4: CR 3.7"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.10)",
"requirementName": "CR 3.8 \u2013 Session integrity",
"requirementDescription": "Session Integrity Protection: Components must protect communication session integrity by invalidating session identifiers upon user logout or session termination, including browser sessions. Generating unique, system-generated session identifiers and recognizing only these. Creating unique session identifiers using accepted random sources. This control helps maintain trust in the identities of communication session parties and data integrity, reducing risks like man-in-the-middle attacks, session hijacking, and data injection. The use of session integrity mechanisms should be carefully assessed for real-time communication requirements, as they may introduce overhead. Secure and unpredictable session IDs, linked to session lifetimes, help mitigate session hijacking and related attacks.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to CR 3.8 are:\n\u2022 SL-C(SI, component) 1: Not selected\n\u2022 SL-C(SI, component) 2: CR 3.8\n\u2022 SL-C(SI, component) 3: CR 3.8\n\u2022 SL-C(SI, component) 4: CR 3.8"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.11)",
"requirementName": "CR 3.9 \u2013 Protection of audit information",
"requirementDescription": "Components must protect audit information, audit logs, and audit tools (if available) against unauthorized access, alteration, and deletion. This includes all data essential for control system audits, such as records, settings, and reports. Ensuring the security of this information is vital for activities like error correction, recovery from security breaches, investigations, and more. Enhanced protection measures may include storing audit data on hardware-enforced write-once media.",
"requirementSatisfaction": "Requirement enhancement: (1) Audit Records on Write-Once Media: Components must support storing audit records on hardware-enforced write-once media.\nSecurity Level: The requirements for the four SL levels that relate to CR 3.9 are:\n\u2022 SL-C(SI, component) 1: Not selected\n\u2022 SL-C(SI, component) 2: CR 3.9\n\u2022 SL-C(SI, component) 3: CR 3.9\n\u2022 SL-C(SI, component) 4: CR 3.9 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.12)",
"requirementName": "CR 3.10 \u2013 Support for updates",
"requirementDescription": "The support for updates requirements are component-specific and can be located as requirements for each specific device type in Clauses 12 through 15."
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.13)",
"requirementName": "CR 3.11 \u2013 Physical tamper resistance and detection",
"requirementDescription": "The physical tamper resistance and detection requirements are component-specific and can be located as requirements for each specific device type in Clauses 12 through 15."
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.14)",
"requirementName": "CR 3.12 \u2013 Provisioning product supplier roots of trust",
"requirementDescription": "The provisioning product supplier roots of trust requirements are component-specific and can be located as requirements for each specific device type in Clauses 12 through 15."
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.15)",
"requirementName": "CR 3.13 \u2013 Provisioning asset owner roots of trust",
"requirementDescription": "The provisioning asset owner roots of trust requirements are component-specific and can be located as requirements for each specific device type in Clauses 12 through 15."
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a77.16)",
"requirementName": "CR 3.14 \u2013 Integrity of the boot process",
"requirementDescription": "The integrity of the boot process requirements are component-specific and can be located as requirements for each specific device type in Clauses 12 through 15."
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a78.3)",
"requirementName": "CR 4.1 \u2013 Information confidentiality",
"requirementDescription": "Confidentiality Protection: Components must support:\n\u2022 Protecting the confidentiality of information at rest with explicit read authorization.\n\u2022 Protecting the confidentiality of information in transit per IEC 62443-3-3 SR 4.1. The decision to protect particular information relies on the context and cannot be established during product design. However, if the control system requires explicit read authorizations, this implies a need for protection. Therefore, information with explicit read authorization should be treated as potentially sensitive, and the component must offer confidentiality protection. To ensure confidentiality during information transmission, system-level capabilities are necessary, which the component should facilitate. Additional requirements for confidentiality protection can be found in section 8.5.",
"requirementSatisfaction": "Requirement enhancement; None.\nSecurity Level: The requirements for the four SL levels that relate to CR 4.1 are:\n\u2022 SL-C(DC, component) 1: CR 4.1\n\u2022 SL-C(DC, component) 2: CR 4.1\n\u2022 SL-C(DC, component) 3: CR 4.1\n\u2022 SL-C(DC, component) 4: CR 4.1"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a78.4)",
"requirementName": "CR 4.2 \u2013 Information Persistence",
"requirementDescription": "Secure Information Removal: Components must erase all data with explicit read authorization when taken out of service or decommissioned. Removal should not accidentally release sensitive data like authentication or network configurations, which could enable unauthorized activity. User-generated data must not be disclosed to other users or roles without proper control. Managing control system data persistence prevents accidental data disclosure when resources are returned to the control system.",
"requirementSatisfaction": "Requirement enhancement:\n1. Memory Security: Components must prevent unauthorized data transfer via volatile shared memory resources, which do not retain data after release to memory management. Attacks on volatile memory (RAM) can extract sensitive information before it\u2019s overwritten. Therefore, when volatile shared memory is used by a different user, all data and connections must be purged to ensure privacy and security.\n2. Erase Verification: Components must support verifying the successful erasure of information.\nSecurity Level: The requirements for the four SL levels that relate to CR 4.2 are:\n\u2022 SL-C(DC, component) 1: Not selected\n\u2022 SL-C(DC, component) 2: CR 4.2\n\u2022 SL-C(DC, component) 3: CR 4.2 (1) (2)\n\u2022 SL-C(DC, component) 4: CR 4.2 (1) (2)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a78.5)",
"requirementName": "CR 4.3 \u2013 Use of cryptography",
"requirementDescription": "Components must adhere to international best practices for cryptographic security. The choice of cryptographic protection should be based on a threat and risk analysis, considering factors like data value, consequences of breaches, information confidentiality duration, and control system constraints. This applies to data at rest and in transit, including backups. Suppliers should document their cryptographic key establishment and management practices. Components should use well-established encryption and hash algorithms like AES and SHA, with key sizes meeting standard requirements. Effective random number generators are essential for key generation. Security policies and procedures for key management should cover periodic changes, destruction, distribution, and backup of encryption keys, following established standards. Detailed implementation guidelines can be found in documents like NIST SP 800-57, FIPS 140-2, or ISO/IEC 19790.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four security levels that relate to CR 4.3 are:\n\u2022 SL-C(DC,component) 1: CR 4.3\n\u2022 SL-C(DC,component) 2: CR 4.3\n\u2022 SL-C(DC,component) 3: CR 4.3\n\u2022 SL-C(DC,component) 4: CR 4.3"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a79.3)",
"requirementName": "CR 5.1 \u2013 Network segmentation",
"requirementDescription": "Components must support network segmentation aligned with the broader network architecture, considering logical segmentation and criticality. Network segmentation enhances system response, reliability, and cybersecurity by controlling network traffic ingress and egress. It isolates different network segments, including critical and safety-related systems, for added protection. Access to the World Wide Web from the control system should be justified based on operational requirements. The effectiveness of network segmentation varies based on the facility\u2019s network architecture. Trade-offs between logical and physical segmentation should be evaluated during network design (see IEC 62443-2-1). In case of an incident, breaking connections between network segments may be necessary. In such cases, essential services must be maintained for device operation or orderly shutdown. This may involve duplicating some servers on the control system network to support features like DHCP, DNS, or local CAs. It may also require designing critical control and safety-related systems for complete isolation from other networks.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to CR 5.1 are:\n\u2022 SL-C(RDF, component) 1: CR 5.1\n\u2022 SL-C(RDF, component) 2: CR 5.1\n\u2022 SL-C(RDF, component) 3: CR 5.1\n\u2022 SL-C(RDF, component) 4: CR 5.1"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a79.4)",
"requirementName": "CR 5.2 \u2013 Zone boundary protection",
"requirementDescription": "The zone boundary protection requirements are network-component-specific and can be located as requirements for network devices in Clause 15.",
"requirementSatisfaction": ""
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a79.5)",
"requirementName": "CR 5.3 \u2013 General-purpose person-to-person communication restrictions",
"requirementDescription": "The general-purpose person-to-person communication restriction requirements are network component-specific and can be located as requirements for network devices in Clause 15.",
"requirementSatisfaction": ""
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a79.6)",
"requirementName": "CR 5.4 \u2013 Application partitioning",
"requirementDescription": "There is no component level requirement associated with IEC 62443-3-3 SR 5.4.",
"requirementSatisfaction": ""
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a710.3)",
"requirementName": "CR 6.1 \u2013 Audit log accessibility",
"requirementDescription": "Components must permit authorized users and tools to access audit logs in read-only mode, containing event records crucial for post-security incident investigations. Audit reduction and report generation are often done on a separate information system. While manual access through screen views or printouts meets the basic requirement, higher security levels require programmatic access to provide data to analysis mechanisms like SIEM systems.",
"requirementSatisfaction": "Requirement enhancement: (1) Programmatic access to audit logs Components shall provide programmatic access to audit records by either using an application programming interface (API) or sending the audit records to a centralized system.\nSecurity Level: The requirements for the four SL levels that relate to CR 6.1 are:\n\u2022 SL-C(TRE, component) 1: CR 6.1\n\u2022 SL-C(TRE, component) 2: CR 6.1\n\u2022 SL-C(TRE, component) 3: CR 6.1 (1)\n\u2022 SL-C(TRE, component) 4: CR 6.1 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a710.4)",
"requirementName": "CR 6.2 \u2013 Continuous monitoring",
"requirementDescription": "Components must support continuous monitoring to swiftly detect, characterize, and report security breaches. This involves essential monitoring tools like IDS, IPS, protection against malicious code, and network monitoring. Monitoring techniques should adapt to address advanced attacks, such as behavior-based IDS/IPS. Strategically placed monitoring devices within the control system are crucial for collecting critical information. Ad hoc monitoring can be used for specific transactions, and reporting mechanisms are necessary for timely event responses. To streamline reporting and handle data effectively, mechanisms like SIEM are often used to correlate individual events into aggregate reports providing context for raw events.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to CR 6.2 are:\n\u2022 SL-C(TRE, component) 1: Not selected\n\u2022 SL-C(TRE, component) 2: CR 6.2\n\u2022 SL-C(TRE, component) 3: CR 6.2\n\u2022 SL-C(TRE, component) 4: CR 6.2"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a711.3)",
"requirementName": "CR 7.1 \u2013 Denial of service protection",
"requirementDescription": "Degraded Mode Operation: Components must maintain essential functions when operating in a degraded mode caused by a DoS event. Various forms of DoS situations may affect components, and they must be designed to ensure continued safe operations while in this degraded mode.",
"requirementSatisfaction": "Requirement enhancement: (1) Manage communication load from component Components shall provide the capability to mitigate the effects of information and/or message flooding types of DoS events. Security Level: The requirements for the four SL levels that relate to CR 7.1 are:\n\u2022 SL-C(RA, component) 1: CR 7.1\n\u2022 SL-C(RA, component) 2: CR 7.1 (1)\n\u2022 SL-C(RA, component) 3: CR 7.1 (1)\n\u2022 SL-C(RA, component) 4: CR 7.1 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a711.4)",
"requirementName": "CR 7.2 \u2013 Resource Management",
"requirementDescription": "Components must control resource usage by security functions to prevent resource exhaustion. This includes measures like network segmentation and priority schemes to ensure lower-priority software processes cannot disrupt higher-priority control system processes. Actions such as network scans, patching, or antivirus checks on an operating system can disrupt normal operations and should be mitigated using techniques like traffic rate limiting.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to CR 7.2 are:\n\u2022 SL-C(RA, component) 1: CR 7.2\n\u2022 SL-C(RA, component) 2: CR 7.2\n\u2022 SL-C(RA, component) 3: CR 7.2\n\u2022 SL-C(RA, component) 4: CR 7.2"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a711.5)",
"requirementName": "CR 7.3 \u2013 Control system backup",
"requirementDescription": "Backup Capability: Components must support system-level backup operations to safeguard their state, including user and system-level information. These backups should not disrupt normal component operations. Maintaining up-to-date backups is essential for recovery from control system failures or misconfigurations. Automating this function reduces operator workload. Consider the information stored in backups, which may include cryptographic keys and other sensitive data protected by security controls within the system. Backup mechanisms must protect this information, possibly through backup encryption, encrypting sensitive data within backups, or excluding sensitive information from backups. If backups are encrypted, cryptographic keys should be backed up separately using a more secure procedure.",
"requirementSatisfaction": "Requirement enhancement: (1) Backup Integrity Verification: Components must validate the integrity of backed-up information before initiating a restore. Security Level: The requirements for the four SL levels that relate to CR 7.3 are:\n\u2022 SL-C(RA, component) 1: CR 7.3\n\u2022 SL-C(RA, component) 2: CR 7.3 (1)\n\u2022 SL-C(RA, component) 3: CR 7.3 (1)\n\u2022 SL-C(RA, component) 4: CR 7.3 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a711.6)",
"requirementName": "CR 7.4 \u2013 Control system recovery and reconstitution",
"requirementDescription": "Recovery and Reconstitution: Components must support recovery and reconstitution to a known secure state after a disruption or failure. This process involves setting system parameters to secure values, reinstalling critical patches, reestablishing security configurations, ensuring documentation and procedures are available, reinstalling components with established settings, loading information from secure backups, and conducting full testing to ensure functionality.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to CR 7.4 are:\n\u2022 SL-C(RA, component) 1: CR 7.4\n\u2022 SL-C(RA, component) 2: CR 7.4\n\u2022 SL-C(RA, component) 3: CR 7.4\n\u2022 SL-C(RA, component) 4: CR 7.4"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a711.7)",
"requirementName": "CR 7.5 \u2013 Emergency power",
"requirementDescription": "There is no component level requirement associated with IEC 62443-3-3 SR 7.5."
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a711.8)",
"requirementName": "CR 7.6 \u2013 Network and security configuration settings",
"requirementDescription": "Configuration Compliance: Components must support configuration based on the control system supplier\u2019s recommended network and security settings. They should provide an interface for current network and security configuration settings, with default settings aligned with recommendations. To detect and rectify deviations from approved or recommended configurations, components should support monitoring and control of configuration changes in line with security policies and procedures.",
"requirementSatisfaction": "Requirement enhancement: (1) Machine-readable reporting of current security settings Components shall provide the capability to generate a report listing the currently deployed security settings in a machine-readable format. Security Level: The requirements for the four SL levels that relate to CR 7.6 are:\n\u2022 SL-C(RA, component) 1: CR 7.6\n\u2022 SL-C(RA, component) 2: CR 7.6\n\u2022 SL-C(RA, component) 3: CR 7.6 (1)\n\u2022 SL-C(RA, component) 4: CR 7.6 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a711.9)",
"requirementName": "CR 7.7 \u2013 Least functionality",
"requirementDescription": "Function Restriction: Components must support the specific restriction of unnecessary functions, ports, protocols, and services. While components can offer a range of functions and services, not all are essential for IACS operations. As a default, functions beyond a baseline configuration should be disabled. Combining multiple services in a single component for convenience should be done cautiously, as it increases security risks compared to limiting services per component.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to CR 7.7 are:\n\u2022 SL-C(RA, component) 1: CR 7.7\n\u2022 SL-C(RA, component) 2: CR 7.7\n\u2022 SL-C(RA, component) 3: CR 7.7\n\u2022 SL-C(RA, component) 4: CR 7.7"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a711.10)",
"requirementName": "CR 7.8 \u2013 Control system component inventory",
"requirementDescription": "Component Inventory: Components must support control system component inventory as per IEC 62443-3-3 SR 7.8. Components introduced into the control system should have a compatible mechanism for updating the component inventory, aligning with IEC 62443-2-4 SP.06.02.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to CR 7.8 are:\n\u2022 SL-C(RA, component) 1: Not selected\n\u2022 SL-C(RA, component) 2: CR 7.8\n\u2022 SL-C(RA, component) 3: CR 7.8\n\u2022 SL-C(RA, component) 4: CR 7.8"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a712.2)",
"requirementName": "SAR 2.4 \u2013 Mobile code",
"requirementDescription": "Software using mobile code technologies must enforce a security policy covering usage. This policy should, at a minimum, allow:\n\u2022 Control over mobile code execution.\n\u2022 Regulation of user transfers of mobile code.\n\u2022 Management of mobile code execution based on integrity checks.\nMobile code technologies include Java, JavaScript, ActiveX, PDF, Postscript, Shockwave, Flash, VBScript, etc. Usage restrictions apply to server-installed and workstation-executed mobile code. Controls should prevent unacceptable mobile code within the control system, possibly allowing controlled exchanges in adjacent environments managed by IACS personnel.",
"requirementSatisfaction": "Requirement enhancement: (1) Mobile Code Authenticity: The application must enforce a security policy enabling the device to control code execution based on authenticity check results before execution. Security Level: The requirements for the four SL levels that relate to SAR 2.4 are:\n\u2022 SL-C(UC, component) 1: SAR 2.4\n\u2022 SL-C(UC, component) 2: SAR 2.4 (1)\n\u2022 SL-C(UC, component) 3: SAR 2.4 (1)\n\u2022 SL-C(UC, component) 4: SAR 2.4 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a712.3)",
"requirementName": "SAR 3.2 \u2013 Protection from malicious code",
"requirementDescription": "The application product supplier must document compatibility with at least one protection mechanism against malicious code, such as viruses, worms, Trojan horses, spyware, and similar threats.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to SAR 3.2 are:\n\u2022 SL-C(SI, component) 1: SAR 3.2\n\u2022 SL-C(SI, component) 2: SAR 3.2\n\u2022 SL-C(SI, component) 3: SAR 3.2\n\u2022 SL-C(SI, component) 4: SAR 3.2"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a713.2)",
"requirementName": "EDR 2.4 \u2013 Mobile code",
"requirementDescription": "Embedded devices using mobile code technologies must enforce a security policy that includes:\n\u2022 Controlling mobile code execution.\n\u2022 Regulating which users (human, software process, or device) can upload mobile code to the device.\n\u2022 Managing mobile code execution based on integrity check results before execution.\nThis applies to technologies like Java, JavaScript, ActiveX, PDF, Postscript, Shockwave, Flash, VBScript, and others. These measures are relevant for server-installed and workstation-executed mobile code. They aim to prevent unacceptable mobile code from entering the control system environment while permitting controlled exchanges in adjacent environments managed by IACS personnel.",
"requirementSatisfaction": "Requirement enhancement: (1) Mobile Code Authenticity Check: Embedded devices must enforce a security policy that controls the execution of mobile code based on authenticity check results before execution. Security Level: The requirements for the four SL levels that relate to EDR 2.4 are:\n\u2022 SL-C(UC, component) 1: EDR 2.4\n\u2022 SL-C(UC, component) 2: EDR 2.4 (1)\n\u2022 SL-C(UC, component) 3: EDR 2.4 (1)\n\u2022 SL-C(UC, component) 4: EDR 2.4 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a713.3)",
"requirementName": "EDR 3.2 \u2013 Protection from malicious code",
"requirementDescription": "Protection from Unauthorized Software: Embedded devices must safeguard against unauthorized software installation and execution, which could contain malicious code. If an embedded device can employ compensating controls, direct support for protection from malicious code may not be necessary, as the IACS assumes responsibility for implementing safeguards. For scenarios involving local USB host access, the need for protection from malicious code should be assessed through a risk evaluation. Detection mechanisms should identify integrity violations in application binaries and data files using techniques like binary integrity monitoring, hashing, and signatures. Prevention measures may include controlling removable media, sandboxing, and utilizing platform-specific mechanisms like restricted firmware updates, NX bit, DEP, ASLR, stack corruption detection, mandatory access controls. Refer to section 10.4 for related requirements regarding control system monitoring tools and techniques.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to EDR 3.2 are:\n\u2022 SL-C(SI, component) 1: EDR 3.2\n\u2022 SL-C(SI, component) 2: EDR 3.2\n\u2022 SL-C(SI, component) 3: EDR 3.2\n\u2022 SL-C(SI, component) 4: EDR 3.2"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a713.5)",
"requirementName": "EDR 3.10 \u2013 Support for updates",
"requirementDescription": "Embedded Device Updates and Upgrades: Embedded devices must support the capability for updates and upgrades over their operational lifespan. Some embedded devices may perform essential functions, necessitating update mechanisms that won\u2019t disrupt high-availability systems (see 4.2). Redundancy within the embedded device is one approach to enable this capability.",
"requirementSatisfaction": "Requirement enhancement: (1) Update Authenticity and Integrity: Embedded devices must validate the authenticity and integrity of any software update or upgrade before installation.\nSecurity Level: The requirements for the four SL levels that relate to EDR 3.10 are:\n\u2022 SL-C(SI, component) 1: EDR 3.10\n\u2022 SL-C(SI, component) 2: EDR 3.10 (1)\n\u2022 SL-C(SI, component) 3: EDR 3.10 (1)\n\u2022 SL-C(SI, component) 4: EDR 3.10 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a713.6)",
"requirementName": "EDR 3.11 \u2013 Physical tamper resistance and detection",
"requirementDescription": "Tamper Resistance and Detection: Embedded devices must have mechanisms for tamper resistance and detection to guard against unauthorized physical access. These mechanisms aim to prevent, detect, and respond to unauthorized physical actions against an IACS device. Tamper resistance involves using specialized materials and features like hardened enclosures, locks, encapsulation, security screws, and tight airflow paths to make tampering difficult. Tamper evidence mechanisms ensure that visible or electronic evidence remains when tampering occurs. These can include seals, tapes, and more sophisticated techniques like switches.",
"requirementSatisfaction": "Requirement enhancement: (1) Tampering Attempt Notification: Embedded devices must be capable of automatically notifying a configurable set of recipients upon detecting an unauthorized physical access attempt. All tampering attempt notifications must be logged as part of the audit logging function.\nSecurity Level: The requirements for the four SL levels that relate to EDR 3.11 are:\n\u2022 SL-C(SI, component) 1: Not selected\n\u2022 SL-C(SI, component) 2: EDR 3.11\n\u2022 SL-C(SI, component) 3: EDR 3.11 (1)\n\u2022 SL-C(SI, component) 4: EDR 3.11 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a713.7)",
"requirementName": "EDR 3.12 \u2013 Provisioning product supplier roots of trust",
"requirementDescription": "Root of Trust Provisioning: Embedded devices must support provisioning and protecting product supplier keys and data for confidentiality, integrity, and authenticity. To validate hardware, software, and data from the supplier, components require a trusted source of data known as the \u2019root of trust.\u2019 This source can be cryptographic hashes of \u2019known good\u2019 software or the public part of an asymmetric cryptographic key pair for validating signatures. The root of trust data is used to verify critical software, firmware, and data before booting the component\u2019s firmware or operating system, ensuring a \u2019known good\u2019 state with uncompromised security mechanisms. Hardware safeguards protect the root of trust data, and modification is limited to the trusted product supplier\u2019s provisioning process. Information is validated against the root of trust through a hardware or software API, preserving data security.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to EDR 3.12 are:\n\u2022 SL-C(SI, component) 1: Not selected\n\u2022 SL-C(SI, component) 2: EDR 3.12\n\u2022 SL-C(SI, component) 3: EDR 3.12\n\u2022 SL-C(SI, component) 4: EDR 3.12"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a713.8)",
"requirementName": "EDR 3.13 \u2013 Provisioning asset owner roots of trust",
"requirementDescription": "Asset Owner Roots of Trust: Embedded devices must support asset owners in provisioning and safeguarding keys and data for confidentiality, integrity, and authenticity, serving as \u2019roots of trust.\u2019 This provisioning should be self-contained within the device\u2019s security zone. Product suppliers ensure the authenticity and integrity of their components\u2019 software and firmware, providing asset owners with a \u2019known good\u2019 starting point. However, asset owners often expand component functionality with mobile code or user programs, necessitating validation for authorization. Components should contain data to differentiate between valid and invalid origins for these extensions. To accommodate various asset owners\u2019 policies, product suppliers should enable secure provisioning of \u2019roots of trust.\u2019 Ensuring the authenticity and integrity of these \u2019roots of trust\u2019 is essential to prevent unauthorized additions by malicious actors. These roots can also support communication security requirements and authenticity checks for mobile code execution.",
"requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to EDR 3.13 are:\n\u2022 SL-C(SI, component) 1: Not selected\n\u2022 SL-C(SI, component) 2: EDR 3.13\n\u2022 SL-C(SI, component) 3: EDR 3.13\n\u2022 SL-C(SI, component) 4: EDR 3.13"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a713.9)",
"requirementName": "EDR 3.14 \u2013 Integrity of the boot process",
"requirementDescription": "Firmware and Software Integrity: Embedded devices must verify the integrity of the firmware, software, and configuration data required for the component\u2019s boot and runtime processes before use. To provide assurances to asset owners that a component\u2019s security functionality remains uncompromised, it\u2019s crucial to verify that the software and firmware haven\u2019t been tampered with and are valid for execution on the component. Therefore, the component should perform checks during the boot process to validate the integrity of its firmware and/or software. This validation prevents the component from booting into an insecure or invalid state, which could lead to damage or unauthorized access to other components, assets, or data.",
"requirementSatisfaction": "Requirement enhancement: (1) Boot Process Authenticity: Embedded devices must employ the product supplier\u2019s roots of trust to verify the authenticity of the firmware, software, and configuration data required for the component\u2019s boot process before allowing it to proceed. Security Level: The requirements for the four SL levels that relate to EDR 3.14 are:\n\u2022 SL-C(SI, component) 1: EDR 3.14\n\u2022 SL-C(SI, component) 2: EDR 3.14 (1)\n\u2022 SL-C(SI, component) 3: EDR 3.14 (1)\n\u2022 SL-C(SI, component) 4: EDR 3.14 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a713.9)",
"requirementName": "EDR 3.14 \u2013 Integrity of the boot process",
"requirementDescription": "Firmware and Software Integrity: Embedded devices must verify the integrity of the firmware, software, and configuration data required for the component\u2019s boot and runtime processes before use. To provide assurances to asset owners that a component\u2019s security functionality remains uncompromised, it\u2019s crucial to verify that the software and firmware haven\u2019t been tampered with and are valid for execution on the component. Therefore, the component should perform checks during the boot process to validate the integrity of its firmware and/or software. This validation prevents the component from booting into an insecure or invalid state, which could lead to damage or unauthorized access to other components, assets, or data.",
"requirementSatisfaction": "Requirement enhancement: (1) Boot Process Authenticity: Embedded devices must employ the product supplier\u2019s roots of trust to verify the authenticity of the firmware, software, and configuration data required for the component\u2019s boot process before allowing it to proceed. Security Level: The requirements for the four SL levels that relate to EDR 3.14 are:\n\u2022 SL-C(SI, component) 1: EDR 3.14\n\u2022 SL-C(SI, component) 2: EDR 3.14 (1)\n\u2022 SL-C(SI, component) 3: EDR 3.14 (1)\n\u2022 SL-C(SI, component) 4: EDR 3.14 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a714.2)",
"requirementName": "HDR 2.4 \u2013 Mobile code",
"requirementDescription": "Host Device Mobile Code Security: Host devices using mobile code technologies must enforce a security policy covering:\n\u2022 Controlling mobile code execution.\n\u2022 Regulating users (human, software process, or device) allowed to upload mobile code.\n\u2022 Managing code execution based on integrity checks.\nMobile code technologies include Java, JavaScript, ActiveX, PDF, Postscript, Shockwave, Flash, VBScript, and others. Usage restrictions apply to server-installed and workstation-executed mobile code. Measures should prevent unacceptable mobile code within the control system where the host device resides. Exchanges may be limited within the control system but allowed in controlled adjacent environments managed by IACS personnel. Security can be ensured through code-level integrity, authenticity, and authorization checks or secure communication tunnels during \u201cjust-in-time\u201d code execution, or equivalent methods.",
"requirementSatisfaction": "Requirement enhancement: (1) Mobile code authenticity check: The host device shall provide the capability to enforce a security policy that allows the device to control the execution of mobile code based on the results of an authenticity check prior to the code being executed Security Level: The requirements for the four SL levels that relate to HDR 2.4 are:\n\u2022 SL-C(UC, component) 1: HDR 2.4\n\u2022 SL-C(UC, component) 2: HDR 2.4(1)\n\u2022 SL-C(UC, component) 3: HDR 2.4 (1)\n\u2022 SL-C(UC, component) 4: HDR 2.4 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a714.3)",
"requirementName": "HDR 2.13 \u2013 Use of physical diagnostic and test interfaces",
"requirementDescription": "Protection of Factory Diagnostic Interfaces: Host devices must safeguard physical factory diagnostic and test interfaces (e.g., JTAG debugging) from unauthorized use. These interfaces help developers and factory personnel test and debug components but must be shielded from unauthorized access to preserve essential component functionality within the IACS. Interfaces using network communications with the device should comply with document requirements. If a diagnostic and test interface lacks control over the host device or access to non-public information, it may not require authentication. This determination should be based on a threat and risk assessment. For instance, JTAG debugging allows control of the processor and execution of arbitrary commands, while JTAG boundary scan only reads publicly available information.",
"requirementSatisfaction": "Requirement enhancement: (1) Diagnostic Interface Monitoring: Host devices must actively monitor their diagnostic and test interfaces, logging any detected access attempts. Security Level: The requirements for the four SL levels that relate to HDR 2.13 are:\n\u2022 SL-C(SI, component) 1: Not selected\n\u2022 SL-C(SI, component) 2: HDR 2.13\n\u2022 SL-C(SI, component) 3: HDR 2.13 (1)\n\u2022 SL-C(SI, component) 4: HDR 2.13 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a714.4)",
"requirementName": "HDR 3.2 \u2013 Protection from Malicious Code",
"requirementDescription": "Protection from Malicious Code: Host devices must include IACS product supplier-qualified mechanisms for safeguarding against malicious code. The product supplier should document any specific configuration requirements for this protection. Host devices should support protection against malicious code, including viruses, worms, Trojan horses, and spyware while maintaining the primary mission of the control system.",
"requirementSatisfaction": "Requirement enhancement: (1) Code Protection Version Reporting: Host devices shall automatically report the versions of malicious code protection software and files in use, integrated within the overall logging function. Security Level: The requirements for the four SL levels that relate to HDR 3.2 are:\n\u2022 SL-C(SI, component) 1: HDR 3.2\n\u2022 SL-C(SI, component) 2: HDR 3.2 (1)\n\u2022 SL-C(SI, component) 3: HDR 3.2 (1)\n\u2022 SL-C(SI, component) 4: HDR 3.2 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a714.5)",
"requirementName": "HDR 3.10 \u2013 Support for updates",
"requirementDescription": "Update and Upgrade Support: Host devices must be capable of receiving updates and upgrades during their operational lifetime. In cases where host devices perform essential functions, they should have mechanisms for patching and updating that do not disrupt critical operations. Redundancy within the host device is one way to provide this capability.",
"requirementSatisfaction": "Requirement enhancement: (1) Update Authenticity and Integrity: Host devices must verify the authenticity and integrity of any software updates or upgrades before installing them Security Level: The requirements for the four SL levels that relate to HDR 3.10 are:\n\u2022 SL-C(SI, component) 1: HDR 3.10\n\u2022 SL-C(SI, component) 2: HDR 3.10 (1)\n\u2022 SL-C(SI, component) 3: HDR 3.10 (1)\n\u2022 SL-C(SI, component) 4: HDR 3.10"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a714.6)",
"requirementName": "HDR 3.11 \u2013 Physical tamper resistance and detection",
"requirementDescription": "Tamper Resistance and Detection: Host devices must support tamper resistance and detection mechanisms to prevent unauthorized physical access. These mechanisms aim to make tampering difficult and detect any tampering attempts, providing visible or electronic evidence.",
"requirementSatisfaction": "Requirement enhancement: (1) Tampering Attempt Notification: Host devices must automatically notify a configurable set of recipients when an unauthorized physical access attempt is detected. These notifications shall also be logged as part of the overall audit logging function. Security Level: The requirements for the four SL levels that relate to HDR 3.11 are:\n\u2022 SL-C(SI, component) 1: Not selected\n\u2022 SL-C(SI, component) 2: HDR 3.11\n\u2022 SL-C(SI, component) 3: HDR 3.11 (1)\n\u2022 SL-C(SI, component) 4: HDR 3.11 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a714.7)",
"requirementName": "HDR 3.12 \u2013 Provisioning product supplier roots of trust",
"requirementDescription": "Host devices must support the provisioning and protection of product supplier keys and data used as \u201croots of trust\u201d during manufacturing. These roots of trust are critical for verifying the authenticity and integrity of hardware, software, and data provided by the product supplier. They ensure the component starts in a secure and unaltered state. The root of trust data can be safeguarded using software or hardware methods to prevent unauthorized changes. Typically, only the supplier\u2019s trusted provisioning process can modify this data. Validation against the root of trust is performed through a hardware or software API to maintain data protection.",
"requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to HDR 3.12 are:\n\u2022 SL-C(SI, component) 1: Not selected\n\u2022 SL-C(SI, component) 2: HDR 3.12\n\u2022 SL-C(SI, component) 3: HDR 3.12\n\u2022 SL-C(SI, component) 4: HDR 3.12"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a714.8)",
"requirementName": "HDR 3.13 \u2013 Provisioning asset owner roots of trust",
"requirementDescription": "Host devices must support the provisioning and security of asset owner keys and data used as \u201croots of trust.\u201d Product suppliers ensure the authenticity and integrity of their component\u2019s software and firmware, providing asset owners with a secure starting point. However, asset owners often use extensions like mobile code or user programs to enhance device functionality, which must be authorized and approved to maintain device security. Components should include data to distinguish between valid and invalid origins, which vary among asset owners. Since product suppliers may not know all valid origins during manufacture, they should allow asset owners to securely provision their \u201croots of trust.\u201d Protecting the authenticity and integrity of these roots is vital to prevent unauthorized additions and to meet communication security requirements such as data integrity, confidentiality, and mobile code execution authenticity.",
"requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to HDR 3.13 are:\n\u2022 SL-C(SI, component) 1: Not selected\n\u2022 SL-C(SI, component) 2: HDR 3.13\n\u2022 SL-C(SI, component) 3: HDR 3.13\n\u2022 SL-C(SI, component) 4: HDR 3.13"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a714.9)",
"requirementName": "HDR 3.14 \u2013 Integrity of the boot process",
"requirementDescription": "Host devices must verify the integrity of required firmware, software, and configuration data before booting to maintain security functionality and prevent insecure or invalid states that could harm the component or provide unauthorized access. This verification ensures that the software and firmware are suitable for device execution.",
"requirementSatisfaction": "Requirement enhancement: (1) Boot Process Authenticity: Host devices must use the product supplier\u2019s roots of trust to verify the authenticity of the firmware, software, and configuration data required for the component\u2019s boot process before using it in the boot process. Security Level: The requirements for the four SL levels that relate to HDR 3.14 are:\n\u2022 SL-C(SI, component) 1: HDR 3.14\n\u2022 SL-C(SI, component) 2: HDR 3.14 (1)\n\u2022 SL-C(SI, component) 3: HDR 3.14 (1)\n\u2022 SL-C(SI, component) 4: HDR 3.14 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.2)",
"requirementName": "NDR 1.6 \u2013 Wireless access management",
"requirementDescription": "Network devices with wireless access support must identify and authenticate all users in wireless communication. Wireless technology should meet the same security standards as other communication methods in IACS, despite the unique challenges it poses due to limited physical security compared to wired connections.",
"requirementSatisfaction": "Requirement enhancement: (1) Unique Identification and Authentication: The network device must uniquely identify and authenticate all users (humans, software processes, or devices) in wireless communication. Security Level: The requirements for the four SL levels that relate to NDR 1.6 are:\n\u2022 SL-C(UC, component) 1: NDR 1.6\n\u2022 SL-C(UC, component) 2: NDR 1.6 (1)\n\u2022 SL-C(UC, component) 3: NDR 1.6 (1)\n\u2022 SL-C(UC, component) 4: NDR 1.6 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.3)",
"requirementName": "NDR 1.13 \u2013 Access via untrusted networks",
"requirementDescription": "Access Monitoring and Control: Network devices providing access to a network must monitor and control all methods of access from untrusted networks. This includes protecting against unauthorized or subverted connections, such as remote access methods (e.g., dial-up, broadband, wireless) and connections from non-control system office networks. The network device may employ Access Control List (ACL) functionality to restrict access based on various criteria, including MAC addresses, Virtual Local Area Networks (VLANs) for Layer 2 devices like Ethernet switches, and IP addresses, ports, protocols, and virtual private networks for Layer 3 devices like routers, gateways, and firewalls.",
"requirementSatisfaction": "Requirement enhancement: (1) Access Request Approval: The network device must deny access requests from untrusted networks unless explicitly approved by an assigned role. Security Level: The requirements for the four SL levels that relate to NDR 1.13 are:\n\u2022 SL-C(UC, component) 1: NDR 1.13\n\u2022 SL-C(UC, component) 2: NDR 1.13\n\u2022 SL-C(UC, component) 3: NDR 1.13 (1)\n\u2022 SL-C(UC, component) 4: NDR 1.13 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.4)",
"requirementName": "NDR 2.4 \u2013 Mobile code",
"requirementDescription": "Mobile Code Security: The network device must enforce a security policy for mobile code technologies, allowing control over code execution, user transfers, and integrity checks. Mobile code technologies may include Java, JavaScript, ActiveX, PDF, Postscript, Shockwave, Flash, VBScript, among others. Usage restrictions apply to server-installed and workstation-executed mobile code. Control measures should prevent unacceptable mobile code within the control system, allowing controlled exchanges in adjacent environments managed by IACS personnel. Mobile code security can include integrity, authenticity, and authorization checks in the code itself (application layer) or secure communication tunnels for \u2019just-in-time\u2019 code execution, or equivalent mechanisms.",
"requirementSatisfaction": "(1) Mobile Code Authenticity Check: The network device must enforce a security policy to control mobile code execution based on authenticity checks before execution. Security Level: The requirements for the four SL levels that relate to NDR 2.4 are:\n\u2022 SL-C(UC, component) 1: NDR 2.4\n\u2022 SL-C(UC, component) 2: NDR 2.4 (1)\n\u2022 SL-C(UC, component) 3: NDR 2.4 (1)\n\u2022 SL-C(UC, component) 4: NDR 2.4 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.5)",
"requirementName": "NDR 2.13 \u2013 Use of physical diagnostic and test interfaces",
"requirementDescription": "Protection of Factory Diagnostic Interfaces: Network devices must safeguard factory diagnostic and test interfaces (e.g., JTAG debugging) against unauthorized access. These interfaces aid developers and factory personnel in testing and debugging network devices. However, they must be protected from unauthorized access to ensure the device\u2019s essential functionality within the IACS. Interfaces that don\u2019t provide control over the network device or access to non-public information may not require authentication. This determination should be made through a threat assessment. For example, JTAG debugging provides control over the processor and needs authentication, while JTAG boundary scans, which only read the publicly available information, may not require it.",
"requirementSatisfaction": "Requirement enhancement: (1) Active Monitoring: Network devices must actively monitor diagnostic and test interfaces, generating audit log entries when unauthorized access attempts are detected. Security Level: The requirements for the four SL levels that relate to NDR 2.13 are: \u2022 SL-C(SI, component) 1: Not selected \u2022 SL-C(SI, component) 2: NDR 2.13 \u2022 SL-C(SI, component) 3: NDR 2.13 (1) \u2022 SL-C(SI, component) 4: NDR 2.13 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.6)",
"requirementName": "NDR 3.2 \u2013 Protection from malicious code",
"requirementDescription": "Protection from Malicious Code: Network devices must support protection from malicious code. Compensating controls, like network packet filtering, may be used if available. The responsibility for providing safeguards falls on the IACS. Local USB host access scenarios should be evaluated for protection from malicious code.",
"requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to NDR 3.2 are: \u2022 SL-C(SI, component) 1: NDR 3.2 \u2022 SL-C(SI, component) 2: NDR 3.2 \u2022 SL-C(SI, component) 3: NDR 3.2 \u2022 SL-C(SI, component) 4: NDR 3.2"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.7)",
"requirementName": "NDR 3.10 \u2013 Support for updates",
"requirementDescription": "Update Capability: Network devices must support updates and upgrades. They should enable patching and updating without affecting essential functions in high-availability systems, potentially through redundancy.",
"requirementSatisfaction": "Requirement enhancement: (1) Update Verification: Network devices must check the authenticity and integrity of software updates before installing them. Security Level: The requirements for the four SL levels that relate to NDR 3.10 are: \u2022 SL-C(SI, component) 1: NDR 3.10 \u2022 SL-C(SI, component) 2: NDR 3.10 (1) \u2022 SL-C(SI, component) 3: NDR 3.10 (1) \u2022 SL-C(SI, component) 4: NDR 3.10 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.8)",
"requirementName": "NDR 3.11 \u2013 Physical tamper resistance and detection",
"requirementDescription": "Tamper Prevention and Detection: Network devices should resist tampering attempts and detect unauthorized physical access. Tamper resistance involves using specialized materials and features like hardened enclosures, locks, encapsulation, or security screws to make tampering difficult. Tamper evidence techniques, such as seals and tapes, ensure visible or electronic evidence remains when tampering occurs. Combining these mechanisms enhances security",
"requirementSatisfaction": "Requirement enhancement: (1) Tampering Attempt Notification: Network devices must automatically notify a configurable set of recipients upon detecting unauthorized physical access attempts. All tampering notifications must be logged as part of the overall audit logging. Security Level: The requirements for the four SL levels that relate to NDR 3.11 are: \u2022 SL-C(SI, component) 1: Not selected \u2022 SL-C(SI, component) 2: NDR 3.11 \u2022 SL-C(SI, component) 3: NDR 3.11 (1) \u2022 SL-C(SI, component) 4: NDR 3.11 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.9)",
"requirementName": "NDR 3.12 \u2013 Provisioning product supplier roots of trust",
"requirementDescription": "Root of Trust Provisioning: Network devices must provision and safeguard product supplier keys and data as \u2019roots of trust\u2019 to ensure confidentiality, integrity, and authenticity. The \u2019root of trust\u2019 comprises trusted data, which can be cryptographic hashes of \u2019known good\u2019 software or the public portion of an asymmetric cryptographic key pair for verifying signatures. This trusted data validates critical software, firmware, and data before the component\u2019s firmware or operating system boots, ensuring a secure and reliable start. It is protected through software or hardware mechanisms, with limited modification access during product supplier provisioning. Validation is performed through a hardware or software API, preserving data confidentiality.",
"requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to NDR 3.12 are: \u2022 SL-C(SI, component) 1: Not selected \u2022 SL-C(SI, component) 2: NDR 3.12 \u2022 SL-C(SI, component) 3: NDR 3.12 \u2022 SL-C(SI, component) 4: NDR 3.12"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.10)",
"requirementName": "NDR 3.13 \u2013 Provisioning asset owner roots of trust",
"requirementDescription": "Asset Owner Roots of Trust: Network devices must support the provisioning and protection of asset owner keys and data, ensuring confidentiality, integrity, and authenticity as \u2019roots of trust.\u2019 While product suppliers secure their software and firmware, asset owners often extend device functionality with mobile code or user programs. To validate these extensions, components must differentiate valid from invalid origins, which vary among asset owners and may not be fully known by product suppliers at manufacturing. Therefore, product suppliers should enable asset owners to provision their \u2019roots of trust\u2019 securely, differentiating authorized origins according to security policies. Protecting the authenticity and integrity of these \u2019roots of trust\u2019 prevents unauthorized additions. These roots also enable authenticity checks for mobile code execution, ensuring code origin and integrity, and supporting communication security requirements like integrity and confidentiality.",
"requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to NDR 3.13 are: \u2022 SL-C(SI, component) 1: Not selected \u2022 SL-C(SI, component) 2: NDR 3.13 \u2022 SL-C(SI, component) 3: NDR 3.13 \u2022 SL-C(SI, component) 4: NDR 3.13"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.11)",
"requirementName": "NDR 3.14 \u2013 Integrity of the boot process",
"requirementDescription": "Integrity Verification for Boot Process: Network devices must validate firmware, software, and configuration data integrity before using them in the boot process. This ensures that the component\u2019s security functionality remains uncompromised. By checking the integrity and authenticity of firmware and software before booting, components prevent insecure or invalid states that could lead to damage or unauthorized access.",
"requirementSatisfaction": "Requirement enhancement: (1) Boot Process Authenticity: Network devices shall use product supplier roots of trust to verify the authenticity of firmware, software, and configuration data before using them in the boot process. Security Level: The requirements for the four SL levels that relate to NDR 3.14 are: \u2022 SL-C(SI, component) 1: NDR 3.14 \u2022 SL-C(SI, component) 2: NDR 3.14 (1) \u2022 SL-C(SI, component) 3: NDR 3.14 (1) \u2022 SL-C(SI, component) 4: NDR 3.14 (1)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.12)",
"requirementName": "NDR 5.2 \u2013 Zone boundary protection",
"requirementDescription": "Boundary Security Monitoring and Control: Network devices at zone boundaries must enforce compartmentalization as per risk-based zones and conduits. Connections outside each security zone should be managed through boundary protection devices (e.g., proxies, gateways, firewalls) in an effective architecture (e.g., firewalls protecting DMZ application gateways). Alternate processing sites should have the same level of protection as the primary site.",
"requirementSatisfaction": "Requirement enhancement: 1. Default Deny, Exception-Based: Network components must default to denying network traffic and only allow exceptions (deny all, permit by exception). 2. Isolation Mode: Network components must be capable of isolating the control system boundary, e.g., in response to a security breach or attack. 3. Fail-Safe Closure: Network components must block communication through the control system boundary in the event of boundary protection mechanism failure (fail close) Security Level: The requirements for the four SL levels that relate to NDR 5.2 are: \u2022 SL-C(SI, component) 1: NDR 5.2 \u2022 SL-C(SI, component) 2: NDR 5.2 (1) \u2022 SL-C(SI, component) 3: NDR 5.2 (1) (2) (3) \u2022 SL-C(SI, component) 4: NDR 5.2 (1) (2) (3)"
},
{
"requirementStandard": "IEC 62443 4-2 (\u00a715.13)",
"requirementName": "NDR 5.3 \u2013 General purpose, person-to-person communication restrictions",
"requirementDescription": "A network device at a zone boundary shall block general-purpose, person-to-person messages from external users or systems. These messages include, but are not limited to, email, social media (Twitter, Facebook, etc.), and any systems allowing the transmission of executable files. Such systems are typically used for non-control system purposes, posing higher risks than benefits. They are often used as attack vectors to introduce malware, transfer unauthorized information, or create network congestion for security issues or attacks on the control system. Network devices can implement these restrictions by blocking specific communications using port numbers, source/target addresses, and application layer firewalls.",
"requirementSatisfaction": "Requirement enhancement: None Security Level: The requirements for the four SL levels that relate to NDR 5.3 are: \u2022 SL-C(SI, component) 1: NDR 5.3 \u2022 SL-C(SI, component) 2: NDR 5.3 \u2022 SL-C(SI, component) 3: NDR 5.3 \u2022 SL-C(SI, component) 4: NDR 5.3"
}
]
}