Tag Archives: ICS Security

Vastly improve your IT security in 2 easy steps?

1 April 2017

Keep your software patched and defend against social engineering, and you will win the battle against the bad guys. Let me be clear: From my point of view this is simply not enough. Nevertheless, Roger A. Grimes’ post “Vastly improve your IT security in 2 easy steps” published on March 21, 2017 at InfoWorld is really worth reading, in particular the section about patching.

The key to diminishing this risk is to identify the right software to patch and do it really, really well. The risk reducers I respect know the difference between the largest unpatched program in their environment and the unpatched program mostly likely to be exploited in their environment. A security expert knows there is usually a gulf between the two.

In particular in the production domain, where patching has always to be delayed to the next scheduled maintenance, this is a very important hint.

The big question is: How can we identify the right software on the right and important systems? Without an up-to-date asset directory with the relevant details about cyber security this is a very complex and expensive matter.

But even with an up-to-date asset directory this remains a complex task.

Rockwell/Allen Bradley Systems directly connected to the Internet

Rockwell/Allen Bradley Systems directly connected to the Internet in North America

For example, the likelihood of a cyber-attack on an Industrial Control System (ICS), which is directly connected to the internet, is many times higher than the likelihood of an attack on an ICS which is completely isolated in a security zone within the production network. The first ICS is definitely one of those systems Roger Grimes has in mind, the latter can be ignored.

But the likelihood of a cyber-attack is only half the story. For example, in functional safety the risk is the combination of the probability that a hazard will lead to an accident and the likely severity of the accident if it occurs. Thus, from this point of view, even the first ICS may be uncritical unless it is not used for controlling a critical infrastructure.

To identify the right and important systems is the hard task. It requires an up-to-date asset inventory and a smart risk management process. The plain patching process is just a piece of cake.

Have a good weekend.

Rethinking the Patch Strategy in the ICS Domain

5 February 2017

In the past weeks I reviewed several drafts on Industrial Control System (ICS) security. Although of limited value in the ICS Domain, patching and malware protection are key issues of all drafts.

Especially the patch process, which works moderately satisfying in the Office-IT domain, cannot be directly applied to ICS systems because ICS systems cannot be just rebooted to apply the patch.

Industrial control system patch cycle

Industrial control system patch cycle

To reboot an ICS system a shutdown of the process is required. In the worst case, the operators have to wait several weeks or months for the next scheduled plant maintenance to implement the patch and to reboot the ICS. During this time the ICS is more vulnerable against the threats mitigated by the patch.

With this, we have to design and operate our ICS systems and networks such, that they are resilient against cyber-attacks during the time until the next scheduled maintenance.

The following are examples of technical measures:

  • Isolation of ICS and SCADA systems in secured network zones inside the production network and strict flow control across security devices between the zones are basic design principles for creating robust systems.
  • A secure remote maintenance solution which is completely under control of the plant operators, ideally a rendezvous solution to keep the external service provider in the DMZ.
  • A secure and controlled remote access solution for plant operators.
  • Strict Network Access Control in the entire production network to increase resilience against attackers from internal.
  • No Internet access and personal email in the entire production network. This is a quick win! The same holds for the deactivation of USB disk devices.

Have a good weekend.

Update on IIoT Security Basics

27 November 2016

Number One vulnerability on the OWASP IoT Top 10 from 2014 was “Insecure Web Interface”. The OWASP IoT Project makes the suggestions below to mitigate these vulnerabilities:

A secure web interface requires:

  1. Default passwords and ideally default usernames to be changed during initial setup
  2. Ensuring password recovery mechanisms are robust and do not supply an attacker with information indicating a valid account
  3. Ensuring web interface is not susceptible to XSS, SQLi or CSRF
  4. Ensuring credentials are not exposed in internal or external network traffic
  5. Ensuring weak passwords are not allowed
  6. Ensuring account lockout after 3 -5 failed login attempts

Recommendation (1) is much too weak. Customers must be forced to change passwords during initial setup.

Why? In many cases customers are simply not aware of the fact that a device is accessible from the internet. For example, HMI touchscreens are often remote accessible through built-in web services:

SIMATIC HMI Panel

SIMATIC HMI Panel

This HMI panel is well configured. For access e.g. to the files a login to the system is required.

But the default login password is publicly available from SIMATIC discussion forums and wasn’t changed during set up of the device:

SIMATIC HMI Panel File System Browser Details

SIMATIC HMI Panel File System Browser Details

With this, rule (1) above will not prevent any attacks on IIoT devices. Customers must be forced to change passwords as soon as the device network adapter is powered up and connected to the company network or the internet.

Have a good week!