Threat intelligence plays an integral role in cybersecurity, but industrial control system (ICS) environments offer unique challenges. Let's dig into the basics of intelligence-based detections for ICS — noting the benefits, but also where intel misses the mark.

 
Part 1: Understanding intelligence-based detections

We'll start with some quick sound bites:

 
History and basics of detections
Detections and their technologies have evolved from rules-based matching to correlation and automation. See the (oversimplified) diagram below:

And all was well in the world. But there was one problem. Much like detection’s out-of-state cousin antivirus (AV), you were only as good as your signatures. This resulted in organizations being beholden to their vendor's rules for detection.

Luckily, as technology evolved, so did our options. Open source tooling like Snort and Suricata started to standardize the format for rules-based detections. Groups like Proofpoint and Talos began publishing regular rules updates, and the indicator of compromise (IOC) arms race began.

Indicators of compromise
Think of IOCs as AV signatures, but for everything else. An IOC can be as simple as an IP address or a file hash that someone says is malicious or indicative of malicious activity. IOCs represent past behaviors now identified with some context. IOC information is then converted into a detection rule, such as snort/yara/sigma.

Pros: IOC-based rules will 100% either fire or not fire. These are great if you're looking for something specific, either in the past, present, or future.

Cons: You won't catch what you aren't looking for. IOCs can be too specific, so much so that they miss any variation. Or they may be too broad and cause false positives and lower confidence.

Analytics, behaviors, ML/AI
Some organizations may use the term analytics to differentiate how their detection rules work. This takes some correlated or math-based view at one or many data streams to find 'badness.' Imagine taking one element of an IOC (like a file hash), one element of math (standard deviations from a norm) and some context about the user or entity (device type). The idea here is to cast a wide enough net to catch badness while not restricting yourself to a single thread. To overly summarize ML/AI, so far in security, it comes down to advanced stats (ML) or very complicated IF/THEN statements (AI).

Pros: Good systems elevate actual threat activities from the noise floor of millions of snort rules firing.

Cons: Systems need a complex correlation of many data events and types. Correlation rules engines haven't worked as advertised (see https://medium.com/anton-on-security/security-correlation-then-and-now-a-sad-truth-about-siem-fc5a1afb1001)

 
Part 2: Understanding ICS security

To understand industrial threats is to understand the environments in which they wish to act on their objectives. Current enterprise intelligence works well due to the volume of telemetry/monitoring data, common threat actor objectives and general uniformity of the attack surface. But in industrial environments, not all of those factors are present.

Not All ICS is the Same
Misconceptions often occur when bundling all of the world's infrastructure into the bucket of ICS. These misconceptions take place even more so when it comes to security. The amount of vendor diversity alone adds enough complexity without even considering the specific processes, configurations, operational procedures, safety and human elements of industrial control.

PLCs/RTUs, relays, instrumentation, HMIs, EWS/OWS, historians, protocols… could all match precisely, and the operational posture of that system could still vary wildly. Once designed and built, the operations of the asset cause a shift in how it can and should be secured.

No two ICS attacks are the same
Due to the purpose-built nature of ICS and even considering diversity in technology, no two attack vectors are the same (so far). The areas of overlap exist only in the IT technologies that reside in the enterprise and provide initial access to the OT environments.

The Cyber Kill Chain

Image from Lockheed Martin;
https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html
(click to enlarge)
 

The concept of cyber threat intelligence is great. Attackers must generally follow the kill chain steps to act on objectives successfully. These actions can be mapped and detected, allowing defenders multiple opportunities to catch the 'badness.' For an enterprise with tons of users exposed to the internet and other organizations, factoring in the latest TTP gives blue teams an edge in detecting the latest threats.

History has shown us that for ICS attacks to be effective, the TTP has to be so customized for the target as to not have much reuse. While individual attacks on assets by threat groups prove interest and academically provide use cases, not much of the intelligence proves effective in day-to-day operations.

It's about acting on objectives
What we are really trying to prevent is for the threat actor to "act" on objectives. This changes, depending on the environment. Enterprise operations may be targeted with ransomware while ICS is caught in the splash damage. For the most part, current ICS attacks, intelligence and TTP fall into two categories:

1. Phishing a utility does not an ICS threat actor make
   While most agree that spearphishing as an initial inject may lead to process disruption 20 steps down the kill chain, it doesn't necessarily make the case that the TTP is specific to ICS.
    
2. Reversing ICS malware
   Brilliant reversers are out there with actual ICS-specific malware to investigate. When coupled with industrial experts, these reversers can dig into how the threat actor intended to act on objectives. When this capability is applied to real ICS malware, the wealth of knowledge provided is staggering. The deep-dive reports that come out are typically well constructed, even if the media overhypes the impacts. However:
   The intelligence data derived from existing ICS attacks/malware do not scale or apply outside their target. Stuxnet/Triton/Industroyer researched and documented at that moment in time will never resurface exactly elsewhere (and have not to date).

Understanding that current ICS threat intelligence is overly focused on targets and not objectives isn't necessarily a nail in the coffin. Threat intelligence has its place in the world. In industrial, that world consists of wildly diverse architectures, systems and processes where current intelligence has a minimal impact at the operational level.

 
Part 3: INDUSTROYER

We've covered some intelligence basics and the diversity and variation of ICS environments. Now let's combine the two concepts using an example from the industry.

INDUSTROYER background
A well-known cyberattack against Ukrenergo's "North" substation caused power outages in and around Ukraine's capital of Kyiv on December 17^th, 2016. Like Stuxnet, the Ukrenergo use case became well documented and often misrepresented among cybersecurity professionals.

Finally, the industry had a specific and targeted attack against a substation where the actor achieved its objectives. While this was still an attack in a far-off land for some, industrial cyber consultants, advisers and vendors had the evidence they needed to back the messaging.

However, for those in the IOC and analytics shops, it was still a difficult task to convert this deep intelligence history and information into actionable results. Thankfully, MITRE has broken out and mapped each of the INDUSTROYER components for us to digest.

MITRE ATT&CK for ICS
What is MITRE ATT&CK for ICS?:

"ATT&CK for ICS is a valuable knowledge base for describing the actions an adversary may take while operating within an ICS network. The knowledge base can be used to better characterize and describe post-compromise adversary behavior."
from https://collaborate.mitre.org/attackics/index.php/Software/S0001

You can review the in-depth matrices MITRE put together describing every action an adversary can take in an ICS network. These categories help bucketize all known, unknown and future attacks into standard nomenclature to improve the community's ability to defend and respond.

Actions and outcomes
For INDUSTROYER, MITRE attaches nearly 30 actions and outcomes from the attack, ranging from denial of service to loss and manipulation of view/protection/view and everything in between. The concept here is that a defender could break the attack chain at any given point, potentially disrupting the adversary's end objectives of causing a power outage.

From a monitoring, visibility and detection stance, it's difficult to translate these components into analytics that matter across the board. By reading the first in the list, the challenge is apparent:

The Industroyer SIPROTEC DoS module places the victim device into "firmware update" mode. This is a legitimate use case under normal circumstances, but in this case, is used by the adversary to prevent the SIPROTEC from performing its designed protective functions.

Many other techniques utilized or abused current functionality within the substation SCADA systems. This further complicated the idea that these TTP could be codified into detection rules. One part of the attack did stand out, however:

Question: How do you make a SIPROTEC relay go to sleep?
Answer: Send specific data over UDP 50000

In the case of INDUSTROYER, causing a line of power relays to become unresponsive just needed packets on UDP/50000 with a certain 18-byte payload. That was it.

While there is more to the INDUSTROYER event than this particular packet, it was one of the few actionable detections directly related to the event.

What happened next?

• CISA released a specific advisory for a known (and patched) vulnerability exploited by the adversary in this instance.
• Cisco Talos released a snort rule looking for the specific 18 bytes in UDP/50000.
• Some YARA rules for INDUSTROYER were created.
• IOCs were released, a collection of IP addresses that were TOR node exits, files hashes, etc.

But for an attack that will most likely never be seen in this form again, how useful are these for proactive monitoring and detection?

The history lesson here is good, but there are no magic analytics for the INDUSTROYER attack. The attack was a series of stitched together nonindustrial-specific tactics and techniques to gain initial access, followed by highly specialized malicious applications that ended up abusing completely normal industrial protocols.

Detections are the safety net — everyone will want or require your organization to be able to detect known “bads.” The disconnect with our ICS-specific examples is the expectation (and maybe the marketing) that ICS threat intelligence directly translates to analytics and detections.

 
Part 4: Where intelligence succeeds in non-detection use cases

Where intel-based detections in industrial are ineffective compared to enterprise, intelligence for ICS still has some significant benefits.

BENEFIT #1: HISTORICAL AND REAL ATTACK USE CASES
Industrial intelligence used to be focused solely on vulnerability research, adjacent malware reversing and hypothetical use cases. But when an incident occurs, an expert and detailed analysis of what transpired is valuable. Current industrial threat intelligence does a superb job closing this historical documentation gap.

Take this detailed account of the INUDSTROYER event presented by Joe Slowik at VirusBulletin 2018 (see https://www.virusbulletin.com/uploads/pdf/magazine/2018/VB2018-Slowik.pdf.)

"While the original script was not recovered, in log data a series of rapid RPC authentication attempts to multiple hosts were observed for user 'Administrator' with the same password across over 100 endpoints, specified by host name."

This is helpful context for how actual adversaries footprint and pivot around an industrial environment. Interestingly, regarding the SIPROTEC vulnerability, this module by the adversary was a complete failure but still provides context as to how/what adversaries may target in the future.

BENEFIT #2: INFORMED AND DEFECTIVE THREAT HUNTING
Before industrial attacks' historical and real use cases, scenarios were stuck in the fantasy realm. My peers and I would conjecture how to attack an industrial control system effectively. These attack scenarios, while well-informed, were theoretical. Therefore the recommendations and best practices for defense were also technically hypothetical.

With actual events and retrospectives from intelligence groups, the community finally had some breadcrumbs to follow. While we may never see the same exact attack as INDUSTROYER, we have a blueprint for informed and effective threat hunting.

SANS white paper from Gunter/Seitz
A white paper from Dan Gunter and Marc Seitz on threat hunting, using INDUSTROYER as a reference, is a perfect example of this idea (see https://www.sans.org/white-papers/38710/).

Especially important is what Gunter/Seitz call out as "Phase 2: Hypothesis Development." In summary, hypotheses can be derived from many different sources and perspectives, but having historical intelligence from previous events is a significant step in the right direction. That first step is difficult without reference material to spark the imagination, and cases like INDUSTROYER lay out the roadmap.

BENEFIT #3: MOVING MOUNTAINS (CISOS AND BUDGET)
Early on in ICS cybersecurity, most of the effort was around convincing decision-makers and budget approvers that industrial cyber threats were, in fact, real. We piled on proof points like vulnerability research, attack path analysis, penetration testing and the little bits of intelligence we had about enterprise attacks against industrial companies (remember Shamoon, BlackEnergy and Havex?).

But it was difficult to gain traction. Pentesters could pivot down to the control system, get administrator on an HMI, show they could impact the process and often, the question back was, "So what? Who would actually figure out how to do this?" <sigh>

The intelligence deep dives and supporting content described above have effectively moved industrial companies' budgets and projects to improve security. For better or worse, these events moved ICS attacks from purely hypothetical to current reality.

Visibility is key
While industrial threat intelligence may inspire, operations-based intelligence empowers. Visibility crafted, maintained and controlled by operators (security or industrial) defending their environments is the critical gap in the intelligence conversation.

The goal of this article isn't to downplay the importance of threat intelligence, but to broaden the aperture a bit on where intel can be derived. For ICS, it's vitally important to have a solid understanding and control of the single most effective intelligence generating environment you have: your own control system. To put it another way:

No one knows your environment better than you and your operators.