Risk Management/Remediation AND VA360

SonarG provides a facility for more efficiently managing and remediating issues related to vulnerability and sensitive data processing. The solution can be applied to database security systems already being managed within SonarG, as well as to VA and profiling data from a variety of other external systems.

Data to be reviewed is ingested and landed in the va collection for vulnerability details and the classifier collection for sensitive data scans. Each document in these collections is linked to a datasource and the datasources collection is populated with details on the source of information as well as details on the “owner” of each respective datasource. These details guide information routing as part of an automated process flow. Each datasource must have a OwnerUserName specified that is a user defined in product as a WorkflowUser application role. These users are normally created using an automated LDAP, but can also be uploaded to the system using spreadsheets, manual feeds or a fully automated integration with an external DBMS such as a CMDB.

To enable automated vulnerability and/or sensitive data management, simply toggle the switch in the Risk Management section of the SAGE application (Engines), as shown below:


This will initiate the appropriate data flows, which execute according to the following process flow:

  1. Incoming VA or Scan data is enriched with owner information from the datasources collection.
  2. Any new finding is cross referenced with previous findings that were already marked as exceptions or false positives to prevent duplicate review/reporting.

3 The actual new findings are assigned to the appropriate owner using either the Vulnerability Management or Sensitive Data Management workflows.

  1. Details on the new findings are automatically distributed to the respective owners for them to initiate review and remediation.
  2. Owners use the Justify workflow application to record remediation details on each individual event, including an indication as to whether the identified exception was a real issue or a false positive/exception.
  3. False positives and exception details are used as filtering criteria for future exceptions in order to minimize redundant reviews of known/approved exceptions.

The entire flow is shown below:


You can customize the behavior of each part of the flow by editing pipelines and then adding it in the configure part of the Risk Management engine. Each of these fields is an array of a 5-tuple. Each tuple takes the form of:

  pipeline: <name of pipeline generating tickets (after filtering false positives)>,
  feedback: <pipeline generating exceptions / false postives based on owner reporting>,
  published_by: <owner of the pipelines>,
  collection: <collection on which to run the ticket-generating pipeline>,
  expiry: <days the exception is valid for>

All exceptions are recorded in lmrm__ae.ae_false_va and all false positives in lmrm__ae.ae_false_cls.

All data is always recorded and a full history is maintained for both tickets as well as exceptions / false positives.

VA 360

SonarG receives feed from various VA tools and can combine the data into a single va360 collection from which all reporting, remediation workflow and aging data can be derived. For each external VA tool that needs to be integrated you need to setup two things:

  1. An incoming mapping through syslog events in SonarGateway or through CSV files.
  2. A pipeline to process the data into va360.

The second is defined under the Security 360 config section when VA 360 is enabled. Each structure is a document of the form:

{pipeline: 'va360_from_guardium', published_by: 'lmrm__ae', collection: 'va'}

where you specify the name of the pipeline taking data from the incoming collection into va360, who created the pipeline and the starting collection (which is the collection being populated by item 1 above).