Software moles in your systems
Old programs, utilities, and plug-ins languishing on your computer or control systems could threaten your security.
In the world of espionage, a mole is an agent or spy that infiltrates an enemy environment and establishes him- or herself as a normal citizen. The agent burrows in and simply carries on a quiet life in an effort to blend in, not appear suspicious, and develop relationships. Eventually, the mole will receive orders to carry out the spying functions originally planned, taking advantage of trust built up over the years.
Moles may be living in your computer and control systems. They weren’t placed there deliberately, and they may not even realize that they’re moles, but they can be just as dangerous. In this context, we’re talking about software that has security vulnerabilities. One situation that has brought this to mind recently is Java, with reports that hackers have been able to exploit vulnerabilities in conjunction with dangerous websites.
Many computers still have Java installed, possibly an old version, even though the user may not be aware of it. If a hacker discovers that it is there, it can become the port of entry for breaking into the system. The software in this case is the mole. It’s been on the computer for who knows how long because nobody has checked to see what’s there. If it doesn’t get used, it probably doesn’t get updated, so older versions with well-publicized vulnerabilities may still be in place.
Java is certainly not unique in this sense. There are many other examples of programs that have been exploited in the same way. The U.S. Department of Homeland Security publishes alerts related to industrial software online at http://www.us-cert.gov/control_systems/ics-cert/#monthly-monitor. If you’ve never gone there and looked at the number of platforms that are compromised, brace yourself for a shock.
The threat is that a hacker will use one of those vulnerabilities to pry his way into your system. This could happen because a hacker has become proficient at exploiting some favorite vulnerability and goes around looking for targets of opportunity when he can find that software on a system. Or, if he is determined to break into your system specifically, he may hunt and probe to catalog what you have and figure out the weakest platform.
The first step of building a defense is knowing what you have on your systems. You need to look at all the software loaded on your individual computers and servers, and know everything that is there, right down to the revision level. You also need to know why you have what you have. The most frustrating situation would be if a hacker used a vulnerability in an old software platform still on your system that no longer even served a purpose. Worse yet, imagine that it was software totally unrelated to your process that some bored operator installed so he could watch DVDs in the control room. How would you explain that to your boss during the investigation of an intrusion?
You need to know revision level because platforms go through various iterations, some of which are better than others. Generally, the assumption is that the most recent revision will have more of the vulnerabilities fixed.
Checking revision levels often exposes the reality that industrial users don’t patch software with any regularity. There are exceptions, of course, but studies show that users simply don’t implement patches as they should. There are some important reasons why users are cautious. If you have a control system that uses Windows and Microsoft sends out an update, it’s possible that there are elements of that update that aren’t compatible with the control system platform. You either need to test the patch yourself in a way that won’t interfere with your functioning system, or wait for the vendor to clear it for deployment. Whoever is responsible for that network probably has other things to do, and who has time to deal with that kind of thing anyway?
The sad truth is that most industrial users represent easy targets for a determined hacker. While it may not be practical to undertake more comprehensive efforts to protect your networks, you can keep track of your software collection. You may not be able to close off every conceivable hacker entrance, but this one is pretty strategic.
Sidebar: Recommendations on Java, Matthew E. Luallen
The US-CERT recently issued alert TA-13-010A on the Java vulnerability and guidance on how to respond to it. You will need to find out if Java is needed for any of your local or web-based applications and then disable it if it is unnecessary. Systems that are already not communicating to areas of less trust are not at risk, as the exploit must be transferred to local device over the network or through a local connection such as a USB drive.
The wider view of security is to not just worry about Java but to ensure continuous protection of your cyber system. This includes having or installing only the applications that are necessary, using a functional change management process to handle system changes, such as addition or removal of access, applications, and patches, and a monitoring and response mechanism. Some practical advice for these and more are available through the 20 critical security controls or the consensus audit guidelines.
Peter Welander is a content manager for Control Engineering. pwelander(at)cfemedia.com
Read more on industrial cyber security below: