Dealing with risks presented by internal users requires a different approach than those from external threats. This shouldn’t be news to anyone, but it does need to be said since it’s not something that always happens in practice. It’s not uncommon to see the cudgels common to blue teams wielded against internal users who run afoul of security. And frankly who can blame overworked security teams – dealing with internal folks is much more fraught with challenges. It’s far simpler to triage all risks with the same tools and techniques at our disposal for external threats. But it’s 2022 and time to strive for something better.
We must remain mindful of the perils of contacting users during an insider risk investigation. We must approach these interactions with tact, empathy, and caution. As Insider Risk Analysts, our goal is to seek understanding; to assemble a set of facts from disparate sources to generate a clear picture of an event.
To this end, I’m proposing a shift in the analyst’s mindset when handling risks presented by insiders. Below we’ll discuss how to conduct modern insider risk investigations – moving through the stages of inquiry, investigation, and determining outcomes.
Part I: Building the Haystack: Data Sourcing and Gathering Context
Insider Risk Management (IRM) programs are focused on protecting data. They aim to prevent leaks that are malicious, negligent and accidental. The starting place for just about every string of work in IRM is a piece of data. Perhaps it’s an alert from a security tool stating that a file was removed from an endpoint or a notification from a business partner that a user has put in their two-week notice. In order to be effective as an IRM investigator, we must assemble our data sources – the haystack from which we’ll attempt to find needles.
IRM differs from other domains of security in that the data sources which serve as inputs are as often people as they are tools. Below is a short list of common technical and non-technical data sources to consider as you build your particular haystack.
- Human Resources – notification of new hires, users who have access to Performance Improvement Plan
- Procurement – notification of newly on-boarded vendors or partners
- IT – administrative alerts and logging from various tools
- Email System – movement of data via attachments, particularly personal domains
- Removable Device Monitoring – movement of data to removable devices
- Cloud Storage – movement of data to cloud storage, particularly non-corporate/personal cloud destinations
In the event that a particular data movement made by a user piques your interest, it’s important to move into the inquiry phase to gather context, which will help you decide how to proceed. Start by assembling context through the Key Stakeholders and Technical Data Sources of your haystack. In addition, gather Human Context. For example, ask the user’s manager to provide context. Ask, “Is this event part of the subject’s day-to-day work?” “Did this event result from a specific request made by you?”
Part II: Having “The Chat”
Once you’ve gathered context during the inquiry phase, what you learn may signal it’s time to move on to the investigation. During this phase, there are several decisions to make, including what our goals are for an interaction (what are we hoping to learn from this interaction), the order of operations (who to speak with, and in what order), and finally how we’ll make contact (in-person meeting, phone call, chat message, etc.).
We must remain mindful of the perils of contacting users during an insider risk investigation. We must approach these interactions with tact, empathy, and caution. This not only protects the user from irreparable reputational damage in cases when the event is not quite as it may have seemed, but this will also help you in instances that are truly malicious. The order of operations and the tone is important. Improperly handling a coworker or friend of the subject could lead to the subject being made aware of your investigation before you are ready. I always attempt to bring as few people into an investigation as possible to get the necessary context. Even then, withholding certain details can help ensure your investigation isn’t compromised or publicized before it’s complete.
Part III: Documenting Inquiries or Investigations and Determining Outcomes
Once we’ve got our questions answered and we’re satisfied with our understanding of the event, we move on to the final phase of the investigation – documentation and next steps.
Logging an investigation: You should have a template for how investigations are documented, including what set you down the path of the investigation in the first place, what data you reviewed, actions you took, users you talked to and ultimately what was discovered and what was done to address risk.
Logging an inquiry: Per the progression above, not everything we look into warrants a full-blown investigation. If we begin to look into something, but ultimately discover that the activity was benign it’s still a good practice to document these interactions as Inquires.
Determining outcome: Following the completion of an investigation we will need to provide an outcome determination for the event in order to satisfy questions such as “Did the subject take this risky action deliberately?” and “Do they present an ongoing risk to my organization and data?” The course of action taken will depend on whether it’s determined that that event was malicious, negligent or accidental.
As Insider Risk Analysts, our goal is to seek understanding; to assemble a set of facts from disparate sources to generate a clear picture of an event. While technical sources provide invaluable data about an event, often it’s the human aspects of an event that require a conversation to fully understand.
