This blog is part 3 of a 4 blog series on Measuring and Optimizing Enterprise Security Search Costs. See Part 1 and Part 2.

To manually piece together information from multiple sources is a complex and error prone task for security analysts. In our previous blog, we discussed how to calculate Analysts’ Searches per Investigation (ASPI), and determined that high ASPI increases costs while reducing efficiency. Not only is there an opportunity to reduce the drudgery in the current process, but to also reduce licensing and infrastructure costs. Our goal is to reduce ASPI, increasing efficiency and reducing overall costs. 

Open Federated Search for Security provides one search bar to search all of your systems simultaneously without managing multiple syntaxes and platforms. Open Federated Search for Security directly addresses the above multiple searching and pivoting problem by:

  • letting analysts run parallel searches across all their platforms, and 
  • automatically running follow-up searches that walk up the chain of investigated entities.

For understanding Open Federated Search for Security further and testing a suitable solution, please refer to:

Calculating ASPI

To continue the example referenced in our last blog where an email attachment triggered a suspicious malware alert, a single federated search across all sources would have produced:

  • the threat intelligence information on that file, 
  • the users the file was emailed to, 
  • the devices that have had the file,
  • an entity graph, i.e. the linked entities of interest (File, User, Device)

A reminder of our formula for determining ASPI:

ASPI = L x M x N x p, where:

  • L is average number of entity pivots
  • M is average number of consoles
  • N is average number of data sources within a console
  • p is the percentage of possible paths that analysts decide to follow

The result without using Open Federated Search for Security is an ASPI of 24, where:

  • L: 3 entity pivots
  • M: 3-5 consoles
  • N: 3-5 data sources within a console
  • p: 25-75% of searches considered relevant and performed

Reducing ASPI

In simple investigation scenarios, using federated search results in an ASPI of 1, i.e., not needing further pivots, because: 

  • L = 1 (entity information is pulled upfront)
  • M = 1 (selected console platforms’ APIs are reached directly)
  • N = 1 (data sources of interest get queried in original search)
  • p  = 1 (relevant paths are visualized in original search)

For a more complex investigation, like the malware investigation example above, further pivots would still be needed even when using federated search. Let’s try to estimate those:

  • L = 2 entity pivots (since the federated search automatically did the entity lookups and the relevant follow up searches upfront)
  • M = 1 single federated search console
  • N = 2-4 searches across all data sources from the federated search console
  • p = 75% of federated searches considered relevant and performed

The ASPI for the above malware investigation example comes down to  2 x 1 x 3 x 0.75 = ~5 different open federated search operations to complete the investigation. Compared to the previous ASPI of 24, Open Federated Search for Security is approximately five times more efficient for analysts in our malware investigation use-case.

Getting the analyst efficiency is great, but at what cost?

Next Week: Reducing/Optimizing Data Centralization Costs