How to Use Engineering Specs to Ensure OT Cybersecurity in Public Infrastructure

Discussing operational technology (OT) and public facilities, such as hospitals and universities, may seem surprising as OT is most often associated with manufacturing. However, public facilities depend on the reliable functionality of critical infrastructure including their utilities and HVAC systems, which consist of numerous OT components such as digital industrial control systems and other computers designed to monitor and control physical processes, servers, and network devices.

Just like devices running on the enterprise network must be protected from external cybersecurity threats, OT components also need to be secured from vulnerabilities, especially since a breach of an OT component can result in downtime of one of these critical systems. Understanding the security posture of these devices and implementing a protection strategy can be tricky though since, unlike traditional enterprise technology, OT devices are often not selected and configured by the person, team, or third-party responsible for the security of these devices.

Instead, when a new facility is designed or an existing one embarks on a project to update or expand, an engineering or architecture firm is likely hired to produce the engineering specifications. These specs define the technical basis for all the construction involved in the project – from pouring concrete to running electrical to selecting the components for these critical infrastructure systems.

Why Cyber Security is Often Overlooked in Engineering Specs, and What to Do About It

While the facilities engineering group responsible for keeping critical infrastructure systems running is typically involved in conversations with the firm developing the engineering specs for these facilities, cybersecurity is often outside their scope. This usually results in extremely general requirements for security for OT devices in the engineering specs (if it’s mentioned at all).

Since contractors bid on work based on the engineering specs, among other RFQ documents, not providing detailed cybersecurity requirements puts the security of these critical systems at a severe disadvantage even before they are built. For example, if changing all default passwords on the OT hardware is not outlined in the spec, and one of the firms bidding on the job recognizes this as a security issue and includes this work in their bid, that firm will likely lose the bid, especially since most government organizations by law must select the lowest bidder for a project. By leaving OT cybersecurity requirements vague, or not addressing them at all in the engineering spec, it may actually disincentivize contractors from addressing possible cybersecurity vulnerabilities that would add time and costs to the project scope.

So how can you avoid this issue and ensure the engineering spec for your facility’s next project provides detailed cybersecurity requirements in line with your desired cyber posture? In short, security should be treated as a technical parameter that needs to be covered by the system provided, which means the spec needs to speak to how all OT devices in the system should be set up and executed.

Below are some suggestions based on our experience for how you can use the engineering spec to ensure your facility’s desired cyber posture is considered for any OT hardware selected:

1. Require vetting of vendors who will access the network by including a requirement for all vendors to complete a supply chain risk questionnaire during the bidding process.
2. Lean on existing sources such as standards specifically designed for OT cybersecurity like ISA/IEC 62443 or the NIST SP 800-82 series.
3. Identify and define the pieces of the OT computing infrastructure that fall under the scope of the project such as domain controllers, the DNS network, central services, or remote access.
4. Use prescriptive specifications to get what you want security wise. For example, instead of simply saying network switches shall be provided as part of the system, specify the exact devices the vendor must use.
5. Define the operating system and application-level security you want on the devices – rather than saying all devices will have security applied, lay out the details of the permission scheme that needs to be carried out across all systems.
6. Aim for your requirements to be testable and require testing as part of system acceptance.

For more details on how you can ensure cybersecurity measures are covered in engineering specifications, watch my recent presentation, Operational Technology in Public Infrastructure: Procurement Challenges and Solutions.