Threat Observability: Attack Detection, Triage and Hunting
Threat Observability tests how runtime attack detection works, how attacks are triaged against vulnerabilities, and how you hunt through security events rather than waiting for an alert.
Detection
- Runtime Application Protection instruments incoming requests and inspects them for attack patterns such as SQL injection, command injection, JNDI lookup abuse, XXE, SSRF and unsafe deserialisation. Detection depends on the technology being supported and the process being monitored.
- It runs in monitoring or blocking mode. Blocking should follow a monitored baseline period; enabling it blindly in production risks breaking legitimate traffic that resembles an attack signature.
- Each attack record carries the entry point, the affected process, and any exploited vulnerability, letting you connect an external request to internal code and data assets.
Triage and hunting
- Attacks, like vulnerabilities, are security events stored in Grail. Hunting queries filter on security event kinds, for example
fetch events | filter event.kind == "SECURITY_EVENT", then aggregate by entry point, process or attack type. - Attack-path and threat views connect an exposed endpoint through the service to the vulnerable library and the data it can reach, which is exactly the evidence needed for prioritisation.
- Alerting profiles route detections to SIEM, ticketing or chat channels with severity and ownership filters.
Worked example
A public endpoint on a service that loads a vulnerable parsing library shows a burst of requests. Hunting aggregates the security events by entry point and attack type and finds repeated injection attempts, but the attack record shows the vulnerable code path was never reached. Reasoning: an attack is not a compromise - report exposure and patch the library, but do not escalate to incident response on attempt volume alone. If the exploited-vulnerability field were populated, escalation would be justified.
Traps that cost marks
- Treating every detected attempt as a breach rather than reading whether a vulnerability was exploited.
- Expecting detection where the technology is unsupported or the process is unmonitored.
- Exemptions created for vulnerability noise that also suppress attack visibility.
- Enabling blocking mode without validating false positives against real traffic.