Creating and maintaining a
definitive view of your Operational
Technology (OT) Architecture
How organisations who deploy or operate OT
systems should build, maintain and store their
systems understanding.
2
Maintaining a definitive view of your Operational Technology (OT) Architecture This guidance defines a principles-based approach for how operational technology (OT) organisations should build, maintain and store their systems understanding. It is aimed at cyber security professionals working in organisations that deploy or operate OT across greenfield and brownfield deployments. Integrators and device manufactures can also use these principles to ensure their solutions enable effective asset and configuration management. Table of Contents
• Introduction
• Principle 1: Define processes for establishing and maintaining the definitive record
• Principle 2: Establish an OT information security management programme
• Principle 3: Identify and categorise assets to support informed risk-based decisions
• Principle 4: Identify and document connectivity within your OT system
• Principle 5: Understand and document third-party risks to your OT system This guidance has been developed with contributions from partnering agencies and is part of a series of publications aiming to draw attention to the importance of cyber security in Operational Technology.
It is produced by the UK National Cyber Security Centre (NCSC) in partnership with the Australian Signals Directorate Australian Cyber Security Centre (ASD's ACSC), the Canadian Centre for Cyber Security (Cyber Centre), US Cybersecurity and Infrastructure Security Agency (CISA), the US Federal Bureau of Investigation (FBI), Germany’s Federal Office for Information Security (BSI), Netherlands National Cyber Security Centre (NCSC- NL), and New Zealand’s National Cyber Security Centre (NCSC-NZ). 3
Maintaining a definitive view of your Operational Technology (OT) Architecture OT systems are a prime target due to their criticality and the potential impact if these systems are disrupted. As the number and capability of threat actor targeting OT increases, so too does the need for robust cyber security controls. However, the complexity, scale, and long-standing nature of OT systems often means organisations can lack a holistic view of their environment, which undermines their ability to implement effective cyber security measures. Traditionally, OT networks were isolated (or ‘air-gapped’) from the internet and external systems. However, modern operational demands have led to increased connectivity as networks now integrate with enterprise systems, third-party vendors and cloud services. This makes designing appropriate security controls increasingly critical, to reduce the risks to previously isolated systems.
To design appropriate and effective controls a holistic system understanding is required. In this guidance, the term definitive record is used to describe a continually updated, accurate and up- to-date view of the system. A definitive record is an evolving collection of information that will change over time, with all system changes recorded to maintain its accuracy and authority. Establishing a definitive record of your organisation's OT will allow you to effectively assess risks and implement the proportionate security controls. Rather than focusing solely on individual assets, a holistic approach enables you to consider the broader context which leads to a better assessment of the criticality and potential impacts of compromises. Note: The process of establishing a definitive record should be collaborative, with both OT and IT teams involved. Use the NCSC cyber security culture principles to support this approach.
Maintaining a definitive view of your Operational Technology (OT) Architecture Introduction
4
Maintaining a definitive view of your Operational Technology (OT) Architecture Your organisation should aim to create a definitive record of all OT systems that it owns and operates. Since this task can be complex and time-consuming, you should prioritise systems based on:
1. The impact of the system to either your business function or the potential of national impact.
2. Third party connections, particularly where these connections can change the configuration of system components (or have direct control over the process). 3. The overall exposure of the system, taking into account how many connections the system has to external services where your organisation does not set the configuration of security controls.
This guidance outlines the principles that organisations should aim to achieve when documenting their OT. They are intended as goals rather than minimum requirements. Cyber security professionals should use these principles as a framework to develop a comprehensive record of their systems. This will require time and may present complexities, particularly in brownfield deployments. However, much of the information necessary to establish a definitive record is likely already available within your organisations. This information may be found in configuration files, existing documentation, or through monitoring and security tools. Identifying these existing resources is crucial for minimising the burden of ongoing maintenance of the record.
Integrators and device manufactures are encouraged to make these principles easier for organisations to achieve, through freely providing comprehensive documentation for supplied systems and offering tools that enable effective asset and configuration management. It is especially important that this documentation is available for 'turn-key' solutions, allowing operators to understand the design and implement appropriate security controls throughout the system's lifecycle.
Key priorities
Principles-based guidance
5
Maintaining a definitive view of your Operational Technology (OT) Architecture A few quick points on terminology before we start. Asset Any physical or virtual component within your OT system such as field devices, digital sensors, digital actuators, networking equipment, protocol gateways and computer platforms. Assets do not only include physical components but also digital services and software. Asset inventory An organised, regularly updated list of an organisation’s systems, hardware, and software. The inventory includes fields that describe the asset attributes such as manufacturer, model, and supporting communications protocols.
Architecture A holistic design that not only encompasses the components of a system (including technology, security controls, people and process), but how these elements integrate into larger business functions and objectives. The architecture is not just about technology; it is about how people and processes interact with it.
Brownfield An existing OT environment that is already deployed and operational. Brownfield environments present unique challenges when integrating new technologies, requiring careful planning to retrofit, secure, and modernise without disrupting critical operations. Definitive record A definitive record describes a continually updated, accurate and up-to-date view of the system (or element of a system). The definitive record will change over time with all system changes recorded to maintain its accuracy and authority. External connectivity Any connection that leaves the OT network boundary, including connections to any third parties, vendors and/or enterprise systems. Internal connectivity Any communications with assets within your organisation OT system. This includes all LAN and WAN components.
Information In this guidance, information can refer to raw data (sensor values or industrial protocols), documents (reports or diagrams), configurations (settings or policies), records (logs or audit trails) and procedural/process data (workflows or operating plans). Terminology
6
Maintaining a definitive view of your Operational Technology (OT) Architecture To create a definitive record of your organisation's OT systems, you should first determine how your organisation will gather, validate and maintain this information. Establishing a robust change management process is crucial to ensure the ongoing accuracy and relevance of this record over time. Your process should answer the following 3 questions: Once you’ve established the OT systems that you need to collect information on, you need to identify what sources you can use. When selecting information sources for the definitive record you should also consider any identified information gaps within the organisation. Information sources could include, but are not limited to: Asset Inventory
An OT asset inventory should list OT systems, hardware, and software with their attributes, including supported communications protocols.
Existing designs and documents
OT systems undergo extensive design work before they are commissioned to ensure they function as intended. Use any existing design, process or safety documentation as an initial step towards creating a definitive OT system architecture record. Your staff
Many OT systems have evolved in line with business needs. If a change management process has not been implemented, it is likely this information is still known by your organisation's experts. Work with system owners to identify what knowledge is already documented, and how current it is. Passive monitoring
Use passive monitoring tools to help build your OT architecture record. These tools can also aid in spotting undocumented changes to the OT system. If you find differences between your documented designs and monitoring results, you must validate if the changes were planned and where this is the case, document the changes.
1. How will information be collected?
Principle 1: Define processes for establishing and maintaining the definitive record
7
Maintaining a definitive view of your Operational Technology (OT) Architecture Configuration information
Use configuration information stored on support and management components in the environment. This could include project files and related configurations for assets like programmable logic controllers and remote terminal units. This should also include the configuration of network devices within the OT environment. SBOM and HBOM
A Software Bill of Materials (SBOM) and Hardware Bill of Materials (HBOM) can be requested from your manufactures. These can provide visibility into underlying components and help identify potentially vulnerable components. Prior to purchase, an organisation can use the SBOM/HBOM as part of their product risk assessment. The US Cybersecurity and Infrastructure Security Agency
(CISA) has published a HBOM framework as well as a number of resources on SBOMs. This NCSC blog will also help you to understand where SBOMs can add value in your organisation as well as their limitations.
Point-in-time active scanning
Conducting a point-in-time active scanning assessment can help you identify additional assets and their configurations within your environment. Before you conduct any actives scanning in OT environments, you should be aware that this process has the potential to overwhelm legacy devices that may have limited processing power, leading to performance degradation, freezing or crashing. Thoroughly consider and test for these implications before implementation. Note: If your organisation decides to use active scanning, ensure that it employs native ICS/OT protocols and tools, and that the scanning methods have been tested and validated by the original equipment manufacturer (OEM) of each asset. Where your OT system is monitored, it is crucial to inform your Security Operations Centre about your active scanning plans, including the date, time, and scope of the activity. This will help prevent any malicious active scanning from being overlooked after data collection. Planned maintenance windows can further ensure that this assessment does not impact your operations.
Summary: Your organisation should have a documented systematic approach to collect OT systems information. You should understand the sources of information available to you for the definitive record and how you can use this data. You should look to gather information from a range of sources, including from people, documentation, scanning and configurations. 8
Maintaining a definitive view of your Operational Technology (OT) Architecture Your process should also define how you validate any information you have collected. This is a critical step in ensuring you are building an up-to-date and definitive view of your OT system architecture. You will likely need to look at a several factors, including:
• Completeness How complete is the information? Does it capture all the details, or is it a draft document that will need additional information?
• Accuracy Does the documentation match your engineers' understanding of the system? Ensure that subject matter experts verify accuracy.
• Consistency Does the information confirm findings contained in other sources or are there conflicts? Any conflicts should be investigated to get to a consistent understanding of the current state of the system.
• Timelines When was the document produced? Combining this information with known business maintenance/planning windows can help you assess the likelihood that the documentation is representative of the current system state. Validation is especially important in brownfield environments, where systems often change from their original designs.
Summary: Your organisation should have a documented approach to validate OT systems architecture records. Implementing a strong validation framework will enable you to establish an accurate and complete architectural overview. The process should ensure that you can create a single source of truth that shows the “as is” state of the OT architecture. 2. How will information be validated?
9
Maintaining a definitive view of your Operational Technology (OT) Architecture Once a definitive record of the OT architecture has been established, it is critical to maintain the integrity and accuracy of this record. Change management processes and controls are vital for achieving this.
An effective change management process ensures systematic review, approval, and documentation of modifications, minimising the risk of errors. This process should define roles and responsibilities of key stakeholders, focusing on their potential impact on both operational efficiency and cyber security. Additionally, implement version control mechanisms to create a clear audit trail of all changes, enabling easy tracking of design evolution over time. Regular training sessions should be conducted to ensure that personnel involved in design and documentation understand the protocols and their significance. Summary: Your organisation should have an established change management process to govern your definitive OT record. The change management process should establish clearly documented personnel roles, version control, and ongoing training to ensure the integrity and accuracy of the record is maintained over time.
3. How will the definitive record be maintained?
10
Maintaining a definitive view of your Operational Technology (OT) Architecture The definitive record will be a collection of documents that consolidates a wide range of information about your organisation and OT environment. This makes it a high-value target for an attacker. As you build your definitive record, it is important to consider how it will be secured and your broader approach to OT information security management. Skilled threat actors will seek to gain insight into a target system to support their capability development and attack planning. The easier it is for an attacker to build an understanding of your OT system, the more likely an attack will be successful. Since physical assets in an OT environment are operational for long periods, any exposed information is likely to remain relevant for longer
(when compared to planning attacks on conventional IT systems). Your organisation could use standards such as ISO/IEC 27001 to aid in the implementation of an OT information security management system. At a minimum, your OT information security management programme should enable you to answer the following 3 questions: You should understand and create a record of all the information your organisation holds or shares relating to your OT systems. This could be as a standalone inventory or as part of the wider definitive record. Your organisation should record the purpose of the information, any relevant data flow diagrams as well as any key properties such as access permissions, retention and data format.
Standard information types (such as documents) may be stored in a data repository that already produces a record of all or many of these attributes. For less standard information types (such as data generated from OT devices), this may need to be manually produced. 1. What is in scope of the OT information security management programme?
Maintaining a definitive view of your Operational Technology (OT) Architecture Principle 2: Establish an OT information security
management programme
11
Maintaining a definitive view of your Operational Technology (OT) Architecture This guidance identifies five key groups of OT information: Design information
Focuses on providing a clear view of how a system is structured and arranged, and defines the architecture, specifications and/or configuration of an OT system. Examples include network diagrams, asset inventories, configuration files and technical system diagrams. Design information also includes details specific to individual sites such as locations of physical assets. Business information
Focuses on how the OT system functions in the context of business objectives and relationships with stakeholders. This includes (but is not limited to) data on service areas, customer or user locations and supplier contracts.
Identity and authorisation data
Encompasses information that is essential for the authentication and authorisation of users and systems within the OT environment. Identity and authorisation data includes user credentials, details of personnel, encryption keys, access control lists and access logs. Operational data
Refers to the information involved in the real-time control of an OT system. This includes the unrefined data from OT devices/software. Examples include sensor readings, system logs and alerts. Operational data also captures analytical output generated from unrefined data such as predicted reporting of component and/or system performance. Cyber and safety risk assessments
Contains information on weaknesses in the system design, its components and the potential consequences of risks if they were to occur. Examples would include HAZOP assessments or results of penetration testing.
Tip: IEC 62443-2-1:2024 offers advice on the protection of data related to industrial automation and control systems, as well as examples of the types of information/data that are within scope. Summary: You should have a comprehensive and structured record of all the information your organisation holds or shares relating to your OT systems. This record should clearly identify each information/data component’s purpose and relevant properties. This record will support informed decision-making as you build and deploy an effective OT information security management programme.
12
Maintaining a definitive view of your Operational Technology (OT) Architecture An attacker targeting an OT environment typically aims to disrupt, damage and/or destroy industrial systems and processes. They may also target OT systems to gain an economic advantage by stealing intellectual property or datasets that would enable competitors to improve their own processes. To achieve these aims, threat actors require information on how your system is architected, secured and operates.
There are three primary ways that threat actors can use OT information to finesse their cyber attacks:
Inform
Data can help a threat actor understand the broader context of their target system. This could include network architecture, access opportunities, and process dynamics for the underlying operational system. Threat actors may seek information on dependent systems that rely on, or contribute to, the correct operation of the target system. Target
System information can be used to begin targeting components within your environment with the aim of achieving a specific outcome. This will likely focus on developing capabilities to enable an attacker to enter and move within a network. This may involve identifying systems running outdated or vulnerable software. It could also include identifying possibilities for physical sabotage.
Exploit
Data can be used to cause an effect within the target system. Examples would include set-point limits and privileged access credentials. Deep knowledge of how the system works can also allow attacks that target ‘difficult to replace’ or long-lead items, with the intention of extending the duration of any disruption.
2. What is the value of the OT information to an
attacker?
13
Maintaining a definitive view of your Operational Technology (OT) Architecture A good approach is to consider the information an attacker would require within your threat modelling. After identifying the relevant information for each threat scenario, you can then analyse how an attacker might exploit that information and assess how critical its compromise is to their overall success. This helps you to determine the value of the information to an attacker, and to tailor your protections accordingly.
A data aggregation risk arises when threat actors have access to a collection of information that, when combined, can lead to development of capabilities that would not be possible using the individual pieces alone (this is described as latent intelligence). You should understand how information could be combined by a threat actor to chain together attack paths. Managing data aggregation risks requires an understanding of what information is already available, and what may become available as a consequence of future data sharing arrangements. Summary: You will be able to identify the OT information that supports different threat scenarios, understand the ways threat actors seek to exploit this information and recognise how aggregating OT information increases this risk. This knowledge allows you to focus security measures where they are most needed.
14
Maintaining a definitive view of your Operational Technology (OT) Architecture All information your organisation holds or shares relating to OT systems should be secured using appropriate and proportional controls. Your organisation should have clearly documented policies and procedures on how each type of information should be secured. When protecting information it is important to consider all the components of the CIA triad: Confidentiality
Confidentiality controls focus on ensuring that information is only accessible to systems and users that are authorised to have access. Core elements of confidentiality management comprise:
• Storage Where to store information should balance ease-of-access against the ability to apply effective security measures to minimise exposure. If your OT environments lack the ability to implement adequate controls, it may be appropriate to store information in IT systems where they support modern security controls. Where this is implemented in the IT environment, additional management and oversight of export risks should be put in place.
• Access should follow the principle of least privilege, meaning only users who need the information to perform their role are granted access. For high-value information, stronger authentication methods such as multi-factor authentication should be employed.
• Sharing It’s important to assess risks before sharing information about an OT system. One example of a set of handling rules is the Traffic Light Protocol (TLP) designation, which provides a standardised framework to ease the secure sharing of information. When third parties are involved, confidentiality must be protected through carefully defined and contractually enforced agreements.
Integrity
Integrity means proving that information is complete, intact, and trusted and has not been modified or destroyed in an unauthorised or accidental manner. Validating integrity is essential for all types of information in the OT environment. For example, if designs stored at rest lose integrity, a maintenance engineer might misconfigure equipment. Similarly, unauthorised modification of operational data in transit could cause a programmable logic controller to operate incorrectly. 3. How do you secure your OT information?
15
Maintaining a definitive view of your Operational Technology (OT) Architecture Integrity controls can be broadly divided into two categories, those that focus on maintaining integrity and those aimed at validating it:
• Maintain The usability of OT information depends on maintaining its integrity which involves regulating how information is created, updated, deleted, or changed, alongside monitoring these processes to detect anomalies. This includes restricting write permissions to authorised users, and enforcing version control to provide a complete audit trail and enable rollback of changes if needed.
• Validate Validation controls aim to verify that information has not been tampered with or corrupted. Cryptographic methods, such as digital signatures, serve as validation tools to ensure authenticity and integrity.
Availability
Availability controls focus on ensuring that organisations appropriately protect information and systems from outages, delays, and service degradation, ensuring they remain accessible to authorised users whenever needed. This includes building resilience through redundancy, backup and disaster recovery capabilities, as well as monitoring system health to detect and respond quickly to issues. The availability of information in OT is critical when looking to recover systems in the event of an incident. When deciding where this data is stored, you should consider how it would be accessed in different incidents. It is critical that backups are implemented to be ransomware resistant to protect their availability. Summary: You should have a clear and documented understanding of the security controls applied to all information your organisation holds or shares relating to OT systems. These controls should be aligned with the value of OT information and target appropriate security attributes.
16
Maintaining a definitive view of your Operational Technology (OT) Architecture Maintaining a definitive view of your Operational Technology (OT) Architecture Principle 3: Identify and categorise assets to
support informed risk-based decisions
Your organisation should understand the role of each of the components within your OT system. This is critical to enable you to create appropriate and proportionate security controls within your environment.
Tip: This guidance focuses on the broader process required to define your system architecture. There is additional international guidance on delivering an asset discovery programme which can be referred to, including:
• Security for industrial automation and control systems (IEC 62443-2-1)
• The Industrial Control System Community of Interest Asset Management guidance
• Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators CISA.
For each asset you should be able to define three factors; criticality, exposure and availability. Criticality
Criticality describes how important the functioning of the asset is to the wider OT system, in terms of its impact on:
• Business Would a failure cause the process to stop or result in a lower yield?
• Safety Would a failure cause harm or damage to people, equipment, and/or the environment?
• Security Would a failure result in the system being exposed to an unacceptable level of risk? To gain a complete understanding of an asset's criticality, it should be examined in the context of the wider system. This will require combining the criticality of the asset with information about your wider system connectivity.
17
Maintaining a definitive view of your Operational Technology (OT) Architecture Exposure
Exposure refers to the discoverability and accessibility of networked devices within an organisation, which could make them vulnerable to potential threats. This should account for what defence in depth controls might add to its security. Exposure should consider several factors including:
• the time of exposure (for example is it accessible 24/7 or only accessible when required?)
• the type of connectivity being used (for example direct connections to the public internet are inherently more exposed than private fibre links)
• communications flow (for example does the system accept inbound connections?)
• proximity to external networks such as the internet or remote access points
• physical accessibility (are there opportunities for unauthorised physical interaction, such as plugging in devices or physical presence near the system) Availability
Availability refers to the timely, reliable access to data and information services for authorised users. OT availability should include what business or operational functions would be lost in the event of that single asset being unavailable.
Where systems are highly critical, they are likely to be deployed for high-availability with redundancy built in and automated failover systems. This wider system availability may lower the availability requirements of some individual assets, making them easier to update and maintain. Information to record on availability could include but is not limited to:
• timescales for known