SIEM Integration
It is possible to integrate your dope.swg with whichever SIEM tool your organization is using.
Simply provide dope.security with the location of your organizations AWS S3 Bucket where we can send all of web transactions from each dope.endpoint.
Each dope.endpoint sends all web transactions for that endpoint to the dope.cloud every 15 mins. Once SIEM Integration is enabled the dope.cloud will ensure all of this log data is sent to your organizations AWS S3 bucket as it is received from the dope.endpoint.
The data is sent to the AWS S3 Bucket in a compressed GZIP format. This data can then be ingested into whichever SIEM product your organization is using.
Configuring the integration
Provide S3 Bucket Name
The first step to configure SIEM integration is to navigate to the Settings -> SIEM page. From here you must provide the name of the AWS S3 Bucket where you want to the dope.cloud to send the log data to.
Your AWS S3 Bucket must be in the AWS region noted on the right-hand side of the SIEM integration page on the right-hand side (above).
e.g. US-EAST-2 should have a US-EAST-2 S3 Bucket location
Configuring the AWS S3 Bucket Policy
The AWS S3 bucket that you want to log data to be sent to must be configured to give the dope.cloud write access.
Within the SIEM integration page on the right hand panel dope.security have provided the policy that the AWS S3 Bucket needs to be configured with. You need to copy and paste this policy and use it to configure the organizations AWS S3 Bucket.
Synchronise
When everything has been configured correctly a successful synchronization will be clearly indicated on the SIEM page.
A green tick will appear next to the AWS S3 Bucket name and the last synchronization time will appear on the top right of the page.
Synchronization Errors
Where the synchronization fails it will be because of one of the following errors:
AWS S3 bucket not found
AWS S3 Bucket needs to be in Data Residency Region
AWS S3 access policy is not set
AWS S3 access policy is incorrect.
The synchronization failure will be clearly indicated on the SIEM page.
Connection Lost
It is possible that connection to the AWS S3 Bucket could get lost. This will result in log data not getting sent to the organizations AWS S3 Bucket. The reasons for a lost connection be because of one of the following errors:
AWS S3 bucket not found
AWS S3 Bucket needs to be in Data Residency Region
AWS S3 access policy is not set
AWS S3 access policy is incorrect.
If this happens then notifications will appear in two locations.
The SIEM Integration page will clearly indicate that the connection is lost and will indicate the possible reasons.
The Audit Log will have an event posted that shows the number of files that have not been sent to the organizations AWS S3 Bucket.
Screenshot needed
When connection to the AWS S3 Bucket is restored then the SIEM page will again indicate that the synchronization was successful. There will also be a connection returned event added to the Audit Log.
Log Data Format
Here is the format of the web transaction data sent from the dope.cloud to the AWS S3 Bucket.
| Parameter | Description |
|---|---|
Timestamp (ISO 8601 time format) | The timestamp of when the web transaction was requested |
Duration | The duration that the connection was open for, this is in milliseconds |
Matched Destination | The domain that the dope category was matched against |
Destination IP | The destination IP address for the requested URL |
Tenant ID | The customers dope.cloud unique tenant ID |
Agent ID | The unique agent ID for the dope.endpoint where the data is being sent from |
User | The logged in user on the dope.endpoint |
OIDC User | The email address for the authenicated user on the dope.endpoint. Only shown when OIDC authentication is enabled |
Categories | The matched dope category numbers for the requested URL |
Verdict | The policy verdict for the requested URL. This can be Allow (0), Block (1), Warning (2) or Bypass (3) where the URL is part of a policies bypass list. |
Data Sent | The amount of data sent in the connection |
Data Received | The amount of data received in the connection |
Policy Type | The type of policy that was applied to the URL.This can be either Web, Cloud Application Control (CAC), Custom Category or Malware. |
Block Detail | Populated for a block verdict. It will be either a dope category, a custom category, Cloud Application or a malware type. |
Filename | The name any file downloaded. |
File Hash | The file hash for the downloaded file |
Process Name | The name of the process making the URL request. |
URL | The complete requested URL |
Policy Name | The name of the policy applied |
Protocol | Protocol used, e.g.: HTTP/2, HTTP/1.1 |
Hostname | Device hostname |
Last updated
