Securing Read-Only BACnet Data Access for Analytics

The analytics business case is usually easy and the security conversation is usually late. By the time somebody from IT asks what exactly this new platform can do to the building, the connection is built, the contract is signed, and the honest answer is that nobody has checked. The uncomfortable part is that on most building control networks, a client that can read can also write, and the difference is a matter of what it chooses to do rather than what it is permitted to do.

The message up front: read-only has to be enforced somewhere other than in the analytics platform's own good behaviour. The practical options are a network boundary that only permits the traffic you intend, a gateway or middleware that exposes a read interface and holds the BACnet connection itself, and device-level restrictions where the equipment supports them. Combine at least two, log what the connection actually does, and prove the claim by inspecting the building afterwards rather than by reading a datasheet.

1. Why read-only is harder than it sounds

Several properties of a typical building control network combine badly here.

• Older control protocols were designed for trusted networks. They assume everything on the wire belongs there. Authentication and authorisation were not part of the original model, and where modern secure variants exist they require devices that support them, which an existing estate largely will not.
• Reading and writing use the same connection. A client that can request a value can usually also command one. Nothing structural separates the two.
• Commandable objects accept writes by priority, and a write at a high priority will override the building's own logic indefinitely until released, as described in BACnet objects, device instances and addressing. A single careless write is not a transient event.
• Discovery traffic is broadcast, so a client on the network can enumerate the estate without being granted anything.
• Vendor tooling often shares the connection. The same path used for analytics may be the path a contractor uses for engineering, with very different intentions.

None of this is a flaw in anyone's product. It is the consequence of operational technology designed for isolated networks now being connected to things.

2. Where the restriction can actually be enforced

The gateway pattern is the one I would reach for on an existing estate. It converts an unanswerable question, can this platform write to the building, into an answerable one: the platform cannot speak the building's protocol at all, it can only call an interface you defined, and that interface has no write operations in it.

3. The network boundary

• Segment the control network so building devices are not reachable from general corporate space, and so the analytics host reaches only what it needs.
• Permit by explicit allow-list: named source, named destinations, named ports, one direction. Anything broader is a convenience that will be inherited by whoever comes next.
• Account for broadcast traffic. Discovery and the broadcast forwarding described in the addressing article cross subnets through specific mechanisms, and those are part of the attack surface as well as part of how the system works.
• Document the rules in the building system's own records, not only in the firewall. A rule whose purpose nobody remembers is a rule that gets removed, and a removed rule here produces the outage described in the connectivity loss playbook.
• Get building networks into the IT change process. Most connectivity incidents on building systems originate from a change made by people who did not know the building depended on it, which is the wider argument in BMS cybersecurity for connected buildings.

4. Identity, credentials and access

• A dedicated account for the integration, never a shared engineering login and never the contractor's. A connection using somebody's personal credentials dies when they leave, and cannot be audited meaningfully in the meantime.
• Scope it to what it needs, where the platform supports scoping, following the role model in RBAC design for CAFM systems.
• Credentials held in a managed store, rotated on a schedule and on any supplier personnel change, with the rotation procedure written down before it is needed.
• Remote access for support handled separately from the data connection, time-bounded and logged, rather than leaving a permanent path open because it is convenient during commissioning.
• An explicit decommissioning step. When the analytics contract ends, who revokes the account, closes the rules and confirms the path is gone. This belongs in the exit terms discussed in BMS service contracts.

5. Proving the claim

Documentation is not evidence. Three checks, all cheap:

• Priority array snapshot, before and after. Record the priority array of commandable objects in scope before connecting the platform and again after a period of operation. Any new entry is a write. This is the single definitive test and it is described in the BACnet integration acceptance test checklist.
• Out-of-service sweep. Confirm nothing was placed out of service, which is a different way of interfering with the building and leaves a value looking normal.
• Traffic observation. Where the network allows it, confirm from the boundary what the connection actually sends rather than what it claims to send.

Repeat the first annually. Writes accumulate from projects nobody mentioned, and an annual inspection is the only thing that finds them.

6. Logging and monitoring the connection

• Log connection establishment and failures at the boundary, with source and time, so that an unexpected source is visible.
• Alert on write attempts, even rejected ones. A rejected write from a read-only integration is a significant event, and it usually means a configuration change somewhere.
• Monitor volume against the expected profile. A sudden increase can be a misconfiguration, and it can also be the collection regime problem described in BACnet polling schedules.
• Review quarterly, with an owner. Logs nobody reads provide evidence after an incident and prevent nothing.

7. What to ask a supplier, in writing

• Does your platform hold the control-protocol connection directly, or consume an interface from a gateway?
• Which protocol services does it use, and are any of them write services under any circumstance, including during commissioning or support?
• What credentials and network access does it require, as a specific list rather than a range?
• What does it log about its own activity, and can we read those logs?
• What happens to the connection and the stored data at contract end?
• Will you accept a before-and-after priority array inspection as an acceptance condition? The answer to this one is informative regardless of what it is.

The idea to walk away with

Read-only is a property of the architecture, not of the platform's intentions. If the thing holding the connection is capable of writing, then the restriction is a setting in software you do not control, and no amount of contractual language changes that.

So put something between the platform and the building that structurally cannot write, constrain the path at the network boundary as well, give the connection its own identity, and verify the claim by inspecting the building rather than by reading the documentation. The priority array inspection is the whole proof, and it takes minutes.

Final thoughts

If you already have an analytics or monitoring platform connected and have never checked, the useful first question is not about firewalls. It is simply: what is holding the BACnet connection. If the answer is the analytics platform itself, you now know the shape of the risk you are carrying, which is more than most estates know.

The second question is whether anyone has ever looked at a priority array since it was connected. In a reasonable number of buildings that inspection finds at least one write nobody can account for, and finding it deliberately is considerably better than finding it during an investigation into why a plant item has been ignoring its schedule.

Related reading: BMS cybersecurity for connected buildings, BACnet acceptance test checklist, BACnet objects and addressing, RBAC design for CAFM systems, BMS service contracts, Connectivity loss playbook.