SOC1 vs SOC2 – Cyber Threat Intelligence Guide

Security Operations Center (SOC), which I call SOC1, is a standard group of Analysts who analyze an incident/alert created from a security product. For a large organization with SIEM, it could most likely be an alert from their SIEM tool or an IPS/IDS system for a smaller organization. This could vary on the size of an organization. I have often seen organizations rendering 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 see how well a SOC would handle an incident created by a SIEM tool.

Other products could be part of a security infrastructure, like a DLP solution which I am not considering.

A SIEM is a centralized server that 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. When integrating a log source, the main objective should be “what use do I have with these captured logs” Otherwise, your SIEM will just be any other log-storing device.

Now that all the log sources are sending logs to SIEM, the SOC should have a 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 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, and network communications; basically, a behavioral analysis.
  • An Email Gateway solution should work as a suspicious email received by users a second before the 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, a URL established after clicking on the link, payload download, and encryption.
  • The 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 an average user to an admin sec or min or days before the actual infection (this usually will complement the analyst in finding the RCA)

SOC2

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 basic information, internal (could be logs from SIEM) or external (information for active campaigns), and retrieves actual intelligence from 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;

Source: Crowdstrike

A CTI lifecycle would contain the following items but not be limited to these,

  •  Planning – Plan the hunt
  • Collection – Gathering Raw Data
  • Analysis – Raw Data converted into Actionable Intelligence
  • Disseminate – Intelligence shared with different teams
  • Remediation – Remediation actions taken by the teams

For an effective CTI service, the following functions have 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.

What does the Threat Monitoring and Threat Hunting team look out for; they look for evil guys. This could be evil actors performing attacks worldwide and disgruntled internal employees (insider threat) performing attacks inside the organization. From an analyst perspective, these would be

Pyramid of Pain

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.

Let’s hunt!

List down all threat actors from China

  1. With that result, extract the threat actors who target banking organizations.
  2. With that result, you should receive at least 10 different groups and 30 different TTPs. With this information, you have narrowed down from 100 different TTPs to 30.
  3. Now that you have 10 different groups let’s hunt for common TTPs used for all the groups. (use 4 or 5)
  4. 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)

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.

You can follow us on Linkedin, Twitter, Facebook for daily Cybersecurity and hacking news updates.

Reeni B
Reeni B
She closely works with enterprises to help them find the right tool, thereby bridging the gap between technical needs and business goals to ensure successful product adoption.