The canonical use case for SSE (Security Service Edge) is straightforward: inspect outbound traffic, apply policy, block threats. The more nuanced, and arguably more valuable, operational benefit lies in its forensic logging capabilities. Today's incident involved a seemingly benign user device making periodic, low-volume HTTPS calls to a new domain that had slipped through initial threat intelligence feeds. The block came later; the *find* came from systematic log analysis.
The scenario began with a generic alert for "increased call volume to newly registered domains" from our SSE provider's dashboard. The volume wasn't high—perhaps 50 requests over 8 hours from a single source—which is why it was tier-2. The key was accessing and parsing the raw HTTP transaction logs, which our SSE platform exports to our SIEM. These logs go beyond simple allow/deny; they contain full HTTP headers, TLS details, and, critically, the unencrypted **Server Name Indication (SNI)** and certificate information from the TLS handshake, which is visible even for encrypted payloads.
The initial filter in the SIEM was for the source IP and a `transaction_result` of `allowed`. The relevant log entry structure resembled this simplified example:
```json
{
"timestamp": "2024-05-26T14:22:17Z",
"src_ip": "10.5.2.101",
"dst_ip": "203.0.113.45",
"dst_domain": "cdn-update[.]net",
"http_method": "GET",
"http_user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
"tls_sni": "cdn-update[.]net",
"tls_certificate_issuer": "C=US, O=Let's Encrypt, CN=R3",
"url_category": "Technology",
"transaction_result": "allowed",
"bytes_uploaded": 142,
"bytes_downloaded": 1248
}
```
Several anomalies became apparent upon correlation:
* The User-Agent string matched the company's standard browser build, but the process initiating the call, captured by the endpoint agent, was `svchost.exe` (spoofed, as we later found).
* The TLS certificate was a legitimate Let's Encrypt wildcard cert, but for a domain registered only 48 hours prior.
* The `bytes_uploaded` (142 bytes) was remarkably consistent across all calls, suggesting a small beacon payload.
* The `bytes_downloaded` varied slightly but was always a small, specific range (1200-1300 bytes), indicative of a compact command or configuration fetch.
The breakthrough was cross-referencing the TLS certificate serial number and issuer from the SSE logs with public certificate transparency logs. While the domain was new, the same certificate serial number had been issued to a cluster of domains previously flagged (in niche forums, not major threat intel feeds) for C2 activity. The SSE logs provided the forensic link our static intelligence feeds missed.
The process highlights a critical operational shift:
* **SSE as a Sensor Network:** Each proxy node becomes a distributed sensor, capturing metadata at a scale impossible with on-premise secure web gateways.
* **Log-Driven Hunting:** The value isn't just in the inline block but in the rich, queryable transaction log. Key fields for C2 hunting include:
* `tls_sni` and `tls_certificate_*` fields for certificate graphing.
* `bytes_uploaded`/`bytes_downloaded` patterns for beaconing detection.
* `http_user_agent` anomalies against process context (requires endpoint data correlation).
* Temporal analysis on `dst_domain` age (integrated with external whois/CT log feeds).
Ultimately, the malware was isolated and the domain blocked post-investigation. The lesson is that the defensive power of SSE is multiplicative when its extensive logging is treated as a first-class data source for behavioral analysis, not just as an audit trail for blocked connections. The architecture's inherent ability to log plaintext SNI and certificate data for all traffic, regardless of encryption, is a game-changer for threat hunting that is often underutilized in favor of simpler, block-focused workflows.
The emphasis on SNI and cert data in those logs is crucial, and a lot of teams don't parse that deeply. But the real bottleneck in making this process operational is usually the log ingestion and transformation pipeline before it hits the SIEM.
If you're pulling raw HTTP transaction logs at volume, you're likely dealing with semi-structured JSON blobs or syslog streams that need serious normalization before you can run efficient queries like that `transaction_result` filter. A poorly designed ETL here means you're either sampling logs or your queries time out, which defeats the whole forensic purpose.
What's your data pipeline look like from the SSE provider to your SIEM? Direct integration, or are you staging and processing the logs through something like a streaming job first? I've seen alert fidelity drop by half because fields like TLS details weren't properly flattened and indexed.
—davidr