Insider threat
What does an insider threat program with user activity monitoring contain?
An insider threat program is the set of policies, people and technology an organization uses to deter, detect and respond to harm caused by people who already have authorized access. User activity monitoring is the technical part that watches how those people use systems. In the NIST SP 800-53 catalog the program is control PM-12, and much of the monitoring is built on the Audit and Accountability family. This article covers what a program contains, how monitoring is done responsibly, and how it connects to the requirements contractors already face.
What is an insider threat program?
An insider threat program is a formal capability to deter, detect and mitigate risk from people with authorized access, whether their actions are malicious, careless or the result of being manipulated by someone outside. NIST SP 800-53 control PM-12 calls for an insider threat program that includes a cross discipline insider threat incident handling team.
The word program matters. Technology alone is not a program. A working program has a senior official accountable for it, written policy, defined roles, legal review, a way to receive and assess concerns, a process for responding, and training that tells the workforce what to report and why.
What does a program contain?
A program contains governance, detection, response and awareness. Governance means a designated senior official, a charter, and policies reviewed by legal counsel and human resources. Detection means monitoring of user activity, plus channels for people to report concerns. Response means a team that can assess indicators, escalate, preserve evidence and refer matters.
Awareness means training the workforce to recognize and report potential indicators. NIST SP 800-53 addresses this in AT-2, and NIST SP 800-171 requirement 3.2.3 requires insider threat awareness for contractors handling CUI. The program also needs records management, because what it collects is sensitive and has to be protected, retained and disposed of under clear rules.
What is user activity monitoring?
User activity monitoring is the technical capability to observe, record and analyze what users do on systems, so that behavior suggesting misuse can be found. It can include logons and logoffs, privilege use, file access and movement, removable media use, printing, email and web activity, and in some settings screen capture or keystroke records.
Monitoring collects a great deal of data, so its value depends on analysis. Good programs define the indicators they are looking for, correlate activity across sources, tune out noise and route meaningful alerts to analysts who understand both the technology and the business context. Raw logs that nobody reviews do not reduce risk.
Which NIST SP 800-53 controls apply?
PM-12 establishes the program, and the Audit and Accountability family supplies much of the monitoring. AU-2 defines which events are logged, AU-3 sets what each record contains, AU-6 requires review, analysis and reporting, AU-9 protects the records, AU-11 covers retention and AU-12 covers generating the records. AU-13 addresses monitoring for information disclosure.
Other families contribute. AC-2 covers account management, including monitoring of atypical account use. AT-2 covers insider threat awareness training. PS covers personnel screening and termination. SI-4 covers system monitoring. A program that maps its activities to these controls can show auditors and authorizing officials exactly how it is built.
How do you monitor without overreaching?
You monitor within a documented legal and policy basis, collect only what the program needs, and limit who can see it. Users should be notified through banners and acceptable use policies that activity on organizational systems is monitored. Legal counsel and human resources should review what is collected and how it is used.
Access to monitoring data should be restricted to trained analysts and logged in its own right, because the monitoring system is itself a target for misuse. Privacy and civil liberties protections should be written into the program, along with clear rules on retention. A program that is perceived as surveillance without limits loses the trust it depends on.
What does a contractor need?
A contractor handling CUI needs at least insider threat awareness training under NIST SP 800-171 requirement 3.2.3, and the audit requirements in the AU family give it the logging to support investigation. Contractors working on systems for federal customers may be required by contract to support or operate a fuller program.
Contractors subject to the National Industrial Security Program Operating Manual, 32 CFR part 117, have explicit insider threat program requirements, including a designated senior official and workforce training. For other companies a proportionate program, scaled to the data they hold and the people who access it, is sensible practice even where it is not mandated.
How does an organization get started?
Start with governance and scope: name the accountable official, decide what the program protects, and get legal and human resources involved before any monitoring begins. Then inventory the logging that already exists, because most organizations collect more than they review.
Next, define a short list of indicators that matter for your data and people, such as bulk downloads before a resignation, access outside normal patterns or attempts to bypass controls. Build monitoring and review around those, train the workforce, and test the response process with a tabletop exercise. Expand from there as the program proves it can handle what it finds.
How do you measure whether the program works?
You measure it by whether concerns are raised, assessed and resolved in a consistent way, not by how much data is collected. Useful measures include how quickly a reported concern is triaged, how many alerts are reviewed against how many are generated, how often indicators lead to a confirmed issue, and whether training completion is current.
Test it the way you would test incident response. Run tabletop exercises built on realistic scenarios, such as a departing engineer copying design files, and check that the right people are notified, evidence is preserved and decisions are documented. Review the program at least annually with leadership, legal and human resources, and adjust the indicators as the business and the threats change.