If you are pretty new to the Security Operations Center, I recommend you to read my previous blog on SOC. It was tough to list down the most common and important SOC elements. I had to do a lot of research before publishing. It took me about a year to complete and finally, it's here.
Note: All the views here are my personal thoughts. Let me know if I went wrong somewhere :) This is not the ultimate guide or a standard to set up a SOC but this will serve as a “Get started guide”. Keep scrolling and keep reading!
Building a SOC may seem rather intimidating at first. You may be the only person in your entire company that is responsible for IT security. It may seem like out of place for you to build one.
From my previous blog, we saw that a balance in infrastructure and team will make an effective SOC, which stands true for any division apart from SOC.
Now zooming out for a second. Every SOC needs to have a goal and strategy that they need to have in order to ensure that they can serve the business needs. Every industry isn’t the same. Which means the functionality of a SOC will change. Once you have a defined strategy, now you need the components that will work together called the PPT.
- People
- Process
- Technology
People - SOC Teams
The SOC is a unified division with teams working at different levels to resolve an incident.
Tier 1 — Security Analysts (T1)
Security analysts or SOC analysts are the ones who will primarily use detection tools than response or forensic tools. They might depend on Threat Intelligence to verify low-level incidents and filter them if their analysis results don’t show any suspicious activity or behavior. Their responsibility is to review alerts from event management tools, check if it requires attention, verify, analyze, classify, escalate to the T2 team, and document all the details.
Tier 2 — Security Analysts (T2)
This team is usually referred to as the First Incident Responders. They review the tickets created by the T1 team and identify the scope, affected systems, and determine the recovery plans. This is the team that will use Asset discovery tools to help them identify the affected systems. In rare instances, this team might perform forensics as well depending on the type of security incident. And of course, document all findings!
Note: In case your security team is small, the tasks will be done by T1.
Tier 3 — Expert Security Analysts (T3)
The work of this team is to review the T1/T2 findings and act accordingly. Commonly called the Threat Hunters, they use data visualization and threat intelligence tools to understand and analyze the situation. Again documentation is important.
It is common that the team will also be called the CTI (Cyber Threat Intelligence). SOC is meant to be proactive than reactive. Reactive teams are more similar to Incident Responders, which has an indirect connection to the SOC.
Tier 4 — SOC Engineers (T4)
SOC engineers are responsible for building, maintaining, recommending new tools, and updating systems. They help in building SOC architecture, systems and work with other teams to ensure that systems are up to date and they also document requirements, procedures, and protocols to ensure that other users have the right resources.
Tier 5 — SOC manager (T5)
The manager is the one who leads and takes important decisions for the team. A SOC manager needs to be technically sound and also be able to manage the team effortlessly. He should possess good leadership and communication skills. A SOC manager is not the same as a CISO (Chief Information Security Officer). He is the one who will supervise and guide the different teams inside SOC in the right direction and also runs compliance reports, measure SOC performance, and communicates with the CISO (Chief Information Security Officer) and other stakeholders. He is the immediate person responsible for any actions taken for an incident.
Process - SOC Processes
After seeing the various teams for a conventional SOC, we’ll look at the various processes that each team will handle. To get a better understanding and to make things modular, we’ll be breaking down the processes into 5 stages. Each of the stages is unique sub-processes.
Stage 1 — Event classification
This is the most important stage as classifying events help identify an event as a potential threat from regular network traffic. So how is it classified? This work is carried out by T1/T2 analysts. Generally, events may be classified based on priority levels ranked as low, medium, high, and sometimes even critical/urgent. This stage also is known as incident triaging.
Low Priority Events
These events include probing or reconnaissance and similar surface activities. T1 analyzes these events to check for Indicator Of Compromise (IOC) and attempts to block or prevent potential attacks if they suspect the event to be dangerous.
- Medium Priority Events
All attempts and successful exploitation or backdoor installation and similar incidents fall under this category. T1 verifies if the attack has happened and escalates to T2 with the necessary details.
- High Priority Events
If the attack has compromised systems or data, it falls under high priority and T1 escalates incident to T2 and they might take it to T3 with all necessary details for further analysis.
- Urgent Priority Events
In case of any data leak, loss, theft, or any severe damage or damage-causing incidents will be prioritized as urgent. With all defenses in place, this is a very rare scenario. But teams should be prepared for it.
Stage 2 — Event Analysis
Each of the classified events is investigated by T1 before escalating the ticket to T2. Based on the priority level, T2 will work on examining if any systems or users are affected and check for behavioral indicators often called Indicators Of Attack (IOA).
Today SOC cannot rely on Indicators of Compromise alone to triage an event.
Stage 3 — Event Response
Based on all documents and reports from T2, T3 will now perform the remediation actions. They suggest preventive measures that need to be taken to prevent damage.
Stage 4 — Audit
Periodical Assessment, proactive and defensive measures based on Threat Intelligence and SIEM data. Such an audit can often help the teams evaluate their performance. These audits will either be done by someone from T4/T5 or even by security teams that work outside the SOC.
IOCs are small chunks of information like log data that help in forensic investigation to identify an attack or any threat activity. Things like IP, domain and other report level indicators are called IOCs.
IOAs are reflection of the attack steps. T2 identifies them by looking at the system and network logs for attack patterns. These are behavioural indicators and very commonly referred to as Tactics, Techniques, Procedures (TTP)
Technology - SOC Tools
This is an explorer’s paradise. Each SOC needs to decide what tools they need based on their function inside an organization. But there are some fundamental tools to be in place.
SIEM - Security Incident and Event Management
Very important. You will need a tool that you can use to set rules to send alerts based on finding certain patterns in the logs. A SIEM can be used to look into various log sources by having sensors in the log systems. Based on rules you can set alerts. A lot of vendors provide SIEM solutions that work very well with a lot of tools. Being able to integrate with a lot of tools is very good. This helps integrate organization-specific tools.
Ticketing System
A ticketing system is the heart of SOC as everything an analyst gets is a ticket. They work on tickets and update all the details there. There are numerous ones available on the market. The fundamental things that need to be present are Priority settings, Agent management, SLA (Service Level Agreement ) management are basic things to look for in ticketing software.
Incident Management System (IMS)
An IMS has a direct connection with the ticketing platform. Analysts at higher levels (T2/T3) would prefer something like this to have better visualizations and understand an incident. IMS which can map attacks to similar ones and also provides decision support are really overrated but trust me it is going to be a sweet hub in SOC.
Threat Intelligence (TI)
Not just blocklists. A TI platform generally will be a collection of all attacks that happened and most of them will just present with IP addresses, domains, file hashes with supporting information for them. I would call a TI to be good when they attribute every indicator to a campaign or a group and present information about every activity that they have done. The reason behind this is, things like IP and domains keep changing very often. An attacker will not use the same IP over and over again. This means a TI should somehow tell a story about an attacker so that a team can make better decisions and block attacks very early.
I will talk about Threat Intelligence separately in another blog. It is another broad topic in Security Operations.
Data aggregator
Most of the teams might not have such a system in place. A data aggregator will act as a central repository to look at various logs. An analyst can look at logs at any point in time. This helps in making correlations either manually or via the SIEM or it will help in incident analysis.
What else? As I said depending on what the organization does, the SOC goals also change. Which means the tools are not limited to what is above. Consider organizations that have a lot of networks and complex infrastructure and IoT systems. Their SOC will have a different scope. Or for a software vendor, SOC might have to handle vulnerability management.
The goals and strategy will differ, meaning that there will be some groundwork to be done before getting your hands dirty.
With that being said, its time to say goodbye for now! 😉
PS: If you feel I have missed out on something, please do comment on them below. It will help me as well as others who read this story!
