{
  "sRequirements": [
    {
        "requirementStandard": "IEC 62443 3-3 (§5.3)",
        "requirementName": "SR 1.1 – Human user identification and authentication",
        "requirementDescription": "The control system must identify and authenticate human users on access interfaces for security policy enforcement. This applies to local and remote access and can use methods like passwords, tokens, biometrics, or a combination, including geographic location. Application-level authentication is common, and role-based identification is used for groups like control room operators. Emergency actions and critical control functions must not be hindered by authentication requirements. Physical security measures can restrict access, and operator workstation clients should be authenticated or limited to the control room environment. The control system initially verifies user identities and enforces permissions in line with IAC policies as defined in IEC 62443-2-1.",
        "requirementSatisfaction": "Requirement Enhancements: • SR 1.1 RE 1 – Unique user identification and authentication: The control system must uniquely identify and authenticate all human users. • SR 1.1 RE 2 – Multifactor authentication for untrusted networks: The control system must use multifactor authentication for human user access via untrusted networks. • SR 1.1 RE 3 – Multifactor authentication for all networks: The control system must employ multifactor authentication for all human user access. Security Levels: For the four SL levels related to SR 1.1 (Human user identification and authentication): • SL-C(IAC, control system) 1: Complies with SR 1.1 • SL-C(IAC, control system) 2: Complies with SR 1.1 (1) • SL-C(IAC, control system) 3: Complies with SR 1.1 (1) (2) • SL-C(IAC, control system) 4: Complies with SR 1.1 (1) (2) (3)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.4)",
        "requirementName": "SR 1.2 – Software process and device identification and authentication",
        "requirementDescription": "The control system must identify and authenticate all software processes and devices on access interfaces to ensure security policy adherence, prevent unauthorized data exchanges, and address complex identity management, especially for remote vendor support. This encompasses portable and mobile device considerations. Group entity identification and authentication can be role-based, group-based, or entity-based without hindering essential functions. Group authentication with shared accounts or keys is common in specific setups, ensuring alignment with IEC 62443-2-1 control policies.",
        "requirementSatisfaction": "Requirement Enhancements: • SR 1.2 RE 1 – Unique software process and device identification and authentication: The control system must uniquely identify and authenticate all software processes and devices. Security Levels: For the four SL levels related to SR 1.2 (Software process and device identification and authentication): • SL-C(IAC, control system) 1: Not Selected • SL-C(IAC, control system) 2: Complies with SR 1.2 • SL-C(IAC, control system) 3: Complies with SR 1.2 (1) • SL-C(IAC, control system) 4: Complies with SR 1.2 (1)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.5)",
        "requirementName": "SR 1.3 – Account management",
        "requirementDescription": "The control system must allow authorized users to manage all accounts, including adding, modifying, disabling, and removing them. This management can involve different types of accounts and their associated authorizations. Shared accounts may be acceptable with compensating measures in accordance with risk analysis and regulations. For non-human user accounts (e.g., service accounts), specific security policies apply, and account management should follow unified policies and be implemented in relevant control system components. Unused default system accounts from the initial installation should be removable. The aim is to streamline and consistently apply account management for improved security.",
        "requirementSatisfaction": "Requirement Enhancements: • SR 1.3 RE 1 – Unified account management: The control system must support unified account management. Security Levels: For the four SL levels related to SR 1.3 (Account management): • SL-C(IAC, control system) 1: Complies with SR 1.3 • SL-C(IAC, control system) 2: Complies with SR 1.3 • SL-C(IAC, control system) 3: Complies with SR 1.3 (1) • SL-C(IAC, control system) 4: Complies with SR 1.3 (1)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.6)",
        "requirementName": "SR 1.4 – Identifier management",
        "requirementDescription": "The control system must support identifier management for users, groups, roles, or control system interfaces. Identifiers are separate from the privileges they grant within a control system domain or zone (see 6.3, SR 2.1 – Authorization enforcement). User identification for groups, like control room operators, can be role-based, group-based, or device-based. Identification requirements should not impede local emergency actions. Access restrictions may apply with appropriate compensating measures. Specific parts of the control system, such as wireless devices, may require identifiers, while wired devices may not. Identifier management follows local policies and procedures, aligning with IEC 62443-2-1.",
        "requirementSatisfaction": "Requirement Enhancements: None Security Levels: For the four SL levels related to SR 1.4 (Identifier management): • SL-C(IAC, control system) 1: Complies with SR 1.4 • SL-C(IAC, control system) 2: Complies with SR 1.4 • SL-C(IAC, control system) 3: Complies with SR 1.4 • SL-C(IAC, control system) 4: Complies with SR 1.4"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.7)",
        "requirementName": "SR 1.5 – Authenticator management",
        "requirementDescription": "The control system must manage authenticators, which include tokens, keys, biometrics, passwords, and more, to verify identity. Authenticators have a lifecycle, with initial authenticators like passwords for new accounts. Changing default passwords is crucial for security. Authenticators must be protected from unauthorized disclosure and modification during storage and transmission. Encryption or hashing helps secure passwords and keys. Hardware modules like trusted platforms enhance protection. Authenticator management follows security policies, considering defaults, refresh periods, and safeguards. Security measures must not compromise control, especially in highly available systems. Additional requirements are detailed in SR 1.7 (Password-based authentication strength), SR 1.8 (PKI certificates), and SR 1.9 (Public key authentication strength).",
        "requirementSatisfaction": "Requirement Enhancements: • SR 1.5 RE 1 – Hardware security for software process identity credentials: The control system must protect software processes and device user authenticators through hardware mechanisms. Security Levels: The requirements for the four SL levels that relate to SR 1.5 – Authenticator management are: • SL-C(IAC, control system) 1: SR 1.5 • SL-C(IAC, control system) 2: SR 1.5 • SL-C(IAC, control system) 3: SR 1.5 (1) • SL-C(IAC, control system) 4: SR 1.5 (1)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.8)",
        "requirementName": "SR 1.6 – Wireless access management",
        "requirementDescription": "The control system must uniquely identify and authenticate all users involved in wireless communication, including humans, software processes, and devices. Wireless communication follows the same security requirements as other methods but presents unique challenges due to the absence of physical security measures. In some cases, wireless communication may require a higher security level compared to wired protocols in the same context. Wireless technologies include options like microwave, satellite, packet radio, IEEE 802.11x, IEEE 802.15.4 (ZigBee, WirelessHART, ISA-100.11a), IEEE 802.15.1 (Bluetooth), wireless LAN mobile routers, mobile phones with tethering, and various infrared technologies.",
        "requirementSatisfaction": "Requirement Enhancements: • SR 1.6 RE 1 – Unique identification and authentication: The control system shall provide the capability to uniquely identify and authenticate all users (humans, software processes, or devices) in wireless communication. Security Levels: The requirements for the four SL levels related to SR 1.6 – Wireless access management are: • SL-C(IAC, control system) 1: SR 1.6 • SL-C(IAC, control system) 2: SR 1.6 (1) • SL-C(IAC, control system) 3: SR 1.6 (1) • SL-C(IAC, control system) 4: SR 1.6 (1)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.9)",
        "requirementName": "SR 1.7 – Strength of password-based authentication",
        "requirementDescription": "For password-based authentication in control systems, the system must support customizable password strength requirements, such as minimum length, composition, and password history. Passwords should not be hardcoded, and mechanisms must exist to protect against dictionary attacks and account lockouts. Strong password policies enhance security, requiring compliance with organizational policies and consideration of the environment and user convenience. The control system must ensure passwords are changed periodically and employ strong encryption and hashing to protect stored and transmitted passwords.",
        "requirementSatisfaction": "Requirement Enhancements: • SR 1.7 RE 1 – Increased password strength: The control system must increase password strength, including longer lengths, complexity requirements, and no default passwords. • SR 1.7 RE 2 – Password expiration: The control system must enforce password expiration policies. • SR 1.7 RE 3 – Password history: The control system must ensure passwords are not reused within a specified period. Security Levels: The requirements for the four SL levels related to SR 1.7 – Strength of password-based authentication are: • SL-C(IAC, control system) 1: SR 1.7 • SL-C(IAC, control system) 2: SR 1.7 (1) • SL-C(IAC, control system) 3: SR 1.7 (1) (2) • SL-C(IAC, control system) 4: SR 1.7 (1) (2) (3)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.10)",
        "requirementName": "SR 1.8 – Public key infrastructure certificates",
        "requirementDescription": "The control system must use Public Key Infrastructure (PKI) certificates for authentication where applicable, ensuring the authenticity of users, devices, and processes. Certificates must follow standard formats and be managed throughout their lifecycle, including issuance, renewal, revocation, and storage. Certificate authorities (CAs) or similar trusted entities must issue these certificates, which are essential for secure communication and establishing trust relationships. The system must support methods for verifying certificate validity, such as OCSP or CRLs, and ensure certificates are properly protected.",
        "requirementSatisfaction": "Requirement Enhancements: • SR 1.8 RE 1 – Certificate validity checking: The control system must support methods for checking the validity of PKI certificates, such as OCSP or CRLs. Security Levels: The requirements for the four SL levels related to SR 1.8 – Public key infrastructure certificates are: • SL-C(IAC, control system) 1: SR 1.8 • SL-C(IAC, control system) 2: SR 1.8 (1) • SL-C(IAC, control system) 3: SR 1.8 (1) • SL-C(IAC, control system) 4: SR 1.8 (1)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.11)",
        "requirementName": "SR 1.9 – Strength of public key authentication",
        "requirementDescription": "The control system must support strong public key-based authentication methods to verify the identity of users, devices, and software processes. This involves using cryptographic keys of sufficient length and strength to prevent unauthorized access. The system must enforce policies for key generation, distribution, storage, and usage, ensuring compliance with industry standards and best practices. Regular updates and audits of key management practices are necessary to maintain security. Public key authentication enhances security through non-repudiation and secure key exchange mechanisms.",
        "requirementSatisfaction": "Requirement Enhancements: • SR 1.9 RE 1 – Stronger public key authentication: The control system must enforce stronger public key authentication methods, ensuring compliance with current cryptographic standards. Security Levels: The requirements for the four SL levels related to SR 1.9 – Strength of public key authentication are: • SL-C(IAC, control system) 1: SR 1.9 • SL-C(IAC, control system) 2: SR 1.9 (1) • SL-C(IAC, control system) 3: SR 1.9 (1) • SL-C(IAC, control system) 4: SR 1.9 (1)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.12)",
        "requirementName": "SR 1.10 – Authenticator feedback",
        "requirementDescription": "The control system must hide authentication feedback during the authentication process to prevent unauthorized access. This can involve displaying asterisks or random characters instead of passwords or other feedback. The system should avoid providing clues about authentication failure reasons, such as 'unknown username'.",
        "requirementSatisfaction": "Requirement Enhancements: None Security Levels: The requirements for the four SL levels that relate to SR 1.10 – Authenticator feedback are: • SL-C(IAC, control system) 1: SR 1.10 • SL-C(IAC, control system) 2: SR 1.10 • SL-C(IAC, control system) 3: SR 1.10 • SL-C(IAC, control system) 4: SR 1.10"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.13)",
        "requirementName": "SR 1.11 – Unsuccessful login attempts",
        "requirementDescription": "The control system must limit consecutive invalid access attempts by any user (human, software process, or device) within a configurable time frame, denying access for a set period or until unlocked by an administrator. Interactive logons are not allowed for system accounts running critical services or servers. To prevent potential denial of service, there may be limits on consecutive invalid access attempts. Access attempts may reset to zero after a specified time, allowing legitimate users to regain access with the correct credentials. Exceptions should be made for control system operator workstations and nodes in emergency situations requiring immediate operator responses. Lockout mechanisms must ensure uninterrupted operations to avoid system failure or harm to personnel. Allowing interactive logins for critical service accounts could lead to denial of service or other issues.",
        "requirementSatisfaction": "Requirement Enhancements: None Security Levels: The requirements for the four SL levels that relate to SR 1.11 – Unsuccessful login attempts are: • SL-C(IAC, control system) 1: SR 1.11 • SL-C(IAC, control system) 2: SR 1.11 • SL-C(IAC, control system) 3: SR 1.11 • SL-C(IAC, control system) 4: SR 1.11"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.14)",
        "requirementName": "SR 1.12 – System use notification",
        "requirementDescription": "The control system must display a configurable system use notification message before authentication, editable by authorized personnel. System use notifications, often presented as warning banners, serve primarily for legal purposes, aiding in prosecution and proof of intentional breaches rather than directly improving IACS security. These notifications can be shown during login but don’t cover remote login situations. The notification message may include information like specifying access to a specific control system, warning of monitoring, recording, and auditing of system usage, prohibiting unauthorized use with potential penalties, and implying consent to monitoring and recording by using the system.",
        "requirementSatisfaction": "Requirement Enhancements: None Security Levels: The requirements for the four SL levels that relate to SR 1.12 – System use notification are: • SL-C(IAC, control system) 1: SR 1.12 • SL-C(IAC, control system) 2: SR 1.12 • SL-C(IAC, control system) 3: SR 1.12 • SL-C(IAC, control system) 4: SR 1.12"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§5.15)",
        "requirementName": "SR 1.13 – Access via untrusted networks",
        "requirementDescription": "The control system must monitor and manage access from untrusted networks, including remote methods like dial-up, broadband, wireless, and connections from non-control system office networks. Dial-up access should be restricted based on the request source, safeguards should be in place to prevent unauthorized or subverted connections (e.g., through VPNs technology), and access to remote control system components (e.g., control centers and field locations) should only be allowed when necessary and authenticated. Multifactor authentication for remote user access may be mandated by security policies.",
        "requirementSatisfaction": "Requirement Enhancements: SR 1.13 RE 1 – Explicit access request approval: The control system shall provide the capability to deny access requests via untrusted networks unless approved by an assigned role. Security Levels: The requirements for the four SL levels that relate to SR 1.13 – Access via untrusted networks are: • SL-C(IAC, control system) 1: SR 1.13 • SL-C(IAC, control system) 2: SR 1.13 (1) • SL-C(IAC, control system) 3: SR 1.13 (1) • SL-C(IAC, control system) 4: SR 1.13 (1)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§6.3)",
        "requirementName": "SR 2.1 – Authorization enforcement",
        "requirementDescription": "The control system enforces user authorizations based on principles like segregation of duties and least privilege. It uses control policies and access enforcement mechanisms to manage interactions between users (humans, software, devices) and assets (devices, files, records, software, programs, domains). After verifying user identity, it checks if requested operations comply with security policies. For example, in role-based access control, it verifies the user’s roles and privileges before allowing or denying the operation. This ensures proper segregation of duties and least privilege without adversely affecting system performance. Qualified and authorized individuals handle control system component changes, including upgrades and modifications, due to their significant impact on overall security.",
        "requirementSatisfaction": "Requirement Enhancements:\n• SR 2.1 RE 1 – requires enforcing user authorizations for all interfaces to ensure duty segregation and least privilege.\n• SR 2.1 RE 2 – suggests allowing authorized users or roles to define and modify permission-to-role mappings for human users.\n• SR 2.1 RE 3 – mandates support for supervisor manual override of current human user authorizations for a configurable time or event sequence.\n• SR 2.1 RE 4 – recommends enabling dual approval for actions with the potential to seriously impact industrial processes.\nSecurity Levels:\n• SL-C(UC, control system) 1: Complies with SR 2.1.\n• SL-C(UC, control system) 2: Complies with SR 2.1 (1) and (2).\n• SL-C(UC, control system) 3: Complies with SR 2.1 (1), (2), and (3).\n• SL-C(UC, control system) 4: Complies with SR 2.1 (1), (2), (3), and (4)."
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§6.4)",
        "requirementName": "SR 2.2 – Wireless use control",
        "requirementDescription": "The control system must apply industry security practices to enforce wireless connectivity restrictions, covering various technologies like microwave, satellite, IEEE 802.11x, IEEE 802.15.4 (e.g., ZigBee and WirelessHART), IEEE 802.15.1 (Bluetooth), wireless LAN, mobile routers, tethering-enabled mobile phones, and infrared. These technologies must adhere to the same IACS security requirements as other communication methods. Depending on risk analysis and regulations, wireless IACS components may require stronger controls compared to wired systems in the same context, potentially warranting a higher security level.",
        "requirementSatisfaction": "Requirement Enhancement: SR 2.2 RE 1 – Detect Unauthorized Wireless Devices: The control system must identify and report unauthorized wireless devices operating within its physical environment.\nSecurity Levels:\n• SL-C(UC, control system) 1: Complies with SR 2.2.\n• SL-C(UC, control system) 2: Complies with SR 2.2.\n• SL-C(UC, control system) 3: Complies with SR 2.2 (1).\n• SL-C(UC, control system) 4: Complies with SR 2.2 (1)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§6.5)",
        "requirementName": "SR 2.3 – Use control for portable and mobile devices",
        "requirementDescription": "The control system must automatically enforce usage restrictions, which may include blocking portable and mobile device usage, requiring context-specific authorization, and limiting code and data transfer to/from these devices. Specific controls are necessary due to the potential risks associated with these devices. Security policies and procedures may dictate restrictions on specific device functions and activities. For guidance on allowing portable and mobile device usage, consult IEC 62443-2-1. Details about protecting information on these devices, including data confidentiality and integrity during storage and transmission outside controlled areas, can be found in Clause 8, Foundational Requirements (FR) 4.",
        "requirementSatisfaction": "Requirement Enhancement: SR 2.3 RE 1 – Verify Portable and Mobile Device Security: The control system must confirm that portable and mobile devices attempting to connect to a zone meet the security requirements of that zone.\nSecurity Levels:\n• SL-C(UC, control system) 1: Complies with SR 2.3.\n• SL-C(UC, control system) 2: Complies with SR 2.3.\n• SL-C(UC, control system) 3: Complies with SR 2.3 (1).\n• SL-C(UC, control system) 4: Complies with SR 2.3 (1)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§6.6)",
        "requirementName": "SR 2.4 – Mobile code",
        "requirementDescription": "The control system must enforce restrictions on mobile code technologies to protect the system. These restrictions can include blocking the execution of mobile code, requiring proper authentication and authorization for the code’s origin, limiting the transfer of mobile code to/from the control system, and monitoring the usage of mobile code. Mobile code technologies include Java, JavaScript, ActiveX, PDF, Postscript, Shockwave, Flash, VBScript, and others. These usage restrictions apply to both selecting and using mobile code on servers and workstations. Control procedures should prevent unacceptable mobile codes from entering the system. For instance, direct mobile code exchanges with the control system should be disallowed while allowing controlled environments managed by IACS personnel to handle them.",
        "requirementSatisfaction": "Requirement Enhancement: SR 2.4 RE 1 – Mobile Code Integrity Check: The control system must verify the integrity of mobile code before allowing its execution.\nSecurity Levels:\n• SL-C(UC, control system) 1: Complies with SR 2.4.\n• SL-C(UC, control system) 2: Complies with SR 2.4.\n• SL-C(UC, control system) 3: Complies with SR 2.4 (1).\n• SL-C(UC, control system) 4: Complies with SR 2.4 (1)"
    },
    {
        "requirementStandard": "IEC 62443 3-3 (§6.7)",
        "requirementName": "SR 2.5 – Session lock",
        "requirementDescription": "The control system must support session locks, which can be triggered by user inactivity or initiated manually. These locks remain in effect until the initiating user or another authorized user regains access through proper identification and authentication. Session locks can be used to secure specific workstations or nodes. They may activate automatically after a defined period, with some exceptions for control system operator workstations required for immediate emergency responses. It’s important to emphasize that session locks should not be a replacement for proper logout procedures. When session locks cannot be implemented, the responsible entity should introduce compensating measures, such as enhancing physical security, personnel security, and auditing procedures.",
        "requirementSatisfaction": "Requirement Enhancement: None.\nSecurity Level:\nThe requirements for the four SL levels that relate to SR 2.5 – Session lock are:\n• SL-C(UC, control system) 1: SR 2.5\n• SL-C(UC, control system) 2: SR 2.5\n• SL-C(UC, control system) 3: SR 2.5\n• SL-C(UC, control system) 4: SR 2.5"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§6.8)",
        "requirementName": "SR 2.6 – Remote session termination",
        "requirementDescription": "The control system must be able to end a remote session either automatically after a user-configured period of inactivity or through manual user termination. Remote sessions are initiated when accessing the control system across an asset owner-defined zone boundary, determined by their risk assessment. This requirement may pertain specifically to sessions used for control system monitoring and maintenance (not critical operations) based on risk assessment and security policies. Note that some control systems or components may not support session termination.",
        "requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level:\nThe requirements for the four SL levels that relate to SR 2.6 – Remote session termination are:\n• SL-C(UC, control system) 1: Not Selected\n• SL-C(UC, control system) 2: SR 2.6\n• SL-C(UC, control system) 3: SR 2.6\n• SL-C(UC, control system) 4: SR 2.6"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§6.9)",
        "requirementName": "SR 2.7 – Concurrent session control",
        "requirementDescription": "The control system must restrict the concurrent sessions per interface for each user (human, software process, or device) to a user-defined maximum. This limitation is crucial to prevent resource-starvation DoS attacks. There’s a balance between potentially blocking a specific user and safeguarding all users and services from resource depletion within the control system. Guidance from the product supplier or system integrator is often necessary to determine the appropriate value for the maximum number of sessions.",
        "requirementSatisfaction": "Requirement enhancement: None.\nThe requirements for the four SL levels that relate to SR 2.7 – Concurrent session control are:\n• SL-C(UC, control system) 1: Not Selected\n• SL-C(UC, control system) 2: Not Selected\n• SL-C(UC, control system) 3: SR 2.7\n• SL-C(UC, control system) 4: SR 2.7"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§6.10)",
        "requirementName": "SR 2.8 – Auditable events",
        "requirementDescription": "The control system must generate security-related audit records across various categories, including access control, request errors, OS and control system events, backup, configuration changes, reconnaissance activity, and audit logs. These records should include essential details like the timestamp, source (device, software process, or user), category, type, event ID, and event result. This requirement ensures that significant security events are recorded, while acknowledging the potential performance impact of auditing. The security audit function often collaborates with network health monitoring, which may be located in a different zone. Recognized checklists and guides can aid in identifying auditable events. Security policies should define the events necessary for post-incident investigations and evaluate the effectiveness of security mechanisms. It’s important to note that event recording aligns with specific security requirements at each system level, with different events being recorded in various control system components or detected by specialized monitors like IDS or Intrusion Prevention System (IPS).",
        "requirementSatisfaction": "Requirement Enhancement: SR 2.8 RE 1 – Centralized System-Wide Audit Trail: The control system must centrally manage audit events and consolidate audit records from various components into a system-wide, time-correlated audit trail. It should also support the export of these records in standard formats for analysis using commercial log analysis tools, such as SIEM.\nSecurity Levels:\n• SL-C(UC, control system) 1-2: Complies with SR 2.8.\n• SL-C(UC, control system) 3-4: Complies with SR 2.8 (1)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§6.11)",
        "requirementName": "SR 2.9 – Audit storage capacity",
        "requirementDescription": "The control system must provide sufficient storage for audit records in compliance with established log management and system configuration recommendations. Additionally, mechanisms should be in place to prevent exceeding this storage capacity. The system should account for necessary storage based on factors such as retention policies, auditing requirements, and online processing needs. Reference documents like NIST Special Publication (SP) 800-92 should be consulted. Storage capacity should align with the retention duration mandated by relevant policies, regulations, or business requirements.",
        "requirementSatisfaction": "Requirement Enhancement: SR 2.9 RE 1 – Capacity Warning: The control system must be able to issue a warning when the audit record storage volume reaches a user-defined percentage of its maximum capacity.\nSecurity Levels:\n• SL-C(UC, control system) 1-2: Complies with SR 2.9.\n• SL-C(UC, control system) 3-4: Complies with SR 2.9 (1)."
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§6.12)",
        "requirementName": "SR 2.10 – Response to audit processing failures",
        "requirementDescription": "The control system must be capable of alerting personnel and mitigating the loss of critical services and functions in the event of an audit processing failure. It should follow industry best practices for addressing such failures. Audit generation occurs at the event source, while audit processing involves record transmission, potential enhancements (e.g., timestamp addition), and storage. Failures in audit processing can stem from software or hardware issues, capture mechanism problems, or reaching storage capacity. When determining response strategies, consider guidelines like NIST SP800-92. It’s essential to acknowledge that addressing exceeded storage capacity may entail overwriting the oldest audit records or temporarily suspending audit log generation, which could result in the loss of valuable forensic data.",
        "requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to SR 2.10 – Response to audit processing failures are:\n• SL-C(UC, control system) 1: SR 2.10\n• SL-C(UC, control system) 2: SR 2.10\n• SL-C(UC, control system) 3: SR 2.10\n• SL-C(UC, control system) 4: SR 2.10"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§6.13)",
        "requirementName": "SR 2.11 – Timestamps",
        "requirementDescription": "The control system must use timestamps (date and time) in its audit records, generated using internal system clocks. When system-wide time synchronization is lacking, known offsets may be required to analyze event sequences. Synchronizing internally generated audit records with external events may necessitate alignment with a trusted external time source, such as Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), or Galileo. Safeguarding the time source against unauthorized changes is crucial.",
        "requirementSatisfaction": "Requirement Enhancements:\n• SR 2.11 RE 1 – Internal Clock Synchronization: The control system must synchronize its internal system clocks at a user-defined frequency.\n• SR 2.11 RE 2 – Time Source Protection: The time source must be safeguarded against unauthorized alterations and trigger an audit event when altered.\nSecurity Levels:\n• SL-C(UC, control system) 2: Complies with SR 2.11.\n• SL-C(UC, control system) 3-4: Complies with SR 2.11 (1) (2)."
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§6.14)",
        "requirementName": "SR 2.12 – Non-repudiation",
        "requirementDescription": "The control system must enable non-repudiation, verifying that specific human users performed actions like operator tasks, configuration changes, document creation, message sending, information approval, and message receipt. Non-repudiation prevents users from falsely denying their actions, authors from disavowing document creation, senders from denying message transmission, and receivers from claiming non-receipt. This assurance is achieved through methods like digital signatures, digital message receipts, and timestamps.",
        "requirementSatisfaction": "Requirement Enhancement: SR 2.12 RE 1 – Non-Repudiation for All Users: The control system must be able to confirm whether a given user (human, software process, or device) performed a specific action.\nSecurity levels: The requirements for the four SL levels that relate to SR 2.12 – Non-repudiation are:\n• SL-C(UC, control system) 1: Not Selected\n• SL-C(UC, control system) 2: Not Selected\n• SL-C(UC, control system) 3: SR 2.12\n• SL-C(UC, control system) 4: SR 2.12 (1)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§7.3)",
        "requirementName": "SR 3.1 – Communication integrity",
        "requirementDescription": "The control system must protect information integrity during data transmission, selecting methods based on the network type and context. Physical access control is adequate for smaller point-to-point networks if endpoint integrity is maintained. Larger distributed networks may need alternative security measures, particularly if commercial communication services are used, posing legal constraints. Harsh industrial environments, with conditions like particulates, liquids, vibrations, gases, radiation, and EMI, can disrupt communication. To counter this, infrastructure design should consider measures like using sealed connectors (e.g., RJ-45 or M12) in challenging environments, deploying different cable jackets for durability, using M12 connectors in vibration-prone areas, and employing shielded cables in radiation or EMI-prone zones. For wireless networking, a wireless spectrum analysis can determine feasibility.",
        "requirementSatisfaction": "SR 3.1 RE 1 – Cryptographic integrity protection: The control system must use cryptographic mechanisms to detect changes in transmitted information.\nSecurity Level: The requirements for the four SL levels that relate to SR 3.1 – Communication integrity are:\n• SL-C(SI, control system) 1: SR 3.1\n• SL-C(SI, control system) 2: SR 3.1\n• SL-C(SI, control system) 3: SR 3.1 (1)\n• SL-C(SI, control system) 4: SR 3.1 (1)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§7.4)",
        "requirementName": "SR 3.2 – Malicious code protection",
        "requirementDescription": "The control system must employ protective measures against malicious code and unauthorized software, with support for updates. These measures aim to prevent, detect, and mitigate malicious code (e.g., viruses, worms, Trojans, spyware) from various sources like emails, internet access, removable media, and infected devices. Detection involves checking for unauthorized changes in application files using methods like binary integrity monitoring, hashing, and digital signatures. Mitigation may include cleaning, quarantining, and limiting communications. Preventive strategies comprise blacklisting, whitelisting, sandboxing, and using platform-specific features like firmware updates, No Execute (NX) bit, Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), and mandatory access controls. Refer to 10.4, SR 6.2 for additional monitoring requirements. These measures apply to host elements, network-based systems, and control system components.",
        "requirementSatisfaction": "Requirement Enhancement:\n• SR 3.2 RE 1 – Malicious code protection on entry and exit points. The control system shall provide the capability to employ malicious code protection mechanisms at all entry and exit points.\n• SR 3.2 RE 2 – Central management and reporting for malicious code protection: The control system shall provide the capability to manage malicious code protection mechanisms.\nSecurity Level: The requirements for the four SL levels that relate to SR 3.2 – Malicious Code Protection are:\n• SL-C(SI, control system) 1: SR 3.2\n• SL-C(SI, control system) 2: SR 3.2 (1)\n• SL-C(SI, control system) 3: SR 3.2 (1) (2)\n• SL-C(SI, control system) 4: SR 3.2 (1) (2)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§7.5)",
        "requirementName": "SR 3.3 – Security functionality verification",
        "requirementDescription": "The control system must validate security functions during FAT, SAT, and scheduled maintenance, covering all security requirements. Product suppliers and system integrators should guide security control testing, while asset owners should assess the impact on regular operations. Examples of security verification include:\n• Testing antivirus measures with European Institute for Computer Antivirus Research (EICAR) on the control system file system.\n• Verifying identification, authentication, and use control through unauthorized access attempts.\n• Evaluating IDSs by configuring a rule for detecting non-malicious traffic and introducing such traffic.\n• Ensuring audit logging complies with policies and prevents disabling.",
        "requirementSatisfaction": "Requirement enhancement:\n• SR 3.3 RE 1 – Automated verification: The control system must use automated mechanisms for security verification during FAT, SAT, and scheduled maintenance.\n• SR 3.3 RE 2 – Verification during normal operation: The control system should verify security functions during regular operations.\nSecurity Levels:\n• SL-C(SI, control system) 1: SR 3.3\n• SL-C(SI, control system) 2: SR 3.3\n• SL-C(SI, control system) 3: SR 3.3 (1)\n• SL-C(SI, control system) 4: SR 3.3 (1) (2)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§7.6)",
        "requirementName": "SR 3.4 – Software and information integrity",
        "requirementDescription": "The control system must detect, record, report, and protect against unauthorized software and information changes. Unauthorized changes refer to those made by entities without the necessary privileges. This complements requirements in FRs 1 and 2, focusing on role, privilege, and usage pattern enforcement. Integrity verification methods, like cryptographic hashes, are used to identify, record, report, and protect against tampering with software and information. These mechanisms help monitor field devices for configuration changes and detect security breaches, including unauthorized alterations.",
        "requirementSatisfaction": "Requirement enhancement: SR 3.4 RE 1 – Automated Integrity Violation Notifications: The control system must use automated tools to notify a configurable set of recipients when integrity verification detects discrepancies.\nSecurity Levels: The requirements for the four SL levels related to SR 3.4 – Software and Information Integrity are:\n• SL-C(SI, control system) 1: SR 3.4\n• SL-C(SI, control system) 2: SR 3.4\n• SL-C(SI, control system) 3: SR 3.4 (1)\n• SL-C(SI, control system) 4: SR 3.4 (1)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§7.8)",
        "requirementName": "SR 3.6 – Deterministic output",
        "requirementDescription": "The control system must be able to set outputs to a predefined state in case of a cyberattack. This ensures the predictability of control system outputs during cyber threats, which is essential for operational integrity. The system should ideally continue normal operation during an attack, but if it can’t, it should transition to a predetermined state. This state can be one of three user-configurable options:\n• Unpowered: The outputs switch to an unpowered state.\n• Hold: The outputs maintain the last-known good value.\n• Fixed: The outputs assume a fixed value determined by the asset owner or the application.",
        "requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to SR 3.6 – Deterministic output are:\n• SR-C(SI, control system) 1: SR 3.6\n• SR-C(SI, control system) 2: SR 3.6\n• SR-C(SI, control system) 3: SR 3.6\n• SR-C(SI, control system) 4: SR 3.6"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§7.9)",
        "requirementName": "SR 3.7 – Error handling",
        "requirementDescription": "The control system must handle error conditions effectively, providing information for resolution without revealing sensitive details unless necessary for quick troubleshooting. Error messages should be designed by the product supplier or system integrator to balance usefulness and security. They should provide timely and helpful information while avoiding disclosing potentially harmful details that attackers could exploit. Since it may not always be evident whether an error relates to a security event, all error messages should be available during incident response. Releasing such information should be justified by the need for swift error resolution. Following guidelines like those in the OWASP Code Review Guide is recommended.",
        "requirementSatisfaction": "Requirement enhancement: None.\nSecurity Levels: The requirements for the four SL levels related to SR 3.7 – Error handling are:\n• SL-C(SI, control system) 1: Not Selected\n• SL-C(SI, control system) 2: SR 3.7\n• SL-C(SI, control system) 3: SR 3.7\n• SL-C(SI, control system) 4: SR 3.7"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§7.10)",
        "requirementName": "SR 3.8 – Session integrity",
        "requirementDescription": "The control system must safeguard session integrity by rejecting invalid session IDs. This helps ensure secure communication, preventing threats like man-in-the-middle attacks, session hijacking, data insertion, and replay attacks. The use of session integrity mechanisms should be weighed carefully, particularly in real-time communication scenarios",
        "requirementSatisfaction": "Requirement Enhancement:\n• SR 3.8 RE 1 – Invalidate session IDs after session termination.\n• SR 3.8 RE 2 – Generate unique session IDs and treat unexpected ones as invalid.\n• SR 3.8 RE 3 – Create unique session IDs with accepted randomness sources.\nSecurity Levels:\n• SL-C(SI, control system) 1: Not Selected\n• SL-C(SI, control system) 2: SR 3.8\n• SL-C(SI, control system) 3: SR 3.8 (1) (2)\n• SL-C(SI, control system) 4: SR 3.8 (1) (2) (3)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§7.11)",
        "requirementName": "SR 3.9 – Protection of audit information",
        "requirementDescription": "The control system must safeguard audit information and tools (if present) from unauthorized access, changes, and deletions. Audit information encompasses all necessary data, such as records, settings, and reports, essential for auditing control system activity. Protecting against unauthorized modifications and deletions may involve storing audit data on hardware-enforced write-once media.",
        "requirementSatisfaction": "Requirement enhancement: SR 3.9 RE 1 – Audit records on write-once media: The control system shall provide the capability to produce audit records on hardware-enforced write-once media.\nSecurity Level: The requirements for the four SL levels that relate to SR 3.9 – Protection of audit information are:\n• SL-C(SI, control system) 1: Not selected\n• SL-C(SI, control system) 2: SR 3.9\n• SL-C(SI, control system) 3: SR 3.9\n• SL-C(SI, control system) 4: SR 3.9 (1)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§8.3)",
        "requirementName": "SR 4.1 – Information confidentiality",
        "requirementDescription": "The control system must protect information confidentiality through methods like explicit read authorizations, physical security, encryption, and compartmentalization. These protective measures should not compromise system performance or the ability to recover from attacks. The decision to protect specific information depends on the organization’s needs and is typically configured with explicit read authorizations in the control system. If supported, the system should provide corresponding protection, with encryption strength determined by information sensitivity and standards. Confidentiality concerns also apply to network configuration data, especially in exposed information transfers. Communications with external service providers may require compensatory measures or risk acceptance. This confidentiality requirement extends to portable and mobile devices, including engineering laptops and USB sticks. Authentication information, such as passwords, must always be treated as confidential and should never be sent in plain text.",
        "requirementSatisfaction": "Requirement enhancement:\n• SR 4.1 RE 1 – Protection of information confidentiality at rest or in transit across untrusted networks.\n• SR 4.1 RE 2 – Protection of information confidentiality across zone boundaries.\nSecurity Level: The requirements for the four SL levels that relate to SR 4.1 – Information confidentiality are:\n• SL-C(DC, control system) 1: SR 4.1\n• SL-C(DC, control system) 2: SR 4.1 (1)\n• SL-C(DC, control system) 3: SR 4.1 (1)\n• SL-C(DC, control system) 4: SR 4.1 (1) (2)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§8.4)",
        "requirementName": "SR 4.2 – Information persistence",
        "requirementDescription": "The control system must securely remove all information from components that are taken out of service or decommissioned. This process should prevent the inadvertent release of sensitive information, such as cryptographic data or 'join keys,' stored in non-volatile storage. It ensures that data generated by user actions or software processes is not disclosed to unauthorized users or roles, maintaining confidentiality even when shared resources are returned to the control system.",
        "requirementSatisfaction": "Requirement enhancement: SR 4.2 RE 1 – Purging of shared memory resources: The control system shall provide the capability to prevent unauthorized and unintended information transfer via volatile shared memory resources.\nSecurity Level: The requirements for the four SL levels that relate to SR 4.2 – Information persistence are:\n• SL-C(DC, control system) 1: Not Selected\n• SL-C(DC, control system) 2: SR 4.2\n• SL-C(DC, control system) 3: SR 4.2 (1)\n• SL-C(DC, control system) 4: SR 4.2 (1)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§8.5)",
        "requirementName": "SR 4.3 – Use of cryptography",
        "requirementDescription": "If cryptography is required, the control system must use industry-standard cryptographic algorithms, key sizes, and key management methods. The choice of cryptographic protection should align with the information’s value, potential consequences of a breach, confidentiality duration, and operational limitations, whether for data at rest or in transit, including backups. The product supplier should document key establishment and management practices, using established encryption and hash algorithms like AES and SHA series, with standard key sizes. Key generation should rely on a secure random number generator. Security policies must cover aspects like key changes, destruction, distribution, and encryption key backup, following recognized standards such as NIST SP800-57 and ISO/IEC 19790. This requirement, along with SR 1.8 – PKI certificates, may apply to meeting other standards in this document.",
        "requirementSatisfaction": "Requirement enhancement: None.\nSecurity Level: The requirements for the four SL levels that relate to SR 4.3 – Use of cryptography are:\n• SL-C(DC, control system) 1: SR 4.3\n• SL-C(DC, control system) 2: SR 4.3\n• SL-C(DC, control system) 3: SR 4.3\n• SL-C(DC, control system) 4: SR 4.3"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§9.3)",
        "requirementName": "SR 5.1 – Network segmentation",
        "requirementDescription": "The control system should employ network segmentation by logically separating control system networks from non-control system networks. It can further segment critical control system networks from other control system networks. Network segmentation serves multiple purposes, including enhancing cybersecurity, performance, reliability, and overall protection. It restricts network traffic, adding layers of defense to various segments, especially for critical control and safety-related systems. Internet access from the control system should be based on operational justifications. The level of protection and its effectiveness depend on network architecture and design choices. Logical segmentation offers some protection, but physical segmentation provides higher security, albeit at a greater cost. These considerations should be part of network design (see IEC 62443-2-1). In the event of an incident, isolating network segments may be necessary while ensuring essential operations. Critical control systems might need complete isolation from other networks.",
        "requirementSatisfaction": "Network Segmentation Enhancement:\n• SR 5.1 RE 1 – Physically separate control system networks and segregate critical from non-critical control system networks.\n• SR 5.1 RE 2 – Enable the control system to provide network services to control system networks without connecting to non-control system networks.\n• SR 5.1 RE 3 – Logically and physically isolate critical control system networks from non-critical control system networks.\nSecurity Level: These enhancements align with SR 5.1 – Network Segmentation, with varying requirements across different security levels:\n• SL-C(RDF, control system) 1: SR 5.1\n• SL-C(RDF, control system) 2: SR 5.1 (1)\n• SL-C(RDF, control system) 3: SR 5.1 (1) (2)\n• SL-C(RDF, control system) 4: SR 5.1 (1) (2) (3)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§9.4)",
        "requirementName": "SR 5.2 – Zone boundary protection",
        "requirementDescription": "The control system must monitor and manage communications at zone boundaries to enforce the compartmentalization specified in the risk-based zones and conduits model. External network or control system connections should be established through managed interfaces, utilizing boundary protection devices like proxies, gateways, routers, firewalls, unidirectional gateways, guards, and encrypted tunnels. An effective architecture, such as using firewalls to secure application gateways in a DMZ, should be implemented. Alternate processing sites for high-impact control systems must maintain the same level of security as the primary site. For defense-in-depth, high-impact control systems should be divided into separate zones using conduits to restrict or prevent network access in alignment with security policies, procedures, and risk assessments, with guidance from the SL-T(system) categorization.",
        "requirementSatisfaction": "Requirement enhancement:\n• SR 5.2 RE 1 – The control system should employ a default deny approach for network traffic, permitting it only in exceptional cases.\n• SR 5.2 RE 2 – The control system must be capable of isolating itself from all external communication, often referred to as ’island mode.’\n• SR 5.2 RE 3 – In the event of operational failures in boundary protection mechanisms, the control system should be able to block all communication through its boundary. This ’fail close’ functionality should not disrupt the operation of a Safety Instrumented System (SIS) or other safety-related functions.\nSecurity Level: The requirements for the four SL levels related to SR 5.2 – Zone Boundary Protection are:\n• SL-C(RDF, control system) 1: SR 5.2\n• SL-C(RDF, control system) 2: SR 5.2 (1)\n• SL-C(RDF, control system) 3: SR 5.2 (1) (2) (3)\n• SL-C(RDF, control system) 4: SR 5.2 (1) (2) (3)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§9.5)",
        "requirementName": "SR 5.3 – General-purpose person-to-person communication restrictions",
        "requirementDescription": "The control system must block general-purpose person-to-person messages from external users or systems, such as email systems and social media platforms. These types of messages are typically used for private purposes unrelated to control system operations and can introduce security risks. This requirement may involve implementing various system requirements, including usage restrictions and data flow limitations outlined in this standard. While the control system may permit two-way communication systems internally between servers and workstations, it must restrict external computer communications through email or messaging solutions to outbound messages. These outbound-only messages should be limited to sending system alerts or computer-generated information to external users or systems. Users should not be allowed to attach files or additional information to these messages.",
        "requirementSatisfaction": "Requirement enhancement: SR 5.3 RE 1 – Prohibit all general-purpose person-to-person communications The control system shall provide the capability to prevent both transmission and receipt of general-purpose person-to-person messages. Security Level: The requirements for the four SL levels that relate to SR 5.3 – General-purpose person-to-person communication restrictions are:\n• SL-C(RDF, control system) 1: SR 5.3\n• SL-C(RDF, control system) 2: SR 5.3\n• SL-C(RDF, control system) 3: SR 5.3 (1)\n• SL-C(RDF, control system) 4: SR 5.3 (1)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§9.6)",
        "requirementName": "SR 5.4 – Application partitioning",
        "requirementDescription": "The control system must support data, application, and service partitioning based on criticality to enable the implementation of a zoning model. Partitioning can be achieved physically or logically by using different hardware, central processing units, operating system instances, network addresses, or other suitable methods. Examples of applications and services that may be partitioned include emergency/safety systems, closed-loop control applications, operator workstations, and engineering workstations.",
        "requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to SR 5.4 – Application partitioning are:\n• SL-C(RDF, control system) 1: SR 5.4\n• SL-C(RDF, control system) 2: SR 5.4\n• SL-C(RDF, control system) 3: SR 5.4\n• SL-C(RDF, control system) 4: SR 5.4"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§10.3)",
        "requirementName": "SR 6.1 – Audit log accessibility",
        "requirementDescription": "The control system must allow authorized individuals and/or tools to access audit logs in a read-only mode. Audit logs contain records of system events (see 6.10, SR 2.8 – Auditable events), and access to these logs is essential for tasks like filtering, identifying redundant information, reviewing, and generating reports for post-incident investigations. This access should not modify the original audit records. While manual access (e.g., screen views or printouts) is sufficient for meeting the basic requirement, higher security levels require programmatic access for analysis tools like SIEM. Refer to relevant SRs in Sections 5, 6, and 9 for additional details on creating, protecting, and accessing audit logs.",
        "requirementSatisfaction": "Requirement enhancement: SR 6.1 RE 1 – Programmatic access to audit logs The control system shall provide programmatic access to audit records using an application programming interface (API). Security Level: The requirements for the four SL levels that relate to SR 6.1 – Audit log accessibility are:\n• SL-C(TRE, control system) 1: SR 6.1\n• SL-C(TRE, control system) 2: SR 6.1\n• SL-C(TRE, control system) 3: SR 6.1 (1)\n• SL-C(TRE, control system) 4: SR 6.1 (1)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§10.4)",
        "requirementName": "SR 6.2 - Continuous monitoring",
        "requirementDescription": "The control system must continuously monitor security mechanism performance following standard security industry practices to promptly detect, analyze, and report security breaches. Monitoring employs tools like IDS, IPS, malicious code protection, and network monitoring systems, with adaptability to evolving cyberattacks. Strategic placement of monitoring devices, including perimeter and critical application server farms, is crucial for data collection. Ad hoc monitoring may be needed for specific transactions. Effective reporting mechanisms are essential for timely responses to security incidents. To streamline reporting and manage information effectively, tools like SIEM are used to consolidate individual events into comprehensive reports that provide context. These tools can also track the impact of security changes in the control system (see 6.10, SR 2.8 - Auditable events). Pre-installed forensic tools aid in incident response.",
        "requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to SR 6.2 - Continuous monitoring are:\n• SL-C(TRE, control system) 1: Not Selected\n• SL-C(TRE, control system) 2: SR 6.2\n• SL-C(TRE, control system) 3: SR 6.2\n• SL-C(TRE, control system) 4: SR 6.2"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§11.3)",
        "requirementName": "SR 7.1 - Denial of service protection",
        "requirementDescription": "The control system must have the capability to function in a degraded mode during a DoS event. Various technologies can be employed to mitigate or eliminate the impact of DoS situations. Boundary protection devices can filter certain types of packets to shield internal, trusted network devices from direct DoS effects or limit information flow to unidirectional outbound. It's crucial that a DoS event on the control system does not negatively affect safety-related systems, as mentioned in Clause 4.",
        "requirementSatisfaction": "Requirement enhancement:\n• SR 7.1 RE 1 - Manage Communication Loads: The control system shall be capable of managing communication loads, including rate limiting, to mitigate the impact of information flooding DoS events.\n• SR 7.1 RE 2 - Limit DoS Effects on Other Systems or Networks: The control system shall have the capability to restrict all users (humans, software processes, and devices) from causing DoS events that could affect other control systems or networks.\nSecurity Level: The requirements for the four SL levels related to SR 7.1 - Denial of service protection are:\n• SL-C(RA, control system) 1: SR 7.1\n• SL-C(RA, control system) 2: SR 7.1 (1)\n• SL-C(RA, control system) 3: SR 7.1 (1) (2)\n• SL-C(RA, control system) 4: SR 7.1 (1) (2)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§11.4)",
        "requirementName": "SR 7.2 - Resource management",
        "requirementDescription": "The control system must be able to restrict resource usage by security functions to prevent resource exhaustion. Resource management, such as network segmentation or priority schemes, ensures that lower-priority software processes do not disrupt or delay higher-priority processes. For example, activities like network scans, patching, or antivirus checks can disrupt normal operations and should be mitigated using traffic rate limiting.",
        "requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to SR 7.2 - Resource management are:\n• SL-C(RA, control system) 1: SR 7.2\n• SL-C(RA, control system) 2: SR 7.2\n• SL-C(RA, control system) 3: SR 7.2\n• SL-C(RA, control system) 4: SR 7.2"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§11.5)",
        "requirementName": "SR 7.3 - Control system backup",
        "requirementDescription": "The control system must support the identification and backup of critical files, including user-level and system-level data, without disrupting normal plant operations. Having up-to-date backups is crucial for recovery from system failures or misconfigurations. Automating this process ensures that all necessary files are included, reducing the workload on operators. While not typically needed for control system recovery, backups should also include information required for post-incident forensic activities, such as audit logs (see 10.4, SR 6.2 - Continuous monitoring). If the backups contain sensitive information, encryption should be considered (see 8.5, SR 4.3 - Use of cryptography)",
        "requirementSatisfaction": "Requirement enhancement:\n• SR 7.3 RE 1 - Backup verification The control system shall provide the capability to verify the reliability of backup mechanisms.\n• SR 7.3 RE 2 - Backup automation The control system shall provide the capability to automate the backup function based on a configurable frequency.\nSecurity Level: The requirements for the four SL levels that relate to SR 7.3 - Control system backup are:\n• SL-C(RA, control system) 1: SR 7.3\n• SL-C(RA, control system) 2: SR 7.3 (1)\n• SL-C(RA, control system) 3: SR 7.3 (1) (2)\n• SL-C(RA, control system) 4: SR 7.3 (1) (2)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§11.6)",
        "requirementName": "SR 7.4 - Control system recovery and reconstitution",
        "requirementDescription": "The control system must be capable of recovering and restoring itself to a known secure state following a disruption or failure. This involves resetting all system parameters to secure values, reinstalling security-critical patches, reconfiguring security settings, ensuring documentation and operating procedures are available, reinstalling application and system software with secure configurations, loading data from the latest secure backups, and conducting thorough testing to ensure full functionality.",
        "requirementSatisfaction": "Requirement enhancement: None Security Level: The requirements for the four SL levels that relate to SR 7.4 - Control system recovery and reconstitution are:\n• SL-C(RA, control system) 1: SR 7.4\n• SL-C(RA, control system) 2: SR 7.4\n• SL-C(RA, control system) 3: SR 7.4\n• SL-C(RA, control system) 4: SR 7.4"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§11.7)",
        "requirementName": "SR 7.5 - Emergency power",
        "requirementDescription": "The control system must support seamless transitions to and from an emergency power supply without compromising the existing security state or a documented degraded mode. In some cases, compensating countermeasures, like physical door access control, may be impacted by the loss of the main power supply, and the emergency power supply should cover these related systems. If this isn't feasible, alternative compensating countermeasures may be necessary during emergency situations",
        "requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to SR 7.5 - Emergency power are:\n• SL-C(RA, control system) 1: SR 7.5\n• SL-C(RA, control system) 2: SR 7.5\n• SL-C(RA, control system) 3: SR 7.5\n• SL-C(RA, control system) 4: SR 7.5"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§11.8)",
        "requirementName": "SR 7.6 - Network and security configuration settings",
        "requirementDescription": "The control system must support configuration based on recommended network and security settings provided by the supplier. It should also offer an interface for the existing network and security configuration settings. These settings are the adjustable parameters of control system components. To ensure that any deviations from approved or recommended configuration settings can be detected and corrected, the control system should enable monitoring and control of configuration changes in line with security policies and procedures. For added security, an automated check may be conducted, where an agent collects the current settings and compares them to approved ones",
        "requirementSatisfaction": "Requirement enhancement: SR 7.6 RE 1 - Machine-readable reporting of current security settings The control system 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 SR 7.6 - Network and security configuration settings are:\n• SL-C(RA, control system) 1: SR 7.6\n• SL-C(RA, control system) 2: SR 7.6\n• SL-C(RA, control system) 3: SR 7.6 (1)\n• SL-C(RA, control system) 4: SR 7.6 (1)"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§11.9)",
        "requirementName": "SR 7.7 - Least functionality",
        "requirementDescription": "The control system must have the ability to prohibit or restrict the use of unnecessary functions, ports, protocols, and services. Control systems offer various functions and services, but not all of them are essential for core operations. Consequently, functions beyond a baseline configuration should be disabled by default. Furthermore, it's often more secure to limit the services provided by individual components, even if it means sacrificing convenience. Many functions and services commonly found in Commercial-Off-The-Shelf (COTS) equipment, such as email, Voice over Internet Protocol (VoIP), Instant Messaging (IM), FTP, HTTP, and file sharing, may be considered for elimination",
        "requirementSatisfaction": "Requirement enhancement: None Security Level: The requirements for the four SL levels that relate to SR 7.7 - Least functionality are:\n• SL-C(RA, control system) 1: SR 7.7\n• SL-C(RA, control system) 2: SR 7.7\n• SL-C(RA, control system) 3: SR 7.7\n• SL-C(RA, control system) 4: SR 7.7"
      },
      {
        "requirementStandard": "IEC 62443 3-3 (§11.10)",
        "requirementName": "SR 7.8 - Control system component inventory",
        "requirementDescription": "The control system must be able to report the current list of installed components and their associated properties. This inventory can include component ID, capability, and revision level. It should align with the System under Control (SuC). Configuration management procedures should be in place to maintain the component inventory baseline (refer to IEC 62443-2-1)",
        "requirementSatisfaction": "Requirement enhancement: None. Security Level: The requirements for the four SL levels that relate to SR 7.8 - Control system component inventory are:\n• SL-C(RA, control system) 1: Not Selected\n• SL-C(RA, control system) 2: SR 7.8\n• SL-C(RA, control system) 3: SR 7.8\n• SL-C(RA, control system) 4: SR 7.8"
      }
      
]
}