A manufacturer built an in-house parts catalog served over plain HTTP on TCP 8443, and it is absent from the system-provided detector list. Two other unrelated services also listen on TCP 8443 in the same segment. The SOC wants the catalog to appear in the discovered application inventory for event views and correlation. Which custom application detector design fits this requirement?
Select an answer to reveal the explanation.
Short Explanation
A detector is only as specific as the pattern you feed it, and TCP 8443 alone is a crowded house. Matching the host name and path tags the catalog, and the custom detector lets discovery identify it by name.
Full Explanation
The catalog must be represented as a discovered application so it can appear in inventory views and support event correlation. A custom detector keyed to both the catalog's host name and URL path, constrained to TCP 8443 and activated for discovery, identifies the intended HTTP application while avoiding the two unrelated services that share its port. Leaving discovery inactive, even after deploying a correctly scoped detector, prevents the catalog from being added to the discovered inventory; classification may exist elsewhere, but it does not satisfy the inventory requirement. Matching only the URL path is a plausible HTTP detection technique, yet without the host-name condition it can misclassify traffic to another service on the same port if that service uses the same path. Enabling the custom detector for alerting only can produce security events, but alert generation is not application discovery and will not create the requested inventory entry. Exam caveat: a detector's available match fields and activation scope vary by product, so do not assume that a port match alone uniquely identifies an application. Practical check: after activation, generate representative catalog traffic and confirm the inventory shows the catalog by its expected name, while the other TCP 8443 services remain separately identified.