BACnet SC the case against

This is the Smart Buildings Academy podcast with Phil Zito, episode 238. Hey folks, Phil Zito here and welcome to episode 238. In episode 238 of the Smart Buildings Academy podcast, I'm going to be talking about why I believe BACnet Secure Connect is a horrible idea. Now, I want to add a little bit of background so you all understand kind of where I come from, because I'm going to say a lot of things here. And granted, these are my opinion. You don't have to agree with me. You know what? It'd be totally fine if you don't agree with me. I would love to hear your counter opinions to my perspective. Now, my perspective comes from a pretty wide background. Prior to starting Smart Buildings Academy, I was running the integration program at Johnson Controls. I would build out BACnet stacks. I would build out APIs. I worked with a slew of different data sets across multiple different buildings, systems, specialty systems, and business systems. I also have a master's degree in cybersecurity and information systems. I've designed networks. I've held Cisco certifications. I've held the CISSP certification. I've. I've done a lot in regards to technology, and I've been involved in white box and black box testing of control systems and other applications for customers back in my time at Johnson Controls. Now, I say all this not to toot my own horn, but rather to give you a perspective of my pedigree and background when I bring up these issues. Because at the end of the day, BACnet SC is not a bad solution. Architecturally, how it's created, the technologies they chose to use in it are not bad. I'm going to argue that they're not necessary, and they actually are going to complicate things further rather than simplifying things. They are going to add potential barriers with IT, and they are going to most importantly add significant project and material costs. to the industry. And we're actually moving away from where we should be moving as an industry, which is using more open data-focused models that are flexible and are decoupled from the protocol. I'll talk about that towards the end of the episode. So what is BACnet SC? You've probably seen a lot of the marketing from the OEMs coming out talking about BACnet Secure Connect. It's an answer to three problems. One, it's an answer to the BACnet BBMD routing issue. It's an answer to the BACnet clear text issue. And it's an answer to the BACnet device authentication and verification issue. And I'll talk through that once again later in the episode. Now, BACnet SC uses WebSockets, which are similar to HTTP, but not. So WebSockets are bidirectional communication, whereas if you look at HTTP, it uses post and get messages, so it's unidirectional. And also WebSockets tend to handle data flow. streaming data flow better and bi-directional data flow better. That's why you see them used in like a lot of real-time chat applications, in video games, in a lot of streaming video applications. You'll see WebSockets in lieu of HTTP APIs being used. It also uses TLS 1.3, which is transport layer security. It basically replaced SSL after SSL got some issues. Essentially, each device is going to have a certificate, and that certificate is going to validate that the device is who the device says it is, and it's going to enable encryption between endpoints. So what? What basically happens is it uses a hub-spoke methodology. There are BACnet hubs, or the SC hubs as they call them. And the SC hubs enable the devices to communicate to the hub and authenticate to the hub. And the devices can also do peer-to-peer where they authenticate using their certificate checking. Like I mentioned, you can have multiple hubs. And the hubs, see, one of the misunderstandings of BACnet SC is it still has broadcasts. You know, the whois.im is still broadcasting, but those messages are handled through hubs, which are going and sending the information. There's much more technical aspects to it, but you're not crossing subnet boundaries. it kind of decouples you from the physical isolation that is BBMDs and all of the fun stuff that causes issues with BBMDs. So you may be sitting here at this point being like, Phil, you have really not convinced me at all that BACnet SC is a bad idea. Actually, it sounds like BACnet SC is a great idea. I mean, after all, it's going to compensate for the fact that we've utterly failed in training our BAS people around IT. It's going to solve the BACnet routing issue. It's going to solve the clear text issue. It's going to really help you conform with certain government security requirements. Actually, this is one of the biggest issues that drove BACnet SC was people not being able to get on sites because BACnet's clear text and they were saying, hey, we can't have this clear text solution on our site. You need to go and have a more secure version of your protocol in order to be on our site. It's going to solve broadcast storms from poorly designed BBMDs. It's going to fix the protocol address translation issues and BBMD location issues. But is it really the best solution? Do we really need fixes for all of these issues? So first we need to understand. What are cybersecurity controls? I mean, what is a cybersecurity control? There's three types of controls. They're administrative, physical, and technical controls. If we look at building automation systems, the majority of the issues that we experience and that they reference in BACnet SC are on the technical and the physical aspects of the controls. So from a technical perspective, yes. Backnet is clear text. And in a certain context, clear text can be very bad. In a different context, clear text can be perfectly fine. And we've forgotten, or maybe we never knew, as an industry, the number one rule on cybersecurity controls. And that is that you apply the level of controls. equal to the level of acceptable risk. That's like the first thing you learn when you're getting an education in cybersecurity is threat analysis, risk profiling, and then going and assigning a value to risk based on the probability of occurrence and the impact to business continuity from that risk. And then once you've determined the actual cost of the risk, you then say, okay, I'm willing to spend this much to mitigate the risk. Now, in a DoD application, in a Tier 4 data center, yeah, maybe they do have a very, very low level of risk tolerance. They want the least amount of risk as possible. That being said, what is the majority of the assets that we are dealing with out in the built environment? Office space, K-12, some university campuses, some corporate campuses, most of which are segmented from the greater IT network. Now, let's just take commercial real estate and K-12, which are the majority of the assets we deal with. If you look at those, what is the level of cybersecurity risk tolerance at those buildings? If you say none, then you're fooling yourself. Those buildings absolutely have a very high acceptance of risk for most of those buildings because the reality is The cybersecurity risk of impacting business operations of that and the likelihood of someone attacking that system is relatively low. So because of that, the amount of cost, both in implementation and support for a cybersecurity control, should be low. But as we'll see with BACnet SC and the things it requires and the support it requires, that's not the case. Also, we are using a protocol to solve technical security issues. Think about that for a second. We are implementing BACnetSC as a stack of protocols, and we are going and mixing all this up. Yes, BACnet is an open protocol. You can go purchase the standard and you can make your own BACnet stack. But once that stack is implemented inside someone's firmware, your visibility to that stack becomes limited. So how did they implement OAuth? How did they implement WebSockets? How did they implement TLS? What if a new version of TLS comes up and now you've got a network that, because it was perceived secure... is now riding across both public and private networks, whereas before it was isolated. And we could have used different technology sets that we would have had full visibility to. that we could rapidly update in case of a security vulnerability. The thing is, whenever you bake multiple security technologies into a single protocol, into a single stack of protocols, as the case of SC, you are increasing the likelihood that one of those protocols is going to be vulnerable, and you're going to give this false perception of cybersecurity. Now, that being said, when you're analyzing all of this, if you were to use some of the solutions that I'll provide later in this episode, if one of those solutions was vulnerable, you would be able to deal with that directly. It would be much easier to check that vulnerability. Now, I know some folks are going to argue, well, a lot of folks thought SolarWinds was pretty secure, but it turned out it wasn't. Yes, you're absolutely right. But imagine if you had SolarWinds as part of a stack, and it was all built together, and in order to replace SolarWinds, it wasn't a matter of just up. dating SolarWinds, you had to update the entire firmware. Now, what kind of issue would you have? I hope what you're seeing with that explanation is by having these separated out, you can go and throttle your different levels of security. You can be aligned with customers'IT security stacks and applications. And then... If the IT security that they want is higher than what SC could have provided, great. If it's lower, that's fine too. But you aren't putting all of this stuff into a mixed bag and then relying on firmware updates and things of that nature in order to go and patch security vulnerabilities, which are coming out almost on a daily basis. But one of the bigger issues I see is that we're trying to use a protocol to solve poor design issues, poor flow regulation issues, and poor FISEC issues, physical security. One of the things you'll often hear folks say is, if I could go into the building and I got access to your BACnet network, I now have access to your network and I could do all sorts of bad things. And the issue should not be... that BACnet is insecure and that they got access to the network. The issue should be that they are physically in the building connecting to a network and your FISEC completely failed. FISEC is physical security. There's this concept of the onion, the security onion. And so you have perimeter FISEC, you have entryway FISEC, and then you have restricted areas. And, you know, it goes further and further. the fact that they're able to gain access physically to these assets shows multiple layers of physical security failure. And remedying that with a protocol is foolish because at the end of the day, yeah, you may have a secure protocol, but if I can get physical access to your machine, I can root your machine and still bypass your security protocols. And so saying that this protocol is going to solve FISEC issues is going to once again create a false sense of security. Also, we talk about solving poor design issues. Oftentimes the BBMD and foreign device registration is referenced as really difficult and we have broadcast storms and we have all these issues. The issue is that there was no strategy put into establishing BBMDs and BDTs. BBMDs and BDTs have been very clearly defined. How to go and deploy them has been very clearly defined. The fact that a campus chose not to have a strategy does not necessitate a technical solution. It necessitates a proper design strategy. That's like going and saying every building is named differently and all the points are named differently. And now we can't use a data taxonomy and analytics because of that. So we need to go and... Create this new protocol and overlay everything. No, you should get in front of the fact that you have all of these disparate namings and you should go and implement a standard. Now I know I just said implement a standard and some of you are screaming, well, SC is a standard, so we should implement that. No, that's the thing. There's going to be some cost that comes with that that I'm going to describe in just a second that is going to be why it's just much more effective for us to follow proper design. with BACnet IP as it stands right now. Now, poor flow regulation issues. This is another argument that you'll get from folks, which is that BACnet IPs and broadcast storms aren't such a big deal until they start to hit the field controllers, which cannot tolerate that much data flow. Okay, but that's why you set up your supervisory devices properly. That's why you do flow regulation on your supervisory devices and you control the flow rates. So if you go back to, you know, 100,000 plus baud. on your field trunks, you go and you use the 9600 or the 38.4 that is specified by the MSTP standard. And by implementing that, you're effectively controlling data flow. Now, granted, could your networks get bogged down by poor broadcast or too many broadcasts? Yes, absolutely. But once again, that's poor BBMD design and BDT design. That's putting too many IPs on your BDTs and expecting that to have proper flow control. So what are some viable opportunities or viable alternatives to the solution? Right off the bat, VPNs. If you're really concerned about secure messaging, end-to-end VPNs, IPsec VPNs, perfectly fine. Implement them, and you've essentially created a secure tunnel between the devices. But Phil, we can go and still put our networks, or we could put a device on the network. Once again, it's a FISEC issue. and then, you know, if you have your VPN, you're going to have secure communication between devices. You're going to get encryption, and before I go any further, I want to talk about this concept called the CIA triad, confidentiality, integrity, and availability. Confidentiality, we're not so much concerned about confidentiality with building automation traffic. You don't really care if someone knows their set point in most cases. I have worked at some facilities that are concerned about that because their temperatures are part of proprietary manufacturing processes, so they care about those environmental variables. Most people care about integrity and availability. If I command a point to 72 degrees and it comes back at 80 degrees, that's an integrity issue. If someone could DDoS, which is a directed denial of service, right, and they take down a device by basically, you know, pinging it with a bunch of different computers or whatever, that is an availability issue. Both of which can be mitigated through things like firewalls, intrusion detection, intrusion prevention. and VPNs. So all of these things right there can go and actually solve our secure communication issue. They can actually go and solve our availability and integrity issues right there. Now, once again, Those cost a little bit of money, but they are in most cases already being utilized by an organization. If an organization has a need for BACnet SC, the likelihood of their IT organization already using some sort of secure tunnel is going to be high. Now you may say, okay, Phil, we've encrypted this data and we've secured it using a VPN, but it can still go and access all the other data on the network. Well, that's where VLANs come into play. VLANs allow us to logically isolate traffic. So we are able to essentially create another subnet for our traffic that cannot interact with other subnets. Now sure, there are ways to cross the VLAN boundary, but those mainly have to do with people improperly setting up their networks. So by implementing VLANs and VPNs, we've solved a lot of the issues. Now, people will say, okay, what about the BBMD and the flow rate issue? What about the broadcasting? What about the static versus dynamic IPs, which static and dynamic IPs in DNS have been largely solved by most manufacturers at the supervisory device layer. So that being said, And with these technologies, we're able to go and address many of the vulnerabilities that are caused by BACnet, IP, and MSTP without the added cost. So now let's talk about cost. I've talked about cost quite a bit. What does this look like? Now. If you go and read the BACnet white paper, and I spent the better part of two days reading all about BACnet SC, that's why this podcast is a little bit delayed. I wanted to really get up to speed with the latest information and kind of dig into it really deep so I could talk to you about it. But if you look at BACnet SC, they do have, in scenario three of their white paper, they do address using BACnet secure connect routers that go back to the hub device that will essentially allow secure communication between the devices. So you could implement this on legacy devices. That being said, the whole purpose of BACnet IP and BACnet MSTP traffic and the devices being insecure and being able to be locally connected to if someone accesses the network, that still exists even with SC. Unless it's a BACnet SC device that implements certificating and authentication, then you're still going to have that device. So ultimately to get to the BACnetSC level, we're going to have to update to the BACnetSC firmware. Now best case scenario, you've got modern controllers and that's simply downloading a new firmware and configuring the devices. Speaking of configuring the devices, you're going to have to create a certificate for each device because each device has its own certificate. The reality is they say to use certificating authorities. Reality is most of the contractors out there, are going to go and self-sign certificates, and they may or may not use the right version of TLS for those self-signed certificates. Now, granted, hopefully they have security built into the SC devices that detects that and will not allow that to be a valid certificate, but who knows? That being said, for a majority of you who have assets out in the built environment, you're going to have to physically update your devices in order to support the SC firmware. So now you have to ask yourself, who benefits from this protocol? Now, I'm not going to get very, very conspiracy theory. there are definitely, when I put out BACnet SC has issues, change my mind post on LinkedIn, I got some folks on there who said, look at the board of SC. Of course, who's got to benefit from this? I like to be a little bit more optimistic than that. And I think that people legitimately feel that this is a solution to the problem. However, I think that we often when we see a van, when we buy a van, like I bought a Honda Pilot years ago, 2000 or a Honda Odyssey years ago, 2014, I think. and I started seeing Honda Odysseys all the time. Well, if all you've known is BACnet MSTP and IP and all you've ever worked with, then you're going to see the answer to this problem being solved as BACnet SC. There's a constraint I like to bring to my employees whenever they bring an idea to me and they say, hey, Phil, I want to do this, or hey, Phil, I want to do that. And I feel like we're limiting ourselves. I say, if you absolutely had to do it with This limitation, what would you do? So my question is, if we had to implement secure communications only using BACnet IP and BACnet MSCP, how would we do it? How could we implement secure communications and do that? And I think that that conversation, I'm sure it was had. And I'm sure that they looked at it and evaluated that. At the same time, I will tell you. What if there was no BACnet? What if we abandoned BACnet entirely? And I'm going to come to that in just a second, because I know that's like a crazy extreme thought. And it's something that I think, personally, I'm biased. I think it needs to happen. I don't have a dog in the fight. I don't own any products, but I think it's holding us back. But let's back up from that constraint real quick. If we look at... implementing VPNs, if we look at implementing VLANs, if we look at implementing intrusion protection and intrusion detection or intrusion prevention and intrusion detection, we've got a viable solution that solves most of the problems. If we properly implement BACnet IP, we solve most of the BBMD and BDT issues. We're implementing a solution with SC for a small subset of customers. For those of you who have never worked for a products organization, what happens is your biggest customers influence the direction of products. So what will happen is the GSA or the DOD or the US military will come along and they'll say, we've got FIPS, whatever, or we're doing this standard. and in order to be certified, you know, back in the day, it used to be like DITSCAP and DICAP. It's not that anymore. But in order to be certified to be on our system, you need to meet XYZ. And so then the salespeople who handle those federal accounts, they freak out and they're like, oh crap, we're not going to be able to qualify. So they go back to the products organization and they say, you absolutely need to implement this, this, this, and this. And the products organization goes, oh, well, we can't do that. So we're going to go back to the protocol and say, we need to do this. and then you get a protocol that is being driven not by the market need, but by several large customers. Because if you look at what SC does, and you look at what most, going back to the risk profile, most companies'risk profile is, they are not aligned. I challenge you to show me alignment between the SC solution and the average customer. where is their security threat so high that it justifies changing out this architecture? And now we move to the actual implementation. I said there's an implementation cost. We've got a workforce that is barely cognizant of basic IT fundamentals. Now we are going to be implementing WebSockets. We are going to be implementing TLS, potentially OAuth. We're going to be implementing authentication, certificating. Can you imagine the communication issues and the troubleshooting issues and the configuration issues that are going to occur because of this? Already people struggle with setting up BBMDs and BDTs, and those are basic architectures. And now we're going to take a technology stack, which by the way is encrypted, and we're going to go and try to implement it, and we're going to run into issues. And then if you have certificate version mismatching, you have issues with potential firewall issues, all sorts of stuff that could cause implementation challenges. Not to mention that a lot of this technology stack, like I mentioned, is all bundled together. So if there's a vulnerability with one of the protocols. in that stack, you have to wait for that firmware update to fix that. Hopefully they've decoupled that. Hopefully they've broken it into microservices or maybe containerized certain aspects of the protocol so that they can be individually updated. I highly doubt that's happened. All right. So I mentioned BACnet should go away and I'm a proponent of that. So let me leave you with a challenge here and then we'll discuss it a little bit because I realize we're running up on the 30 minute time limit that I try to keep these episodes to. but if I told you that you had to create a way for building automation systems to communicate and you could not use a standardized data model, how would you do it? probably freak out, right? Because every time I say BACnet needs to go away, people are like, well, BACnet defines services. You can't use WebSockets by themselves. You can't use APIs by themselves. You have to define services. You have to define data types. But yet you see space after space after space that is using, you know, I don't think RESTful APIs necessarily are the solution for BACnet. I just use them as an example oftentimes because That's something everyone seems to understand, and it's an easy way to say API. But if we constrain ourselves... two limitations like, hey, we need to use stuff that's only in the space with IT right now. It cannot be a algamation of multiple different protocols. And it has to be something that the code base is open to anyone. So it's not firmware dependent, things like that. What would that look like? I don't profess to have the answer. I am not trying to build a solution to replace BACnet. I will just tell you that I've seen folks like Distech Controls with their API solutions. I've seen a lot of the digital solutions. We're going to be working to get Johnson Controls talking about their OpenBlue solution, which I'm interested in learning more about because I want to understand how they're doing data, how they're doing APIs, how they're handling that. and we're going to be also trying to get increasingly more people who are outside of our industry but are kind of in our industry, and how are they doing data? How are they doing their application stacks? I want to start digging into this because we often say that we want open systems. We often say that we want to go and have open communications and not be tied down to someone, but yet we're following the same path we've done time and time again. And the reason I'm hammering this so hard lately is because I really feel like we're about to see a surge of retrofits. You know, we're talking with Maureen Ehrenberg. and I think that's episode 240. And she was with WeWork. She was with JLL. She was with a bunch of different companies. I think Seabury as well. She has a very interesting look at commercial assets and just buildings in general. And one of the things she said is that we're going to see... people consolidate and then modernize their existing assets that are high performers. In order to modernize, that often requires new control solutions. And if we're rolling out yet another protocol that is going to make it difficult for developers, that's going to make it difficult for data consumption and sharing, and that is going to constrain us to a data model that is not really an IT standard data model, then I think we're going to be in for a world of hurt. My hope is to get the folks from Haystack and Brick Schema on the podcast as well so we can talk about their data stacks. I feel like that is where we should be going as an industry. We should have a transportation method, right? And that should be a standard IT transportation method. We should have standard services. and we should have a data set that is by some outside party that is not going to be wrapped into the network communication piece. I know this was kind of deep in some aspects, was kind of high level in others. We bounced around a lot. I really look forward to seeing your dialogue. If you disagree with me, I absolutely encourage you to communicate. I would love to hear your disagreement. I don't take anything personally. And I realized by me saying BACnet SC is a bad idea, that that probably insulted a lot of people. And that was not my intent. I realized there were probably a lot of people who put a lot of hours. into creating the solution. They're like, who the F is this Phil Zito guy telling us our thing is not good? And I hope that I was fair to the solution at the beginning of this episode by saying that it's not a bad solution. Technically, it's sound. It does a lot of good things. I feel, based on analyzing the market, that it's a solution designed for a very specific set of customers. It's not really applicable to the security needs of the greater market, and it's going to provide labor and material costs. It's going to actually create labor and material costs that are not necessary and become a burden to both those on the construction as well as on the service side. So my hope is that you'll consider that. You'll think through this. You'll have your thoughtful comments, and let's dialogue about it. I'm always open to admit where I'm wrong or maybe somewhere I've missed. I don't know everything, but I will tell you, looking at this with no dog in the fight, it does not look like a good solution for the mass market. So with that being said, I encourage you to go to podcast.smartbuildingsacademy.com forward slash 238. Once again, that is podcast.smartbuildingsacademy.com forward slash 238. I'd love to see your comments. I'd love to have a conversation with you. Thanks a ton. Have a great rest of your day.

You don't have to agree with me. You know what? It'd be totally fine if you don't agree with me.

I would love to hear your counter opinions to my perspective. Now, my perspective comes from a pretty wide background. Prior to starting Smart Buildings Academy, I was running the integration program at Johnson Controls.

I would build out BACnet stacks. I would build out APIs. I worked with a slew of different data sets across multiple different buildings, systems, specialty systems, and business systems.

I also have a master's degree in cybersecurity and information systems. I've designed networks. I've held Cisco certifications. I've held the CISSP certification.

I've. I've done a lot in regards to technology, and I've been involved in white box and black box testing of control systems and other applications for customers back in my time at Johnson Controls. Now, I say all this not to toot my own horn, but rather to give you a perspective of my pedigree and background when I bring up these issues. Because at the end of the day, BACnet SC is not a bad solution.

Architecturally, how it's created, the technologies they chose to use in it are not bad. I'm going to argue that they're not necessary, and they actually are going to complicate things further rather than simplifying things. They are going to add potential barriers with IT, and they are going to most importantly add significant project and material costs. to the industry.

And we're actually moving away from where we should be moving as an industry, which is using more open data-focused models that are flexible and are decoupled from the protocol. I'll talk about that towards the end of the episode. So what is BACnet SC?

You've probably seen a lot of the marketing from the OEMs coming out talking about BACnet Secure Connect. It's an answer to three problems. One, it's an answer to the BACnet BBMD routing issue.

It's an answer to the BACnet clear text issue. And it's an answer to the BACnet device authentication and verification issue. And I'll talk through that once again later in the episode.

Now, BACnet SC uses WebSockets, which are similar to HTTP, but not. So WebSockets are bidirectional communication, whereas if you look at HTTP, it uses post and get messages, so it's unidirectional. And also WebSockets tend to handle data flow. streaming data flow better and bi-directional data flow better. That's why you see them used in like a lot of real-time chat applications, in video games, in a lot of streaming video applications.

You'll see WebSockets in lieu of HTTP APIs being used. It also uses TLS 1.3, which is transport layer security. It basically replaced SSL after SSL got some issues. Essentially, each device is going to have a certificate, and that certificate is going to validate that the device is who the device says it is, and it's going to enable encryption between endpoints. So what?

What basically happens is it uses a hub-spoke methodology. There are BACnet hubs, or the SC hubs as they call them. And the SC hubs enable the devices to communicate to the hub and authenticate to the hub. And the devices can also do peer-to-peer where they authenticate using their certificate checking. Like I mentioned, you can have multiple hubs.

And the hubs, see, one of the misunderstandings of BACnet SC is it still has broadcasts. You know, the whois.im is still broadcasting, but those messages are handled through hubs, which are going and sending the information. There's much more technical aspects to it, but you're not crossing subnet boundaries. it kind of decouples you from the physical isolation that is BBMDs and all of the fun stuff that causes issues with BBMDs.

So you may be sitting here at this point being like, Phil, you have really not convinced me at all that BACnet SC is a bad idea. Actually, it sounds like BACnet SC is a great idea. I mean, after all, it's going to compensate for the fact that we've utterly failed in training our BAS people around IT. It's going to solve the BACnet routing issue.

It's going to solve the clear text issue. It's going to really help you conform with certain government security requirements. Actually, this is one of the biggest issues that drove BACnet SC was people not being able to get on sites because BACnet's clear text and they were saying, hey, we can't have this clear text solution on our site.

You need to go and have a more secure version of your protocol in order to be on our site. It's going to solve broadcast storms from poorly designed BBMDs. It's going to fix the protocol address translation issues and BBMD location issues. But is it really the best solution?

Do we really need fixes for all of these issues? So first we need to understand. What are cybersecurity controls?

I mean, what is a cybersecurity control? There's three types of controls. They're administrative, physical, and technical controls.

If we look at building automation systems, the majority of the issues that we experience and that they reference in BACnet SC are on the technical and the physical aspects of the controls. So from a technical perspective, yes. Backnet is clear text.

And in a certain context, clear text can be very bad. In a different context, clear text can be perfectly fine. And we've forgotten, or maybe we never knew, as an industry, the number one rule on cybersecurity controls. And that is that you apply the level of controls.

equal to the level of acceptable risk. That's like the first thing you learn when you're getting an education in cybersecurity is threat analysis, risk profiling, and then going and assigning a value to risk based on the probability of occurrence and the impact to business continuity from that risk. And then once you've determined the actual cost of the risk, you then say, okay, I'm willing to spend this much to mitigate the risk.

Now, in a DoD application, in a Tier 4 data center, yeah, maybe they do have a very, very low level of risk tolerance. They want the least amount of risk as possible. That being said, what is the majority of the assets that we are dealing with out in the built environment? Office space, K-12, some university campuses, some corporate campuses, most of which are segmented from the greater IT network. Now, let's just take commercial real estate and K-12, which are the majority of the assets we deal with.

If you look at those, what is the level of cybersecurity risk tolerance at those buildings? If you say none, then you're fooling yourself. Those buildings absolutely have a very high acceptance of risk for most of those buildings because the reality is The cybersecurity risk of impacting business operations of that and the likelihood of someone attacking that system is relatively low. So because of that, the amount of cost, both in implementation and support for a cybersecurity control, should be low.

But as we'll see with BACnet SC and the things it requires and the support it requires, that's not the case. Also, we are using a protocol to solve technical security issues. Think about that for a second. We are implementing BACnetSC as a stack of protocols, and we are going and mixing all this up.

Yes, BACnet is an open protocol. You can go purchase the standard and you can make your own BACnet stack. But once that stack is implemented inside someone's firmware, your visibility to that stack becomes limited. So how did they implement OAuth? How did they implement WebSockets?

How did they implement TLS? What if a new version of TLS comes up and now you've got a network that, because it was perceived secure... is now riding across both public and private networks, whereas before it was isolated. And we could have used different technology sets that we would have had full visibility to.

that we could rapidly update in case of a security vulnerability. The thing is, whenever you bake multiple security technologies into a single protocol, into a single stack of protocols, as the case of SC, you are increasing the likelihood that one of those protocols is going to be vulnerable, and you're going to give this false perception of cybersecurity. Now, that being said, when you're analyzing all of this, if you were to use some of the solutions that I'll provide later in this episode, if one of those solutions was vulnerable, you would be able to deal with that directly. It would be much easier to check that vulnerability.

Now, I know some folks are going to argue, well, a lot of folks thought SolarWinds was pretty secure, but it turned out it wasn't. Yes, you're absolutely right. But imagine if you had SolarWinds as part of a stack, and it was all built together, and in order to replace SolarWinds, it wasn't a matter of just up.

dating SolarWinds, you had to update the entire firmware. Now, what kind of issue would you have? I hope what you're seeing with that explanation is by having these separated out, you can go and throttle your different levels of security.

You can be aligned with customers'IT security stacks and applications. And then... If the IT security that they want is higher than what SC could have provided, great. If it's lower, that's fine too. But you aren't putting all of this stuff into a mixed bag and then relying on firmware updates and things of that nature in order to go and patch security vulnerabilities, which are coming out almost on a daily basis.

But one of the bigger issues I see is that we're trying to use a protocol to solve poor design issues, poor flow regulation issues, and poor FISEC issues, physical security. One of the things you'll often hear folks say is, if I could go into the building and I got access to your BACnet network, I now have access to your network and I could do all sorts of bad things. And the issue should not be... that BACnet is insecure and that they got access to the network. The issue should be that they are physically in the building connecting to a network and your FISEC completely failed.

FISEC is physical security. There's this concept of the onion, the security onion. And so you have perimeter FISEC, you have entryway FISEC, and then you have restricted areas.

And, you know, it goes further and further. the fact that they're able to gain access physically to these assets shows multiple layers of physical security failure. And remedying that with a protocol is foolish because at the end of the day, yeah, you may have a secure protocol, but if I can get physical access to your machine, I can root your machine and still bypass your security protocols. And so saying that this protocol is going to solve FISEC issues is going to once again create a false sense of security.

Also, we talk about solving poor design issues. Oftentimes the BBMD and foreign device registration is referenced as really difficult and we have broadcast storms and we have all these issues. The issue is that there was no strategy put into establishing BBMDs and BDTs. BBMDs and BDTs have been very clearly defined. How to go and deploy them has been very clearly defined.

The fact that a campus chose not to have a strategy does not necessitate a technical solution. It necessitates a proper design strategy. That's like going and saying every building is named differently and all the points are named differently.

And now we can't use a data taxonomy and analytics because of that. So we need to go and... Create this new protocol and overlay everything.

No, you should get in front of the fact that you have all of these disparate namings and you should go and implement a standard. Now I know I just said implement a standard and some of you are screaming, well, SC is a standard, so we should implement that. No, that's the thing.

There's going to be some cost that comes with that that I'm going to describe in just a second that is going to be why it's just much more effective for us to follow proper design. with BACnet IP as it stands right now. Now, poor flow regulation issues. This is another argument that you'll get from folks, which is that BACnet IPs and broadcast storms aren't such a big deal until they start to hit the field controllers, which cannot tolerate that much data flow.

Okay, but that's why you set up your supervisory devices properly. That's why you do flow regulation on your supervisory devices and you control the flow rates. So if you go back to, you know, 100,000 plus baud. on your field trunks, you go and you use the 9600 or the 38.4 that is specified by the MSTP standard. And by implementing that, you're effectively controlling data flow.

Now, granted, could your networks get bogged down by poor broadcast or too many broadcasts? Yes, absolutely. But once again, that's poor BBMD design and BDT design.

That's putting too many IPs on your BDTs and expecting that to have proper flow control. So what are some viable opportunities or viable alternatives to the solution? Right off the bat, VPNs. If you're really concerned about secure messaging, end-to-end VPNs, IPsec VPNs, perfectly fine.

Implement them, and you've essentially created a secure tunnel between the devices. But Phil, we can go and still put our networks, or we could put a device on the network. Once again, it's a FISEC issue. and then, you know, if you have your VPN, you're going to have secure communication between devices. You're going to get encryption, and before I go any further, I want to talk about this concept called the CIA triad, confidentiality, integrity, and availability.

Confidentiality, we're not so much concerned about confidentiality with building automation traffic. You don't really care if someone knows their set point in most cases. I have worked at some facilities that are concerned about that because their temperatures are part of proprietary manufacturing processes, so they care about those environmental variables. Most people care about integrity and availability. If I command a point to 72 degrees and it comes back at 80 degrees, that's an integrity issue.

If someone could DDoS, which is a directed denial of service, right, and they take down a device by basically, you know, pinging it with a bunch of different computers or whatever, that is an availability issue. Both of which can be mitigated through things like firewalls, intrusion detection, intrusion prevention. and VPNs.

So all of these things right there can go and actually solve our secure communication issue. They can actually go and solve our availability and integrity issues right there. Now, once again, Those cost a little bit of money, but they are in most cases already being utilized by an organization.

If an organization has a need for BACnet SC, the likelihood of their IT organization already using some sort of secure tunnel is going to be high. Now you may say, okay, Phil, we've encrypted this data and we've secured it using a VPN, but it can still go and access all the other data on the network. Well, that's where VLANs come into play. VLANs allow us to logically isolate traffic.

So we are able to essentially create another subnet for our traffic that cannot interact with other subnets. Now sure, there are ways to cross the VLAN boundary, but those mainly have to do with people improperly setting up their networks. So by implementing VLANs and VPNs, we've solved a lot of the issues. Now, people will say, okay, what about the BBMD and the flow rate issue? What about the broadcasting?

What about the static versus dynamic IPs, which static and dynamic IPs in DNS have been largely solved by most manufacturers at the supervisory device layer. So that being said, And with these technologies, we're able to go and address many of the vulnerabilities that are caused by BACnet, IP, and MSTP without the added cost. So now let's talk about cost.

I've talked about cost quite a bit. What does this look like? Now. If you go and read the BACnet white paper, and I spent the better part of two days reading all about BACnet SC, that's why this podcast is a little bit delayed.

I wanted to really get up to speed with the latest information and kind of dig into it really deep so I could talk to you about it. But if you look at BACnet SC, they do have, in scenario three of their white paper, they do address using BACnet secure connect routers that go back to the hub device that will essentially allow secure communication between the devices. So you could implement this on legacy devices.

That being said, the whole purpose of BACnet IP and BACnet MSTP traffic and the devices being insecure and being able to be locally connected to if someone accesses the network, that still exists even with SC. Unless it's a BACnet SC device that implements certificating and authentication, then you're still going to have that device. So ultimately to get to the BACnetSC level, we're going to have to update to the BACnetSC firmware.

Now best case scenario, you've got modern controllers and that's simply downloading a new firmware and configuring the devices. Speaking of configuring the devices, you're going to have to create a certificate for each device because each device has its own certificate. The reality is they say to use certificating authorities. Reality is most of the contractors out there, are going to go and self-sign certificates, and they may or may not use the right version of TLS for those self-signed certificates.

Now, granted, hopefully they have security built into the SC devices that detects that and will not allow that to be a valid certificate, but who knows? That being said, for a majority of you who have assets out in the built environment, you're going to have to physically update your devices in order to support the SC firmware. So now you have to ask yourself, who benefits from this protocol? Now, I'm not going to get very, very conspiracy theory.

there are definitely, when I put out BACnet SC has issues, change my mind post on LinkedIn, I got some folks on there who said, look at the board of SC. Of course, who's got to benefit from this? I like to be a little bit more optimistic than that. And I think that people legitimately feel that this is a solution to the problem.

However, I think that we often when we see a van, when we buy a van, like I bought a Honda Pilot years ago, 2000 or a Honda Odyssey years ago, 2014, I think. and I started seeing Honda Odysseys all the time. Well, if all you've known is BACnet MSTP and IP and all you've ever worked with, then you're going to see the answer to this problem being solved as BACnet SC.

There's a constraint I like to bring to my employees whenever they bring an idea to me and they say, hey, Phil, I want to do this, or hey, Phil, I want to do that. And I feel like we're limiting ourselves. I say, if you absolutely had to do it with This limitation, what would you do? So my question is, if we had to implement secure communications only using BACnet IP and BACnet MSCP, how would we do it? How could we implement secure communications and do that?

And I think that that conversation, I'm sure it was had. And I'm sure that they looked at it and evaluated that. At the same time, I will tell you. What if there was no BACnet?

What if we abandoned BACnet entirely? And I'm going to come to that in just a second, because I know that's like a crazy extreme thought. And it's something that I think, personally, I'm biased. I think it needs to happen.

I don't have a dog in the fight. I don't own any products, but I think it's holding us back. But let's back up from that constraint real quick. If we look at... implementing VPNs, if we look at implementing VLANs, if we look at implementing intrusion protection and intrusion detection or intrusion prevention and intrusion detection, we've got a viable solution that solves most of the problems.

If we properly implement BACnet IP, we solve most of the BBMD and BDT issues. We're implementing a solution with SC for a small subset of customers. For those of you who have never worked for a products organization, what happens is your biggest customers influence the direction of products. So what will happen is the GSA or the DOD or the US military will come along and they'll say, we've got FIPS, whatever, or we're doing this standard. and in order to be certified, you know, back in the day, it used to be like DITSCAP and DICAP.

It's not that anymore. But in order to be certified to be on our system, you need to meet XYZ. And so then the salespeople who handle those federal accounts, they freak out and they're like, oh crap, we're not going to be able to qualify. So they go back to the products organization and they say, you absolutely need to implement this, this, this, and this.

And the products organization goes, oh, well, we can't do that. So we're going to go back to the protocol and say, we need to do this. and then you get a protocol that is being driven not by the market need, but by several large customers.

Because if you look at what SC does, and you look at what most, going back to the risk profile, most companies'risk profile is, they are not aligned. I challenge you to show me alignment between the SC solution and the average customer. where is their security threat so high that it justifies changing out this architecture?

And now we move to the actual implementation. I said there's an implementation cost. We've got a workforce that is barely cognizant of basic IT fundamentals. Now we are going to be implementing WebSockets.

We are going to be implementing TLS, potentially OAuth. We're going to be implementing authentication, certificating. Can you imagine the communication issues and the troubleshooting issues and the configuration issues that are going to occur because of this? Already people struggle with setting up BBMDs and BDTs, and those are basic architectures.

And now we're going to take a technology stack, which by the way is encrypted, and we're going to go and try to implement it, and we're going to run into issues. And then if you have certificate version mismatching, you have issues with potential firewall issues, all sorts of stuff that could cause implementation challenges. Not to mention that a lot of this technology stack, like I mentioned, is all bundled together.

So if there's a vulnerability with one of the protocols. in that stack, you have to wait for that firmware update to fix that. Hopefully they've decoupled that.

Hopefully they've broken it into microservices or maybe containerized certain aspects of the protocol so that they can be individually updated. I highly doubt that's happened. All right.

So I mentioned BACnet should go away and I'm a proponent of that. So let me leave you with a challenge here and then we'll discuss it a little bit because I realize we're running up on the 30 minute time limit that I try to keep these episodes to. but if I told you that you had to create a way for building automation systems to communicate and you could not use a standardized data model, how would you do it?

probably freak out, right? Because every time I say BACnet needs to go away, people are like, well, BACnet defines services. You can't use WebSockets by themselves.

You can't use APIs by themselves. You have to define services. You have to define data types.

But yet you see space after space after space that is using, you know, I don't think RESTful APIs necessarily are the solution for BACnet. I just use them as an example oftentimes because That's something everyone seems to understand, and it's an easy way to say API. But if we constrain ourselves...

two limitations like, hey, we need to use stuff that's only in the space with IT right now. It cannot be a algamation of multiple different protocols. And it has to be something that the code base is open to anyone.

So it's not firmware dependent, things like that. What would that look like? I don't profess to have the answer. I am not trying to build a solution to replace BACnet. I will just tell you that I've seen folks like Distech Controls with their API solutions.

I've seen a lot of the digital solutions. We're going to be working to get Johnson Controls talking about their OpenBlue solution, which I'm interested in learning more about because I want to understand how they're doing data, how they're doing APIs, how they're handling that. and we're going to be also trying to get increasingly more people who are outside of our industry but are kind of in our industry, and how are they doing data?

How are they doing their application stacks? I want to start digging into this because we often say that we want open systems. We often say that we want to go and have open communications and not be tied down to someone, but yet we're following the same path we've done time and time again. And the reason I'm hammering this so hard lately is because I really feel like we're about to see a surge of retrofits.

You know, we're talking with Maureen Ehrenberg. and I think that's episode 240. And she was with WeWork. She was with JLL.

She was with a bunch of different companies. I think Seabury as well. She has a very interesting look at commercial assets and just buildings in general. And one of the things she said is that we're going to see... people consolidate and then modernize their existing assets that are high performers.

In order to modernize, that often requires new control solutions. And if we're rolling out yet another protocol that is going to make it difficult for developers, that's going to make it difficult for data consumption and sharing, and that is going to constrain us to a data model that is not really an IT standard data model, then I think we're going to be in for a world of hurt. My hope is to get the folks from Haystack and Brick Schema on the podcast as well so we can talk about their data stacks.

I feel like that is where we should be going as an industry. We should have a transportation method, right? And that should be a standard IT transportation method. We should have standard services. and we should have a data set that is by some outside party that is not going to be wrapped into the network communication piece.

I know this was kind of deep in some aspects, was kind of high level in others. We bounced around a lot. I really look forward to seeing your dialogue.

If you disagree with me, I absolutely encourage you to communicate. I would love to hear your disagreement. I don't take anything personally.

And I realized by me saying BACnet SC is a bad idea, that that probably insulted a lot of people. And that was not my intent. I realized there were probably a lot of people who put a lot of hours. into creating the solution.

They're like, who the F is this Phil Zito guy telling us our thing is not good? And I hope that I was fair to the solution at the beginning of this episode by saying that it's not a bad solution. Technically, it's sound. It does a lot of good things.

I feel, based on analyzing the market, that it's a solution designed for a very specific set of customers. It's not really applicable to the security needs of the greater market, and it's going to provide labor and material costs. It's going to actually create labor and material costs that are not necessary and become a burden to both those on the construction as well as on the service side. So my hope is that you'll consider that. You'll think through this.

You'll have your thoughtful comments, and let's dialogue about it. I'm always open to admit where I'm wrong or maybe somewhere I've missed. I don't know everything, but I will tell you, looking at this with no dog in the fight, it does not look like a good solution for the mass market. So with that being said, I encourage you to go to podcast.smartbuildingsacademy.com forward slash 238. Once again, that is podcast.smartbuildingsacademy.com forward slash 238. I'd love to see your comments.

I'd love to have a conversation with you. Thanks a ton. Have a great rest of your day.

Transcript for:BACnet SC the case against

Transcript for:
BACnet SC the case against