Control systems have always had alarms and alerts and fine-tuning the system is always an important part of commissioning and every day operation.
In the last several years, ICS Network Security Monitoring (NSM) technology and methods have been a popular topic in our space. These ICS NSM security alerts must be tuned, much like the ICS alarms are tuned. In fact, the process should be similar…and tied closely together. This session will look at how successful techniques from alarm management, such as ISA 18.2, can be used for NSM alert tuning.
Chris will show that your SOC analyst may not have to be an ICS expert, but it will be important to build in context behind each alert that should come from working with your ICS Engineers and SMEs.
The main focus of this talk is to cover ICS Security Alert Tuning
I won’t get into the details about ICS threats as they should be ICS Security 101 by now…and the latest threats have been talked about in other S4x20 talks
Main point: Nothing is new under the sun! No need to reinvent the wheel here…
But this is important to document because there are not a lot of talks or articles about how to tune ICS NSM tools and alerts.
There are articles and standards for engineering ICS alarms (ISA 18.2 standard, EEMUA 191) and for tuning traditional IT NSM systems (NIST SP 800-94), BUT not something that blends both concepts
I will show you the similarities from ISA 18.2 and 800-94 and flesh out an OT NSM Security Alert Engineering method
Lastly, I will cover the importance of using Security Alert Engineering with your OT Incident Response
Continuously ask yourself these questions
Security Engineering is a relatively new and fast-growing segment of ICS Engineering.
These referenced talks cover some of these concepts…and my talk on security alert engineering expands this research.
What are these Goals that little bobby is talking about?
ICS visibility to ICS Security visibility end goals + response playbooks / use cases = Security Alert Engineering
What drives that whole process? The philosophy!
Operations and Security have different and overlapping goals for monitoring
Where you get visibility depends on your network, what the critical assets are, and the ingress/egress points are
You should also study past ICS attacks and how they map to the attack lifecycle
Can we modify existing engineering alarm philosophies to dovetail with our SOC analysts alert philosophies for ICS?
EEMUA 191 standard is not free but the philosophy checklist is free to download
Philosophy drives the whole process…whether adding a new alert or revising an existing alert.
Philosophy drives the whole process…whether adding a new alert or revising an existing alert.
With regards to OT Security NSM, these are some of the basic things to collect from different parts of the OT network
Detection goals may be different for each system, which is why detection needs to be engineered.
Each OT system is engineered
No network is the same
Thus detections must be engineered too
Tuning a network sensor has challenges that are similar to any ICS or SCADA system
It has to be managed
Alerts have to be tuned
Nuisance logs/alerts are no use (write a rule to where it will fire only on specific instances)
https://www.automation.com/library/articles-white-papers/alarm-monitoring-management/keeping-the-peace-and-quiet
Talk about several real use cases that we’ve seen regarding real-world tuning situations
Given the “insecure by design” problem with ICS protocols, apps and devices, protection is difficult if the attacker is past the cyber security perimeter. Detection is key to identify
attacks early and response is necessary to prevent or limit the consequences. This is a fast-moving area in ICSsec.
you can start small with detection. For example, even monitoring your endpoint protection for alerts. Or monitoring your firewall log for blocked egress attempts. The idea that detection is a continuum and you can, and maybe should, start small rather than be overloaded with data no one looks at. The equivalent of operator alarm fatigue.
Rather it is here is how you should gather and consider attack and threat information as part of your ICS risk management program.
Design and engineer these playbooks to match your ICS alert philosophy and ICS incident response plan