User entity creation and update process

Products

• Information Centric Analytics

Issue/Introduction

When Information Centric Analytics (ICA) is integrated with Microsoft Active Directory (AD) and Symantec Data Loss Prevention (DLP), how does it create or update records for users?

Environment

Version : 6.x

Resolution

Microsoft Active Directory

The process by which AD account information is processed into ICA is as follows:

1. ICA's Active Directory Connector Utility executes Lightweight Directory Access Protocol (LDAP) queries against one or more domain controllers, as configured by the user. The results of these queries are inserted into staging tables in the database ActiveDirectoryDW and then processed into intermediary tables with some enrichment. For example:
   1. AD user account records are initially staged in the table dbo.stg_User. This table is truncated prior to staging.
   2. The records in dbo.stg_User are merged into the table dbo.User, where additional metadata for each record is stored. For example, if a user record was previously imported from AD but is no longer returned by LDAP query, indicating the record no longer exists in AD, the bit column DeletedByMerge is set to 1.
2. ICA's nightly RiskFabric Processing job queries the ActiveDirectoryDW database and inserts the results into staging tables in the RiskFabric database. The records are then inserted into pre-processing tables, enriched, and inserted or merged into ICA's core tables where the data will rest. The principal user entity table in the RiskFabric database is dbo.LDW_Users.

Note that user data from AD is only imported into the ActiveDirectoryDW database by the Bay Dynamics AD Connector Job, which runs once each day. By default, this job is scheduled to run at 20:00 (8:00 PM). AD records are only processed into ICA's RiskFabric database during the RiskFabric Processing job, which runs once each day. By default, the job is scheduled to run at 00:15 (12:15 AM).

Symantec Data Loss Prevention

The process by which users associated with DIM incidents are processed into ICA is as follows:

1. ICA imports DIM incidents from DLP into staging tables within the RiskFabric database during step 4 ('Run Staging Procedures') of the nightly RiskFabric Processing job and, if enabled, the RiskFabric Intraday Processing job.
   NOTE: Unlike AD records, DLP records are not staged in a separate database prior to ingestion into the RiskFabric database.
2. Staged records are passed through pre-processing tables for mapping and enrichment, followed by processing into ICA's core tables.
   1. During processing, the NetBIOSDomain and sAMAccountName pair of the source user on each incident is compared against corresponding paired columns in the dbo.LDW_Users table. If a match is found, the incident is linked in the table dbo.LDW_DIMIncidents to the matched record's UserID (stored in dbo.LDW_Users) and labelled as the SourceUserID on the incident record. If a match is not found, a new record is created in dbo.LDW_Users containing the NetBIOSDomain and sAMAccountName values from the incident.
   2. If there are no NetBIOSDomain and sAMAccountName values associated with a DIM incident (this is typical of Network Prevent incidents), ICA evaluates the NetworkSenderIdentifier value. For SMTP protocol incidents, this is typically an e-mail address. If this is matched to an e-mail address on an existing record in dbo.LDW_Users, the record's UserID is associated with the incident as described above.
   3. Users who are recipients of messages that trigger policy violations and generate DIM incidents are identified in the same manner as steps 2.1 and 2.2 above. Each user entity has a record in the table dbo.LDW_Users. Unlike source users, however, their association with incidents is mapped in the table dbo.LDW_DIMIncidentsToUserDestinations.

Please note that, as illustrated by the order of operations outlined above, it's important when integrating data sources to proceed in this order:

1. Integrate AD
2. Import AD users by running the Bay Dynamics AD Connector Job
3. Integrate DLP
4. Process users and incidents by running the RiskFabric Processing job

Performing these steps in this order will ensure incidents imported from DLP are matched to the correct AD user and its corresponding attributes. If AD records are imported subsequent to integrating DLP, the stored procedure dbo.spLDW_UpdateADUsers will match on NetBIOSDomain and sAMAccountName and update the AD attributes for matched records in dbo.LDW_Users, but certain AD attributes stored with incidents in dbo.LDW_DIMIncidents will be missing (for example, SourceManagerUserID, OrganizationID, CountryID).

If you have integrated DLP prior to AD, contact Broadcom for assistance.