Applying Cyber Threat Intelligence to Industrial Control Systems

THE PURPOSE OF CYBER THREAT INTELLIGENCE (CTI) IS TO HELP PROTECT NETWORK INFRASTRUCTURES.

Threat intelligence platforms (TIPs) have been created to help facilitate CTI effectiveness within organizations employing traditional information technology networks. The industrial control system (ICS) sector can benefit from these technologies since most ICS networks are connected to IT networks. In this paper, we provide a high-level overview of CTI and TIP capabilities and show how they can directly support ICS security. We also discuss a prototype solution using a commercially available TIP in conjunction with a standard open source intrusion detection system to mitigate a well-known ICS attack, BlackEnergy.

INTRODUCTION

Industrial control system (ICS) networks have historically operated without much regard to security (compared to traditional IT) due to their proprietary properties and lack of external connectivity. However, with the evolution of the Internet and organizations looking for the most efficient way to do business, ICS and IT networks have become interconnected and in some ways indistinguishable.

The challenge with this new environment is that both types of networks have fundamental differences regarding their operational and security goals. An ICS network’s main objectives are usually focused on integrity and availability, while IT networks tend to be more concerned about confidentiality. Further, there are safety and revenue implications that can arise from the lack of availability to ICS devices. ICS and IT network operators therefore have different risk tolerances and perspectives regarding security. The ICS sector also does not tend to have as many security and defense tools as found in the traditional IT area.

Improvements in cyber threat intelligence (CTI) are showing great benefits in cybersecurity. CTI is based on traditional intelligence gathering and processing activities and produces actionable information products that allow decision makers to understand their operational risks and better prioritize and allocate resources.

“CTI is much more than simply collecting and sharing data—its true value derives from putting threat information into context that is more meaningful for the end-user”

Although CTI has primarily focused on traditional IT systems, we believe ICS network operators can also derive benefit from this capability, because many of the threats to ICS actually come through traditional IT networks (e.g., business networks, billing systems, remote monitoring, etc.). In this paper, we provide a brief overview of CTI and its benefits. We then discuss threat intelligence platforms (TIPs) as an emerging technology used to better deal with the vast (and growing) amount of CTI data. We then discuss a notional scenario in which an ICS network connects to a larger enterprise network and show how CTI and TIP tools can be used in conjunction with standard IT security tools to improve the overall security posture of the ICS network. We conclude with an example implementation use case for the BlackEnergy ICS attack against Ukrainian energy companies.

CYBER THREAT INTELLIGENCE

In 2015, the Cyber Threat Intelligence Integration Center (CTIIC) was created with the mission of determining connections among malicious cyber incidents (The White House, 2015). A major thrust of this initiative was to promote development and sharing of CTI data throughout the public and private sectors.

Benefits of CTI. There are tactical, operational, and strategic benefits of CTI, as shown in Table 1. Tactical benefits will be seen instantly, and operational benefits will begin to form as the context of an attack becomes apparent. Strategic benefits result in an organizational situational awareness that will help current and future security initiatives (Shackleford, 2015 & Friedman & Bouchard, 2015).

Used effectively, CTI offers significant added value because threat information can be shared quickly, often in machine-readable formats that can be readily ingested by security incident and event management (SIEM) tools and increasingly capable threat intelligence platforms (TIPs). But CTI is much more than simply collecting and sharing data—its true value derives from putting threat information into context that is more meaningful for the end-user. This reduces uncertainty, improves situational awareness, and leads to more informed risk management and security investment.

CTI Production Process. Development of CTI is similar to other forms of intelligence products and follows a traditional intelligence cycle (Figure 1) and as described in Joint Publication 2-0, Joint Intelligence (Department of Defense, 2013).

The production cycle begins with requirements or questions that need to be answered, such as “What are the most significant threats to our organization?” or “Given our network maintenance posture, what kinds of attack techniques are we most vulnerable to?” Note that these questions are unique to the end-user and are not the same for everyone. There are no short cuts or technical solutions to replace the amount of introspection required to support a good risk management program. CTI is also adversary-based, because by knowing details about an adversary, an organization can enhance its protection against specific attack methods known to be used by that adversary.

Once the CTI requirements have been identified and prioritized, a data collection plan is developed (to include identification and evaluation of information sources), followed by data processing and exploitation. Analysis generates intelligence products (answers to the questions posed earlier), followed by timely dissemination to internal and external customers. The entire cycle includes ongoing evaluation and feedback to ensure that new information can be taken into account and to ensure that the original questions are being answered effectively.

Data Sources. Examples of CTI data sources include traditional SIEM tools (e.g., network monitors, firewalls, intrusion detection systems), dedicated CTI data feeds, vulnerability and malware databases, and the system users. The data collection must be timely and accurate, in addition to being relevant to address incidents that are likely to happen, are happening, or may be likely to happen. The data collected should also be meaningful to the organization and help answer the original CTI requirements.

The crux of CTI is the contextual information surrounding attacks. This is the comprehension of the past, present, and future tactics, techniques and procedures (TTPs) of an extensive range of adversaries. Included in this analysis should be the connection between the technical indicators, adversaries, their incentives and objectives and information about the target (Shackleford, 2015 & Department of Defense, 2013). This should lead to informative and proactive decision-making. From these sources, indicators of compromise (IOCs) can be identified, documented, and further analyzed. An IOC is a forensic artifact of an intrusion that can be identified on a host or network device. They are tied to observables and related to measurable events and can be categorized as either network-based or host-based. Network-based IOCs include email addresses, subject line and attachments, connections to specific IP addresses or web sites, and fully qualified domain names (FQDNs) used for botnet command and control (C2) server connections. Host-based IOCs may include the presence of filenames on a local drive, programs and processes that are running on a machine, and creation or manipulation of dynamic link libraries (DLLs) and registry keys.

“Analysts should be aware of and minimize internal biases and strive to manage and address uncertainty (e.g., known knowns, unknown knowns, etc.).

Many CTI feeds exist, and the number is growing. Originators include private companies, government agencies, and non-profit group or open-source groups. Open Source feeds^1,2,3,4 are free to use, but they provide only basic IOC data with limited context, and the end-users need to perform more of the analysis to meet their specific needs. Commercial feeds^5,6,7,8 are richer and provide more actionable intelligence.

CTI data collection and analysis processes must be well-documented and efficiently executed, enabling organizations to think systematically on how to effectively use the collected information. Analysts should be aware of and minimize internal biases and strive to manage and address uncertainty (e.g., known knowns, unknown knowns, etc.). This includes keeping track of how answers are developed (traceability) and not just focusing on the answers themselves.

CTI products should also be customizable to meet the needs of different decision-makers. People consume and act on information differently depending on their role within the organization. An analyst will need just enough context to determine if further investigation is needed, whereas an incident responder may require extensive details to track down and assess related incidents. Finally, the chief security officer needs information to evaluate threats in a more global context (Friedman & Bouchard, 2015).

THREAT INTELLIGENCE PLATFORMS

 

A Threat Intelligence Platform (TIP) is a resourceful way to manage and automate CTI feeds, provide organizational-wide situational awareness, and integrate with existing SIEM tools. Some well-known examples include AlienVault⁹, ThreatStream¹⁰, Recorded Future7, and ThreatConnect¹¹. Their capabilities vary, but successful integration can support timely analysis and visualization of intelligence from a wide range of sources. A TIP will also allow for concurrent access making existing network tools stronger and more integrated throughout the enterprise.

TIP employment is most beneficial within a Security Operations Center (SOC). The SOC (which could be a virtual organization) has teams which are responsible for IT control, monitoring and operations (e.g., analysts, incident responders, and Chief Security Officer). Key features are highlighted in Table 2 (Lawson & McMillan, 2014).

A general scenario showing how CTI and TIP technologies can be used within an organization is discussed below and illustrated in Figure 2. Detailed whitepapers are available to provide much more detail (Trost, 2016).

The process begins with ingesting CTI feeds, user input data, and local defensive network data. CTI feeds include commercial and open source feeds, whitepapers, government reports, technical reports, emails, SIEM logs, etc. A parser will extract, store, standardize, categorize, display and archive incoming data from the multiple sources. The SOC monitors the process to ensure proper operations and perform further research on the data to identify additional IOCs for inclusion in the TIP database.

As IOCs are incorporated into the TIP, they are classified with a status of Review or Active. Items labeled as Review are periodically analyzed for validity, and a human analyst may decide final approval of a data element. Some TIPs may be configured to automatically approve data that comes from certain sources. In some cases, IOCs may be deemed irrelevant, perhaps because of how the local network is configured, or because the risk is perceived as being low. The TIP will keep a record of these decisions, which duplication of effort and documents the approving authority’s tolerance of risk when evaluating future IOCs. Once IOCs are validated for distribution, a TIP can automatically format the data for use with the organization’s SIEM tools (e.g., IDS/IPS).

APPLYING CTI IN ICS NETWORKS

ICS networks generally do not have the same scope and breadth of security and SIEM tools as traditional IT networks. However, because most ICS networks connect to an IT network, some common IT security tools are applicable. Research has shown that using a standard IDS, such as SNORT, will improve security of ICS networks (Bartman & Kraft, 2016 & Horkan, 2015). SNORT’s open source nature coupled with its vast IT security industry-wide adaptability make it highly recommendable for IDS purposes. In recent years, ICS and SCADA rule development has led to key enhancements for ICS infrastructures, to include specific SNORT rule sets for ICS security (Marshall, 2016 & Digital Bond). Similarly, ICS stakeholders wishing to increase their ability to prevent, detect, and remediate attacks would likely see benefit in adopting CTI and TIP solutions.

Kill Chain and Indicators of Compromise. The two main stages of an ICS attack are gaining access (intrusion) and creating the effect itself (Lee, Assante & Conway, 2016). The intrusion stage will produce the most prevalent IOCs associated and can be studied using three zones as shown in Figure 3. In the Internet zone, threat actors conduct reconnaissance operations and decide where to probe further. The Enterprise Network zone is where threat actors either attempt to gain access to the internal network. IOCs associated with this could be spear-phishing email details, malicious files being delivered or downloaded.

Finally, the internal Industrial Network zone is where threat actors conduct C2 operations, maintain access, and prepare for future activity. IOCs associated with this could be unknown connections to external IP addresses and FQDNs, unrecognized programs, and any mutual exclusion or registry key creation.

The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) has abundant information that can be used to support an ICS CTI program. Other sources for CTI include reputable security firms and credible ICS-related open source websites¹². Published alerts, advisories, bulletins, security blogs, reports, and white papers are all excellent sources for gathering appropriate data.

 

Example ICS Attacks. We now introduce three well-known attacks (BlackEnergy, Duqu, and Havex) to further illustrate the utility of CTI and TIPs in ICS networks. The Dragonfly campaign against the Ukraine power companies used a variant of BlackEnergy malware, resulting in successful attacks with physical impact. Duqu and Havex were used to perform reconnaissance of ICS networks. Technical reports describe these attacks in great detail (Lee, Assante & Conway, 2016 & Symantec Security Response, 2011 & Belden), and in each case, the attack vectors came through a traditional IT infrastructure, so there will be IOCs related to IT systems.

BlackEnergy. In 2015, a Ukrainian power company, Kylvoblenergo, suffered power outages related to a cyber-attack. A use case was generated (Lee, Assante & Conway, 2016) to better educate ICS stake-holders about security threats, vulnerabilities, and adversary TTPs. The attackers used spear-phishing to obtain valid credentials to gain initial access to the targeted networks. This included emailing infected Microsoft Office attachments which then allowed the malware to establish contact with its C2 system. Using stolen credentials, attackers mapped the victim network, pivoted through the infrastructure, and elevated privileges. Gaining persistent access, they abandoned the original access point and used virtual private networks (VPNs) to access devices controlling electrical power breakers, and about 27 substations were brought offline. Potential IOCs associated with this ICS attack include email (subject and to/from addresses), attachment file names, and traffic associated with in- and outbound C2 connections.

Duqu. Duqu was documented in a technical report in 2011 (Symantec Security Response, 2011). Nearly equivalent to Stuxnet, Duqu’s intent was not to cause physical damage but to gather intelligence on the victim’s assets and infrastructure, possibly to facilitate a future attack. It is primarily a remote access Trojan (RAT) and does not have any code specifically related to ICS. It contains three files: a driver, a main dynamic linked library (DLL), and an encrypted configuration file. In one reported case, the malware was delivered as a Microsoft Word email attachment containing a zero-day exploit. The infection process for the malware is beyond the scope of the paper, but essentially an installer injects the main DLL into the core operating system begins a process of extracting other harmful components, which are then injected into other processes allowing security products to be avoided. One component is responsible for establishing C2 connections outside the target network using web requests. Attackers enumerated the network, logged keystrokes, and gathered system details. Duqu also propagates using network shares and peer-to-peer connections. Potential IOCs would include filenames and hashes of the malicious files and IP addresses of the C2 connections.

Havex. The Dragonfly attacks included multiple forms of malware, such as the Havex RAT, to conduct espionage and reconnoiter ICS networks (Belden & Kaspersky Lab, 2014 & Nelson, 2016). Threat actors planted malware on targeted machines using spear-phishing emails, watering hole attacks, and trojanized software downloads from compromised ICS vendor websites. All three methods required user action to trigger the malware installation, and upon installation the malware would establish contact with a C2 web server. Multiple modules were embedded in the reply message and installed on the target machine. Havex would then embed itself into the Windows Registry and maintain persistent presence. Havex also highlighted the vulnerabilities to so-called air-gapped networks that rely on engineering workstations moving from the main IT network to isolated ICS worksites. Potential IOCs from this attack include FQDN, filename’s along with their respective hashes and registry entries.

EXAMPLE IMPLEMENTATION

In this section, we present complete solution for using CTI and TIP in order to improve security against the BlackEnergy threat to ICS networks. Our demonstration used ThreatQ ¹³ as a TIP solution employed in the DMZ as shown in Figure 4, and we used SNORT for the internal network.

Virtual machines (VMs) were used to emulate most of the devices, to include two engineering workstations (Ubuntu and Windows 7) and a human machine interface machine (Windows XP). Figure 5 shows the general flow (which parallels Table 2) of information used to obtain pertinent CTI and ultimately generate signatures for SNORT IDS alerts. ThreatQ offers great flexibility in importing and exporting data. While there are pre-programmed export options, it is highly tailorable to a wide variety of implementations. Open source data from ICS-CERT, Symantec,

SCADAHacker¹⁴, and IOC Bucket¹⁵ were used to gather general CTI. The primary source for this example was an alert document regarding Ukraine’s power outages¹⁶. This document was obtained from the ICS-CERT secure portal document library and outlines the IOCs associated with this particular attack, such as FQDNs, email headers, IP addresses, URLs and filenames. Six pages of the document were exported to a PDF file that was imported into ThreatQ. Other CTI sources could also be used in a similar manner.

Once imported into ThreatQ, the information was correlated and categorized as part of the BlackEnergy malware family. At this point, the using organization could also share this intelligence with outside entities using a simple export operation provided by ThreatQ. SNORT was initially configured using prevalent ICS rules from ICS-CERT¹⁷, Emerging Threats¹⁸, and Digital Bond¹⁹. The IDS host also included user-developed python scripts to create additional SNORT rules based on information provided by ThreatQ, such as malicious IP addresses, filenames, MD5 hashes, and DNS queries.

A scenario was then constructed to test the rules generated from ThreatQ. In the scenario, the HMI machine opens an Internet Explorer window and attempts to visit an IP address (41.77.136.250). This address had been correlated to BlackEnergy by ThreatQ, and an alert rule was automatically configured for SNORT. The IDS successfully alerted that a malicious IP address was being accessed within the network. As a result, improved situational awareness was obtained to stop and prevent future attacks.

While this example focused on BlackEnergy, the same approach works equally well for Duqu, Havex, and other ICS threats.

 

TECHNOLOGY LIMITATIONS

CTI and TIP may not be mature enough for most organizations to fully and successfully implement without signification customization. The standards for the data structure and sharing CTI are evolving. The MITRE corporation started an initiative that created the Structured Threat Information eXpression (STIX) language and Trusted Automated eXchange of Indicator Information (TAXII) delivery protocol for CTI. However, these are now being transferred to another standard, OASIS²⁰. Because of these evolving standards, organizations using CTI may have to invest additional time and resources to stay abreast and perhaps revisit their implementation.

Additionally, commercial feeds operated by vendors use proprietary methods for delivery, thereby complicating their integration into a larger TIP solution. Offerings by vendors are still somewhat vague, leading to confusion as to which intelligence is actionable compared to second-rate information. Over time, the CTI community will be better able to determine what intelligence is actually useful and provide better tools for effectiveness.

Finally, IOC data that is specific to ICS threats is quite limited. ICS-CERT hosts an advisory website that lists specific known vulnerabilities in ICS systems categorized by vendor. At the time of this writing there were numerous advisories related to buffer overflows, but CTI and TIPs will not account for this type of attack because they are not considered IOCs but rather flaws in software and/or firmware designs. Attackers can also use a variety of exploits (cross site scripting or structured query language injection) to obtain unauthorized access without leaving observable or measurable artifacts to support CTI.

CONCLUSION

The capabilities of cyber threat intelligence and threat intelligence platforms show significant potential in cybersecurity for industrial control systems and critical infrastructure. These technologies benefit IT and ICS infrastructures because of the connections these environments directly have in this ever-connected world. Capabilities and standards are still evolving, but as the community grows, information sharing should improve, yielding greater benefits over time.

The views expressed in this document are those of the author and do not reflect the official policy or position of the United States Air Force, the United States Department of Defense, or the United States Government.

References

1. US Computer Emergency Readiness Team, “Automated Indicator Sharing,” https://www.us-cert.gov/ais.
2. Hail A TAXII, http://hailataxii.com/
3. ThreatCrowd, https://www.threatcrowd.org/
4. “Awesome Threat Intelligence,” https://github.com/hslatman/awesome-threat-intelligence
5. FireEye, “Cyber Threat Intelligence Services,” https://www.fireeye.com/services/cyber-threat-intelligence-services.html.
6. Symantec, “DeepSight Intelligence,” https://www.symantec.com/services/cyber-security-services/deepsight-intelligence.
7. Recorded Future, https://www.recordedfuture.com/.
8. Verisign, https://www.verisign.com/en_US/security-services/index.xhtml.
9. AlienVault, https://www.alienvault.com/.
10. ThreatStream, https://www.anomali.com/.
11. ThreatConnect, https://www.threatconnect.com/.
12. SCADAHacker, “Think Like a Hacker to Secure Industrial Control Systems,” https://scadahacker.com/
13. ThreatQuotient, “ThreatQ Threat Intelligence Platform,” https://www.threatq.com/threat-intelligence-platform/.
14. SCADAHacker, “Think Like a Hacker to Secure Industrial Control Systems,” https://scadahacker.com/.
15. IOC Bucket, “Community Supported Threat Intelligence,” https://www.iocbucket.com/
16. Industrial Control Systems Cyber Emergency Response Team, “Cyber-Attack Against Ukrainian Critical Infrastructure,” https://ics-cert.us-cert.gov/alerts/IR-ALERT-H-16-056-01
17. ICS-CERT, “Industrial Control Systems Cyber Emergency Response Team,” https://ics-cert.us-cert.gov/.
18. Emerging Threats, “Emerging Threats Rule Documentation,” http://doc.emergingthreats.net/
19. Digital Bond, “Snort IDS/IPS rules for ICS and ICS Protocols,” https://github.com/digitalbond/Quickdraw-Snort
20. “OASIS Cyber Threat Intelligence (CTI) Technical Committee,” https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti.