Sentinel receives information from devices, normalizes this information into a structure called an event, categorizes the event, and then sends the event for processing. By adding category information (taxonomy) to events, events are easier to compare across systems that report events differently. For example, authentication failures. 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 and destination port. There are two sets of configurable fields: Reserved fields are for Sentinel internal use to allow future expansion and Customer fields are for customer extensions.
Fields can be re-purposed by renaming them. The source for a field can either be external, which means that it is set explicitly by the device or the corresponding Collector, or referential. 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 defined to be the building code for the building containing the asset mentioned as the destination IP of an event. For example, a field can be computed by the mapping service using a customer defined map using the destination IP from the event.
The Mapping Service allows a sophisticated mechanism to propagate business relevance data throughout the system. This data can enrich events with referential information that will provide context that enables analysts to make better decisions, write more useful reports, and write well-thought out correlation rules.
You can enrich your event data by using maps to add additional information such as host and identity details to the incoming events from your source devices. This additional information can be used for advanced correlation and reporting. The system supports several built-in maps as well as custom user-defined maps
Maps that are defined in Sentinel are stored in two ways:
Built-in maps are stored in the database, updated using APIs in Collector code, and automatically exported to the Mapping service.
Custom maps are stored as CSV files and can be updated on the file system or via the Map Data Configuration UI, 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 buildup of large static maps in dynamic memory. The value of this streaming capability is particularly relevant in a mission-critical real-time system such as Sentinel where there needs to be a steady, predictive and agile movement of data independent of any transient load on the system.
Sentinel provides the ability to cross-reference event data signatures with Vulnerability Scanner data. Users are notified automatically and immediately when an attack is attempting to exploit a vulnerable system. This is accomplished through:
Advisor Feed
Intrusion detection
Vulnerability scanning
Firewalls
Advisor provides a cross-reference between event data signatures and vulnerability scanner data. Advisor feed contains information about vulnerabilities and threats as well as a normalization of event signatures and vulnerability plug-ins. For more information on Advisor, see Configuring Advisor
in the NetIQ Sentinel 7.1 Administration Guide.