Format of Security Alerts

Network data collected to support threat analysis, fault diagnosis, and intrusion report correlation may range from simple MIB statistics to detailed activity reports produced by complex applications such as intrusion or anomaly detection systems. So far, we have used the term security alert loosely to refer to site-local activity produced by a network security component (sensor) as it reports on observed activity or upon an action it has taken in response to observed activity. A security alert can represent a very diverse range of information, depending on the type of the security device that produced it. In this section, we consider the typical content of security alerts from the three primary types of alert contributors used in the context of Internet-scale threat analysis centers.

Table 1: Summary of security alert content.

Source_IP	FW,ID	Typically refers to the source IP address of the machine that initiated the session or transferred the transaction that caused the alert to fire. In IDS alerts, this field may represent the victim, not the attacker, since some systems alert upon an attack reply rather than request.
Source_Port	FW,ID	Source TCP or UDP port of the machine that initiated the session or transferred the transaction that caused the alert to fire.
Dest_IP	FW,ID,AV	Typically refers to the destination IP address of the machine that initiated the session or transferred the transaction that caused the alert to fire. In AV systems, Dest_IP can identify the machine in which the infection is discovered.
Dest_Port	FW,ID	Destination TCP or UDP port of the machine that initiated the session or transferred the transaction that caused the alert to fire.
Protocol	FW,ID	Protocol type (e.g., UDP, TCP, ICMP).
Timestamp	FW,ID,AV	May incorporate incident start time, end time, incident report time.
Sensor_ID	FW,ID,AV	May incorporate the brand and model of the sensor and a unique identifier for the individual instantiation of the sensor.
Count	FW,ID,AV	Often used to represent some notion of repeated activity, either at the alert or event (e.g., packet) level.
Event_ID	FW,ID,AV	Uniquely defines the alert type for the given sensor.
Outcome	FW,ID,AV	Reports the status or disposition of the reported activity. For firewalls, it may report whether the log entry was associated with an allow or deny rule. For AV, it may indicate infection disposition (e.g., Symantec's AV indicates whether the infected file is cleaned or quarantined). Outcome fields for IDS tools are highly vendor-specific.
Captured_Data	ID	Some IDS sensors have the ability to report part or all of the data content in which the alert was applied.
Infected_File	AV	Antivirus logs include the identity of the file that was infected.

Firewalls reside at the gateways of networks, and contribute reports that indicate ``deny'' and ``allow'' actions for traffic across the gateway boundary. Most typically, firewalls contribute alerts flagging incoming packets that were denied. Volume, port, and source distribution patterns of such packets provide significant insight into the probe and exploit targets of malicious systems, new attack tools, and self-propagating malicious applications.

Intrusion detection systems include network- and host-based systems, and may employ misuse or anomaly detection. Unlike firewalls, intrusion detection reports may represent a wide variety of event types, and can report on anomalous phenomena that span arbitrarily long durations of time or events.

Antivirus software reports email- and file-borne virus detection on individual hosts. Reports include virus type, infection target, and the response action, which is typically to clean or quarantine the infection.

Table 1 summarizes the fields that constitute a typical firewall (FW), intrusion detection (ID), or antivirus (AV) security alert in its raw form, prior to data sanitization.