Tag Archives: Patching

Concerns about using open source libraries from an IT security point of view

18 December 2017

Some days ago I participated in a discussion about the necessity of using open source libraries in industrial software development and the data scientist workbench. IT security is often perceived as spoil sport in such discussions …

To be honest, I like open software. I prefer for example Firefox on Windows 10 because the configuration of Edge is really annoying. However, when it comes to the use of open software libraries in scientific or industrial software development projects or by data scientists I have two major concerns:

1. I have just no clue what the open software libraries do in addition to their intended use.

This sounds a bit paranoid. The question is:

Can we make sure, that no malicious code snippets are hidden in an open software library which send the company’s secrets to a cyber criminal’s command and control server, or which encrypt all data?

In my opinion this is not possible. Reviewing e.g. the 300 thousand lines of code of the OpenSSL-1.0.2 project is a herculean task, which has to be repeated for every patch and release. We can automate the software review process with advanced code analyzers. With such analyzers, we can make sure that open source code has no or few critical errors. But analyzers cannot find malicious code snippets, they just make sure that such snippets cause no critical errors during program execution.

Advanced Persistent Threat (APT) solutions may detect malicious behavior. But when a developer or data scientist includes open software into his code, the threat type changes from external to insider threat, thus APT solutions are no longer effective.

Eventually, we have to trust the developers of open software. Thus, the use of open software depends largely on the risk appetite of an organization.

2. I have no idea how to fix vulnerabilities in software which uses open software libraries.

Firefox gets security patches immediately after vulnerabilities are published. For example, the remote code execution vulnerability CVE-2017-7827, published 11/15/2017, was patched on the morning of 11/17/2017. When I logged in to my Linux box in the evening, even a patch for the Firefox ESR version was installed.

The OpenSSL-1.0.2 library mentioned above can be used potentially in many applications, in the worst case, some of them may be connected directly to the internet. The developers of Firefox take care of security bugs in this library. Who cares in the case of self-developed software? And how fast? Just remember the Equifax data breach some months ago. The reason for this really costly data breach was an unpatched vulnerability in the Apache Struts framework …

The focus of open software developers is innovation. Thus, the use of open software will be a major driver in the digital transformation, and we should foster this use to stay at the cutting edge of digital transformation.

Nevertheless, we must be aware of the risks of this use and take proper precautions for their mitigation.

Have a great week.

Advertisements

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.