Skip to content
Blog

3 Steps to Conduct a Modern Insider Risk Investigation

As Insider Risk Analysts, our goal is always to seek understanding. We need to use past experience to filter out important information from a set of facts.

While technical sources provide invaluable data about an event, very often the human aspects of an event require conversations to fully understand.

When an analyst reaches outside of technical data sources to speak with someone, the line between business-as-usual crosses into a formal inquiry. These interactions with subjects, managers, data owners, executives or trusted partners are crucial to provide context as we attempt to understand what happened, why it happened and what the impact is.

How to conduct an Insider Risk Investigation

Step 1: Gathering context

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. We must assemble our data sources – the haystack from which we’ll attempt to find needles.

Insider Risk Management differs from other domains of security in that the data sources are as often people as they are tools.

Consider the following data sources as you build your particular haystack:

Image featuring 6 key stakeholders and their corresponding data points

Now that we have the data, we need to gather context to decide how to proceed. At this point, in addition to the Key Stakeholders and Technical Data Sources described above, we’ll add a third category: Human Context

Step 2: Having “The Chat” 

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 modern, hybrid workforce presents as many opportunities as it does challenges for these conversations, so it’s important to think through how to make contact. If we are careless in what we say to whom, we risk irreparable reputational damage to our subject.

Consider the following:

  • Goals for an interaction (what are we hoping to learn from the conversation)
  • Order of operations (who we’ll speak with, and in what order)
  • How we’ll make contact (in person meeting, phone call, chat message, etc.) 

Setting out specific goals ahead of any conversation will help keep things on track and ensure we get what we need to refine our risk determination while not wasting the subjects’ time. Order of operations helps avoid improper handling of a conversation with a coworker that could lead to the subject being made aware of your investigation before you are ready.

Step 3: Documentation and determining outcomes

Once we’ve gotten 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. 

Investigation logs

Throughout the investigation process it’s a good idea to keep key stakeholders apprised. At Code42, we notify a private slack channel at the outset of the investigation. This channel has representatives from Security, HR and Legal, and is a good way to allow these stakeholders to keep themselves informed as to the progress, ask any questions that may arise and provide comments on the ongoing investigation. 

Determining the 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?”. Try as we might, it’s near impossible for an IRM analyst to truly know someone’s intention – and that’s really what that determination is trying to capture – did this subject intend to cause harm by this action. 

Join us for part 3 where we’ll dig into the question of Automation in Insider Risk Management, including how to select a use case to automate, and how to be successful in your implementation.

You might also like: