How to Secure Your BAS - Part 2

Hey folks, Phil Zito here and welcome back. In this post, we're going to continue discussing how to secure your building automation system and we are going to be looking at a couple different things. In the previous post, we went through fundamentals, cybersecurity, talked about a couple things related to cybersecurity risks, risk assessments, controls, etc. Now we're going to look at cybersecurity capabilities of a BAS, we are going to look at and discuss the limitations of cybersecurity controls, and we're going to look at the human aspects of cybersecurity.

So, as I mentioned in the previous post, what happens in the world of building automation cybersecurity is that we start off with a potential risk. That risk is going to vary based on the type of building. So, if you have a DOD facility, Department of Defense facility, that's going to have a different risk profile than Jimmy Bob's 3-story office building. Because of that, we have to apply different levels of cybersecurity controls.

I covered the three primary types of controls: physical, administrative, and logical controls. Now, we're going to look further at controls, we're also going to look at some specific things around building automation cybersecurity standards. So, we're going to look at the building automation cybersecurity standards in regard to what the Department of Defense is promoting, and then from there, we're going to go through some basic things you can do as far as securing your building automation system and understanding what in your building automation system can be secured.

Alright, this is NIST 853 Revision 4: Security and Privacy Controls. This is a huge document, so if you’ve never looked at this, it can be very intimidating.

If you're familiar with risk classification in the DoD sphere, so if you've ever done any building automation work for Department of Defense, you know that they classify their buildings as low, medium, and high.

If you dive into the UFC, the Unified Facilities Criteria, which is kind of replacing DITSCAP and DIACAP RMF. It still has RMF built into it, which is Risk Management Framework.

If you dive into that, they take it even a step further, where they dive into the CIA, which is Confidentiality, Integrity, and Availability. So, I'm going to talk about that real quickly, the CIA triad. The CIA triad is this confidentiality, integrity and availability. The majority of what we do from a cybersecurity controls perspective, is to basically shore up those three areas.

Confidentiality is making sure that whatever is being communicated cannot be disclosed. In most cases, confidentiality is not a major concern of building automation systems. There have been facilities that I've worked on, where you ended up having to actually separate the building automation networks from the entire building. This was an electronics manufacturer, and they were worried of people eavesdropping through sound vibrations coming across the field trunks of the field controllers. So, obviously that is a physical control concerned with the confidentiality of what's going on in the building.

Then you have integrity. This is a big one for building automation systems as well as availability. Integrity is ensuring that, if I send a chiller command to 55 degrees, it actually receives a 55-degree command. That's actually how the Stuxnet attack happened. Basically, they made the centrifuges look like they were spinning slower than they actually were. Through some false values, the centrifuges kept spinning, spinning, spinning, faster, faster, faster, until they basically destroyed themselves.

Then you have availability, which is also a primary concern of building automation. Availability is the ability to have access to our resources. In our case, our building automation resources, like our servers, supervisory device.

We'll cover attack vectors for each of these a little bit later in this post, but I want you to understand that when you're working with cybersecurity folks, and when you are addressing cybersecurity issues in the building automation space, most of you, if you just have password policies, unique username requirements for each individual user, you certificate and patch your systems, and you enable HTTPS with the appropriate TLS version, then you're going to be pretty solid. But if you work with anybody like a large pharmaceutical, a large healthcare organization, or government organization, then you're going to branch into the need for potentially more intense cybersecurity controls.

Now NIST 853, in my opinion, while it's useful at understanding what controls are available, it's not very useful in how we apply the controls and how we interpret them, Which is why I like this UFC document. Why I like this is, about two-thirds of the way down, you'll start to see these controls. They directly parallel with the NIST 800 controls and controls being cybersecurity, logical, technological, physical, or administrative. So, process policy procedure that you can put in place to ensure that your system is secure.

So, you'll notice they're classified by LOW, MODERATE, and HIGH. You’ll see L-L-L and that directly corresponds with the CIA triad, confidentiality, integrity, availability. no confidentiality.

So, if you had something that was like L-M-L, it would mean confidentiality requirements are low, integrity requirements are medium, and availability requirements are low.

So, as we start to dig into these categories, there are several different families as far as cybersecurity controls are concerned. If we look at access control, what I like about this UFC standard is that it gives examples that are pertinent to building automation. So, even if you don't implement DoD level cybersecurity, even if you're not being held accountable to the UFC standard, if you're ever working with a client who is concerned about cybersecurity, they are most likely going to be implementing something along the lines of NIST 800-53 Rev 4.

If you do 800-53 Rev 4, then you start to dig into the controls. While they're not one-for-one, there are some similar controls. Where you may find yourself challenged is, how does a specific control correspond to building automation? That's where this UFC standard really shines.

It goes in here and it talks about Permitted Actions Without Identification or Authentication. So basically, what it's calling out here is that, “Some user access (local display panels, H-O-A switches) may not support authentication and necessary physical security should be considered.”

So, what are they saying here? Well, this is saying two things:

1. When you go to the BAS, to the server, to the Web User Interface, you should not be able to have access to things that are outside of your role. Whatever is outside of your role should require authentication, meaning login and users. This is why I said earlier, if you have unique usernames, you have strong passwords, and a third thing, you have unique roles and those roles have specific access to only the things they need to access, you're going to make your system more secure. So, you may have a user role, you have an engineer role, and then you have a power user administrator role, and these different roles will have different access to different capabilities.
2. Additionally, and I think this is strong, is you can have the best logical and administrative security, but if you don't have proper physical security, none of it matters. They do hammer that, and they say, “local display panels, HOA switches, etc,” so you need to put the appropriate physical security into place.

If you are working with a customer, and they say they want to secure their building automation system, but are unsure of how to do this, UFC is a really nice place to start.

Let’s look at RMF, and RMF is the risk management framework. RMF is a six-step process.

First, we categorize the system, and I’m not going to dive into how we categorize the system, but based on the system categorization, we have, low, medium, and high. A system, according to the RFC model is a five-level model.

• Level 0 being your sensor actuators.
• Level 1 being your field controllers.
• Level 2 being field controllers that are IP.
• Level 3 being field point of connection; we're talking supervisory devices and routers. (They can also argue that this is their actual IT level connection as well.)
• Level 4 being front end and IP network.
• Level 5 being any external connections.

So, you can start to see kind of the goofy little overlap in here, things that can be a little confusing. Depending on how this is interpreted, Level 2 can be your supervisory devices or Level 3 can be your supervisory device, but it's typically interpreted as:

• Level 0: actuators
• Level 1: field controllers and trunks
• Level 2: supervisory devices
• Level 3: switches and routers
• Level 4: servers
• Level 5: external connections

Why does any of that matter? Well, because if we go back to our risk management framework, we go based on categorization of our levels, we select our security controls. This is where I was saying that these security controls apply to these levels, then we implement them. So, selecting the security controls, this is engineering phase, right? This is where architect engineers are going to review and the controls contractors are going to select. So, then they get implemented and then they get assessed to ensure that they're working, and then the system gets authorized. The key part being that it's monitored.

So, if we think about this, from a parallel, which would be like an engineering approach to building out a building.

• Step 1 would be our use case mapping with an architect, so that we can kind of set aside funds to build a building. We can figure out what we want, where we're scoping the needs.
• Step 2 is selection and design.
• Step 3 would be where we have our construction documents, we're implementing.
• Step 4 would be point to point and functional test.
• Step 5 would be commissioning.
• Step 6 ongoing monitoring and support; warranty phase post.

That's kind of how this parallels to an engineer design.

So, if we dive a little deeper, we have a ton of different control families, as they like to call them, and as I mentioned, once you've defined your security classifications for your levels, then you start to select your appropriate controls. You can see that they have a lot of different controls that are listed on here, individual controls, and as I mentioned, we can see how these are implemented, how they're measured in the different parts of this process.

So far, we went through in greater detail how we do classification of our systems. We talked about what we do once we've classified our systems and select controls. I've covered the human aspects of cybersecurity. Now we're going to look at our cybersecurity capabilities of our BAS because at the end of the day, what you're going to learn as you do these controls, are the majority of these controls cannot be implemented via a building automation system. They actually require some sort of outside technology, or they require some sort of outside process.

For example, as we look at access control, we see access control for transmission medium, which is PE-4. What we're saying is that, we need to coordinate with the electrical designer for conduit requirements so that people can't physically access the transportation medium, meaning the RS485 trunk.

Now, here's the deal. That is a physical control. That is not something that you're necessarily going to set in the building automation system. There's no setting to make RS485 secure. So, what do we do? Well, it says that we can see SC-8, which will give us a little bit more clarity on this.

Physical security is going to be our answer. We're going to have to physically secure our building automation system trunks. Now that's going to require coordination with the electrical contractor, that's going to require additional cost, potentially.

So, we can see in SC-8, that “alternate physical safeguards such as protected distribution system can be employed.”

So, we'd have to understand what that means and there's a variety of interpretations to that as well.

You can start to see how these things are interconnected. Things like vulnerability scanning, something you've probably never done, but you need to be conscious that on some cases, it may be required.

Let’s look more at the access controls, because the access controls tend to be the stuff that we can implement. A lot of the integrity, a lot of the authentication is coming along, and we're gaining greater capabilities to be able to do that. But for most of us, our access control and our auditing are going to be things we’re able to implement in the control system.

We can see our access control and we can see permitted actions.

We see unsuccessful login attempts, system use notification, session locks. These are all things that can be implemented as part of your building automation system design.

You can do session timeouts, you can do session locks, you could do system use notifications, unsuccessful login attempts, least privileged, as long as you set up the appropriate roles. There are all sorts of things that you can do in your control system to make these.

Alright, so at the end of the day, how do we know if we can do these things? There's no one simple answer. It's a matter of understanding the control you're trying to implement, and then going back to your manufacturer, either through their documentation, or what I recommend, through your distributor. If you directly work for an OEM, then go directly to your regional field support manager, or your support manager, whoever that is, and ask them about the capabilities.

Ask them, “Do we support authentication between devices?” If you have BACnet/SC, there's authentication, some systems have authentication, just by default. Do we have the capability to do lease privilege? Do we have the ability to do session lock? Most modern systems do. So, this is where you would go to your OEM and you would dig in to understand how exactly you approach this, and what exactly you do.

Alright, I know this has been more in the weeds, more technical, and the reality is, for a lot of you, you're not going to work on DoD work. I know it seems like I'm sitting here saying this is important, but it's not important. But it is important.

While maybe you're not going to be doing DoD work and having to run through the UFC, or running through NIST 800 Special Publication and doing that whole NIST 830 risk assessment process, and then implementing 853 Rev-4, and implementing controls. While you may not be doing that, you most likely do have customers who could benefit from having a more secure system. Being aware of these frameworks and how to take the information in these frameworks and apply them, even in a partial application, is going to make your customers more secure. It's a value-add service that you could potentially sell to your customers or use to differentiate you from your competition.

I hope this gave you a little bit more clarity. Like I said before, please ask whatever questions you have below. I'd love to answer them for you. I know that these posts are a little more on the technical side, but it's important. Everyone out there is talking about energy, talking about green, but at the end of the day, energy can change with a simple change of whoever's in office at the time.

Cybersecurity is going to remain and become ever more important as we further distance ourselves from serial networks, moving towards IP networks, moving towards more compete at the edge. Cybersecurity is going to become increasingly important especially as hackers start to realize that they can use our systems as launchpads to make attacks into business networks and into facilities. Right now we're still very much a shielded technology set, as far as being used as an attack vector, but that will continue to change as we add more and more IP-enabled devices.

Thanks a ton and take care.