Why are there no passwords for BACNET data

[choosewisely]

I've done quite a few tie-ins to different Bacnet/IP devices (Chillers, Boilers, Lighting controls, Fan Coil Units, Etc). Everytime a device manufacturer give me a Bacnet Points list (or I use a Bacnet utility like Bacnet Explorer to "learn" the datapoints.

Usually, Once I have the TCP/IP address scheme for the Bacnet device, the bacnet utility finds the datapoints with no problem.

As a matter of fact, I also have full access to any Bacnet datapoints (chiller setpoints, start/stop, etc (without supplying any security passwords).

It seems to me that it would be pretty easy to connect to a system with a TCP/IP sniffer, Learn the IP schema, Find the Bacnet devices, and destroy a system.

Where is the security in Bacnet???

[qtip]

And rhat is different in the LON world in which way?

[dngrsone]

Security in the form you are talking about would negate the whole reason behind BACnet; that is, an open protocol that is accessible by all makers.

If one were to incorporate security codes for accessing data points, then who would own those codes? It seems to me that the users would end up in the same quandary the have had over the past few decades-- stuck with one manufacturer or dealer, or replace the works.

Unless you want to have gangs of controls people who have to hack their way into other people's systems... it's difficult enough trying to get the various different brands to work together with this open protocol, without having to password the data on the off-chance some HVAC Controls person decides to become a terrorist and hack their way into a buildings system just to destroy it.

The security lies in the building manager's/IT guy's regulation of their networks, restricted access to the relevant computers, and lack of knowledge outside the still relatively small world of Controls.

[sysint]

And rhat is different in the LON world in which way? Why don't you stick to the question instead of always bringing up Lonworks?

[qtip]

Why don't you stick to the question instead of always bringing up Lonworks?


LOL
That was a fare question. sir moderator

[choosewisely]

The security lies in the building manager's/IT guy's regulation of their networks, restricted access to the relevant computers, and lack of knowledge outside the still relatively small world of Controls.


Security relying on a lack of knowledge also implies relying on a lack of good judgement.

Anyway, I'm not trying to compare Bacnet to Lon. (But at least the Lon stuff looks more cryptic). I'm trying to figure out why nobody else cares that it is so easy to hack into a bacnet system. I was hoping someone would tell me that I was wrong about my assumption (that Bacnet has no inherent security)

I'm just trying to figure out how to explain to the IT guys (who are getting more savy everyday) why the stuff we are hanging on there networks has no security. and why they need to be responsible for all the security.

I don't see how a simple password structure incoporated into the protocol would blow the whole open thing out of the water

[kontrolphreak]

Delta controls initially released a BACnet access control system and then realized that any other BACnet OWS could control their system changed the protocol back to V2 (I think???). That is one of the problems with open systems, anyone can access, view and control the objects in another vendors products. I feel that this will become an issue with the new access BACnet objects that ASHREA is developing. If no security is developed we could have some issues in the future.

kontrol out

[jc47]

How is changing chiller setpoints, start/stop, etc. going to 'destroy a system'? I don't see anyone wanting to hack into a network just to change a chiller setpoint. If you wanted to do real damage it would be a lot eaisier to just go find the chiller and start cutting wires.

[sysint]

I think you will find that most security issues get solved by authentication and encryption. Encryption scrambles data. Authentication is somewhat different. Authentication is asking who is sending --- OK I'll do it or not.

Really bacnet doesn't have much in the way of adopted security as you can see by the links. They are still in the proposal phase...

http://www.fire.nist.gov/bfrlpubs/build03/PDF/b03034.pdf
http://www.bacnet.org/Bibliography/BACnet-Today-05/27059Holmberg.pdf
http://www.buildings.com/Articles/detailBuildings.asp?articleID=1740

EDIT-- When you have an "open" protocol encryption tends not the thing you want to do. You would want to rely more on authentication. - at least at the point where info needs to be exchanged. For instance, Lonworks is used extensively in electrical metering. I know that the utility allows the meter to talk to residential appliances for energy saving. In that case, there would be authentication. At the same time, I'm sure they don't want the owner of the home getting into setting pricing or meter resetting, so there is a need to authenticate the request but not encrypt the data preventing the home owner from using useful information. So, the homeowner can view pricing, but not set there own pricing level.

By contrast when going through a WAN between 2 points you are looking more into encryption.

[choosewisely]

How is changing chiller setpoints, start/stop, etc. going to 'destroy a system'? I don't see anyone wanting to hack into a network just to change a chiller setpoint. If you wanted to do real damage it would be a lot eaisier to just go find the chiller and start cutting wires.

OK, How about I change my original phrase to "wreak havoc on a functioning chiller plant"

SYSINT, as far as your reply which points out Authentication and Encryption. I know that LON has these mechanisms. But the way that the LON systems are curretnly being installed, these options are not really being used (for the mechanical control systems anyway). and I'm not an expert, but I believe that the authentication mechanism might only be for the bound variables (not CPs). Wouldn't the manufacturers of te LON devices have to lead the way (by programming there devices to use these mechanisms) in order for the security mechanisms to be utilized?

Anyway, There must be some reason why I haven't asked the question when installing LON systems.

Here's an example
One Building the following:
1. A Tenant Owned BMS system (Bacnet, of course)
2. A "Base Building" BMS system (Also Bacnet)
3. A Requirement to share a CONTROLLABLE number of data points

This should be easy. Both Systems are Bacnet, Both Systems are open. Why not just connect them togethet on the IP bus and set up the data you want to share.
The reason is that EVERYTHING gets shared.

Solution:
Uses a bacnet to bacnet MAPPING device (not a router) as a GATEWAY (bacnet to bacnet), and MAP the points that you want shared between both systems

I thought that the idea was to get away from GATEWAYS and MAPPING

[dngrsone]

Well, I do know that one of my clients knows exactly when I plug into their network to work on the BMS, and they make a point to speak to me about it, even when they know I'm about to plug in.

I don't know enough about the protocol to know whether one could actually hack into the IP network from the MS/TP lines... if it is possible, then there is a significant problem there that will show up in coming years.

As for the ethernet side of things, well... I'm not trying to be cavalier about it, but that is IT's job, isn't it? I have no problem working with them to get my servers, clients and BCMs locked into their network and security scheme.

[choosewisely]

I guess I made my point. (and confirmed my assumption)

There's no sense in debating or arguing about whether or not it is a concern.

Our customers will let us know the answer to that question

[sysint]

SYSINT, as far as your reply which points out Authentication and Encryption. I know that LON has these mechanisms. But the way that the LON systems are curretnly being installed, these options are not really being used (for the mechanical control systems anyway). and I'm not an expert, but I believe that the authentication mechanism might only be for the bound variables (not CPs). Wouldn't the manufacturers of te LON devices have to lead the way (by programming there devices to use these mechanisms) in order for the security mechanisms to be utilized?

If you utilize authentication in Lonworks you double the traffic.

Encryption is utilized on the router side. Which can be used with bacnet also. Further, if either protocol is contained in a packet, it can be encrypted between points. And, yes.... the IT guys deal with that.

On gateways and mapping--- I can see where authentication in bacnet is going to be a godsend for OEMs. I can just see Trane laughing as they generally restrict access from third party bacnet companies..... time for Reliable and others to fold up shop, authentication and security by individual bacnet providers are going to wipe them out.

[choosewisely]

Sysint. What about authentication and access to CPs? Or authentication and Broadcast messages, (or group messages) for that matter?

[sysint]

Well...

Within LNS you assign authentication. The keys originate there. Then keys are assigned to the node which cannot be read unless you have the key already. So, as far as I understand things it would be everything.

[choosewisely]

OK
Then if that's true. It basically locks down a system as a whole. I wonder if the device developer has to enable support for authentication? or if it's part of the protocol that can't be removed

It shows that Echelon has thought about the subject of security at least

[tripper]

Security relying on a lack of knowledge also implies relying on a lack of good judgement.

I agree with this, we used to write a little code in the programs (bacnet) to command critical or important points to auto, and or set value, and or limit the range of. To protect the system from others (in some cases the owners).
When all the 'what ifs' are taken out, you have a secure system. Just remember you might be able to see all the bacnet points (but change none if the security is needed) there also could be local variables that only the programmer has access to.

just my 2 cents

[sysint]

OK
Then if that's true. It basically locks down a system as a whole. I wonder if the device developer has to enable support for authentication? or if it's part of the protocol that can't be removed

It shows that Echelon has thought about the subject of security at leastYou do have to enable authentication on the design side. Again, it doubles the traffic. The request comes into a device with the authentication key. The device sends back a 64 bit random number that the athenticator solves and answers. If OK, changes are made.

On the bacnet side, aren't companies simply hiding data from view? Doesn't ALC do that?

[choosewisely]

Hiding data from view doesn't help the scenario I previously posted:

Two BMS systems connected to one set of Bacnet devices, Each one has access to only a portion of the data

[lonman]

If you consider security to be a multi-tiered issues, which I think it is, you need to look at what type of security is desired at each level. At the field bus level both LonWorks and BACnet work off an unencrypted set of addresses (as do most hard wired protocols). So snooping on the line will reveal address and point information. One different is that LonWorks has a lock and key mechanism that can be used to secure access and modification rights of objects (data points) in each controller. This is typically not used in BAS applications outside of security systems thought since it does add overhead and more importantly makes system maintenance and management more difficult. If you loose the key in a device you can make land fill of the controller which is true security. The security mechanism in LonWorks has no back door and the only way to recover a locked device that you loose the key is to perform a "EE blank" by removing the eeprom/flash and replacing it with a part with the special eeblank program. This will intialize the device. Of course you must first have physical access to the device (security 101) and the memory part must be removable not soldered down. Most memory parts are soldered down, so using most likely the controller is landfill. Bottom line don't use the field level bus authentication in HVAC applications.

One the other hand, the IP to field bus security is used frequently and handled by IP852 and RNI based devices with MD5 authentication. If you want to hide data you need to add VPN type security which is inexpensive, but is rarely needed. You don't really care that someone knows the temperature in a zone, but he better not be able to change it. MD5 authentication takes care of this and is standard in LonWorks IP/852 routers.

I believe BACnet providers have their own security models that leverage standard IT security as well. One problem is the lack of a standard in this area might make it difficult to integrate multi-vendor installations.

This is also another multi-user security model used in vendors tools for DB access. This is true in many (but not all) BACnet and LonWorks tools. If you are looking for a multi-user/tier DB and network access model check out each tools capability. Echelon's LonMaker for example allows the DB to be segmented into "Subsystems". User access including Read and/or Write access can be assigned to users. This is further broken down to allow / disallow specific operations such as Configuration parameter access, device replacement, NV access. etc.... This way you can have a "lighting control" subsystem, "HVAC subsystem", "Access Control" subsystem, and for each subsystem assign installer, facility manager, and maintanece personnel access for each.

:cool: