Code signing is a security feature that has been around for quite some time, and has been proven in many other areas, but is uncommon to find it in any control system component and very rare to find in control devices where firmware uploading is an important feature.  Without a doubt the technology is useful, and provides a high level of assurance that the code running on the device is the code that you want running on it, but lately I’ve been in too many conversations where code signing is seen as a panacea for any and all security issue we may ever face and many involved in securing, administering, or pontificating about control systems don’t have a real understanding of the technology even as they praise or denigrate it.

So what does code signing give you?  It usually boils down to is some sort of digital signature mechanism that lets the system (or the user) know that a sheep is actually a sheep and not just a wolf with wool glued to it.  This usually takes the form of a cryptographic key of some sort, and the device that the firmware is being uploaded to won’t accept the firmware unless it’s signed with a valid key (this check should also be done at runtime, not just upload, but we’ll keep it simple).  Having a mechanism like this in place is a great step in the right direction, but it has to use real cryptography.  That means something that one of those PHD types, who probably has an algorithm with his last name in it, came up with and has had it peer reviewed for decades, not an in house routine that divides the total firmware size by 10 and does a crc-16 on each of those offsets and makes sure it equals the value in the header of the file.

The integrity of the code at the time it starts is more than reasonably assured.  That is definitely a good thing, but more than a few voices in our little corner of the security community think that this means that vulnerabilities in that code aren’t exploitable.  This is not the case; once the code is loaded and running the checks are finished until the next time it runs. That means that arbitrary code can still be executed on the device if a vulnerability was successfully exploited, it just means that the exploit code has to do some serious work before the next reboot or it’s going to be homeless.  Code signing makes one set of attacks significantly more difficult, and makes any permanent changes tougher but it’s not a cure all.

So with that out of the way, are we going to see a time in the future where code signing of firmware is common? I’ve had SCADA admins tell me that they’ll never use a device that required it, citing issues with key management, verification, what happens if they want to keep the devices in place but the company providing firmware stops supporting them, and so on. These are valid concerns, but ones that could be overcome with proper planning and forethought.  But by far the more common excuse is the same one we hear for why HMI stations don’t have passwords, usually something along the lines of “What if someone needed to login immediately and they forgot their password?”  But honestly, if your system is a configuration having to push firmware to a device immediately without any sort of safeguards is a problem, it’s probably time to go through some of those emergency scenarios and get some mitigating controls in place that would keep that from being a deal breaker.

When stories about Internet based attacks on control systems, like the 60 Minutes story, appear on sites like Slashdot, most people question the need to attach the control network to  another network.  In my previous position at a National Laboratory, I have seen proper network segregation implemented successfully, though at times it can be a pain to work with.  The Labs place a high value on security and have the financial means to implement it.  In an optimal setting, there would be no need to have the control network connected to any other network.  There are often business reasons that make it necessary at times to connect the control network to another network.

Information is often shared from the control network to the corporate network for various reasons.  In this case, the optimum way to share that data would be to give those employees who need the control network data a separate workstation on a network not connected, physically and logically, to the corporate network.  These systems would connect to a DMZ in between the control network and this control data sharing network.  This setup is similar to what we see in some of the better implemented control networks where the control system employees are given a separate workstation connected to the corporate network.  The difference is that this configuration would provide limited control system data access to those on the corporate side.  The systems could be very lightweight, possibly thin clients or older computer systems that would normally be discarded.

Remote access is difficult to assess as there are times employees may be required to connect to control network when out of the office.  This of course is a business / risk management decision that needs to be determined internally.  If remote access is allowed, even if only for emergency situations, it may be appropriate to have a physical separation between the remote access server and the control network.  One option is a KVM over IP setup that is physically put in place by a local technician when access is needed, then removed once access is no longer required.

Another big reason control networks are connected to external networks is information sharing with partners.  This is possibly the most difficult situation to protect against as there must be some trust between the two networks.  If the data is a one way outbound connection and the data is being sent over a stateless protocol (e.g. UDP) physical countermeasures, like cutting the receive wire in an ethernet cable, can be taken.  When the data is not stateless but still one way outbound, one way gateways can be used to provide the data with significantly less risk.  When data is being shared in both directions proper firewalling is paramount.

In all of the situations listed above, proper authentication and access control should be implemented.  In all situations, it should be easy to disconnect the control network from outside networks and there should be a process in place that allows that to happen.

I’ll start off by saying don’t believe all the FUD that’s been going around, we all know how many members of the media area when they get hold of a story, especially one that can have a date in the future to speculate on.

That said, there are definitely some interesting things going on with the worm, but at the heart of it, that’s all it is another worm albeit one with a sophisticated command and control network.  There are some good write-ups out there to get a basic understanding and SRI has a very good paper if you’re interested in the technical details.

So how does this worm affect the world of control systems?  Honestly, it shouldn’t, but whether you like it or not it’s a real world test of a few different policies that you should have in place.  First one, firewalls, 135/tcp and 445/tcp should be blocked, that’s the initial vector that this worm uses, exploit the MS08-067 vulnerability that we talked about on patch day.  I won’t say that there’s no good reason for you to have these ports coming into your SCADA network, but I haven’t heard one.

Next up, mobile computers that are uses on both the control system network and other networks.  File and print sharing might be blocked at the firewall, but if it’s enabled and all your systems are unpatched then you may well have a problem. Not only will this worm, and others like it try to use the MS08-067 vector, it will also try to access SMB shares using a long list of common/poor passwords. Two tests here, rre your SCADA admins allowed to have laptops connected to the corp network too?  How about home, coffee shop, or hotel networks?  These systems should be the first ones patched, and should be treated more suspiciously than others.  Strong password policies should be common knowledge by now, and I would hope that none that the worm is using are protecting anything as important as access to a control system.

Sneaker net, the silent killer.  Infected systems also infect removable devices that it uses, so make sure that USB drive that you’re using to move data back and forth isn’t already spreading badware.  Disable autorun, and be careful of sharing media with others, and between systems, and please don’t plug thumbdrives you’ve found somewhere into the control system network, you’re effectively sharing files with every other system that it’s been used in, and it might not cause problems on this one, but you’re asking for trouble.
Lastly, if you haven’t done any of these, and you find yourself infected, good egress filtering should make the infection rather painless.  Outbound connections should be denied by default, and those that are enabled should have a very good reason for being there.

In the mean time, there’s a lot of ways to tell if you’ve got a problem.  Nmap would be my tool of choice if you’re looking for one.  So in the end, if you’re following good practices you don’t have anything to worry about, and if you’re not then you should have started worrying about this back in November.

Or: “A Few Simple Suggestions for Improving Core Control System Security”

The core precepts of IT security are confidentiality, integrity and authentication, precepts not present in the design of most control systems, but there are some simple changes whose implementation would serve to greatly improve the security of control systems. Changes which could be readily and easily added to the majority of in the field systems.

Currently, in the majority of control systems, if an attacker can penetrate into the control system network segment, the lack of the core security principle allows the attacker to “own the system”. These failures are most notably:

*The use of poor authentication schemas e.g. no passwords, default passwords, and cleartext password exchanges. Authentications is critical in any system as it ensures that a user is who they “appear” to be and authentication limits the privileges that a user had to modify data and interact with system processes. This inherent weakness in control systems allows attackers a variety of attack pathways including; firmware attacks, and simple vectors into “rooting” control system services on both field devices and pc based servers and workstations.

*No use of data integrity schemas. The lack of integrity controls allows attackers to manipulate the data communicated on the system through man in the middle, IP spoofing and various other attacks.

*No encryption. Though confidentiality of the control system communication may not be of the upmost importance, the encryption of password and key exchanges would serve to greatly improve the security postures of control systems.

The main impetus of this posting is to suggest some simple modifications to control system designs that will correct these faults. Changes that could be readily implemented on existing control systems and that would not excessively tax the resources of field devices nor introduce excessive latency into time critical communications. Many of these suggestions are based on the specifications for the IPsec data authentication (Authentication Header) standard.

Though there has been a lot of discussion of encrypting all communications on control systems, there are various trip-falls to implementing this. Namely the field devices lack the computational horsepower to perform full packet encryption and decryption. This then requires the use of a bump in the line encryption device, which could be very costly and difficult to deploy on all devices “in the field” of large installation.

Data confidentiality on control systems via strong encryption is also not an essential necessity. Full packet encryption makes debugging communications virtually impossible, and outside of authentication exchanges what if any of the data exchanged needs the protection of encryption? Note that “outside of authentication exchanges” is key.

The IPsec  Authentication Header standard describes a robust schema for providing data authenticity, integrity and confidentiality. By following the basis described by IPsec’s Authentication Header we can develop a similar security headers for control system protocols. This header would contain:

*Encrypted authentication key, token or password. This is equivalent to the Security Parameters Index (SPI) of the IPsec standard.

*Encrypted packet sequence number.

*Integrity Check Value. Like the IPsec ICV this is a hash of the packets data including the majority of the headers. This hash is recomputed by the receiver and if the calculated has does not match the sent hash then the packet has been tampered with.

Each of these fields is a 32 bit value adding 96 bits to the end of a packet.

The addition of this security header to packets in control system protocol ensures Authentication and Integrity. If the packet is faked, replayed, or modified by an unauthorized user (attacker) the lack of the proper authentication key will ensure that the packet is rejected. The hash of the packet will also compute incorrectly doubly assuring that the packet will not be processed and assuring the integrity of the data in the packet. Man in the middle attacks with the specific goal of packet tampering are now moot.

Returning to the topic of authentication. A recent SCADASEC list discussion indicates that the use of no or default passwords is rampant in control systems, a finding already widely known by everyone who has spent any time in these environments. This practice must change. Vendors must provide systems that require new passwords be chosen during the installation/configuration phase of system deployment. These passwords must be changed to passwords that meet some minimum password policy determined by the asset owner. 

As asset owners and system maintainers have voiced some concern over operators having sufficient time to type in passwords during critical situations, the use of some type of stored token/key on a fob or USB stick may also be permissible. This would allow for the system to quickly query the key, while still providing for strong authentication.

Strong authentication also allows for better accountability, auditing and forensics as each login and transaction can now be correlated to a specific user.

Passwords exchanged across the network, wherever in the packet they occur must be encrypted. If the above IPsec style authentication and integrity schema is employed then each packet can be signed by its originator’s/user’s password/key.

As this schema only employs 96 bits of encrypted/hashed data it is a feasible implementation for security on many existing control systems and field devices. This schema removes the ease by which attackers can now infiltrate control systems by using no passwords, default passwords and sniffing passwords off of the network and also provides data integrity by which the tampering and replaying of data can be detected and avoided. This schema also increases the ability to perform real auditing and forensics on control systems.

One of the most common exceptions to best practice is operators in the control center share an operator account. In fact, they do not login or logout out at all. The main reason for this is operators cannot risk losing access to the HMI for even a few second or minutes it takes to login and logout. Additionally, opening all the displays and arranging them could introduce additional delay.

I recently saw a technical solution, a “change shift” feature in a SCADA system. In this system an operator coming on shift would click the change shift button on a display. A login window appears, and the operator enters there username and password. If successful, the login window closes and the HMI resumes operation. All the displays are the same as before. However now all log entries and authorizations are under the new operators username.

If the login fails, the operator can try again. If an emergency situation arises or the operator can’t remember the login, he can click cancel and resume operations without delay.

This is one of many technical solutions. The point is there are solutions to this problem, and we all probably give in to easily to the “it won’t work or is not possible in SCADA” argument.

Loyal readers of this blog know I’m a huge proponent of strong, two-factor authentication solutions to prevent all the vulnerabilities in password authentication. Two factor is based on having two of the three factors:

- something you know (a password)
- something you have (a token or smartcard)
- something you are (a fingerprint)

At Distributech I came across Xyloc from Ensure Technologies which combines an active RFID card, something you have, with a password, something you know. As you walk up to a computer, the RFID reader will pick up the RFID card and request the password. After entering the password you are logged in. If you leave the area, the computer will lock. If you walk back in the area before the configurable idle timeout, the computer will unlock. Very simple to use.

The product can be added to Active Directory with a schema extension and costs $59 for the card and $120 for the reader.

If you are one of the many organizations that use passive RFID cards, the ones you have to hold close to the reader, to access the control center, you will need to carry two cards. Also, we have some concerns on how this would work in a control center where you have multiple PC’s and multiple operators in close proximity. While we still lean towards a smart card solution as our preferred two-factor option, this is the best proximity two-factor solution we have seen.