Malware in SQL – Really new?

18 February 2017

In post ‘Magento stores targeted by self-healing malware that steals credit card details‘, published by David Bisson on 18 February 2017 at Graham Cluleys’s newsletter, I found the really astonishing statement from Willem de Groot:

This is the first time I see malware written in SQL.

What happened? To put is briefly, someone found a vulnerability in Magento-powered online stores. He guessed the web shop’s administrator password. With this, he managed to get the database schema user’s username and password, connected to the database and added an after-insert trigger to the sales_flat_order table. The after-insert triggers adds code to the web page which sends customer credit card details to the attackers C&C server.

To be honest, there’s nothing new here.

As in 90% of all data breaches, a vulnerability known for some month was used to get administrative access to the shop software. For details please see post ‘10 tricks to improve Magento admin security‘.

But this must not necessarily end in a data breach. The issue here is, that the admin user was used to get privileged access to the database. This kind of trouble can be easily avoided by strict separation of duties inside the database. Only the database schema owner should have the privileges to change the database schema, i.e. add a trigger to a table. All other database users should have the privilege to access data sets only. And the web shop software administrator should have no access to database content at all. That’s plainly long known database design best practice.

In general, database application designers spend a lot of time ensuring data integrity. Data integrity was not violated here. In this case, we encounter code integrity issues, which result in the loss of confidentiality.

Separation of duties is the standard means for mitigation of this kind of issues. In addition, we should consider adding code integrity checks to ensure code integrity at runtime.

Have a good weekend.

IIoT is killing ISA 95!?

12 February 2017

At the end of his great post ‘IIoT is killing ISA 95 !! …a.k.a. the operators that talked to the CEO‘, Antonio Buendia, Head of Manufacturing Process Control at Novartis, asks 3 questions:


What do you think?

(1) Do you think that ISA 95 is dead, and we are going to have a series of devices each of them talking to each other? And those devices will be able to digest and process the information by themselves?

(2) Do you think that the IIoT will bring enhanced communication capabilities, but we still need to establish a hierarchy, a set of common rules for orchestration, but a new model has to be created?

(3) Or do you think that ISA 95, with some minor tweaks, is still the model of reference for the IIoT?”


There is no simple answer to this question. In my opinion the answer depends strongly on the issues one is going to solve with IIoT devices.

Even in the age of IIoT ISA 95 will still be a reference model in production. Let me be quite clear: For just the execution of a manufacturing order the ISA 95 model will fit more or less well even in the age of the IIoT.

For other production related issues the ISA model may possible not fit. Let me make this clear with an example:

For the execution of a huge production order it would be helpful to know in advance of the likelihood of equipment breakdowns during the execution time. IIoT devices like smart pumps or smart valves are able to gather operational data. This data can be used for the prediction of the remaining run time of the devices. If the remaining run times of all devices are known, it is easy to predict whether a production order can be executed without major delays.

This is one possible added value we create from IIoT devices. Currently only few manufacturers are collecting these data. The Industrie 4.0 concept goes far beyond the local collection and analysis of operational data. If the data is sent to the equipment manufacturer for further analysis, we can create more value from the data because the device vendor may correlate the data with the data from thousands of similar devices. With this, remaining run times can be estimated more accurately.

From my point of view, it is not necessary that an individual device contacts the vendors database to get details about its remaining run time. It is enough if the device management system does this job. I don’t think that the ERP system must be involved at least during this analysis phase in this communication.

With this, my answer is: ISA 95 is still a reference model for manufacturing in the age of IIoT. But we have to develop other models or extent the ISA 95 model if we are going to turn the capabilities of the IIoT into EBIT.

Have a good week.

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.

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

IIoT Security is the result of close collaboration between Vendors, Contractors, and Operators

18 December 2016

In the past days, I prepared a key-note speech for the kick-off meeting of a new working group in the Committee for Operating Safety of the German Federal Ministry for Work and Social Affairs.

IIOT: Impact of Digital World on Physical World

Impact of Digital World on Physical World in IIoT

The working group deals with the impact of the Industrial Internet of Things (IIoT) issues on functional safety. In the world of Cyber Physical Productions Systems (CPPS) or the IIoT this becomes very important. A CPPS is a system which combines physical objects (through sensors or actuators) and processes with digital (virtual) objects and processes across information networks and the internet. In the IIoT the digital word acts upon the physical world. With this we have to be prepare for safety issues.

Cyber Cyber Physical Production System Structure

Cyber Physical Production System Structure

Safety engineers have long lasting experience in managing the risk created by classic vulnerabilities of safety devices like power or compressed air malfunction, corrosion or operator errors.

With the embedded system and its connection to the internet thousands of easy exploitable IT vulnerabilities enter the safety domain.

The main difference is that these IT vulnerabilities are exploitable by

  • any internet user
  • from any location and
  • at any time.

If the safety device is not properly designed this may have a negative impact on the safety function, thus on people or the environment.

Inspection engineers have in general only few experience in managing the risks which arise from the IT vulnerabilities. Objectives of the working group are to create awareness for these new kind of IT risks and to provide working materials for support of the inspection engineers.

During preparation, I focused on the easy exploitable weakness CWE-16 (Configuration), in particular Default Passwords.  Lots of process control systems (PCS) are attached to the Internet. And lots of them are accessible with default passwords for the administrator and guest account. Although the vendors strongly recommend to change the passwords during startup, neither the engineering teams nor the operators performed their duties.

Vendors started to deal with the default password issue and introduced individual passwords for PCS. Rockwell for example uses the serial number of the system as individual password:

The Configuration pages (Device Identity, Network Configuration and Device Services) are password protected. By default they can be accessed with:

  • Username = administrator
  • Password = the adapter’s serial number (listed on the adapter’s home page)

Generally, this is a good idea. But if the engineering team does not remove the password from the systems homepage or change the password this will create no security. The same applies to the operators. At least before commissioning they must check whether basic security best practice is implemented. Since the power plants I found during my research are operated from some years now, the operators checked this definitely not.

With this it is required that Vendors, Vontractors, and Operators

  • introduce Security-by-Design and Cyber Risk Management in their design standards
  • introduce Security Gates in their design processes
  • enhance handover and acceptance procedures by security requirements

to make sure that at least basic security requirements are met, thus the safety of the systems is not compromised by IT vulnerabilities.

That’s it for today, and for this year. I will take a Christmas break.

A merry Christmas to you all
and the best wishes
for health, happiness and prosperity
in the New Year.

Christmas Trees

Whaling emerges as major cybersecurity threat

3 December 2016

Whaling is a type of cyber fraud that targets mainly corporate executives. It is very closely related with phishing, thus not new. For a superb collection of examples see this slide show published on CIO.com.

As always, the combination of People, Process and Technology measures (PPT approach) is the best way to combat whaling:

People. The most effective way to deal with whaling is security awareness training. Include some whaling attacks in your anti-phishing training to raise awareness.

Processes. Enhance your information handling policy (IHP) or office manual. Add rules for the compliant handling of business requests by email:

  1. Users should never act on a business request from a company executive if the email is not signed with a company owned and valid email certificate.
  2. Never trust an email of a business partner when it is not signed with the partners valid email certificate.

Communicate the IHP to all users and train them in use and handling of email certificates.

Technology. Configure your email system such that all mails to external partners and at least all emails from company executives are signed with a valid email certificate.

With this, the risk of getting the victim of a whaling attack is greatly reduced.

Have a good weekend.