Recent research indicates that organizational insiders perpetrate 35 percent of data breaches, and malicious insider incidents cost organizations an average of $701,500 annually. The study and management of insider threat and risk remain areas of increasingly growing attention, prevalence, and concern, but capturing and sharing information about insider incidents in a standardized way has been a challenge for practitioners. A standard of incident classification and information sharing could allow practitioners to build, maintain, deidentify, and share insider threat case data with an eye toward building more robust data for analysis and insights that benefit their organizations and the whole community. In this post, we introduce the Insider Incident Data Exchange Standard (IIDES) schema for insider incident data collection, provide an example use case, and invite you to collaborate with us on its development.
The field of insider threat is itself still relatively young, encompassing many different fields, disparate sources of legal and policy mandates, and several schools of thought regarding concepts of operation. The most recent edition of The CERT Common Sense Guide to Mitigating Insider Threats was published in 2022, and it builds on more than two decades of data collection, research, and partnering by the SEI CERT Division. In much the same way that research around insider threat is still growing and coalescing, practitioners are still building on experience to work out best practices around technical defenses, behavioral and human elements mitigations, and methods for storing and exchanging incident data.
These goals have all motivated the CERT Insider Risk Team to develop a new standard for storing and exchanging insider threat case data. While there have been some attempts at standardizing various aspects of insider threat terminology over the years, none have been comprehensive enough to meet our own data collection needs, and none provide a specific schema for interconnecting pieces of data. The Insider Incident Data Exchange Standard (IIDES) includes structures for collecting and analyzing a variety of technical, non-technical, organizational, and incident response information to meet the varied needs of researchers and practitioners, and will be accompanied by a corresponding tool suite. We hope that IIDES supports a more consistent mapping of recommendations and best practices for response, detection, and mitigation of insider threats in the future.
IIDES development, as is the case with many standards, required a tradeoff between a fully articulated, tightly constrained schema and a language flexible enough to be useful across a range of potential applications and users. We used the guiding principles of simplicity, expertise, flexibility, and interoperability to balance these tradeoffs.
The IIDES Schema
IIDES provides a schema, coded in JSON, to collect and categorize insider threat incidents. The schema includes four sections: the core components, additional subcomponents, relationships, and vocabularies.
Core Components in IIDES
There are seven core components in the IIDES schema:
- Incident—a summary and description of the security threat
- Insider—the person involved in the incident
- Organization—the organization involved in the incident
- Job—the employment relationship between an individual and an organization
- Detection—details about how, when, and by whom the incident was discovered
- Response—the organization’s response to the incident
- Tactic, Technique, and Procedure (TTP)—an action taken by an insider during an incident
Figure 1: The core components in IIDES
Additional Subcomponents
Some components have additional subcomponents. For example, the Response component can have a Legal Response subcomponent, which might include one or more Court Case components. Figure 2 more fully illustrates these relationships.
Figure 2: A diagram of all components and subcomponents in IIDES
Relationships
A relationship connects two entities in IIDES. For example, an Insider may have a relationship to an accomplice who helped commit the incident. The Insider also likely has a relationship with a Job component. Specifying relationships is one of the major differences between IIDES and other standards that have been proposed over the years. Rather than a list of potential terms, IIDES provides the entire structure of an incident, and how each piece of information about the insider, the organization, and the insider’s actions connect together to form a complete picture of the insider threat.
Vocabularies
Many of the components in IIDES have associated vocabularies that further describe entities and provide consistent terminology for discussing incidents across different organizations. The Insider component, for example, includes a vocabulary for the insider’s motive, such as financial gain or curiosity. These vocabularies will likely change over time as IIDES develops further and users suggest additions.
IIDES in Action
We have provided a number of example cases with fictitious data to illustrate how IIDES can work in practice. In one example, we created a case with the following summary:
The insider, a former military member, worked as a cybersecurity specialist for a government agency in May 2003. During this time, she printed a report from her work computer that detailed unauthorized access attempts by a foreign hacking group against municipal election systems and voter databases. She then shared this Top Secret information with a tech blog. This report revealed the techniques and tools used to gather the information contained in the report, which, if disclosed, could be detrimental to the United States. A government agency investigated her, and the insider pleaded guilty in June 2004 to one felony count of unauthorized transmission of national defense information and was convicted.
The sample cases include a JSON file matching IIDES, an easier to read markdown representation of the same data, and a visualization of the components generated from the schema.
Figure 3: IIDES sorts the incident data into a structured schema for easy collection, analysis, and sharing. The lower left blocks are magnified in Figure 4.
Figure 4: An excerpt of a visualization of a sample case in IIDES. Each piece of case information fits into the organized schema.
These examples illustrate the insider’s actions, their relationships, and the outcome of the incident in a format that enables easier storage and sharing of insider incidents.
Work with the SEI
We anticipate IIDES will benefit those who create models and simulations for training, education, and best practices by providing a consistent vocabulary across organizations. Practitioners such as analysts, investigators, and those responsible for risk management stand to benefit from building internal case corpora that can be easily analyzed, searched, and measured. For those with a need to share case data with other practitioners, other similar businesses or entities, and third-party organizations, such as law enforcement, governmental agencies, or research organizations, IIDES provides a consistent format for a shared understanding.
We are very interested in getting feedback from the community regarding IIDES and plan to incorporate the feedback we receive before releasing an official 1.0 version. How do you see your organization using IIDES? Are there specific additions or changes you would like to see? Are there use cases or benefits that we haven’t anticipated? Do we need to clarify anything in the documentation or vocabularies? You can review the IIDES white paper for more information about IIDES development and its core functionality or go straight to the schema or documentation for each of the classes.
You can submit your feedback to info@sei.cmu.edu or directly on GitHub through the issues tab.
