CIP IEC-62443-4-2 Foundational Requirement-2 Assessment details
Revision History
Revision No |
Date |
Change description |
Author |
Reviewed by |
|---|---|---|---|---|
001 |
2025-08-04 |
CIP IEC-62443-4-2 FR-2 assessment details |
Dinesh Kumar |
BV (Bureau Veritas) |
002 |
2025-10-22 |
CIP IEC-62443-4-2 FR-2 added details to most requirements |
Pasquale Nieddu |
BV (Bureau Veritas) |
003 |
2025-11-12 |
Fix formatting issues in CR 2.8 and CR 2.10 and update 2.09 RE(1) |
Adithya Balakumar |
BV (Bureau Veritas) |
004 |
2025-11-21 |
Fixed applicable requirements for CIP User action |
Dinesh Kumar |
BV (Bureau Veritas) |
005 |
2025-11-24 |
Fixed typo in CR-2.10 based on BV feedback |
Dinesh Kumar |
BV (Bureau Veritas) |
006 |
2025-12-15 |
Update CR 2.5 Session lock as NA |
Adithya Balakumar |
BV (Bureau Veritas) |
007 |
2025-12-29 |
Update reason for NA in CR 2.7 |
Adithya Balakumar |
BV (Bureau Veritas) |
1. Overview
This document provides details of IEC-62443-4-2 FR-2 requirements for CIP assessment. The objective of the document is to share details with CIP users for requireements which are found Met and NA during CIP IEC-62443-4-2 assessment by BV.
This document can be used as reference by CIP users for IEC-62443-4-2 compliance for end products based on CIP.
4. CR-2.1 RE(2) Permission mapping to roles [Met]
4.1 How CR-2.1 RE(2) is Met
CIP provides authorization enforcement for all users (human, software processes, and devices) based on assigned responsibilities and the principle of least privilege.
The Linux security feature ‘SELinux’ can be used for granular access control, moving beyond default privilege hierarchies. While a ‘root’ account may be useful for maintenance, ideally no superuser account is required for regular operation.
Evidence for authorization enforcement is provided by TC_CR2.1_1 [1].
4.2 CIP User action
To effectively manage authorization for all user types, CIP users should:
Apply Least Privilege: Extend the principle of least privilege to human users, software processes, and devices.
Utilize SELinux: Consider using SELinux for fine-grained access control policies for processes and devices.
Minimize Root Usage: Strive to operate without direct ‘root’ access for daily operations; control and log its use for maintenance.
Review All User Types: Conduct regular audits of authorization policies for all users, including service accounts and device credentials.
5. CR-2.2 Wireless use control [NA]
5.1 Why CR-2.2 is NA
Meeting the full scope of this requirement, which involves comprehensive authorization, monitoring, and restriction of wireless use, necessitates an external infrastructure. The CIP image, as a minimal reference, primarily focuses on providing a robust and secure base operating system. While CIP may include client-side components like wpa_supplicant to facilitate wireless connectivity, these alone do not fulfill the overarching requirement for managing and controlling wireless usage across an entire system or network. The complete solution extends beyond the scope of the base image.
5.2 CIP User action
To adequately address the “Wireless use control” requirement, CIP users (integrators) should:
Implement External Infrastructure: Establish and integrate the necessary external infrastructure for wireless authorization, monitoring, and usage restrictions.
Utilize Client-Side Components: Leverage any client-side wireless components provided by CIP (e.g., wpa_supplicant) as part of their broader wireless control solution.
Define and Enforce Policies: Develop and enforce comprehensive policies for wireless network access, device authentication, and data transmission, integrating them with their chosen external management systems.
Monitor and Audit: Implement mechanisms for continuous monitoring and auditing of wireless activities to ensure compliance with security policies.
6. CR-2.3 Use control for portable and mobile devices [NA]
6.1 Why CR-2.3 is NA
This requirement is not applicable as the CIP image is designed for industrial embedded systems and does not target portable or mobile devices.
6.2 CIP User action
No user action is expected for this requirement.
7. CR-2.4 Mobile code [NA]
7.1 Why CR-2.4 is NA
This requirement is not applicable to the CIP platform because it specifically addresses mobile code within software applications, whereas CIP provides the base operating system and not the applications themselves.
7.2 CIP User action
This requirement is component specific hence no user action is required for it.
8. EDR 2.4, HDR 2.4, NDR 2.4, SAR 2.4 Mobile code [NA]
8.1 Why mobile code requirements are NA
These mobile code requirements are not applicable to the CIP platform because they primarily address mobile code within specific software applications rather than the base operating system provided by CIP. The CIP image serves as a foundational platform, and the responsibility for managing mobile code typically resides with the applications running on it. Furthermore, while CIP plans to get the EDR and NDR variants assessed, the requirements for Host Devices (HDR) and Software Applications (SAR) are considered outside the direct scope of the CIP platform itself, as they pertain to higher-level application logic and specific host device implementations.
8.2 CIP User action
CIP can not recommend any actions for HDR and SAR category as these two categories were out of scope for CIP IEC assessment. Following are the recommended user actions for EDR-2.4 and NDR-2.4 requirements.
Ensure that only authorized code can run by verifying the integrity of the bootloader and subsequent software components using cryptographic signatures.
Use whitelisting of applications so only authorized apps run
Ingest logs from Mobile code apps to a Security Information and Event Management (SIEM) solution to monitor for suspicious activity and generate alerts.
Implement a mechanism where a trusted component verifies the integrity of the code before execution. If the verification fails, the execution can be terminated or disabled.
9. EDR 2.4 RE(1), HDR 2.4 RE(1), NDR 2.4 RE(1), SAR 2.4 RE(1) Mobile code authenticity check [NA]
9.1 Why mobile code authenticity check requirements are NA
These requirements for mobile code authenticity checks (EDR 2.4 RE(1), HDR 2.4 RE(1), NDR 2.4 RE(1), SAR 2.4 RE(1)) are not applicable to the CIP platform. The core reason is that CIP provides the foundational operating system, not the specific software applications that utilize mobile code. The responsibility for ensuring the authenticity of mobile code lies with the applications running on CIP. Furthermore, while CIP intends to have EDR and NDR variants assessed, the requirements pertaining to Host Devices (HDR) and Software Applications (SAR) fall outside the direct scope of the CIP platform itself, as they relate to higher-level application logic and specific host device implementations.
9.2 CIP User action
Refer use action section 8.2
10. CR-2.5 Session lock [NA]
10.1 Why CR-2.5 is NA
This requirement is not applicable to the CIP platform as the platform takes a more defensive approach to automatically terminate sessions due to inactivity. Specifically, the component offers:
Automatic Session Termination: The system can be configured to automatically terminate user sessions after a specified period of inactivity. This is achieved through mechanisms like the TMOUT environment variable (e.g., in /etc/bash.bashrc for interactive shell sessions) and openssh configurations for remote access. This termination effectively prevents further access by initiating a session lock after the configurable inactivity period.
Secure Re-establishment of Access: Once a session is terminated due to inactivity, access remains locked. The session lock remains in effect until the human user who owns the session, or another authorized human user, re-establishes access. This re-establishment requires successful identification and authentication procedures, ensuring that only authorized personnel can regain control.
Evidence for this implementation is provided by TC_CR2.6_1, as referenced in the conformity statement.
10.2 CIP User action
To enable and configure session locks, CIP users (integrators) can use user-space packages like vlock or screen.
11. CR-2.6 Remote session termination [Met]
11.1 How CR-2.6 is Met
The CIP platform effectively meets the “Remote session termination” requirement by providing a mechanism to automatically terminate remote sessions after a configurable period of inactivity. This is achieved through the use of the TMOUT environment variable. By setting a specific value for TMOUT, the system ensures that remote sessions (such as SSH sessions) are automatically closed if no user activity is detected within the defined timeframe. This capability is crucial for enhancing security by preventing unauthorized access to unattended remote connections. Evidence for this implementation is verified by TC_CR2.6_1, as referenced in the conformity statement.
11.2 CIP User action
To enable and configure the automatic termination of remote sessions, CIP users (integrators) should:
Configure Inactivity Timeout: Set the desired period of inactivity (in seconds) for remote sessions by assigning a value to the TMOUT variable. This can typically be done in shell configuration files (e.g., /etc/profile, ~/.bashrc, or /etc/bash.bashrc) to ensure it applies to relevant remote shell sessions.
12. CR-2.7 Concurrent session control [NA]
12.1 Why CR-2.7 is NA
This requirement is for SL-3 and were out of scope for CIP assessment. However, CIP images have capability to meet this requirement. While CIP provides the underlying mechanisms and tools (e.g., through libpam-modules) to control concurrent sessions, the specific policy and enforcement of session limits are ultimately determined and configured by the system integrator or product developer based on their specific application and security needs. CIP enables this capability rather than enforcing a default, universal policy.
12.2 CIP User action
CIP users (integrators) can meet this requirement for their specific product by configuring the number of allowed concurrent sessions in the /etc/security/limits.conf file, which is provided by libpam-modules.
13. CR-2.8 Auditable events [Met]
13.1 How CR-2.8 is Met
The CIP platform comprehensively meets the “Auditable events” requirement by leveraging the robust auditd package. This component provides the capability to generate security-relevant audit records for a wide range of critical system activities, ensuring detailed and verifiable logging.
The system is capable of recording events across the following essential categories:
Access control events
Request errors
Control system events
Backup and restore events
Configuration changes
Audit log events
Each individual audit record generated by auditd is designed to include all necessary parameters to provide a complete and contextual understanding of the audited event. These parameters typically include:
Timestamp: Indicates the exact date and time when the event occurred.
Source: Identifies the origin of the event, which can be an originating device, a specific software process (e.g., by Process ID and executable path), or a human user account (e.g., by User ID).
Category & Type: The audit system utilizes a structured approach to classify events. A broader “Category” groups events into general classes (e.g., system calls, authentication events), while a more granular “Type” provides specific details about the nature of the event within its category (e.g., a specific system call number or an authentication success/failure).
Event ID: A unique identifier associated with each audit record, allowing for precise tracking and correlation of individual events. This often relates to the process ID or a sequential identifier.
Event Result: Describes the outcome of the event, typically indicating success or failure and often including relevant result codes.
These audit records can be effectively managed and analyzed using standard Linux tools like ausearch and journalctl, which allow for searching, filtering, and reviewing the generated logs. This ensures that all required auditable events are captured with the necessary detail for security monitoring and compliance.
13.2 CIP User action
To ensure comprehensive auditing capabilities are leveraged, CIP users (integrators) must:
Configure `auditd`: Utilize the auditd package to define specific audit rules that capture all necessary security-relevant events according to their operational requirements. This involves creating or modifying configuration files, typically located in /etc/audit/rules.d/ (e.g., audit.rules). Key aspects of configuring audit.rules to meet the requirement include: * Monitoring Critical Files and Directories: Add rules to monitor read, write, and execute access to sensitive system files (e.g., /etc/passwd, /etc/shadow, /etc/sudoers) and critical configuration directories. This helps capture access control violations and configuration changes. For example, a rule like -w /etc/passwd -p wa -k passwd_changes would audit write/attribute changes to /etc/passwd. * Monitoring System Calls: Implement rules to audit specific system calls related to process execution, file manipulation, and control system events. For instance, -a always,exit -F arch=b64 -S execve -k process_execution could track program executions. * Recording User Authentication and Sessions: Ensure rules are in place to capture events related to user logins, logouts, and authentication attempts. * Ensuring Rule Persistence: After defining rules, it’s crucial to ensure they are loaded automatically upon system boot. This is typically done by restarting the auditd service (systemctl restart auditd) or by saving the current rules (e.g., auditctl -D; auditctl -R /etc/audit/audit.rules).
Monitor Audit Logs: Regularly use tools such as ausearch or journalctl to search, analyze, and review the generated audit logs. This ensures that the required events are being recorded correctly and allows for proactive monitoring of security-relevant activities and compliance verification.
14. CR-2.9 Audit storage capacity [Met]
14.1 How CR-2.9 is Met
The CIP platform addresses the “Audit storage capacity” requirement by leveraging the auditd package, which provides robust capabilities for managing audit log storage and protecting against system failures when capacity limits are approached or exceeded.
Specifically, the auditd component offers:
Configurable Audit Record Storage: The system provides the capability to allocate and manage audit record storage capacity in line with commonly recognized recommendations for log management. This includes defining the maximum size of individual log files and the number of log files to retain through a sophisticated log rotation mechanism. This ensures that audit logs are maintained efficiently without consuming excessive disk space indefinitely.
Protection Against Storage Capacity Exceedance: auditd incorporates mechanisms to protect the system from failure when audit storage capacity is reached or exceeded. Instead of simply overwriting old logs or crashing, auditd can be configured to: * Rotate Logs: Automatically create new log files and archive older ones once a configured size limit is reached, maintaining a specified number of log files (e.g., in /var/log/audit). * Issue Warnings: Generate warnings to alert administrators when a defined threshold of remaining disk space for audit logs is reached. * Execute Predefined Actions: Perform configurable actions, such as suspending auditing, shutting down the system, or sending notifications, when the disk becomes critically full or an error occurs. This prevents the audit system itself from causing operational issues due to full disk conditions.
These features ensure that audit logging continues reliably while providing administrators with the necessary controls and alerts to manage storage effectively and prevent system instability.
14.2 CIP User action
To effectively manage audit storage capacity and ensure system resilience, CIP users (integrators) must:
Configure `auditd` Storage Parameters: Adjust the auditd.conf configuration file (typically located in /etc/audit/auditd.conf) to define appropriate storage management policies. Key parameters to consider include: * max_log_file: Sets the maximum size (in MB) of an individual audit log file before rotation occurs. * num_logs: Specifies the number of rotated log files to retain. * max_log_file_action: Defines the action to take when max_log_file is reached (e.g., ROTATE for standard rotation, KEEP_LOGS, SUSPEND, SINGLE to shut down the system). * space_left_action: Determines the action when a low disk space threshold is met (e.g., WARN, SYSLOG, EMAIL, SUSPEND). * disk_full_action: Specifies the action when the audit log partition becomes completely full (e.g., SUSPEND, SINGLE, HALT). * disk_error_action: Defines the action in case of a disk error (e.g., SUSPEND, SINGLE, HALT).
Monitor System Resources: Regularly monitor the disk space allocated to audit logs to ensure that the configured parameters are sufficient for the operational environment and to anticipate potential capacity issues.
Review Audit Logs for Warnings: Pay attention to system logs and audit logs for any warnings or errors related to audit storage capacity, indicating that configured thresholds are being met or exceeded.
15. CR-2.9 RE(1) Warn when audit record storage capacity threshold reached [NA]
15.1 Why CR-2.9 RE(1) is NA
This requirement is for SL-3 and were out of scope for CIP assessment. However, CIP images have capability to meet this requirement. This requirement is tested by IEC layer test TC_CR2.9-RE1_1.
15.2 CIP User action
CIP users can configure auditd to warn when the audit storage capacity threshold is reached using the space_left_action configuration provided by auditd.
16. CR-2.10 Response to audit processing failures [Met]
16.1 How CR-2.10 is Met
The CIP platform effectively addresses the “Response to audit processing failures” requirement by providing robust mechanisms to protect essential services and ensure appropriate actions are taken during audit system malfunctions.
Specifically, the platform meets this requirement in two key ways:
Protection of Essential Services: While the definition of “essential functions” is ultimately the responsibility of the system integrator or end-user based on their specific application requirements, the CIP platform ensures that the audit system operates as an independent and architecturally decoupled service. Through process isolation and independent resource management, the platform guarantees that audit processing failures cannot impact other system functions that might be deemed essential by the end-user. This architectural design inherently protects critical operations from audit-related disruptions.
Support for Appropriate Actions: The auditd package provides comprehensive capabilities to respond to audit processing failures in accordance with commonly accepted industry practices. This includes: * Configurable Failure Actions: auditd can be configured to take specific actions when audit storage capacity is reached, or other processing failures occur (e.g., issuing warnings, suspending auditing, or even halting the system in critical scenarios). * Centralized Logging and Redundancy: A crucial capability is the support for redirecting audit logs to external Security Information and Event Management (SIEM) systems or central logging servers. This ensures that audit data continues to be captured and preserved even if local audit log storage becomes unavailable or full. This remote backup mechanism is designed to function without interruption, even when local storage capacity is exceeded.
These features collectively ensure that the system remains resilient and that critical audit information is preserved, even in the face of audit processing failures.
16.2 CIP User action
To effectively manage and respond to audit processing failures, CIP users (integrators) must:
Configure `auditd` Failure Actions: Adjust the auditd.conf configuration file (typically in /etc/audit/auditd.conf) to define appropriate actions for various failure scenarios. This includes setting parameters like space_left_action, disk_full_action, and disk_error_action to ensure the system responds as desired (e.g., WARN, SUSPEND, HALT).
Implement Centralized Logging: For critical environments where audit logging is considered an essential function, configure auditd to forward audit logs to an external SIEM system or a central logging server. This provides redundancy and ensures audit data continuity even if local storage fails. Refer to the platform’s documentation on centralized logging for guidance on this setup.
Monitor Audit System Health: Regularly monitor the health and status of the auditd service and its associated logs for any warnings or errors related to audit processing. This allows for proactive intervention and ensures the audit system is functioning correctly.
17. CR-2.11 Timestamps [Met]
17.1 How CR-2.11 is Met
CIP meets the “Timestamps” requirement by ensuring that all generated audit records include precise date and time information. This capability is provided by the auditd package, which is central to the platform’s auditing framework.
Every audit record generated by auditd incorporates a detailed timestamp, indicating the exact moment an event occurred. These timestamps are critical for:
Chronological Ordering: Accurates timestamps allow for the correct sequencing of events, which is vital for understanding the flow of activities within the system.
Forensic Analysis: They provide an immutable reference point for investigating security incidents and tracing actions back to their origin.
Event Correlation: Timestamps enable the correlation of events across different logs and systems, offering a holistic view of system behavior.
The accuracy of these timestamps is directly dependent on the underlying system clock, which the platform leverages to ensure the integrity of audit data.
17.2 CIP User action
To ensure the integrity and accuracy of audit record timestamps, CIP users (integrators) must:
Set the System Clock Accurately: During the initial setup and deployment of the CIP system, ensure that the device’s internal clock is set to the correct date and time.
Implement Time Synchronization: Configure and maintain a reliable Network Time Protocol (NTP) client (e.g., ntpd or chronyd) on the system. This is crucial for synchronizing the system clock with trusted external time sources, preventing clock drift, and ensuring continuous timestamp accuracy.
Monitor Time Synchronization: Regularly verify the operational status of the time synchronization service to confirm that the system clock remains accurate and synchronized. This proactive monitoring helps guarantee the trustworthiness of all generated audit records.
18. CR-2.11 RE(1) Time synchronization [Met]
18.1 How CR-2.11 RE(1) is Met
CIP fully meets the “Time synchronization” requirement by providing the capability to synchronize all system-generated timestamps, including those in audit records, with a system-wide time source. This is achieved through the integration and support for standard Network Time Protocol (NTP) clients, such as chrony or ntpd.
The platform’s underlying operating system and its auditing components are designed to:
Utilize System-Wide Time: All audit events leverage the system’s synchronized clock, ensuring that every timestamp reflects a consistent and accurate point in time.
Support Robust NTP Clients: The platform supports the configuration and operation of industry-standard NTP clients, which can reliably synchronize the system clock with trusted external NTP servers.
Maintain Timestamp Integrity: By providing mechanisms for accurate time synchronization, the platform ensures the integrity and chronological consistency of audit records, which is crucial for forensic analysis, compliance, and event correlation.
This capability ensures that audit records are not only generated with timestamps but that these timestamps are also accurate, consistent, and synchronized across the entire system.
18.2 CIP User action
To ensure robust time synchronization for audit records, CIP users (integrators) must:
Configure a Time Synchronization Client: Implement and configure a reliable NTP client (e.g., chrony or ntpd) on the system. This involves specifying trusted NTP servers to synchronize with. The configuration of these NTP servers is an application-specific condition.
Follow Best Practices for Time Sources: Adhere to commonly recognized best practices for configuring time sources. This includes selecting secure and reliable NTP servers and implementing measures to protect against time-skew attacks, thereby ensuring the authenticity and integrity of the synchronized time.
Monitor Time Synchronization Status: Regularly monitor the operational status of the time synchronization service to confirm that the system clock remains accurately synchronized. Proactive monitoring helps detect and address any potential issues with time drift or synchronization failures.
Initial Clock Setting: Ensure the device’s internal clock is set accurately during initial setup, as the time synchronization service will then maintain this accuracy over time.
19. CR-2.11 RE(2) Protection of time source integrity [NA]
19.1 Why CR-2.11 RE(2) is NA
This requirement is classified for Security Level 4 (SL4). As CIP is currently targeting Security Level 2 (SL2), this requirement is not applicable for the compliance level.
20. CR-2.12 Non-repudiation [Met]
20.1 How CR-2.12 is Met
CIP addresses the “Non-repudiation” requirement by leveraging the robust auditing capabilities of the underlying operating system and the auditd package. While CIP itself does not implement a Human User Interface (HUI), the kernel and auditd provide foundational mechanisms to ensure that critical user-related actions and system events are recorded in a verifiable and undeniable manner.
Specifically, CIP’s auditing framework, through auditd, by default tracks and logs:
User Logon Events: Successful and unsuccessful attempts to access the system.
User Logoff Events: Records when a user session terminates.
Failed Login Attempts: Detailed records of authentication failures.
User Account Changes: Events like the creation, modification, or deletion of user accounts.
Other Critical System Actions: Many other system calls and administrative actions that can be attributed to a specific user or process.
Each audit record generated includes essential details such as the user ID, process ID, timestamp, and the specific action taken, making it difficult for an entity to falsely deny having performed an action. These records are designed to be immutable, contributing significantly to the non-repudiation of system-level activities.
20.3 CIP User action
To ensure comprehensive non-repudiation, CIP users (integrators) must:
Implement Application-Specific Logging: Since CIP does not provide a Human User Interface, application developers building on CIP are responsible for implementing logging and tracing of user activity within their specific applications. This includes all interactions and transactions performed by users through the application’s interface.
Configure `auditd` for Critical Actions: Utilize auditd to define specific audit rules that capture any additional security-relevant user actions or system interactions critical to their application’s non-repudiation requirements. This might include monitoring access to sensitive application data, execution of specific commands, or configuration changes.
Protect Audit Logs: Ensure that audit logs are adequately protected against unauthorized modification, deletion, or access. This includes configuring appropriate file permissions, utilizing log rotation, and potentially forwarding logs to a secure, centralized logging system or SIEM for long-term storage and integrity.
21. CR-2.12 RE(1) Non-repudiation for all users [NA]
21.1 Why CR-2.12 RE(1) is NA
This requirement is classified for Security Level 4 (SL4). As CIP is currently targeting Security Level 2 (SL2), this requirement is not applicable for the compliance level.
21.3 CIP User action
User actions in section 20.3 can be implemented to meet this requirement, additionally following points should be kept in mind.
Enable extensive logging to keep track all user actions along with accrate timetamp
Secure log integrity and audit logs access records periodically
Implement strong authentication such as MFA and certificate based authentication
Set clear policies on how to use secure systems and understand the implications of their digital actions and consequences of wrong actions
22. CR 2.13, EDR-2.13 RE(1), HDR-2.13 RE(1), NDR-2.13 RE(1) Activer Monitoring [NA]
22.1 Why Active Monitoring requirements NA
All these requirements are for SL-3 and were out of scope for CIP assessment. As these requirements expect active monitoring of device diagnostic and test interfaces hence purely specific to underlying hardware. CIP reference device (M-COM) does not have any such interface which can provide any diagnostic information for monitoring.
22.3 CIP User action
CIP users shall investigate their end device whether it supports any interfaces which can be used to monitor diagnostics. if there are any interfaces available on the device, evidence should be provided to meet these requirements.