Do You Know How and What Your Smart Building Devices Are Connected To?

Okay… Your control system was installed a couple of years ago and you were handed riser diagrams, As-Builts, mechanical drawings, etc. and you were good to go.  Right?


Up until recently the standard implementation for a controls network was created by the integrator and given either a 192.168.X.X or 10.0.X.X IP schema.  In some cases the only way to access the system was from a PC on the same network.  In other cases the control network did not touch the corporate network, but it was accessible remotely.  This was done by purchasing a router/VPN from a big box electronic store and your ISP (internet service provider) supplied you with a public IP to access your front-end from anywhere in the world.

But is that still the way it is setup?

If it is, it is the right way?  Or it may have been set up correctly, but because of zero change management and oversight, your control network and corporate network have converged or holes have been punched in your security.

The following examples are possible representations of what a control network may look like or maybe what is has become after a few years of “a change here” and “a change there”.  It is important that you know your control system network configuration and keep your documentation up-to-date.

Example 1 – The control network was originally air gapped (physically separated from the corporate network) and the only access was via a public IP to front end.  The public IP put the control system in jeopardy by itself.  At some point in time a second network card was added to the front-end and connected directly to the corporate network.  By doing this there is now a hole punched into the corporate network and it can be used as a pivot point to access company systems.

‍Example 2 – The control network and corporate network are air gapped.  There is no physical connection between the two. However, the control system is exposed to the world with a public IP.  The leaves the control system vulnerable to have infected payloads ready and waiting for anyone who accesses the system.

Example 3 – Everything in this example is behind the corporate firewall and is seemingly safe.  It has been my experience in some cases that the control system front-end is highly accessible and is used to check email, social media, etc.  This practice can either cause the front-end crash or a means for a threat actor to inject malware for data mining, command & control, etc.

For more examples and diagrams, click here.

‍If you haven’t reviewed your control system network architecture in a while, I suggest you do.  If you don’t have change management in place, you need to.  If you have any segment of your control network exposed to the world, work with IT and get it behind a high quality firewall.

The BlackHats are looking and probing and they have plenty of tools available to them to find you.  Let’s not make it too easy for them.