ISC-CPH November 2024 – Day 2

@Robert Valkama, Fortum & @Mikko Kenttälä, SensorFu – leaks & OT Security – Reap process improvements from Network leaks

A good network monitoring will be able to verify if the network segmentation is done properly and still working properly. Using a solution to identify if something can “breakout” of the network architecture will allow you to quickly identify possible missing elements in your OT security defence or policies. It complements physical security walkthroughs in that way that when a change is made immediately after such a walkthrough you won’t detect it until the next walkthrough.

Those sensors (which “phone home” to detect connectivity) are mostly placed inside the OT environments, often on HMI’s or engineering workstations. Problems that can be detected using such solution are:

• Bad firewall configurations => a decent configuration and change management process is needed
• Connections to guest WiFi’s => there is insufficient hardening and a lack in control of procedures and training
• Rogue 4G modems => there is a lack of supplier management and supervision
• HMI (laptop’s) connected to the Office network (to “update” the device…) => lack of solid patch management solution for OT
• a de-commissioned HMI device suddenly connecting to the network again => a lack of proper asset management (asset removal part more exactly)

First being sceptic, but I really liked this talk as Beacon is good and interesting way of finding out things quicker in your network before something bad happened.

@Søren Egede Knudsen – Assessing embedded systems

As with any assessment, you need to understand what you are testing, in this case understanding the device is important. Understand the hardware, the boot process, the firmware…
Following that you can find and know what the vulnerabilities are that are present in these?
It is only after these initial steps that you could attempt breaking the attack chain and how the device could be secured properly. One caveat, there are always vulnerabilities that you will miss and don’t see.

So combining the knowledge of the context within your own environment and the knowledge of the vulnerabilities within your devices, you can properly assess the risk that particular devices are posing to your environment.

This is also where the CRA comes into play, future devices within the EU should not have a lot of vulnerabilities anymore… but this is to be seen (and assessed) first 😉

@Joe Slowik – defensive tensions in critical infrastructure protection

For a lot of people, It seems to be obvious what “critical” means but it is actually everything what is necessary for everyday life.
However, not only the economic significance is important but also the military value of certain infrastructure. What purpose does that infrastructure has for military readiness? Is defence impacted if that infrastructure is no longer there?
Some things might be “more critical” than others, so how do you make the tough choices of what to protect (better) and what not? How do you make the distinction between Non-critical and critical? And could you choose to not protect non-critical infrastructure? This is actually indefensible yet hard choices must be made.
Non- or Less critical infrastructures can apply low-cost actions to reduce risk, such as improving asset inventory, patch management and having a BCP/DRP.
Yet, it might also be interesting to look at larger entities to do more and government could direct resources to those that are unable to help themselves with regards to protecting their infrastructure.

@Daniel – Grundfoss – securing Legacy (the “old shit”)

Some interesting quotes during this talk:

• “Smart cities, (id)IoT Threats” – Smart Cities are often built on old legacy equipment. Introducing IoT within these legacy devices causes the security layers to turn up-side down.
• “Things should be doing what it used to be doing, nothing else …“. This actually means that people are reluctant against changes, even if it would bring them a better and more secure way of working.
• “Legislation will give us unlimited resources…” but first panic mode at management level because of that legislation

How to secure legacy environments us actually following a well-known cycle:

• Identify – what are the most critical systems that we cannot live without?
• Protect – from what? How?
• Detect – encryption? How would that help detection?
• Recover – getting ready for the next attack…

Identify, build list(s) with the following info:

• What is the criticality of the device?
• Is this a Safety device or not?
• What is the device type?
• What is the redundancy available of the device?
• What is the product order number so to be able to order spare devices (including delivery times) – on paper and digital

Protect, prevent against loss of view and loss of control (mostly both of these at the same time)

• Get your environment secure: segment, isolate, decentralize and eliminate PLC’s where possible, use built-in control features
• The problem is the old equipment, can these features and actions be done with this equipment?
• Move control points down in the deployed layers & return of the de-duplicated dedicated controllers
• Reduce number of active devices per system
• Implement Micro segmentation and use built-in controller features
• Also invest in looking into Principle of least privilege
• Look at the application security layer – a possibility here is to use SPAKE2+

Detect

• Encryption – this hides things and prevents you from monitoring the traffic itself, monitoring then has to shift to endpoints but can these endpoints support this (legacy equipment remember)?

@Ron Brash – Your Supply’s chain DNA

Knowing the DNA and the history of a product is critical to find and detect vulnerabilities in a device. Certainly when you are researching the national vuln database, you have to know this. Like name changes, mergers & acquisitions etc

This brings us to the question whether you can trust the SBOM’s provided by product vendors. To be honest, not entirely…

Product DNA and history will also help in analyzing the criticality impact and exploitability of devices, what and how these could be abused through history things in there. It also shows that people moving between organisations take code snippets with them to include these in their new employers products.

Back to day 1: ISC-CPH November 2024 – Day 1