Identifying Knowledge Elements
Abstract
Being able to manage indicators of attack (IOA), indicators of compromise (IOC), and indicators of interest (IOI) is of paramount importance in today’s world. Whether you are working to defend an enterprise from attack, mitigating the risk associated with an intrusion, or just trying to work toward a better way of sharing indicator and indicator object data, the ability to share in some fashion should be taken seriously. In this chapter you will learn about the importance in being able to distinguish between intelligence and information, while being introduced to the concept of increasing the signal-to-noise ratio. You will be guided through the most common frameworks and standards in the industry today for indicator and indicator object sharing and will be introduced to concepts that speak contextually to the threats represented by said indicators. Ultimately, you will be introduced to concepts that play a greater role in Chapter 5 and beyond, all of which influence the process of forecasting and predicting threat.
Keywords
Indicators of Attack; Indicators of Compromise; Indicators of Interest; Intrusion; Indicator object data
Synopsis
Being able to manage indicators of attack (IOA), indicators of compromise (IOC), and indicators of interest (IOI) is of paramount importance in today’s world. Whether you are working to defend an enterprise from attack, mitigate the risk associated with an intrusion, or just trying to work toward a better way of sharing indicator and indicator object data, the ability to share in some fashion should be taken seriously. In this chapter you will learn about the importance in being able to distinguish between intelligence and information, while being introduced to the concept of increasing the signal-to-noise ratio. You will be guided through the most common frameworks and standards in the industry today for indicator and indicator object sharing and will be introduced to concepts that speak contextually to the threats represented by said indicators. Ultimately you will be introduced to concepts that play a greater role in Chapter 5 and beyond, all of which influence the process of forecasting and predicting threat.
Introduction
The world is a much more complex place than it was a decade ago. The impact and extent of sharing what we commonly call IOC today, was small scale and minimal; most relegated to trust communities set up among information security vendors, industry trust communities, or information sharing analysis centers (ISAC) and computer emergency response teams (CERT). Over time as more and more information became available about the threat landscape, more and more sharing took place. Whether we were sharing information about malicious IP addresses, domains, MD5s or malware samples, the sharing grew but the pieces of information derived and distilled from that sharing—the indicators—were not necessarily shared universally or if they were, they were not easily consumed by the disparate technological platforms ranging from end point agents, to network based security devices, to Security Information Event Management (SIEM). As a result, many people and organizations began recognizing the need to devise ways in which to extract salient information from threat research endeavors, consume them and package them for reuse and consumption by themselves and, eventually, other organizations. Concepts such as IOA were introduced to add more contextual relevance to IOCs and IOI making them more valuable than if they were just stand alone indicators. These indicators worked from the premise that the signal-to-noise ratio had already been met and that participating organizations were taking full advantage of the schemas, standards, and frameworks that were being brought to market and made freely available to those in need. In this chapter we will explore these concepts collective while differentiating their key points. We will demonstrate the merits of each schema, framework, or standard identified, while identifying potentials for failure, which warrant amendment. Individuals and organizations alike will be able to gain key insights into these offerings, which will enable them to make intelligence decisions regarding their employment and use within their environments.
Defining Knowledge Elements
Intelligence Versus Information
As we begin our discussion on knowledge elements within this chapter we thought it would be important to take a moment to explain the difference between intelligence and information. Many people use these terms interchangeably yet they are unique and carry their own distinct meaning. Intelligence, as defined by Merriam-Webster is:
• the ability to learn or understand things or to deal with new or difficult situations
• secret information that a government collects about an enemy or possible enemy; also: a government organization that collects such information
Information as defined by Merriam-Webster is:
• knowledge that you get about someone or something: facts or details about a subject
• a service that telephone users can call to find out the telephone number for a specified person or organization
Acknowledged by individuals and organizations alike for their differences they often remain used synonymously. For many the only difference lies in the second proposed definition of the word information, which describes a service, provided by telecommunications services the world over for their clientele. Though their differences are pronounced, understanding the unique relationship that exists between them is paramount to any individual or organization seeking to develop and establish a service that focuses on threat forecasting and predictive analysis. Contrary to popular belief, within certain communities and elements within the information security industry these terms, when use appropriately with authority, are not banal but rather fresh and inspired as they bring together key concepts germane to people, objects, locations, systems, and networks that can and often are used to achieve a wide variety of ends by many different types of actors and defenders.
Therefore, understanding the definitions of the words intelligence and information cannot be stressed enough. Understanding and being able to apply knowledge related to diverse subjects and situations where the focal points may vary from diverse threat actors (ideologically driven, criminal, nation state proxy, or state sponsored) and their tactics, techniques, and procedures (TTPs) to real-world targets (e.g., individuals, businesses/organizations, entire industry verticals, or government/military) from a Target of Interest (ToI)—a target which an attack is planned against after much preparation, and Target of Opportunity (ToO)—a target on which attack is unplanned and which is attacked upon favorable presentation or unexpected discovery or appearance.
A Quick Note About the Signal-to-Noise Ratio Metaphor
Like intelligence and information, two other terms come into play when beginning discussions related to cyber threat intelligence, threat forecasting and predictive analysis. The two terms in question are signal and noise. We often refer to them in terms of “ratios” or the number of times one value contains or is contained within the other value, when in fact what we're really referring to (unless we’re engineers) is the metaphor associated with them. As we’ve noted with respect to the terms intelligence and information, there is a great degree of disparate thought surrounding signal and noise within the industry. However, we would be remiss were we to write not only a chapter but an entire book without introducing, explaining, referencing, and reinforcing these concepts based on our real-world and academic understanding of their use and application.
So what is the signal-to-noise ratio? The signal-to-noise (commonly abbreviated SNR or S/N in scientific circles) is a form of measurement used in certain applied sciences (electrical engineering for example), which compares the level of desired signal or the level of a function that conveys information about the behavior or attributes of some phenomenon.1 The use of signal in this context often evokes images of data or telecommunications environments, signal processing or electrical engineering. Signal is compared against background noise or unwanted sound; sound that interferes with the overall signal quality making receipt, interpretation, and response to a message or piece of intelligence or information extremely difficult. Over the course of many years this metaphor for signal-to-noise ratio has come to be used quite broadly, especially in those cases where we may be discussing messages (intelligence or information) that need to be received, interpreted, and responded to in as crisp a manner as possible. With regard to this book and specifically this chapter, our goal is to ensure that the signal-to-noise ratio is quite low, so that we may maintain a precise focus on our goal of sending and receiving messages (intelligence and information concepts) germane to the topic of threat forecasting and predictive analysis. Because of the net effect that that the signal-to-noise ratio may have on our work, whether we are electrical engineers triaging a routing or switching platform, or information security oriented individuals focused on cyber threat intelligence as it relates to threat forecasting and predictive analysis, we must strive to achieve the highest levels of fidelity and purity in signal possible.
A Brief Note on IOCs and IOIs
As we make our way through this chapter, two concepts shall be introduced which will be critical to the reader as he or she endeavors to comprehend cyber threat intelligence, threat forecasting and predictive analysis. These two concepts or, perhaps put more appropriately, these two acronyms account for many sub-categories of knowledge and understanding that we will explore. It should also be noted that though in most instances these concepts, specifically the IOC and the IOI, are solely relegated to the world of machine-oriented interpretation systems. However, there are many instances and cases where some of these sub-categories will be extremely important on a non-machine-oriented level and thus will have an impact or some material bearing on work being conducted by cyber threat intelligence analysts the world over.
Identifying Something Important Through the Use of IOAs, IOCs, and IOIs
IOAs, IOCs, and IOIs aid us in understanding important things that are occurring within our hosts and networks. Some of these things may be benign yet meaningful from an administrative perspective while others may be indicative of a state of compromise within the environment affecting one or more hosts and the infrastructure itself. In the broad case of threat forecasting and predictive analysis, having a healthy understanding of IOAs and their relations to IOCs and IOIs is of paramount importance.
Through understanding what is critical to a threat actor or adversary (that which is contextually relevant to an exploit and compromise), we can gain key insights into what may occur or may be associated with the modus operandi—particular way through which a threat actor or adversary conducts him- or herself within enterprise environments. As we will see in the following sections, having a solid understanding of IOAs, IOCs, and IOIs will aid us in understanding several factors of the events taking place within our enterprise environments and regarding those who may be responsible for them. This information is critical if your organization believes or has reason to believe that it is a ToI. In the section named Types of Knowledge Elements, we will explore IOAs, IOCs, and IOIs in more detail.
Types of Knowledge Elements
Within the information security and threat intelligence disciplines there are many types of knowledge elements. Some are oriented toward machines and the consumption of knowledge elements by machines, such as firewalls (FW), intrusion detection systems (IDS), intrusion prevention systems (IPS), and endpoint threat detection and response (ETDR) platforms, while other knowledge elements are oriented towards the combination of machines and human analysts. In the following sections we will discuss in detail the two primary categories of knowledge elements associated with information security, threat intelligence, and threat forecasting and predictive analysis.
IOA or Pre-attack Indicators
Defined by CrowdStrike and Intel/McAfee in 2014, the term IOA carries with it a different meaning from its peer terms IOC and IOI. The term IOA is similar in nature to a term commonly used in law enforcement scenarios, the Pre-Attack Indicator.2 According to Intel/McAfee an IOA is the unique construction of unknown attributes, IOCs, and contextually relevant information (including organizational intelligence and risk) into a dynamic, situational picture that guides response.3 CrowdStrike defines an IOA differently. According to a blog post written by CrowdStrike on this topic in December of 2014, an IOA can be defined as a series of actions that an adversary must conduct in order to succeed.4 CrowdStrike uses the example of a spear phishing attack to illustrate their point regarding IOAs. They go on to build out a scenario that looks something like the following:
• Campaign relies on convincing or persuading the target to click on a link or open a document that will infect a machine
• Once successfully compromised, the adversary will execute another process, hide in memory or on disk in order to establish and maintain persistence
• Command and control communications will be established with a C2 sit where in the adversary informs his handlers that he awaits further instructions
According to both Intel/McAfee and CrowdStrike the IOAs will be concerned with and focus upon execution of these steps (in this scenario the steps associated with the spear phishing attack), the intent of the adversary (reasoning/rationale/goal behind the attack and its success) and the outcomes of the efforts put in place. So in the case of the IOA we’re concerned with a broader, overarching condition and state that may include, among other things, IOCs, but completion of the mission is not necessarily solely dependent upon these alone. Understanding IOAs is of paramount importance and critical to understanding the mindset and rationale of an adversary. Certainly CrowdStrike and Intel/McAfee do, as do the authors. And so it is in the best interests of the analyst and the organization impacted to understand IOAs as deeply as possible.
Indicators of Compromise
Unlike IOAs, IOCs are forensic artifacts or remnants of an intrusion that can be identified on a host or network.5 They are not behaviorally driven (in other words they do not necessarily reflect the behavior or intent of a threat actor or adversary) nor are they tied to extensions of TTPs. They are however, rooted in artifacts that can be extracted from hosts within the network or the elements which comprise the network itself leading to the entry point of a threat actor and his or her exfiltration point(s). Common examples of IOCs include:
• IPv4
• IPv6
• URL and FQDN+Path
• MD5 hash
• SHA-1 hash
• File Name
• File Type
• Windows Registry Key
• Windows Driver
In many cases identifying IOCs, once an analyst is trained in what to look for, is quite simple and leads to examples such as those provided in Table 4.1.
Table 4.1
Examples and Descriptions of IOCs
| Indicator of Compromise (IOC) | Description of the IOC |
| IPv4 | 105.103.125.129 |
| IPv6 | 2002:0:0:0:0:0:105.103.125.129 |
| URL (FQDN+Path) | islam20134.no-ip.biz |
| MD5 | a07c79ed7a30c5408d6fb73b4c177266 |
| SHA-1 | 992cbd54688030d9afd631946f4698de078638bf |
| File name | Server.exe |
| File type | PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows |
In many instances people have mistakenly associate IOCs with behaviors observed in hosts or within network enterprise environments (conflating the term IOC with IOA). For example, in 2013 the online information security magazine Dark Reading posted an article titled “Top 15 Indicators of Compromise.”6 The article provides examples of what they purport to be “Indicators of Compromise.”
However, the list provided by Dark Reading is actually better aligned with the definition we saw above for IOAs or TTPs. In their list they include observable behaviors such as:
• Unusual outbound network traffic
• Anomalies in privileged user activity
• Geographical irregularities
• Other log-in red flags
• Swells in database read volume
• HTML response sizes
• Large number of requests for the same file
• Mismatched port-application traffic
• Suspicious registry or system file changes
• DNS request anomalies
• Unexpected patching of systems
• Mobile device profile changes
• Bundles of data in the wrong places
• Web traffic with unhuman behavior
• Signs of DDoS activity
If we are to assume that our definition of IOCs is true and accurate and that IOCs apply to machine-oriented platforms such as firewalls, IDSs, IPSs, ETDR platforms, and advanced threat detection (ATD) products among other platforms, as well as to information security and cyber threat intelligence analysts respectively, then we must dismiss lists such as these in relation to IOCs and relegate them to behaviors associated with IOAs and TTP. This is important due to the fact that there remains some degree of debate as to what an IOC is (exactly) within the information security industry, how they are used, and to what degree. Not to mention the fact that, at least in the eyes of certain organizations and industry subject matter experts, IOCs are merely attributes of IOAs. In the next section we will explore a concept that is not as well known as that of the IOC, yet still provides a tremendous amount of value to those seeking to understand more about their host and network environments while attempting to forecast and predict threat activity.
Indicators of Interest
Like IOCs, IOIs may include forensic elements and artifacts associated with the remnants of an intrusion or compromise of a host or networks, however, they typically address information that acts in a supporting role to the identification and definition of an IOC. In many instances, IOIs themselves will contain or provide insight into IOCs lending themselves closer (by definition) to IOAs than IOCs. Examples of IOIs may include:
• ‘WHOIS' information
• DNS Queries
• Autonomous system network number
• User accounts
• Country of operation
• Packet capture
In the following example we will provide information related to an IPv4 address that will demonstrate information that can be used in defining contextually relevant information within or pertaining to an IOI, in this case an IP address associated with known malicious domains (Table 4.2).7
Table 4.2
Examples of Indicators of Interest (IOIs)
| Indicator of Interest | Data | Detail |
| IP Address | ||
| Type-IPv4 Address | 105.103.125.129 | |
| WHOIS | % This is the AfriNIC Whois server. % Note: this output has been filtered. % To receive output for a database update, use the “-B” flag. % Information related to “105.96.0.0 - 105.111.255.255” % No abuse contact registered for 105.96.0.0 - 105.111.255.255 inetnum: 105.96.0.0 - 105.111.255.255 netname: TA23-new descr: Telecom Algeria country: DZ org: ORG-TA23-AFRINIC admin-c: DN2-AFRINIC tech-c: SD6-AFRINIC status: ALLOCATED PA mnt-by: AFRINIC-HM-MNT mnt-lower: DJAWEB-MNT mnt-domains: DJAWEB-MNT source: AFRINIC Filtered parent: 105.0.0.0 - 105.255.255.255 organisation: ORG-TA23-AFRINIC org-name: Telecom Algeria org-type: LIR country: DZ address: Complexe Informatique des PTT address: RN 36 Ben Aknoun address: ALGER phone: + 213 92 12 24 fax-no: + 213 92 12 08 admin-c: SD6-AFRINIC tech-c: SD6-AFRINIC mnt-ref: AFRINIC-HM-MNT mnt-ref: DJAWEB-MNT mnt-by: AFRINIC-HM-MNT source: AFRINIC Filtered person: DJOUAHRA Naima address: ALGERIE TELECOM INTERNET DJAWEB address: Complexe Informatique des PTT address: Route Nationale N 36 Ben Aknoun address: ALGER—ALGERIA phone: + 213 21 92 20 04 fax-no: + 213 21 92 20 04 nic-hdl: DN2-AFRINIC mnt-by: AT-MNT source: AFRINIC Filtered person: Security Departement address: Alger phone: + 21321911224 fax-no: + 21321911208 nic-hdl: SD6-AFRINIC source: AFRINIC Filtered | |
| DOMAIN | islam20134.no-ip.biz | |
| User accounts | N/a | |
| Country of operations | Algeria | |
| Name/Identity/Contact Information |
DJOUAHRA Naima ALGERIE TELECOM INTERNET DJAWEB address: Complexe Informatique des PTT address: Route Nationale N 36 Ben Aknoun address: ALGER—ALGERIA phone: + 213 21 92 20 04 fax-no: + 213 21 92 20 04 person: Security Departement address: Alger phone: + 21321911224 fax-no: + 21321911208 nic-hdl: SD6-AFRINIC source: AFRINIC Filtered | |
Publicly Defined Knowledge Elements
As we have seen previously in this chapter, knowledge elements take on many forms. In this section we will be describing several of the most popular publicly defined knowledge elements for review and consideration. Before we begin, let’s take a moment to review our definition of an IOC. An IOC is a forensic artifact or remnant of an intrusion that can be identified on a host or network. Each of the following publicly defined knowledge elements deals with IOCs in one way or another. NOTE: as at the time of writing there is no universally adopted or ratified standard for IOC sharing. Though there are several options to choose from, there remains a fairly heated debate as to which standard affords the users with the greatest degree of flexibility and usefulness. It is not uncommon to find adherents to one standard or another rather adamant about their choice of element. This is to be expected, as most adherents are end users and consumers of the standards. They will have a vested interest in seeing whichever standard they have chosen successfully adopted, utilized, and supported, not only within their own environments, but also within the industry itself. In this section we will explore four standards options for IOC sharing: OpenIOC, Cyber Observable eXpression (CybOX), Incident Object Description Exchange Format (IODEF) (RFC5070), and IOCBucket.com.
OpenIOC
OpenIOC is a standard that was first pioneered and championed by the team at Mandiant (now FireEye). Since its inception it has become the defacto standard for machine-oriented data point sharing (specifically for data points related to, or determined by, IOC). Mandiant developed the standard because they had recognized both the need for a solution and realties that dictated it:
• Sophisticated Indicators: Traditional methods of identifying security breaches no longer worked. Mandiant found that intruders too easily circumvented simple signatures; they recognized the need for a better way. They decided that the best solution for all organizations would be to be able to communicate whether or not there were attackers on their networks and hosts in an efficient, reliable, and fast manner. The solution it seemed lied in the ability of a provider (in this case Mandiant) to deliver such data in a machine-oriented (digestible) format that would see the greatest source of delay—the human delay—removed from the equation and from threat intelligence sharing.
• Advanced Threat Detection: Mandiant was able to prove that by using the OpenIOC framework an organization could achieve a state where the most advanced threat-detection capabilities were not only possible, but also available. So confidant were they that they built a community dedicated to the OpenIOC standard (also known as an initiative) through which an organization could benefit significantly from the net effect of threat intelligence organizations within a given industry vertical in addition to those across the Fortune 1000.
• Extendable and Customizable: Recognizing early on that any solution that they devised would need to be adaptable and flexible, Mandiant decided only through offering extensions and customization would the standard be accepted broadly beyond their own use cases. As a result, OpenIOC offers organizations the ability to use Mandiant’s field tested and proven IOCs while also affording them the ability to create their own custom sets of IOCs.
• Codification: The need to be able to codify or arrange in systematic order information brought into an organization for consumption in the form of an IOC was crucial to the success or failure of this standard. Mandiant defined the standard in such a way so that any and all data is easily codified and ready for use.
• Satisfaction: Through the development of this standard, Mandiant achieved a sense of satisfaction. They had seen something grow out of their own use cases, be adopted across their user community and then be recognized for its pioneering spirit by the information security industry.
Once developed, deployed, tested, and refined, this standard became one of the most important in the area of threat intelligence and information sharing. The need for this type of codification remains important to anyone tasked with managing or maintaining enterprise grade information security technologies (e.g., firewalls, IDSs, IPSs, e-mail and web gateways, malware analysis platforms or endpoint detection and response platforms, etc.), in addition to those tasked with performing forensic investigations, incident response, or threat intelligence research.
The OpenIOC standard has proven to be quite successful and widely adopted. So successful, that during the course of their incident response engagements and product roll outs Mandiant was often asked by their clients and customers whether or not they had given thought to sharing these data beyond the Mandiant platform. After some consideration a decision was made by the team at Mandiant to create the OpenIOC initiative with its community element. In doing so, Mandiant would be able to accommodate the requests of the information security community by opening the standard up beyond their tool and utilities. Mandiant brought several new tools and utilities to the market to support the adoption of this new standard while striving to communicate threat information at machine speed. The ability to deliver threat intelligence in a machine-oriented (readable) fashion at machine speed proved to be extremely well received by the information security community. Due to the ever-evolving state of the Internet threat landscape, the ability to provide robust and meaningful intelligence rapidly in a manner that is actionable is critical. Doing so aids in ensuring the swift detection, response, and approach to targeted attacks.
How It Works
The OpenIOC schema is based on an XML framework. This framework enables the user to document and categorize forensics artifacts of intrusions in an easy, lightweight manner. Furthermore, it enables those who use it to describe the technical characteristics that identify a known threat, an attacker's methodology, or other evidence of compromise.
How Do You Get It
Getting OpenIOC is easy, as there are free tools available at the official FireEye website. Tools such as the IOC Editor (which is used to create IOCs), or the Redline tool used in host-based investigations are available online for immediate use by all who seek them. The raw XML is also available at this site. Your organization can keep abreast of the latest innovations associated with OpenIOC by visiting the Mandiant's public Github site or via the OpenIOC Google Group (Fig. 4.1).
Incident Object Description Exchange Format (RFC5070)
As we have seen in the previous sections, data sharing is vital to properly identifying, triaging, and mitigating threats as we encounter them within our environments. Standards such as OpenIOC, as we have seen, enable organizations to share information specific to IOC. Beyond the adoption and use of indicator information within our enterprises, organizations may find that they require additional help from third parties to mitigate threats targeting their enterprises while seeking to gain a deeper insight and understanding into potential threats. In order to ensure that this sort of coordination can occur between disparate parties, a new standard was introduced by the IETF that promises to help represent and share data. That standard is the IODEF. It was defined by the IETF in RFC5070 as “…a format for representing computer security information commonly exchanged between Computer Security Incident Response Teams (CSIRTs).” The format provides an XML representation devised to enable the communication of incident information across and between administrative domains between parties that have an operational obligation and responsibility for remediation. According to the RFC, the data model encodes information about the following:
• Networks
• Services
• Attack methodology
• Forensic evidence
• Impact of the activity
• Workflow (limited)
Though the original purpose of the IODEF standard was to improve the operational capabilities of CSIRTs it is being championed beyond these organizations to organizations not tasked with the same responsibilities, namely enterprise businesses. Like all data sharing standards, adoption and ratification is taking some time; however, IODEF’s community-oriented value proposition provides an improved ability to resolve incidents in a timely fashion while communicating situational awareness through collaboration and data sharing.
IODEF Data Model
The IETF has defined the IODEF data model as being a data representation, which provides a framework for sharing information commonly exchanged by CSIRTs about computer security incidents. When defining the data model, the IETF considered the following points8:
• The data model serves as a transport format and is not an optimal representation for on-disk storage, long-term archiving, or in-memory processing
• There is no precise or universally agreed upon definition of an “incident.” As a result, the model does not try to dictate one through its implementation. IODEF is considered with being flexible enough to accommodate most operators
• IODEF strives to be a framework to communicate commonly exchanged incident information
• Because the domain of security analysis is not fully standardized and must rely on free-form textual descriptions, IODEF attempts to create a balance between supporting the free-form content and, at the same time, supporting and allowing automated processing of incident information
• IODEF is only one of several security-relevant data representations that are being converted into industry-accepted standards
This balanced approach to both data representation and sharing will likely encourage continued development and adoption of the IODEF standard.
IODEF Implementation
As mentioned earlier in this section, the IODEF implementation has been defined as an XML schema. This XML schema provides numerous advantages to the organizations seeking to adopt and deploy the standard. The extensibility of the schema makes it “…ideal for specifying a data encoding framework that supports various character encodings…”9 There are many well-defined active use cases of sharing with IODEF. Many of those use cases can be found online at websites such as http://siis.realmv6.org/implementations. Use cases, tools, and open-source implementation codes can be found at this site and others like it which enable the deployment of the infrastructure necessary for the adoption of IODEF RID servers.10
IOCBucket.com
Another alternative to OpenIOC and IODEF for sharing IOCs is the IOCBucket. It was created by three security professionals who were active in the penetration testing industry. IOCBucket.com, the site that hosts the IOCBucket exchange, provides a significant amount of information regarding their origins, their purpose, and their intent with respect to facilitating intelligent indicator sharing. It's a global community of computer and information security professionals who have what they believe to be a vested interest in sharing IOCs during their research. The owners believe that their website acts as a trans-oceanic gap between multinational corporations providing them with a wealth of incident response knowledge and experience.11 The community thrives upon the contributions of industry OpenIOCs and aspires to be the largest repository of open source indicators in the world. The website affords users with the opportunity to check and search for IOCs found on ones network against a reputation database in order to determine the potential and possibility of infection using one of the 500 fields that are supported by the OpenIOC standard. OpenIOCs are made available for download in order for the end user to continue his or her search for infections and intrusions within his or her network. The site is not owned, operated, or sponsored by any government personnel or agencies (Fig. 4.2).
Cyber Observable eXpression
CybOX is another system designed for sharing IOCs or observables for all cyber security use cases. According to its founders, it is a flexible system that supports domain-specific standards and solutions through a unified and consistent foundational definition of cyber observables.12 In most instances utilization of CybOx should be indirect with a primary focus being on the use case domain-specific standard or solution that leverages CybOx as an enabler according to the authors. The standard adheres to the following principles for scoping of information (IOC and observable) content:
• Information content related to cyber observables is only included in CybOx if it is of general user to multiple cases and not found to be in conflict within any specific use cases
• Data regarding cyber observables that are specific to a single supported use case domain may be managed in a use case domain-specific standard or solution that leverages CybOx for all general cyber observable informational content.
Supported use cases would include things like (Table 4.3).13
Table 4.3
Cybox Use Cases
| Supported Use Case | Relevant Process | Domain Specific Standard |
| Analyze event data from diverse set of sensors of different types and different vendors | Event Management | CybOX |
| Detect malicious activity utilizing attack patterns | Attack Detection | Common Attack Pattern Enumeration and Classification (CAPEC™) |
| Detect malicious activity utilizing malware behavior characterizations | Attack Detection | Malware Attribute Enumeration and Characterization (MAEC™) |
| Enable automated attack detection signature rule generation | Attack Detection | CybOX, MAEC, CAPEC, Structured Threat Information eXpression (STIX™) |
| Characterize malicious activity utilizing attack patterns | Incident Response/Management | CAPEC, STIX |
| Identify new attack patterns | Threat Characterization | CAPEC |
| Prioritize existing attack patterns based on tactical reality | Security Testing and Secure Development | CAPEC, STIX |
| Characterize malware behavior | Malware Analysis | MAEC |
| Guide malware analysis utilizing attack patterns | Malware Analysis | MAEC, CAPEC |
| Detect malware effects | Attack Detection and Incident Response/Management | Open Vulnerability and Assessment Language (OVAL®), MAEC, STIX |
| Enable collaborative attack indicator sharing | Information Sharing | |
| Empower and guide incident management utilizing attack patterns and malware characterizations | Incident Response/Management | STIX, CAPEC, MAEC, CybOX |
| Enable consistent, useful and automation-capable incident alerts | Incident Response/Management | STIX, MAEC, CAPEC |
| Enable automatic application of mitigations specified in attack patterns | Incident Response/Management | STIX |
| Enable incident information sharing | Incident Response/Management | STIX |
| Support correlation between observed properties and malicious indicators as part of digital forensics | Digital Forensics | Digital Forensics XML (DFXML), STIX, MAEC, CAPEC |
| Capture digital forensics analysis results | Digital Forensics | DFXML |
| Capture digital forensics provenance information | Digital Forensics | DFXML |
| Enable collaborative sharing of digital forensics information | Digital Forensics | DFXML |
| Enable explicit and implicit sharing controls for cyber observable information | Information Sharing | STIX, CybOX, Trusted Automated eXchange of Indicator Information (TAXII™) |
| Enable new levels of meta-analysis on operational cyber observables | Cyber Situational Awareness | CybOX, STIX |
Summary
In this chapter we discussed the importance in being able to distinguish intelligence from information in order to ensure actionability through one of the schemas, frameworks, or standards that we introduced to the reader. We described for the reader the concepts of the IOA, IOC, and IOI. We presented the OpenIOC framework, IODEF (RFC5070), IOCBucket, and CybOx for your review and consideration paying attention to the unique detail, which comprise each of these offerings and their specialized use cases. Furthermore, this chapter was designed as an introduction to these concepts and as a prelude to more complex situations and scenarios, which will be presented in later chapters of this book.