As with my last post, this was originally written for an intermediate assignment in my M.S. program. It has already been submitted for credit and slightly modified for the for the format. Comments or questions here or @digital4rensics are always welcome!
Introduction, or Why These Frameworks?
Computer security incident details are deeply technical, but it is often the job of incident response personnel to translate these details in to business terms. In some cases, these descriptions are used to make organization influencing decisions and occasionally the high level incident details make it out of an organization. In these cases, the information gleaned may not be particularly useful for other incident handlers or organizations dealing with similar incidents. The gap that exists in the ability to share computer security incident information has been outlined and a rough system for facilitating such information sharing was described. Such a system would require a standard framework or taxonomy for representing data.
The frameworks examined herein were not chosen at random. There are several preliminary considerations when evaluating a potential framework.
- Extensibility: If the framework can’t be expanded in the future, there is high probability it will become outdated. This also serves to facilitate customization in specific implementations.
- Scope: The system previously described is designed to include information regarding an entire incident. As such, frameworks designed to facilitate information exchange about single events (such as CEE) or specific applications (such as IDMEF) are not suitable.
- Ease of Use: For most of the organizations that would benefit from querying the information dataset, research is not a primary goal. With this in mind, extremely detailed frameworks could be too cumbersome for the most likely audience, and may require too much time to use, raising a barrier to adoption.
- Activity: While not 100% required, active development and community involvement in a framework serves to reduce the barrier to adoption. Frameworks which have not been updated or otherwise received attention for ten or more years are at a disadvantage to those with current traction in the incident response community.
With these requirements in mind, the frameworks examined all have pros and cons associated with their use. Additionally, since none of these frameworks was designed for an information sharing system as described, it is likely that the most effective solution would actually incorporate aspects of each framework.
VERIS, or My Manager’s Framework
The Verizon Enterprise Risk and Incident Sharing (VERIS) framework was designed and published by the Verizon Business and is used by their Investigative Response team in order to formulate the Data Breach Investigations Report (DBIR) each year. Naturally then, VERIS is designed to support the collection and creation of the metrics contained in the DBIR and it does this very well. Verizon describes VERIS as a “common language for describing security incidents in a structured and repeatable manner” and states that its goal is facilitate the ability to “better manage risk”.
Since risk management is a primary goal for VERIS, it makes use of a model which gathers metrics describing an incident, as well as affected assets, the estimated level of impact, and estimated cost of the incident. These figures can then be used across countries, industries, and organizations to inform management of trends and statistics that can be used to help make risk management decisions. When considering the proposed incident reporting system, one area of specific interest is the incident classification model used by VERIS. Verizon calls it the A4 threat model, which includes the Agent, Action, Asset, and Attribute. In this model, an incident is comprised of multiple adverse events. Each event contains the A4 elements, which then each have a series of associated classifications. It’s interesting to note that this model closely mirrors Howard & Longstaff’s incident taxonomy, which was originally published in 1998. The primary difference is seen in the definition of an event. Since VERIS views an incident as a series of adverse events, negative impact is already assumed. More precisely, one would already know an incident is occurring. In Howard & Longstaff’s model, an event is comprised of only and action and asset (or target). In this case, there is no assumption regarding negative impact. In Howard & Longstaff’s model, expanding the classification to an attack introduces the attribute element, and including the incident then takes in to account the agent.
Another interesting comparison applies to the potential types associated with the 4th A, attribute. The proposed selections do not mirror the traditional Confidentiality, Integrity, and Availability (CIA) triad. Instead, VERIS makes use of the Parkerian Hexad, a model proposed by Donn B. Parker, which adds Possession of Control, Authenticity, and Utility. Since the selection of elements within the VERIS framework is not mutually exclusive, the additional attributes available serve to more holistically describe an incident.
The yearly DBIR shows that VERIS is a solid framework for its purpose. Generating metrics to support risk decisions is trivial, and the framework’s extensibility offers the ability to add additional areas in the future. However, in its current form, the framework focuses largely on anonymity. In order to be viable for use in the proposed system, the framework would immediately need to be extended to include identification traits. Additionally, the framework currently focuses largely on high-level details. While there are options for free-text entry, this reduces the ease of use within the proposed system as the data within those entries would not be standardized. Extending the data collected to include more technical details would provide increased utility to incident responders.
IODEF, or A Solid Base
The Incident Object Description Exchange Format (IODEF) is a framework for sharing common incident-related information. The framework is a product of the Internet Engineering Task Force (IETF) Networking Working Group and may also be referred to as RFC5070. Since IODEF was created specifically to enhance data sharing capabilities, it includes a baseline of data models that are commonly included in any computer security incident, as well as additional supporting information often exchanged during an incident. IODEF also focuses on the entire incident, and recognizes that each incident consists of multiple events. Structurally, each IODEF document can be composed of multiple incidents, each of which can include multiple event descriptions.
When compared with VERIS, IODEF is both less inclusive and more detailed. There is notably less attention paid to the agent involved in an incident in the IODEF framework, but the ability to estimate impact and define causality still exist. One area of particular interest is the built-in support for restricting the release of certain portions of an IODEF document. If extended for a large incident information sharing system, this capability could be leveraged to enforce access control to certain types of information. IODEF also contains a dedicated class for contact information, which is doesn’t appear at all in VERIS. This is a function of purpose. Where VERIS is designed to aggregate data, IODEF is designed to share the details of the data at hand, which cannot be easily accomplished without sharing identifying information. IODEF becomes more detailed when examining the capabilities for recording temporal data, as well as incident flow, which could be useful in identifying specific patterns in a group of incidents.
While additional detail is welcomed in some areas, IODEF could become too cumbersome in some instances. The level of detail allowed, down to identifying attributes of all systems in a specific incident, approaches the level of a full incident report. In most organizations, a written, free-flow report will be required for incidents. Duplicating the same level of detail in an information sharing environment could discourage the use of the system. Ensuring the proper level of generalization and restriction of some details from the schema could serve to reduce this barrier. This ties in with the extensibility requirement, which also applies to custom implementations. The IETF has also demonstrated the extensibility of IODEF by publishing RFC5901, which is specific to phishing events within an incident. The document demonstrates how additional elements can be included in the standard classes included with IODEF.
OpenIOC, or The Enterprise Defender’s Framework
OpenIOC is a framework developed by MANDIANT to share information about specific threats which could be experienced during an incident. OpenIOC differs from the previous two frameworks in that it doesn’t incorporate information regarding the entirety of an incident. The reason it was included in this comparison is that it could be used to extend each of the previously described frameworks by including the OpenIOC schema as a subset of information.
In order to understand OpenIOC, the idea of an IOC, or Indicator of Compromise, must for be examined. “Indicators of Compromise (IOCs) are forensic artifacts of an intrusion that can be identified on a host or network.” That is, some piece of information that occurs as a result of compromise. Since the OpenIOC framework was originally designed for use in MANDIANT’s products to identify specific signs of intrusion, it makes since that the entire incident is not included within the framework. Again, there is a scope variable at play.
OpenIOC documents do provide a unique opportunity for transmitting detailed incident data without compromising the confidentiality of sensitive information. Since the artifacts of a compromise are described instead of the compromise itself, other incident handlers can use the information within an incident. In the case of malware, all that’s needed are the traces left behind. In the case of an active perpetrator, the document may include just a description of the attacker’s actions. Neither case requires knowledge of the target or its sensitivity level. Additionally, IOC data can still be used to generate metrics about current and emerging attack trends and techniques. When linked with higher level information, determining the most common technical methods of attacks can also help influence risk management decisions.
In the case of an incident sharing system, one potential downfall of the OpenIOC format is the flexibility that it allows an incident handler. More specifically, the plethora of indicators included in the framework provides the opportunity for multiple incident handlers to describe a single event in multiple ways. Each may be technically correct, but correlating the information could become difficult on a large scale. Additionally, there is a definite learning curve for writing effective indicators as described by MANDIANT. However, this is expected in many technical areas and with practice, the indicators can assist in accurate identification of incident-related artifacts.
Bringing it All Together
None of the frameworks examined would be completely suited for the proposed incident information sharing system. However, each has definite pros and cons and each fits within its defined scope well. For the proposed system, the scope would differ slightly, which will require leveraging the extensibility of these frameworks and defining a hybrid. Successfully completing this task would create a system useful on multiple levels. High level executives could gather metrics used to inform risk management decisions. Industry researchers could use the dataset to identify the impact of incidents and trends in attack methods. Incident handlers could query the data for similar incidents to gather methods for incident response. The key is designing a framework for use in a system that accepts descriptions of incidents on a high level while still collecting an accurate and useful level of technical detail.
 (Gilbert, 2011)
 (MITRE, 2011)
 (Debar, Curry, & Feinstein, 2007)
 (Verizon Business, 2010)
 (Verizon Business, 2010)
 (Verizon Business, 2010)
 (Howard & Longstaff, 1998)
 (Kabay, 2011)
 (Danyliw, Meijer, & Demchenko, 2007)
 (Cain & Jevans, 2010)
 (MANDIANT, 2011)
 (MANDIANT, 2011)
 (MANDIANT, 2011)
Cain, P., & Jevans, D. (2010, July). Extensions to the IODEF-Document Class for Reporting Phishing. Retrieved January 18, 2012, from Internet Engineering Task Force: http://www.ietf.org/rfc/rfc5901.txt
Danyliw, R., Meijer, J., & Demchenko, Y. (2007, December). The Incident Object Description Exchange Format. Retrieved January 18, 2012, from Internet Engineering Task Force: http://www.ietf.org/rfc/rfc5070.txt
Debar, H., Curry, D., & Feinstein, B. (2007, March). The Intrustion Detection Message Exchange Format. Retrieved December 18, 2012, from Internet Engineering Task Force: http://www.rfc-editor.org/rfc/rfc4765.txt
Gilbert, K. J. (2011). On Computer Security Incident Information Sharing. Norwich University MSIA.
Howard, J. D., & Longstaff, T. A. (1998). A Common Language for Computer Security Incidents. Albuquerque: SANDIA National Laboratories.
Kabay, M. (2011). The Parkerian Hexad. Retrieved January 18, 2012, from mekabay.com: www.mekabay.com/courses/academic/norwich/is340/is340_lectures/csh5_ch03_parkerian_hexad.pptx
MANDIANT. (2011). OpenIOC. Retrieved January 19, 2012, from openioc.org: http://www.openioc.org
MANDIANT. (2011). Sophisticated Indicators for the Modern Threat Landscape: An Introduction to the OpenIOC. Retrieved January 18, 2012, from openioc.org: http://openioc.org/resources/An_Introduction_to_OpenIOC.pdf
MITRE. (2011, July 21). About CEE. Retrieved December 18, 2012, from Common Event Expression: http://cee.mitre.org/about/
Verizon Business. (2010). Verizon Enterprise Risk and Incident Sharing Metrics Framework. Retrieved January 18, 2012, from Verizon Business: http://www.verizonbusiness.com/resources/whitepapers/wp_verizon-incident-sharing-metrics-framework_en_xg.pdf