Security SLAs and MSSPs

A Service Level Agreement (SLA) is a contractual commitment between a service provider and a client that defines the expected level of service, performance metrics, remedies for failures, and exclusions. In the context of security, an SLA typically covers aspects like uptime of security tools, time to detect incidents, time to respond, and reporting frequency. SLAs are not just technical documents; they are legal contracts that allocate risk and responsibility.

An SLA specifies key performance indicators (KPIs) and service level objectives (SLOs). For example, an MSSP might guarantee 99.9% uptime for its Security Information and Event Management (SIEM) platform, meaning no more than 8.76 hours of downtime per year. If the SIEM is down for 10 hours, the SLA may trigger a service credit (e.g., 5% refund of monthly fee). The SLA also defines measurement methodology: uptime is calculated as total minutes in a month minus unscheduled downtime, divided by total minutes. It excludes planned maintenance windows (e.g., 2 AM to 4 AM on Sundays).

For incident response, an SLA might specify: "Time to Triage" (TTT) within 15 minutes of alert generation, "Time to Respond" (TTR) within 1 hour for critical incidents, and "Time to Resolve" (TTRes) within 8 hours. The MSSP uses a ticketing system with timestamps to measure these. The client can audit these metrics via monthly reports. If the MSSP fails to meet the TTR for three incidents in a quarter, the client may terminate the contract without penalty.

- Mean Time to Detect (MTTD) - Mean Time to Respond (MTTR) — note: sometimes MTTR means "repair" or "resolve" - Mean Time to Contain (MTTC) - Uptime/Availability (e.g., 99.9% for SIEM) - False Positive Rate (e.g., <5%) - Report Delivery (e.g., within 5 business days of month end) - Remedies: Service credits (e.g., 10% of monthly fee per hour of downtime), termination rights, or escalation paths. - Exclusions: The SLA typically lists what is NOT covered, such as:

- Incidents caused by client's failure to patch systems - Attacks exceeding a certain volume (e.g., DDoS over 100 Gbps) - Zero-day exploits before a signature is available - Standards: While there is no single SLA standard, frameworks like ITIL and ISO 20000 provide guidance. The US National Institute of Standards and Technology (NIST) SP 800-86 offers best practices for incident handling that can inform SLAs.

When procuring an MSSP, the client drafts a Request for Proposal (RFP) that includes desired SLA metrics. The MSSP responds with proposed SLAs. Negotiation focuses on realistic targets: a 1-minute MTTD for all alerts is unrealistic; a 5-minute MTTD for critical alerts may be achievable. The client must also define how alerts are categorized (critical, high, medium, low) and what constitutes an incident. For example, a single failed login is an alert, not an incident; 10 failed logins in 5 minutes may be an incident.

While SLAs are contractual, tools help monitor them. For example, using a SIEM like Splunk or ELK, you can query:

source="ids.log" | stats count by signature | where count > 100 | table _time, signature

This might be used to measure detection time. For MSSP reporting, the provider might use a platform like ServiceNow to track tickets. A sample SLA report might include:

Some organizations use a co-managed model where the MSSP handles Level 1 monitoring and the internal team handles Level 2/3 response. The SLA then defines handoff times: e.g., MSSP must escalate to client within 10 minutes of detecting a critical incident. Other variants include fully outsourced (MSSP does everything) and hybrid (MSSP provides tools but client staff operate them).

An MSSP typically deploys sensors (e.g., network taps, endpoint agents) on the client's network. The client must provide access (e.g., VPN, firewall rules). The SLA may include a "readiness" metric: e.g., MSSP must have full visibility within 30 days of contract signing. The MSSP's Security Operations Center (SOC) analysts monitor alerts 24/7 and follow playbooks defined in the SLA. For example, a playbook for ransomware might include: isolate the host, block the C2 IP, notify the client, and preserve forensic data.

SLAs often include limitation of liability clauses. For example, the MSSP's liability may be capped at the total fees paid in the last 12 months. This means if a breach causes $1M loss, the client may only recover $100k. The SLA should also address data ownership: who owns the logs and alerts? Typically the client owns the data, but the MSSP may retain copies for a period (e.g., 90 days).

For SY0-701, you need to understand:

A mid-sized retailer outsources SIEM monitoring to an MSSP to meet PCI DSS Requirement 10 (log monitoring). The SLA specifies: MTTD < 15 minutes for critical alerts, SIEM uptime 99.9%, and monthly compliance reports. One month, the MSSP fails to detect a brute-force attack on a POS system for 45 minutes. The client's internal auditor catches it. The client reviews the SLA report and finds the MSSP's MTTD was 12 minutes on average, but the specific incident was missed due to a rule misconfiguration (the MSSP's rule for failed logins was set to 50 attempts per minute, but the attack used 40). The client invokes the SLA breach clause and receives a 10% service credit. The MSSP updates the rule. The client also learns to specify that all PCI-related alerts must be treated as critical, regardless of volume.

A hospital network contracts an MSSP for 24/7 SOC services. The SLA includes MTTR < 1 hour for critical incidents. A ransomware attack encrypts files on a file server. The MSSP detects the initial lateral movement within 5 minutes (MTTD met) but takes 2 hours to respond because the playbook required client authorization before isolation. The SLA did not specify the authorization process. The client argues that MTTR should include the time to get approval. The MSSP counters that the SLA excludes delays caused by client. Ultimately, they revise the SLA to include a pre-approved isolation list and a 15-minute authorization window. The incident causes 4 hours of downtime, but the SLA breach leads to a 15% credit. The client also realizes they need a separate SLA for backup restoration (the MSSP did not handle backups).

A financial firm signs an MSSP contract with an SLA that promises "detection of all known malware." A new variant of Emotet (CVE-2023-1234) infects the network, and the MSSP does not detect it for 8 hours because no signature existed. The client demands a credit, but the SLA excludes zero-day threats. The client had not negotiated a separate zero-day detection SLA (e.g., using behavioral analysis). The lesson: always review exclusions and negotiate coverage for emerging threats if needed.