The limits of responsible behavior

2012-04-06T15:33:00.001-07:00

What is responsible behavior for cyber security specialists? Do we always tell the world all we know? Should an engineer go public with a security vulnerability detected at a chemical production site when the owner / operator is not willing to fix it? Should a researcher publish a security vulnerability when he discovers one in a critical SCADA / DCS product? Should a vendor keep a security vulnerability a secret for its customers when a vulnerability is detected?

I have been struggling some time with these and other questions involving responsible behavior and security ethics. What are the limits, when does responsible behavior become irresponsible behavior? When are we trying to improve the cyber security posture of the SCADA / DCS to prevent serious incidents that potentially affect thousands of people and when are we just trying to make ourselves a name to grow the companies security business?

Theoretically every vulnerability can be fixed, in every day practice this doesn't always happen. There are several reasons for this:

The vulnerability is discovered in legacy products / software no longer supported by the vendor. In those cases the vulnerability is fixed in the releases still supported when the problem is generic for that product. (See link) So the owner / operator needs to invest in an upgrade and find the right moment to do this.
The fix of the vulnerability requires a redesign of the entire product / software. In those cases a vendor will include the fix in a future product. This takes time, not many people are aware that design organizations work years ahead in time to develop new products.
An alternative method is available to remediate the vulnerability and prevent an exploit. A properly designed security architecture has multiple layers of defense and can protect this way also insecure products.
Finally not every reported vulnerability can be duplicated during vendor verification tests.

So vulnerabilities exist for various reasons and both the vendor as well as the owner / operator do not always have the possibility to fix the problem.

When it comes to the disclosure of vulnerabilities we see different behaviors, for example the the HP TippingPoint Zero-Day Initiative (ZDI) pays researchers for revealing their discoveries to them. ZDI uses this information to build security filters for their HP Tippingpoint IPS (virtual patch), and in parallel they inform the vendor so a fix can be developed. This is a classical example of responsible behavior. Improve a product, provide a protection, allow a structural solution, and publish when all parties are ready.

Another example of responsible behavior is the case where a researcher informs ICS-CERT about the vulnerability. ICS-CERT will report the vulnerability to the vendor, also in this case ICS-CERT will wait with going public with the vulnerability until the vendor has created its fix. Maybe the security consultants are left in the dark and don't like this, but it is the best way of protecting the owner / operator's assets.

This are two cases were the "window of vulnerability", the period between disclosure of a vulnerability and the availability of a security patch, is minimized. But there are also researchers that have a different approach, and go public even when there is no security patch or other fix available.

An example of this are recent publications at DigitalBond. This company organized a "project basecamp" an event that tested process control equipment, primarily PLCs, for having vulnerabilities. In the months following, the results of this project were published including the exploits that make use of these vulnerabilities. exploits that can stop the PLCs ladder logic, or even replace it. Their latest publication is a direct security compromise of all Modicon Quantum PLCs. PLCs that are used frequently in critical places in the control systems.

Must we consider DigitalBond's action as responsible behavior? DigitalBond's owner - Dale Peterson - believes he is doing the right thing. In my opinion not, I consider DigitalBond's approach as irresponsible for society. I would even say that if a successful exploit causes damage, prosecution should follow. This is typical a case where the researcher should have waited for the availability of a fix, or at least provide advise on how to mitigate the problem with alternative security controls. To publish both the vulnerability and provide an exploit using Metasploit is endangering society and a step too far. How far are we willing to go in endangering society? Refineries, chemical plants, offshore platforms are no toys you can play with, these PLCs often function in the hart of the plant and can cause very serious problems, where are the limits of responsible behavior?

Application Whitelisting for SCADA / DCS

2012-04-06T06:01:00.000-07:00

Application White Listing (AWL) is the new buzz word in discussions between vendors of SCADA / DCS systems and owner / operators of plants. What does AWL offer, what are the issues, is it worth the investment?

What is AWL?

AWL is a protection mechanism for servers / stations that prevents that non-authorized executables are started. It acts at the moment an executable is started, either by a user, another program or malware. So it blocks malware to download code and initiate it. Often AWL solutions have enhanced their products with resource and device protection functions. Such as memory protection, registry protection and USB device protection.

How does AWL work?

AWL scans the hard disk of a computer for executables. It recognizes executables by inspecting the file format. When it identifies an executable it creates a hash code of the executable, a hash code being a fixed size identification for the code. Because hash codes are vulnerable to collisions (different data files resulting in the same hash code) multiple hash codes are created using different algorithms. This way the chance of a collision is minimized. These hash codes are stored in an index table allowing a quick search / comparison each time the system evaluates if an executable is authorized to run. This authorization is configured by the system administrator who determines if code is clean and trusted and allowed to run.

What is the strength of AWL?

AWL has a DENY by default policy, so it blocks any program / process to be initiated if it is not previously authorized. So malware downloading malicious code in the server / stations and activating this code is stopped. Because AWL uses a deny by default policy any code with a hash value that is unknown, or a hash value that is known but not authorized to run, will be blocked. This way AWL protects the system against various zero-day attacks.

Another strength of AWL is that it doesn't need a signature database that requires daily updates to protect the system, no external network connection is required. An important advantage for SCADA / DCS where remote connectivity is limited as much as possible.

Another advantage of AWL compared to antivirus is that its impact on the system performance is less.

Finally some AWL vendors offer overviews of all executable code in your SCADA / DCS. This is very helpful for configuration management purposes.

What are the weaknesses of AWL?

AWL blocks the execution of a program / process at the moment it is activated, but when it is activated and running in memory it has no longer control over it. So attacks, for example the Conficker worm, that run in memory and enter the system in a different way than downloading code are not stopped. For example an attack that successfully exploits a buffer overflow, or uses a DLL injection technique can execute malicious code in a previously authorized process. Tests showed that malware such as used by Conficker and Duqu were not stopped.

Another concern with AWL is how to stop it when it fails. After AWL is software and software has a long history of bugs. The use of AWL in SCADA / DCS has the potential to fully shutdown the system, and with this the production. AWL is tamper proof, it is resistant against easy ways of killing the AWL processes. This in order to protect itself against attacks that first disable AWL and than run malicious code. However this also makes situations possible where stopping AWL is not a quick activity, so increasing the risk of loss of production or worse.

Another drawback of AWL is also linked to system failure. Reboot time is increased because the AWL application has to rebuild its index tables at start up. For a regular reboot no issue, but in case of a massive power failure and subsequent reboot this can become important. And even though most plants have UPS systems, full power outages do occur - sometimes even caused by the UPS.

Finally at a certain moment in time when implementing an AWL solution we need to decide if the executables are clean from malware and can be trusted. This is certainly not an easy decision. Vendors do offer an online database with the hash codes of known malicious executables, but this would require a direct connection between the AWL server and the Internet.

Conclusions of AWL for SCADA / DCS?

AWL offers additional protection (particularly against zero-day attacks), certainly for those solutions that combine USB device control and core AWL functionality.
AWL still requires traditional antivirus, it is not replacing it. So additional cost and additional system load will occur.
AWL requires more management than traditional antivirus does.
AWL improves the configuration management of SCADA / DCS in that it provides overviews over all executables in a system. So allows you for example to easily spot legacy executables.
AWL adds complexity (additional server, configuration, response to failure) to SCADA / DCS and therefore also adds new risk

Is AWL worth the additional cost, time will tell. For certain it draws a lot of attention.

SCADA / DCS cyber security

The limits of responsible behavior

Application Whitelisting for SCADA / DCS