Monthly Archives: February 2017

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.