SIEM for MSPs: What It Is, How It Works, and Whether to Build or Buy

Share this post on:

Key Takeaway: A SIEM without an analyst is an expensive log storage system. An analyst without a SIEM is guessing. The combination, done right, is how you detect the attacks that bypass every other control. For MSPs, the question is not whether to offer SIEM capabilities. It is whether to build them or buy them through an MDR partnership.

Security information and event management is the technology that makes security operations possible at scale. Without a SIEM, security monitoring means logging into individual systems one at a time and hoping you notice something wrong. With a SIEM, logs from every system in the environment flow into a single platform where correlation rules, behavioral analytics, and human analysts can identify patterns that no individual system would surface on its own.

For MSPs building a security practice, SIEM is the infrastructure layer that separates reactive IT support from proactive security operations. Understanding what it does, what it costs, and how to deliver it to SMB clients is foundational to any serious security service offering.

What a SIEM Does

Log aggregation. A SIEM collects logs from every source in the environment: firewalls, endpoints, servers, identity providers, cloud services, email platforms, and applications. Logs that would otherwise sit in isolation on individual systems are centralized in a single platform where they can be searched, correlated, and analyzed.

The value of centralization is context. A failed login attempt on a single server is noise. Three hundred failed login attempts across fifty servers in ten minutes is a brute force attack. A SIEM sees the pattern. Individual system logs do not.

Event correlation. Correlation rules define patterns of events that indicate suspicious or malicious activity. A rule might fire when a user authenticates successfully from two different countries within an hour (impossible travel). Another might fire when a service account that normally runs scheduled tasks suddenly starts accessing file shares it has never touched. Another might fire when an endpoint communicates with a known command-and-control IP address.

Correlation rules are the intelligence layer of the SIEM. Out-of-the-box rules catch known attack patterns. Custom rules catch patterns specific to the client’s environment. The quality of the rules determines the quality of the detections.

Alerting and case management. When a correlation rule fires, the SIEM generates an alert. The alert goes to an analyst who investigates, determines whether it is a true positive or a false positive, and takes appropriate action. The SIEM tracks the investigation as a case, documenting the analyst’s findings and the actions taken.

Threat hunting. Beyond reactive alerting, SIEM enables proactive threat hunting: analysts searching through historical log data for indicators of compromise that did not trigger automated rules. Threat hunting finds the attacker who has been in the environment for weeks without triggering alerts, moving slowly and carefully to avoid detection.

Compliance reporting. Many compliance frameworks (PCI DSS, HIPAA, SOC 2) require log retention and review. A SIEM provides both: logs are retained for the required period and the review process is documented through the case management system. Compliance reporting that would take days to compile manually can be generated in minutes from SIEM data.

SIEM vs. Log Management vs. MDR

Log management is the collection and storage of logs without the correlation and analytics layer. It satisfies compliance requirements for log retention but does not provide security monitoring. A log management system that stores 90 days of firewall logs is useful for forensic investigation after a breach. It does not help you detect the breach while it is happening.

SIEM adds correlation, alerting, and analytics on top of log management. It is the detection layer. But a SIEM without analysts reviewing alerts is just an alert generator. Alerts that are not investigated are not security.

MDR (Managed Detection and Response) is SIEM plus analysts plus incident response capability delivered as a managed service. The MDR provider supplies the SIEM platform, the correlation rules, the 24/7 analyst coverage, and the incident response capability. For MSPs that cannot staff a 24/7 SOC, MDR is how you deliver SIEM-level security monitoring to clients without building the infrastructure yourself.

According to Gartner’s Market Guide for Managed Detection and Response Services, MDR adoption among organizations with fewer than 1,000 employees grew 40 percent year-over-year as organizations recognized that SIEM technology without analyst coverage does not deliver security outcomes.

The Build vs. Buy Decision for MSPs

Building an in-house SIEM capability requires significant investment. The SIEM platform itself (Microsoft Sentinel, Splunk, IBM QRadar, Elastic SIEM) costs money to license and requires expertise to configure. Correlation rules need to be written and tuned. Analysts need to be hired, trained, and retained. 24/7 coverage requires multiple analysts. The total cost of building a genuine SOC capability is typically $500,000 to $1 million annually for a small team, before accounting for the SIEM platform costs.

For most MSPs, this investment is not justified by the revenue opportunity. The alternative is partnering with an MDR provider who has already built the infrastructure and staffed the analysts. The MSP white-labels or resells the MDR service, manages the client relationship, and handles the endpoint deployment. The MDR provider handles the monitoring, detection, and response.

MDR partnerships typically cost the MSP $5 to $20 per endpoint per month depending on the provider and coverage level. The MSP marks this up to $15 to $40 per endpoint per month, with the margin covering the client relationship management and endpoint administration. The economics work for MSPs at almost any size.

The MSPs that should consider building in-house SIEM capability are those with 50 or more employees, a dedicated security practice, and a client base that demands it. For everyone else, the MDR partnership model delivers better security outcomes at lower cost than attempting to build the capability internally.

Microsoft Sentinel for MSPs

Microsoft Sentinel has become the most accessible SIEM option for MSPs in the Microsoft ecosystem. It is cloud-native, integrates directly with Microsoft 365 and Azure, and is available through the Microsoft CSP program. For clients already paying for Microsoft 365 E5 or Microsoft Defender for Endpoint, significant Sentinel functionality is included or available at reduced cost.

Sentinel’s multi-tenant management through Azure Lighthouse allows MSPs to manage Sentinel workspaces for multiple clients from a single interface. This is the operational model that makes SIEM delivery practical for MSPs: one analyst can monitor multiple client environments from a single dashboard rather than logging into separate systems for each client.

The cost model for Sentinel is consumption-based: you pay for the volume of data ingested. This requires careful planning to avoid unexpected costs. Not every log source needs to go into Sentinel. Prioritize the sources that generate the most security-relevant events: identity logs (Entra ID), endpoint logs (Defender for Endpoint), firewall logs, and email security logs. Lower-value log sources can go to cheaper log management storage and be pulled into Sentinel only when needed for investigation.

What Log Sources Matter Most

Identity logs. Authentication events from Entra ID (Microsoft 365), Active Directory, and any other identity provider. Failed logins, successful logins from unusual locations, MFA bypass attempts, privilege escalation, and account changes. Identity is where most attacks start and where the most valuable detections happen.

Endpoint logs. Process creation, network connections, file system changes, and registry modifications from endpoints. EDR platforms (Defender for Endpoint, CrowdStrike, SentinelOne) generate rich endpoint telemetry that feeds SIEM correlation rules for detecting malware execution, lateral movement, and data exfiltration.

Firewall and network logs. Inbound and outbound connections, blocked traffic, DNS queries, and VPN authentication. Network logs reveal command-and-control communication, data exfiltration, and lateral movement that endpoint logs may miss.

Email security logs. Phishing attempts, malicious attachments, suspicious links, and email forwarding rules. Email is the most common initial access vector. Email security logs in the SIEM enable detection of phishing campaigns and business email compromise attempts.

Cloud service logs. For clients using Azure, AWS, or Google Cloud, cloud audit logs capture administrative actions, resource changes, and access patterns that are critical for detecting cloud-based attacks.

Frequently Asked Questions

Do SMB clients need a SIEM?
SMB clients need the security outcomes that a SIEM enables: detection of threats that bypass perimeter controls, correlation of events across systems, and documented log review for compliance. Whether they need a dedicated SIEM platform or an MDR service that includes SIEM capabilities depends on their size and budget. The outcome is the requirement. The technology is the means.

How is SIEM different from EDR?
EDR (endpoint detection and response) monitors individual endpoints for malicious behavior. SIEM aggregates logs from all systems and correlates events across the entire environment. EDR is the eyes on the endpoint. SIEM is the brain that connects what the eyes see across all endpoints and systems. They are complementary, not competing.

What is SOAR and how does it relate to SIEM?
SOAR (security orchestration, automation, and response) automates the response to common alert types. When a SIEM alert fires for a known threat pattern, SOAR can automatically isolate the affected endpoint, reset the compromised account, and create a ticket in the PSA without analyst intervention. SOAR reduces the time between detection and response and allows analysts to focus on complex investigations rather than routine responses.

How long should logs be retained?
PCI DSS requires 12 months of log retention with three months immediately available. HIPAA requires six years of documentation retention. SOC 2 auditors typically want to see 12 months of logs. For clients without specific compliance requirements, 12 months is a reasonable baseline. Longer retention is valuable for threat hunting and forensic investigation but increases storage costs.

What is the difference between a SIEM alert and a security incident?
A SIEM alert is a notification that a correlation rule has fired. It may or may not indicate a real security incident. The analyst’s job is to investigate the alert, determine whether it is a true positive (real threat) or false positive (benign activity that matched the rule), and take appropriate action. Most SIEM alerts are false positives. The skill of the analyst and the quality of the correlation rules determine the ratio of true positives to false positives.

Sources

Related Reading: NOC vs SOC | MSP Incident Response Plan | From MSP to MSSP | Dark Web Monitoring for MSPs | MSP Cybersecurity Hub

Share this post on:

Author: Brent Lacy

Brent Lacy is the founder of Rewired MSP and author of three books on managed services, vCIO strategy, and cybersecurity. He helps MSP owners build trust-based, scalable businesses through documented processes, strategic leadership, and client-first culture.

View all posts by Brent Lacy >

Leave a Reply