|
T |
alk to any IT Department or CIO and you will get an earful about the time and expense spent on patch management. While Microsoft is one of the biggest culprits, Linux, Oracle, and other software is far from patch free. The Yankee Group estimates that companies spend annually an average of $254 per PC for patch management.
The first step to addressing patch management is to automate the inventory and patch distribution process wherever possible. Manual distribution is almost always doomed to failure. Security assessments of SCADA systems with manual patch management typically finds many missing patches -- and this is when the System Administrators know the assessment is coming. Applying missing patches will only be a temporary fix if the patch management process is not changed.
While patch management, software solutions provide visibility to the patch status and remove the need to visit each system, they do not relieve the need to test the patch prior to deployment, and phased deployment is always recommended. The patch management process is likely to remain more cautious in a SCADA network than the average IT enterprise network.
SCADA, DCS and other process control applications have been notoriously bad when it comes to patching. The problem takes two forms. First, the time it takes for the application vendor to certify the patch. The applications are complex, so it may not be practical to certify the patch in hours or days, but in the past, testing could take months. Many of the SCADA application vendors have stepped up to address this challenge and now certify a patch within one or two weeks.
The second and more troublesome problem is when asecurity patch will break the SCADA application and therefore cannot be applied. This should be a rare occurrence in a well designed software application, and the results vary greatly by vendor and application. It can be quite bad. One major vendor only certified 19 of the 45 security patches Microsoft issued in 2004. Users of this vendor&rsquos application are stuck with an unpatched SCADA system with 26 vulnerabilities, 7 of which Microsoft labeled critical.
Equally troubling is the length of time a patch is listed as an exception. In most other enterprise software markets, such as the database and ERP markets, vendors commit to making their software work with the latest, secure version of the operating system. That is not to say all patches can be applied immediately, there are cases where a patch will break these IT enterprise applications. However, the application vendor quickly develops and releases at least a plan to modify their software so the patch can be applied in the future.
Some of the simplest hacking attacks involve scanning a system for missing patches, downloading an exploit from a site like www.packetstormsecuirty.org, and owning the server. Since the SCADA community is forced to live with unpatched systems with many known vulnerabilities, compensating security controls are required.
Network Intrusion Detection Systems (IDS) identify hacking reconnaissance attempts and cyber attacks on known exploits. Most of the solutions are signature based. Each time a new exploit is developed, a corresponding IDS signature is released. Updating the IDS is very similar to updating anti-virus software.
Each IDS signature is assigned a severity level at release, and responses are typically tied to severity level. Triggering a high level signature may cause a page to the System Administrator and Information Security Officer or an audio/visual alarm in the control center, while a low level signature may simply cause an e-mail notification.
IDS signature severity levels can and should be adjusted to reflect the risks to the monitored SCADA system. For example, if you don&rsquot have an Oracle database on your network, an Oracle related signature with a default level of high is not appropriate for your system. The alert should be addressed because it indicates someone is trying to attack the network, but the attacker will not be successful with that attack.
How does this tie into patch management? If a patch cannot be applied, the system is in a known vulnerable state. When an IDS detects an attack against a known vulnerability it warrants the highest level alert and response because the attack is likely to be successful. The IDS is a compensating control to at least facilitate quick response and limit damage due to the cyber attack.
Intrusion Prevention Systems (IPS) are inline devices that not only detect attacks, but also block them. Think of an IPS as a firewall with added IDS intelligence to the firewall ruleset. An IPS could stop communication that included an exploit that attacked a known, unpatched vulnerability. IPS needs to be carefully deployed so the IPS is not fooled into forcing a denial of service attack.
Firewalls are typically deployed between the enterprise and control network, but a firewall&rsquos benefits are applicable elsewhere in the control network. How about a firewall or IPS between the control center and the field to limit attacks from the field on vulnerable systems in the control center? An internal IPS could even be used to segment vulnerable control servers that cannot be patched from HMI stations and any other systems that gain access to the control network.
