In a very distant past, security monitoring used to be a very simple activity. A single guy would grab logs from the firewall, the IDS and maybe an authentication system and looks for bad stuff, usually applying some scripts or slightly more sophisticated tools. It quickly evolved to log management and SIEM, where logsĀ from different technologies is aggregated and correlated in real time and presented to a team of analysts looking for potential security incidents. The challenge to do effective security monitoring was, for a long time, dealing with the increasing volume of events, false positive rates and additional log sources to consider.
With the increasing computational power and the adoption of data science concepts by security, researchers and start-ups have been creating many new tools to improve security monitoring. Some of those tools capture data directly from the network, while others get data from the SIEM or other centralized event repository to apply their different techniques. The interesting aspect about those technologies is that they are loosely coupled to SIEM systems (when connected at all). Organizations can leverage those tools even without a SIEM in place. In fact, many organizations are deploying these tools as a way to compensate forĀ their SIEM blind spots. AsĀ the tools don’t need to be integrated, they can also be operated independently.Ā There is no need to talk to theĀ SOC guys running the SIEM when deploying your cool new UEBAĀ (Gartner access required), NBA or NFT.
However, as any defense strategy, coordination of efforts is key to success. There are many real and cyber world examples of things being detected by a group just to beĀ forgotten in another group’s queue. Doing things in isolation is a recipe for disaster and that has been proven over and over again. Does that mean security systems must be implementedĀ and controlled by a single group, always acting as a new event source to the top-of-the-pyramid SIEM?
I don’t think so. Some of the new tools even require different skills to operate, so trying to keep everything under the same group may be too complex (maybe impossible?) to do. There might be some benefits of having separate monitoring groupsĀ looking for different threats or applying different methods. But there is something that can’t be left behind: Coordination.Ā Security Information has to flow between the groups doing security monitoring and suspicious activities mustĀ be reported to those in charge of incident investigation and response.
SecurityĀ information flow is just likeĀ working with threat intelligence; some organizations are pretty good on obtaining and usingĀ externally provided TI. With different security monitoring groups, each one of those must be prepared to consume and provide TI to its peers. It doesn’t have to be centralized, it can follow a federated model. Instead of everything operating like an event source for a SIEM, The groups could keep operating independently butĀ communicating through something like a Threat Intelligence Platform (TIP).
If security monitoring cannot be centralized and operated by the same team, think about using a federationĀ model. It works decently for law enforcement (in places where law enforcement works ;-)), it could also work for cyber security.