SIEM and SOAR Security Service

What Are SIEM and SOAR?

SIEM – Security Information and Event Management and SOAR – Security Orchestration, Automation and Response are the two most important components of modern cyber security operations.

SIEM collects the security logs coming from an organisation's different systems centrally, analyses them, and helps detect security events through correlation rules.

SOAR aims to automate the response processes carried out against detected security events, to make different security products work together, and to reduce the repetitive tasks handled by SOC teams.

In short:

SIEM helps you see and understand the threat.

SOAR helps you automate what is done about it.

When the two technologies are used together, an organisation's security operations can be made faster, more centralised and more measurable.

The SecureSys SIEM and SOAR Security Service aims to bring an organisation's log sources together under central security visibility, detect attack behaviour, prioritise security events, and automate the appropriate response processes.

What Is SIEM?

SIEM – Security Information and Event Management is a security technology that centrally collects and analyses log data from sources such as servers, network devices, security products, user systems, applications and cloud platforms.

An organisation may have hundreds or even thousands of systems.

The firewall produces its own logs.

Windows servers produce their own logs.

Active Directory produces its own logs.

EDR, VPN, WAF, email security and cloud platforms all create different event records.

Examining these records independently of one another can make real attacks difficult to detect.

SIEM brings the data from these different sources together on a single central platform.

The purpose is not merely to store logs.

The real value lies in correlating different events with one another.

What Is SOAR?

SOAR – Security Orchestration, Automation and Response is a security approach that automates repetitive processes in security operations and allows different security products to work within a shared workflow.

When a connection to a malicious IP address is detected in the SIEM, for example, the SOC analyst may need to manually check the IP reputation, run a threat intelligence query, check the endpoint, block the IP on the firewall and raise a ticket.

SOAR can automate a significant part of this process.

A playbook such as the following can be run:

SIEM Alert → IOC Enrichment → Threat Intelligence Check → Endpoint Check → Firewall Block → Ticket Creation → SOC Notification

This can reduce the repetitive operational burden on security teams.

How Do SIEM and SOAR Work Together?

The relationship between SIEM and SOAR can be explained most simply through the following structure:

Log → SIEM → Correlation → Alert → SOAR → Playbook → Response

SIEM analyses security events coming from different sources.

When suspicious behaviour is detected, it generates an alert.

SOAR receives that alert and initiates the necessary analysis or response processes through a predefined playbook.

SIEM and SOAR are therefore not alternatives to one another.

Used together, they strengthen the detection + analysis + response chain of a security operation.

SecureSys SIEM and SOAR Security Service

The SecureSys SIEM and SOAR Security Service can be configured so that the organisation's existing security infrastructure is monitored centrally and security events are responded to more quickly.

The service can address the following together:

SIEM deployment, log source integration, use case design, correlation rule development, dashboards and reporting, SOAR playbook design, automation, threat intelligence integration and SOC operations

The objective is not simply to provide a SIEM licence or a SOAR product.

In the SecureSys approach, technology, security operations and attack scenarios are assessed together.

Which Logs Does SIEM Collect?

SIEM platforms can collect logs from a wide range of sources according to the organisation's needs.

These can include:

firewalls, VPN, IDS/IPS, WAF, EDR/XDR, NDR, Active Directory, Windows Server, Linux Server, databases, proxies, DNS, DHCP, Microsoft 365, Entra ID, AWS, Azure, Google Cloud, Kubernetes, applications and security products

The aim of a SIEM project, however, should not be to collect as many logs as possible.

The real question is this:

"Which log gives us the ability to detect which attack?"

This approach reduces unnecessary log costs while helping to increase security visibility.

Why Does Log Management Matter?

When a cyber security incident occurs, having historical logs available can be critical to understanding how the attack progressed.

When a user account is found to have been compromised, for example, the SIEM records can be used to investigate which IP the login came from, which servers were connected to, which files were accessed and when the attack began.

Log management therefore matters not only for compliance purposes but also for incident investigation and digital forensics.

What Is SIEM Correlation?

Correlation is the association of independent security events under a common attack scenario.

None of the following events, taken alone, may look critical:

A user entered the wrong password five times.

A successful login then took place.

Shortly afterwards, the same user made an RDP connection to a different server.

They were then added to a highly privileged group.

Assessed together, these events can reveal a potential account compromise and privilege escalation scenario.

SIEM correlation rules can associate these events and present a more meaningful alert to the SOC analyst.

What Is a SIEM Use Case?

A SIEM use case is a specific security scenario that the organisation aims to detect.

Scenarios such as the following can be built as SIEM use cases:

Brute Force Detection

Impossible Travel

Privileged Account Creation

Multiple Failed Logins

Ransomware Activity

Suspicious PowerShell

Lateral Movement

Malware Communication

Data Exfiltration

Unauthorised Cloud Access

In a successful SIEM project, what matters is not how many logs the platform ingests but which real threats it can detect.

SIEM Use Case Design With MITRE ATT&CK

Mapping SIEM use cases to the MITRE ATT&CK framework provides an important advantage in terms of detection coverage.

It becomes possible to assess which detection rules the organisation has across:

Initial Access,

Execution,

Persistence,

Privilege Escalation,

Credential Access,

Lateral Movement,

Command and Control

This reveals the detection gaps in the SIEM infrastructure.

A MITRE ATT&CK-based use case development model can be used in the SecureSys SIEM approach.

SIEM Detection Engineering

Detection engineering is the systematic development of the security rules needed to detect attacker behaviour.

This approach is broader than the classic "let's write an alert rule" model.

A detection engineer analyses the attack technique, identifies the required log sources, builds the correlation rule, tests it and optimises the false positive rate.

Using a single Event ID to detect credential dumping, for example, may not be sufficient.

Endpoint telemetry, Windows Security logs and identity information can be assessed together.

Detection engineering is therefore a critical area of expertise in advanced SIEM operations.

What Is a SOAR Playbook?

A SOAR playbook is an automation flow in which the steps to be applied when a particular security event occurs are defined in advance.

The following playbook, for example, can be created for a phishing alert:

Email Alert

↓

URL Reputation Check

↓

Domain Reputation Check

↓

Attachment Hash Analysis

↓

User Mailbox Check

↓

Identification of Other Users Who Received the Same Email

↓

Quarantine of the Malicious Emails

↓

SOC Ticket Creation

A significant part of this work can be done manually.

In high-volume operations, however, using SOAR can save the SOC team considerable time.

Phishing SOAR Playbook

Phishing is one of the most common use cases for SOAR automation.

When a user reports a suspicious email to the SOC team, SOAR can check the sender domain, run a URL reputation query, analyse file hashes and gather information from threat intelligence sources.

If the email is confirmed as malicious, the platform can investigate whether the same message is present in other mailboxes.

Within the scope of authorised automation, malicious emails can be quarantined.

Manual analysis that would normally take 20–30 minutes can therefore be completed within a few minutes.

Malware SOAR Playbook

When a critical malware alert is generated by EDR, SOAR can automatically:

check the file hash against threat intelligence platforms,

retrieve endpoint details,

query the user's identity information,

analyse the associated IP addresses and domains,

and, where necessary, trigger an endpoint isolation request.

This approach helps reduce response time, particularly in ransomware and active malware incidents.

What Is IOC Enrichment?

IOC enrichment is the enrichment of threat indicators such as IP addresses, domains, URLs or hashes with additional security information.

When a SOC analyst sees an IP address, for example, they may investigate:

Which country does the IP belong to?

Has it been associated with malware in the past?

Is it flagged as malicious in threat intelligence sources?

Which domains resolve to this IP?

SOAR can run these queries automatically and present the result to the SOC analyst ready for review.

SIEM and Threat Intelligence Integration

The IOCs obtained from threat intelligence sources can be used within the SIEM.

A list of known malicious domains, for example, can be compared against the organisation's DNS and proxy logs.

If one of the organisation's devices has communicated with such a domain, an alert can be generated.

Threat intelligence integration helps the SIEM assess not only internal behaviour but also the external threat context.

SOAR and Threat Intelligence

SOAR platforms can make extensive use of threat intelligence integrations.

When a new IOC is detected, for example, SOAR can automatically gather information from different sources.

Then, according to the risk score determined:

at low risk it may simply open a record,

at medium risk it may escalate to an analyst,

at critical risk it may initiate an authorised automated response process.

Threat intelligence data can therefore be turned directly into operational action.

SIEM and Active Directory

Active Directory logs are one of the SIEM's most critical data sources.

The SIEM can track:

failed logins, account lockouts, user creation, group membership changes, Domain Admin activity and unusual authentication

A standard user suddenly being added to the Domain Admin group, for example, can generate a critical alert.

Early detection of Active Directory attacks is important in preventing ransomware and lateral movement attacks.

SIEM and Microsoft 365

In Microsoft 365 environments, login activity, mailbox events, administrator actions, OAuth application permissions and email security events can be integrated into the SIEM.

A user logging in from a country different from their usual location and creating a forwarding rule shortly afterwards, for example, can be an indicator of business email compromise.

Correlation allows these events to be assessed under a single incident.

SIEM and Entra ID

Entra ID logs are an important data source for detecting identity-based attacks.

The SIEM can analyse events such as:

risky logins,

MFA activity,

privileged role changes,

new application permissions

As identity security becomes steadily more important in modern attacks, including identity logs in SIEM use cases has become critical.

SIEM and EDR/XDR

Endpoint alerts from EDR and XDR platforms can be forwarded to the SIEM.

These alerts can then be correlated with firewall, identity and network logs.

When EDR detects credential dumping on a device, for example, the SIEM can check whether the same user has logged in to other systems and whether there is a suspicious outbound connection on the firewall.

This approach gives a broader view of the attack chain.

SIEM and NDR

Anomalous network behaviour detected by NDR can be forwarded to the SIEM.

NDR may, for example, have detected lateral movement or C2 behaviour.

By correlating that information with endpoint and identity logs, the SIEM can show which user and system the attack is associated with.

SIEM and DDR

Data Detection and Response systems generate data-centric security events.

DDR may show, for example, that a user has downloaded a large volume of sensitive data.

At the same time, the SIEM may show that the user logged in from an unusual location, that EDR saw a suspicious process on the endpoint, and that NDR detected high-volume outbound traffic.

Assessing these events together can reveal a critical data exfiltration scenario.

SIEM and Cloud Security

Audit logs from AWS, Azure and other cloud platforms can be integrated into the SIEM.

Events such as the following can then be tracked centrally:

IAM changes,

creation of new access keys,

unusual API activity,

changes to public storage

In organisations using hybrid and multi-cloud environments, SIEM can provide common security visibility.

SIEM and Kubernetes

In Kubernetes environments, audit logs and container security events can be forwarded to the SIEM.

The following, for example, can be turned into alert scenarios:

creation of a new privileged container,

suspicious service account usage,

unusual API calls against the cluster

As cloud-native systems have become more widespread, extending SIEM use case coverage to container environments has become important.

SIEM and Database Security

Database audit records can be integrated into the SIEM so that critical data access is tracked.

A DBA account querying hundreds of thousands of customer records at night, for example, can constitute unusual behaviour.

Similarly, the creation of a new privileged database user can be turned into a SOC alert.

When SIEM and Database Activity Monitoring are used together, critical data access can be monitored more comprehensively.

Ransomware Detection With SIEM

Ransomware attacks do not consist of a single alert.

An attack can progress as follows:

Phishing → Execution → Credential Access → Privilege Escalation → Lateral Movement → Backup Manipulation → Encryption

By correlating the logs from these different stages, the SIEM can help detect a ransomware attack before encryption begins.

The following, for example, can all be indicators of the same attack chain:

unusual PowerShell activity,

credential dumping,

a large number of RDP connections,

changes to backup services

Brute Force Detection With SIEM

In brute force attacks, a large number of failed logins can be made against a user account in a short period.

Within a given time window, the SIEM can detect failed logins made from the same IP against a large number of users, or against the same user account from a large number of IP addresses.

A successful login following a series of failed attempts can raise the risk level.

Impossible Travel Detection

A user logging in from geographically distant locations within a very short period can constitute an impossible travel scenario.

If an account appears to log in from Türkiye and then from the United States 10 minutes later, for example, the event should be investigated.

By analysing identity logs, the SIEM can detect anomalies of this kind.

Because VPN and cloud proxy usage can generate false positives, however, the detection rules need to be optimised for the organisation's environment.

Privileged Account Monitoring

The activity of highly privileged user accounts should be monitored specifically by the SIEM.

The actions carried out by privileged accounts such as Domain Admin, Global Administrator and root are of critical importance.

The following, for example, can be treated as high-risk activity:

creation of a new user,

security group changes,

disabling of audit logging,

access to a large number of systems

SIEM False Positive Management

One of the most common problems in SIEM projects is excessive alert generation.

Treating every event as critical can create alert fatigue in SOC teams.

Correlation rules therefore need to be optimised regularly.

The SecureSys SIEM service can carry out:

false positive analysis, whitelist management, threshold optimisation and use case tuning

The aim is not to generate more alerts, but to generate better ones.

Alert Fatigue and SOAR

SOAR can help reduce alert fatigue.

The tasks a SOC analyst performs for every alert — IP lookups, domain reputation checks, endpoint lookups and user information queries — can be automated.

The analyst can then focus on the part of the event that requires a decision, rather than spending time gathering data.

Automated Endpoint Isolation With SOAR

In a critical malware attack, the infected endpoint may need to be isolated from the network quickly.

With the appropriate EDR integration, SOAR can carry out endpoint isolation automatically or subject to approval.

This process must be designed carefully, however.

Automatically isolating a critical production server because of a false alert, for example, can cause serious operational disruption.

Different response policies can therefore be applied to different asset classes.

User Account Response With SOAR

When an account compromise is detected, SOAR can support actions such as:

disabling the user account,

terminating active sessions,

initiating a password reset process,

checking MFA status

through integration with IAM or identity systems.

This automation can reduce response time particularly in business email compromise and credential theft incidents.

Firewall Automation With SOAR

When threat intelligence identifies a high-risk malicious IP address or domain, SOAR can carry out a block on the firewall.

In IOC-based automation, however, the risk of blocking something legitimate has to be considered.

Blocking a shared cloud IP address by mistake, for example, can stop many legitimate services from working.

Risk scoring and human approval mechanisms are therefore important.

Human-in-the-Loop SOAR

SOAR does not have to carry out every action fully automatically.

In a human-in-the-loop model, approval can be sought from the SOC analyst at certain stages.

For example:

IOC enrichment is performed automatically.

The risk score is calculated automatically.

Analyst approval is required for endpoint isolation.

This approach combines the speed of automation with human judgement.

SOC Operations With SIEM and SOAR

SIEM and SOAR are among the core technology layers of modern SOC operations.

SIEM collects and detects security events centrally.

SOAR accelerates the response processes.

SOC analysts use these technologies to assess events and make the necessary decisions.

The ideal structure can therefore be described as:

SIEM + SOAR + Threat Intelligence + SOC Analysts + Incident Response

What Is Managed SIEM?

Managed SIEM is a service model in which the SIEM infrastructure is managed by an expert security team.

The service can cover:

log source management,

use case development,

correlation tuning,

alert monitoring,

reporting

and platform management

For organisations without extensive in-house SIEM expertise, Managed SIEM can offer a significant operational advantage.

What Is Managed SOAR?

Managed SOAR is the development and management of an organisation's security automation processes by an expert team.

New playbooks can be prepared, existing flows optimised, and the integrations between security products managed.

The real value of SOAR comes not from the handful of playbooks created during initial deployment, but from the automation library that is developed continuously over time.

Managed SIEM and SOAR Service

The Managed SIEM and SOAR Service that SecureSys can provide aims to manage the organisation's security operations across both technology and expert resource.

The service can be structured as:

SIEM management + SOAR automation + threat intelligence + SOC monitoring + incident response support

This model is worth considering particularly in organisations that need a 24/7 security operation.

24/7 SIEM and SOAR Monitoring

Cyber attacks do not happen only during working hours.

Monitoring SIEM alerts around the clock is therefore important in critical organisations.

Critical SIEM incidents can be monitored continuously under the SecureSys SOC model.

Performing initial analysis and enrichment automatically through SOAR can help SOC analysts assess an alert more quickly.

How Are MTTD and MTTR Reduced?

MTTD – Mean Time to Detect expresses the time between an attack taking place and it being detected.

MTTR – Mean Time to Respond shows how long it takes for a response to be carried out after detection.

SIEM's fundamental contribution is to reduce MTTD.

One of SOAR's important contributions is to reduce MTTR.

When the two platforms are used together, the entire detection and response process can therefore be optimised.

SIEM and SOAR Implementation Process

1. Analysis of the Existing Infrastructure

The organisation's existing security products, servers, cloud systems and log sources are identified.

2. Log Source Prioritisation

Not every log source carries the same security value.

Critical sources are prioritised.

3. SIEM Integration

Log sources are integrated into the SIEM platform.

4. Use Case Design

Attack scenarios are built according to the organisation's risk profile.

5. Correlation Rule Development

The necessary detection rules are prepared.

6. MITRE ATT&CK Mapping

Use cases can be mapped to attack techniques.

7. SOAR Integration

Firewall, EDR, XDR, email, ticketing and threat intelligence systems can be connected to SOAR.

8. Playbook Development

Automation scenarios are created for events such as phishing, malware, IOCs and account compromise.

9. SOC Integration

Alerting and escalation processes are defined.

10. Continuous Tuning

The system is improved continuously in line with false positive rates and new threats.

The Most Common Mistakes in SIEM Projects

A significant proportion of failed SIEM projects fail not because of the technology chosen but because of the wrong operating model.

The most frequently seen problems include:

collecting every log indiscriminately, failing to build use cases, relying on default correlation rules, not carrying out false positive tuning, not checking the quality of log sources, and not defining SOC processes

Buying a SIEM and building a SIEM operation are not the same thing.

The SecureSys approach aims to place use cases and detection engineering at the centre of the SIEM project.

The Most Common Mistakes in SOAR Projects

In SOAR projects, automating more than is warranted for the sake of automation is a risk.

A badly designed playbook can:

block a legitimate IP address,

disable a critical account,

isolate a production endpoint.

SOAR processes should therefore be designed on a risk basis.

Low-risk actions can be fully automated, while critical actions may require analyst approval.

Which Organisations Are SIEM and SOAR Suitable For?

SIEM and SOAR are important security components particularly for:

financial institutions, public bodies, the defence industry, energy, telecoms, healthcare, e-commerce, technology companies, holding companies and critical infrastructure

Central security visibility can also be achieved in mid-sized organisations through a Managed SIEM/SOAR model.

SIEM, SOAR and Compliance

By collecting and retaining logs centrally, SIEM contributes to organisations' security and audit processes.

Log management and the monitoring of security events can be important under ISO/IEC 27001, PCI DSS and various sector-specific requirements.

SOAR can help standardise and record incident response processes.

No SIEM or SOAR product should be assumed, however, to deliver regulatory compliance on its own.

SIEM and SOAR Reporting

In a professional SIEM/SOAR service, reporting should show more than the volume of logs.

For management, the following can be reported:

the number of critical incidents, threat types, MTTD, MTTR, the most frequently triggered use cases, response times and security trends

For technical teams, details such as the following can be provided:

correlation rule performance,

false positive rates,

log source health,

playbook execution results

Why the SecureSys SIEM and SOAR Security Service?

The success of SIEM and SOAR projects does not depend on product deployment alone.

The real value emerges from selecting the right log sources, building use cases that reflect real attack scenarios, and automating response processes correctly.

The SecureSys SIEM and SOAR Security Service aims to help organisations detect and analyse security events centrally and accelerate their response processes.

According to the organisation's needs, the service can be configured together with:

SIEM deployment, SOAR deployment, log integration, use case development, detection engineering, MITRE ATT&CK mapping, threat intelligence, SOC, incident response, and EDR/XDR/NDR and DDR integrations

In the SecureSys approach, the objective is not merely to collect logs but to:

collect the right data, detect the real threat, and take the right action in the shortest possible time

The SecureSys SIEM and SOAR Security Service is an integrated detection and response service that analyses organisations' security logs centrally, correlates attack scenarios, and automates the response processes for security events.

Frequently Asked Questions

What is SIEM?

SIEM is Security Information and Event Management technology that collects security logs from different systems centrally, analyses them and correlates attack scenarios.

What is SOAR?

SOAR is Security Orchestration, Automation and Response technology that orchestrates operations across security products and automates incident response processes.

What is the difference between SIEM and SOAR?

SIEM focuses on the detection and analysis of threats, whereas SOAR focuses on the response and automation processes applied to those threats.

Can SIEM and SOAR be used together?

Yes. The strongest model is one in which the security events detected by the SIEM are passed to SOAR for enrichment and response.

Are SIEM and XDR the same thing?

No. SIEM performs broad log management and correlation, whereas XDR focuses more on attack-oriented analysis of security telemetry and on response processes. They can be used together.

What is the difference between SIEM and SOC?

SIEM is a technology. A SOC is the whole structure of people, process and technology that monitors and manages security events.

Can SOAR disable a user account automatically?

Where the necessary IAM integration and corporate policy exist, automated or analyst-approved account response can be designed.

Can SOAR block an IP on the firewall?

Where the appropriate integration exists, firewall block actions can be automated in line with the policies defined.

What is Managed SIEM?

Managed SIEM is the deployment, monitoring and management of the SIEM platform by an expert security team.

Is 24/7 SIEM monitoring possible?

Yes. SIEM platforms can be monitored around the clock as part of a SOC operation.

Seeing the Alert Is Not Enough — It Has to Become Action

Security systems in modern organisations generate thousands of events every day.

The real problem is not a lack of data, but noticing the right event at the right time.

SIEM helps find the answer to:

"What is happening?"

SOAR turns the answer to:

"What should we do now?"

into automation.

With the SecureSys SIEM and SOAR Security Service you can analyse your organisation's security logs centrally, monitor your attack scenarios through MITRE ATT&CK-based use cases, and automate the response processes for security events.