Security Operations Center (SOC) which I call here SOC1 is a standard group of Analysts who analyze an incident/alert created out of a security product. For a large organization with SIEM, it could most likely be an alert from their SIEM tool or from an IPS/IDS system for a smaller organization. This could vary upon the size of an organization. At times I have seen organizations rendering out their SOC services to a third-party vendor. Either way, the SOC team would analyze and work on the incident to identify its source and the reason behind the generation of that offense.
Let me take these products (most standard ones) in an environment and let’s see how well a SOC would handle an incident created from a SIEM tool.
There are other products as well which could be part of a security infrastructure like a DLP solution which I am not taking into account.
A SIEM is a centralized server which collects/receives logs from all other products in an organization depending on their prime use. It could be logs from networking devices, security products, databases and applications. These products are called log sources in SIEM terms. An efficient SIEM tool is how well the use-cases are written on it. Some organizations do not effectively utilize this tool. The main objective when integrating a log source should be “what use do I have with these captured logs” otherwise your SIEM will just be any other log storing device.
Now that we have all the log sources sending logs to SIEM, the SOC should have firsthand analysis of an incident.
Let’s take a use case; a very common one, a known ransomware infection. The SOC team would receive an alert from most of the products listed above.
- An antivirus product would alert you on the type of Ransomware based on Signature
- An EDR (and next gen AV) would alert you on malicious changes to Registry, services, network communications; basically a behavioral analysis
- An Email Gateway solution should work as a suspicious email that was received by users second before infection
- A proxy would alert you on a malicious URL the user visited which could have come in through an email the user received.
- An IDS device would alert you from a user getting a phishing email, URL established after clicking on the link, payload download and encryption.
- Firewall would alert you on communication initiated to/from a blacklisted range of IPAddress
- Active Directory could help with insights the attacker used to escalate from a normal user to an admin sec or min or days before the actual infection (this usually will complement the analyst in finding the RCA)
Now that we understand that most SOC operations are SOC1. So what is SOC2? I define SOC2 as a conjunction of SOC1 and Cyber Threat Intelligence. There are two scopes of intelligence, Open Intel and Dark Web Intel. Here we are going to discuss open intelligence.
Cyber Threat Intelligence (CTI) is a service that identifies raw information, internal (could be logs from SIEM) or external (information for active campaigns) and retrieves actual intelligence out of it. This intelligence will pay a long way for an organization when intelligence is actioned. Intelligence could be in the form of
- Open Source Intel (OSINT Tools)
- Human Intel (HUMINT)
- Social Media Intel
- Third party Intelligence – Licensed and free
There are three types of Intelligence. They are;
A CTI lifecycle would contain the following items but not limited to these,
- Planning – Plan the hunt
- Collection – Gathering Raw Data
- Analysis – Raw Data converted into Actionable Intelligence
- Disseminate – Intelligence shared to different teams
- Remediation – Remediation actions taken by the teams
For an effective CTI service, the following functions has to be in place for any organization
- Threat Monitoring – Proactive approach uses Intelligence from Intel Sources and sweeping the infrastructure for intrusions and placing blocks
- Threat Hunting (similar to Red Team) – Using threat information/intelligence to look for bad guys.
Now what does the Threat Monitoring and Threat Hunting team look out for; they look for evil or bad guys. This could be evil actors performing attacks around the world and internal disgruntled employees (insider threat) performing attacks inside the organization. From an analyst perspective, these would be
the stages of information he would receive and the difficulty in which they would receive it. At the lowest level, the easiest information that an intel analyst would receive is the Hash Values followed by the different indicators until the network artifacts. The last two become a bit harder to find and block. The tools and the TTP (Tactic, Technique and Procedures) used by the attacker. TTPs and Tools would most probably depend on a malware analyst or an Incident Responder with the information.
Finally with all the above information on hunt, TTP, threat actor, it would be narrowed down on the action that an analyst would take pertaining to an attack. Let’s take a use-case to narrow down a hunt. A Chinese ATP group targeting your organization. Let’s assume you are managing a banking security project. I am using the MITRE framework to devise this hunt. You could also use other methods to device this hunt. I have added my list of tools, framework and platform which could be useful to hunt.
List down all threat actors from China
- With that result, extract the threat actors who targets banking organization
- With that result you should receive at least 10 different groups and you should have at least 30 different TTPs. With this information, you have narrowed down from 100 different TTPs to 30.
- Now that you have 10 different groups, let’s hunt for common TTPs used for all the groups. (use 4 or 5)
- Now that we know the top 5 TTPs employed by the threat group. We should devise a strategy to device, monitor and block these actions.
Tools, Platforms and Frameworks
My view on tools, platform and framework that are most used to gather intelligence (not restricted to intelligence)
- YETI intel platform
- Kyle Hubert’s Threat intel tool – Aggregator
- Kibana with Elastic
Do not restrict yourself to just these tools. Again for a threat monitoring team they most often look for IOCs and TTPs. Here’s my list which you would find it useful
- APT Groups and Operation
- Qualified quality cyber intelligence
The SOC analyst will now have incidents created out of intelligence added to the system. Intelligence is always converted to a rule to monitor TTPs/Tools/IP/Hash/Domain and more. For example; when intelligence about a bad IP/hash is added to the SIEM rule and when a user has a communication established with that IP, we could track down the intelligence about a campaign, an actor or a threat group. This could very well pay off in the long term to identify intrusions which are due to hold access to a network for a longer time.