detectionIngeniería de Detección~1 min de lectura
Esta nota todavía no está traducida — se muestra el original en inglés.

From local exploit to detection

Behavior

Use a deliberately vulnerable local fixture with two tenants. The test changes only an object identifier while retaining a valid fixture session. The purpose is to validate that a missing object-level check creates an unauthorized state transition and to observe the resulting evidence—not to test arbitrary hosts.

Required telemetry and data model

The fixture emits structured edge, application, and audit events. Required fields are timestamp, correlation ID, authenticated principal, tenant, route template, requested object class, authorization decision, response category, and policy version. Normalize timestamps and retain enough context to join one request across components.

Detection logic and expected alert

Alert when a principal produces multiple denied cross-tenant object requests in a short window, or when an allowed decision conflicts with the object's tenant in the audit fixture. Expected alert: a case containing correlation IDs and the normalized evidence, not an accusation. Verify it with a deterministic fixture run; after the authorization fix, rerun the test and confirm no unauthorized response is possible.

Trade-offs and response

False positives include stale links and client bugs; false negatives include missing audit fields, low-and-slow behavior, and compromised trusted accounts. Triage the evidence, contain access through the local fixture's account policy, repair the authorization check, and retain the regression test.

Sources