Blog :: Network Operations :: Security Operations

Best Practices in Network Forensics, Part II: Insider Threats

jake

In part 1 of our Best Practices in Network Forensics we discussed different integrations and how you can tie in your existing tools with our solution to correlate events with syslogs, DNS, IPAM, and cloud infrastructure logs. This blog will go a bit deeper on these integrations, but focus on tracking insider threats and lateral movements across the network.

Why should we care about insider threats?

I assume most of the people reading this are familiar with what an insider threat is. But to make sure everyone is on the same page, US-CERT defines an insider threat as follows:

“An insider threat is generally defined as a current or former employee, contractor, or other business partner who has or had authorized access to an organization’s network, system, or data and intentionally misused that access to negatively affect the confidentiality, integrity, or availability of the organization’s information or information systems.” – US CERT Combating the Insider Threat

I feel this homes in on the exact problem a lot of companies have; even someone with little technical knowledge or limited access on the network can still pose a huge problem. Since networks range in size and complexity, it can be very difficult to grasp exactly what current or former users are doing day to day.

Identifying potential threats

The first step in tracking down hosts that may be problematic is to look for any warning signs associated with their endpoints. We find a lot of success by implementing machine learning algorithms to inspect the network traffic at the perimeter and at the core. In our solution, these algorithms are designed to correlate events together so that if a host starts violating multiple policies or starts using unallowed applications, a notification is sent to the correct party or tool. Security teams often use our algorithms to better correlate events in their SIEM solution, which helps reduce false positives and adds context to other alarms that they might have already seen.

Indicator Correlation Event

Using our Indicator Correlation Event we can quickly drill in to find potential hosts that may (sometimes unknowingly) have become an insider threat.

Remediation of suspect host

From a single event we can usually pull a lot of information:

  • IP address of host
  • User that was logged in during the event
  • Timeframe of anomalous behavior
  • Suspicious behaviors seen
  • Have we seen any lateral movements?

We can also combine this with other data sources to see URLs, DNS queries, and applications used during this timeframe to help figure out not just whether they were an insider threat, but what they were after. Once you have gathered enough information, it will be up to your internal incident response plan on how you should proceed. A big benefit of collecting these types of telemetry data is the ability to go back in time to see how long this type of communication might have been happening!

Historical data analysis

Tracking insider threats

Now that you have a game plan on how you can use different types of telemetry data to proactively alarm on when insider threats may be running rampant on the network, it’s time to implement these systems! Feel free to reach out to our team if you want more information on anything I’ve spoken about.