• No results found

You can manage the amount of log data by defining log pruning filters. Log pruning is needed, for example, when a rule generates both useful and unnecessary logs. Log pruning gives you the ability to discard newly generated irrelevant logs entries on the Log Server. Only logs can be pruned: alerts and audit entries are never pruned.

It is preferable to adjust log generation options instead of letting log entries be generated and then pruning them, as this wastes system resources in creating and transferring the

unnecessary logs.

You can define two types of log pruning filters:

Immediate Discard filters delete log entries immediately as they arrive to the Log Server. The deleted log entries are not displayed in the Management Client.

Discard Before Storing filters deletes log entries before they are saved. Log entries are shown the Current Events mode in the Logs view before they are deleted (in effect, this option converts Essential or Stored type log entries into Transient log entries).

If Domain elements have been configured, log pruning filters can only be defined in the Shared Domain. The same log pruning filters are used in all Domains. Administrators who have the right to manage log pruning can view the log pruning filters when they are logged in to other Domains.

Using Log Management Tools

About the Log Files

Logs are stored as a files on the Log Server. A separate folder is created for the logged events each hour. The log files are stored by default in the <installation directory>/data/

storage/ directory on the Log Server.

The log files have the following naming: YYYYMMDD_hh_C<ORIGINATOR>_MMDDhhmmsssss.arch.

•The date YYYYMMDD_hh refers to the date and hour of the logged events.

•The rest of the file name starting with “_C” refers to the file creation date and the

<ORIGINATOR> refers to the originator of the logged events.

The time and date in the file name always use the UTC time zone, which is the system’s internal time zone.

Archive Directories

Log files are archived by default in the Log Server’s default archive directory <installation directory>data/archive. You can change this directory and define up to 32 alternative or additional directories. For example, you could directly archive some or all of the logs on a network drive to free resources on the Log Server. See the Management Client Online Help and the McAfee SMC Administrator’s Guide for more information.

Caution – Be careful when defining the pruning filters. The matching log events are irreversibly deleted at the Log Server.

Forwarding Log Data to Syslog Servers

Log entries can be forwarded from a Log Server to external syslog servers. If log pruning is applied, any entries that pass “immediate discard” pruning can be sent to the syslog servers.

Entries do not need to be stored on the Log Server to be sent to the syslog server. See the Management Client Online Help and the McAfee SMC Administrator’s Guide for more information.

Forwarding Log Data to External Hosts

Log entries can be forwarded from a Log Server to an external host. You can define which type of log data is forwarded and the format for sending the data. You can use local filters to specify the log data in more detail. If log pruning is applied, any entries that pass “immediate discard”

pruning can be sent to the external host. Entries do not need to be stored on the Log Server to be forwarded to an external host. See the Management Client Online Help and the McAfee SMC Administrator’s Guide for more information.

Forwarding Audit Data to External Hosts

Audit data can be forwarded from a Management Server to an external host. Audit data can be forwarded in CSV or XML format. You can use local filters to specify the audit data in more detail. See the Management Client Online Help and the McAfee SMC Administrator’s Guide for more information.

Examples of Log Management 91

Examples of Log Management

The examples in this section illustrate some common uses for log management and general steps on how each scenario is configured.

Archiving Old Logs

Last month’s logs are taking up too much disk space on the Log Servers at Company A, but some of the logs are still needed for the company’s records. The administrators decide to archive the needed logs on another server and to delete last month’s log data from the Log Servers. Because not all the logs from last month need to be archived, they delete the unnecessary logs altogether. They want to repeat the same archiving operation once a month from now on. To do this the administrators:

1. Create a new Archive Log Task for archiving the data with the following settings:

2. Save the new Archive Log Task.

3. Create a new Scheduled Task for running the Archive Log Task and set it to be repeated monthly.

4. Save the Scheduled Task.

Table 11.2 Archive Log Task for Company A

Option Setting

Time Range Last Full Month

Filter for Copying A custom filter which matches the important log data that the administrators want to archive.

Filter for Deletion Match All to delete all last month’s logs from the Log Server.

Archive Target

Directory A network drive.

Filtering Out Irrelevant Logs

Illustration 11.2 Company B’s Network

Server A provides services to users in network X, as well as to Server B. The administrators are interested in tracking how many of the users in network X actually use Server A. Server B also connects frequently to Server A, and generates a large amount of traffic.

Since Server B makes very frequent connections to Server A and the administrators are only interested in connections from other hosts in network X to Server A, the administrators decide to temporarily eliminate logs that are a result of Server B’s connections. All hosts in network X including Server B are currently logged according to a single rule. Creating a separate rule to handle just the Server B connections with logging set to “None” would create unnecessary clutter in the policy when the administrators only want to filter the logs from Server B temporarily. The administrators decide to set up log pruning to filter the logs so that only the relevant ones are stored on the Log Server. To do this the administrators:

1. Select one of the irrelevant log entries in the Logs view.

2. Create a temporary filter based on the log entry, and save the filter as a permanent filter.

3. Add the new filter to the Discard Before Storing list in the Log Data Pruning view.

Server A Server B

Host

Network X Firewall

93

C H A P T E R 1 2

A LERT E SCALATION

Alert Escalation means defining when and how the SMC notifies the administrators when an alert entry is created.

The following sections are included:

Overview of Alert Escalation (page 94)

Configuration of Alert Escalation (page 94)

Using Alert Escalation (page 98)

Examples of Alert Escalation (page 100)

Overview of Alert Escalation

Alert entries inform the administrators when an event in the system requires their attention, for example, when there is a problem with the system, when a test or task fails, or when a rule of that is configured to trigger an alert matches. Alerts notify you in case something unexpected or suspicious happens. It is important that administrators respond to alerts in order to maintain the health of the system.

Active alerts are stored on the Management Server until the alerts are acknowledged. In an environment with multiple Management Servers, each active alert is stored on each

Management Server. Alert entries are displayed in the Active Alerts view and in the Logs view with other types of log entries.

The Management Server can send out different types of notifications to administrators. Alert escalation stops when one of the administrators acknowledges the alert or when all configured alert notifications have been sent. When an alert entry is acknowledged, it is removed from the Active Alerts view and from the Management Server, and an audit entry is created.

Configuration of Alert Escalation

Illustration 12.1 Alert Escalation

1. An alert entry is triggered by an event on a system component.

2. The alert entry is sent to the Log Server, which stores it.

3. The Log Server forwards the alert entry to the Management Server, where it is handled as an active alert.

4. The Management Server matches the alert entry to the Alert Policy to select the correct Alert Chain.

5. The Alert Chain triggers a series of notifications that are sent to administrators.

•For example, an Alert Chain can first notify one of the administrators by e-mail and wait for acknowledgement for 10 minutes. If the alert is not acknowledged in time, the

Management Server can send another notification as an SMS text message.

1

3

4

2 5

Configuration of Alert Escalation 95

Default Elements

By default, the system includes the following alert-related elements:

•System Situations: System Situations contain definitions for events in the system that trigger a System Alert. There are no configurable parameters for System Situations and you cannot adjust when these Situations are triggered.

•System Alert: This Alert element is used for alerts triggered by critical events in the system’s internal operation (System Situations). System Alerts always require administrator action.

Make sure that your Alert Policies escalate System Alerts.

•Default Alert: This Alert element defines the alert that is triggered if no other alert is

specified. The Default Alert is used in the default Inspection Policy. You can also use it in your own custom configurations.

•Test Alert: This Alert element is used when you test alert handing.

•Default Alert Chain: This Alert Chain escalates all alerts to all administrators through user notification in the Management Client.

•Default Alert Policy: This Alert Policy contains a rule that escalates all alerts using the Default Alert Chain.

Configuration Workflow

The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the McAfee SMC Administrator’s Guide.

Related documents