Segmentation and Firewall Rules: How to Talk to IT About the BAS Network

Most of the security problems I find on building systems don't come from anything clever. They come from a controller, a supervisor and three hundred office laptops all sitting on the same flat network, where anything that can reach one can reach them all. Fix that, and most of the other problems get smaller.

The good news is that segmentation is mostly a conversation, not a project. IT already knows how to build VLANs and write firewall rules. What they usually don't know is what the building system needs, and they can't approve a rule nobody has written down. That part is our job. This article is about doing it well: explaining the risk in terms IT recognises, listing the flows the BAS really uses, and handing over a request they can say yes to.

Why a flat network is the core risk

BACnet/IP and Modbus TCP were designed to trust whoever is on the wire. There's no login on a read or a write. (The article on why BACnet and Modbus have no security goes into why.) That's workable when the only things on the wire are building controllers and the people who look after them. On a flat network, the "wire" is every desk, every guest device that got onto the wrong SSID, and every PC that clicked the wrong email attachment.

Flat networks also cut the other way. A broadcast storm from a misconfigured BBMD, or a controller that floods the segment when it fails, now lands on the office network too. IT gets the outage, and the building system gets the blame. Segmentation protects both sides.

Zones and conduits: borrowing IT's vocabulary

The IEC 62443 series gives us two words that make this conversation much easier. A zone is a group of assets that share the same security requirements — say, the BAS controllers and supervisor. A conduit is a defined path between zones, with the traffic allowed through it spelled out. (There's a plain-language tour of that series in IEC 62443 and NIST for BAS techs.)

You don't need to cite the standard to use the idea. On a typical commercial building, a sensible first cut looks like this:

• BAS controller zone. Field controllers, routers, IP-to-MS/TP gateways. Their own VLAN and subnet. Nothing else lives here.
• BAS supervisory zone. The supervisor, operator workstations, maybe a historian. On larger sites this is separate from the controllers; on small sites it's often the same zone, and that's a reasonable call.
• Corporate zone. The office network, where the facilities staff's laptops live.
• Remote access. However the vendor and service contractor get in — ideally through something IT runs, covered in remote access without opening the building to the internet.

Between each pair of zones there's a firewall (or at least a routed boundary with access control lists), and the conduit is the short list of flows allowed through it. Everything else is denied by default.

What the BAS actually needs to talk to

This is the list IT needs, and it's the one most contractors can't produce on the spot. Build it before the meeting. The BAS Port Reference has the defaults in one place; confirm each against the products on the job, because vendors move things.

Notice what's missing. There's no "any to any". There's no inbound from the internet. And there's rarely a reason for the corporate zone to reach a controller directly — operators should come through the supervisor, and the supervisor should be the only thing that talks down to the field.

Broadcast-based BACnet/IP across subnets needs BBMDs or foreign-device registration, which means UDP 47808 between specific BBMD addresses, not between whole subnets. That's worth spelling out, because "open 47808" is the kind of request that ends up as a rule covering the entire building. BACnet/SC is simpler here: one TCP port to the hub and the failover hub, no broadcasts, no BBMDs.

Writing the firewall rule request

A rule request IT can approve has five things in it. Leave any one out and it comes back to you, usually a week later.

I also add a sixth field when it applies: temporary or permanent. Commissioning often needs a laptop to reach everything for a fortnight. Say so, and give an end date, rather than letting a commissioning rule become the permanent design.

What to push back on

Working with IT isn't the same as agreeing with every suggestion. A few requests come up repeatedly that will break the system or leave it worse off, and it's fair to say so politely and explain why.

• TLS inspection on BACnet/SC flows. A firewall that decrypts and re-signs traffic replaces the hub's certificate, and SC's mutual authentication will refuse it. Ask for SC flows to be exempted. (More in BACnet/SC troubleshooting.)
• Short idle timeouts on long-lived connections. SC connections and some supervisor links stay open for days with periodic heartbeats. A firewall that drops idle sessions after a few minutes causes reconnects that look like device faults.
• Blocking UDP broadcast within the controller zone. BACnet/IP discovery depends on it. Contain broadcasts to the BAS zone; don't kill them inside it.
• Moving controllers onto DHCP. BACnet/IP devices and BBMD tables usually expect fixed addresses. Reservations can work; plain dynamic leases generally don't. SC nodes are the exception, since they connect out to the hub by URI.
• "Just put it on the guest network". Sometimes offered as a quick way to separate the BAS. It usually means client isolation, captive portals and nobody monitoring it. Ask for a proper zone instead.

And equally, don't push back on the things IT is right about. "We need the vendor's remote support tool to stay installed" and "the BAS has to be able to reach the internet for updates" are usually not true, and they're the kind of claim that costs you credibility when IT checks.

The questions IT will ask

Have answers ready for these. "I'll find out" is fine for one or two; it isn't fine for all of them.

Doing the cut-over without an outage

Re-addressing controllers mid-occupancy is how segmentation projects get a bad name. A few habits keep it boring:

• Capture the baseline first. Point lists, device instances, BBMD tables and a backup of every controller database, taken the week before.
• Move the boundary, not the devices, where you can. If the BAS already lives on its own subnet, IT can often put a firewall in front of it without anyone touching a controller address.
• Start with logging, then enforce. Ask IT to run the new rules in a monitor or log-only mode for a week if their firewall supports it. The hits tell you which flows you forgot.
• Test from both sides afterwards. Check the supervisor still sees every device and every trend is updating, and check that a laptop on the office network can't reach a controller. The second test is the one people skip.

The Subnet Checker helps catch the mask and gateway mistakes that tend to appear during re-addressing.

The takeaway

You don't need to be a network engineer to get this right. You need an asset list, a flow table and a willingness to write down the reason for every rule. Do that, and IT will usually meet you more than halfway, because you've handed them the part they couldn't do without you.

Found a wrong number or a broken link? Tell me and I’ll fix it.