Hey folks, Phil Zito here and welcome back. In this post, we are going to start a 3-part series on how to secure your building automation system. So, in this post, we are going to explore potential threats to building automation systems, how to assess risk, and common cybersecurity controls. This is mainly going to be a conceptual post and then the next two posts, we're going to get a little bit more hands-on, with the third post being very hands on. Be sure to read all 3 posts because if you skip this post, you won't understand most of the concepts. So, definitely don't skip this post.
So, a little background here. As far as I can remember, up until probably around 2014-2015, cybersecurity really wasn't that big of a deal to building automation systems. That is because primarily, we were a serial network. So, field bus network, with maybe a couple IP devices. We had a server and maybe a couple supervisory devices, but by and large, our exposure to risk was fairly low.
Now, fast forward to 2022 and we've seen all of these malware attacks, or malicious software. We've seen all of these malware attacks on industrial systems, power systems, etc, and if you actually dig a little deeper, there are attacks on control systems.
Now, I often hear from folks say when we're talking about cybersecurity, that they don’t often hear about building automation systems being hacked, so why should they care? Well, the issue with that is that building automation systems, their attacks happen, but they're often not reported.
This brings us to understanding how attacks are reported and how vulnerabilities are reported, and it's going to be the first area we’re going to dive into. Then we're going to look at risk, and finally we're going to look at cybersecurity controls.
So, as far as how risk is reported, when we are concerned about how attacks are reported, when we're concerned about vulnerabilities or attacks, my first place to go to is ICS-CERT. When you go there, will find alerts, advisories and reports.
- Alerts are critical infrastructure issues, threats that could hit critical infrastructure of which building automation, we serve a lot of critical infrastructure. We are serving healthcare, data centers, serving schools, government, municipalities, etc.
- Advisories are where we can start to dig into potential cybersecurity risks with a specific building automation system. Now, the easiest way to do that is to look at ICS-CERT advisories by vendor, and then find whatever vendor it is that you are concerned with. ICS-CERT is going to tell us what vulnerabilities exist.
Now, if you were to look at ICS-CERT, about six years ago, there weren't a ton. It happened that there was a cybersecurity researcher named Billy Rios, who happened to find a pretty common vulnerability in a building automation system. He was able to log in and mess with some graphics, and some set points and stuff. It was a pretty easy vulnerability to fix, but it became all the news for three reasons:
- This was a major vendor, and all the competing vendors were like, “Hey, let's point this out, while fixing our systems, because they're vulnerable to the same thing.”
- This guy was trying to create a consulting practice for himself in what is was a green-filled environment. It was an environment of which there weren't really any cybersecurity consultants for building automation. There were tons for SCADA there, which is industrial controls, but there weren't really any for building automation at the time.
- Control systems at the time were going IP. They were going much more web based, and so their exposure on things like io allowed people to detect these building automation systems that were running on legacy systems that were on the network. If you’ve never been on Shodan.io, you can actually search by vendor, you could type in the name of the software, and you can see publicly exposed building automation systems.
So, you have these three things colliding in the 2016-17 timeframe, and all of this is bringing to attention this focus on cybersecurity.
Okay, so what naturally happens in the building automation world, as far as product creation and cybersecurity goes? Well, typically the OEMs will have a couple really large contracts. In most cases, those large contracts and large customers, they make up a big portion of the OEM’s revenue, and because of that, they have a loud voice when it comes to product creation. So, with this product creation, you start to see a big focus on cybersecurity, because naturally, these large government and private sector companies are focusing on cyber, and they start to expect that from their controls companies.
So, on one hand, you have this new interest in analyzing building automation software, because of potential risks, the potential market for cybersecurity consultants, and on the other hand, you have all these organizations becoming more cyber aware, and they're now demand that OEMs have more cybersecurity controls. All of this comes together, and equals more monitoring on control systems, which now leads to more ICS-CERT alerts, it leads to adoption of the NIST 800 framework, specifically 853. For controls, that can be used around building automation systems, and so you're starting to see this new focus.
Now, why do I have this three-part series going on right now? Well, we live in a world right now where there is an increased concern about cyber-attacks, and we saw the pipeline on the east coast go down, we saw meat factories be affected, so we know that industrial systems are being attacked. Earlier in this post, I mentioned that a lot of building automation systems get attacked, but don't get notified, and that is because the notification rules for breaches and attacks, especially at smaller buildings, don't really take effect. There's no real overarching rule that you must report if you've been cyber compromised until you get to hospitals and things like that.
Additionally, as you dig into these types of attacks, you'll start to realize that a lot of compromised attacks, people aren't aware. I mean, the Target attack went ignored for a long time, as well as the Home Depot attack. Those were the point-of-sale attacks because people were ignoring the reporting.
Now let's talk about the attack process touching on our potential risks, how to assess that risk, and then we'll talk about common security control categories. Over the next couple posts, we'll dive even deeper into securing your building automation system.
Alright, so here's how an attack will typically happen. First thing that will happen is what is called reconnaissance. Now, reconnaissance can be active reconnaissance and can be passive reconnaissance. They can Google “Facility maintenance tech at ABC hospital needs to work on ABC system version….” By doing that, they've started to figure out what kind of control system that hospital has in place.
Now, once they've done that, they can move to their reconnaissance phase where they can kind of figure out what they're going to attack and if it's worth attacking. This is where they can do things like running Nmap. Nmap is a software that can do analysis, it can analyze the protocols that are speaking, it can see what ports are open on a machine, it can figure out exactly what the exposure is and what the attack points are at a site.
So, from there, they will make an attack and an attack could be compromising via phishing, via emails, it could be taking advantage of some sort of software compromise, or maybe taking advantage of a race condition. That's where memory works faster than CPU or CPU works faster than memory and thus, they're able to insert malignant code, or bad code. Once they've done that, they will then use that to establish a foothold.
Now, typically, except in the area of ransom, where they're locking down your control system, control systems are used as pivot points. What they're really after are business systems, hence why, if you've ever wondered why IT is so firm about having a dedicated network for control system, why they want things isolated, it has to do with them being concerned of someone moving laterally, from your building automation network, to the production network, maybe to business network, maybe to finance network, accounting network, etc.
So, what they will typically do, except in the case of ransomware, is they will establish what is called a foothold. From there, they will either do a lateral move to another system, or they may use ransomware. Then the cycle just continues. They'll use your BAS as a platform to recon other business systems, and once they recon those other business systems, they move laterally to then do whatever they have to do.
So, as a building automation professional, we have to ask ourselves, what risk do we have of that happening? I see a lot of folks out there who are pushing the same level of cybersecurity controls, which by the way, cybersecurity controls, those are technical, administrative and physical measures that are taken to limit the potential, either for an attack or to the reduce the severity of an attack. Sometimes you can't eliminate an attack, but if you have proper detection in place, you can at least detect it sooner, and you can limit the severity. These cybersecurity controls, they are in response to risk.
So, if I could give you one piece of advice, and it's a long piece of advice, but it would be to understand the NIST 800 framework. The NIST 800 framework is the National Institute of Standards and Technology. They created a standard known as NIST SP 800, which is a special publication, and it's a series of documents. The most common document being the 853, which is where all of the cybersecurity controls are listed.
You want to dive into this document and NIST 830 is the Guide for Conducting Risk Assessments. Most of you, I would say 95% of you, do not need to conduct a risk assessment. You can pretty much, through common sense, tell what risk exists. If you're in a hospital, that is a more likely target than Jimmy Bobs 2-story office building.
That's probably not a high-risk target.
The whole point of risk assessments and establishing a risk value to your assets is going to help you determine what level of controls you want to put in place. Now, I tell you all of this, so that you understand how the cybersecurity folks think at your customer site, because in reality, as we'll see, in parts 2 and 3 of this series, you are going to do a couple simple things that will mitigate a lot of attacks. That being said, I still want you to understand this because if you ever do DoD work, if you ever do any sort of large private sector work, understanding how risk assessments work, understanding how cybersecurity people are going to look at your systems is going to be important.
So, you go through the NIST 830, and you're able to assign a risk value to potential threats. Based on the cost of impact of that threat, both in the impact to business continuity, in the monetary cost, etc, that then adds up to a threat value. You can implement controls, potentially up in cost, potentially up to that threat value. That's how you determine that.
Now, as I mentioned, there's three primary areas of controls, and those are administrative, technical and physical. The easiest ones for us to implement are physical and administrative. Technical usually requires the customer, except for a handful of things like using encryption, certificates, patching, etc. As I was mentioning, though, administrative and physical are the easiest things.
So, I've often run into customers who are like, “Hey, your system needs to be super cyber-secure,” which I don't know what super cyber-secure means. So, we'll take that at face value. But what I say to them is, “Cybersecurity and technical controls do not matter if the system's not physically secure, and you don't have good administrative policies.”
So, I want to give you a helpful tip that you can use today, right now: Physical security and administrative security controls you can implement right now to make all of your systems and installation safer. What do I mean by that?
- Physically, making sure there's a UPS (uninterruptible power supply) on the server, making sure the server is in a data closet, making sure that your panels actually have unique keyed locks on them, making sure that wherever you put your control systems, the IP control systems that can be compromised, that they are actually secure and isolated from outside folks.
It doesn't matter what level of cybersecurity you have if I can physically get to your machine. There's a saying in the cybersecurity world that if you can physically access the machine, you can compromise it. It's just a matter of time till you can compromise it if you can physically access it. So having our physical access secured is critical.
- The second is administrative. We've all seen everyone share usernames and passwords. We've all seen poor passwords. We've all seen people browsing ESPN, or whatever the fantasy football team website of the day is, on the server. So not having proper administrative controls like internet use policies, password policies, unique passwords, password reset policies, not having those things implemented, is going to make your control system less secure.
So right off the bat, just implementing those two things is going to make your control system more secure today.
So, how do we assess risk so that we can make a decision? Well, this is where it becomes really difficult for control systems, because there's not a lot of data around control system breaches. So, for us, there's that term actuary tables, when they do a risk assessment on you from an insurance perspective of whether you're going to die based on your lifestyle. So, we don't really have actuary tables for control systems, and that in itself becomes a problem. We know we need to assess risk, but we have nothing to base that risk on.
So, what I like to do is I like to look at the industrial tables. You can Google “likelihood of cyber-attack, industrial control systems.” When you do that, you're going to come up with a couple of websites. FireEye has a good PDF on it. Packet Labs has a nice little data sheet on it. Based on that, you're able to see the likelihood of attacks on specific vertical markets like healthcare, industrial, shipping, transportation, etc, as well as what kind of attacks happened in the controls to mitigate them.
So, once we do that, once we figure out which sector is likely to have this kind of attack, then we're able to put a percentage on that. We're able to say that healthcare is likely to have a ransomware attack because it has private health data, it has a data breach. It is not likely to have a DDoS, which is a distributed denial of service attack, which basically brings down the network. So, you're not likely to have a DDOS on health care, but you are likely to have a data breach so that people can collect private data.
Now you have to ask yourself, if someone wanted to collect private data, and they wanted to use my building automation system as a foothold to do that, how would they do that? Well, first, they would have to compromise my server. So, you know, I see all these people wanting to secure their field level networks, but I would ask myself, what has an operating system that can be used to pivot? That's typically my supervisory devices, and my servers.
So, how do I mitigate those risks? Well, closing unnecessary ports, patching my software, keeping my software up to date, keeping my servers secure, and not running unnecessary services. So, I'm able to look at the potential risks that I found in that industrial table and identify that the percentage of that happening is x, so what would it cost my company if my building automation server was used to compromise 10,000 patient data records? I used to be able to look up “cost of record compromise cybersecurity,” or “cost of individual personal health,” and there would be an easy per person chart. If I remember correctly, it was like $50 a record that you could get sued for, but I'm not 100% sure on that. But you can see how it adds up. So that's kind of the math you do in your head and then that's how you determine what level of cybersecurity controls you put in place.
Here's the real simple answer to things: If you were saying, “Phil, for 95% of the sites, what should I do?” I would say, “Have a password policy, have unique usernames and strong passwords, have your systems locked up, have them patched, have certificates installed, and turn on HTTPS. I mean, if you do those things, you will be ahead of the curve on most of the people, and we'll talk more about those kinds of controls in the next two posts.
Alright, so through this post we've talked about potential threats. So far, we've talked about our threat around compromise for data stealing. Now we're going to look at our threat for direct denial of service. So, depending on if you're doing an airport, or maybe you're doing a local government or school district, this is where DDoS could potentially come into play.
What happens is with DDoS, a bunch of computers get malware on them. That malware allows people to remotely control those computers, and then with that remote control of the computers, they send data packets to your exposed server. So, if your building automation server isn't exposed, you're less likely of a risk to DDoS.
What they'll do, they will send a flood of packets and then the server cannot handle all the packets, and it will shut itself down. You've seen this happen a couple times lately, where you had web service providers shut down. Most recently, I think it was a DDoS against the domain naming servers. So, you saw Yahoo go down, Pay Pal, and a couple of other sites. I believe that was last year, maybe the year before.
So, DDoS is a potential attack, but it's not the one I'm most concerned about. The one I'm most concerned about is not ransomware, is not DDoS, and it's not compromising for escalation. The one I'm most concerned about is disgruntled employees. So, what I see on a lot of controls, companies, and a lot of sites is people not actually shutting off credentials as soon as someone leaves. So, people still have access to the building automation system.
Now, what that means is they could change set points. We've all seen where you have all your K factors on the graphic for your calibration factors for test and balance, and someone changes those and there's no record of the change because you have no auditing enabled on your control system. None of the records are written down and there's no backups. So, now this person, by just changing all the K factors, or changing set points, has really hosed up your system, causing you to have spend 1000s, if not 10s of 1000s of dollars, bringing a system back up.
So, that is the thing, that if I were a control system provider, that's what would keep me up at night. I'd be less worried about ABC country deciding to attack my control system. There definitely is that risk if you're like DOD, or healthcare, or maybe some sort of large private institution, but for most folks, I would look at purposeful or accidental user compromise and user damage to your building automation system. That would be my biggest worry of a threat. So those are the primary threats.
We've talked about how to assess risk and we've talked about some common cybersecurity controls that you can implement. We're going to dive even deeper into those in the next two posts. I hope this has been helpful. I hope this kind of gave you a history of cybersecurity in the building automation world, gave you an understanding of some basic terminology, and gave you an idea on a couple things you could do right now that would be beneficial to your control system.
Thanks a ton and take care.
