Insider Threat Blog

InTP Series: The Insider Threat Framework (Part 16 of 18)

The single most important aspect of developing a successful insider threat program (InTP) framework is a clear vision. Therefore, it is imperative that you define your vision in a concept of operations document or charter.

Hi, this is Jason W. Clark, Ph.D, an insider threat researcher with the CERT Insider Threat Center. In this blog post, I will briefly describe and define an InTP framework document.

A framework document must clearly articulate the InTP mission and scope, including the following:

Types of assets to be protected

Consideration of classified versus unclassified systems

Consideration of malicious versus unintentional acts

Types of insider threat incidents to be reported

Triggers for various types of incidents

It is crucial that this framework document clearly describes where the InTP will reside in the organization. Furthermore, there must be management buy-in and the hierarchy, functions, and operations must be well-established before implementation.

One of the primary reasons that InTPs fail is due to weak or missing relationships between the InTP and other parts of the organization (both internal and external). Additionally, all roles, responsibilities, and authority of the various components and stakeholders must be dispersed according to the mission and objectives of the InTP prior to implementation.

The graphic on the right shows the elements of an effective InTP and how the four areas are interconnected.

One common theme in mature InTPs we've encountered is consistency. This theme is especially relevant when determining priorities, severity, and escalation criteria.

There are various ways to structure an InTP, so it is imperative that an organization determine what works best for its environment and culture. Lastly, remember that an InTP mission must support the organization's goals and objectives.

We want to hear your feedback on this topic. If you have questions or want to share experiences you've had with your InTP, contact us.

SEI LIBRARY

LATEST POST

According to DevSecOps: Early, Everywhere, at Scale, a survey published by Sonatype, "Mature DevOps organizations are able to perform automated security analysis on each phase (design, develop, test) more often than non-DevOps organizations." Since DevOps enables strong collaboration and automation of the process and enforces traceability, mature DevOps organizations are more likely to perform automated security analysis than non DevOps organizations. My previous blog post, Microcosm: A Secure DevOps Pipeline as Code, helped address the problem that most organizations do not have a complete deployment pipeline in place (and are therefore not considered to be DevOps mature) by automating penetration tests of software applications and generating HTML reports as part of the build process through the Jenkins CI service. In this follow-up blog post, I explore the use of a service evolution of Microcosm as a simple one-stop shop for anyone interested in learning how to implement a DevSecOps pipeline.