DIY insider threat detection/prevention within ICS environments

This is a summary of the talk I gave during the CS3sthlm conference in October (link to topic: https://cs3sthlm.se/program/presentations/dieter-sarrazyn/)

The goal of the presentation was to help people and organisation in setting up an internal “insider threat detection/prevention” program without looking at the big/expensive products out there. I will explain some (sometimes simple) things and tricks can be used to tackle the insider threat within ICS environments.

Before we dig into how you can detect/deter or prevent insider threats, we first need to define what an insider actually is. This is often described as an internal employee stealing information. Yet, a better definition, which I personally like, is the one from Probst et al [1]:

an insider is a person that has been legitimately empowered with the right to access, represent, or decide about one or more assets of the organizations environment

This actually means that employees, contractors, visitors, cleaning crew, remote workers all have to be considered as an insider. These have all received a specific right to access one or more assets, being it either physical, logical or social.

Detection, deterring and prevention of insider threats can (and should) be done on 4 different aspects: network, system, physical and social (people). On each level, you can use specific things/solutions to do so.

Network level

One of the first things to do is to create a baseline of your complete network environment. This often means that you will have to “chase the wire” to get to all juicy details. This should contain all systems, current network zones, bridge systems and remote access connections in use. Without a decent network map and inventory, you often have an “invisible network” unknown to you compared to what you believe to be having (the “visible network”).

You should also ask yourself the question whether you will detect an insider plugging in a rogue device and/or access point in your network environment. This can be easily done with some open source tools such as arpwatch to detect rogue devices on a wired network and kismet to detect rogue wireless networks. These tools can be installed on any device yet a low coast solution can be a raspberry PI.

Preventing (some) insider threats can be done through setting up decent network zoning including an access matrix stating what type of network access is allowed from zone x to zone y and what security measures are required to enable this. This can be based on the IEC 62443 standard.

System level

On the system level we want to make sure that adversaries are not succeeding in getting access to the system in the first place. So you could start by properly securing your system. This means creating a secure system baseline and use this for hardening but also for verifying the security state of systems over time.

Another piece of the puzzle is using media sanitation solutions to make sure no malware is able to enter your systems.

But it doesn’t stop here, only securing a system is not enough, logging of several actions/events is also required in order to detect potential malicious insider actions. Insertion/usage of usb sticks, usage of certain access rights, commands executed from the command line are all events you want to know and log.

Physical level

On the physical level you have actually two specific parts: physical access people have and physical connections onto your environment. I’ve talked about physical connections to your network environment already within the network level part of this post.

About the physical access that people have, it is important to know who is where at what time. It is also important to have physical detection and protection measures on your sensitive locations within your environment (including rack door alarms).

It is also important to revoke physical access rights when these are no longer required for the role that people are having within the organisation. This is however often forgotten.

Social level (people / users)

When trying to deal with insider threats, another important aspect is “knowing” your users, just as you have to know your logical (network, systems) and physical environments.

Knowing your users is not that simple as you should be familiar with their background, their normal working hours, physical access they have, logical access they have. However you also need to know a bit more about their beliefs, their social life etc. This sounds a bit intrusive yet it is important to understand that events in social life and/or beliefs could trigger them to become an insider threat actor in the (near) future. Most of the insiders are actually “sleepers” but once they are triggered, you better be prepared to counter most or all of their attempts to harm your environment in any way.

There are moments when it becomes a really tedious and difficult task in getting to know your “insiders”. This is specifically the case during revision/maintenance periods when a lot of other people (contractors, subcontractors…) have to be on site to perform the necessary maintenance tasks.

Logging and (network) monitoring

While I did not specify this as one of the aspects on which detecting, deterring and prevention of insider threats can be done. Logging and (network) monitoring is a sub-aspect of all 4 mentioned aspects.

I think its becoming clear that performing some of the mentioned will (quickly) generate quite some logging. These should ideally be centralized so that these can be easily analysed. However, the more data points, the more logs, the bigger the data to go through. So be ready to have people ready to deal with this otherwise your logging efforts are rendered to be useless.

Summary

To conclude this post, insider threats have been and will always be there. However, there are ways to harness yourself against insider threats and to detect, prevent or deter these from being exploited.

Link to the presentation: DIY insider threat detection – CS3sthlm 2017

 

[1] Probst C., Hunker J., Bishop M., Gollman D. (2009), “Countering Insider Threats”, ENISA Quarterly Review Vol. 5, No. 2, June 2009