Justification Application (Workflow)

Guardium Big Data Intelligence has two workflow systems. Justify is an event-level workflow that allows you to assign any generated event in the system by user or by role, manage the event’s status transitions, manage attachments and more. This is the workflow application used most often within Guardium Big Data Intelligence. In addition, the system also allows managing a workflow process per output of a scheduled job - e.g. per report (PDF or CSV). In this case the entire report can be sent to a user for getting sign-off. Both systems use the same application; the difference is in the granularity of what gets reviewed, justified and approved.

To use the Justify (workflow) application a user needs to have the WorkflowUser application role.

Report-Level Workflow

When scheduling a job for delivery, select the “Require sign-off” checkbox if you want the deliverable and the sign-off to be tracked by workflow. The report will be emailed to the user as usual but a workflow task will also be created for tracking and sign-off. One or more workflow events may be created based on how many users have the delivery email. The system will look up users with that email in three places:

  1. If a user’s username is the email itself an event will be created and assigned to that user.
  2. If a user in the lmrm__ae.managed collection has the email, that user will be assigned an event. This collection is the main user-role definition collection for Justify workflow applications.
  3. If a user with that email is defined in the sonargd.lmrm__users_email collection, that user will be assigned an event. This is the collection that contains user-email association populated from a pull from LDAP.

Report-level workflow is a built-in Justification workflow called “Report Sign-Off” with a very simple structure. It has only two statuses - OPEN and CLOSE and a single transition called CLOSE. Events are assigned directly to the user based on the email mapping and the report is attached to the event as an attachment.

Event-Level Workflow

Event-level workflows are processes that allow an event to be routed through an organization. You define what the workflow looks like - what statuses exist, what transitions exist, what custom fields exist (allowing people to document and record data), and define how the event will be generated.

Any data can be part of an event that is routed through a process. Everything starts with a report or a pipeline. A pipeline generates data and you control what fields are part of the pipeline’s output. To create events you schedule a job and select “Justify” as the Output type. Each document in the output will generate and assign an event. See the section on Building Workflows to control which workflow will be selected per pipeline.

Once a workflow ticket is created it is routed through people’s queues based on status definitions, transitions, permissions and a management hierachy. A person has a queue to tickets assigned to them, assigned to one of the roles that they belong to, or asigned to one of the people that they manage. A person will only be able to work on a ticket if it is in a status that they have permission to transition from. A person can always see and comment on tickets that they have already worked on. A manager can see and work on any ticket that one of their managed people can (i.e. the permissions are inheritted-up). If an organization is defined per ticket then only people who also belong to this organization may view and work on it.

A full history of all transitions, comments and attachments is fully maintained by the system and no event, comment or transition may be deleted from the system.

Building Workflows

To build workflows the user needs to have the WorkflowManager application role.

To add a new workflow open the Justify application and click the Add New Workflow button. To edit an existing workflow select it from the list on the left and clisk on Configure. Each workflow has a name, a final status and a set of piplines. These pipelines are the “feeders” that will create events governed by the workflow. Specify the pipeline name, who it is published by, the initial status, the assignment method and (optionally) the organization association method.

Assignment of events can be by user or by role. User assignment means that a particular user will need to handle the ticket (although, the user’s managers will also be able to see/work on the ticket). Assignment to role means that any user having this role can work on this ticket. In both cases determining which role or which user will be assigned can be by a hard-coded value or by taking a value from the pipeline’s document using a field name.

Organization (optional) is determined similarly using either a value for a field or a hard-coded value.

Once a workflow has been defined and the pipelines mapped you can define the statuses and transitions between the status. Each transition can also have any number of custom fields that the user reporting the transition should/can enter. You also define which users/roles can view tickets by roles and which transitions a user can perform by roles.

State and transition permissions are defined by the WorkflowManager. Per role, the WorkflowManager can define which states that role can see and which transitions that role can do. It is important to understand how these work:

  1. State Permissions: A ticket can be assigned to a user or to a role. Regardless of what role permissions have been assigned to the states, a user may always see tickets that are assigned to him (by name), tickets that the user has already worked on, tickets assigned to any person they manage, or tickets that are assigned to one of the roles they belong to. Additionally, if a user has a role that has explicitly received permission to the state then they can see any tickets in that state.
  2. Transitions: A transition is available to a user only if that transition permission has been granted to one of the roels they belong to.

When defining a transition to a non-final state you also define what the next assignment is - either by user, by role, by history (e.g. assign to the same person who was working on it in the past at a certain state). This allows you to route tickets through different stakeholders and ensure that each ticket sits in the right persons’ queues.

User roles are defined in the managed collection in the lmrm__ae database and usually populated through an LDAP pull but you can also manage these in the WorkflowManager GUI.


When you activate Workflow Services in the SAGE configuration screen a daily email will be sent to every user detailing the open tickets that they should be working on. You can configure the cron schedule for this automated email.

In addition, the administrator will receive a daily email of all tickets that have been open for more than X days or tickets that have not been worked on for Y days (configurable).


Each user can assign a delegate. A delegate assignment defines a time period during which any ticket that would have been assigned to the individual will be assigned to the delegate instead.

Predefined Reports

The predefined reports pull down allows you to run/schedule a report for all tickets you have been involved with using a varierty of filters and all pending (non-closed) tickets assigned to you. The admin reports include similar reports for all users.

Built-In Workflows

In addition to the Report Sign-Off built-in workflow used as report-level workflows there are three additional built-in workflows that come with the system: the Outlier Incidents workflow, the Trusted Connections workflow and the Trusted Connections Revalidation workflow.

Outlier Incidents Workflow

When you configure the Machine Learning Engine in SAGE you can specify a user to which new outliers are assigned. If you specify this user every time a new outlier is flagged a workflow event will be created and assigned to this user. The workflow only have an OPEN and a CLOSE state with one transition.

Trusted Connections Workflow

When you use the Trusted Connections Engine in SAGE and configue to use Workflow to accept new trusted connections, and new trusted connection candidate will create a workflow event. If you do not choose to enrich the data then all these events will be assigned to the admin user. Add an enrichment collection mapping between the server IP and the user to assign the events dirtectly to the appropriate owners. Each such event starts in the OPEN state detailing the details of the connection. To close and event you must specify whether to trust the connection or not and what the reason is. Once you determine if the connection is trusted this will update the trusted connections collection which drives the called to update the Guardium groups used for filtering traffic.

Trusted Connections Revalidation

When you use the Trusted Connections Engine in SAGE and configue to use Workflow to revalidate trusted connections, existing trusted connections will generate revalidation events routed to the owner. Revalidation events require a YES/NO decision and a reason in the same way as trusted connection events.

Vulnerability Management

When you use the Risk Management - Vulnerability Management service in SAGE all vulnerabilities will be routed to their respective owner for remediation or to allow them to record an exception.

Sensitive Data Management

When you use the Risk Management - Sensitive Data Management service in SAGE all vulnerabilities will be routed to their respective owner for remediation or to allow them to record a the finding as a false positive.

Known Issues:

  • When you add a WorkflowUser role to a user, that user will not be able to access Justify tickets until one of the WorkflowManagers clicks the “Reload Data” option.