行业观点：智慧建筑OT网络安全应纳入楼宇自控设计规格文件

The specifying engineer’s role in secure smart buildings

October is Cybersecurity Awareness Month, and I’d like to bring the conversation into the design development meeting in the consulting engineer’s office.

When we specify a building automation system, we spend a lot of time on sequences of operation, equipment performance, graphics, and interoperability. Those details matter, but we should give the same attention to how people (operators, vendors, etc.) and applications will access that system once it is connected.

Things such as… Who can log in? What can they reach? Who approves a contractor’s access? And who removes that access when the work is finished?

These are questions we can address while the project is still in the design development stage.

In my role at Cochrane Supply & Engineering, my focus includes helping the design community understand building IoT, integration, and OT cybersecurity. Through our website SmartBuildingDesign.com, we help connect those conversations to architecture and guide specifications engineers can use.

My message to specifying engineers is straight forward… Cybersecurity belongs in the design documents!! A clear and concise specification gives the project team something to price, implement, and verify.

Start with the people who will operate the building

Before selecting platforms or writing cybersecurity requirements, it’s always best to bring the owner’s Facilities and IT teams into the conversation. Both parties should participate in these meetings jointly as a team, so that technologies can be vetted, and cyber security best practices can be implemented that are in alignment with the Owner’s IT department’s standards.

Facilities need dependable operation and timely service. IT needs visibility into connected systems and control over access. The consulting engineer needs enough information from both to develop a workable design.

I would start with a few practical questions. Which systems need to exchange data? Which contractors need remote access? Does the owner already have an approved remote access policy? Who will manage accounts, software updates, and backups after turnover?

Record those answers in the Owner’s Project Requirements. When responsibilities remain undefined, contractors are left to make assumptions, and the owner inherits the result.

This collaboration is what I call Cyber Harmony. It means the people designing, installing, protecting, and operating the building agree on how it should work.

Make the architecture visible

Most engineers and systems integrators think in pictures! One of the most useful tools that an engineer can provide in clarifying the overall architecture is a systems integration drawing.

The drawing should show the connected systems, integration platform, OT network, enterprise connections, cloud applications, and remote access paths. It should identify where data moves, where access is controlled, and who owns the major pieces.

For example, if a cloud application needs meter data, show the approved path for that information. If a controls contractor needs to service the Niagara supervisor, show how that connection will be authorized and controlled.

Document read access and command access separately. An application that displays equipment data has different permissions from one that changes setpoints.

The drawing and specification should support each other. The drawing explains the architecture; the specification establishes the requirements for delivering it. Together, they give the engineer, owner, IT team, and integrator a common reference.

Turn Zero Trust into practical requirements

Zero Trust can sound intimidating until we apply it to a familiar service call.

A technician needs to troubleshoot an air handler. We should be able to verify the technician’s identity, authorize access to the equipment needed for the job, and record the access activity. That permission should be reviewed or removed when it is no longer needed.

NIST’s Zero Trust guidance explains that trust should not be granted simply because a user or device is inside a network or belongs to the organization. Authentication and authorization must govern access to resources.

For the consulting engineer, that translates into requirements such as individual user accounts, multifactor authentication for remote users, permissions based on job responsibilities, and defined procedures for granting and revoking access.

It also means specifying controlled communication between systems and making access records available to the owner.

Existing buildings require practical judgment. Some legacy controllers cannot support modern identity or encryption capabilities directly. The design must account for that limitation through appropriate gateways, segmentation, and access controls. Remote access is a useful place to begin applying Zero Trust, with the broader architecture addressing application and device access as well. The engineer should familiarize themselves with easy to specify platforms for zero trust remote access if the tools are not already in place and it is your responsibility to include remote access in your design documents.

Design the Secure by Design OT Stack

The Secure-by-Design OT Stack is a way to organize these decisions across the building’s technology architecture. Each layer has a job, and the interfaces between layers need the same attention as the products themselves.

The secure edge controls connections into and out of the OT environment. NEEVE is an example of a platform that supports Zero Trust remote access, role-based permissions, and auditing. The engineer should establish the required access behavior, deployment responsibilities, and owner acceptance criteria.

The enterprise operating platform brings building information together for operators and portfolio teams. KODE Labs is an example of this layer. Specify the data it will receive, the applications it will support, and whether it is permitted to issue commands. Define ownership of the data and management of application credentials.

The open integration fabric connects systems and organizes their information. Tridium Niagara provides an example of this role. Engineers should define the required protocols, integrations, naming, tagging, and permissions so that openness supports an architecture the owner can understand and maintain.

The hybrid OT network connects the field equipment, controllers, gateways, and supervisory systems using the appropriate wired and wireless infrastructure. Its design should establish system boundaries, permitted communication, device hardening, and support responsibilities.

Selecting these layers is the beginning. Their configuration, integration, and ongoing management determine how effectively the architecture protects the building. Engineers can use the stack to identify gaps and assign responsibility for closing them.

Write requirements that can be delivered

A sentence such as “provide a secure BAS” leaves the project team with too many unanswered questions. Give bidders requirements they can understand and include in their scope.

At a minimum, I would want the specifications to address:

An asset inventory and documented network architecture.
Approved remote access methods and account management.
Removal of default credentials and unnecessary services.
Segmentation and permitted communication paths.
Responsibilities for updates, vulnerability response, and product support.
Backup, restoration, logging, and turnover requirements.

Coordinate those requirements across the relevant sections of Divisions 23, 25, 27, and 28, with project-wide responsibilities established in Division 01 where appropriate.

Be clear about the controls contractor’s scope and the master systems integrator’s scope. For example, the controls contractor may install and program the BAS, while the integrator delivers specified integrations, tagging, and owner applications. The documents should identify who configures and verifies the security controls at their interfaces.

Updates and testing also need to fit building operations. NIST’s OT security guidance recognizes the importance of performance, reliability, and safety. Define how changes will be evaluated, approved, and scheduled with the owner.

Commission what you specify

As a commissioning authority, I want a requirement to lead to a demonstration.

If the specification requires limited contractor access, demonstrate that the contractor can reach the approved system and is blocked from reaching unauthorized systems. If access must expire, verify that it expires. Confirm that the owner can retrieve the required access records.

Review the installed communication paths against the approved systems integration drawing. Demonstrate the agreed backup and restoration procedure in a way that protects operations.

Then verify turnover. The owner should receive the asset inventory, current drawings, configuration records, account administration procedures, and a clear explanation of ongoing responsibilities. Credentials should be transferred through an approved secure process.

Cyber commissioning gives the owner evidence that the specified protections have been implemented. Ongoing operation must keep those protections current as users, software, and equipment change.

Bring cybersecurity into your next design meeting

For engineers looking for a starting point, SmartBuildingDesign.com provides architecture resources and guide specifications to support these conversations. Use them as a foundation, then adapt the requirements to the owner and the project.

On your next project, ask the owner how remote access is managed. Bring Facilities and IT together before the architecture is finalized. Develop the systems integration drawing, put clear requirements in the specifications, and establish how the completed system will be verified.

Cybersecurity Awareness Month gives us a reason to raise the subject. Specifying engineers have an opportunity to carry it into the decisions that shape the building for years to come.

Your next set of drawings and specifications is a good place to start!!