Sentinel receives information from devices, normalizes this information into a structure called an event, categorizes the event, and then sends the event for processing.
An event represents a normalized log record reported to Sentinel from a third-party security device, network or application device, or from an internal Sentinel source. There are several types of events:
External events (events received from a security device) such as:
An attack detected by an intrusion detection system (IDS)
A successful login reported by an operating system
A customer-defined situation such as a user accessing a file
Internal events (events generated by Sentinel), including:
A correlation rule being disabled
The database filling up
Sentinel adds category information (taxonomy) to events, to make it easier to compare events across systems that report events differently. Events are processed by the real time display, correlation engine, dashboards, and the back end server.
An event comprises more than 200 fields; event fields are of different types and of different purposes. There are some predefined fields such as severity, criticality, destination IP address, and destination port.
There are two sets of configurable fields:
Reserved fields: For Sentinel internal use to allow extension of functionality in future.
Customer fields: For customer use to allow customization.
The source for a field can either be external or referential:
The value of an external field is set explicitly by the device or the corresponding Collector. For example, a field can be defined to be the building code for the building containing the asset mentioned as the destination IP address of an event.
The value of a referential field is computed as a function of one or more other fields using the mapping service. For example, a field can be computed by the mapping service using a customer defined map, using the destination IP address from the event.
The Mapping Service propagates business relevance data throughout the system. This data can enrich events with referential information.
You can enrich your event data by using maps to add additional information, such as host and identity information, to the incoming events from your source devices. Sentinel can use this additional information for advanced correlation and reporting. Sentinel supports several built-in maps, and also customized user-defined maps.
Maps that are defined in Sentinel are stored in two ways:
Built-in maps are stored in the database, updated internally, and automatically exported to the Mapping service.
Custom maps are stored as CSV files and can be updated on the file system or by using the Map Data Configuration User Interface, then loaded by the Mapping service.
In both cases, the CSV files are kept on the central Sentinel server but changes to the maps are distributed to each Collector Manager and applied locally. This distributed processing ensures that mapping activity does not overload the main server.
The Map Service employs a dynamic update model and streams the maps from one point to another, avoiding the accumulation of large static maps in the dynamic memory. This is relevant in a mission-critical, real-time system such as Sentinel where a steady, predictive, and agile movement of data, independent of any transient load on the system is required.
Sentinel provides the ability to cross-reference event data signatures with Vulnerability Scanner data. Sentinel notifies users automatically and immediately when there is an attempt to exploit a vulnerable system. Sentinel accomplishes this through the following functions:
Advisor feed
Intrusion detection
Vulnerability scanning
Firewalls
Advisor feed contains information about vulnerabilities and threats, and also a normalization of event signatures and vulnerability plug-ins. It provides a cross-reference between event data signatures and vulnerability scanner data. For more information on Advisor feed, see Detecting Vulnerabilities and Exploits
in the Sentinel Administration Guide.