The Value of Threat Intelligence for Aiding in the Fortification of Industrial Control Systems

    Industrial control systems are the lifeline of critical infrastructure. They are used to control virtually every aspect of production, distribution, extraction of natural resources, manufacturing, transportation systems, and more. The control systems are composed of many different components, including hardware, software, and networked infrastructure. From supervisory control and data acquisition (SCADA) systems–which use network connected devices to locally and remotely monitor data in real-time–to programmable logic controllers (PLC) to aid in a systems automation processes, ICS systems are now more heavily reliant on interconnectivity than ever before. This paradigm shift from centralized control to a more hyper converged infrastructure inherently increases both the threat level and attack vectors. To combat these risks, ICS environments need to begin implementing threat intelligence into their environment’s defense in depth strategies.

    Threat intelligence is the mechanism that helps organizations mitigate risk by identifying the latest threats and exploits through proactive measures and cooperation. It is much more cost effective in the long run for organizations to be proactive in addressing potential threats then it is taking a reactive approach. Given that ICS threats pose a much greater risk of injury, loss of human life, and disruption to the supply chain, the benefit of implementing threat intelligence into ICS environments far exceeds the costs. However, it is paramount to understand that threat intelligence is not a silver bullet solution. While utilizing threat intelligence mechanisms help in identifying potential threats, they do not provide context without synthesizing information into relevant and actionable intelligence.  Robert Lee points out that “By understanding the difference between data, information, and intelligence, security personnel can make informed decisions on what they are actually looking for to help with a problem they face” (Lee, 2015). This requires a human analysis to make meaningful correlations between information and threat intelligence.

    To make use of the information acquired from threat intelligence solutions, organizations first need to identify what potential threats are germane to their organization. Using resources to analyze the data obtained from threat intelligence solutions to determine potential vulnerabilities and aligning them with the known threat vectors that a threat intelligence engine converts information into operational and/or tactical intelligence. This enables resources to take the proactive measures to mitigate the potential risk of exploitation or exposure to the threat vector. This is known as active defense.

    Robert Lee defines active defense as “the process of personnel taking an active and involved role in identifying and countering threats to the network and its systems” (Lee, 2015). Lee states that as part of taking an active defense posture includes implementing the active cyber defense cycle (ACDC). The ACDC model is comprised of four parts consisting of Threat Intelligence Consumption, Asset Identification and Network Security Monitoring, Incident Response, and Threat and Environment Manipulation. Each component of this model essentially works with the next to better classify, check, and adapt to threats.

Figure 1 – The Active Cyber Defense Cycle (ACDC)

    One of the biggest challenges of implantation of the ACDC model is ensuring that there is a solid accounting of both deployed architecture and passive measures that are stood up to protect the infrastructure. These passive mechanisms include both HIDS/HIPS and NIDS/NIPS, as well as anti-virus solutions, firewalls, and other traditional defense mechanisms designed to protect both hosts and networks. To maximize effectiveness and help an organization determine when the right time to begin the implementation of the ACDC model, the network topology should be mapped, a patch management policy needs to be put into place, and an overall understanding the data flow on the network ought to be fully detailed. Only when an organization has an updated and complete understanding of the entire environment can threat intelligence or the ACDC model be fully deployed with maximum efficiency.

    Another principle that should be fully understood for better implementation of threat intelligence is the Cyber Kill Chain. This term was coined by Lockheed Martin. The Cyber Kill Chain provides a framework to better understand the steps an adversary takes to accomplish their objective of exploitation and/or exfiltration. While Giora Engel of Dark Reading argues that this framework is “detrimental to network security because it reinforces old-school, perimeter-focused, malware-prevention thinking,” it is important to understand the process an attacker takes to better protect against their successful intrusion (Engel, 2014).

Figure 2 – The Cyber Kill Chain

    Per the SANS Institute, “there are various ways to attack an ICS environment, the most common methods to achieve functional impact fall into three categories: loss, denial and manipulation. They include a loss of view, denial of view, manipulation of view, denial of control, loss of control, manipulation of control, activation of safety, denial of safety, manipulation of safety and manipulation of sensors and instruments” (Assante and Lee, 2015). What makes the fundamental of the Cyber Kill Chain so relevant in terms of ICS environments is that it “highlights the fact that a significant ICS incident requires a thorough understanding of the target’s process environment” (Singer, Wilhoit, Hilt, Bodungen, & Shbeeb, 2015). By understanding how an adversary thinks, learning their tactics, techniques, and procedures for intrusion, and conducting vulnerability assessments, ICS can begin to implement meaningful threat intelligence into an active defense strategy.

    Everything discussed up until this point explored internal controls necessary to ensuring the successful implantation of threat intelligence. This included identification of assets within the environment, conducting vulnerability assessments, inventorying and the establishment of an active cyber defense posture that works in conjunction with the traditional passive defense mechanisms. However, external factors such as the collection and sharing of information is principal when it comes to utilizing quality threat intelligence.

    Sharing threat intelligence across a plethora of industries is a great way of getting out in front of new attack and threat vectors. In October of 2015, the United States successfully passed the Cybersecurity Information Sharing Act (CISA) as a means of promoting enhanced sharing of cyber threats.  CISA allows for organizations to actively implement mechanisms for monitoring, defense, and countering cyber threats. Additionally, the statute offers organizations assurances and a level of protection to promote the voluntary sharing of threat indicators as well as suggested defense mechanisms to further protect against cyber threats and vulnerabilities. While there is obviously a strong level of encouragement for sharing threat intelligence from a federal level, as Chris Young from Intel Security states, “there hasn’t been much that’s happened since that bill became law to start to operationalize threat intel sharing in a real way” (Weafer, 2016). Even though a 2015 Intel Security survey found that 97% of those surveyed found valued in sharing cyber threat intelligence, the survey showed that while 91% of organizations wanted to receive the shared cyber threat intelligence, only 63% were actually willing to share it themselves (Weafer, 2016).

Figure 3 – Intel Security Survey Results of the Value of Cyber Threat Intelligence

Figure 4 – Intel Security Survey of Those Wanting versus Those Willing to Share Cyber Threat Intelligence

A McAfee report entitled “McAfee Labs Threats Report Discusses Cyber Threat Intelligence Sharing and More” found that there are several reasons that organizations shy away from sharing cyber threat intelligence. They are:

• Company policy: Companies often have blanket policies that don’t take into account what is being shared, such as hashes vs. personally identifiable information.
  
  
• Catching bad guys: Sharing could interfere with ongoing investigations. Some allow exploits to succeed while monitoring them—in order to gain more information about who is behind the attack. If the threat data is shared with a CTI community and the attackers participate in that community, they could be alerted that their activities have been identified.
  
  
• Concerns over legality: Legal and trust frameworks for sharing cyber threat information are not well established, making it easy for risk-averse corporate lawyers to say no or to set up highly restrictive policies to limit sharing.
  
  
• Concerns over privacy: Global laws and norms make sharing an extremely complicated landscape. Regulations regarding the sharing of personal information are not always fully understood. To avoid fines and penalties, many err on the side of caution.
  
  
• Lack of exchange standards: Until recently, established and widely accepted technical standards have not existed except in focused areas such as incidence response.

    With regards to company policy, many organizations are ultra-cautious when it comes to sharing any information that might contain any customer or employee personal identifiable information. The Ponemon 2016 Cost of Data Breach Study found that the “average consolidated total cost of a data breach grew from $3.8 million to $4 million” (Ponemon 2016 Cost of Data Breach Study, 2016). The legality issue is also a great concern for many organizations. Even though the CISA offers some protections under the law to encourage sharing of cyber threats, many organizations would rather not share information than to risk any liability. However, Structured Threat Information eXpression (STIX™) framework helps to address the concern relating to a lack of exchange standards.

    STIX™ offers organizations a means to cooperative sharing of threat intelligence by utilizing industry, government, and academic feedback and the voluntary sharing of threat intelligence data. According to Sean Barnum in his whitepaper titled Standardizing Cyber Threat Intelligence Information with the Structured Threat Information eXpression, “[STIX™] aims to extend indicator sharing to enable the management and widespread exchange of significantly more expressive sets of indicators as well as other full spectrum cyber threat information” (Barnum, 2014).

    Mainly, the STIX™ architecture offers the ability to share intelligence related to potential indicators of compromise, current targeted cyber-attack campaigns, the tactics, techniques, and procedures used to facilitate the targeted campaigns – this includes the APT’s kill chains, new (and old) malware, specific attack patterns, exploit kits and known vulnerabilities, etc. Given the flexibility of STIX™, it implements well with other security languages and policies such as YARA and Snort, for example.

    The Structured Threat Information eXpression architecture is comprised of eight main components. The first component, Observable's, utilizes CybOX–the “language for encoding and communicating standardized high fidelity information about cyber observable's, whether dynamic events or stateful measures properties that are observable in the operational cyber domain” (Barnum, 2014). Observable's provide a baseline that observe stateful properties like the initiation of services, HTTP requests, file properties, network data, etc. With the help of CybOX, the observables component aids in adding a higher level of operational context to what may be considered a viable target. This contextual data is helpful in identifying behavior patterns that may show in the Indictor phase of the STIX™ framework.

Figure 5 – The Structured Threat Information eXpression Architectural Structure

    Indicators utilize patterns found in observable's; in tandem with metadata with the goal of attempting to map potential identified tactics, techniques, and procedures. The metadata for this context includes information related to handling exceptions, related threat campaigns, possible sources of indications, suggested courses of action, etc. As Barnes points out, this component is dependent on utilizing community cooperation and knowledge of best practices to further enhance indicator information.

    The Incident component primarily focuses on data associated with any occurrence of compromise and information that may become uncovered during incident response activities. This component utilizes data from related indicators and observable's, as well as exploring the nature of the compromise, identifying all the assets affected, the requested course of action, as well as the actions taken, attribution, etc. Like the previous components, the incident phase relies heavily on community involvement aiming to outline potential new structures for representing any information obtained during the Incident phase of the STIX™ structure.

    The next component explores the tactics, techniques, and procedures (TTPs) employed by an adversary to accomplish their objective. The objectives themselves are more closely associated with the next two phases, however, the TTPs are the means employed to achieve them. The tactics employed are the methods used to compromise. They include the utilization of malware, capitalizing on specific exploits, taking advantage of a backdoor or rootkit, etc. The techniques are the methods to promulgate the tactic. Examples of techniques could include social engineering, spear phishing, watering hole attacks, and more. The procedures are the steps taken and the processes employed during the entire attack cycle. This component has the most dependencies on other component in the STIX™ architecture. Per Barnes, “They are relevant for Indicators, Incidents, Campaigns, and Threat Actors. In addition, they hold a close relationship with Exploit Targets that characterize the specific targets that the TTPs seek to exploit” (Barnes, 2014).

    The next two components – Campaigns and Threat Actors – are connected in that the threat actors are the mechanisms used to deploy a campaign. A campaign is simply a targeted objective. The threat actors are those groups or individuals who act to accomplish the campaign objectives(s). These can come in the form of advanced persistent threats (APTs), hacktivism groups, malicious nation states, disgruntled employees, etc. There must be a presumed intent to be classified as a campaign and a threat actor. Threat actors act with malice. In other words, there is a suspected intent and motivation with threat actors. Like the other components, the reliance on community involvement is paramount to help identify specific campaigns to better understand their motivations, TTPs, and opportunities. This cooperation ultimately helps take a more active defense security posture and mitigate the associated risks much faster.

    Given that TTPs seek to exploit vulnerabilities, the Exploit component essentially deals with the characterization and classifications of known vulnerabilities. This includes utilizing the Common Vulnerability and Exposures (CVE) database as well as the Open Source Vulnerability Database (OSVDB) and Common Vulnerability Reporting Framework (CVRF) format which “may be utilized for detailed structured characterization of vulnerabilities not identified in CVE or OSVDB including the potential for characterizing zero day vulnerabilities” (Barnes, 2014).

    To combat and mitigate the risk of threat actors exploiting vulnerabilities, recommended courses of actions are explored to reduce the likelihood and potential impact of incidents. There are many factors in finding the right course of action. These include determining the “observable parameters” of implementation, the impact implementation may have on any given environment, as well as the total cost of ownership with implementation. The goals and objectives of the course of action need to be clearly defined and should also take best practices into account when determining the best course of action to be undertaken. These tasks fall into the last component of the STIX™ framework; Course of Action.

    When determining whether threat intelligence is right for a specific organization, thorough research should be conducted. This includes but is not limited to conducting risk assessments, preparing a business cost analysis (BCA), inventory and mapping of the environment (including hardware, software, and network architectures), identifying potential vulnerabilities, conducting internal audits, utilizing penetration testing, deploying a security operations center (SOC), etc. Threat intelligence can be a great tool to help enhance an organizations security posture, but far too often, owners, managers, and other stakeholders are seeking a silver bullet solution. They ultimately seek to rely solely on the technology to fill in the gaps. However, threat intelligence is just a single spoke on the wheel of a comprehensive security posture and should be treated as such. It needs to be used to enhance the defense in depth strategy, not replace it.

Sources

Assante, M. J., & Lee, R. (2015, October). The Industrial Control System Cyber Kill Chain. Retrieved April 25, 2017.

Barnes, S. (2014, February 20). Standardizing Cyber Threat Intelligence Information with the Structured Threat Information eXpression (STIX™). Retrieved May 2, 2017.

Bodungen, C. E., Singer, B. L., Shbeeb, A., Hilt, S., & Wilhoit, K. (2017). Hacking exposed industrial control systems: ICS and SCADA security secrets & solutions. New York: McGraw-Hill Education.

Engel, G. (2014, November 18). Deconstructing the Cyber Kill Chain. Retrieved April 23, 2017.

Lee, R. (2015, July 9). Data, Information, and Intelligence: Your Threat Feed is Not Threat Intelligence. Retrieved April 26, 2017.

Lee, R. (2016, April 25). Threat Intelligence in an Active Cyber Defense (Part 1). Retrieved  April 23, 2017.

Ponemon, L. (2016, June 15). 2016 Ponemon Institute Cost of a Data Breach Study. Retrieved  May 01, 2017.

Weafer, V. (2016, October 25). McAfee Labs Threats Report Discusses Cyber Threat  Intelligence Sharing and More. Retrieved May 01, 2017.