SOC Use Cases: How to Define and Implement Optimal Cyber-Response Scenarios

What is a SOC Use Case?

Companies are used to viewing the SOC as a business unit — a team of cybersecurity specialists, mostly managers, engineers, analysts, and threat hunters, in charge of safeguarding technical estate, focusing on prevention, detection, and the mitigation of risks.

Operationally, however, SOC is also a business process. As such, it consists of various modeling elements (components) — standard activities, information links, policies, rules, and tools. Among them are  SOAR (security, orchestration, automation, & response) and SIEM (security information and event management), UBA (user behavior analytics), XDR (extended detection and response) tools and many more.

In the above sense, SOC is a set of scenarios and pattern identification activities for detecting anomalies, attack attempts, vulnerabilities, zero-day exploits, and other cyber-risk factors and then applying mitigation methods.

SOC use case development is a formalized mechanism for the selection and implementation of scenarios of cybersecurity incident detection rules, tools, and response measures.

The end goal of SOC use cases is to build a repetitive process for detecting incidents and develop standardized response plans to various threats. The latter part includes investigation and mitigation by SOC analysts, as well as automatic response scenarios for common issues with cloud-based SIEM/SOAR solutions.

3 Standard Types of SOC Use Cases

Now that we have discussed the gist of SOC, let’s closely examine the most common SOC use cases on the following levels:

• Technical level
• Business logics level
• User behavior level

Technical Use Cases

Most vulnerabilities emerge on the IT infrastructure level — networking, data management, servers, system integrations, and operating systems.

Hackers are well-familiar with various technical components (since many are universally used) and can therefore plan attacks using known vulnerability exploits. For example, a misconfigured firewall can have default policies enabled, which makes intrusion relatively easy to orchestrate.

Web servers are another attractive target for cybercriminals. By breaching an email server, for example, a hacker could gain access to sensitive corporate data and then demand ransom by threatening disclosures. They can also use email servers to send spam or phishing campaigns to other entities and gain data ransom. Likewise, database, file, or streaming server breaches can cause operational downtime and reputational damages, as well as compliance fines.

To identify such scenarios, the SOC team needs an established process for collecting security telemetry data paired with proactive mechanisms for preventing intrusion. For example, web application firewall (WAF) log data can help identify complex threats. At this level, the security team can also implement endpoint solutions to secure corporate devices, conduct penetration testing, or deploy IDPS or network intrusion detection and prevention systems.

Using IDPS systems, SOC experts collect data from various sources, including firewalls, routers, servers, and endpoints, to identify potential threats, such as viruses and malware, and prevent security breaches. Overall, the purpose of IDPS is to prevent unauthorized access, data theft, and other malicious activities on the network of an organization

However, analysts can quickly be overwhelmed by the sheer complexity of the architectures they must use to respond to security incidents, which can be hundreds of thousands per day. In this case, SIEM or Security Information and Event Management tools are designed to reduce the load of SOC analysts.

SIEM relies on data analytics to identify the most possible threats by combining information from multiple sources. As a result, security operations analysts can concentrate on the events most likely to turn into actual attacks on their systems.

At this stage, the goal of SOC analysts is to create and implement various analytics rules for detecting use cases at the infrastructure level. Then, they respond to identified anomalies based on standard SOC practices.

Business Logic Use Cases

Hackers know many ways to exploit the standard application business logic for personal gain, like abusing the referral bonus system or tampering with the application’s access control list (ACL) for privilege escalation. In both scenarios, the attack becomes possible because of the underlying application design. The optimal approach to minimizing risks due to business logic flaws is implementing security by design. This means involving cybersecurity specialists during the product development stage to codify relevant security controls into the product. That is what the DevSecOps process assumes. Moreover, to cover all security use cases, DevSecOps practices must be integrated with the specific needs and requirements of other applications used within the organization.

Companies often want to secure existing custom software. In this case, the best course of action is to map app-specific anomaly types and attack patterns. Then create rules for identifying signals for the mapped risks. In some cases, such monitoring may require extra security technology investments.

Separately, IP monitoring should be implemented to detect potentially malicious access and app usage attempts. Such rules can be configured to a specific product type and industry. For example, local community bank, primarily serving German consumers, may catch a signal of intrusion getting multiple passwords reset requests from a Malawi IP address.

Certain industries, like finance and telecom, often include fraud detection scenarios in SOC use cases. For example, a telecom provider might want to prevent tampering with the distribution of loyalty bonuses. Fraud scenarios are more challenging to implement as they assume both advanced rule development (with dynamic, context-based exclusions) and extra investment in SIEM/SOAR technologies.

SOAR, which stands for Security Orchestration, Automation, and Response software, empowers SOC specialists to integrate and coordinate disparate security tools, automate repetitive tasks, and streamline incident and threat response workflows by providing a centralized console. This console also enables SOCs to consolidate and manage all security alerts in one central location.

Behavioral Use Cases

The last cohort of security use cases is centered around detecting anomalies in user and system behaviors. Examples of anomalies in user behaviors may include a sudden spike in sent traffic from a certain user ID or multiple password-reset attempts from an unknown IP address. These are likely indicators of a potential intrusion attempt.

Anomalies in system behavior are closely related to infrastructure-related use cases — instances when a certain system does not behave as intended, like a the sudden blockage of traffic from a certain IP. Such anomalies can indicate a breach attempt, persisting glitch, or previous tampering.

To cover behavior-related use cases, it may be worth investing in user and entity behavior analysis (UEBA) solutions. UEBA uses behavioral analytics, ML algorithms, and automation to identify harmful user and device behavior. With UEBA, SOC specialists can get better insight into security and enhance zero-trust security programs. All these systems automatically collect data about application usage patterns and alert the SOC team to anomalies.

How to Develop SOC Use Cases for Your Business

Every SOC use case, regardless of the domain, goes through five lifecycle stages:

• Design
• Development
• Implementation
• Application
• Fine-tuning

Source

Below is an overview of the standard development process Infopulse applies as part of its  SOC services.

Design: On-Table Assessment and Threat Modeling

To create a cyber-defense strategy, you first need to understand what you are protecting yourself against. An on-table security assessment is an audit of your current security posture, paired with a baseline assessment of business risks your company faces.

High-level business threats include:

• Risk of data breach/data loss
• Direct hacker attacks and exploits
• Insider attacks or data leakage.

On the lower level, the above risks translate to specific attack vectors and breach scenarios, applicable to your IT infrastructure. For example, legacy servers are often prone to remote code execution (RCE) attacks because of old operating system versions or delayed patching.

Similarly, if you have recently migrated to the cloud, your current configurations may not offer full asset security. In fact, cloud misconfigurations cost USD 4.5 million in 2023, with a 15% increase over the last three years, so it’s always recommended to watch out for these issues.

That said, lower-level use cases will often nest within a higher-level use case. For example, if the company’s goal is to minimize the risks of a data breach, lower-level SOC use cases will include “detection of unauthorized activity on servers,” “server-side injection (SSI) detection and prevention,” and “server scanning for suspicious data exports.”

The definition of lower-level SOC cases is also called threat modeling. Cybersecurity analysts identify all possible attack attempts and vulnerabilities your business might be exposed to.

Development: Vulnerability Scanning

Once you have determined the scope of the required protection, it is time to map and assess all the IT assets your company has. Your goal here is to create an inventory of all network endpoints, local and cloud-based servers, and other “entry points” to your IT systems such as corporate emails, application log-in forms, etc.

At Infopulse, our cybersecurity team usually maps all unprotected endpoints first to indicate the “weak links” in your baseline. Then we perform an in-depth vulnerability scan across local and cloud environments to identify vulnerabilities in specific systems. For example, flag apps with subpar security controls, firewall misconfigurations for hybrid cloud infrastructure, and other IT administration goofs.

Based on the vulnerability assessment, we then develop specific rules for:

• Exploitation attempts detection (e.g., responding to different types of malware)
• Future mitigation steps (to prevent the reoccurrence of vulnerabilities)

Then we formalize these into specific SOC threat monitoring practices and incident response playbooks. 

Implementation: Mitigate Threats and Eliminate Causes

Based on the data from your vulnerability scans, it is easy to identify where common risks emerge and why they persist.

In most cases, vulnerabilities have either of the following root causes:

• Human error – 82% of data breaches occur due to human error. Thus, SOC use cases should be designed to minimize the impact of individual user actions on corporate security. For example, implementing a strong password security policy and 2FA can minimize the risks of brute-force attacks.
• Inadequate IT administration — haphazard adoption of remote work tools during the pandemic, poor network security decisions, and oversight in firewall configurations are common system administration issues that lead to breaches. Companies can fix subpar controls and issue new policies to prevent their reoccurrence.
• Lift and shift migration to the cloud — some companies simply do not consider the new security implications when moving on-premises assets or local applications to the cloud. For example, the corporate firewall usually protects a local SharePoint deployment. Still, when transitioning to SharePoint Online, there will be a need for cloud-specific access management (AM) controls and security configurations.

Overall, the root causes for various vulnerabilities are aplenty. Your goal is to address them proactively with new cybersecurity policies and extra security tools.

Case Study

Explore

Establishing a Security Operations Center for a Swiss Manufacturer

Application: Vulnerability Management

Vulnerability management is an ongoing process. Given that organizations worldwide now face an average of 1,158 attacks per week, running regular assessments is cheaper than dealing with an attack.

A common question we get is how often your company should perform vulnerability scanning.

The more frequent, the better (i.e., every 3-6 months). If you operate in a sensitive industry such as finance, you may be subject to extra regulations. For instance, to maintain PCI DSS compliance, payment vendors must perform in-depth vulnerability assessments each quarter and do security testing (pen testing) every six months.

Cloud-based SOAR solutions like Microsoft Sentinel now allow companies of any size to implement automatic threat monitoring and vulnerability detection. Automation of standard security workflows allows SOC teams to focus on more value-oriented tasks such as proactive threat hunting and risk mitigation.

eBook

Download eBook

Learn how to build a high-performing SOC function from our free eBook

Conclusion

SOC adoption used to be “reserved” for larger organizations with multi-million security budgets. However, that is no longer the case today.

Competitive SOC service models such as SOC as a Service and managed SOC, paired with advanced SOAR solutions like Azure Sentinel, make this function more accessible to businesses of different sizes and industries. Moreover, you can always start with a “test-run” of SOC use cases and progressively expand coverage to new business systems as your risk radar evolves.