Listen to this Post
Introduction:
Service Level Agreements (SLAs) are the bedrock of trust between clients and Managed Security Service Providers (MSSPs). However, a pervasive industry practice involves manipulating SOC metrics to present a facade of compliance. This article exposes the common techniques used to skew these metrics and provides the technical know-how to verify your security posture independently.
Learning Objectives:
- Identify the six primary methods MSSPs use to manipulate SLA reporting.
- Learn verified commands and techniques to audit and validate security metrics.
- Implement best practices for ensuring transparency and accountability from your security provider.
You Should Know:
1. The Art of Auto-Closure and Ticket Padding
MSSPs often inflate their performance metrics by automatically closing low-fidelity alerts or creating tickets for non-issues to pad numbers and improve closure statistics.
` Linux: Query auditd for log clearance events, a potential sign of log tampering.`
`sudo ausearch –message ANOM_LOGIN_SESSIONS,ANOM_SESSION –start today -i`
` Windows PowerShell: Check System Event Log for unexpected restarts or log clears.`
`Get-EventLog -LogName System -Source “Service Control Manager” -InstanceId 7036,7040 | Where-Object { $_.Message -like “stopped” -or $_.Message -like “started” } | Select-Object -First 10`
This Linux command searches the audit daemon (auditd) for events related to session anomalies, which could indicate unauthorized access or log manipulation. The Windows PowerShell command checks the System log for service stops and starts, which could be used to disrupt logging. Regular monitoring of these logs helps establish a baseline and identify anomalous administrative actions.
2. The “Excluded Outlier” Illusion
Legitimate security alerts are sometimes classified as “outliers” and excluded from SLA calculations, artificially boosting compliance rates.
` SIEM Query (Splunk SPL Example): Search for alerts closed with “false positive” or “outlier” tags.`
`index=alerts (tag=”false_positive” OR tag=”outlier”) | stats count by alert_name, user`
` ELK Stack (Kibana Query): Find events with specific exclusionary keywords.`
`alert.signature: AND (tags: “excluded” OR status: “benign”)`
This Splunk SPL query counts how many alerts have been tagged as false positives or outliers, broken down by the type of alert and the user who applied the tag. A high volume from a single analyst or on critical alert types warrants investigation. The ELK query performs a similar function, searching for excluded events.
3. Log Source Gambiting: Selective Ingestion
To reduce alert volume and improve performance metrics, MSSPs may deliberately fail to onboard noisy but critical log sources.
` Linux: Use grep to check critical log files (e.g., sshd, sudo) for recent entries.`
`sudo tail -f /var/log/auth.log | grep -i “failed\|accepted”`
` Windows: Use wevtutil to list all log channels and check their status.`
`wevtutil el | while read channel; do wevtutil gli “$channel” | grep -i “enabled:\|logging:”; done`
The Linux command tails the authentication log in real-time, filtering for successful and failed login attempts, ensuring the log is active. The Windows script lists all event log channels and checks if they are enabled and currently logging, helping to identify any critical logs that have been disabled.
4. Threshold Tuning for “Quiet” Periods
Alerting thresholds are artificially raised to a point where only the most egregious incidents generate a ticket, creating a false sense of calm.
` YARA Rule Snippet: A rule with an intentionally high condition count to evade detection.`
`rule Suspicious_PowerShell_Encoding {`
` meta:`
` description = “Detects base64 encoded PowerShell commands with high entropy”`
` strings:`
` $s1 = /-Enc(odedCommand)?\s+[A-Za-z0-9+\/]{100,}/`
` condition:`
` uint32(0) == 0x5A4D and filesize < 2MB and $s1`
`}`
Suricata Rule: A rule with a highdetection_threshold.
`alert http any any -> any any (msg:”SUSPICIOUS User-Agent”; content:”Mozilla|2F 5.0|”; pcre:”/^[^\r\n]{200,}/”; threshold: type threshold, track by_src, count 100, seconds 60; sid:1000001;)`
The YARA rule is designed to detect encoded PowerShell commands, but a provider might set the condition so that it only fires on files under 2MB, missing larger payloads. The Suricata rule has a `threshold` directive that requires 100 events from a single source in 60 seconds before alerting, which could allow a slow-and-low attack to pass unnoticed.
5. Clock Manipulation and Timeframe Tricks
SLA clocks are stopped for “maintenance” or “investigation” during critical incidents, effectively pausing the timer on their response obligations.
Linux: Use `auditctl` to monitor changes to the system time.
`sudo auditctl -w /etc/localtime -p wa -k system_time_change`
` API Security: Check SIEM API logs for timestamp anomalies in alert ingestion.`
` Example using jq to analyze a log file from your SIEM’s API.`
`cat siem_api_logs.json | jq ‘. | select(.received_timestamp != .internal_timestamp) | {received, internal}’`
The Linux command adds a watch to the system time configuration file (/etc/localtime) and logs any write or attribute changes, which could indicate time manipulation. The `jq` command parses SIEM API logs, looking for discrepancies between the time a log was received and the time it was stamped internally, which could signal delayed ingestion.
6. The Mute Button: Suppressing Noisy Detections
Instead of properly tuning detection rules, entire rules or data sources are simply disabled to cut down on alert fatigue.
` Wazuh/OSSEC: Check the agent’s configuration to see if any active-response or rules are disabled.`
`sudo grep -r “disabled\”\s:\strue” /var/ossec/etc/`
` Check Suricata rule updates for recently modified or disabled rules.`
`git log -p — /etc/suricata/rules/ | grep -B 5 -A 5 “^-\salert\|^+\s\salert”`
The first command recursively searches the Wazuh configuration directory for any lines explicitly setting a rule or response to “disabled”. The second command uses `git` (if your rules are version-controlled, which is a best practice) to show the recent history of changes to Suricata rule files, highlighting where active `alert` rules have been commented out or removed.
What Undercode Say:
- Trust, but Verify. Blind faith in SLA reports is a critical vulnerability in your security program. The most important control is an in-house analyst capable of independent validation.
- Transparency Over Metrics. A provider willing to show you the “warts and all” view of their operations is inherently more trustworthy than one that only presents pristine, green dashboards. The future of effective security outsourcing lies in verifiable, real-time data and immutable audit trails, not polished monthly reports. Clients must demand technical literacy and audit rights, moving beyond simple compliance checkmarks to a true partnership based on demonstrable security outcomes.
Prediction:
The growing awareness of SLA manipulation will catalyze a shift towards blockchain-verified or cryptographically-secured audit trails for SOC activities. Client-side monitoring agents, which independently verify alert generation and response times, will become a standard requirement in MDR contracts. This will force a new era of radical transparency in the MSSP industry, separating providers who deliver genuine security value from those who merely excel at reporting.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Rafal Kitab – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
