A hospital forbids TLS decryption for patient-privacy rules but suspects a workstation is talking to a command-and-control server over HTTPS. The team wants to characterise that connection without seeing any payload. Which information does the Encrypted Visibility Engine provide for the session?
Select an answer to reveal the explanation.
Short Explanation
You can keep the session encrypted while EVE fingerprints the TLS Client Hello to identify the likely client process and application and provide a threat score. Think of it as recognizing how a visitor knocks without opening their luggage.
Full Explanation
The correct choice describes Encrypted Visibility Engine (EVE) on Threat Defense with Snort 3: it fingerprints the TLS Client Hello and, combined with other data such as the destination, identifies the client process and operating system that started the session, maps many processes to client applications, and can score the likelihood that the process is malware. This happens without decrypting, meeting the hospital’s privacy constraint. TLS version, cipher suite, and ALPN are real handshake details, but the claim that EVE cannot suggest the client process misses its process identification capability. DNS-query correlation can help identify a likely C2 domain, but it does not infer which client process created the session. A proxy can show destination, client, and timing in CONNECT records without decryption, but those records do not identify the process behind the traffic. Exam caveat: EVE provides a likelihood, not proof, and it does not see inside encapsulated traffic; results appear in connection events and can be used in access control rules on devices managed by the Management Center. Practical check: enable EVE in the access control policy’s advanced settings, then review a connection event for the process name and threat score.