GBDI 4.2

GBDI Data Model

GBDI maintains many collections for Guardium data (depending on Guardium version and which GBDI data marts you configure). Some examples are:

  • Session – All session data; one document per database session captured by Guardium.

  • Instance – One document per activity per time period; referencing the session (and embedding some of the important session attributes) as well as the object-verb information.

  • Exception – One document per recorded exception along with session information and the SQL that caused the exception.

  • Full SQL – One document per request sent to the database including session data and the SQL itself; this data is only recorded by Guardium with a LOG FULL DETAILS audit policy.

  • Outlier data – When using Guardium V10 and up, outlier data (both summary and details) is also copied to GBDI into two separate collections.

  • Group data – Group member data is copied from a Guardium system, usually from the CM (but possibly from any appliance).

  • DM Extract log – Data on records extracted from the Guardium appliances is copied from the Guardium appliances.

Each of these collections is central to running GBDI queries and the GUI, whether using the custom GBDI GUI or JSON Studio, processing begins with selecting one of these collections to query.

In addition to the data models specified above, any data housed within the Guardium system can be extracted into GBDI using the Guardium Data Mart mechanism. For example, you are able to export STAP health metrics into the GBDI warehouse and use this information as the basis for a STAP health performance dashboard.

These are the main databases in the system:

  • admin – Internal to app; maintains admin info

  • lmrm__ae – Internal to app; maintains data related to analytic engines and built-in app

  • lmrm__scheduler – Internal to app; maintains scheduling and job dispatch queues

  • lmrm__sonarg – Internal to app; main metadata database

  • sonar_log – Internal to app; maintains profiling data

  • sonargateway – Internal to app; maintains data used by ingestion layer

  • sonargd – Main database used for storing data related to Guardium and other security consoles

These are the main collections in the sonargd database (used for SonarG and GBDI):

  • classifier – Data related to classification of sensitive data scans

  • classifier_log – Log records related to invoked scans

  • databases_discovered – Data related to discovery of databases using scans such as nmap

  • datasources – Datasource data; datasources are used for classifier scans, VA scans etc.

  • db_error_text – Mapping between database error codes and error texts

  • discovered_instances – Data related to instances discovered through the agents

  • exception – Data related to errors and exceptions such as failed logins and sql errors as reported by the database

  • full_sql – Data related to the SQL statements including the statement and bind values

  • gfiles, grdm, grdmrec and grdmcomplete – Tracking data on DM files processed by the ETL layer; internal to app

  • group_members and group_members* - Group member data from each of the CMs

  • installed_patches – Data related to the patches installed on each of the appliances

  • installed_policy – Data related to policy rules installed on each of the appliances

  • instance – Query data at hourly granularity with a count as to how many times each such query (contruct) per session occurred within the hour

  • outliers_list – Detailed data from Guardium outlier detection

  • outliers_summary – Summary data from Guardium outlier detection

  • policy_violations – Data related to each violation as fired by policy rules

  • session – Session-level data logged for each logon and logoff to a database. There is a separate record for logon and logoff.

  • stap_status – Data related to the status of STAP

For more information on data marts and data sets see the following DeveloperWorks article: