Skip to main content

Make periodic revisions to the logbook

C
Written by Cyberangels
Updated over 2 years ago

A recurring theme in many security incidents is that complete information about the attacks resides in the records of the affected organizations, waiting to be discovered and used. Unfortunately, discovery of such information occurs very late, when the damage has already been done. A timely response can prevent a more serious breach if proper review procedures are followed.

Basic Requirements

To successfully implement a log review process, some basic requirements must be established:

  • A formal logging policy must be established that includes all applicable regulatory and operational requirements (such as log review frequency, retention periods, and so on);

  • Logging options must be enabled on the systems or devices you wish to monitor. Logs cannot be reviewed if no events are recorded;

  • The time and date of all systems to be monitored must be synchronized. If systems reside in different time zones, the time differences must be documented and the log management tools must take them into account;

  • The responsibility for reviewing the logs of a system should not fall solely on the people whose actions are recorded in that system;

  • The logs themselves must be monitored and protected, and all attempts to terminate or alter the logs must be recorded. Such actions could signal a new or ongoing security breach;

Create a baseline.

Since the goal of a log review process is to detect unusual or abnormal events, the first step in achieving this goal is to determine what is "normal." The exact process of creating a baseline may vary depending on the system to be logged and the requirements of the organization, but it usually involves the following:

Determining the time period for the baseline.

The baseline may be based on events already captured, such as the last 30 days of events. On the other hand, you may decide that the baseline will be the next 30 days of recorded events.

Create a report for the baseline events.

Once you have captured events for the selected time period, you can create a baseline report that includes information such as counts for each message type and the average number of events per hour/day/week. The information included in this report should help describe the systems normal operating conditions.

In the process of establishing a baseline, events may occur that require additional investigation or action. These types of events and their responses should be documented because they can be used as a starting point for analysis of new events.

Log review and analysis

The process of reviewing logs should be performed regularly according to requirements, regulatory and otherwise, and fully documented in the logging policy. The review essentially consists of comparing newly produced logs with the documented baseline. How the comparison is done depends on the tools available and the type of systems being logged, among other things. In most cases, one simply tries to determine whether a particular event or sequence of events has been recorded previously in the baseline or in the various reviews.

If the new event can be identified as part of normal operations, it can be added to the baseline. On the other hand, if during this initial investigation the event does not fit the normal profile, it must be reported and a more detailed investigation is required.

Depending on the system and the type of event reported, the investigation may require different approaches. For example, when investigating an event involving a user account, we may need to review the event history for that particular user; in this way, we may be able to establish a possible context for the specific event. You may also want to determine whether other users have generated the same event or whether the event occurred in another system, at that time or at some other time in the past.

During the investigation, you may need to gather information from other sources, such as change management systems, anti-malware, and IDS. Another excellent source of information is from other people in the organization, who could provide information about the true nature of the reported event. Finally, you can ask the application vendor about the event, although in some cases this option may not be feasible.

Create an event analysis log

An event analysis log can help you document everything related to the analysis of events reported during regular log review. This log can provide a knowledge base for future investigations, can be used in conjunction with an incident management process, or can be used as evidence of compliance for certain regulations, such as PCI DSS.

An entry in this log must contain:

  1. The date and time the entry was created;

  2. Name of the person who created the entry;

  3. Complete copy of the analyzed log entry, including the date and time and source information (such as system name, IP address, application name, and so on);

  4. Actions taken during the analysis such as those described above (e.g., searching for other user events in the system);

  5. Conclusions drawn from the analysis, recommended actions or mitigations (if applicable).

Log review is not just for compliance.

Although some regulations mandate a log review process, all types of nonregulated organizations can benefit greatly from establishing a log review process.

Did this answer your question?