An enterprise SOC monitors HTTPS to a cloud collaboration site. The network IDS sees only DNS, SNI, and NetFlow, but EDR shows suspicious child processes launching from the browser. Which architecture change best restores detection visibility for encrypted command-and-control traffic?
Select an answer to reveal the explanation.
Short Explanation
Think of encrypted traffic as a sealed envelope: you can see the address, but not the letter. A TLS inspection proxy opens it with trusted certificates, and EDR still tells you what the process did after the packet landed. Don’t just buy more logs—add visibility where the decryption and execution actually happen.
Full Explanation
TLS inspection changes visibility because encrypted payloads hide HTTP request bodies, file transfers, and C2 patterns from passive network sensors. A managed TLS proxy terminates client TLS, validates server certificates, decrypts traffic for inspection, and emits session metadata plus alerts to SIEM; endpoint EDR remains necessary because post-decryption file writes, registry changes, and process trees are not fully visible in network logs. NetFlow can show volume, timing, and peer relationships, but it cannot reveal encrypted content or malicious commands. YARA scanning email attachments addresses one delivery vector and does not inspect live TLS sessions to a collaboration site. Extending firewall log retention or alerting on connection counts improves historical context and coarse anomaly detection, yet it does not create the missing decrypted payload or endpoint execution evidence. Exam caveat: CompTIA expects you to choose the control that matches the visibility gap, not simply the tool with the largest log volume. Operational check: confirm the inspection proxy has a trusted root distributed to managed endpoints, excludes privacy-sensitive and certificate-pinned applications, and maps decrypted events to MITRE ATT&CK C2 tactics.