Best Practice for Insider Threat Investigations

[qcj3]

Does anyone have a best practice or workflow suggestion on using the SecOps module for Insider Threat investigations?  One requirement is making sure that the scope of knowledge is limited to just one group in the SOC.  Therefore, VM and IR teams are not aware of an investigation and the SITs attached to it.  Also, is SIR the right approach since this isn't really an incident yet?

[Chris McDevitt · Accepted solution]

SIR is the perfect place for this. First, you can think of the beginning states as "Security Incident Candidates" that need to be investigated. Also, you could add a field "Is Incident" if you need that level of definition.   

It is very easy to limit who can see an internal investigation, just use Tags.

1. Create a new role and assign it only to the Team that does internal investigations.

2. Create a new Tag for this team and assign the role to the Read and Write User Access. (And Enforce Restricted Access Check box and of course, do this in the Security Incident Scope)

3. Simply Tag the Security Incident with this Tag and it is locked down!

Please mark this is Correct or Helpful so others can benefit from our conversation. 

[qcj3]

Chris,

Does the security tagging method also secure the SITs that are spun off of the tagged SIR?  A method that our 3rd party uses doesn't extend beyond the SIR.  If we need to send an SIT over to the Exchange team to pull emails then the whole SOC can see the SIT's content.  This is troublesome if the person being investigated is someone in the SOC.

[Chris McDevitt]

No, it does not OOB set the tag on the SIT.

1. You Could Tag Rules to Set a NEW (not the same one) Tag on the SIT. (or Manually set it)

2. Business Rule...

Tags on SIT

1. You would need  New Tag with a new Role that allowed only the team doing the work access and not the SOC.

2. Craft a NEW ACL that only allowed the assigned to Person or Team to see that 

[andy_ojha]

Hey there - as Chris mentioned, using the Security Tags is one approach you could take to achieve the lockdown component of this.

It's common for security teams to want to specifically track the volume of "Insider Threat" investigations they are performing over time and reporting on the results of these activities - especially if they are receiving an increasing amount of these escalations - e.g. "Volume of insider threat investigations closed as false positive from HR / Legal in the past XYZ days"....

Framing these escalations within on-going reporting will help signal whether or not the SOC's service is being utilized for appropriate "Insider Investigations".

You may want to consider introducing an appropriate Category and / or Sub-Category choice on the SIR form - such that Analyst's would easily be able to select and classify the SIR record as "Insider Investigations". 

Then you could introduce some reporting around this as time goes on, and track the SIRs classified as "Insider Investigations" plotted by "Close Codes" (e.g. False Positive, etc).  You might even also want to include the source or team that initiated the "Insider Investigations", so that you can track over time which initiating team is not leveraging the SOC's service appropriately and address that with enablement / training.

You could also look to leveraging certain Runbooks (KB Articles) that an analyst could refer to, when handling "Insider Threat" investigations.

If there are always certain steps / processes that the analyst should follow - you could look at introducing a specific workflow that establishes these steps or questions in a sequential flow.  You likely would also want to make sure you have a way of locking down the Security Response Tasks (setting values on response task records, ACLs based on conditions / values / roles, etc).

You mention locking down access to the record from certain groups in the SOC; assuming a breakout of Tier1, Tier2, Forensics, Leadership / Mgmt...   

You could investigate locking down the entire record via Tags as Chris mentioned, or using ACLs based around conditions and specific roles (e.g. Category = Insider Threat).

You could also investigate introducing a new tab / form section to the SIR record, and introducing "Insider Threat" related fields onto this section.  You could make this section hidden or shown based on conditions on the SIR Form and also further lockdown the fields on this section via ACL with roles / conditions (e.g. Category = Insider Investigations).