Tag Archives: Patching

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.

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

IBM Webinar: Force the Bad Guys to Use Zero Day Exploits with Continuous Endpoint Enforcement and Patching

22 October 2016

On Tuesday, I watched the IBM webinar ‘Force the Bad Guys to Use Zero Day Exploits with Continuous Endpoint Enforcement and Patching’.

On slide 3 one could read the really interesting statement ‘NSA: no zero days were used in any high profile breaches over last 24 months’.

Slide 3 - Force the Bad Guys to Use Zero Day Exploits — and Why That’s a Good Thing

Slide 3 – Force the Bad Guys to Use Zero Day Exploits — and Why That’s a Good Thing

Curtis Dukes, deputy national manager of security systems within the NSA, said that NSA has been involved in incident response or mitigation efforts for all ‘high profile incidents’ one has read about in the Washington Post or the New York times.

In all this incidents hacker used somewhat simple technology like spear phishing, water holing and USB-drive delivery to get onto the victim’s networks.

In the last 24 months, not one zero day has been used in these high profile intrusions.

That is a very interesting insight. Moreover, Curtis Dukes said that

The fundamental problem we faced in every one of those incidents was poor cyber hygiene.

The central idea of the webinar is to harden all systems by applying at least all existing patches to the known vulnerabilities, and in a timely manner. For most of the organizations this is a great challenge: Applying an endless stream of operating system and application patches to thousands of servers and endpoints is a never-ending nightmare. But essential to hinder an attacker, who managed to get on the network, in his lateral movement across the network.

If an attacker cannot exploit existing vulnerabilities, he is forced to install hacking tools from his C&C server. But this will increase the likelihood of detection because the attacker creates anomalies which can be detected e.g. by a current anti-malware solution or a well-tuned SIEM system.

It is important to recognize that cyber hygiene shall not be restricted to patching and password rules. Operating systems offer lots of powerful inbuilt tools, e.g. PowerShell, which can be used by an attacker to move laterally across the network. Such movements a much harder to detect, because they are very similar to standard user behavior. Pass-the-hash attacks are another example where patching is of limited value only.

It is very important to understand what threats a security solution mitigates. But it is of crucial importance to know the gaps and to have some ideas on how to deal with them effectively.

Have a good weekend.