23 lines
1.3 KiB
Markdown
23 lines
1.3 KiB
Markdown
# Broker lifecycle evidence in SIEM exports
|
|
|
|
Broker events use a request UUID separate from OpenTelemetry trace identifiers.
|
|
A terminal forwarding fault references the durable authorization event UUID;
|
|
authorization alone does not prove delivery. Strict shared schema validation
|
|
rejects unsupported phases, reasons, self-links and raw content fields.
|
|
|
|
ECS exports the projected facts under `safetynet.broker`, including request,
|
|
connection and original event IDs. Forwarding/inspection faults have an error
|
|
type and failure outcome. An authorization has an unknown delivery outcome.
|
|
|
|
CEF uses the standard custom string `cs2`, labeled `BrokerLifecycle`, for bounded
|
|
JSON facts, `cs3` for the original event UUID and `requestContext` for the request
|
|
UUID. This preserves the existing rule, file type, trace, span and audit-integrity
|
|
fields. Configure the SIEM to parse the custom JSON string when joining causal
|
|
events. The standard `outcome` field reflects unknown authorization or failure;
|
|
Microsoft documents its mapping to `EventOutcome` in
|
|
[CommonSecurityLog](https://learn.microsoft.com/en-us/azure/sentinel/cef-name-mapping).
|
|
|
|
These format and exporter tests do not establish a customer's remote SIEM
|
|
deployment, retention, key custody or incident-response configuration. Production
|
|
browser-to-broker integration remains a separate acceptance gate.
|