Chatee ahora con Soporte
Chat con el soporte

Change Auditor Threat Detection 7.4 - Deployment Guide

Reviewing configuration status

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

To see the Threat Detection configuration status
1
Select Administration Tasks | Configuration | Threat Detection.
2
Click Refresh.
 
Table 5. Available configuration states
State
Description

Configured

The Threat Detection server is properly configured.

Not configured

The Threat Detection server is not configured. See Creating a Threat Detection configuration.

NOTE: If you see this status after removing a configuration and want to configure Threat Detection again, see Removing a configuration for details.

Update is required

An update is required on the Threat Detection server. See Upgrading the Threat Detection server.

License required

A valid Threat Detection license has not been applied.

License expired

The Threat Detection license has expired.

Configured server deployment details

For a configured server, 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 that sent events.

Removing a configuration

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, you can either revert to a snapshot from a previously deployed (but not configured) Threat Detection server or deploy a new Threat Detection server.

 

* 
NOTE: When you join the server to the domain during configuration, Change Auditor creates a computer and service account in the domain required for Integrated Windows Authentication. The computer and service account must be removed manually from the domain when a configuration is removed.
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 6. 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.
Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación