icon-carat-right menu search cmu-wordmark

High-Level Technique for Insider Threat Program's Data Source Selection

This blog discusses an approach that the CERT Division's National Insider Threat Center developed to assist insider threat programs develop, validate, implement, and share potential insider threat risk indicators (PRIs). The motivation behind our approach is to provide a broad, tool-agnostic framework to promote sharing indicator details. You might share these details among your insider threat team personnel and other key stakeholders, such as Human Resources, Legal, and Information Technology, before the direct dive into implementation or tool acquisition.

Flow chart reading: Scenarios, drives, 4-tuples, updates, tools.

To develop a new indicator, your team will start with a threat scenario describing a potential insider incident. These scenarios can be gathered from various sources, such as known issues within the organization, cases taken from organizations in the same field, or an internal tabletop exercise.

The next step is to break the threat scenario into a set of observables. Observables can be physical, behavioral, or technical actions to describe the state or activity the insider may be exhibiting. For each of the observables, identify the following four pieces of information (we call this the 4-tuple).

  1. data source(s)
  2. field within the data source
  3. analytic technique(s)
  4. response options

Let's look at each element of the 4-tuple. The data source(s) is the first element of the 4-tuple, and it specifies where to find details related to the observable. A sensor monitoring user or device activity, for instance, could be a technical data source that is logging information at (or inside) your organization's firewall. An organization might have data sources such as data loss prevention tools, operating system security logs, physical security logs, and Human Resources management system information1, for example.

Since a data source may capture many different types of activities, the second element consists of the fields in the data source. Examining these fields narrows down the details needed to find events associated with the observable. For example, for the given observable you only may want to look for failed login attempts. For example, Window's Security logs have a type field, and you could use the failed login value to find failed logins. You could also include fields associated with the activity such as the account name, machine, date, time, and other information to support the observable.

The next element is the analytic technique. This element describes how the fields in the data sources are analyzed in hunting for potential threats; various techniques are presented. Above we mentioned matching a failed login type to the window's security type field--an example of a value match analysis technique. You could also use pattern matching analysis techniques to learn whether a data source's fields match a pattern. For example, use the activities timestamp field to show any activity that occurred within the last seven days.

More sophisticated analysis techniques enable you to use multiple field and trend data over time to look for statistical anomalies (outliers). The anomalies could be in the insider's baseline behavior, or you could compare the insider's behavior against the insider's peer group.2

The analytic techniques vary in complexity and computational resources needed. The 4-tuple approach to indicator development notes this complexity early in the process and makes it explicit to the team. Members of the insider threat program team should perform a cost/benefit analysis regarding the implementation of this PRI.

The final element in the 4-tuple is the response the insider threat program will take if this indicator is detected, generating an alert for an insider threat analyst to triage. The response could range from simple alerting to taking some automatic action, such as disabling an account with suspicious activity. Using this approach, the team can use the response option to express how critical this indicator is to the organization.

As mentioned above, the 4-tuple is written at a high level to facilitate discussion among the team. Let's make this high-level nature more concrete by looking at an example. Assume we want to develop a PRI from a scenario that includes the loading of unauthorized software. The observable in this example is the installation of unauthorized software. The 4-tuple is given in the following table.

Observable Data Sources Fields Analytic Technique Response Option
Successful software installation attempt Windows Event Logs Software Name Pattern match -- is software not in a list of approved software packages? Generate an alert (high)

Enable enhanced monitoring

The 4-tuple approach provides enough detail that all the stakeholders can discuss the merits of the indicator. Human Resources and General Council are made aware of the data being requested. The technical teams can scope the complexity and the impact to system resources. Executive leadership understands the scenarios being monitored and implications to the organization based on the response options.

Once the stakeholders agree the PRI is of concern to the organization and should be tracked, the insider threat team can begin the process of incorporating the appropriate data source(s), analytics, tools, and/or procedures to detect the indicator. Sometimes this means the insider threat team might simply need to update the configuration of a currently deployed tool. If the current tools can't detect the indicator, the organization could begin an evaluation and acquisition process using the information gathered during the 4-tuple exercise as a guide for selecting a tool capable of finding the required PRIs.

With this approach, the insider threat program's personnel and stakeholders can more effectively discuss any indicator's requirements under consideration and the impact of incorporating those indicators would have on the organization.

Stay tuned for more content from the CERT National Insider Threat Center, refer to our current publications (such as Analytic Approaches to Detect Insider Threats), or consider attending our instructor-led Insider Threat Analyst course.

Subscribe to our Insider Threat blog feed to be alerted when any new post is available. For more information about the CERT National Insider Threat Center, or to provide feedback, please contact insider-threat-feedback@cert.org.

1 See Common Sense Guide to Mitigating Insider Threats, Sixth Edition (https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=540644) for a discussion of data source providers.

2 See https://www.insaonline.org/an-assessment-of-data-analytics-techniques-for-insider-threat-programs/ for detailed discussion of analytics

Get updates on our latest work.

Each week, our researchers write about the latest in software engineering, cybersecurity and artificial intelligence. Sign up to get the latest post sent to your inbox the day it's published.

Subscribe Get our RSS feed