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

What is a SOC Use Case?

Companies are used to viewing SOC as a business unit — a team of cybersecurity specialists who are in charge of safeguarding your technical estate.

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.

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 — 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: build a repetitive process for detecting incidents and put down standardized response plans to various types of threats. The latter part includes investigation and mitigation done by SOC analysts, as well as automatic response scenarios for common issues with cloud-based SIEM/SOAR solutions.

How to Develop SOC Use Cases for Your Business

Source

Every use case (no matter the domain) goes through four lifecycle stages:

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

Below is an overview of the standard development process of a SOC use case Infopulse applies as part of our 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 have caused 15% of breaches over the past year, so we always recommend watching out for these issues.

That said: lower-level use cases will often nest within a higher-level use case. For example, if your goal is to minimize the risks of a data breach, lower-level SOC 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.

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 involve some degree of human error. Your 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, which lead to breaches. 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, a local SharePoint deployment is usually protected by the corporate firewall, but when transitioning to SharePoint Online, you will need 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.

Application: Vulnerability Management

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

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

The short answer — higher frequency is always better (i.e., every 3-6 months). On average, 80% of exploits are published 23 days before the official patch becomes available. 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

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

Download eBook

3 Standard Types of SOC Use Cases

Now that you understand the general mechanics of developing SOC use cases, let us look at several common SOC use case examples.

A good way to think of a use case is as a cyber-security control mechanism you employ for detecting anomalies on the following levels:

• Technical level
• Business logics level
• User behavior levels

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 cyber-criminals because the potential gains are high. By breaching an email server, for example, a hacker could get access to sensitive corporate documents and then demand ransomware by threatening disclosures. Or they can use your email server to send spam or phishing campaigns to other entities. Neither scenario is great for your business.  Likewise, database, file, or streaming server breaches can cause both operational downtime and reputational damages (not to mention compliance fines).

To identify such scenarios, your 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 come in handy for identifying complex threats.

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

Business Logic Use Cases

Hackers know plenty of ways to exploit the standard application business logic for personal gain. For example, abuse the referral bonus system or tamper 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.

More often than not, however, companies would like 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, you should implement IP monitoring to detect potentially malicious access and app usage attempts (and block them). Such rules can be specifically configured to your product type and industry. If you are a local community bank, primarily serving German consumers, multiple password reset requests coming from a Malawi IP address are a likely signal of intrusion.

Certain industries like finance and telecom also 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), as well as extra investment in SIEM/SOAR technologies.

Behavioral Use Cases

The last cohort of use cases should be centered around detecting anomalies in user and system behaviors. 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 doesn’t behave as intended. For example, it suddenly blocks traffic from a certain IP. Such anomalies can be a sign of 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) systems to automatically collect data about application usage patterns and alert your SOC team to anomalies.

Conclusions

At present, the average time to fix cybersecurity vulnerabilities sits at 205 days. The current frequency of attacks leaves unprotected businesses exposed to multiple risks. 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.