Operational Technology

SCADA software applications are often developed for on-premises deployments and do not provide Software as a Service (SaaS) product alternatives. This leads to solutions being moved to the cloud as ‘lift and shift’ deployments. You can identify this pattern if:

• a solution must be deployed to Infrastructure as a Service (IaaS)
• a solution requires a locally deployed database or file store

You should always consult with the SCADA software vendor directly to identify if a cloud solution is a supported deployment option for their product. Where a vendor does have a SaaS solution, you should look to identify how they meet the NCSCs cloud security principles with particular attention to Principle 3: separation between customers.

You should also work with the SCADA vendor to understand how they have architected the solution to determine if it is suitable for your use case of cloud deployment. A large proportion of existing OT applications are designed using a ‘monolithic architecture’ (where a solution is developed as a single unified unit, typically under a large single code base). These architectures are often difficult to update due to small changes having impacts to large areas of the code base, and also typically require maintenance of an underlying operating system in addition to the software. 

A modern approach to development would be to use a microservice architecture. This is where an application is broken down to services which can be independently maintained. 

Microservice architectures can be used to enable security improvements in OT environments with faster patching cycles to critical infrastructure. This is due to update procedures only involving updating individual services (rather than underlying operating systems and whole application suites). The NCSC’s services and deployments models guidance provides further advice on how these can be deployed. Using the flexibility of cloud workspaces to implement testing environments can also speed up acceptance testing. The NCSC’s using cloud services securely guidance discusses how workspaces can be used effectively. 

The ability to use technologies such as containerisation for hosting applications, allows you to adopt automation for deployment, both natively in cloud environments, and in on-premises infrastructure. Containerising an application can be a great enabler for improving its security. The NCSC has also published further security guidance on using containerisation. 

Where OT organisations are migrating legacy solutions (such as products architected on a monolithic code base) they should use the NCSC's guidance on 'how to lift and shift successfully' to assist developing a migration strategy. You should also consider how this effects your responsibilities for maintaining this solution under the cloud shared responsibility model. The impact of these should feed back into the board level discussions on your overall readiness to move to a cloud based solution. 

SCADA systems by definition will always include a physical element. SCADA systems need to be able to gather data or issue control commands to a range of distributed sensors and actuators. This requirement to connect to the physical world is still the case when deployed to the cloud, and can result in a complex attack surface.

Organisations should reduce the number of connections to the cloud environment, and centralise these on-premises connections where possible. The trust model between on-premises and cloud components needs to be carefully considered.

The risk to cloud elements from distributed physical components is further elevated if a legacy estate is connected that doesn’t support effective security controls. Without appropriate security controls in the cloud, this could also put the connected on-premises environment at risk. In addition, legacy protocols often don’t support encryption or authentication natively. 

When considering a cloud migration, you should identify what your chosen provider is able to natively ingest to the platform as part of a managed service. The supported protocols should inform how you integrate your existing telemetry estate. Non-traditional SCADA protocols such as MQTT might be able to be considered specific use cases where full SCADA protocol functionality is not required. Using protocols such as MQTT (which are easier to integrate to a cloud environment) would be an enabler to a successful cloud migration. 

Due to the complexities presented by each use case, the NCSC cannot provide a specific set of patterns for the connectivity of distributed field devices to the cloud. However, we’d advise field devices to use cloud-native capabilities such as IoT gateways or VPN gateways services. 

External connectivity should be designed with adequate protections for confidentiality, integrity, and availability (CIA). In OT organisations, the CIA triad is often described as AIC, where availability is prioritised above all else. When moving to the cloud, the weighting of these needs to be reconsidered. Clouds internet-connected nature makes the integrity and authenticity of control data ever more critical. If your ability to ensure integrity is not possible due to availability requirements, your organisation should consider whether cloud is suitable for your SCADA solution.

The considerations for latency will form part of the engineering design and feasibility assessment before a cloud migration. You should ensure that the overall security posture of the solution is not being altered to reduce system latency. The ability to implement security alongside the latency requirements should directly feed the organisational decisions on whether cloud is suitable for your SCADA solution. 

Operators should work with their cloud service provider and SCADA vendors to understand if their latency requirements can be met sufficiently. 

Where edge compute is used to mitigate latency concerns, these should be secured in line with our device security guidance.

OT organisation's SCADA data is sensitive, and provides the necessary information required to control physical infrastructure. Ensuring that this data is adequately protected should be a priority both on-premises and in a cloud deployment.

As stated in the NCSCs cloud security guidance, a public cloud service can only protect data according to the OFFICIAL threat model (including data with the SENSITIVE handling caveat). There may also be cases where information is not classified as SECRET (or above), but where you need to protect the information to a similar threat model. This might include extremely sensitive bulk personal data or services with very high integrity requirements. CNI organisations should work with their competent authority under NIS to determine if this applies to their data.

Where cloud data storage is appropriate, adequate security controls should be put into place. Data encryption at rest and in transit is covered in more detail in the first principle of the cloud security principles. You should ensure that you have confidence that your cloud service will meet the security needs of your organisation's data. Before deciding how to manage your organisation's keys in the cloud, you should familiarise yourself with the ‘Myth busting cloud key management services’ blog.