ISC-CPH November 2024 – Day 1

@Vivek Ponnada – Managing Complexity by Engineering OT Security

Currently there are a lot of good developments within OT Security, on better and more useful than the other, yet this is up to you to decide what is best fitted for your environment. These developments are for example: Dedicated ‘Security PLC’ (as compared to ‘Safety PLC’), built-in security features such as local-PLC firewalls, OT purpose built end-point protection tools, virtual PLC’s … Also a better acceptance and usage of “industrial” standards such as the IEC62443 is driving these developments and future road of OT security.
However, there are still hurdles to tackle such as a lack of (cyber) security practitioners that are both IT and OT savvy, trying to apply IT security solutions to OT but (sometimes obviously) failing, difference in OT between different sites of the same org which can be considered logic, as “local” OT has their preferred supplier, but makes it diff to manage from an organisational wide perspective, this is again proof that every site is unique and should be treated as such, yet that there should be a common baseline amongst diff sites of the same org

Unfortunately, there is also still a silo thinking approach between IT and OT, that didn’t change over the years unfortunately. Teams need to work together instead of against each other as (OT) security is for everyone. We all need to work together!
With regards to policies and frameworks to use: either embed IEC62443 into your existing framework, or use the ISO27/IEC62443 combination in which the ISO27 tackles the IT part of your environment together with the ISMS, and where the IEC tackles the specific OT parts of your environment.

@Daniel de Santos – Software supply chain security in OT/IoT cellular routers

This talk was about why OT cellular routers are important or interesting to look at from a security perspective. The presenter pointed out that most organisations are aware of the attack surface on their IT (and maybe OT) network infrastructure but that many OT/IoT Edge devices do not always receive the necessary attention they should. These edge devices connect different networks either directly on the Internet or through gateway systems, but those connections are not always controllable or known to the asset owner. For example 4G/5G modems/routers in industrial cabinets that are “needed” for remote maintenance…
These devices are often based on old(er) open-source solutions (such as for example OpenWRT) yet these are never or not always updated, security features are also often lacking and well known vulnerabilities are present within.

Listening to this talk gets me thinking that cellular routers should be equally treated within network segmentation and this is yet another reasons to migrate towards a centrally controlled remote access solution where possible.
Which also means that this should be stipulated upfront in any security requirements you set that vendors or integrators should adhere to.
Exceptions might be possible, but then the necessary security measures inside your environment must be in place to prevent unwanted connections into your network.
Next to this logical aspect, there is also a risk element with such edge routers connected to specific systems as you should also take into account the possible impact on your production processes of these remotely accessible systems.

@Andres Jacobsson (Orange), Martin Eenfeldt (Volvo) – Securing OT – Lessons learned from Volvo

In this talk about the network segmentation road Volvo tool it was mentioned that “OT Security is NOT a copy/paste of IT Security”. I would go further and state that is also not a copy/paste of any other site having OT security as each site is unique (as also mentioned in the first talk).

The different steps Volvo took in their Network segmentation journey were:

1. Design: network zoning plan with all necessary designs and explanations (zone & conduit concepts), information sharing to all stakeholders. A requirement was that the design should be based on IEC62443. Also part of the design phase is a (network) communication design (this is what I call an access matrix in my presentations).
2. Migration: select and prioritize the segments to migrate (and place behind a firewall).
3. Clean-up phase: verify unused firewall rules and clean these
4. Runtime: creating more strict(er) rules, implement secure access tools, provide visibility and training in new tools

In my personal opinion, I would add a step between the design and migration phases. Namely I would also do a paper based migration/mapping first before going into the live migration as in such way potential problems during the live migration might be avoided. This will also allow you to go back to the design phase should you see that some things would not be working as foreseen or intended. It is important to have an as up-to-date inventory as possible before going into migration phases.

Other take-aways from this talk:

• Make sure the entire company is included in the segmentation exercise
• Make sure that site isolation is possible, which means having as few centralized solutions as possible, or at least have this deduplicated
• Make sure enough training is provided and information is distributed

@Kcert – Create visibility on your production network

The question is: How can you get cybersec related visitibility within OT? By looking at your Logs… “all we need is logs”
These can be obtained from

• Honeypots in OT
• OT devices themselves
• Scada servers, jumpstations, engineering stations etc… all “OT’ devices
• Firewalls (preferably only the necessary part but how do you define this?)
• Network monitoring: Open Source solutions or commercial solutions

One of the problems you’ll might run into to is that there is not a one-size-fits-all solution for gathering all this information nor does it exist in one single “box”…
This is dependent on your environment, and one log might be more important than others, but those other logs can be used to have easy detections.
So it’s all about importance, relevance and it should be tailored to your system an device criticality as well as your zoning criticality…

Important things to keep in mind if you start logging:

• you should define what you really want to be seeing within your environment and focus your logging on that aspect
• your logging infra should/must follow your network zoning approach
• it is important to collect the right logs
• looking at logs will allow you to identify the things that should be investigated and potentially removed from the OT network environment, these might even be the less obvious things.
• logging can bring networks down due to the amount of traffic (or potential UDP storms when using UDP traffic for logging), it might therefore be more interesting to use log aggregators and filtering before sending these logs through the FW
• it might be better to start “low” and build up your logging capabilities as you go along.

@Tommy Evensen – Why IEC62443 Risk Assessment should be your first step in an OT security program

Risk assessments and system design are covered in IEC62443-3.2. The standard states that you should do it, but the how to actually do it is not explained.

Within the IACS security lifecycle, Risks assessments come obviously first, followed by design and implement and finally maintain.
With regards the Initial risk assessment according to -3-2 and vendors… A lot of vendors have their “own way” of doing risk assessments. My reflection on this is whether vendors are capable of doing risk assessments on their own installations or not? As they not too involved in doing so? What about having independent risk assessments? In my opinion this is not only better but provides also more value to asset owners.

Main take away from this talk is that there is a lot in the standard stating that you should you do something but the how to actually perform or execute this is missing within the standard.

@Ken Bonfeld Nielsen – Hybrid warfare & ICS/OT systems

We live in a heavily digitalized world but we all tend to forget the hidden critical OT infrastructure, which is becoming more and more complex, and is playing a huge role within today’s society. Such critical services are at the minimum “communication”, “critical infra” and “energy”.

The problem is that people are spoiled (in most parts of the world) … They are “used” to have power all the time so a power hiccup or small outage is immediately big news. A worst case scenario with those critical services is that control is taken over by an adversary for a certain amount of time…

The goal of Hybrid Warfare is to destabilize and weaken the opponent without direct military conflict.
What rules apply to hybrid warfare? Currently none…

So the question is how vulnerable are the ICS/OT/SCADA systems towards hybrid warfare attacks? As “legacy systems” are actually just “old shit” out there, filled with vulnerabilities and weaknesses… According to Dragos, 83% of the vulnerabilities within an OT environment reside deep inside the OT network. As those devices are hardly ever patched or fixed whenever security issues are discovered in them.

The fact is that ICS attacks could/will be weaponized in the (near) future to kill people… If not already done so…

To summarize this: We should be more resilient against attacks and able to always come back in a good state. Meaning that your OT environments should be well protected by all means.

Continue reading day 2: ISC-CPH November 2024 – Day 2