The Hows, Whys, and Whats of Remote Access to Your BAS

I recently received an e-mail question via the Contact Phil Section of my blog. I enjoy writing articles for my blog but I enjoy even more when I get interaction from my readers.

The question posed by my subscriber is pertinent to so many people that I felt it deserved to be posted in its entirety.

The last blog topic I read was the hacking a BAS theme and how to secure it. What are your thoughts on putting the BAS behind a Firewall/VPN versus a public IP. While the Firewall/VPN is a more secure route, don’t most building managers want to be able to pull up an app on their home tablet just like any other app they access?  It is a bit of a hassle to first log into a VPN and then access your app.  They don’t have to do that to access their bank accounts, cloud storage, or Office 365 apps.  Thoughts?

The other thing I’ve been noodling with is how a BAS network ties to a corporate network. With the Target breach, this really has raised some concern. The most secure thing to do is to never tie the two together and just force the BAS to sit on its own standalone network with its own Internet connection.  However, this ruins all the fun!  This is 2014 and we should be able to utilize corporate resources such as DHCP, DNS, AAA to manage the network and authenticate the users who can access the BAS.  Not to mention offer some cool futuristic services to my all of my users such as BAS-widgets on their desktops showing their temperature and lighting statuses and set points.

 Well, my fellow readers this question really involves two separate issues:

1. How to manage the behavioral and technical aspects of remote access to a BAS
2. The how and why of addressing the security concerns of putting a BAS on a Corporate Network?

How to manage the behavioral and technical aspects of remote access to a BAS

Remote access for your BAS really comes down to solving two issues. The first, and most difficult is solving a behavioral or cultural issue. There is a massive difference between working with the IT group at a major hospital and the one-man band at a 80k square foot commercial real estate building.

In an enterprise environment, the aspects of authentication, authorization and accounting or (AAA) will be handled by the corporate IT policy. The IT group will typical detail out the method (typically a Secure Socket Layer Virtual Private Network or SSL VPN) will be used to handle authentication and authorization. The login account may or may not be linked to a Single Sign On (SSO) account.

Suffice to say in an enterprise environment most of what you will do will be dictated by the existing enterprise IT standards, remember this statement when we address the second question of how to put a BAS on the corporate network.

The bigger concern of managing behavior is found within the small (less than 100k sq ft), non campus/branch environment. In these situations your “IT” guy is the local DSL provider and you are limited to the capabilities you yourself can implement. In these situations I have found that your options are fairly limited because:

• The guy who is going to be accessing this system from home is typically limited in his IT capabilities.
• The installers company is typically not built to become the building’s IT rep.
• Most contractors do not want to maintain devices post installation.

I’d like to say it’s a given to not put a BAS on a public IP address. Every security bone in my body screams do not do this! But outside the realm of academia and research there lies a land called reality. In the real world, it is not practical to isolate a BAS all the time, what if this building is 250 miles from the “local” support? What then? Also, what if the manager of the building does not want to invest in the security infrastructure, what then? In that case you simply:

• Change your passwords every 30 days
• Use pass-phrases instead of passwords
• Use uppercase, lowercase, numbers, and symbols in your pass phrase.
• Maintain a length of at least 10 characters
• Do not allow the reuse of a previous password.
• Patch your system, delete default user accounts.
• Pray…

However, if you get a slightly more sophisticated user, or one that is at least willing to listen to reason. You can have them use a VPN device, firewall, ect.. For the small office application there aren’t a whole lot of systems. Two of the most common systems are listed below:

A straight up VPN

In this scenario you are going to have the VPN extend the local network to your device. From here you would use your web-browser or BAS client to log into the BAS. Keeping in mind that all of the previous comments on passwords still apply.

A VPN with a proxy server

This is a more secure method, but is more complex. Essentially your client would log in via the VPN to the local network. Then you would click on a desktop icon that would be scripted to use Remote Desktop Protocol (RDP) to connect to the proxy server. This server would then be used to access the BAS application. This is not a typical Proxy that simply masks IP and filters packets. Rather it is a hybrid between a Bastion host and a proxy server. This obviously is more complicated and requires more user sophistication.

 

Option 1, besides for the need to manage a VPN,  is actually quite easy as the VPN can be set to auto-logon. Additionally certain providers have solutions for tele-workers that consist of an always on VPN that directly connects to the building network. Option two is slightly more complex but is more secure due to the fact that the attacker would have to compromise both the employee’s laptop and the proxy server.

Additionally, if done right the proxy server can be setup to block malicious traffic prior to it entering the network.

 

The how and why of addressing the security concerns of putting a BAS on a Corporate Network?

My day job involves the consultative design of smart building systems. My role covers the full OSI stack from Layer 1 to Layer 7. Because of this I often find myself acting as a mediator of sorts between the application folks and the network folks. The application providers (both internally and externally) want their systems to have easy access to the network. On the flip side the network folks want to keep the “applications” in their own little box so that they can guarantee the network traffic plays nicely.

I can’t say I blame the networking folks for being cautious.

Try to see the problem from their perspective. In a large enterprise environment you may have over 1000 different applications running. Each application is running on a platform that may or may not be supported any longer, may or may not have proprietary data flows, and may or may not be Quality of Service (QoS) sensitive.

To visualize this take a medium size hospital that is implementing a new imaging software and accidentally allows the traffic to pass over the public WiFi, imagine the potential damage both in credibility and legality that would arise if you allowed patient imaging to ride over the public WiFi.

Because of these kind of concerns there is a hesitancy to put devices on the internal network. Now add to the mix the influx of Smart devices that BAS vendors and Smart Building vendors are flooding the market with. These devices pose some serious threats like:

• Using messaging that typically does not fit a Intrusion Detection System (IDS) profile.
• Utilizing older or End of Life (EoL) operating systems.
• Composed of Un-patched software or proprietary programs.
• Lack of segmentation in product design which denies IT the ability to push patches.
• Lacking Simple Network Management Protocol Version 3 SNMPv3 capabilities for simple network monitoring.
• Lack of, or antiquated logging capabilities.

If I was in charge of an enterprise network and you presented me with these challenges there would be no way in hell I would let you put this device on my internal network. This however, doesn’t have to be the case as you will see in my analysis of each specific threat.

Unfortunately because most in the BAS field only dabble in IT the responses that are often given to these objections are o not as robust as they could, and should, be.

Now I will discuss each one of these objections in further detail:

Using protocols that typically do not fit a Intrusion Detection System (IDS) profile.

There is a myth out there that all hell could break loose if you put a BAS on your network.

Because IT folks don’t commonly work with BAS systems they are rightfully concerned about the following implications associated with BAS Message traffic:

• BandwidthThe typical BAS message is over UDP, meaning it’s essentially fire and forget. Additionally as can be seen by the packet capture above, the packet size is not abnormally large. There is a good case study on bandwidth here.
• QoSQuality of Service is a concern. How do I shape my traffic so that it doesn’t drown out other systems. One solution is to use Virtual Local Area Network (VLANS) for all BAS systems, this becomes a concern if VLANS drift over multiple access switches. This can create a spanning-tree nightmare and could require either Layer 3 at the access layer or multiple VLAN’s spread across the access layer to resolve. Another solution is to simply have the Access layer switches for the BAS pull back into a single N+1 Distribution switch (kind of like using Virtual Switching System (VSS). See the image below
  

  You can see how the multiple VLAN’s are be pulled into the two Distribution switches. These switches act as the default gateway and allow the devices on different VLAN’s to communicate. Additionally the Distrubution switches have a trunk between them allowing for multiple redundancy options (like HSRP, GLBP, or VSS)

   

• Traffic SignaturesWe already have a BACnet packet capture above. We can see the shape and form the traffic takes and how it is structured. Additionally, there are multiple resources laying out the format of BAS traffic. As such we can easily configure an IDS to reject traffic. Additionally, we know the devices that will be communicating and as such we can use common sense to ensure that any devices which are not on our white-list should not be communicating. Furthermore, with the new 2008 BACnet Addendum we can apply encryption and credentialing to our BACnet traffic to further support the network.

Utilizing older or End of Life (EoL) operating systems.

Why people still install antiquated control systems is beyond me. There are still folks out there trying to install systems that run on Windows 2000 series machines. Scary indeed. Quite a few of the IT folks I talk to are concerned around the platform on which the BAS runs. However, one point needs to be made. The typical BAS supervisory device is not the same as a client computer. The BAS is often stripped down, with services and functionality disabled. Some BAS’s are secured to the point of being DIACAP certified. When Dealing with older operating systems, you must define two things:

1. Has a support extension been purchased. Even though Windows XP has EOL’d many organizations can purchase an extension of support from Microsoft. So just because a OS is EOL’d does not mean it is necessarily no longer supported.
2. What services and functions are on? In many BAS devices you can disable features that leave you vulnerable. Some of these features are SNMP v1, RDP, and IIS. You should work with your IT group to know what services are available on your systems.

Composed of Un-patched software or proprietary programs.

It’s true that most BAS’s run on older software. Unfortunately the length of the product development life-cycle for a BAS is somewhere between the end of all solar activity in the galaxy and the evolution of fish into birds, whichever happens first… In all seriousness, most BAS offerings are developed on a platform that is at least 2 revisions behind the current revision in the field. This however is ok, as long as you understand which version the software is at you can mitigate the threats.

The big fear here is that some vulnerability will allow the system to be exploited. As you will see in the following section the Network side of a BAS can often be patched and secured. If you keep this part of the system safe then your supervisory devices should be fine.

Lack of segmentation in product design which denies IT the ability to push patches.

This isn’t so much an issue of not being able to patch device as it is an issue of understanding which devices you can patch. Most BAS’s consist of a 3-tier architecture ; Network, Supervisory, Field. The field devices are traditionally hard-wired non-IP devices as such, the practicality of patching these devices is near-zero. On the other end of the spectrum you have the network tier which is composed of SQL databases, and server class machines. These systems can be patched, monitored, and managed. The problem therefore lies with the Supervisory Tier.

The devices in the supervisory tier tend to have an embedded OS and are capable of IP (Layer 3) communication) because of this many in the IT world fear these devices.

My response to this fear is three-fold:

1. If you properly manage your edge and you keep your Network devices patched you should have very little to worry about with a supervisory device. A supervisory device should never have a public IP. The network server should be the only device on the internal network that talks to a supervisory device.
2. Most supervisory devices are capable of being managed via LDAP, SNMP, and have well-formed traffic. Because of this and point 1. It will be very difficult to compromise a supervisory device on an internal network with no public exposure.
3. Most embedded devices ship with default services disabled. You as an BAS provider should ensure that the IT services, IIS, RDP, ect are disabled.

With these three things in place alongside a robust credential management program you will have effectively hardened your devices for all but the most persistent hackers.

The name of the game is to make the device difficult enough that attackers will choose a softer, more difficult target.

Lacking Simple Network Management Protocol Version 3 SNMPv3 capabilities for simple network monitoring.

SNMP utilizes Management Information Bases (MIB) that are composed of Object Identifiers(OID). SNMP is a protocol, that in its current version, version 3, provides a relatively secure method for managing and monitoring network based systems. Some not all BAS devices support SNMP and those that do should be setup to use this feature. This is simply something your device has or doesn’t have.

Fortunately a good majority of the BAS products on the market have this capability, (although for some reason a few unnamed vendors insist on stupidly implementing Version 1 of this protocol…..)

SNMPV3 is another tool when you seek to build your case as to why the BAS should be on the internal network. The first thing I do when I sit down with an IT group is to ask why they do not want a device on their network. The answer usually revolves around three objections:

1. We can’t patch the device (the response to this challenge was discussed in an early bullet)
2. Our IDS/IPS cant categorize the traffic (see my early bullet on traffic analysis and how to create signatures)
3. We can’t monitor/ manage the device

SNMPv3 solves the challenge of monitoring and managing the device. When put into these situations I will pull out the MIB reference PDF that details the MIB’s and associated OID’s that my product provides. We discuss exactly what the IT group would like to manage and 9 times out of 10 I can show them that exact OID in my reference PDF. The moral of the story is that you should know your MIBS and your OIDS!

Here is a sample MIB file

Lack of, or antiquated logging capabilities.

Let’s face it, BAS’s are not known for their amazing logging capabilities. When a janitor can wipe the access logs of most BAS’s with a few clicks we have a major problem (if this happens you have bigger issues around device access and account level segmentation!) . To throw further “logs” on the fire, about half of the BAS’s on the market have no logging capabilities whatsoever. Because of this when some go into the IT departments office and get asked about logs they tend to clam up and look down at their shoes.

Well, my friends, it doesn’t have to be that way.

Remember earlier when I mentioned the capabilities of SNMP and LDAP  ? Well these capabilities are your friends! Utilizing LDAP you can apply user roles and you can log these users with the event manager found in many server OS’s. Add SNMP Traps to the mix and now you are able to monitor your device. This gives you the capability of monitoring everything from temperature to RAM utilization.

So next time you are challenged on your logging capabilities, you can simply say that you support LDAP integration and SNMP v3 with a robust MIB (if your product supports them) .

Conclusion

I’ve discussed how to access your BAS remotely. We have detailed two of the most common ways to access a BAS system within a small business environment. Additionally I discussed how to make the case for placing the BAS system onto the internal network. I discussed common objections and how to handle those objections with facts not emotion.

However, I must caution you. Most of the decisions are made based on the business outcome not on the technical viability. If I have to spend 500 dollars each time I roll a truck to service a site the price of a $1,200 dollar VPN appliance seems much more affordable. Futhermore if the CEO wants the BAS to be able to turn his room on based on his Outlook calendar the discussion around whether the BAS will be on the network becomes a mute point. There are a lot of grey areas in systems integration and as much as we search for black and white, we often will not find it.

What has been your experience working with IT?

How have you handled security questions?

What are your ideas on solving the remote access dilemma?