v3.2 Data Risk Analytics User Guide 3-21-2023

v3.
2 Data Risk Analytics User Guide
v3.2 Data Risk Analytics User Guide
v3.2 Data Risk Analytics User Guide 1

Contents
Contents
Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
End User License and Services Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Introducing Data Risk Analytics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Document Conventions and Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Configuring Data Risk Analytics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Overview of Data Risk Analytics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Setting Up Data Risk Analytics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Responding to Incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Employee Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Allow List Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Closing Incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Filtering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Exporting Incidents Issues and Anomalies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Anomalies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Managing Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
System Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Health Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
User and Role Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Active Directory Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Active Directory Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Active Directory Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Incident Responders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Application Owners. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Security Engineers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Admin Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Security Event Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Email Notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
SIEM Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Placeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Active Directory Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Licenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
License Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Uploading Licenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Contents
Managing Licenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Advanced Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Encrypted Archive File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Changing Policy Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
cbctl Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Installing Custom Certificate in Admin Server for SSL Communication with Browser. . . . . . . . . . . . 119
Installing Custom Certificate in Admin and Analytics Servers for SSL Communication. . . . . . . . . . . 120
Understanding Incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Database Access at Non-standard Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Database Service Account Abuse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Excessive Database Record Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Excessive Failed Logins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Excessive Failed Logins from Application Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Excessive Multiple Database Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Machine Takeover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Suspicious Sensitive System Tables Scan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Suspicious Application Data Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Suspicious Database Command Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Suspicious Dynamic SQL Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Excessive File Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Excessive Personal File Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Slow Rate File Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Slow Rate Personal File Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Suspicious File Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Understanding Health Status Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Admin Server Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Admin server components are not fully functioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Failed to connect to the Admin server. Unmatched version on the Analytics server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Analytics Server Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Analytics server components are not fully functioning, and thus data cannot be processed successfully. . . . . . . . . . . 145
Analytics server configuration not synced with the admin server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Analytics server disk space usage exceeds 90% of the capacity: x/y GB used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Analytics server disk space usage exceeds 95% of the capacity: x/y GB used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Analytics server failed to process DB/file/DB & file information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Analytics server(s) is(are) not configured. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Analytics server is utilized at X% of its capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Audit data from [fromTime]-[toTime] from policy [PolicyName] received from SecureSphere gateway [GatewayName]
could not be processed successfully. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Contents
Audit data from file [file-name] failed to load. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Audit data from file [file-name] failed to load. Audit data handling failed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Audit data from file [file-name] failed to load. Corrupted audit data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Audit data from file [file-name] failed to load. File is encrypted and no matching decryption key was found. . . . . 156
Audit data from file [file-name] failed to load. Policy is not configured correctly in SecureSphere. . . . . . . . . . . . . . . 157
Audit data from file [file-name] failed to load. Policy name is unrecognized. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Audit data from policy [PolicyName] from SecureSphere gateway [GatewayName] has not been received for
[NumOfDays] days.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Database/File audit data received on [Date] was only partially processed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Failed to connect from the Analytics server to the Admin server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Failed to connect to Analytics server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Failed to connect to Analytics server. [IP/host] unknown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Failed to connect to Analytics server on [IP]. Password does not match. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Failed to retrieve data from Analytics server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
High CPU usage: X% on average. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Active Directory Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Active directory [ADName] cannot be accessed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Active directory [ADName] cannot be accessed. Bad username or password. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Active directory [ADName] cannot be accessed. Host cannot be resolved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Active directory [ADName] cannot be accessed. Please make sure all the parameters are set correctly and that the
active directory server is reachable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Active directory [ADName] cannot be accessed. Unknown host/IP or port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
No Groups found under Active Directory [ADName]. Please check the base search path is configured correctly. . . . . 173
No users found under Active Directory [ADName]. Please check the base search path is configured correctly. . . . . . . 174
Active Directory is not configured. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
General Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
General Error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Data Risk Analytics REST API Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
URL Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
HTTP Basic Authentication Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
HTTP Return Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Security Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Get Security Events: Incidents/Anomalies/Both (v1.0). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Get Security Events: Incidents/Anomalies/Both (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Get Event Class (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Get Incident Database Names (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Contents
Get Anomaly Database Names (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Update Event Class (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Update Incident (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Update Anomaly (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Get User’s Permissions (v1.0). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Get Incident Responder User’s Permissions (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Get Application Owner User’s Permissions (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Get Restricted Data (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Update Incident Responder User’s Permissions (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Update Application Owner User’s Permissions (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Update Restricted Data (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Allow List Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Get Allow List Rule List (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Get Specific Allow List Rule (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Get Relevant Fields Per Group of incidentType (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Add/Update/Delete Allow List Rule (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Copyright Notice
© 2002 - 2021 Imperva, Inc. All Rights Reserved.
Follow this link to see the SecureSphere copyright notices and certain open source license terms:
https://www.imperva.com/sign_in.asp?retURL=/articles/Reference/CounterBreach-License-and-Copyright-
Information
This document is for informational purposes only. Imperva, Inc. makes no warranties, expressed or implied.
No part of this document may be used, disclosed, reproduced, transmitted, transcribed, stored in a retrieval system,
or translated into any language in any form or by any means without the written permission of Imperva, Inc. To obtain
this permission, write to the attention of the Imperva Legal Department at: 3400 Bridge Parkway, Suite 200, Redwood
Shores, CA 94065.
Information in this document is subject to change without notice and does not represent a commitment on the part of
Imperva, Inc. The software described in this document is furnished under a license agreement. The software may be
used only in accordance with the terms of this agreement.
This document contains proprietary and confidential information of Imperva, Inc. This document is solely for the use
of authorized Imperva customers. The information furnished in this document is believed to be accurate and reliable.
However, no responsibility is assumed by Imperva, Inc. for the use of this material.
TRADEMARK ATTRIBUTIONS
Imperva and SecureSphere are trademarks of Imperva, Inc.
All other brand and product names are trademarks or registered trademarks of their respective owners.
PATENT INFORMATION
The software described by this document is covered by one or more of the following patents:
US Patent Nos. 7,640,235, 7,743,420, 7,752,662, 8,024,804, 8,051,484, 8,056,141, 8,135,948, 8,181,246, 8,392,963,
8,448,233, 8,453,255, 8,713,682, 8,752,208, 8,869,279 and 8,904,558, 8,973,142, 8,984,630, 8,997,232, 9,009,832,
9,027,136, 9,027,137, 9,128,941, 9,148,440, 9,148,446 and 9,401,927.
Imperva Inc.
General Information: info@imperva.com
One Curiosity Way, Suite 203
Website: http://www.imperva.com
San Mateo, CA 94403
Tel: +1 (650) 345-9000
USA
Imperva-Data-Risk-Analytics-v3.2-User-Guide-v1

End User License and Services Agreement
To view the End User License and Service Agreement for this product, please visit https://www.imperva.com/legal/
license-agreement/.

Overview
Data Risk Analytics is a security solution that provides protection to the databases in your environment. This chapter
introduces Data Risk Analytics and provides a short description of its main capabilities. It includes the following
sections:
• Introducing Data Risk Analytics

• Intended Audience
• Document Conventions and Terminology

Introducing Data Risk Analytics

Imperva Data Risk Analytics protects enterprise data stored in databases and file shares from the theft and loss
caused by:
• Compromised users whose credentials are stolen, or who unknowingly introduce malware into the enterprise
• Malicious users who deliberately steal or tamper with corporate assets
• Careless users who inadvertently put sensitive data at risk
Data Risk Analytics dynamically learns users’ normal data access patterns and then identifies inappropriate or abusive
access activity in order to proactively alert IT teams to dangerous behavior.

Intended Audience
This guide is intended for system administrators who are tasked with the configuration and ongoing maintenance of
Data Risk Analytics.

Document Conventions and Terminology

In this document, the following typographical and formatting conventions are used:
Typographical and Formatting Conventions
Convention Meaning Example
The monospaced font is used for CLI commands

command cd /tmp
or output, and for file names.
| separates optional values in lists oranges | apples
indicates a placeholder which must be replaced

[]
with a relevant value
The following terms where changed:
Terms Changed
Term Changed To
Whitelist Allow List Rules
Whitelisted Part of an existing allow rule

Configuring Data Risk Analytics

This chapter details the steps required to configure Data Risk Analytics to identify compromised, careless and
malicious users.
This chapter includes:
• Overview of Data Risk Analytics

• Setting Up Data Risk Analytics

Overview of Data Risk Analytics

Data Risk Analytics uses machine learning and peer group analytics to automatically uncover anomalous data access
events. This establishes a full contextual baseline of typical user access to database tables, files stored in file shares
and objects stored in cloud apps, and then detects and prioritizes anomalous activity. This baseline is built using not
just data objects and users, but also incorporates items like differences in access types (e.g., application vs. human),
different data types (e.g., system vs. application), account types (e.g., user vs. service vs. DBA), machine types, query
tools used, time and length of access and network information.
By design, Data Risk Analytics looks at not only a single request, but also requests over time (e.g., last hour, last day,
last week) and compares this to the baseline. This avoids triggering on a single request by mistake (false positive) or
missing a slow abusive behavior over time (false negative). Data Risk Analytics is also able to compare the behavior of
a given user to the behavior of that user’s peers.
The following diagram illustrates the Data Risk Analytics solution architecture.

Setting Up Data Risk Analytics

Setting up Data Risk Analytics consists of the following main tasks:
Task Overview Description For more information, see
Instructions on how to install and

Installation and Configuration of See the Imperva Data Risk
1 setup the Data Risk Analytics
Data Risk Analytics Analytic Installation Guide
Analytics and Admin Servers.
Configuring the Imperva On-

Premises Management Server to
Configuring Imperva On-Premises archive audit data to the Data Risk See the Imperva Data Risk
2
for Data Risk Analytics Analytics Analytics Server so that it Analytics Installation Guide
can be analyzed by Data Risk
Analytics as part of Analytics.

Responding to Incidents
When suspicious events or risky behaviors are detected, Data Risk Analytics notifies you via the Open Incidents page
and optionally by email (see Optional Configuration). You can then investigate, star incidents in order to analyze them
later on, perform a search for a specific incident, filter (see Filtering), create Allow List rules (see Allow List Rules),
export to a file (see Exporting Incidents and Anomalies) or close the incident (see Closing Incidents).
The Open Incidents page aggregates all detected suspicious activities in table format. It shows general details on each
open incident and enables further drill down on each incident for more comprehensive details.


General details shown for each incident may include:
Incident Details
Field Description
Opens a dialog box showing all the issues that this incident is related to. You can click on
Related Issues
an issue to jump to the Issue Details page and view its details.
ID The incident ID number.
The severity of the issue Low, Medium, High or Critical and the priority score. The
Severity severity and priority score are assigned by Data Risk Analytics using an internal scoring
system.
Type The specific incident type detected (e.g. Suspicious Application Data Access).
Event Time The time and date the event occurred.
User Name The name of the user that performed the suspicious activity.
The host name and IP address of the machine from which the suspicious activity
Source Host
originated.
Depending on the type of server to which the suspicious activity was intended, the
following details are shown:
• Host
• Destination IP address
• Database User
Destination • Database Name
• Cluster Name - For IBM DB2 for z/OS, this is the data sharing group
• Cluster Member
The destination server type can be:
• - Databases (including IBM DB2 for z/OS standalone subsystem)

Field Description
• - Clustered Databases (currently supporting only IBM for z/OS data sharing
group)
• - File Server
Comment The comment that was entered in the Incident Details page.
When you click on an incident in the table, you are shown a more comprehensive details page about the incident. In
addition to the details, you can close the incident, export the incident details or create an Allow List rule from this
page.


Comprehensive details include:
Comprehensive Incident Details
Field Description
A detailed description of the incident stating the activity performed, by whom, from
where and to where.
Description
You can click Learn how to investigate this type of incident to jump to the Data
Risk Analytics Incidents Online Help where you can get in depth details on each of
the incidents Data Risk Analytics is warning against.
A field where you can type any information that would further assist in understanding
Comment
the incident.
Severity Influencing
Information on the reasons for deciding on the level of severity set for the incident.
Reasons
Full details of the source that performed the suspicious action and the destination on
which the action was performed.
Source and Destination
Details
Note: For IBM Db2 for z/OS cluster and IBM Db2 for z/OS database that is NOT part of
a cluster destinations, the details presented are Cluster Name and Cluster Member.
Specific information about what was accessed, operations performed by the source,
etc.
Incident Details
In order to provide all the incident details as they were received from Imperva On-
Premises, a Get Full DB Operations Info button is provided here. This button
appears for certain database and file incidents only.
Information about the typical activity conducted when accessing this asset in
Typical Behavior
addition to typical activity conducted by this user.
• Employee Profile
• Allow List Rules
• Closing Incidents
• Filtering
• Exporting Incidents Issues and Anomalies

• Anomalies

Employee Profile
The Employee Profile page aggregates all the information collected on the particular employee. The information is
given in three tabs:
• Dashboard - This tab aggregates all the information collected on the employee and presents it via widgets in a
dashboard format. The information presented includes:
• Employee Details - If you configured active directory integration, this widget presents employee
details such as email, phone numbers and office location. You can click the Show More link to jump to
the Employee Details tab where you can see the full details on the employee including the Manger
details.
• Incidents - This widget, presents a graphical view of the employee's number of incidents by severity.
You can click the Show More link to jump to the Incidents page where you can view the incidents and
drill down for more information.
• Anomalies - This widgets presents a graphical view of the employee's number of anomalies on a scale
of Low to High. You can click the Show More link to jump to the Anomalies page where you can view
the anomalies and drill down for more information.
• Endpoints Activity - This widget presents details on the amount of endpoints that were used to access
the resources by the employee. You can click the Show More link to jump to the Behavior Profile tab
where you can see the full details on the endpoints activity.
• Databases Activity - This widget presents details on the amount of databases that were accessed by
the employee. You can click the Show More link to jump to the Behavior Profile tab where you can see
the full details on the databases activity.
• File Activity - This widget presents details on the daily amount of files that were accessed by the
employee. You can click the Show More link to jump to the Behavior Profile tab where you can see the
full details on the file activity.


• Employee Details - If you have configured active directory integration, this tab aggregates and presents all the
information about the employee from the active directory.

• Behavior Profile - This tab indicates the behavior profile of the employee as per their activities. It presents in
full detail the employee endpoints, databases and file activities. This enables you to get a clear picture of their
behavior not only as an individual, but in comparison to their team and the organization.



Allow List Rules

In each organization, activities may be deemed more or less suspicious according to company policies. Data Risk
Analytics enables you to create Allow List rules for events you determine are acceptable and that should not trigger an
incident.
Allow List rules are governed by the permissions given to you according to the role you are logged in as. Entering as a
role with permission to work with Allow List Rules, does not allow you access to everything. Allow List Rules that do
not fit your permissions (event type and destination IP wise), you cannot see. Allow List Rules that fit your
permissions, you can see but not edit. An eye icon is displayed next to these Allow List Rules to indicate this. Allow List
Rules that fit your permissions exactly, you can see, edit or delete. A pencil icon and a trash icon are displayed next to
these Allow List Rules to indicate this.
To create an Allow List rule:
1. Login to Data Risk Analytics.

2. Click Allow List Rules.


If you are logged in with restricted destination IPs list, you may see a page that looks like this:
3. Click Add. The Allow List Rules -Add New Rule page is displayed.


If you are logged in with restricted destination IPs list, you may see a page that looks like this:


4. In Rule Name, type a name for the rule.
5. In Expiration Date, click and select the date this rule expires on. Leaving this field blank implies the rule
does not expire.
6. In Comment, type any information that would further assist in understanding why this rule was created.
7. In Rule Conditions, provide details that define under what circumstances an incident should be ignored.
8. In Related Incidents:
1. Select the check box to close existing incidents that correspond to this rule.
2. From the Close Reason dropdown, select the reason for closing the incident.
3. Select Add to existing comment and type a comment that would further assist in understanding why the
incident was closed. Your comment is added to any existing comments for these incidents.
-OR-
Select Overwrite existing comment and type a comment that would further assist in understanding why
the incident was closed. Your comment overwrites any existing comments for these incidents.
9. Click Save and close.

10. Click Yes or No in the dialog box that is displayed asking if you want to close all existing incidents that match
this rule.
Notes:
▪ You can create an Allow List rule for a specific incident/issue by clicking on the incident/
issue in the Incidents/Issues page and then clicking the Create Allow List Rule button.
▪ Once an Allow List rule exists, you can edit or delete it by clicking the appropriate button
next to the rule.
▪ You can select the Show expired rules check box to see the expired rules.

Closing Incidents
Closing an incident is performed in the Incidents page or in the Incident Details page.
To close an incident in the Incidents page:
1. In the Open Incidents page, select the check box next to the incident you want to close.
2. Click on Close Selected. The Close Incident window is displayed.
3. From the Close Reason drop down, select the reason for closing the incident. The available reasons are:
▪ Blank - No reason needed.
▪ Authorized - The incident (that should generally not happen) was reviewed and the activity was approved
(due to some specific circumstances).
▪ Resolved - The incident was reviewed and the necessary steps to correct were taken.
▪ Permitted - The incident was reviewed and the activity was deemed to be necessary and not malicious. An
Allow List rule may have been created for this incident.
▪ Misclassified - The system misclassified the activity and thus the incident was falsely created. An Allow List
rule may have been created for this incident.
▪ Part of an existing allow rule - The incident was reviewed and deemed to be necessary and not malicious.
An Allow List rule was created for this incident.

4. In the Comment field, type any information that would further assist in understanding why the incident was
closed.
5. Click Close Incident. The incident is closed and removed from the Open Incidents page.
Note: You can select multiple incidents to close. When doing so, the Close Incident window is
updated to include the number of incidents being closed in the window title and two radio
buttons above the Comment field:
▪ Add to existing comment - Your comment is added to any existing comments for these
incidents.
▪ Overwrite existing comment - Your comment overwrites any existing comments for
these incidents.
To close an incident in the Incidents Details page:
1. In the Incident Details page, click the Close Incident button. The Close Incident window is displayed.
2. From the Close Reason drop down, select the reason for closing the incident.
closed.
4. Click Close Incident. The incident is closed and removed from the Open Incidents page.
After closing incidents, you can view them or reopen them from the Closed Incidents page.
To view and reopen an incident:
1. In the Open Incident page, click View closed incidents located on the top right corner of the page. The Closed
Incidents page is displayed and you can view the general details of the incident or incidents.
2. Click on an incident to view more comprehensive details on the incident.
3. Click on the Reopen Selected button. The Reopen Incident window is displayed.

reopened.
5. Click Reopen Incident. The incident is reopened and appears in the Open Incidents page.
Note: You can select multiple incidents to reopen. This is performed in the Closed Incidents
page by selecting the check boxes next to the desired incidents and clicking Reopen Selected.
When doing so, the Reopen Incident window is updated to include the number of incidents
being reopened in the window title and two radio buttons above the Comment field:
▪ Add to existing comment - Your comment is added to any existing comments for these
incidents.
▪ Overwrite existing comment - Your comment overwrites any existing comments for
these incidents.

Filtering
As explained, the incidents and anomalies are the objects that Data Risk Analytics uses to notify you of suspicious
events or breaches. As time progresses, the amount of incidents and anomalies that exist in the system grows and
filtering becomes a major necessity in order to find what you would like to work on.
Data Risk Analytics enables two types of filters both located on the Open and Closed Incidents pages:
• A free text filter - This filter does not allow granularity when filtering incidents and anomalies.
• An advanced filter - This filter allows you to pin point the exact incidents and anomalies you would like to see.
The free text filter is denoted as the Quick filter field .
The advanced filter is denoted as the Add Filter link . It allows filtering by multiple fields and for each
field by multiple values.
When you click it, you are required to choose a field to filter by from a predefined list. Once a field is selected, a small
dialog opens in which you choose what exact values you want to filter. After finishing choosing the values you click the
Update button and the added filter is shown on screen with any previously added filters and the list will be filtered
accordingly. If you want to clear the filter you can clear each filter field independently or press Clear Filter.

Exporting Incidents Issues and Anomalies

Data Risk Analytics enables you to export detected incidents, issues and anomalies to a file. This is handy when you
need to have someone that does not have access to Data Risk Analytics, review and decide on what needs to be done
regarding the detected incident, issue or anomaly.
Exporting detected incidents and anomalies is performed from the Open/Closed Incident and Open/Closed Anomaly
pages. Exporting detected issues is performed from the Issues page. You can also export a specific incident, issue or
anomaly from the Incident Details, Issue Details and Anomaly Details pages. The export creates a file in Excel format.
To export incidents, anomalies or issues from the Open/closed Incident, Open/closed Anomaly or Issues pages:
1. In the Open/Closed Incident, Open/Closed Anomaly or Issues pages, select the check boxes next to the
incidents, anomalies or issues you want to export.
2. Click the button. The export file is created.
-OR-
1. In the Open/Closed Incident, Open/Closed Anomaly or Issues pages, click Add Filter and apply your filter
criteria.
2. Click the button and select the Export currently filtered incidents/anomalies option. The export file is
created.
Note: This type of export file is limited to 1000 entries. If your filter results in more than 1000
entries, you will get a confirmation dialog box indicating only the first 1000 entries will be
included in the export file. Click OK to create the export file.
To export incidents, anomalies or Issues from the Incident Detail, Anomaly Detail or Issue Detail pages:
• In the Incident Detail, Issue Detail or Anomaly Detail pages, click the button. The export file is created.

Anomalies
Data Risk Analytics detects anomalous activity based on a baseline learned from the audit data it receives. If the
activity is suspicious, but not enough to deem an incident, it is displayed in the Open Anomalies page. You can then
perform all actions available for incidents (e.g. investigate, star, search, filter, etc.) except for Allow List rules.
An anomaly, in contrast to an incident, is a suspicious activity that is not categorized by severity. It is another piece of
information that can be attributed to an employee, and in conjunction with their incidents, lets you asses the risk they
might pose.
The Open Anomalies page aggregates all detected suspicious activities in table format. It shows general details on
each open anomaly.


General details shown for each anomaly include:
Anomaly Details
Field Description
ID The ID number assigned by Data Risk Analytics to the anomaly.
Type The specific anomaly type detected (e.g. Excessive Database Record Access).
Event Time The time and date the event occurred.
User Name The name of the user that performed the suspicious activity.
The host name and IP address of the machine from which the suspicious activity
Source Host
originated.
• Host
• Database User
• Database Name
• Cluster Member
Destination
group)
• - File Server
Comment The comment that was entered in the Anomaly Details page.

When you click on an anomaly in the table, you are shown a more comprehensive details page about the anomaly. In
addition to the details, you can perform all actions available for incidents, except Allow List rules.
Comprehensive Anomaly Details
Field Description
A detailed description of the anomaly stating the activity performed, by whom, from
where and to where.
Description
You can click Learn how to investigate this type of incident to jump to the Data
Risk Analytics Incidents Online Help where you can get in depth details on each of
the incidents Data Risk Analytics is warning against.
Comment
the anomaly.
Creation Influencing
Information on the reasons for creating the anomaly.
Reasons
Details
Specific information about what was accessed, operations performed by the source,
Anomaly Details
etc.
Information about the typical activity conducted when accessing this asset in
Typical Behavior
addition to typical activity conducted by this user.

Managing Issues
Issues is a functionality that is intended to provide a more manageable way for users to see and react to the incidents
in their system. It does this by grouping incidents that describe a phenomenon. Grouping is on the same incident
type, and display both groups and single incidents in a single prioritized list. Groups are defined such that the
incidents associated with them describe a phenomenon that the user can clearly understand and enable the user to
trigger actions on all related incidents as one (e.g. closing all related incidents).
This feature is NOT intended to replace the handling of individual incidents as is currently done, but to enhance the
existing functionality such that the users have a clearer and more manageable way to understand their system. The
following principles are followed when working with Issues:
• Issues can be either single incidents that were not grouped or grouped incidents.
• Issues are prioritized.
• For grouping:
• Incidents can appear in more than one group.
• When an incident is closed, regardless from what page, it is removed from all groups which it was
associated to.
• Groups are not final, they may be created/deleted when new incidents are added, or when the user
closes existing incidents.
• The grouping functionality does not affect the existing implementation/algorithms in the analytics
functionality.
You can investigate, star issues in order to analyze them later on, perform a search for a specific issue, filter (see
Filtering), create Allow List rules (see Allow List Rules), or close the incidents related to the issue (see Closing
Incidents).
The Issues page aggregates all grouped and single issues in table format. It shows general details on each open
incident and enables further drill down on each incident for more comprehensive details.


General details shown for each issue may include:
Issue Page Details
Field Description
The severity of the issue Low, Medium, High or Critical and the priority score. The
Severity and Priority severity and priority score are assigned by Data Risk Analytics using an internal scoring
system.
The specific issue type detected (e.g. Several Database Service Accounts Abused Multiple
Type
Times by a Single User).
ID The issue ID number.
#Incidents The number of incidents that are related to this issue.
Last Event Time The time and date the last event occurred.
Client Details The name of the user that performed the suspicious activity.
• Host
• Database User
• Database Name
Server Details
• Cluster Member
group)

Field Description
• - File Server
Comment The comment that was entered in the Issue Details page.
When you click on an issue in the table, you are shown a more comprehensive details page about the issue. In
addition to the details, you can close all the incidents related to the issue, export the incident details or create an
Allow List rule from this page.


Comprehensive Issue Details
Field Description
A detailed description of the issue stating the activity performed, by whom, from
where and to where.
Description
You can click Learn how to investigate this type of issue to jump to the Data Risk
Analytics Incidents Online Help where you can get in depth details on each of the
incidents Data Risk Analytics is warning against.
Comment
the incident.
Details
A table showing general details on each incident that is related to the issue. It enables
further drill down on each incident for more comprehensive details. In addition, It
enables you to close selected incidents, export the incidents to a file or filter.
General details shown for each incident include:
• Related Issues - Opens a dialog box showing all the issues that this incident is
related to. You can click on an issue to jump to the Issue Details page and view
its details.
• ID - The incident ID number.
Related Incidents • Severity - The severity and prioritization of the incident Low, Medium, High or
Critical. The severity is assigned by Data Risk Analytics using an internal scoring
system.
• Type - The specific incident type detected (e.g. Suspicious Application Data
Access).
• Event Time - The time and date the event occurred.
• User Name - The name of the user that performed the suspicious activity.
• Source Host - The host name and IP address of the machine from which the
suspicious activity originated.
• Destination - The IP address of the server to which the suspicious activity was
intended.

Field Description
• Comment - The comment that was entered in the Incident Details page.

Dashboard
When you log into Data Risk Analytics, as per your permission setting, you are presented with a predefined dashboard
page containing widgets that give a quick informative, and in some widgets drill down capabilities, view of the
following:
• Protected Assets - This widget displays the amount of servers protected by Data Risk Analytics by analyzing
their data and reporting on anomalous behavior. If an asset is not configured, a zero is displayed next to it. This
widget is informative only.
• Open Issues - This widget displays the total amount of issues detected and a breakdown of it into the severities.
You can click on the severity to jump to the issue page, filtered by severity.
• Security Events Over Time - This widget displays two gadgets:
• Incidents created - Trend graph showing the amount of incidents created over the last seven days (not
including today). This gadget is informative only.
• Anomalies created - Trend graph showing the amount of anomalies created over the last seven days
(not including today). This gadget is informative only.
• Entities With Most Severe Incidents - This widgets displays three gadgets:
• Users - This gadget displays the top three employees with the most severe incidents. In this gadget, you
can click each user in order to access the Employee Profile page and view more details. Clicking Show
More, adds up to seven more employees to the display.
• Endpoints - This gadget displays the top three endpoints from which the most severe incidents
occurred. In this gadget, you can click each machine in order to access the Incidents page, filtered for
this machine, and view more details. Clicking Show More, adds up to seven more machines to the
display.
• Servers - This gadget displays the top three servers on which the most severe incidents were found. In
this gadget, you can click each server in order to access the Incidents page, filtered for this server, and
view more details. Clicking Show More, adds up to seven more servers to the display.
• Events Analyzed - This widget displays two gadgets:
• Database Server events created - Trend graph showing the amount of Database Server events over the
last seven days (not including today) that were analyzed in order to learn the behavior baseline and
detect anomalous behavior. If no database servers are monitored, this graph is not displayed. This
gadget is informative only.
• File Server events created - Trend graph showing the amount of File Server events over the last seven
days (not including today) that were processed in order to achieve the reported incidents and
anomalies. If no file servers are protected, this graph is not displayed. This gadget is informative only.
• System Health Status - This widget displays health status of the Data Risk Analytics Admin and Analytics
servers and Active Directory. When the system is working properly without any problems all of the components
appear with a green check mark indicating a healthy status. When a health status problem is detected, the
particular component indicates it and a Show details link appears (see figure below). Clicking the link opens an
info section that details the problem and provides a link to an online help knowledge base where instructions
on how to resolve the problem are given. In addition, if the problem is a configuration problem in Data Risk
Analytics, the configure icon is provided, which when clicked, sends you to the appropriate screen in the UI
where you can check the configuration and make corrections.

The problems indicated in the System Health Status widget are:
• Errors - The system is not working properly.

• Warnings - The system is working properly, but might go into an error state shortly if no human
intervention occurs soon.
• Info - A recommended configuration is missing
Notes:
• Data Risk Analytics is set to send an email notification according to the

configuration in the System > Notifications screen on health status changes
(when a problem exists and when it is resolved) that occur continuously for 10
minutes per component.
• The Dashboard screen is not refreshed automatically. Therefore, to see the
updated status in the Dashboard screen, you need to perform a manual refresh of
the screen.


If you are logged in with restricted permissions, you may see a page that looks like this:



System Configuration
Data Risk Analytics offers system configuration settings that give you the ability to:
• View the health status of your system

• Perform user and role settings such as:
• Manage active directory integration
• Manage Active Directory Groups
• Manage Incident Responder settings
• Manage Application Owner settings
• Manage Security Engineer settings
• Manage Admin settings
• Perform security event settings
• Manage notifications such as:
• Email notifications for incidents with a specific severity threshold
• Syslog Notifications
• Manage your active directories
• Manage your license
• Health Status
• User and Role Settings
• Security Event Settings
• Notifications
• Active Directory Integration
• Licenses

Health Status
This page allows you to see detailed information on the health status of your Admin server, Analytics servers and
Active Directories.
To review the health status of your system:

2. Click System > Health Status.


3. In the Admin Server tab, you can view the condition of the Admin server (critical, medium and good), the host
name and the software version installed.
4. In the Analytics Servers tab, you can view the number of Analytic servers in your system and the condition they
are in (critical, medium and good). In addition, you can view a table that indicates the details of each server
(condition, IP address or Host name, any Errors found, any Warnings found and the software version installed on
the server) and use a filter to see only your desired information.
5. In the Active Directories tab, you can view the number of active directories in your system and the condition
they are in (critical, medium and good). In addition, you can view a table that indicates the details of each active
directory (condition, name, primary IP address, any Errors found and any Warnings found) and use a filter to see
only your desired information.

User and Role Settings

Data Risk Analytics helps organizations to achieve two Insider Threat related goals by detecting:
• Breaches through surfacing malicious activity (AKA “breach detection incidents”)

• Risky behaviors through surfacing careless activity (AKA “risk reduction incidents”)
In most organizations two different personas are responsible to help Data Risk Analytics achieve these goals:
• Security Operation Center (SOC) users who handle breach detection incidents. These users are usually called
Incident Responders and they do not handle risk reduction incidents.
• Owners of Data Risk Analytics in the organization (i.e. users from the database security team) who usually
handle risk reduction incidents. In some cases (not very common) risk reduction incidents are handled by a
team that is responsible for risk in the organization (part of the GRC group).
Data Risk Analytics Roles and Permissions model is built to allow you to achieve these two Insider Threat related goals
while using Data Risk Analytics with maximum alignment to your organization’s structure. The following configuration
tasks on this page, allow you to achieve this:
• Choose the active directory to pull the roles members from for authentication.
• Map your active directory groups according to the role settings.
• Manage settings (permissions and users) for each of the roles.
Below you can find best practices for assigning the different roles to personas in your organization.
Note: Many organizations have slight differences in the way they are structured. Therefore, the
below is just a suggestion that should be tuned, if needed.
• Admin – This role should be assigned to the Data Risk Analytics owner, i.e. to the persona that is responsible to
configure the system, review health status and assign roles to other users. This role has the highest level of
privileges across all roles and assigned users to it serve as super users. This role also allows one to investigate
issues or incidents and create Allow List rules.
• Incident Responders - This role should be assigned to SOC users who serve as the first tier of response for
handing breach related incidents.
• Application Owners - This role should be assigned to pesonnas who are responsible for database security of
specific application(s). It means that they should not see or handle incidents related to other databases (except
from specific cases where the incidents are part of the same issue) and should not create Allow List rules that
block incidents on other databases.
• Security Engineers - This role should be assigned to personnas in the organization who handle incidents
(either all classes or just one of them) and who should create Allow List rules, but do not handle configuration
and user management tasks.
• API users - This role should be assigned to applications or scripts that integrate with Data Risk Analytics
through its APIs. The privileges in this roles are similar to the Admin role privileges, without the ability to access
the system through the GUI.

• Active Directory Authentication

• Active Directory Authorization
• Active Directory Groups
• Incident Responders
• Application Owners
• Security Engineers
• Admin Management

Active Directory Authentication
Data Risk Analytics enables user management by integrating with Active Directory. User management includes:
• Allow multiple users to have access to the product

• Allow adding and removing access from different users at the administrator’s discretion
The user management options to have multiple users in the system and add and remove users at the administrator’s
discretion, are based on integration with your active directory system. The integration is based on predefined active
directory groups that you need to create in your active directory server, and add users to them. For more information,
see Active Directory Authorization.
To configure active directory authentication:
1. Define, if not already done, the active directory integration information as described in Active Directory
Integration.
2. Click System > User and Role Settings.


3. Select the active directory server for user authentication from the dropdown.
Note: You can click Add New to jump to the Active Directory -Add New Active Directory
screen in order to add more active directory servers. For more information on adding new
active directory servers, see Active Directory Integration
4. Click Save Changes.

5. Add to your Active Directory server at least one of the groups described in Active Directory Authorization and
populate the group(s) with users you want to grant access to Data Risk Analytics.

Active Directory Authorization
Active directory authorization allows the system administrator to restrict system access to authorized users only using
the role-based access control method. This is performed by creating the CounterBreach_Admins,
CounterBreach_Api, CounterBreach_IncidentResponders, CounterBreach_ApplicationOwners, and
CounterBreach_SecurityEngineers groups in your active directory server. Only users that belong to these groups are
allowed to log into Data Risk Analytics. The groups also define the set of permissions for the user. The
CounterBreach_Admins group allows users to have full administrator access privileges. The
CounterBreach_IncidentResponders group allows users to handle issues, incidents and anomalies. Furthermore,
you can limit users in the CounterBreach_IncidentResponders group to see and handle specific incidents or
anomalies by their destination IPs. The CounterBreach_ApplicationOwners group is similar to the
CounterBreach_IncidentResponders group, which allows flexibility. The CounterBreach_SecurityEngineers group
allows users to view and handle issues, incidents and anomalies, to view the dashboard to all IPs, not just their
designated IPs.
In order to configure active directory authorization follow the steps defined in Active Directory Authentication.
If you want to define additional administrators for Data Risk Analytics, add the CounterBreach_Admins group to your
active directory server and add relevant users to it.
If you want to define users that are able to see and handle only specific incidents and anomalies, perform the
following procedure.
To define users that are able to see and handle only specific issues incidents and anomalies:
1. Add the CounterBreach_IncidentResponders group and/or CounterBreach_ApplicationOwners group to

your active directory server and add relevant users to it.
3. Select the active directory server for user authentication from the drop down. The screen is automatically
populated with the users from the CounterBreach_IncidentResponders group and/or
CounterBreach_ApplicationOwners group.


4. For each user, click and type the IP address that he/she is allowed to see destination IP addresses for. You
can type multiple IP addresses by separating them with a comma or you can type '*' if you want this user to
have access to all incidents and anomaly destination IPs. In addition, you can add a comment that would
further assist inthe understanding of this user's restrictions.

Active Directory Groups
In this page you can map your active directory groups according to the role settings.
To map active directory groups according to the role settings:

3. Click the AD Groups tab.


4. Type the name of the group from the active directory for each role or use the default names.
5. Click Test Connection for each group to verify they are connected.

Incident Responders
Incident Responders can review events coming from the permitted destination IP addresses as per the selected
security event types. They can access the Allow List page (if configured to) as per the User And Permitted
Destination IP Address table.
To manage Incident Responders settings:

3. Click the Incident Responders tab.


4. Fill in the information in the fields, check boxes and dropdowns.
Field Description
• Select the security event class - This radio button enables you to
configure the permitted security event types according to the security
event class. Select one of the possible event classes Breach Detection or
Permitted Security Event
Risk Reduction. Click the Configure the security event class link to jump
Types
to the Security Event Settings page and configure these classes.
• Custom - This radio button enables you to select the permitted security
events regardless of the security event class.
Configuration Select this check box to enable the role to configure Allow List rules.
In this table you can view and configure users acting as incident responders and
their permitted destination IP addresses imported from the group in the set
active directory.
User and Permitted
Destination IP Address For each user, click and type the IP address that he/she is allowed to see
Table destination IP addresses for. You can type multiple IP addresses by separating
them with a comma or you can type '*' if you want this user to have access to all
incidents and anomaly destination IPs. In addition, you can add a comment that
would further assist inthe understanding of this user's restrictions.

Application Owners
Application Owners can review events coming from the permitted destination IP addresses as per the selected
security event types. They can access the Allow List page as per the User And Permitted Destination IP Address
table.
To manage Application Owners settings:

3. Click the Application Owners tab.


Field Description
Types
Configuration Select this check box to enable the role to configure Allow List rules.
In this table you can view and configure users acting as incident responders and
their permitted destination IP addresses imported from the group in the set
active directory.
User and Permitted
Destination IP Address For each user, click and type the IP address that he/she is allowed to see
Table destination IP addresses for. You can type multiple IP addresses by separating
them with a comma or you can type '*' if you want this user to have access to all
incidents and anomaly destination IPs. In addition, you can add a comment that
would further assist inthe understanding of this user's restrictions.

Security Engineers
Security Engineers can access all pages in the UI except for pages under the System tab. They can review any event
coming from any destination IP address as per the selected security event types.
To manage Security Engineers settings:

3. Click the Security Engineers tab.


Field Description
Types

Admin Management
Data Risk Analytics allows basic management of the built-in admin user in the system. This option enables you
change the admin password. The admin password must be changed every 90 days (an indication of how much time is
left is given on the login screen) and is required to be at least eight characters long and include at least: one uppercase
letter, one lowercase letter, one number and one special character.
To manage admin settings:

3. Click the Admin tab.


4. Type the current password.

5. Type a new password according to the requirements indicated.
6. Retype the new password to confirm.
7. Click Change Password.
Note: The password change takes affect only after a log out (manual or timed) occurs.

Security Event Settings

In this page you can configure the security event types to be Breach Detection and/or Risk Reduction. This allows the
events to be included in Syslog notifications and REST API. This page can also be accessed from any of the role pages
(Incident Responders, Application Owners and Security Engineers) when setting the Permitted Security Event Types
for each role.
You can click on links that open relevant online help pages to learn more about the event type and the REST API.
To classify each event type to a class:

2. Click System > Security Event Settings.


3. For each security event type select the security event class that you want classify it to or use the defaults.
4. Click Back to Default to revert to the default settings.

Notifications
In this page you can manage Email Notifications and SIEM Integration (syslog) notifications.

Email Notifications
The following procedure details the steps to configure Data Risk Analytics to send email notifications.
To configure Data Risk Analytics to send email notifications:

2. Click System > Notifications.
3. Select the Enable Incident Email Notifications check box.


Field Description
SMTP Server The SMTP Server name or IP address.
SMTP Port The port number used to by the outgoing SMTP Server.
From Email Address The email address from which the email will be sent.
The email address (es) to whom the email will be sent. To enter multiple email
To Email Addresses
addresses, separate each email address by a semicolon.
The security protocol that will be used when the servers communicate. Select:
• None - No security protocol.

• TLS - Use the Transport Layer Security (TLS) protocol.
SMTP Security Method
• SSL - Use the Secure Sockets Layer (SSL) security technology.
When selecting TLS or SSL, you need to provide the Username and Password of
the SMTP server.
Send an email for health

Select this check box to have an email sent notifying on health issues.
issues
Select this check box to have an email sent notifying on issues. Select:
• The minimum severity level that email notifications are sent for (Critical,
Send issues notifications High, Medium or Low).
• The check box or check boxes to have an email sent to designated role in
addition to the configured emails.
• The number of emails per day that are sent.
Select this check box to have an email sent notifying on incidents. Select:
Send incidents
notifications
• The minimum severity level that email notifications are sent for (Critical,
High, Medium or Low).

Field Description
• The check box or check boxes to have an email sent to designated role in
addition to the configured emails. For more information on incident
responders, see Active Directory Authentication.
• The number of emails per day that are sent.
1. Click Send Test Email. An email indicating proper settings were configured should be received by the
designated To Email Addresses.

SIEM Integration
Data Risk Analytics incidents can be exported and sent using Syslog notifications to enable integration with SIEM
products such as Splunk and HP ArcSight.
To enable SIEM integration:

2. Click System > Notifications.
3. Click the Syslog Notifications tab.
4. Select the Enable Incident Syslog Notifications check box.


5. Fill in the information in the fields and dropdowns.
Field Description
• Host/IP - Type the host name or IP address of your Syslog server (the server
that is setup with the SIEM product).
• Port - Type the port that your Syslog server is setup for receiving the Data Risk
Analytics notifications.
Syslog Server Settings
• Protocol - Select from the dropdown the protocol used to issue the logs to
Syslog. The available protocols are: UDP and TCP.
• Facility - Select from the dropdown the option that specifies the type of
program that is logging the message.
• Configure the security event class - Click this link to jump to the Security
Event settings page where you can classify each event type to a class
Send Security Event to • Send Breach Detection - Select this check box to send this event type to the
Syslog Server Syslog server
• Send Risk Reduction - Select this check box to send this event type to the
Syslog server
Send issues notifications - Select this check box to have an email sent notifying on
issues. Select:
• Message Format - Select from the dropdown the format used to export the
issues data to Syslog. The available formats are:
RAW - This standard is best suitable for SIEM vendors such as Splunk
CEF - This format is best suitable for SIEM vendors such as HP ArcSight
LEEF
• Message Template - Shows the template comprised from placeholders that is
used to create the message per the selected Message Format. For information
on the placeholders used, see Placeholders.
Note: The length of the syslog message sent by Data Risk Analytics is limited to
Notifications Configuration
1024 bytes.
• Select from the dropdown the severity threshold for which notifications equal
to or higher are sent. The available thresholds are: Critical, High, Medium, Low
and Anomaly (all severities).
Send incident notifications - Select this check box to have an email sent notifying
on incidents. Select:
• Message Format - Select from the dropdown the format used to export the
incidents data to Syslog. The available formats are:
RAW - This standard is best suitable for SIEM vendors such as Splunk
CEF - This format is best suitable for SIEM vendors such as HP ArcSight
LEEF

Field Description
• Message Template - Shows the template comprised from placeholders that is

used to create the message per the selected Message Format. For information
on the placeholders used, see Placeholders.
Note: The length of the syslog message sent by Data Risk Analytics is limited to
1024 bytes.
• Select from the dropdown the severity threshold for which notifications equal
to or higher are sent. The available thresholds are: Critical, High, Medium, Low
and Anomaly (all severities).

Placeholders
The following table indicates the placeholders used in the message templates for the available message formats to
create Syslog Notifications.
Syslog Notification Placeholders (General)
Placeholder Description
CounterBreachVersion The current version of Data Risk Analytics.
ItpIp The IP address of the Data Risk Analytics Admin server.
Syslog Notification Placeholders (Incidents)
A list of the tables accessed in this event. This is relevant for database
events only. For all other event types it is irrelevant.
This list is sent in a json format as follows: {applicativeTables:

[...],applicativeCommands:[...],nonApplicativeTables:
[...],nonApplicativeCommands:[...]}.
Where:
applicativeTables – A list of tables that are typically accessed by the

Incident.accessedTables
application.
applicativeCommands - A list of SQL commands that are typically used

by the application.
nonApplicativeTables - A list of tables that are not typically accessed by

the application.
nonApplicativeCommands - A list of SQL commands that are typically

not used by the application.
Possible values:
Incident.additionalClusterNames
• The name of the Cluster

• A cluster group of one or more database servers or instances.

• In Mainframe a cluster is called a “data sharing group”.
Note: These are the rest of the values in the list besides the first, which
is given by Incident.ClusterName.
A single instance/node in a Cluster

Incident.additionalClusterMemberNames
is given by Incident.ClusterMemberName.
The IP addresses of the destination server.

Incident.additionalDestinationIps
is given by Incident.destinationIp.
The application names used by the source that created the event.
Incident.additionalSourceApps
is given by Incident.sourceApp.
The host names of the source that created the event.

Incident.additionalSourceHosts
is given by Incident.sourceHost.
The IP addresses of the source that created the event.

Incident.additionalSourceIps
is given by Incident.sourceIp.
The user names of the source that created the event.

Incident.additionalSourceUsers
is given by Incident.sourceUser.
Incident.category Indication of whether this is an Anomaly or Incident.

Possible values:
Incident.clusterName • The name of the Cluster

• A cluster group of one or more database servers or instances.
• In Mainframe a cluster is called a “data sharing group”.
Incident.clusterMemberName A single instance/node in a Cluster
Incident.description The description of the event.
Details on the destination server as follows:

Incident.destination
• For database events: The database name
• For file events: The root folder

Incident.destinationAccount
• For database events: The database username
• For any other events: Irrelevant
The host name of the destination where the event was created on.
Incident.destinationHost
Note: In case of multiple destination host names, this value is the first
value in the list, which is ordered alphabetically ascending.
The IP address of the destination server.

Incident.destinationIp
Note: In case of multiple destination IP addresses, this value is the first
value in the list, which is ordered numerically ascending.

Incident.destinationType
For database events: The database type

The time the event actually occurred.

Incident.eventTime
The format is yyyy-MM-dd HH:mm:ss
The ID of the event.
Incident.id Note: The ItpIp and Incident.id placeholders are used in the message
template in a url that links to the event in the UI as follows: https://$!
ItpIp:8443/#/securityEvents/incidentDetails/$!Incident.id
The type of server protected by Data Risk Analytics.

Incident.incidentCategory
Possible values: Database or File
Incident.incidentType The type of the event. For example, Excessive File Access.
Direct link to the incident in the UI

Incident.incidentURL
For example: https://$!ItpIp:8443/#/securityEvents/incidentDetails/$!
Incident.id
• For Excessive Database Record Access events: The number of

rows accessed
Incident.numOfAccessedObjects
• For file events: The number of files
The severity of the event.
Incident.severity Possible values: Critical, High, Medium or Low
Note: RAW and CEF formats are string. LEEF format is integer.
Incidnet.severityScore The priority of the incident.

The application name used by the source that created the event.
Incident.sourceApp
Note: In case of multiple application names, this value is the first value
in the list, which is ordered alphabetically ascending.
The host name of the source that created the event.

Incident.sourceHost
Note: In case of multiple source host names, this value is the first value
The IP address of the source that created the event.

Incident.sourceIp
Note: In case of multiple source IP addresses, this value is the first
value in the list, which is ordered numerically ascending.
The user name of the source that created the event.

Incident.sourceUser
Note: In case of multiple source user names, this value is the first value
• For file events: The operation: Read/Copy or Write

Incident.userAction
Syslog Notification Placeholders (Issues)
Indication that an issue was created.

Issue.action
Note: The indication is for issue creation only.
Indication that this is an issue message is.

Issue.category
Note: The indication is for an issue only.

Issue.description The description of the issue.
The time the issue was created.

Issue.eventTime
The format is yyyy-MM-dd HH:mm:ss
The first name in the cluster list, which is ordered alphabetically

Issue.firstClusterName
ascending.
The first member in the cluster list, which is ordered alphabetically

Issue.firstClusterMember
ascending.
Issue.firstIncidentTime Time of the newest incident.
In case of multiple Server host names, this value is the first value in the
Issue.firstServerHost
list, which is ordered alphabetically ascending.
In case of multiple server IP addresses, this value is the first value in

Issue.firstServerIp
the list, which is ordered numerically ascending.
In case of multiple user names, this value is the first value in the list,
Issue.firstUser
which is ordered alphabetically ascending.
In case of multiple User host names, this value is the first value in the
Issue.firstUserHost
list, which is ordered alphabetically ascending.
In case of multiple User IP addresses, this value is the first value in the
Issue.firstUserIp
list, which is ordered numerically ascending.
Issue.id
The ID of the issue.

Note: The ItpIp and Issue.id placeholders are used in the message
template in a url that links to the event in the UI as follows: https://$!
ItpIp:8443/#/issueDetails/$!Issue.id."
Issue.incidents List of the incidents for this issue
The type of the issue.

Issue.issueType
For example: Excessive Multiple Database Access
Direct link to the issue in the UI.

Issue.issueURL
For example: https://$!ItpIp:8443/#/securityEvents/issueDetails/$!
Issue.id"
Issue.lastIncidentTime Time of the oldest incident.
Issue.numIncidents Number of incidents in the issue.
Issue.servers List of servers of this issue.
The severity of the issue.

Issue.severity
Possible values: Critical, High, Medium or Low
Issue.severityScore The priority of th issue.
Issue.users List of users of this issue.

Active Directory Integration

Data Risk Analytics can be configured to integrate with one or more active directories. This allows Data Risk Analytics
to enhance its algorithms using peer group analysis as well as show full details about every user it encounters
performing anomalous behavior.
To configure Active Directory integration:

2. Click System > Active Directory.


3. Click Add.
4. In Name, type the name you want to assign to the active directory server you are connecting to.

5. In IP, type the IP address of the active directory.

6. In Port, type the active directory port number. Typically 389 for unsecured and 636 for secured connections.
7. Select the Use SSL check box if you are using a secured connection.
8. In Username, type the user name of a domain user with read permissions for all active directory users. The user
name can be typed in a domain\username format or in a Distinguished Name (DN) format (e.g.
CN=User,OU=People,DC=company,DC=com).
Note: Imperva recommends creating a dedicated domain user that will be used for active
directory integration.
9. In Password, type the password of the predefined dedicated domain user.

10. In Base Search Path For Users and Groups, type the location in the active directory from where the search
begins, which narrows the index search and finds results more quickly. The location should be typed in a DN
format (e.g. DC=company,DC=com).
11. Click Test Connection. A Connection Succeeded message should appear. If the connection fails, follow the on-
screen instructions.
Once you have configured active directory integration, you can use this tab to add active directory servers in order to
support a forest topology, delete or edit the active directories.

Licenses
Data Risk Analytics requires a license. The following sections describe the Data Risk Analytics licensing process and
reviews the following subjects:
• License Overview
• Uploading Licenses
• Managing Licenses

License Overview
A license contains the following information:
• Data Risk Analytics requires a base platform license, and then is licensed based on the data assets that
customers would like to protect:
• Data Risk Analytics for Databases: per database server
• Data Risk Analytics for Files: per terabyte of the file logical volume
• Expiration Date: Shows the date the license expires. For evaluation licenses only. Non-evaluation licenses have
no time limit
• Maintenance Period: Specifies the period during which Data Risk Analytics is covered under the maintenance
agreement
When a non-evaluation license is renewed, it is replaced by a new license. You can add an evaluation license to an
existing non-evaluation license.
The license for Data Risk Analytics is uploaded to the Data Risk Analytics Admin Server right after setting the admin
password when logging in to the UI for the first time. Afterwards, you upload new licenses from System > Licensing in
the UI.

Uploading Licenses
When you login to the Data Risk Analytics UI for the first time, and after setting the admin password, you are asked to
upload a license. The License file you need as part of the process is downloaded by clicking a link in the License screen
and entering an account ID that is given in the welcome email you received after purchasing Data Risk Analytics.
To upload a license:
1. Login to Data Risk Analytics for the first time. The Set Admin Password screen is displayed.
2. Set the admin password according to the requirements indicated and click Login. The License screen is
displayed.
3. Click on the here link.
4. Follow the on-screen instructions and download the license file to a folder on your PC.
5. Click Browse and navigate to the folder where you saved the license file.
6. Select the file and click OK.
7. Click Upload License. The license is uploaded and a successful message is displayed.

Managing Licenses
If you purchased an evaluation license or your maintenance license is about to or has expired, you need to purchase a
new license. Once you have purchased and received the license file, you need to upload it to Data Risk Analytics.
To upload a new license:
1. Save the license file you received from Imperva in a folder on your PC.
3. Click System > Licensing.
4. Click Browse and navigate to the folder where you saved the license file.
5. Select the file and click OK.
6. Click Upload License. The license is uploaded and a message is displayed confirming if uploaded succeeded.

Advanced Procedures
The following sections detail advanced procedures that can be performed as part of the configuration of Data Risk
Analytics. They Include:
• Encrypted Archive File

• Changing Policy Names
• cbctl Commands
• Installing Custom Certificate in Admin Server for SSL Communication with Browser
• Installing Custom Certificate in Admin and Analytics Servers for SSL Communication

Encrypted Archive File

When your Imperva On-Premises gateway is configured to encrypt the audit data archive files it collects, the audit
data archive file sent to Data Risk Analytics is encrypted as well. This requires Data Risk Analytics to have the
decryption keys in order to be able to read the archive file as required.
If you know that your Imperva On-Premises gateway(s) encrypt audit data file, perform the following procedure in
order for Data Risk Analytics to work properly.
To properly configure Data Risk Analytics when Imperva On-Premises gateways encrypt the audit data file:
1. From your Imperva On-Premises MX units, collect all securesphere.kst and securespherekst.properties files. By
default, these files reside in /opt/SecureSphere/server/SecureSphere/jakarta-tomcat-secsph/conf/.
Note: The kst and corresponding properties files names are identical in each Imperva On-
Premises MX unit. Therefore, when collecting the kst and properties files from more than one
Imperva On-Premises MX, you need to change the names of these files so that they do not over
write each other. In addition, you need to keep the new names in the same convention as the
existing ones. For example, <new name>.kst and <new name>kst.properties.
2. Save these files on the Analytics Server in a dedicated folder under /opt/itpba. Make sure that the folder name
does not contain "kst" in it and that it has the proper access rights.
3. Connect to the Analytics Server CLI with root privileges as follows:
▪ If in sealed mode, connect locally with the user 'root'.
▪ If not in sealed mode, connect with any user and run the command admin to gain root privileges.
4. Run the command chown itp:itp on the folder you just created.
5. On the Analytics Server, edit the etlConfigOverrides.properties file by adding the following rows to it:
etl.mprv.keystore.folder=/opt/itpba/<FOLDER NAME>/ where <FOLDER NAME> is the name

of the dedicated folder from step 2.
etl.mprv.keystore.unifiedkeystorefilename= unifiedkeystore.kst
etl.mprv.keystore.keystoreextension= kst
etl.mprv.keystore.keystoretype= JCEKS
Note: When adding new kst and properties files from additional MX units after already
performing steps 1-3, just change the names as per step 1 and save the files in the already
created dedicated folder.
6. Perform a stop operation (cbctl stop) on the Analytics Server.

7. Perform a start operation (cbctl start) on the Analytics Server.

Changing Policy Names

The Data Activity Monitoring and File Security policy names indicated in this guide are default ADC policy names that
Data Risk Analytics is configured with. They can be changed to accommodate your company's policy by cloning one of
ADC policies and changing its name. The following procedure details how to do it.
To change the default policy names:
1. In Imperva On-Premises, go to Policies > Audit.

2. In the Audit Policies pane, click and select DB Service or File. The Create New Database Policy window is
displayed.
3. In Name, type the name of the policy as you desire.
4. Click Use existing and select the ADC policy you want to clone.
5. Click Create. The policy is created and appears in the Audit Policies pane.
6. Repeat steps 1-5 for each policy you want to change the name of.
7. Configure each policy you changed the name of according to the instructions in Configuring Policies for
Database Activity Monitor and Configuring Policies for File Activity Monitor, substituting your policy names for
the default names used.
8. Connect to the Analytics Server CLI with root privileges as follows:
▪ If in sealed mode, connect locally with the user 'root'.
▪ If not in sealed mode, connect with any user and run the command admin to gain root privileges.
9. Edit the /opt/itpba/conf/etlConfigOverrides.properties file as follows:
In the secure.sphere.itp.aa1.policy=<AA1 substring> row, replace <AA1 substring> with your desired name
for the CounterBreach for Database - All Events policy.
-OR-
In the secure.sphere.itp.ll2.policy=<LL2 substring> row, replace <LL2 substring> with your desired name for
the CounterBreach for Database - Logins Logouts policy.
-OR-
In the secure.sphere.itp.fam_aa2.policy=<AA2 substring> row, replace <AA2 substring> with your desired
name for the CounterBreach for File - All Events policy.
10. Perform a restart operation (cbctl restart) on the Analytics Server.

cbctl Commands
cbctl is a configuration tool that runs on the Data Risk Analytics servers. The available cbctl commands are
detailed in the following table:
Command Description
cbctl adminserver certificate external- Installs a custom certificate for Data Risk Analytics external
communication install-custom-certificate SSL communication with the Browser in the Admin server.
cbctl adminserver certificate internal- Installs a custom certificate for Data Risk Analytics internal
communication install-custom-certificate SSL communication in the Admin server.
cbctl adminserver registration-password set Changes the password used to register to this Admin server.
Resets the UI password for the admin user. The user is

cbctl adminserver ui-password reset
required to set a new password on the next login.
Unregisters the Analytics servers connected to this Admin

server.
cbctl adminserver unregister-analytics-server
Note: Unregistering an Analytics server should be done
from the Analytics server itself. This command should be
used only when the Analytics server is no longer available.
cbctl analyticsserver certificate install-custom- Installs a custom certificate for Data Risk Analytics internal
certificate SSL communication in the Analytics server.
Registers this Analytics server to the Admin server.

cbctl analyticsserver register-to-admin
Note: You need to perform cbctl restart after running this
command.
Sets the File profiler limit to default.
cbctl analyticsserver set-file-profiler-limit default Notes:
• After running this command you need to run the

command cbctl restart.

Command Description
• This command is available on the Data Risk Analytics

Analytics Server only.
Sets the File profiler limit to high, which allows it to profile a

large amount of users dealing with files (up to 10000 users).
Notes:
cbctl analyticsserver set-file-profiler-limit high
Displays a table showing the monitored and protected

entities. The information presented is destinations, the
database endpoint and the database type.
cbctl analyticsserver show-protected-entities
Once the command is performed, the protected entities
table can also be found under /tmp/protectedEntities/
protectedEntities.csv.
Unregisters this Analytics server from the Admin server it is

registered to.
cbctl analyticsserver unregister-from-admin
Note: You need to perform cbctl restart after running this
command.
Excludes the specified destinations from analysis by the

Analytics Server
Notes:
cbctl analyticsserver load excluded-destinations add
<comma separated list of destinations>
• The list of analyzed destinations must have at least
one address in it.
cbctl analyticsserver load excluded-destinations

Includes back all destinations that were previously
clear
excluded from analysis by the Analytics Server.

Command Description
Note: This command is available on the Data Risk Analytics

Includes back the specified destinations that were

previously excluded from analysis by the Analytics Server
cbctl analyticsserver load excluded-destinations
remove <comma separated list of destinations>
Display the list of analyzed destinations and the respective

load each IP creates on the system.
cbctl analyticsserver load show
Sets the client keystore password.
Notes:
cbctl keystore-password set
• If this is the first time you are changing the password,
the default current password is changeit.
Changes the fully qualified domain name and list of DNS

cbctl dns set
servers.
cbctl hostname set Changes or sets the hostname.
Changes the IP address and default gateway settings of the

cbctl ip set
Admin or Analytics Server.
cbctl ntp set Changes or sets the NTP settings.

Command Description
Configure a proxy server that enables the Data Risk

cbctl proxy set
Analytics server to communicate with the outside world.
cbctl proxy show Display the configuration settings of the proxy server.
cbctl proxy clear Clear the proxy server configuration settings.
Runs a safe reboot of the Data Risk Analytics server,

cbctl reboot verifying that all critically running jobs are completed
before the reboot is actually performed.
cbctl restart Performs an application stop + start.
cbctl start Performs an application start.
cbctl status Displays general and configuration status of the server.
cbctl stop Performs an application stop.
Creates a TAR file that contains log information necessary

cbctl support get-tech-info
for debugging.
Creates a TAR file that contains all information necessary for

cbctl support get-tech-info --all
debugging.
Creates a TAR file that contains logs and baseline

cbctl support get-tech-info --baseline
information necessary for debugging.
cbctl support get-tech-info --mprv Creates a TAR file that contains logs and audit information
necessary for debugging.

Command Description

cbctl timezone set Changes or sets the timezone settings.
cbctl version Displays the version number and build date.
ftl Starts the First Time Login configuration tool.

Installing Custom Certificate in Admin Server for SSL Communication with

Browser
The Admin Server uses a built-in default ROOT Certificate for SSL client-server communication. If you need to use your
own certificate, you need to provide your public certificate and private key files in binary (.der) format. Then, follow
the procedure below to install your certificate in the Admin Server.
To install your custom certificate:
1. Verify that in your certificates, the organization's DN is NOT set to

CN=CounterBreach,OU=CB,O=IMPERVA,L=Unknown,ST=Unknown,C=Unknown.
2. Connect to the Admin Server CLI with root privileges as follows:
▪ If in sealed mode: connect with any user and run the command admin to gain root privileges.
▪ If not in sealed mode: connect locally with the user 'root'.
3. Place the .der files in the /tmp folder on the Admin Server.
4. Run the following command and follow the on screen instructions:
cbctl adminserver certificate external-communication install-custom-

certificate
Note: Running this command restarts all Admin Server processes.
5. After the Admin Server restarts, verify that the certificates were uploaded successfully by inspecting the log file
at cat /var/log/cbctl<DATE>.log and verifying you see the line Not Default certificate, update is skipped!
followed by your DN information.

Installing Custom Certificate in Admin and Analytics Servers for SSL

Communication
The Admin and Analytics servers use a built-in default ROOT Certificates for SSL communication both between them
and internally. If you need to use your own certificates, you need to provide your public certificate and private key files
in binary (.der) format. Then, follow the procedure below to install your certificates in the Admin and Analytics
servers.
To install your custom certificates:
1. Connect to the Admin server CLI with root privileges as follows:

2. Place the .der files intended for the Admin server in the /tmp folder on the Admin server.
cbctl adminserver certificate internal-communication install-custom-

certificate
Note: Running this command restarts all Admin server processes.
4. Connect to the Analytics server CLI with root privileges as follows:

5. Place the .der files intended for the Analytics server in the /tmp folder on the Analytics server.
cbctl analyticsserver certificate install-custom-certificate
Note: Running this command restarts all Analytics server processes.
7. Repeat steps 4-6 on all your Analytics servers.
After performing the above procedure, you may decide, at some future point in time, to distribute data between your
Analytics servers. In this case, all you need to do is perform steps 4-7 from the above procedure on the Analytics server
you added.

Understanding Incidents
This appendix provides in depth details on each of the incidents Data Risk Analytics is warning against. These details
include: what the incident means, why it is important, what should you be looking for in order to understand if the
incident is a breach or not and any exceptions that might be relevant to your decision making process of the incident.
• Database Access at Non-standard Time

• Database Service Account Abuse
• Excessive Database Record Access
• Excessive Failed Logins
• Excessive Failed Logins from Application Server
• Excessive Multiple Database Access
• Machine Takeover
• Suspicious Sensitive System Tables Scan
• Suspicious Application Data Access
• Suspicious Database Command Execution
• Suspicious Dynamic SQL Activity
• Excessive File Access
• Excessive Personal File Access
• Slow Rate File Access
• Slow Rate Personal File Access
• Suspicious File Access

Database Access at Non-standard Time

What it means
An account was used to access the database at a time that is atypical for this user and their peer group.
Implications
Data access outside of typical working hours has been observed in several documented breaches. One reason for this
is that hackers often operate at times when the individual whose computer has been compromised is away from their
desk. This lowers the chance that network noise will be detected. In addition, hackers operating from a different geo
may be operating at times that are convenient to them, which may not be the normal office hours for an individual.
What to look for
• Review the “Behavior Profile” in the Employee Profile screen in Data Risk Analytics. Check the incident time
frame and see how it compares to the typical working hours of the individual. To do this:
In the UI, click Security Events->Incidents, click on the incident you are investigating and on the top of the
incident details page, review the event time and then click on the source user. The Employee Profile screen is
displayed. Click the Behavior Profile tab and under Typical User Database Activity, review the typical working
hours of the user on databases.
• Look for additional indicators of concern (e.g., application used and operation performed) to see if potentially
sensitive data has been accessed. To do this:
In the UI, click Security Events->Incidents, click on the incident you are investigating and under Additional
Information review the tables accessed.
• If there is sufficient cause for concern, contact the individual or their manager to verify the access.
Exceptions
• Special projects/deadlines: At times, special projects or deadlines can cause individuals to work during non-
standard hours. In these cases, it is recommended to use the time-bound Allow List feature to set the team
working on the database as allowed for the duration of the special project.
• Emergencies: Emergencies happen, and when they do, it’s common that they occur during non-standard hours.
These should be rare enough to warrant attention. If an individual frequently dispatches emergencies, Data Risk
Analytics will eventually learn about the off hour access and include in the user’s typical behavior over time.
Alternatively, you can also set this incident type as an Allow List rule for an individual or list of individuals for a
period of about 30 days.

Database Service Account Abuse

What it means
An interactive (human) user is using a service account to access the database.
Implications
A 3-tier application enforces access controls to business data and provides an audit trail for users logging into the
application. The serious implications of this activity hinge on the fact that service accounts have access to all business
data that the application manages, regardless of the entity using the service account. As such, a human user using the
service account will bypass all access controls and have complete access to business data, regardless of that person’s
role. Furthermore, the individual’s data access activity will not be traceable.
All of these factors make the application account a desirable target for insiders with malicious intent and
cybercriminals, and therefore any human use of the service account is flagged in Data Risk Analytics.
Even if this is a legitimate user access, using a highly privileged service account should be avoided for the following
reasons:
• Generally permitting such activity will mask compromise by an outside attacker, making this behavior more
difficult to identify.
• Data access performed using a generic service account violates security best practices and compliance
standards such as PCI DSS and ISO/IEC-27002.
• This practice can indicate that the service account password is exposed to, and shared by, various employees
who may not securely store these passwords. In addition, as these individuals move into other roles, the service
account does not offer user permissions to revoke, which is risky as the accounts will continue to possess access
to the application data.
What to look for
• When reviewing this incident, the first order of business is to trace the activity back to an individual:
• In Data Risk Analytics, look for the User Name (if available) to get visibility into the identity of the
person who initiated the access. To do this:
In the UI, click Security Events->Incidents, click on the incident you are investigating and under
Client Details click on the user name. The Employee Profile screen is displayed and you can view the
user details.
• Look for the source application (the client tool that was used to connect to the database), if available,
to see if this is an interactive SQL tool or an application server. To do this:
Client Details you can view the Source Application details.
• If you cannot trace the activity back to an individual, try using the source IP or host (if available), and
contact the device owner. To do this:
Client Details you can view the Source IP and Host details.

• Failing all of the above, the security team must take quick action to establish the source of this activity,
as it may be malicious.
• If the User Name is identified, be sure to look at the user’s role. If this role is not a DBA or a technical user, this is
cause for alarm as it is strong indication of a compromised account.
Once the individual behind the activity is found, it is important to establish:
• If this individual is not allowed to access the database:

• Examine the incident details and use Imperva On-Premises as required to understand what data has
been accessed.
• Verify this is indeed an action performed by the individual, and not by a hijacked account.
• This individual should be instructed not to use this account in the future.
• If this individual is generally allowed access to the database:
• Create a dedicated DB account for this individual, and instruct them to only use this account.
• Restrict access permissions of this user to the level required to ensure business-need-to-know.
Exceptions
Some exceptions may apply:
• Developers may need regular access to non-production databases. It is inconvenient to generate individual
passwords for all non-production or dev DBs. In the event that these databases do not contain sensitive data,
using a service account may be fine. For situations of this nature, it would be wise to use an Allow List rule for
non-production and dev DBs.
• Emergency cases in DevOps sometimes require unplanned activity by the dev team without the use of an
individual account. These cases should be rare enough to warrant a second glance at such incidents to ensure it
is not the result of account takeover. Therefore, it is recommended to allow Data Risk Analytics to continue to
alert on such behavior.

Excessive Database Record Access

What it means
An individual has queried records in excess of what this individual, their peer group, and the organization normally
query.
Implications
Excessive record access is a key risk factor and indicator of “change of intent” – that is, privilege abuse that puts data
at risk. This can be caused by an attacker impersonating the individual, or employees with malicious intent (e.g.,
“harvesting” enterprise data before moving to a competitor).
What to look for
• Review the tables accessed, find the ones with the highest volume queried, and see if they contain sensitive
data. To do this:
Information review the list of tables accessed, sorted by volume.
• Look at the source application (the client tool that was used to connect to the database), as this can indicate the
purpose of the activity. To do this:
In the UI, click Security Events->Incidents, click on the incident you are investigating and under Client Details
view the Source Application details.
• Find the individual who performed the query and verify this exception is warranted. To do this:
you can view the Source User details.
If there is a WAF in non-blocking mode front of the application, it is worth establishing that there is no suspected alert
in the WAF for the same incident (such as a SQL injection).
Exceptions
As always, exceptional procedures may query an abnormally high number of records. Based on the thresholds
established by Data Risk Analytics, this is something that should occur very rarely, and hence it is better to err on the
side of caution in these cases.

Excessive Failed Logins

What it means
A user has failed to login more times than typical for this particular account owner.
Implications
This could be an indication of brute-force attempts to takeover an account.
What to look for
Examine the incident details and Imperva On-Premises audit logs as required to determine:
• The number of attempts that took place

• Whether the attempts succeeded
• If the attempt(s) succeeded, check to see what data was accessed. Note that even if data was not accessed, this
will not necessarily indicate that this was legitimate login.
• Trace the activity to the human user, and verify it was indeed this person performing the action.
Exceptions
While the threshold in Data Risk Analytics is high, a user who is consistently incorrectly typing his password may
trigger this alert. Generally speaking, these cases should be rare enough to warrant a quick check with that user to
ensure it was indeed them.

Excessive Failed Logins from Application Server

What it means
A user failed to log in to the database from an application server.
Implications
Applications that reside on application servers typically have the login credentials hard coded, and therefore should
not fail their logins. Even just one failed login attempt from an application is a prime indicator that a hacker is
attempting to escalate privileges. This often takes place while attempting a default password, because brute-forcing a
production database may result in account lockout by the database itself.
What to look for
Look at the source and time of the activity. Trace this back to what happened on the application server at the time of
the failed login to find out who or what caused this attempt. To do this:
In the UI, click Security Events->Incidents, click on the incident you are investigating and under Incident Details
review the logins details.
Exceptions
• In some cases, bugs may cause the application to fail a login. While this is not a security incident, it should be
reported and fixed.
• A human user, such as an administrator, may connect to a database from an application server for
troubleshooting purposes and fail to login during this process. While these cases should be rare enough to
warrant investigation, it is possible to set an Allow List rule for certain users for login failure behavior.

Excessive Multiple Database Access

What it means
A user has attempted to access an abnormally high number of different databases over a short period of time.
Implications
This could be an indication that a hacker or malicious user is running a reconnaissance attack searching for
interesting databases that can be accessed in the organization.
What to look for
• Review the amount and diversity of databases this individual attempted to access, as well as whether the access
was successful or not. To do this:
In the UI, click Security Events->Incidents, click on the incident you are investigating and under Incident
Details review the list of databases that were attempted access, including the database accounts used for that
purpose.
• Look at the typical behavior for this individual and compare the databases regularly accessed by this user to the
databases that triggered this incident. To do this:
In the UI, click Security Events->Incidents, click on the incident you are investigating and under Typical
Behavior review the databases typically accessed by this user.
• Find the individual who performed the command and verify that it was indeed performed by this individual and
not by someone impersonating them. To do this:
you can view the source user details.
Exceptions
Exceptional procedures may require accessing an abnormal amount of databases over a short period of time. Based
on the baseline established by Data Risk Analytics, this is something that should occur very rarely, and hence it is
better to err on the side of caution in these cases.

Machine Takeover
What it means
A user logged in to another employee’s corporate device to access a database.
Implications
This is a key indicator that a user device/endpoint is compromised. An attacker that gains access to an individual’s
endpoint may use it to access to data repositories using stored or stolen credentials.
What to look for
• Look at the IP and host (if available), and determine the assigned owner of this host. If it is a server rather than
an endpoint, ensure that the User Name can be traced to an individual. To do this:
you can view the Source IP and Host details.
• In Data Risk Analytics, review the "typical behavior" section under the incident details to see the users that
normally use this host to access databases. To do this:
Behavior find the users that normally use this host to access databases.
• To establish the scope of potential damage, look at the tables accessed and view the table names, particularly
those identified as sensitive tables used by applications. To do this:
Information review the list of tables accessed.
• If the individual that performed the access is identified, contact them as well as the owner of the machine to
verify that this activity is legitimate.

Suspicious Sensitive System Tables Scan

What it means
An interactive (human) user has scanned sensitive system tables on several databases over a relatively short period of
time in an abnormal way.
Implications
This could be an indication that a hacker or malicious user is running a reconnaissance attack searching for
interesting databases that can be accessed in the organization
What to look for
• Review the amount and diversity of tables this individual accessed, to ensure this a normal behavior of this user.
To do this:
Details review the list of tables that were accessed, including the database accounts used for that purpose.
you can view the source user details
• Review the failed login attempts to databases attempted by this user, high amount can be an indication of an
attempted reconnaissance attack. To do this:
Details review the list of failed logins.
Exceptions
Data Risk Analytics will automatically learn human (interactive) users, such as DBAs, accessing sensitive tables. If a
specific DBA did not access these sensitive tables during the learning stage, a single incident might occur.

Suspicious Application Data Access

What it means
An interactive (human) user is directly accessing business data that should normally only be accessed via an
application.
Note: This incident is generated only if the individual did not recently access the database table in
question.
Implications
Permissions to access business data are granted and managed through the application. The application therefore
enforces access data on a need-to-know basis. At the same time, individuals in the organization - such as DBAs and
developers - are tasked with maintaining the integrity and operation of the system and data. For this reason, they are
granted almost full access to the data. These individuals expose the enterprise to risk because:
• Their credentials are desirable targets for hackers.

• They can make mistakes that expose and duplicate sensitive application data, moving it outside the purview of
IT control.
• In the event there is malicious intent, these individuals have a carte blanche to access to all data.
These individuals, however, should not access sensitive business data as part of their jobs (except in rare
emergencies). Access to application data – as opposed to metadata – may be an indication of potential compromise,
malice or negligence. This also violates compliance best practices that are part of PCI-DSS and ISO/IEC-27002, which
recommend that data is only accessed on a need-to-know basis.
What to look for
• First and foremost, it is important to clearly identify the individual behind the activity. The database access
activity must be clearly traceable to an individual. To do this:
click on the source user. The Employee Profile screen is displayed and you can view the User Name details.
• Once traceable, look at the source application (the client tool that was used to connect to the database) used to
access the data to determine if it is a free form query tool such as SQL*Plus, or a dedicated reporting tool. To do
this:
you can view the Source Application details.
• To give some context into the potential sensitivity of the data, look at the following:

• In Data Risk Analytics, review the “typical behavior” of the user via the Incident Details screen to see
the applications that normally access this data. This will give you an idea of the type of data that was
accessed, and whether it makes sense for this individual to access it. To do this:
Typical Behavior review the details.
• Look at the actual tables accessed. By default, tables identified as application tables will appear first in
the incident DB operations list. The priority of this case may hinge on the nature of these tables, their
names often give away the sensitive nature of the data (e.g., credit card data or social security
number). It is also interesting to look at the number of records accessed and the type of operation
performed (e.g., select, update or delete).
Exceptions
In a few cases, individuals will need to directly access application data:
• Emergencies: Sometimes urgent, unplanned operations need to take place immediately, which is why
administrators are granted high privilege in the first place. Just like a police officer firing his weapon, these
cases should be rare enough that you will want to review them and verify they are explained and legitimate.
• DevOps: In some applications, DevOps requires individuals to update database tables directly or query data into
a different system. While this does expose data, it may be a necessary evil, even if only for the early stages of the
project lifecycle.
In these cases, Data Risk Analytics will gradually learn the access habits by each individual and stop alerting on
recurring behavior. Until then, you may apply a time-bound Allow List rule to avoid further alerts. It is important
to emphasize that if there is a change of intent, Data Risk Analytics will continue to pick up on behavioral
changes.
• Business users: In some systems, business users need direct access to production data. Examples may include
business reporting and application analytics. In these cases, it is recommended that these business users work
on a masked clone of the data as much as possible (learn about Imperva data masking here). This way, any
misuse of their accounts (whether the result of credential compromise, or careless or malicious behavior by the
actual account owner) will cause as minimal damage as possible to the organization.
If this is not a viable option, the recommendation is the same as that of DevOps (above). Data Risk Analytics will
gradually learn the standard behavior by these individuals and alert only on changes in behavior.
• Rare applications: In rare cases, applications with sporadic usage patterns may take longer to be identified by
Data Risk Analytics as application servers. In this case, Imperva recommends that you set an Allow List rule for
the very specific combination of source IP, application, User Name, DB User and specific list of tables for this
specific incident type. Data Risk Analytics will continue to alert on changes in behavior by this application.

Suspicious Database Command Execution

What it means
A user performed a command that is highly suspicious in nature in an abnormal way.
Implications
Several database commands are rarely performed by users, whether interactive users or application users. Many
times these commands can bypass the regular permission model of the database allowing who ever uses them to
obtain elevated privileged access to the database potentially going unnoticed. Thus, when such commands are
performed they should automatically raise a suspicion, especially when the usage pattern differs from the established
baseline of the user. The real intent behind these commands is usually difficult to detect due to the complexity of their
usage, and as a result is an effective evasion technique used by hackers and malicious users.
In many cases the best practice would be to completely disable the option of running such commands on the
databases within your organization.
What to look for
• Review the actual command performed by this individual and try to understand whether this is legitimate
activity or not. To do this:
Details review the actual command which triggered this incident.
• Look at the typical behavior of this individual and compare the activity in this incident to the usual activity
performed by this individual. To do this:
Behavior review how typically this command is run by this individual.
you can view the source user details.
Exceptions
Exceptional procedures may require running complex database operations that can only be achieved by running
complex commands. Based on the baseline established by Data Risk Analytics, this is something that should occur
very rarely, and hence it is better to err on the side of caution in these cases.

Suspicious Dynamic SQL Activity

What it means
An interactive (human) user has queried a database using dynamic SQL queries in an abnormal way.
Implications
While dynamic SQL queries can be used for legitimate purposes, they are also an effective evasion technique used by
hackers and malicious users. This is due to the complexity of dynamic SQL queries and the difficulty of understanding
the real intent behind them. For this reason, dynamic SQL queries ran by interactive users are to be suspected,
especially when they are performed in an anomalous way, which differs significantly from typical access patterns.
What to look for
• Review the dynamic SQL queries performed by this individual and try to understand whether sensitive tables
were accessed. To do this:
Details review the dynamic SQL queries which triggered this incident.
• Find the individual who performed the query and verify this exception is warranted. To do this:
you can view the Source User details.
• Look at the typical behavior for this individual to establish whether the activity flagged is indeed abnormal and
requires further investigation. To do this:
Behavior review the dynamic SQL queries that are typically run by this individual.
Exceptions
Exceptional procedures may require running complex database operations that can only be achieved by running
dynamic SQL queries. Based on the baseline established by Data Risk Analytics, this is something that should occur
very rarely, and hence it is better to err on the side of caution in these cases.

Excessive File Access

What it means
An individual has accessed files in excess of what this individual, their peer group, and the organization normally
access.
Implications
Excessive file access is a key risk factor and indicator of “change of intent” – that is, privilege abuse that puts data at
risk. This can be caused by an attacker impersonating the individual, or employees with malicious intent (e.g.,
This incident may also occur out of negligence. For example, an employee that copies the entire contents of a shared
folder onto their personal workstation, increasing the exposure and risk to these files.
What to look for
• In Data Risk Analytics, look for the User Name to get visibility into the identity of the person who
initiated the access. To do this:
user details.
• Once the individual behind the activity is found, it is important to establish:

• The sensitivity of the data retrieved. To do this:
Incident Details view the root folder of the accessed files and see if it contains sensitive data.
• The amount of files accessed in comparison to the typical behavior of this individual, their peer group
and the organization. To do this:
Incident Details view the number of files accessed. Now click on the Typical Behavior tab to view the
established baseline of this individual, their peer group and the organization.
• Speak to the individual who performed the access (or their manager) and confirm that this activity had a
legitimate business purpose.
Exceptions
Exceptional procedures may require access to an abnormally high number of files. Based on the thresholds

Excessive Personal File Access

What it means
An individual accessed more files from their personal or department folder than what this individual, their peer group,
and the organization normally accesses.
Implications
Excessive file access is a key risk factor and indicator of “change of intent” – that is, privilege abuse that puts data at
risk. This can be caused by an attacker impersonating the individual, or employees with malicious intent (e.g.,
This incident may also occur out of negligence. For example, an employee that copies the entire contents of a shared
folder onto their personal workstation, increasing the exposure and risk to these files.
What to look for
• In Data Risk Analytics, look for the User Name to get visibility into the identity of the person who
initiated the access. To do this:
user details.
• Once the individual behind the activity is found, it is important to establish:

• The sensitivity of the data retrieved. To do this:
Incident Details view the root folder of the accessed files and see if it contains sensitive data.
• The amount of files accessed in comparison to the typical behavior of this individual, their peer group
and the organization. To do this:
Incident Details view the number of files accessed. Now click on the Typical Behavior tab to view the
established baseline of this individual, their peer group and the organization.
Exceptions
Exceptional procedures may require access to an abnormally high number of files. Based on the thresholds

Slow Rate File Access

What it means
An individual has accessed files at an exceptionally slow rate in comparison to the typical access rate of this individual,
their peer group, and the organization.
Implications
Slow rate file access may indicate that files were exported to an external network using a VPN connection, or to an
external device (such as a USB drive). Removing sensitive enterprise data from the enterprise systems may put the
data at risk, since it moved data outside the purview of IT control. This can be caused by an attacker impersonating
the individual, or negligent employees that unknowingly put enterprise data at risk.
What to look for
• Under Incident Details review the root folder of the accessed files, and see if it contains sensitive data.
• Under Incident Details review the rate of access to these files in comparison to the typical behavior of this
individual, their peer group and the organization which can be found under Typical Behavior.
• Under Client Details review the client IP address to determine if the activity originated from a VPN IP range.
Exceptions
In some cases, pulling out files using a VPN connection or to an external device is warranted.
Based on the thresholds established by Data Risk Analytics, this is something that should occur very rarely, and hence
it is better to err on the side of caution in these cases.

Slow Rate Personal File Access

What it means
An individual has accessed files from their personal or department folder at an exceptionally slow rate in comparison
to the typical access rate of this individual, their peer group, and the organization.
Implications
Slow rate file access may indicate that files were exported to an external network using a VPN connection, or to an
external device (such as a USB drive). Removing sensitive enterprise data from the enterprise systems may put the
data at risk, since it moved data outside the purview of IT control. This can be caused by an attacker impersonating
the individual, or negligent employees that unknowingly put enterprise data at risk.
What to look for
• Under Incident Details review the root folder of the accessed files, and see if it contains sensitive data.
• Under Incident Details review the rate of access to these files in comparison to the typical behavior of this
individual, their peer group and the organization which can be found under Typical Behavior.
• Under Client Details review the client IP address to determine if the activity originated from a VPN IP range.
Exceptions
In some cases, pulling out files using a VPN connection or to an external device is warranted.
Based on the thresholds established by Data Risk Analytics, this is something that should occur very rarely, and hence
it is better to err on the side of caution in these cases.

Suspicious File Access

What it means
An individual has accessed files that are unrelated to themselves and/or their peer group. In order to determine that
this file access is suspicious, Data Risk Analytics automatically learns how users across the organization access
enterprise files and places them into “virtual” working groups. Once peer groups are identified, Data Risk Analytics
flags risky file access from unrelated individuals.
Implications
Suspicious file access may indicate that a user is accessing files they shouldn’t be accessing. This can be caused by an
attacker impersonating the individual, harvesting sensitive data and trying to take it out of the organization, or
employees with malicious intent. In other cases, it can be caused by negligent employees that unknowingly try to
access data they should not be accessing.
What to look for
• Under Client Details review details related to the individual that performed the suspicious file access. This
includes their user name, department and role to get visibility into the identity of the person who initiated the
access.
• Under Incident Details review and investigate the actual folders and files accessed by this individual to
establish their level of sensitivity.
• Navigate to Typical Behavior to investigate the users who regularly access these folders.
• Be sure to also review the Associated Groups column. This field tells you what Active Directory groups are most
closely associated with these folders. This provides context about the nature of the files pertaining to the
incident.
Note: Machine learning is used to identify the AD groups that are most relevant to the files
accessed in this incident.
Exceptions
Exceptional procedures may require access to files that are regularly not accessed by an individual and their peer
group.
In some cases, public folders that are regularly accessed by a specific set of users can be attributed to these common
users and their peer group, generating an alert when a new individual accesses these folders. Since these are public
folders, it is recommended to set an Allow List rule for this type of incident from triggering on these specific folders.

Understanding Health Status Errors

This appendix provides in depth details on each of the error messages you may receive as a result of the unhealthy
status of the system. These details include: What the error means, what is the reason or possible reason for the error,
steps to try and resolve and what to do if the problem persists.
• Admin Server Errors

• Analytics Server Errors
• Active Directory Errors
• General Errors

Admin Server Errors

The following errors are related to the Data Risk Analytics Admin server.
• Admin server components are not fully functioning

• Failed to connect to the Admin server. Unmatched version on the Analytics server

Admin server components are not fully functioning
How to resolve
1. Connect via ssh to the Data Risk Analytics Admin server.

2. Run the command cbctl restart to restart all processes.
3. Wait for the web interface to load (can take up to three minutes) and check in the dashboard if the error still
exists.
4. If the problem persists, contact Imperva support and provide them with the log files obtained by running the
command cbctl support get-tech-info from the command line.

Failed to connect to the Admin server. Unmatched version on the Analytics server
How to resolve
1. Connect via ssh to the Analytics server.

2. Run the command cbctl status and check that the software version corresponds to the one on the Admin
server.
3. If it does not correspond, upgrade the Analytics server to match the version on the Admin server.

Analytics Server Errors

The following errors are related to the Data Risk Analytics Analytics server.
• Analytics server components are not fully functioning, and thus data cannot be processed successfully
• Analytics server configuration not synced with the admin server
• Analytics server disk space usage exceeds 90% of the capacity: x/y GB used
• Analytics server disk space usage exceeds 95% of the capacity: x/y GB used
• Analytics server failed to process DB/file/DB & file information
• Analytics server(s) is(are) not configured
• Analytics server is utilized at X% of its capacity
• Audit data from [fromTime]-[toTime] from policy [PolicyName] received from SecureSphere gateway
[GatewayName] could not be processed successfully
• Audit data from file [file-name] failed to load
• Audit data from policy [PolicyName] from SecureSphere gateway [GatewayName] has not been received for
[NumOfDays] days.
• Database/File audit data received on [Date] was only partially processed
• Failed to connect from the Analytics server to the Admin server
• Failed to connect to Analytics server
• Failed to retrieve data from Analytics server
• High CPU usage: X% on average

Analytics server components are not fully functioning, and thus data cannot be processed
successfully
How to resolve

2. Run the command cbctl restart
3. Wait five minutes and check in the dashboard if the error still exists.

Analytics server configuration not synced with the admin server
How to resolve
1. Connect via ssh to the Admin server.

exists.

Analytics server disk space usage exceeds 90% of the capacity: x/y GB used
How to resolve

2. Clear the /var/tmp directory.
3. Try to clear the oldest files from the /opt/itpba/incoming/archives/error-archives and from the /opt/itpba/
incoming/saved-archives folders.
4. Run the command cbctl status and check that the used disk space is green.
5. If the problem persists, perform the following steps to increase storage on the VM server:
1. Run the command cbctl stop
2. Power off the VM server.
3. Add a new disk to the VM of at least 200GB.
4. Power on the VM server.
5. Wait up to 30 minutes to allow the process of adding disk space to finish, then run the command cbctl
status to check that the used disk space is green.

Analytics server disk space usage exceeds 95% of the capacity: x/y GB used
How to resolve

2. Clear the /var/tmp directory.
3. Try to clear the oldest files from the /opt/itpba/incoming/archives/error-archives and from the /opt/itpba/
incoming/saved-archives folders.
4. Run the command cbctl status and check that the used disk space is green.
5. If the problem persists, perform the following steps to increase storage on the VM server:
1. Run the command cbctl stop
2. Power off the VM server.
3. Add a new disk to the VM of at least 200GB.
4. Power on the VM server.
5. Wait up to 30 minutes to allow the process of adding disk space to finish, then run the command cbctl
status to check that the used disk space is green.

Analytics server failed to process DB/file/DB & file information
How to resolve

2. If the error indicates it is for file or DB & file information, run the command cbctl analyticsserver
set-file-profiler-limit high
4. Wait five minutes and run the command cbctl analyticsserver profiler profile-now
5. Wait one day and check in the dashboard if the error still exists.
command cbctl analyticsserver profiler profile-now from the command line.

Analytics server(s) is(are) not configured
How to resolve

2. Run the command cbctl ip set
3. Follow the on-screen instructions for inserting the information of the Data Risk Analytics Analytics server.
exists.
5. Repeat steps 1-4 for all Analytics servers.

Analytics server is utilized at X% of its capacity
How to resolve

2. Run the command cbctl analyticsserver load show to show full analysis of the existing load.
3. If a single Destination(s) in the list causes more than 50% of the load, contact Imperva support. Otherwise,
consider deploying an additional Data Risk Analytics environment in order to split the load between the
environments.
In order to control the list of Destinations that are excluded from the analysis:
1. Run the command cbctl analyticsserver load show to show full analysis of the existing load.
2. Run one or more of the following commands to change the list of Destinations that are excluded from the
analysis:
1. cbctl analyticsserver load excluded-destinations add [comma separated
list of destinations] to exclude additional Destinations from the analysis.
2. cbctl analyticsserver load excluded-destinations remove [comma separated
list of destinations] to return excluded Destinations back to the analysis.
3. cbctl analyticsserver load excluded-destinations clear to return all Destinations
back to the analysis.
Note: If the system identifies a load problem again, it will automatically exclude additional
Destinations from the Data Risk Analytics analysis.

Audit data from [fromTime]-[toTime] from policy [PolicyName] received from SecureSphere
gateway [GatewayName] could not be processed successfully
How to resolve

2. Run the command cbctl support get-tech-info from the command line to obtain the log files.
3. Contact Imperva support and provide them with these log files.

Audit data from file [file-name] failed to load
The possible reason for this error is that there is a file that was not processed successfully by the ETL. This can occur
because:
• The file is encrypted and no matching decryption key was found

• The policy is not configured correctly in Imperva On-Premises
• The policy name is unrecognized
• The audit data handling failed
• The audit data is corrupted
• Audit data from file [file-name] failed to load. Audit data handling failed
• Audit data from file [file-name] failed to load. Corrupted audit data
• Audit data from file [file-name] failed to load. File is encrypted and no matching decryption key was found
• Audit data from file [file-name] failed to load. Policy is not configured correctly in SecureSphere
• Audit data from file [file-name] failed to load. Policy name is unrecognized

Audit data from file [file-name] failed to load. Audit data handling failed
How to resolve


Audit data from file [file-name] failed to load. Corrupted audit data
How to resolve


Audit data from file [file-name] failed to load. File is encrypted and no matching decryption key was found
How to resolve
1. Verify that the process written in the Data Risk Analytics User Guide under Advanced Procedures > Encrypted
Archive Files was performed (if you are not sure, you can run it again).
3. Run the command cbctl analyticsserver failed_audit_files retry

Audit data from file [file-name] failed to load. Policy is not configured correctly in SecureSphere
How to resolve
1. Log into the Imperva On-Premises Management server.

2. In the Main workspace, select Policies > Audit.
3. For the relevant policy, verify it is configured exactly as described in the Data Risk Analytics Installation Guide
under Configuring Imperva On-Premises for Data Risk Analytics.
4. Run the command cbctl analyticsserver failed_audit_files retry

Audit data from file [file-name] failed to load. Policy name is unrecognized
How to resolve
1. If you did not manually change the default policy names expected by Data Risk Analytics, verify the policy name
in Imperva On-Premises is exactly as detailed in the Data Risk Analytics User Guide under Configuring Imperva
On-Premises for Data Risk Analytics.
2. If you have manually changed the default policy names expected by Data Risk Analytics, perform the following
steps:
2. Go to the /opt/itpba/conf folder and view the contents of the file etlConfigOverrides.properties.
3. If there are lines that do not begin with a # sign, look at their values and verify the policy name in Imperva
On-Premises contains these values.
4. For example: In the line secure.sphere.itp.aa1.policy=some_value, verify the policy name in Imperva
On-Premises contains the string some_value in its name.
5. If all lines begin with a # sign, change the policy name in Imperva On-Premises or change/add the correct
value in the etlConfigOverrides.properties file.
6. If you made changes to the etlConfigOverrides.properties file, run the command cbctl restart for
the change to take effect.
For more information, see the Changing Policy Names section in the Data Risk Analytics User Guide.
3. Run the command cbctl analyticsserver failed-audit-files retry


Audit data from policy [PolicyName] from SecureSphere gateway [GatewayName] has not been
received for [NumOfDays] days.
How to resolve
1. This error might be expected in certain cases (either the policy or gateway have changed their name or they are
no longer supposed to be sending data to Data Risk Analytics). If this is the case, ignore the error (will disappear
with time).
2. If the error is not expected, connect via ssh to the Analytics server.
3. Check that the /opt/itpba/incoming/archives folder is empty.
4. If the folder is not empty, wait a few hours for it to empty and see if the error still appears in the dashboard.
5. If the problem persists, log into the Imperva On-Premises Management server.
6. Go to Admin > Job Status > Audit Archiving and search for the relevant archive job.
7. Click on the Execution History tab and verify there are no errors showing.
8. If there are continuous errors, contact Imperva support.

Database/File audit data received on [Date] was only partially processed
How to resolve


Failed to connect from the Analytics server to the Admin server
How to resolve

2. Run the command cbctl status and check that the IP address/host under the Admin Server IP field
corresponds to the IP address/host of the Admin server.
3. If it does not correspond, run the command cbctl adminserver analyticsserver-ip set and
enter the correct IP address/host of the Admin server when asked (answer n to all other questions)
4. If the IP/host corresponds and it is a host, check that the DNS settings are correct as follows:
1. Run the command cat /etc/resolv.conf
2. Verify the DNS IP and the fully qualified domain name are correctly set.
3. If they are not:
▪ Run the command cbctl hostname set in the command line and type the new host name
▪ Run the command cbctl dns set in the command line and follow the on-screen instructions
5. Verify no firewall rules are denying access from the Analytics server to the Admin server on ports 61617 and
8443.

Failed to connect to Analytics server
The possible reason for this error is that there is no connectivity from the Admin server to the Analytics server. This
can occur because:
• The host/IP address is unknown

• The password from the communication between the two servers does not match
• Failed to connect to Analytics server. [IP/host] unknown

• Failed to connect to Analytics server on [IP]. Password does not match

Failed to connect to Analytics server. [IP/host] unknown
How to resolve

2. Run the command cbctl status and check that the IP address/host under the Analytics Server IP field
corresponds to the IP address/host of the Analytics server.
3. If it does not correspond, run the command cbctl ip set in the command line and follow on-screen
instructions.
4. If the IP/host corresponds and it is a host, check that the DNS settings are correct as follows:
3. If they are not, run the command cbctl dns set in the command line and follow on-screen
instructions.
5. Verify no firewall rules are denying access from the Admin server to the Analytics server on port 8443.

Failed to connect to Analytics server on [IP]. Password does not match
How to resolve

2. Run the command cbctl analyticsserver register-to-admin to re-register the Analytics server.

Failed to retrieve data from Analytics server
How to resolve

2. Run the command cbctl status and check that all processes are up.
4. Run the command cbctl status and check that all processes are up.

High CPU usage: X% on average
How to resolve


Active Directory Errors

The following errors are related to the active directory.
• Active directory [ADName] cannot be accessed

• No Groups found under Active Directory [ADName]. Please check the base search path is configured correctly
• No users found under Active Directory [ADName]. Please check the base search path is configured correctly
• Active Directory is not configured

Active directory [ADName] cannot be accessed
The possible reason for this error is that the specified active directory is not accessible. This can occur because:
• The credentials (username or password) are incorrect or do not match

• The host/IP or port are unknown
• The host can not be resolved
• One or more of the setup parameters is configured incorrectly
• Active directory [ADName] cannot be accessed. Bad username or password

• Active directory [ADName] cannot be accessed. Host cannot be resolved
• Active directory [ADName] cannot be accessed. Please make sure all the parameters are set correctly and that
the active directory server is reachable
• Active directory [ADName] cannot be accessed. Unknown host/IP or port

Active directory [ADName] cannot be accessed. Bad username or password
How to resolve
1. Log into the Data Risk Analytics Admin server.

2. Go to System > Active Directory and edit the problematic active directory endpoint.
3. Verify the username and password are set correctly and click Test Connection.

Active directory [ADName] cannot be accessed. Host cannot be resolved
How to resolve

3. Verify the host is set correctly.
4. Connect via ssh to the Admin/Analytics server and verify the DNS settings are accurate as follows:
3. If they are not, run the command cbctl dns set in the command line and follow the on-screen
instructions.
5. Click the Test Connection button and verify everything is working properly.

Active directory [ADName] cannot be accessed. Please make sure all the parameters are set correctly and that
the active directory server is reachable
How to resolve

3. Make sure all the parameters are set correctly and that the active directory server is reachable.

Active directory [ADName] cannot be accessed. Unknown host/IP or port
How to resolve

3. Verify the host/IP and port are set correctly.
Note: Different ports are used for SSL and non-SSL communication. Verify your port
corresponds to the connection you are using.
4. Verify no firewall rules are blocking access from the Data Risk Analytics Admin or Analytics servers to the Active
Directory server on the specified port.

No Groups found under Active Directory [ADName]. Please check the base search path is
configured correctly
How to resolve

3. Verify the Base Search Path For Users and Groups field is configured correctly to include a base search path
with all the groups in the organization.
4. Verify the configured group is not disabled in the active directory and has permissions to read groups under the
configured base search path.

No users found under Active Directory [ADName]. Please check the base search path is
configured correctly
How to resolve

3. Verify the Base Search Path For Users and Groups field is configured correctly to include a base search path
with all the users in the organization.
4. Verify the configured user is not disabled in the active directory and has permissions to read users under the
configured base search path.

Active Directory is not configured
How to resolve

2. Go to System > Active Directory.
3. Click Add.
4. Configure an Active Directory as described in the Data Risk Analytics User Guide.

General Errors
The following are health status general errors.
• General Error

General Error
How to resolve

5. Wait a few minutes and check in the dashboard if the error still exists.

Data Risk Analytics REST API Overview

This section is the reference document for the REST API and resources provided by Imperva Data Risk Analytics. The
REST APIs are for developers who want to access the Data Risk Analytics server directly. This document describes
various API operations, related request and response structures, and error codes.
Data Risk Analytics REST APIs provide access to resources (data entities) using URL paths. To use a REST API, your
application makes an HTTP request and parses the response. Data Risk Analytics REST API uses the following
information in order to identify and process each request:
• URL path – to identify the resource or resources to work on

• HTTP method – to identify the action to be done on the resource according to the following mapping:
• GET – fetch data about the resource
• PUT – Update a resource idempotently
• POST – Create a resource
• DELETE – delete a resource
• Query parameters – for additional information about the resource or required action
• HTTP request body in JSON format – for any additional information required
The following information is returned in the HTTP response of each request:
• HTTP response code – 200 for success and 4xx for a failure.
Note: A response code 302 may be returned when a request for a non valid base path is made.
• URL Structure
• SSL
• Authentication
• Authorization
• HTTP Return Codes
• Resources

URL Structure
URLs for the Data Risk Analytics REST API resource have the following base structure:
https://host:port/counterbreach/api/api-version/...
For example, to retrieve security event resources, the following URL should be used:
https://host:port/counterbreach/api/1.0/security_events
All the parameters should be URL encoded. In addition, parameters that are sent using a query string allow using the
plus sign (“+”) and %20 for encoding a space character.
• Provided Resources:
• Security Events
• Permissions

SSL
In order to invoke API requests, all communications must be done over SSL. This means that there must be a
certificate trust between the Data Risk Analytics server and the API client.
The certificate should be accepted by any https client that invokes the remote API.
Alternatively, although not recommended, the client can be configured to accept all certificates naively.

Authentication
Data Risk Analytics API supports HTTP Basic Authentication strategy. There is no need to establish an HTTP session
before consuming any of the exposed APIs. Each request must contain valid credential details in order to successfully
accomplish the request, otherwise http code 401 is returned.

HTTP Basic Authentication Header
Authorization: Basic {username}:{password}
Notes:
• The password should be sent as a plain text.

• “{username}:{password}” string should be encoded in Base64 URL, otherwise http code 401
is returned.
Possible Error Responses
The following responses can appear when invoking any API method:
HTTP Code Code Name Body and Description
401 Unauthorized {"errorCode":16010,"errorMessage":"Bad Credentials"}

Authorization
In order to get permission to consume the API, the specified user must be a valid active directory user and a member
of the CounterBreach_API group. Otherwise, HTTP code 401 is returned. In addition, Data Risk Analytics has to be
configured for authentication using active directory (for more information, see the Active Directory Integration
section in the Data Risk Analytics User Guide).
Note: The CounterBreach_API group grants access only to the REST API actions. To gain access to
the Data Risk Analytics admin web interface, the user must be a member of other active directory
groups that are related to Data Risk Analytics (for more information, see the Data Risk Analytics
User Guide). Imperva recommends assigning different users for API integrations and accessing the
admin web interface.
The following responses can appear when invoking any API method:
HTTP Code Code Name Body and Description
401 Unauthorized {"errorCode":16010,"errorMessage":"Bad Credentials"}

HTTP Return Codes

This section provides reference information about Data Risk Analytics open API errors.
Data Risk Analytics open API uses standard HTTP responses as follows:
• 200 for a successful request

• 401 for an unauthorized request. In this case, the specific internal reason for the failure is represented in the
HTTP body by the following JSON format:
{"errorCode":16010, "errorMessage": "Bad Credentials"}
• 403 for a missing or expired license.

• 404 for missing mandatory parameters or non-existing URLs
• 405 for a Not Allowed Method request. In this case, the specific internal reason for the failure is represented in
the HTTP body by the following JSON format:
{"errorCode":1010, "errorMessage": "{HTTPMethod} method is not supported for

this request. Supported methods are: {listOfSupportedMethods}"}
• 406 for an error request. In this case, the specific internal reason for the failure is represented in the HTTP body
by the following JSON format:
{"errorCode":1001, "errorMessage": "Field {fieldname} doesn't support value

{value}"}
The following table indicates the Data Risk Analytics general errors for HTTP 406 status.
Code Code Name Description
1001 Field value error The field does not support the value you are trying to use.

Resources
The following section lists the APIs used for:
• Security Events
• Permissions

Security Events
This section lists the APIs which can be used to retrieve security events:
• Get Security Events: Incidents/Anomalies/Both (v1.0)

• Get Event Class (v1.2)
• Get Event Class (v2.0)
• Get Incident Database Names (v1.2)
• Get Incident Database Names (v2.0)
• Get Anomaly Database Names (v1.2)
• Get Anomaly Database Names (v2.0)
• Update Event Class (v1.2)
• Update Event Class (v2.0)
• Update Incident (v1.2)
• Update Incident (v2.0)
• Update Anomaly (v1.2)
• Update Anomaly (v2.0)

Get Security Events: Incidents/Anomalies/Both (v1.0)
Description
Get a list of security events based on filter/search parameters. The list contains open incidents and anomalies only.
URL
https://host:port/counterbreach/api/1.0/security_events?
logged_before={logged_before}&event_category={event_category}&search={search}
HTTP Method
GET
URL Path Parameters
Parameter Description Value Notes
‘incident’ - get incidents

• incident Optional
event_category ‘anomaly’ - get anomalies • anomaly
• all Default value: ‘all’
‘all’ - get incidents and anomalies
A free-text filter. When specified, security

events are served only if they contain the
requested text in one or more of the Optional
following fields:
Default value: empty string
• id
• status Maximum number of chars:
search • severity (available for 'incidents' only) String 100. If a larger search text is
• type_description sent it is trimmed.
• log_time
• event_time Event Time and Log Time
• source_username value format are: Aug 16, 2016
• source_host 6:00:00 PM
• source_ip
• destination_ip
logged_before Log time before which to retrieve security

long Optional
events.

If not provided, all available

The format must be the milliseconds
security events are served
representation of the date from 1970 in GMT
based on the other search
time-zone
fields.
Possible Values for the type_code Parameter
The possible return values for the type_code parameter under each incident/anomaly are:
• DB_ACCOUNT_ABUSE
• DB_SUSPICIOUS_APPLICATION_TABLE_ACCESS
• DB_MACHINE_TAKEOVER
• DB_EXCESSIVE_FAILED_LOGINS_APPLICATION_SERVER
• DB_EXCESSIVE_FAILED_LOGINS
• DB_ACCESS_OUT_OF_HOURS
• EXCESSIVE_DB_RECORD_ACCESS
• EXCESSIVE_FILE_ACCESS
• EXCESSIVE_PERSONAL_FILE_ACCESS
• SLOW_RATE_PERSONAL_FILE_ACCESS
• SLOW_RATE_FILE_ACCESS
• SUSPICIOUS_COMMAND
incidentTypes
IncidentType Incident Name
DB_ACCOUNT_ABUSE Database Service Account Abuse
DB_SUSPICIOUS_APPLICATION_TABLE_ACCESS Suspicious Application Data Access
DB_MACHINE_TAKEOVER Machine Takeover
DB_EXCESSIVE_FAILED_LOGINS_APPLICATION_SERVER
DB_EXCESSIVE_FAILED_LOGINS Excessive Failed Logins

DB_ACCESS_OUT_OF_HOURS Database Access at Non-standard Time
EXCESSIVE_FILE_ACCESS Excessive File Access
EXCESSIVE_PERSONAL_FILE_ACCESS Excessive Personal File Access
SLOW_RATE_PERSONAL_FILE_ACCESS Slow Rate Personal File Access
SLOW_RATE_FILE_ACCESS Slow Rate File Access
SUSPICIOUS_FILE_ACCESS Suspicious File Access
EXCESSIVE_DB_RECORD_ACCESS Excessive Database Record Access
SUSPICIOUS_DYNAMIC_SQL_ACTIVITY Suspicious Dynamic SQL Activity
SUSPICIOUS_COMMAND Suspicious Database Command Execution
EXCESSIVE_MULTIPLE_DB_ACCESS Excessive Multiple Database Access
SENSITIVE_SYSTEM_TABLE_SCAN Suspicious Sensitive System Tables Scan
Response Body Example
• Anomalies Resource:
"events":[

"id":1402,
"status":"OPEN",
"event_category":"ANOMALY",
"type_code":"DB_ACCOUNT_ABUSE",
"type_description":"Database Service Account Abuse",
"log_time":1473058533846,
"event_time":1434351600000,
"source_username":[
"john.d"
],
"source_host":[
"JOHN_DOE-IL_5677-3567"
],
"source_ip":[
"10.2.33.55","10.2.33.66"
],
"destination_ip":[
"10.2.33.124","10.2.33.126"
• Incident Resource:
"events":[

"id":1402,
"status":"OPEN",
"event_category":"INCIDENT",
"severity":"LOW",
"log_time":1473058533846,
"event_time":1434351600000,
"source_username":[
"john.d"
],
"source_host":[
"JOHN_DOE-IL_5677-3567"
],
"source_ip":[
"10.2.33.55","10.2.33.66"
],
"destination_ip":[
"10.2.33.124","10.2.33.126"

Get Security Events: Incidents/Anomalies/Both (v1.2)
Description
Get a list of security events based on filter/search parameters. The list contains open incidents and anomalies only.
URL
https://host:port/counterbreach/api/1.2/security_events?
status=Open&event_category=all&event_class=all&search=&logged_before=
HTTP Method
GET
URL Path Parameters
‘open’ == open events

Optional
status ‘closed == close events String
Default value: ‘open’
‘all’ == both open and close events
‘Incident’ == get incidents

Optional
event_category ‘Anomalies’ == get anomalies • String
Default value: ‘All’
‘All’ == get incidents and anomalies
‘breach_detection’ == get all the events

classified as breach detection
Optional
event_class ‘risk_reduction’ == get all the events String
classified as risk reduction Default value: ‘all’
‘all’ == get all events
search A free-text filter. String Optional

Log time before which to retrieve security

logged_before long Optional
events.
Possible Values for the type_code Parameter
The possible return values for the type_code parameter under each incident/anomaly are:
• DB_SUSPICIOUS_APPLICATION_TABLE_ACCESS
• DB_EXCESSIVE_FAILED_LOGINS_APPLICATION_SERVER
• DB_EXCESSIVE_FAILED_LOGINS
• EXCESSIVE_FILE_ACCESS
• EXCESSIVE_PERSONAL_FILE_ACCESS
• SLOW_RATE_PERSONAL_FILE_ACCESS
• SLOW_RATE_FILE_ACCESS
incidentTypes

• Anomalies Resource:
"events":[

"id":1402,
"status":"OPEN",
"event_category":"ANOMALY",
"log_time":1473058533846,
"event_time":1434351600000,
"source_username":[
"john.d"
],
"source_host":[
"JOHN_DOE-IL_5677-3567"
],
"source_ip":[
"10.2.33.55","10.2.33.66"
],
"destination_ip":[
"10.2.33.124","10.2.33.126"
],
"status_change_time": 1607867783052,
"source_app": [
"newApp"

• Incident Resource:
"events":[
"id":1402,
"status":"OPEN",
"event_category":"INCIDENT",
"severity":"LOW",
"log_time":1473058533846,
"event_time":1434351600000,
"source_username":[
"john.d"
],
"source_host":[
"JOHN_DOE-IL_5677-3567"
],
"source_ip":[
"10.2.33.55","10.2.33.66"
],
"destination_ip":[
"10.2.33.124","10.2.33.126"
],
"status_change_time": 1607867783052,
"source_app": [

"newApp"
HTTP Code DRA Code Body and Description
406 1001 Field \"status\" doesn't support value \"close\"

Get Event Class (v1.2)
Description
Get the event types per class.
URL
https://host:port/counterbreach/api/1.2/security_events/settings?event_class=risk_reduction
HTTP Method
GET
URL Path Parameters
‘breach_detection’ == get all the event types

classified as breach detection
event_class String Mandatory
‘risk_reduction’ == get all the event types
classified as risk reduction
"event_class": "risk_reduction",
"event_types": ["DB_ACCOUNT_ABUSE", " DB_SUSPICIOUS_APPLICATION_TABLE_ACCESS"]
406 1001 Field "event_class" doesn't support value "close"

Get Incident Database Names (v1.2)
Description
Get a list of database names associated with the incident.
URL
https://host:port/counterbreach/api/1.2/security_events/incidents/<incident_id>/databases
HTTP Method
GET
URL Path Parameters
event_id The id of the incident long
“databases”:[
“db_type:”Oracle”
“destination_ip”:”10.1.1.1”,
“db_name”:”db1”

406 1026 No incident with id %s exists in the system
No databases exist for an incident of type 'Excessive File Access'

406 1028
This error will be shown for FAM incidents.

Get Anomaly Database Names (v1.2)
Description
Get a list of database names associated with the anomaly.
URL
https://host:port/counterbreach/api/1.2/security_events/anomalies/<anomaly_id>/databases
HTTP Method
GET
URL Path Parameters
event_id The id of the anomaly long
“databases”:[
“db_type:”Oracle”
“destination_ip”:”10.1.1.1”,
“db_name”:”db1”

406 1027 No anomaly with id %s exists in the system
No databases exist for an anomaly of type 'Excessive File Access'

406 1029
This error will be shown for FAM anomalies.

Update Event Class (v1.2)
Description
Update the event class settings.
URL
https://host:port/counterbreach/api/1.2/security_events/settings
HTTP Method
PUT
Request Body Parameters
‘breach_detection’
event_class String Mandatory
‘risk_reduction’
A list of the permitted event types
•
DB_SUSPICIOUS_APPLICATION_TABLE_ACCESS
• List of strings
permitted_event_types DB_EXCESSIVE_FAILED_LOGINS_APPLICATION_SERVER Mandatory
• DB_EXCESSIVE_FAILED_LOGINS for empty []
• SUSPICIOUS_DYNAMIC_SQL_ACTIVITY
• EXCESSIVE_MULTIPLE_DB_ACCESS
• SENSITIVE_SYSTEM_TABLE_SCAN
Request Body Example
"event_class": "risk_reduction",
"event_types": ["DB_ACCOUNT_ABUSE", " DB_SUSPICIOUS_APPLICATION_TABLE_ACCESS"]

406 1001 Field "event_class" doesn't support value "close"
406 1033 Invalid event type – DB_ACCOUNT_ABUSEe"

Update Incident (v1.2)
Description
Update the incident settings of comments, open/closed status and star/unstar.
URL
https://host:port/counterbreach/api/1.2/security_events/incidents/<event_id>
HTTP Method
PUT
URL Path Parameters
event_id The id of the updated event long
comment The new comment String Optional
star Star/unstar boolean Optional
status Open/Closed String Optional
close_reason The reason for the closure String Optional
"comment": "comment",
"star": true,

"status": "Closed",
"closing_reason": "Resolved"
Request Body Partial Example
"star": true
406 1026 Incident does not exist
Field status does not support value <invalid value>

406 1019
Valid incident statuses are: Closed,Open"
Field closingReason does not support value <invalid value>

406 1019
Valid close reasons are:
Authorized,Resolved,Whitelisted,Misclassified,Permitted
406 1041 closingReason can only be used when the event is closed

Update Anomaly (v1.2)
Description
Update the anomaly settings of comments, open/closed status and star/unstar.
URL
https://host:port/counterbreach/api/1.2/security_events/anomalies/<event_id>
HTTP Method
PUT
URL Path Parameters
event_id The id of the updated event long
comment The new comment String Optional
star Star/unstar boolean Optional
status Open/Closed String Optional
close_reason The reason for the closure String Optional
"star": true,

"status": "Closed",
"closing_reason": "Resolved"
Request Body Partial Example
"star": true
406 1026 Incident does not exist
Field status does not support value <invalid value>

406 1019
Valid anomaly statuses are: Closed,Open"
Field closingReason does not support value <invalid value>

406 1019
Valid close reasons are:
Authorized,Resolved,Whitelisted,Misclassified,Permitted
406 1041 closingReason can only be used when the event is closed

Permissions
This section lists the APIs which can be used to retrieve permission settings:
• Get User’s Permissions (v1.0)

• Get User’s Permissions (v2.0)
• Get Incident Responder User’s Permissions (v1.2)
• Get Application Owner User’s Permissions (v1.2)
• Get Restricted Data (v1.2)
• Get Restricted Data (v2.0)
• Update Incident Responder User’s Permissions (v1.2)
• Update Application Owner User’s Permissions (v1.2)
• Update Restricted Data (v1.2)
• Update Restricted Data (v2.0)
• Update User's Permissions (v2.0)

Get User’s Permissions (v1.0)
Description
This API returns for each user from the "incident responders" role the set of destination IPs that they are allowed to
see and work on. This API retrieves the entire list of users with their corresponding destination IPs list.
URL
https://host:port/counterbreach/api/1.0/users/permissions
HTTP Method
GET
"permissions": [
{ "username": "John Doe", "allowed_destination_ips": ["10.2.33.124",

"10.2.33.126"] }
{ "username": "Albert Simon", "allowed_destination_ips": ["*"] }

Get Incident Responder User’s Permissions (v1.2)
Description
This API returns for each user from the "incident responders" role the set of destination IPs that they are allowed to
see and work on. This API retrieves the entire list of users with their corresponding destination IPs list.
URL
HTTP Method
GET
"permissions": [{
"username": " John Doe",
"allowed_destination_ips": ["10.2.33.124", "10.2.33.126"],
"userId": "C1Xyl4zhc0+FEsvjg2V3EA==\r\n",
"comment": ""
}]

Get Application Owner User’s Permissions (v1.2)
Description
This API returns the set of destination IPs for each user from the "application owners" role that they are allowed to see
and work on. This API retrieves the entire list of users with their corresponding destination IPs list.
URL
https://host:port/counterbreach/api/1.2/users/permissions/appowners
HTTP Method
GET
"permissions": [{
"username": " John Doe",
"allowed_destination_ips": ["10.2.33.124", "10.2.33.126"],
"userId": "C1Xyl4zhc0+FEsvjg2V3EA==\r\n",
"comment": ""
}]

Get Restricted Data (v1.2)
Description
Get the restricted data per role. Restricted data means the permitted event types of this role, the group name in the
active directory that the members of this role will be pulled from and the permitted configuration for this role.
URL
https://host:port/counterbreach/api/1.2/users/settings?role=IncidentResponders
HTTP Method
GET
URL Path Parameters
‘IncidentResponders’
‘ApplicationOwners‘
role ‘SecurityEngineers‘ String Mandatory
'admin'
‘api'
"role": "IncidentResponders",
"permitted_event_types": "DB_ACCOUNT_ABUSE"],
"group_name_in_ad": "CounterBreach_IncidentResponders",
"configuration": ["Allow_List"]

406 1031 Invalid role - <role>

Update Incident Responder User’s Permissions (v1.2)
URL
HTTP Method
PUT
"user_id": "qF5YuBNIjEOLGiodsKMD8w==\r\n",
"allowed_destination_ips": ["1.1.1.1"],
"comment": "comment"
406 1022 Invalid IP address - <invalid ip address>
Invalid input – either use a wildcard ‘*’ or a list of IP addresses, but not
406 1023
both
406 1024 Cannot find user_id - <user_id>
406 1025 user_id cannot be empty

Update Application Owner User’s Permissions (v1.2)
URL
https://host:port/counterbreach/api/1.2/users/permissions/appowners
HTTP Method
PUT
"user_id": "qF5YuBNIjEOLGiodsKMD8w==\r\n",
"allowed_destination_ips": ["1.1.1.1"],
"comment": "comment"
406 1022 Invalid IP address - <invalid ip address>
Invalid input – either use a wildcard ‘*’ or a list of IP addresses, but not
406 1023
both
406 1024 Cannot find user_id - <user_id>
406 1025 user_id cannot be empty

Update Restricted Data (v1.2)
URL
https://host:port/counterbreach/api/1.2/users/settings
HTTP Method
PUT
‘IncidentResponders’
‘ApplicationOwners‘
role ‘SecurityEngineers‘ String Mandatory
'Admin'
‘Api’
You can configure a custom list of the

permitted event types or a class that defines
the permitted event types of the role.
Custom list event types:

Mandatory
• Cannot be empty
DB_SUSPICIOUS_APPLICATION_TABLE_ACCESS
• DB_MACHINE_TAKEOVER Cannot includes event types
permitted_event_types
• List of strings related to File (event types
DB_EXCESSIVE_FAILED_LOGINS_APPLICATION_SERVER related to File are by default
• DB_EXCESSIVE_FAILED_LOGINS permitted to every role)
• EXCESSIVE_DB_RECORD_ACCESS Cannot be used for ‘Admin’
• SUSPICIOUS_DYNAMIC_SQL_ACTIVITY and ‘Api’ roles
• EXCESSIVE_MULTIPLE_DB_ACCESS
• SENSITIVE_SYSTEM_TABLE_SCAN
Class:

• BREACH_DETECTION
• RISK_REDUCTION
The name of the group in the Active

group_name_in_ad String
directory that represent the role
[] means no configuration at
all
A list of the permitted configuration
configuration String
Cannot be used for ‘Admin’,
Allow_List
‘Api’ and
‘SecurityEngineers‘ roles
Example for ‘IncidentResponders’ or ‘ApplicationOwners‘:
"role": "IncidentResponders",
"permitted_event_types": ["DB_ACCOUNT_ABUSE"," SENSITIVE_SYSTEM_TABLE_SCAN"],
"group_name_in_ad": "DRA_IncidentResponders",
"configuration": ["Allow_List"]
Example for ‘SecurityEngineers‘:
{ "role": "SecurityEngineers",
"permitted_event_types": ["BREACH_DETECTION"]
"group_name_in_ad": "DRA_SecurityEngineers"
Example for ‘Admin‘ or 'Api':
{ "role": "Admin",
"group_name_in_ad": "DRA_Admin"

Note: As a member of the Api group, if you change the Api group name in the Active directory, the
change is immediate and can affect the continuation of your work as an Api user.
406 1031 Invalid role - <role>
406 1032 Invalid configuration - <configuration>
406 1033 Invalid event type - <event type>
Request body parameter ‘configuration’ for the Security Engineers role

406 1034
is not applicable. Please remove this parameter from the request body
The permitted event types are: BREACH_DETECTION,RISK_REDUCTION

406 1035
(or both), or custom list of security event types
406 1036 The permitted event types cannot be empty
Request body parameters ‘permitted_event_types’ and ‘configuration’

406 1037 for the Admin and Api roles are not applicable. Please remove these
parameters from the request body
406 1038 group_name_in_ad cannot be empty
406 1039 group_name_in_ad is already used by another role


Allow List Rules
This section lists the APIs which can be used to retrieve Allow List rule settings:
• Get Allow List Rule List (v1.2)

• Get Allow List Rule List (v2.0)
• Get Specific Allow List Rule (v1.2)
• Get Specific Allow List Rule (v2.0)
• Get Relevant Fields Per Group of incidentType (v1.2)
• Get Relevant Fields Per Group of incidentType (v2.0)
• Add/Update/Delete Allow List Rule (v1.2)
• Add/Update/Delete Allow List Rule (v2.0)

Get Allow List Rule List (v1.2)
URL
https://host:port/counterbreach/api/1.2/ignore_rules
HTTP Method
GET

Get Specific Allow List Rule (v1.2)
URL
https://host:port/counterbreach/api/1.2/ignore_rules/<ignoreRuleName>
HTTP Method
GET
406 10011 Ignore rule <rule name> was not found

Get Relevant Fields Per Group of incidentType (v1.2)
Description
Returns a Json with the relevant fields that are common to all the given incidentTypes.
URL
https://host:port/counterbreach/api/1.2/ignore_rules/fields?type=<incidentType>
For example:
https://<admin_ip>:8080/counterbreach/api/1.2/ignore_rules/fields?
type=ACCOUNT_MISUSE&type=EXCESSIVE_DB_RECORD_ACCESS&type=TABLE_ACCESS
or
http://<admin_ip>:8080/counterbreach/api/1.2/ignore_rules/fields?type=Any
HTTP Method
GET
incidentTypes

Note: For any incidentTypes, use the value outside the brackets. The value inside the brackets is
for explanation only. In future versions, only the value inside the brackets will be used.

"rule_name": "",
"rule_comment": "",
"expiration_date": "",
"close_incidents": true,
"closing_reason": "Resolved",
"comment": "",
"append_comment": true,
"incident_type": [
""
],
"src_user": [
""
],
"src_ip": [
""
],
"src_hostname": [
""
],
"src_app": [
""
],
"db_user": [
""
],
"dest_ip": [

""
],
"dest_hostname": [
""
],
"db_name": [
""
],
"cluster_names": [
""

Add/Update/Delete Allow List Rule (v1.2)
URL (Add)
https://host:port/counterbreach/api/1.2/ignore_rules
HTTP Method (Add)
POST
URL (Update/Delete)
https://host:port/counterbreach/api/1.2/ignore_rules/<Rule_id>
HTTP Method (Update)
PUT
HTTP Method (Delete)
DELETE
Relevant for update and

id As PathParams Long
delete
ruleName Allow List rule name String Mandatory
Options:
ruleComment String
• With value: “<comment>”
• Without value: ""
See incidentTypes table below.

incidentType
Note: For any incidentType, use the value List of strings
outside the brackets. The value inside the
brackets is for explanation only. In future

versions, only the value inside the brackets

will be used.
• If you want to enter a

Options: value, the format is
yyyy-mm-
expirationDate • With value in a specific format yyyy- String ddT00:00:00.000Z
mm-ddT00:00:00.000Z • If you do not want to
• Without value: "" enter a value, just leave
it ""
Options:
dbName • With value[“<value>”] List of strings

• Without value: null or [“”]
• IS_EMPTY
Options:
tableName • With value[“<value>”] List of strings

• IS_EMPTY
Options:
destHostname • With value[“<value>”] List of strings

• IS_EMPTY
Options:
destIp • With value[“<value>”] List of strings

• IS_EMPTY
Options:
dbUser
List of strings
• With value[“<value>”]

• IS_EMPTY
Options:
srcApp • With value[“<value>”] List of strings

• IS_EMPTY
Options:
srcHostname • With value[“<value>”] List of strings

• IS_EMPTY
Options:
srcIp • With value[“<value>”] List of strings

• IS_EMPTY
Options:
srcUser • With value[“<value>”] List of strings

• IS_EMPTY
Options:
• With value
suspiciousCommand List of strings
• Assembly
• xpcmdshell
• Without value: null
Options:
fileExtension
List of strings

• IS_EMPTY
Options:
Folder • With value[“<value>”] List of strings

• IS_EMPTY
closeIncidents true/false Boolean
Options:
• null
• Authorized
closingReason List of strings
• Resolved
• Whitelisted
• Misclassified
• Permitted
Options:
comment String
• With value: “<comment>”
• Without value: ""
overrideComment true/false Boolean
Note: All the fields which are List of strings ([])
• ["IS_EMPTY"] - use this in case you want one of the field must be empty
incidentTypes


Request Body Example (Add/Update)
"rule_name": "wl2",
"expiration_date": "",
"rule_comment": "",
"incident_type": ["ACCOUNT_MISUSE"],
"src_user":[""],
"src_ip": null,
"srcHostname": ["IS_EMPTY"],
"src_app": null,
"db_user": null,
"dest_ip": ["10.10.10.31"],
"db_name": null,
"dest_hostname": null,
"close_incidents": true,
"closing_reason": "Resolved",
"comment": "",
"append_comment": false
Response Body Example (Success)

"ruleId": 452,
"closed_incidents": 5
The provided incident type(s) for the following field(s) is/are invalid:
406 1013
<FIELD>
406 1014 <Field> cannot contain only asterisk sign
406 1015 Invalid source/destination IP address or CIDR notation - <Invalid ip>
Invalid incident type - MACHINE_SHARINGGG -
Optional valid values are : Any or one from the following list
[ACCOUNT_MISUSE, TABLE_ACCESS, MACHINE_SHARING,
FAILED_LOGIN_NON_HUMAN, FAILED_LOGIN_HUMAN,
WORKING_OUT_OF_HOURS,
406 1016 FAM_BULKS_READ_NOT_PERSONAL_NUM_OF_FILES,
FAM_BULKS_READ_PERSONAL_NOT_CATEGORIZED_NUM_OF_FILES,
FAM_BULKS_READ_PERSONAL_NOT_CATEGORIZED_RATE,
FAM_BULKS_READ_NOT_PERSONAL_RATE, FAM_DPGA,
EXCESSIVE_DB_RECORD_ACCESS, DYNAMIC_SQL,
SUSPICIOUS_COMMAND, SKYFENCE, MULTIPLE_DB_ACCESS,
SENSITIVE_SYSTEM_TABLE_SCAN]
The incident type combination list is invalid.

406 1012
The list should only contain incident types of the same asset type (DAM/
FAM) or just a single Any
406 1017 Only one suspicious command type should be provided

406 1018 Invalid suspicious command
406 1020 <Field> cannot be more than 500 characters
406 1021 Rule expiration date is set in the past
Failed to save rule '%s'. Incidents’ Allow List rule with the same
406 10001
attributes already exists
Failed to update rule. Incidents’ Allow List rule with the same attributes
406 10002
already exists
Failed to save rule '%s'. Incidents’ Allow List rule with the same name
406 10003
already exists
406 10005 Failed to save rule '%s'. Please fill at least one property
406 10006 Failed to update rule. Please fill at least one property
406 10007 Failed to save rule. Please fill rule name
406 10010 Ignore rule '%s' was not found" (name /id update/delete)
Failed to update rule. Incidents’ Allow List rule with the same name
406 10012
already exists
406 10013 Failed to update rule. Please fill rule name
406 10014 Failed to save rule. Rule name exceeds 200 characters length

406 10015 Failed to update rule. Rule name exceeds 200 characters length
Ignore rule cannot contain the clusterNames field. The clusterNames

406 10019 field is used only when the system monitors the IBM Db2 for z/OS
database

v3.2 Data Risk Analytics User Guide 3-21-2023

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

v3.2 Data Risk Analytics User Guide 3-21-2023

Uploaded by

Copyright:

Available Formats

v3.

2 Data Risk Analytics User Guide

v3.2 Data Risk Analytics User Guide

v3.2 Data Risk Analytics User Guide 1

v3.2 Data Risk Analytics User Guide

Managing Licenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

v3.2 Data Risk Analytics User Guide

Audit data from file [file-name] failed to load. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

v3.2 Data Risk Analytics User Guide

Get Anomaly Database Names (v1.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

v3.2 Data Risk Analytics User Guide

© 2002 - 2021 Imperva, Inc. All Rights Reserved.

Imperva and SecureSphere are trademarks of Imperva, Inc.

v3.2 Data Risk Analytics User Guide 6

End User License and Services Agreement

v3.2 Data Risk Analytics User Guide 7

• Introducing Data Risk Analytics

v3.2 Data Risk Analytics User Guide 8

Introducing Data Risk Analytics

v3.2 Data Risk Analytics User Guide 9

v3.2 Data Risk Analytics User Guide 10

Document Conventions and Terminology

Typographical and Formatting Conventions

Convention Meaning Example

The monospaced font is used for CLI commands

| separates optional values in lists oranges | apples

indicates a placeholder which must be replaced

The following terms where changed:

Whitelist Allow List Rules

Whitelisted Part of an existing allow rule

v3.2 Data Risk Analytics User Guide 11

Configuring Data Risk Analytics

This chapter includes:

• Overview of Data Risk Analytics

v3.2 Data Risk Analytics User Guide 12

Overview of Data Risk Analytics

v3.2 Data Risk Analytics User Guide 13

Setting Up Data Risk Analytics

Task Overview Description For more information, see

Instructions on how to install and

Configuring the Imperva On-

v3.2 Data Risk Analytics User Guide 14

v3.2 Data Risk Analytics User Guide 15

v3.2 Data Risk Analytics User Guide 16

General details shown for each incident may include:

ID The incident ID number.

Event Time The time and date the event occurred.

The destination server type can be:

• - Databases (including IBM DB2 for z/OS standalone subsystem)

v3.2 Data Risk Analytics User Guide 17

v3.2 Data Risk Analytics User Guide 18

v3.2 Data Risk Analytics User Guide 19

Comprehensive details include:

Comprehensive Incident Details

v3.2 Data Risk Analytics User Guide 20

v3.2 Data Risk Analytics User Guide 21

v3.2 Data Risk Analytics User Guide 22

v3.2 Data Risk Analytics User Guide 23

v3.2 Data Risk Analytics User Guide 24

v3.2 Data Risk Analytics User Guide 25

v3.2 Data Risk Analytics User Guide 26

v3.2 Data Risk Analytics User Guide 27

Allow List Rules

To create an Allow List rule: