In the second installment of this blog series we built off of the first installment by discussing in greater detail many key principles and concepts for the comprehension of indicators of compromise (IOC) by security analysts. We continued our conversation related to how IOCs relate to observables and how observables relate to measurable events and / or stateful properties on a given host.
We also reiterated the importance of being able to identify, collect, record and note in a detailed manner IOCs as they are encountered in a host and network-based forensic investigations. In fact, I can’t stress too often or strongly how important this truly is! We also introduced another framework or taxonomic model that is making waves in the industry related to the establishment of a formal approach to IOC creation and communication, the OpenIOC initiative. We found that the OpenIOC standard is intriguing due to its highly extensible, well vetted for IOC development and customization of IOCs for organizations of varying size and industry vertical. Potential downside being that it is vendor-sponsored and largely driven though it endorses a “community” driven look and feel. For some organizations, this will be the ‘Achilles heel’ in the selection process.
What is the IODEF (RFC 5070)
The IODEF is a standing IETF RFC (RFC 5070) that is designed to address and define a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. The basic premise is that organizations need help from third parties to mitigate malicious or nefarious activity targeting their hosts and networks. They need to gain additional (presumably absent) insight into these new and exotic threats. The coordination element of this communication seems to be less obvious and natural than one might think hence, the need for a standards-driven framework for coordinating this process. The RFC suggests that such coordination may include (but is not limited to) working with ISPs to filter traffic deemed malicious and unwanted, to contact a remote site to take down botnet hosts or for the sharing of reputation-based intelligence.
The architects of the Incident Object Description Exchange Format (IODEF) are a format that offers the users a means by which to represent computer security information as described above. It is communicated via an XML schema that conveys incident information across administrative domains amongst parties that have an operational responsibility for both remediation and notification of their user population.
The data model itself encodes information about hosts, networks, and services running on various systems, along with attack methodology and associated forensic evidence (artifacts), and impacts. Furthermore, the standard offers an approach (albeit a limited one) for documenting the workflow necessary for triaging and communicating the aforementioned data.
Overall, the IODEF (which came out in 2007 and was sponsored by some folks at the University of Amsterdam) strives to enhance the operational capabilities of CSIRTs and threat intelligence analysts. It’s community driven which makes it highly extensible and affords the standard refinement and improvement driven by an ‘open source’ community independent of a vendor sponsor. The architects of the standard designed it with the goal of improving the ability to resolve incidents while being able to more artfully express situational awareness via simplified collaboration and data sharing. A beautiful thing however, it may not meet your organization’s needs and requires more research as we’ll see. The format that the standard espouses sees its architects advocating automation for the following:
- Processing incidents
- Decreased efforts in normalization of incident data
- Common format / schema for the purpose of building tools for incident handling and analysis
A very well defined standard driven (vendor independent) approach to the creation and articulation of IOC related information and intelligence. For some organizations this will be a much more natural and easily adopted format than for others given its vendor neutrality and heavily documented nature. For others, it may not be as readily adopted due to the very same reasons. I would recommend organizations investigate this standard and become familiar with it in comparison to the two other standards we have described and discussed in this series to date. I believe that an open standard designed with increasing situational awareness and ability to react is what most organizations require and that this is a great example of what can be done and how it can be architected for an enterprise and a community.
All of the standards we looked at require scrutiny and investigation in order that organizations make the correct decision in terms of which to adopt and for what reason. It’s completely plausible that an organization may decide that certain aspects of one standard and certain aspects of another make for a winning combination. Whatever your decision take the time to review and assess your organizational readiness in preparation of adopting one of these standards. In doing so, you will save both time and trouble!