Analyst's Problems as a Service (APaaS)

There are many blogs and industry experts who have discussed issues of a SIEM, how it can fail, and what it is lacking. I'm worked and am working in a SOC, so I understand most of the issues. One thing I see very rarely are discussions on how it will affect an analyst to perform their job. SOC is an analyst's den and its success and failure depend on them and the management. 

I have created a three-part series to discuss some of the issues an analyst face if the SIEM architecture is not planned and designed properly. For the sake of length and readability, I have divided this blog into three parts: Sections: "The usual" and "Architectural" will be discussed in the first blog,  "Augmentation" and "Alerts" will be discussed in the second blog. After seeing some of the problems we as an analyst's face at the above-mentioned levels, the third and final blog, will discuss the things we as an analyst can/may do to help ourselves.

Though we will not go into technical details of every component, rather a mixture of both technical and non-technical reasons.

 The usual:

    In this blog, we will see how an analyst's work is spiked by some of the industry problems like analyst's burnout and less efficient/skilled staff.

Architectural:

     There are many moving parts in a SIEM like data shippers, aggregators, queuing technologies, storage systems, and alert engines at a minimum. We will discuss the components and how it will thwart an analyst's workflow if they are not designed properly. 

Logs:

SIEM is full of logs. The main purpose of SIEM is to gather all the logs and view them from a single pane of glass. Several questions arise when it comes to logs like what are the important ones to collect, how to collect them, where to find them, and such. Though we will not go into details saying "here is how you and where to collect them", we will see why these questions are important to ask and how an analyst's work can become cumbersome if they are not being properly addressed.

Alerts:

An analyst spends a significant amount of time in this area of the SIEM. As the list of the products which generate logs and alerts increase, the demand for context around them also increase. If the SIEM is not designed to contextualize alerts and only gather them from these point products, an analyst will face several issues in their triage process.  

What an analyst can/may do:

This is is the final part of the blog series where we will discuss the things analysts can do within their power or at least suggest things to the people who control the component. The whole concept of this blog is "Don't make an analyst work for the SIEM instead let the SIEM work for an analyst "  (sorry Justin Henderson, I stole your quote).

I hope you enjoy this three-part series. I have done a webinar about this one too, if you are interested.  Feedback and your thoughts are much appreciated and encouraged.