Chat now with support
Chat with Support

Change Auditor Threat Detection 7.0.1 - Deployment Guide

Creating a Threat Detection configuration

A Threat Detection configuration must be created before you can view activity, receive alerts, and analyze anomalies on the dashboard.

The status of the Threat Detection configuration is displayed on the configuration page. The configuration is either:

•
Configured - All Change Auditor settings are properly applied.
•
Not Configured - Change Auditor does not have an existing Threat Detection configuration. If you see this status after removing a configuration and want to configure Threat Detection again, see Removing a configuration for details.
•
A valid Change Auditor Threat Detection license is required - Information is provided on how to obtain a license.
To create a Threat Detection configuration
* 
NOTE: Selecting the Refresh button, will provide an accurate state of the configuration - that is to say, whether it is currently configured, unconfigured, or a license update is required.
1
From Change Auditor select Administration Tasks | Configuration | Threat Detection.
2
Enter the Threat Detection server fully qualified domain name and integration password you created when deploying the Threat Detection server.
3
Select how many days of historical events should be sent to Threat Detection server. For information on how to determine the best amount for you, see Historical events and your baseline calculations.
4
Select Apply Changes.

Reviewing configuration status

To see Threat Detection configuration status
1
Select Administration Tasks | Configuration | Threat Detection.
2
Click Refresh to update the Threat Detection configuration from Change Auditor.
The following deployment details are displayed:
•
State of the configuration
•
How many historical events have been sent to Threat Detection server.
•
Status of the Threat Detection server.
•
Status of the data processing. For example, building baseline.
•
Threat Detection server version.
•
Threat Detection subscription ID.
•
Starting point in time for events to send.
•
Subsystems that contain the event data that is being sent.
•
Whether the Threat Detection subscription is enabled.
•
How often how often (in milliseconds) events are sent.
•
Interval (in milliseconds) that a heartbeat check is made for the configuration.
•
Batch size. (The maximum number of events to include in a single notification message.)
•
Url for notifications.
•
Url for heartbeat notifications.
•
When the last event was sent.
•
Last event response (For example OK, HTTP 429 - Too many events being sent, and HTTP 401 - Unauthorized access.)
•
When the last heartbeat was sent.
•
When the last heartbeat response. (For example OK, HTTP 429 - Too many events being sent, and HTTP 401 - Unauthorized access.)
•
Number of events sent.
•
Number of batches sent.
•
Number of heartbeats sent.
•
Time of the event that was last sent.
•
List of coordinators permitted to send events.
•
The coordinator that is sending events. If the subscription is disabled, this is the last coordinator sending the events.

Removing a configuration

In the current version of Change Auditor, deleting the configuration only removes configuration information from Change Auditor. It does not remove data or configuration on the Threat Detection server.

If you are removing the configuration as a part of a clean up process, you can delete the Threat Detection server after removing configuration.

If you are removing the configuration and plan to start over with the same Threat Detection server, you can either revert to a snapshot of the server taken right after it was deployed or replace the existing Threat Detection server with a new server.

To remove a Threat Detection configuration
1
Select Administration Tasks | Configuration | Threat Detection.
2
Click Remove Configuration.
This removes the Threat Detection configuration from Change Auditor.

Historical events and your baseline calculations

Before the Threat Detection server can generate alerts, it needs to establish user behavior baseline. The baseline is built by processing 30 days of historical or real time events. Refer to the Change Auditor Threat Detection User Guide for information about baseline modeling.

When you create the Threat Detection configuration, you can specify how many days of historical events should be sent to the Threat Detection server to create the baseline.

* 
NOTE: The baseline is more accurate if it is built using the exact configuration of events that you plan to analyze on an ongoing basis. If a new event is enabled after the initial baseline has been built (for instance, the User authenticated through Kerberos event) it may initially be treated as an anomaly as there is no history of it in the baseline.
Table 2. How to determine which type of events to use for a baseline
Type of events to use
When to use...

Real-time events (0 days)

NOTE: It will take at least 30 days before you start seeing alerts in the Threat Detection dashboard.
•
For a new installation of Change Auditor where no events have been collected.
•
If you just enabled events that need to be analyzed by Change Auditor Threat Detection.

Historical events (more than 0 days)
•
If you have been collecting all events supported by Change Auditor Threat Detection.
•
If you are not purging any of the events supported by Change Auditor Threat Detection.

Use the following as guidance on the number of days to specify when you create your Threat Detection configuration:

•
You should not specify more days than the number of days of events that exist in the Change Auditor database.
•
You can enter between 1 and 90 days.
•
If you specify less than 30 days, Threat Detection uses real time events to continue to build a baseline until 30 days of event have been analyzed.
•
If you specify more than 30 days, the Threat Detection server starts generating alerts for any abnormal activity that happened after 30 days.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating