What Is SIEM and SOAR Design? Security Definition

Imagine you work in a large office building with thousands of people coming and going every day. At the front door, there is a security guard who checks every badge. That guard is like your SIEM system: he watches everyone who enters, records their ID, and notes the time they came in.

If someone tries to enter without a badge, the guard writes down the incident and flags it. But the guard alone cannot do anything more than report what he sees. Now imagine that when the guard spots someone without a badge, he instantly calls a second security team that runs to the door, escorts the person out, and locks the door behind them.

That second team is like your SOAR system: it takes the alert from the guard and automatically takes action without waiting for a manager to approve. In cybersecurity, a SIEM gathers information from every computer, server, firewall, and cloud service. It reads logs and events like a guard reads badges.

It then shows all this information on a dashboard so security analysts can see if something is wrong. A SOAR system connects to that SIEM and, based on rules you set ahead of time, performs actions automatically. For example, if the SIEM sees a user typing the wrong password ten times in a minute, the SOAR can automatically disable that user account and send a notification to the IT team.

Designing these two systems together means deciding what logs to collect, how to organize them, what rules trigger automatic actions, and how to make sure the whole process does not accidentally block a legitimate user. It is like planning the entire security guard and response team system for a building, from the cameras at the door to the locked doors and the phone calls to the police. You need to think about what kinds of threats are most likely, how fast you need to respond, and what actions are safe to automate.

If you design it poorly, you might miss important alerts or accidentally lock out your own employees. If you design it well, you can stop a ransomware attack before it spreads, all without a human having to read every single log entry.

SIEM and SOAR design refers to the architecture and planning of two integrated security systems: Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR). A SIEM system performs real-time collection, normalization, correlation, and analysis of security event data from diverse sources including network devices, servers, endpoints, cloud platforms, and applications. It uses agents or API connectors to ingest log data, parse it into a common format (normalization), and apply correlation rules to identify suspicious patterns such as multiple failed logins followed by a successful login from an unusual geographic location. Common SIEM platforms include Microsoft Sentinel, Splunk, and IBM QRadar.

SOAR systems sit on top of the SIEM layer and provide automated response capabilities. They integrate with the SIEM through REST APIs or syslog feeds, receive incident alerts, and execute predefined playbooks. A playbook is a set of automated steps, such as querying threat intelligence databases, isolating a compromised endpoint via network access control, blocking an IP address at the firewall, or resetting a user's password. SOAR platforms like Microsoft Sentinel (which combines SIEM and SOAR), Palo Alto Cortex XSOAR, and Splunk SOAR also support case management, allowing analysts to track incidents from detection to resolution.

In practical implementation, SIEM and SOAR design involves several key technical decisions. First, data ingestion architecture must be planned: what log sources to collect, whether to use agent-based or agentless collection, how to handle high-volume logs like firewall traffic, and how to store data for compliance (e.g., retaining logs for 90 days or one year). Second, correlation rules and detection analytics must be written, tested, and tuned to reduce false positives. Third, SOAR playbooks must be designed for common incident types like phishing, ransomware, and insider threats. Playbooks can be fully automated (no human approval needed) or semi-automated (requiring analyst confirmation before critical actions).

Microsoft Sentinel is a cloud-native SIEM and SOAR solution that runs on Azure. It uses Log Analytics workspaces for data storage, Kusto Query Language (KQL) for queries, and Logic Apps for automation. When designing Sentinel, an architect must decide on data retention policies, workspace design (single vs. multiple workspaces), and integration with Microsoft 365 Defender and Azure Defender. The design must also consider cost, as data ingestion and retention in the cloud are billed per gigabyte. Finally, high availability and disaster recovery should be built in, often by replicating critical log data across multiple Azure regions.

SIEM and SOAR design matters in real IT work because modern organizations face an overwhelming volume of security alerts. A medium-sized company with 500 employees can generate millions of log entries per day from firewalls, email servers, cloud apps, and endpoint antivirus software. Without a SIEM, an analyst would have to manually check each log file, which is impossible. The SIEM automatically collects and correlates these logs, showing only the events that are likely to be real threats. This saves time and reduces the risk of missing an attack.

SOAR matters because even with a SIEM, analysts can be flooded with hundreds of alerts per day. Manually investigating each alert and taking action (like blocking an IP or disabling a user) can take 15 to 30 minutes per alert. With SOAR, many of these actions happen in seconds. For example, if a SIEM detects a known malware signature on a workstation, the SOAR can immediately isolate that workstation from the network, preventing the malware from spreading to other computers. This rapid response can stop a ransomware attack before it encrypts critical files.

In cloud environments like Microsoft Azure, SIEM and SOAR design is even more important because the attack surface is larger and more dynamic. Resources can be spun up and down quickly, and identities from any location can access data. A well-designed SIEM and SOAR solution helps security teams maintain visibility across hybrid and multi-cloud environments. It also supports compliance with regulations like GDPR, HIPAA, and PCI-DSS, which require organizations to monitor access, detect breaches, and respond within specified timeframes. For example, a healthcare provider might need to prove that they detected and responded to a data breach within 72 hours. A properly designed SIEM and SOAR system logs the detection time, the automated response actions taken, and the final resolution, providing auditable evidence for regulators.

In certification exams, especially SC-100 and SC-200, questions about SIEM and SOAR design appear in several familiar patterns. Scenario-based questions are the most common. The exam describes a company with specific requirements, and you must select the best design choice. For example, a question might describe a global organization with offices in Europe, Asia, and the Americas. The chief security officer wants to centralize security monitoring but also needs to comply with GDPR in Europe and local data residency laws in Asia. You are asked to recommend a Sentinel workspace design. The options might include one global workspace, three regional workspaces, or a workspace per country. The correct answer is usually regional workspaces to meet compliance requirements while still maintaining centralized visibility via cross-workspace queries.

Configuration questions ask you to identify the correct settings for a specific task. For instance, you might be asked: You need to create an analytics rule that detects when a user from an untrusted IP address signs into a sensitive application. Which Kusto Query Language (KQL) statement should you use? You would need to know how to filter for specific IP address ranges and correlate with user activity logs. Another common pattern is troubleshooting questions. These present a situation where a Sentinel playbook is not working as expected. For example, an automated response to block a user account fails. You must identify the likely cause: perhaps the playbook does not have the right permissions to modify Active Directory, or the Logic App connector is misconfigured.

Architecture questions test your understanding of how SIEM and SOAR fit into a broader security strategy. A question might ask: Which Microsoft security solution would you use to automatically respond to a detected ransomware outbreak by isolating affected endpoints? The answer would be Microsoft Sentinel's SOAR capabilities combined with Microsoft Defender for Endpoint. Some questions also focus on cost optimization. For example, you might be asked how to reduce data ingestion costs in Sentinel while still maintaining security monitoring for critical servers. The correct answer would involve using basic logs for low-sensitivity data sources and analytics logs for high-priority sources. Finally, licensing and feature comparison questions appear. You may need to distinguish between Microsoft Sentinel, Azure Sentinel (older name), and other SIEM vendors. The exam will expect you to know that Sentinel is cloud-native and has built-in SOAR capabilities, whereas traditional on-premises SIEMs require separate SOAR tools.

To design a SIEM and SOAR system effectively, you must first understand the security operations center (SOC) workflow. The SOC is a team of analysts who monitor and respond to security incidents. In a typical SOC, raw logs from across the enterprise flow into the SIEM. The SIEM parses, normalizes, and correlates this data. When a correlation rule triggers, it creates an alert, which is escalated to an incident if it meets certain criteria. The incident is manually reviewed by a Tier 1 analyst, who may gather more information and then decide to contain the threat or escalate to Tier 2. This manual process can take hours. By adding SOAR, many of these steps are automated, shrinking response time to minutes or seconds.

In practice, when configuring SOAR playbooks, you must define triggers. A trigger is the event that starts the playbook—it could be a new incident being created, a new alert being fired, or a specific condition like a high severity incident. Then you define actions: querying other data sources, sending notifications, creating tickets in a service management tool like ServiceNow, or executing remediation commands. For example, a playbook for a compromised user account might: 1) Trigger on an incident where a user account is detected as compromised by Azure AD Identity Protection. 2) Query Azure AD to get the user's manager name and email. 3) Send an email to the manager requesting confirmation of unusual activity. 4) If no response within 30 minutes, automatically disable the user account and reset the password. 5) Log all actions to a separate audit log.

What can go wrong? A common issue is that playbooks may fail to connect to external systems due to expired API keys or service outages. You must include error handling steps, like retry logic or fallback notifications. Another issue is that playbooks can get too complex, becoming difficult to debug. Keep playbooks focused on a single incident type, and use modular playbooks that can be reused. For example, a 'Block IP' playbook can be called by several other playbooks instead of rewriting the blocking logic each time.

From a broader perspective, SIEM and SOAR design is not just a technical task. It is part of a security strategy called defense in depth, where multiple layers of protection work together. The SIEM provides visibility, the SOAR provides speed, and human analysts provide judgment. A well-designed system balances automation with human oversight. For example, automated responses should never be allowed to lock out an entire company domain, because a single false positive could stop all employees from working. Always define a 'break glass' manual override process. Finally, as you study for the SC-100 exam, focus on understanding how Microsoft Sentinel fits into the Azure security ecosystem, especially its integration with Azure Lighthouse for multi-tenant management and Azure Policy for governance.