A company runs an internal web service on TCP 8443, and a second unrelated service also listens on that port, so port matching alone would tag hosts incorrectly. The traffic never leaves the inside network, and the team wants the application name on discovered hosts so correlation rules can reference it. How should the custom application detector be defined and scoped?
Select an answer to reveal the explanation.
Short Explanation
Since both services use TCP 8443, your detector needs a distinctive payload match to identify the right application, like a fingerprint that tells two look-alike boxes apart. Enable it in a discovery rule that covers the inside network so discovered hosts get the application name for correlation.
Full Explanation
Network discovery works in two layers: a policy rule decides which interfaces and hosts get analyzed, and a detector decides what an application looks like in that traffic. For a service sharing port 8443 with an unrelated one, a port-only detector labels both services the same way, so the resulting application name is not useful for correlation. The detector must also be enabled inside a network discovery rule, because discovery is the process that adds application information to the host inventory. An access control rule can reference a custom detector to match flows, but it does not populate the discovered host record with the application name the team wants. Scoping the discovery rule to the outside interface fails because the traffic never crosses that path, so the detector cannot see the service traffic. Built-in detectors cover common applications, which is why a private service may need a custom one. Discovery must also be enabled for the hosts in question; otherwise, the detector will not identify their application. Generate traffic to the service, then check the host inventory for the application name before building a correlation rule.