SBN

Day In the Life: SOC Analyst

Day In the Life: SOC Analyst

By Tom Dixon, Security Engineer

 

Time.

I heard someone once say that time is the great equalizer. No matter how rich or wealthy you are, how smart or talented you are, or how important you are, you only have the same 24 hours in the day that everyone else has.

I learned this lesson first-hand working in a 24×7 SOC as a part of a Cyber Incident Response Team (CIRT) in the British Military. As a security operations center (SOC) analyst, I had access to first-class defense and detection tools that I would sit in front of, day after day, and monitor hundreds if not thousands of alerts coming from hundreds of physical IDS appliances deployed all over the world.

Alerts, on top of alerts, on top of alerts. Over time my skills grew such that I could prioritize alerts and establish a baseline of normality. But even as proficient as I had become with using the top-of-the-line intrusion detection systems (IDS) platforms of the era, there was seemingly never enough time to get through all of the alerts.

When I look back, I can see a few reasons why I was always playing catch-up on detections. 

The first reason was the vanilla signatures that were used in the IDS engine. Without the ability to add criticality and context to my devices, all devices were considered equal. This meant the same detection firing against a domain controller held the same priority as a workstation. 

That same missing context slowed me down again when trying to clear my alert queue. Too many times I needed additional details which were crucial in helping me understand the true level of concern for detection and then being able to answer questions like:

  • Where was the system globally located? 
  • Who was the network administrator? 
  • Who was the asset owner? 
  • Who was the user? 
  • What was the device? 
  • Was it deployed in an operational theater? 
  • Was it a senior member of staff? 

This missing information caused me to perform a swivel-chair analysis, basically jumping from one tool to the next. Sometimes, I’d even have to walk across the building to talk to another team. I’d have to go to my configuration management database (CMDB) to find asset types, criticality, and owners, DHCP to find the machine name, and possibly even look at authentication to find an end user or owner to contact. To say this was frustrating and time-consuming is an understatement. I would finally clear one detection and 10 new ones were already in the queue. 

Thankfully today, time is no longer my constraint. Rather than continuing down the hardware-based, packet-focused IDS route, the tools I’ve moved to utilize flow from every crevice of my network. My data centers, remote sites, and my multi-cloud all support flow and I have them ingested into a SaaS portal. No more worrying about upgrading hardware or editing the same rule 50 times on 50 different pieces of hardware! 

Most important though is my ability to ingest context into this same portal. This contextual awareness can be third-party information, such as geolocation information and autonomous system information, as well as first-party context, such as high-fidelity details from my endpoint detection and response (EDR) and my CMDB. These details help me quickly identify who is using an IP, who the asset owner is, the type of device it is and even exactly where it is in the world, down to the desk the device is sitting on. 

Not only does this context assist me in quickly identifying the who, what, when, where, and how, upon a detection entering my queue, but it also allows me to write my detection models with this context in mind. Using IoT context, I can now tune down my IP phone network and create specific detections if those phones perform a behavior outside of their expected traffic patterns. Or I can quickly flag traffic to or from areas of the globe that I don’t expect traffic to normally traverse. Lastly, I can normalize services such as DNS and Active Directory and create policy-based detections when workstations bypass the services set up for them. 

The context is the key, and if time is the great equalizer, I feel like I just got an extra six hours back each day. I may run out of excuses for that exercise I’ve been putting off!

The post Day In the Life: SOC Analyst appeared first on Netography.

*** This is a Security Bloggers Network syndicated blog from Netography authored by Tom Dixon. Read the original post at: https://netography.com/day-in-the-life-soc-analyst/

Secure Guardrails