“Actionable alerts” is a term used frequently in marketing documents and tossed about in conference presentations and panel discussions. We believe that truly actionable cybersecurity alerts are particularly important for industrial control system environments. Unfortunately, the term “actionable alert” is such a high-level “marketing” concept (writes the marketing guy) that important nuances of what makes alerts actionable, and why these factors are important to industrial asset owners, is often misunderstood.
Before we dive into the factors that make alerts actionable, there are a few factors that make (truly) actionable alerts important–particularly to industrial control system (ICS) asset owners and managed security services providers monitoring these critical operational technology (OT) networks on behalf of asset owners.
Skills Gaps: Individuals with deep knowledge that spans plant engineering, operations, industrial control networking and cybersecurity are unicorns. This will be the norm for the foreseeable future, despite efforts to cross-train employees. The result is that monitoring and alerting systems must not assume team members have all the networking or industrial control process skills necessary to investigate and remediate potential cybersecurity issues. This is not to suggest that systems should dumb things down or hide important details. Incident responders and Security Operations Center (SOC) teams alike will need access to detailed network and security data for investigations and forensics.
Necessary IT/OT Collaboration: Whether or not skills gaps are present in any given enterprise, the reality in industrial control environments is that investigating and responding to cybersecurity issues must be a team effort. It often requires input and analysis from multiple people across cybersecurity, plant operations and process engineering teams. Some alerts can be investigated and resolved solely by cybersecurity teams, while others will require collaboration between teams to clearly understand the potential impact of the alert on the physical process, people and equipment.
Thus, for a cybersecurity monitoring system to provide real value, it must consider the needs of different constituencies involved in investigating and remediating cyber events and the need for collaboration between those teams.
The “Three C’s"
To be actionable, we believe alerts need to be clear, consolidated and context rich. The main goal is to minimize “mean time to resolution” (MTTR), and another key objective is to enable the team to efficiently process alerts–basically improving both speed and cost.
All three of these factors are important for the fast and efficient processing of alerts.
Clear – The clarity factor considers the need for an alert to be well crafted and provide immediate understanding to the receiver about what is going on. It should be precise, human understandable, and provide the receiver with immediate situational awareness. Machine-to-machine metadata as part of an alert is fine, but the alert that pops up on a SOC or Plant floor should say what it means and mean what it says.
Consolidated – Too many anomaly detection systems bombard operators and SOC teams with a string of anomalous events. This requires the receiver, if they have the requisite skills, to try and assemble said event streams into something that enables them to grasp what happened before they can begin to further investigate. This is costly, time consuming and in many instances, it requires advanced skills just to figure out if something impactful happened. This increases MTTR and can enable attackers to maintain advantage.
Context Rich – This may be the most important factor. Many systems simply don’t provide the teams charged with investigating and resolving alerts with the information (context) they need to do so. This is even more important with industrial cybersecurity. As we noted above, investigation of potential cyber incidents at plants is, by necessity, a team sport. While the initial triage and investigation may start with the SOC, important parts of some investigations, including impact analysis to the underlying process and physical plant, will often require a call to the engineering or operations teams. If the discussion goes something like: “Our security systems saw anomalous activity between IP address X and IP address Y,” then you’re off to a particularly bad start.
However, if the conversation goes something like this – “We saw a configuration download from the XYZ engineering workstation to the ABC controller and we are forwarding a file showing the diff in the ladder logic,” then you’re cooking with gas.
Bottom Line: If you’re DPI-based anomaly detection system is “deep” then you have what you need to expeditiously and cost effectively investigate and resolve potential threats. We think this is key to answering Dale Petersen’s question “how deep is your DPI”
If the system you selected provides alerts that make you and your team do all the work, then you chose the wrong system.