Monthly Archives: January 2017

Unsecured IIoT devices in untrusted networks

28 January 2017

I am currently reviewing a draft of the German Federal Office for Information Security (BSI) about Operational and Control Technology. The goal of the paper is to define suitable requirements for IT security in OT.

IIoT devices, e.g. moderns sensors like the Schneider Electric PowerLogic ION7650 power meter, offer many communication options, including an optional Ethernet port:

PowerLogic ION 7650 communication options

Schneider Electric PowerLogic ION7650 communication options

With the Ethernet port activated the power meter behaves like a standard web server which provides standard internet communication options for access, e.g. ftp via port 21, http via ports 80, 81 and 443.

The BSI paper introduces the concept of ‘required connections‘ to communication partners outside the production network. This concept is based on the idea that production networks are isolated from a company’s office network as well as from the internet through security devices. The number of required connections, e.g. a connection from the ERP system to the Manufacturing Executions system (MES), should be kept as low as possible. In addition, required connections and the related communication endpoints must be specially protected to prevent misuse.

Lots of the PowerLogic ION7650 power meters are not operated in a production network. They are directly attached to the internet through an internet router, thus directly attackable by all internet users.

With this, each power meter creates its own production network, and every connection becomes a required connection. The major difference to the classic production network is that the power meter is far short of the protection capabilities a classic production network provides.

Thus, special attention has to be paid to the secure configuration of the devices and the attached internet routers during commissioning. Unfortunately, neither the service personnel setting up the device nor the operators seem to be aware of the dangers which result from this limited protection options because lots of unsecured devices are directly attached to the internet.

It is not very likely that a single compromised power meter has an impact on the national power grid. But if an attacker is able to compromise hundreds or thousands of devices …

The BSI paper provides a comprehensive set of technical and organizational measures to OT organizations to deal effectively with IT security issues in production environments.

Nevertheless, I recommend to the operators to review the configuration of and secure their devices. Besides financial loss due to malfunctions unsecured devices can be hijacked and included into bot nets.

Have a good weekend.

Software failures are systematic. Stop all patching?

22 January 2017

In the past days I reviewed the draft of the NAMUR Worksheet NA 163 “IT Risk Assessment for Safety Instrument Systems”. In the age of the IIoT even Safety Instrument Systems (SIS) are equipped with embedded IT components and attached to the production or company network. With this, the safety systems become the target of IT threats, which may result in a malfunction of the SIS in the worst case.

Process safety engineers are often unaware of this new threats. IEC 61511 “Functional safety – Safety instrumented systems for the process industry sector” requires an IT risk assessment for SIS, but makes no recommendations about the details of the assessment.

The aim of Worksheet NA 163 is to provide a practicable risk assessment method to safety engineers, supplemented by a checklist on possible mitigation measures.

On Thursday I watched a video recording of a lecture on ‘Safety-Critcial Systems’ given by Martyn Thomas, Livery Company Professor of Information Technology at the Gresham College.

Software failures are systematic. Slide 18 of 'Safety-Critical Systems - when software is a matter of life and death' by Martyn Thomas CBE FREng, Livery Company Professor of Information Technology, Gresham College

Software failures are systematic. Slide 18 of ‘Safety-Critical Systems – when software is a matter of life and death’ by Martyn Thomas CBE FREng, Livery Company Professor of Information Technology, Gresham College

Professor Thomas makes clear, that “Software failures are systematic. They occur whenever the triggering conditions arise”. I highly recommend to watch the entire lecture because one can gain new insights on software testing and reliability. For a link to the video, the PowerPoint presentation and the Word transcript please see below.

NA 163 recommends to patch all SIS systems components including the supporting systems like the engineering stations or the HMI on a regular basis.

But will continuous patching really increase the reliability of the software components?

Will continuous patching really decrease the risk of a cyber-attack?

How many new systematic defects are built in a software system during continuous patching?

Remember the seemingly endless number of critical vulnerabilities fixed in Adobe Flash Player in the past years…

Let me be clear: I do not call to stop all patching. From my point of view we must focus on the right and important system components, vulnerabilities and patches. With this we can escape from the patch treadmill and focus on the really important issues, e.g. how to build and configure industrial control system networks that are less susceptible to cyber-attacks.

Have a good weekend!

Safety-Critical Systems – when software is a matter of life and death

Martyn Thomas CBE FREng, Livery Company Professor of Information Technology, Gresham College, 10 January 2017

Word Transcript | PowerPoint Presentation | YouTube Video