-We describe our ongoing development of an insider threat indicator ontology. Our ontology is intended to serve as a standardized expression method for potential indicators of malicious insider activity, as well as a formalization of much of our team's research on insider threat detection, prevention, and mitigation. This ontology bridges the gap between natural language descriptions of malicious insiders, malicious insider activity, and machine-generated data that analysts and investigators use to detect behavioral and technical observables of insider activity. The ontology provides a mechanism for sharing and testing indicators of insider threat across multiple participants without compromising organization-sensitive data, thereby enhancing the data fusion and information sharing capabilities of the insider threat detection domain.
I. BACKGROUND
The study of insider threat presents some of the most
complex challenges in information security. Even defining the
insider threat has proven difficult, with interpretations and
scope varying depending on the problem space. The CERT®
Division of Carnegie Mellon University’s Software
Engineering Institute defines a malicious insider as a current or
former employee, contractor, or other business partner who has
or had authorized access to an organization’s network, system,
or data and intentionally exceeded or misused that access in a
manner that negatively affected the confidentiality, integrity, or
availability of the organization’s information or information
systems [
All entity and relationship data models, including semantic data models, have their limitations [5]. Models are extremely formal by design and can encounter problems when representing the variety of actions involved in a real-world insider threat case. In addition, the data on cases of insider threat is often gathered from legal judgments and outcomes whose documentation is highly variable. As a result, insider threat domain experts tend to rely on natural language to document their cases and findings. Though natural language is more expressive than a model, we believe the insider threat domain will benefit from the development of an ontology. Our interest in building an ontology, developed from our observations of the field today, is driven by the following factors:
We expect rapid growth in the data being collected and
shared by organizations, specifically about insider threats.
Some organizations have already stated that overcoming
this challenge is one of their top priorities [
The insider threat research community lacks a defined,
formal model that is machine readable, human
understandable, and transferrable with limited sharing
barriers. We felt that starting a model of this kind, based
on the real-world case data we have already collected,
could accelerate this process within the community, as
has been done in other fields [
We are willing to accept some loss of descriptive power for individual cases, provided we can analyze large populations of cases using computation. We expect insider threat teams (both in research and in operations) to be asked to detect insider threat activity by analyzing a growing quantity of data from new sources in an increasingly limited amount of time.
III. APPROACH
At first glance, defining the domain of our ontology appeared to be a trivial matter: representation of potential indicators of malicious insider activity. In practice, indicators of malicious insider activity involve complex interconnections of parts of several other domains:
Human behavior: understanding insider threats involves understanding the people behind the malicious activity— the reasons why they attacked, their psychological characteristics, their emotions, and their intent.
Social interactions and interpersonal relationships: modeling the relationships between insiders and their employers, colleagues, friends, and family is a crucial part of identifying stressors that are often associated with malicious insider activity.
Organizations and organizational environments: the culture and policies of organizations factor heavily into the interpretation of malicious behavior within an organization.
Information technology security: information and information systems can be both the targets of and tools used to perpetrate malicious insider activity. IT security also contains other concepts of interest in describing the insider threat domain, namely, confidentiality, integrity, and availability.
With a representative list of sub-domains for insider threat
enumerated, our next challenge was determining the scope at
which our ontology must provide support for each subdomain.
We chose to develop the following competency questions for
our ontology to assist us in our scoping efforts [
What concepts and relationships comprise the technical and behavioral observables of potential indicators of malicious insider activity? What potential indicators of malicious insider threat activity are insider threat teams using for detection? To facilitate information sharing, at what level of detail should organizations describe their indicators of malicious insider activity without revealing organizationsensitive information?
Since 2001, the CERT® Insider Threat Center has collected over 800 cases in which insiders used IT to disrupt an organization’s critical IT services, commit fraud against an organization, steal intellectual property, or conduct national security espionage, sabotaging systems and data, as well as other cases of insiders using IT in a way that should have been a concern to an organization. This data provides the foundation for all of our insider threat research, our insider threat lab, insider threat assessments, workshops, exercises, and the models developed to describe how the crimes evolve over time. Our case collection involves gathering and analyzing data from public (e.g., media reports, court documents, and other publications) and nonpublic (e.g., law enforcement investigations, internal investigations from other organizations, interviews with victim organizations, and interviews with convicted insiders) sources. This data collection, summarized in Figure 1, primarily focuses on gathering information about three entities: the organizations involved, the perpetrator of the malicious activity, and the details of the incident. Each case in our insider incident repository contains a natural language description of the technical and behavioral observables of the incident. We used these descriptions as the primary data source for our ontology.
To ensure full coverage of the information contained in our
insider incident repository, we adopted an approach that
utilizes concept maps as a first step in the development of an
ontology [
We supplemented the candidate classes and object
properties derived from our insider incident repository with
concepts and relations from the cyber threat and digital
forensics domains. We reviewed the Structured Threat
Information Exchange (STIX) and Cyber Observable
Expression (CybOX) languages [
IV. IMPLEMENTATION
We adapted components from several existing ontologies
for our work. To assist in the modeling of actors and their
actions, we adapted several top-level ontology components
from material available on schema.org [
The top-level of our ontology, summarized in Figure 2, is composed of five classes: Actor, Action, Asset, Event, and Information. The Actor class contains subclasses for representing people, organizations, and organizational components such as departments. The Action class contains the subclasses that define the things that actors can perform. The Asset class provides subclasses that define the objects of actions. The Information class provides subclasses that provide support for modeling the information contained within some assets (examples include personally identifiable information, trade secrets, and classified information). The Event class provides support for multiple types of events of interest. Events are generally associated with one or more Actions. The creation of an individual event typically requires making some inference, as opposed to an individual Action, which can be created through direct observation. For example, moving a file is modeled in our ontology as an Action. A data exfiltration event, when associated with a file move action via the hasAction object property, expresses the fact that the associated action was unauthorized. Additionally, an object property hierarchy is provided to express various types of relationship roles, job roles, and event roles.
Asset hasInformation
Information hasObject / hasInstrument hasOwnership
Actor hasActor Event hasAction
Action precedes
To demonstrate use of the ontology to describe indicators of malicious insider activity, we present two examples of translating natural language descriptions of indicators of malicious insider activity from our insider threat incident repository into ontology individuals. The translation process is relatively straightforward; the concepts from each description are manually identified, individuals are created for each concept as instances of the appropriate ontology class, and individual object properties are added to relate the class instances to one another. Figure 3 and Figure 4, respectively, depict the ontology translation for the following insider threat indicator descriptions:
The insider transferred proprietary engineering plans from the victim organization's computer systems to his new employer.
The insider accessed a web server with an administrator account and deleted approximately 1,000 files. A. Insider Threat Indicator Information Sharing
Our ontology provides two powerful concepts in the description of potential indicators of malicious insider activity: abstraction and extensibility. By abstraction, we mean that indicators can now be described at a level of detail that omits organization-sensitive information while still maintaining enough descriptive information to express the idea that given observable actions or conditions are potential indicators of malicious insider activity. By extensibility, we mean that we have provided the conceptual components that organizations can use to describe their existing indicators and develop new indicators. Potential indicators of malicious insider activity often include qualifiers such as “excessive ,” “anomalous,” “unauthorized ,” and “suspicious” to distinguish conditions that are potentially indicative of malicious insider activity from “normal” behavior and activity. D efinitions and interpretations of these types of conceptual qualifiers vary greatly from organization to organization, and often vary within organizations based on variables such as job type, location, and time. To accommodate these variations, we introduce the idea of “policy packs” in o ur ontology: modular collections of ontology axioms that represent organizationagnostic concepts, definitions, and interpretations of indicator patterns. Our ontology specifically provides support for this via the Event class hierarchy. Organizations using our ontology can develop their own defined classes, or modify existing ones, to specify the necessary and sufficient restrictions for class membership.
B. Automated Indicator Instance Extraction Framework
Insider threats can be detected by observing instances of indicators of malicious insider activity within an organization. Operationally, this involves the collection and analysis of large amounts of data on every employee in an organization. Without some level of automation, this detection practice becomes infeasible to perform effectively and efficiently. Using our ontology, we have designed a semi-automated approach for the detection of potential indicators of malicious insider activity that fuses data from multiple types of sources. The ontology provides an analysis hub that combines information from an organization’ s enterprise network activity and human resources data to provide a data-rich environment for the development and detection of robust, effective indicators of malicious insider activity.
1) Operational Data to Ontology Individuals
We use the term “operational data” to encapsulate the data and data sources that capture the user-based activity that occurs on an organization’s info rmation systems and networks. The technical observables associated with some potential indicators of malicious insider activity are found in operational data and during the analysis of trends in operational data. Some examples of operational data include: Host-based user activity logs Critical application audit logs Network activity logs Communication server logs System event logs
Since operational data is usually found in structured or semi-structured log files, we attempted to prove the concept of automatically translating the information contained in operational data sources into ontology individuals. Instead of direct translation into ontology individuals from operational data sources, we chose to translate the operational data into CybOX cyber observable files, and automatically create ontology individuals based on the contents of the CybOX files. This approach allowed us to focus on identifying the fields from CybOX that were applicable to our ontology classes, and provide a translation mechanism for only those applicable fields. Without the CybOX translation layer, we would have had to develop ontology translation mechanisms for each type of operational data source we wish to support, which would require an infeasible level of effort, support, and maintenance. Additionally, CybOX provides an API for their XML file format, which facilitates the automated translation of any input data source into the CybOX format. (CybOX currently supports over 60 input data sources.)
In our proof of concept, we were successful in automatically translating Windows system event logs into the CybOX format, and, using simple scripts, automatically generating the OWL XML code to create individuals for a small subset of our ontology classes. In a robust implementation, the automated ontology individual creation would provide configurable settings that would allow organizations to control the creation of ontology individuals for classes whose specific definitions may vary from organization to organization. For example, if the ontology contained a class representing after-hours logins, the automated individual creation mechanism should provide a way to specify a time range that is considered after-hours. 2) Human Resources Data to Ontology Individuals We use the term “human resources data” to encapsulate data and data sources that provide contextual and behavioral information about employees. These records are typically stored in an unstructured format, and are locked within Human Resources departments to protect the privacy rights of employees. Examples of human resources data include: Organization charts Employee performance reviews Employee personnel files, including job title, supervisor, role, and responsibilities Employee behavior records, such as formal reprimands and policy violations Information from anonymous insider reporting channels Results of background checks Human resources data provides a rich source of contextual, behavioral, and psychosocial information regarding employees. Human resources data is typically more fragmented and less structured than operational data, so the automated translation of this data into ontology individuals may be a challenge for some organizations. Enterprise solutions for human resource information management exist, and where they are used, a structured representation of human resources data could be used to develop an automated ontology translation process. In our proof of concept for the automated indicator instance extraction framework, we did not attempt to automatically create ontology individuals from human resources data, but in future work, we will apply a similar approach to we used for operational data.
3) Semantic Reasoner
If operational data and human resources data are both described using the ontology, and if indicator policy packs are in place, an organization can use a semantic reasoner to make inferences and automatically classify ontology individuals as instances of specific defined classes. Ontology individuals that meet the formal definitions of potential indicators of malicious insider activity can then be said to have “satisfied” some indicator. A collection of ontology individuals that satisfy threat indicators becomes a useful data set for insider threat analysts. With a robust set of indicators implemented as defined classes, analysts have the ability to see descriptions of potential indicators of malicious insider activity across previously disparate data sets and at larger scale. Satisfied indicators can be reviewed by analysts to identify false positives, refine indicators, develop new indicators to add back into the ontology via policy packs, or create threat reports that summarize the potential malicious insider activity found in the data.
4) Putting it All Together
The full framework—beginning with the development and maintenance of the ontology through the release of organizational threat reports based on the detected instances of potential indicators of malicious insider activity—is presented in Figure 5. This framework is meant to support detection of potential indicators of malicious insider activity that is then triaged. An effective implementation of the framework depends on the indicators it contains, and not all satisfied indicators necessarily warrant an investigation. The evaluation of specific instances of indicators requires expert analysis and investigation to remove false positives, assess severity of the satisfied indicator, and perform set and temporal analysis on the satisfied indicators. The framework can support a workflow-based analysis and incident escalation process. Specific implementations of the framework are expected to grow and change as the organization, its insider threat program, and the larger insider threat community and domain all do the same. The activities associated with the operations and maintenance of this framework include Identifying new candidate indicators during the analysis of satisfied indicators Adding new indicators to the ontology as updates or additions to indicator policy packs Re-running the semantic reasoner as new ontology individuals are created and new indicators are added Adding automated ingest support for new operational data sources Extending the human resources data ingest process to include new data sources Updating the configuration for the automated ontology individual extractor as organizational policies change and new insights are gained In addition to the activities mentioned above, the ontology itself will grow and change over time. The drivers for ontology changes will be the addition of new concepts and relationships based on analysis of new cases involving malicious insider activity, as well as feedback from the organizations that are using the ontology. Finally, indicator policy packs can be safely shared with other organizations as a means of identifying effective industry specific and domainwide detection strategies and patterns.
VI. CONCLUSION
With the initial development of our ontology, we have created a bridge between natural language descriptions of potential indicators of malicious insider activity in case data and the operational data that contains the technical and behavioral observables associated with malicious insider activity. We have provided a mechanism that allows sensitive information to be abstracted away while maintaining enough descriptive ability to effectively communicate actions and behaviors of interest across organizations. By introducing the application of our ontology as an analysis hub that combines operational and human resources data, we have laid the foundation for more effective fusion of these traditionally disparate data sources.
As we continue the development of our ontology, we will perform the following activities in future work:
Provide enhanced support for behavioral components of potential indicators of malicious insider activity Collaborate with other organizations to improve the expression of insider threat indicators using the ontology Add support for additional indicator policy packs Mature the proof of concept automated indicator instance extractor and provide customization options for additional data sources and organization configurations Assess the feasibility of automating the creation of ontology individuals based on human resources data Evaluate formal ontology validation methods and apply them to our ontology
The authors gratefully acknowledge support for this work from the Defense Advanced Research Projects Agency (DARPA) and the Federal Bureau of Investigation. The views, opinions, and/or findings contained in this article are those of the authors and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government. Approved for Public Release, Distribution Unlimited.
Copyright 2014 Carnegie Mellon University This material is based upon work funded and supported by Federal Bureau of Investigation under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center sponsored by the United States Department of Defense.
References herein to any specific commercial product, process, or service by trade name, trade mark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software Engineering Institute.
NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS -IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.
This material has been approved for public release and unlimited distribution. Carnegie Mellon® and CERT® are registered marks of Carnegie Mellon University. DM-0001586