HP Integrity rx1620 Server 1.30 GHz HP-UX Developers Bundle AB430A#006 Prospecto
Los códigos de productos
AB430A#006
Unique characteristics of event data
By understanding the objectives of RDBMS technology and the characteristics of event data, one can
show how well event data maps onto RDBMS technology.
Non-transactional
Event data is non-transactional. It is meant to be stored, searched, removed and archived. Once event
data is stored, it cannot be updated. In fact, for compliance purposes, altering and deleting event
Event data is non-transactional. It is meant to be stored, searched, removed and archived. Once event
data is stored, it cannot be updated. In fact, for compliance purposes, altering and deleting event
data should be strictly prohibited. Although there are some transactional semantics for event data,
they are not the same, nor as stringent, as those for relational data.
Time-based
Event data is a collection of data about a particular event at a specific point in time. Thus, every event
will have a time stamp associated with it. Any search on event data is likely to have some time
Event data is a collection of data about a particular event at a specific point in time. Thus, every event
will have a time stamp associated with it. Any search on event data is likely to have some time
boundary.
Field repetitiveness
Event data is generally repetitive. For example, a company may have a relatively small set of
authorized users. Event data for successful connection events will repeat this small set of authorized
Event data is generally repetitive. For example, a company may have a relatively small set of
authorized users. Event data for successful connection events will repeat this small set of authorized
users over and over again. Other examples of highly repetitive data are URLs, IP addresses, and IDS
signatures.
Time-based archival or removal
All event data is eventually removed, or archived, based on aging, as determined by systems or
security management requirements.
All event data is eventually removed, or archived, based on aging, as determined by systems or
security management requirements.
Variable search requirements
Searches on event data can be precise or pattern-oriented. For example, one search may require a
Searches on event data can be precise or pattern-oriented. For example, one search may require a
precise matching of a user and another may be based on URL patterns such as ‘hotmail.com’.
Although both kinds of searches must be supported, most event log data is unstructured and must be
Although both kinds of searches must be supported, most event log data is unstructured and must be
searched with some form of pattern matching. The storage of event data cannot be organized to
optimize precision searches. The unstructured nature of event data resists query optimization using
indices.
Evolving search requirements
Event data search requirements evolve with the security and systems management landscape. New
Event data search requirements evolve with the security and systems management landscape. New
searches must be created to detect newly discovered security threats, or to monitor new system
components. This can happen daily or weekly. During a forensic process, the results on one search
will determine the nature of the next search. Due to the unpredictable nature of rapidly evolving
search requirements, it is insufficient to have an event storage system optimized for current
search requirements, it is insufficient to have an event storage system optimized for current
requirements. In contrast, RDBMS databases have query requirements which are static, or evolve
slowly with the gradual introduction of new application requirements.
Stream-based loading
Event data is created in real time and must be loaded as fast as it is created. Although all event data
does not need to be available in real time, the load rate must keep pace with the creation rate in the
Event data is created in real time and must be loaded as fast as it is created. Although all event data
does not need to be available in real time, the load rate must keep pace with the creation rate in the
long run. Unlike relational data, the load rate cannot be slowed down by reducing response time.
System components create event data at a rate based on their usage, independent of the event data
load rate.
6