HP Integrity rx8620 Base System A7026A プリント

Mitigating RDBMS event data management barriers  

Faced with the limitations imposed by the RDBMS solutions for event data management, SIM 

companies and their customers have adopted a number of strategies to mitigate RDBMS 

shortcomings. These strategies represent a valiant but costly effort to deal with RDBMS’ event data 

management disadvantages. If the sum of all of these strategies were successful, then this paper could 
end at this point. However, each strategy is either insufficient, risk-producing, or both.  
Data filtering 
To reduce the amount of event data that needs to be stored, one can filter to reduce the number of 

events stored, and the amount of data that is stored for each event. Though allowing event data 
storage to span longer ranges of time, filtering creates harmful side effects. Filtering pre-supposes that 

the nature of searches needed in the future is known in advance. However, unanticipated security or 

systems management scenarios may require deleted data not stored in the database, rendering 

limited value from any event data that is stored. 

Example: Denied access is monitored, but successful connections are not. If a buffer overflow 
attack is being accomplished by a server making excessive outbound FTP connections, examining 

the event data collected will fail to identify the attacking server. 

Additionally, government compliance requires that all original data be available to establish full 

context and to make sure that there is no data tampering. In general, data filtering produces an 
incomplete record resulting in limited value of the event data collected. 

Limited time range searches 
Limiting the time range requires less storage capacity. However, this approach ignores business 

imperatives that require longer-term search capability, and it may miss an attack that occurs over a 
long period of time.  

Example: For a particular company, only one week of event data is kept. A sophisticated attacker 

spreads pre-attack reconnaissance over a few weeks. Use of the available event data is unable to 

detect this low-and-slow attack. 

Limited component monitoring 
If one monitors fewer components, one needs less event data storage. However, determining which 

components do not need to be monitored, as in data filtering, presumes knowing ahead of time the 

nature of the future-event analysis.  
Discovery of new security and system management scenarios may point out the need to monitor non-
monitored components. This creates a ‘missing link’ that impedes a forensic investigation from 

uncovering root cause of a security breach. Compliance mandates typically require the monitoring of 

most components within IT infrastructures. 

Example: A hospital uncovered a risk scenario related to leakage of its VIP patient information 
through web surfing from a shared workstation also used for patient data access. To determine 

the root cause of the leakage, daily event data from window logins, web proxies, and a patient 

management application needed to be correlated for a trailing week. However, collection of 

web-proxy monitoring event data was previously eliminated to reduce RDBMS storage 
requirements. This made it impossible to discover the source of this critical scenario. 

9