13 IDT requirements for OT Flashcards
1
OT Governance
OT Security requirements, roles and responsibilities must be documented and accepted
Risk: Lack of OT Governance roles, responsibilities and processes that are required to continuously manage and maintain OT Security Requirements may result in the degradation of OT Security posture and expose the environment to potential cyber threats.
Outcome: Requirements, roles and responsibilities for the ownership and management of OT Security are defines and accepted by Business Owner. This includes OT Security responsibilities of service providers.
2
OT Asset Inventory
As-built documentation must be maintained.
Risk: Not having complete and up to date documentation, including inventories and network drawings may result in unidentified, unmanaged, and therefore vulnerable OT devices which could be exploited by malicious threat actors targeting weaknesses in the OT Domain.
Outcome: Up to date HW and SW inventory on OT assets for all relevant aspects provides the necessary baseline for OT Security risk assessment and control implementation.
3
OT Management of Change
A formal change management system must be used to manage changes to the OT Domain.
Risk: Unmanaged changes to OT systems or devices can introduce vulnerabilities and degrade the overall security posture of the OT Domain. This can lead to the inability to effectively manage, maintain, and respond to risks and events in relation to those assets.
Outcome: The existence of a MOC process for OT is needed to ensure Business Owner accountability and oversight over the OT Domain as-is. Existing MOC processes on sites or locations where the OT assets reside can be applied as appropriate if they are able to also meet all other OT Security Requirements.
4
OT Secure Architecture (Network Segregation)
OT Domain network architecture must include:
i. Firewall(s) segregating all OT systems from corporate and external networks;
ii. Firewall(s) segregating functional level 2 systems from level 3 systems OR defines security zone(s) based on risk assessment; and
iii. Firewall(s) segregating the OT Domain from all other external OT networks.
Risk: Insufficient network segregation within the OT Domain may expose OT systems or devices to both internal and external cyber threats. Securely configured firewalls will reduce the risk exposure and will also limit the impact of a cyber incident by containing the malicious threat within the defined OT network zone or boundaries.
Outcome: Putting in place OT Domain network segregation though OT Zones, conduits and firewalls in designated logical locations will ensure sufficient levels of protection are embedded in the OT Domain network architecture.
Zoning servers as both preventive and mitigative barrier by making it more difficult for threats to move from one zone to another and reduce the likelihood as well as impact of a widespread system failure. It also allows the application of fit-for-purpose controls as per the threats and risks, coupled with fit-for-purpose activities to maintain the required controls.
A risk assessment is a pre-requisite for determining the required zones and fit-for purpose controls.
5
OT Secure Architecture (External Connections)
When a connection between the OT Domain and corporate or external networks is required, the following must apply:
i. Inbound remote connections to the OT Domain are terminated in an OT Domain DMZ and then re-established from that zone;
ii. IP-Based OT Domain connections that utilize external networks are encrypted; and
iii. All connections between the OT Domain and other networks are supported by a documented risk assessment.
Risk: External threats pose a significant risk to the OT Domain. Malicious threat actors constantly look for weaknesses in perimeter defenses, which when compromised would allow the threat actor to gain remote access to the OT Domain and potentially exploit the process or safety control systems.
Outcome: A risk assessment of connections between the asset OT Domain and corporate or external/other networks (including networks, which may be in the asset but operated by a different organization or company) will determine the security controls that need to be implemented to manage the risks. Assets can leverage a central or global risk assessment for standard solutions which includes performing a localized risk assessment as part of implementation.
6
OT Secure Architecture (Safety Systems)
Changes to the safety system logic solvers must only be possible from specifically authorized OT Domain devices in accordance with asset procedure.
Risk: Unauthorized access to and modification of safety systems can result in an unsafe operating environment and potentially safety related incident.
Outcome: Implementing additional barriers (controls) to make it more difficult for a threat actor to modify or tamper with the safety system of a plant or equipment.
When changes to safety systems are allowed only from specifically authorized devices, the likelihood of unauthorized changes is reduced. Further, it makes it easier to apply more stringent hardening and privilege control on the authorized device.
The controls against changes to safety logic solver should be such that the failure of one control should not permit modifications to the device configuration or programme logic (including performing overrides). The risk assessment and all the applicable controls against changes to the safety logic solver should be documented in the asset documents.
Depending on the installation and operational requirements, a combination of diverse and independent controls should be utilized. System generated alerts to control room operators when logic solver is put in “program mode” or when modification or forces are applied, with documented operator actions on receipt of an alert is another example of additional control.
7
OT Access Control
OT Domain devices and system must be protected from unauthorized access by:
i. Identifying and authenticating the user permitting access;
ii. Restricting user privileges to the minimum required to perform their role; and
iii. Using multifactor authentication for any remote user access via an OT Domain DMZ.
Risk: Insecure or weak access controls may be exploited by malicious threat actors who may use compromised accounts to gain unauthorized access to the OT Domain and deploy malicious SW or change control system logic. Similarly, excessive privileges given to unqualified OT Domain users could result in the compromising of critical parts of the OT Domain.
Outcome: Ensure that users are identified, and only have the minimum privileges to perform their role or the tasks assigned to them. Multifactor authentication should be in place for any remote user access. Site specific procedure should be used to request, approve, enable, and periodically revalidate to remove or modify user privileges on the OT Domain.
8
OT Vulnerability Management
OT Domain vulnerabilities must be managed by:
i. Developing and deploying an OS patching schedule for each OT Domain system and network device;
ii. Developing and implementing a lifecycle management plan; and
iii. System hardening in accordance with vendor guidelines and/or asset specific guidelines.
Risk: OS patches, lifecycle management and system hardening address existing vulnerabilities that malicious threat actors frequently target to compromise systems. Lack of sufficient vulnerability management will increase the exposure of OT systems to targeted and untargeted attacks.
Outcome:
i. The rationale for system patch frequency should be documented.
ii. As part of ongoing lifecycle management of SW and HW, an annual review should be conducted to identify OT Domain devices, systems, and network devices nearing obsolescence and plan mitigating actions.
iii. An asset specific hardening guideline based on industry standards should be developed as a baseline and applied along with the vendor specific guidelines where available.
Vendor approved hardening techniques should be used as a basis for all devices and systems. It is recommended to first contact the vendors to obtain the most recent version of the hardening guidelines for vendor devices and systems. In case vendor specific hardening guidelines are not available, generic hardening guidelines based on industry standards should be included in the site specific system hardening procedure.
9
OT Awareness and Training
OT Domain Users must be made aware of OT Security risks and requirements/responsibilities concerning:
i. Gaining access to the system;
ii. Permitted use of systems;
Following restrictions on portable media and temporary devices;
iv. Intervening and reporting incidents; and
v. The correct usage of elevated privileges.
Risk: Unawareness of OT Security risks by OT Domain users may expose the OT Domain to security risks which can result in the compromising of critical parts of the OT Domain.
Outcome: OT Domain users include staff, contractors, visitors, and third-party users. Required training (including awareness sessions) and the refresh period should be defined and based on the user’s role and managed using a training plan with training records or user acceptance forms.
Special consideration should be given to the training of users with elevated privilege accounts (i.e. admin, engineers, supervisors, managers).
10
OT Malware Protection
OT Domain devices must be protected from malware by:
i. Deploying, maintaining, and running end-point protection technology;
ii. Scanning and confirming that all portable media and temporary devices are free from malware before being connected to the OT Domain; and
iii. Restricting the use of portable OT Domain devices and media to authorized purposes only.
Risk: Malicious SW poses a significant risk to the OT Domain and the lack of malware protection significantly increases the exposure to malicious threat actors that are actively targeting known vulnerabilities.
Outcome: Proper implementation of the measures embedded in this requirement proportionally reduces the risk that malware is introduced into the OT Domain from removable media and portable or temporary devices or via network connections.
11
OT Event Monitoring
Abnormal events must be detected and actioned in accordance with developed site requirements.
Risk: Lack of OT event monitoring may enable malicious cyber threats to go undetected within the OT Domain resulting in widespread compromise and potentially greater impact to the OT Domain.
Outcome: Site requirements on event management must be in place and applied to the OT Domain. This includes log management & analysis thereof as appropriate.
The requirement of abnormal event monitoring is based on the asset’s risk exposure and legal & regulatory requirements. The chosen event monitoring process can be based on information such as system and application logs, network security monitoring, network device and firewall logs, control system event logs and monitoring parameters, sequence of event logs, etc.
12
OT Incident Management
OT Security response plans must be developed and include steps for:
i. Reporting OT Security incidents to the IT Service Desk;
ii. Ensuring incidents are recorded in the asset designated HSSE management system; and
iii. Reporting externally according to applicable regulatory requirements.
Risk: Lack of defined incident response processes and capabilities may result in significant OT Security incidents that are not sufficiently controlled to limit resulting impacts and consequences.
Outcome: All suspected events are required to be reported to IT Service Desk as soon as possible to ensure that timely central support and response can be provided to the asset. This helps OT Domain support desk to check and alert asset if the event has potential to impact other systems.
Recording the full details of the OT Security incidents by the asset on their designated HSSE management system allows for analysis and sharing of lessons and where required, reporting to regulatory bodies vis the appropriate reporting channels.
13
OT Systems Backups
A schedule for conducting, maintaining, and validating backups must be developed and deployed.
Risk: The inability to restore OT devices, systems and network devices through backups can result in the unavailability of parts of the OT Domain.
Outcome: A backup validity strategy should be in place that results in confidence that systems can be restored using backups. An asset’s backup schedule should be risk-based, balanced against changes on device program/configuration. Backup copies or redundant setups should be protected from unauthorized access and ensuring offline onsite/offsite backups are accessible when required.
