What should be preserved from firewall or security alerts?¶

Firewall and security alerts can show what a system detected, blocked or allowed, but they must be preserved with their context and limits.

Avoid this assumption: An alert proves an attack occurred exactly as described. Alerts are generated by rules, thresholds and classifications that can be incomplete, mistaken or triggered by legitimate activity.

Record the appliance, service, console, account, date, time, time zone and visible filters.

Capture the alert name, severity, status, rule, signature, source and destination addresses, ports, protocol and interface.

Preserve timestamps, event IDs, session IDs, action taken, direction of traffic and any linked device or user label.

Record whether the alert was allowed, blocked, challenged, quarantined, acknowledged or closed.

Capture the full screen before opening details, changing filters or marking the alert.

Do not dismiss, acknowledge or remediate an alert merely to clear the interface. That may create new audit records or hide its original state.

Record whether the alert appears current, historic, duplicated, grouped or correlated with other events.

Do not assume the displayed geography or device name is exact.

Where an alert is part of an active incident, preserve related logs and seek incident-response support.

If the system offers raw-event, packet or export references, record them without improvising collection.

Keep detection separate from attribution. The alert may show network activity, not who caused it.

Preserve the alert category and confidence level where shown.

Operational takeaway¶

Preserve the complete alert, rule, identifiers, action and display context before acknowledgement or remediation, and treat it as a detection record requiring corroboration.