close search bar

Sorry, not available in this language yet

close language selection

Top seven logging and monitoring best practices

Ashutosh Rana

Nov 01, 2021 / 3 min read

The concept of logging and monitoring isn’t new, but organizations still struggle to formulate and implement a security-focused logging and monitoring policy. Security teams need to build logging and monitoring programs that not only collect traditional operational metrics, but are also capable of storing, analyzing, and even mitigating a variety of attacks. This proactive approach of collecting and analyzing information can help developers, sysadmins and security teams in many ways such as detecting issues in their code via “application-level logging,” identifying anomalies in network traffic via “infrastructure logs like AWS/Azure,” and detect as well as prevent security incidents by using advance Security Information and Event Management capabilities. You can address these challenges by employing these logging and monitoring best practices.

1. Define your need to log and monitor

Determining why the organization wants a logging solution will help define what you need to log. The following are some of the reasons an organization might want such as solution:

  • Compliance requirements
  • Local laws and regulations
  • Incident response requirements

Discussing these factors with your organization’s security governance team, legal department, and other stakeholders will help define the goals for logging and monitoring.

2. List what needs to be logged and how it needs to be monitored

Based on your goals, determine what metadata needs to be captured and what events need to be logged. Some examples of metadata and events to be logged and why include:

  • PII/PHI transactions to be HIPAA compliant
  • Financial transactions to be PCI DSS complaint
  • Authentication attempts to a server (successful and failed logins, password changes)
  • Commands executed on a server
  • Queries (especially DML queries) executed on a database

Infrastructure administrators and security teams should collaborate to build an effective logging and monitoring program that collects traditional operational metrics and can analyze them to mitigate attacks. Alerts on certain events, such as multiple failed login attempts or weekly notifications on commands executed on a server, can be set up to monitor these events. It is also important to work with application teams to understand what the different attributes of a log entry mean. Once you have a baseline for normal operations, you can configure correlation rules, aggregations, thresholds, and alerts to be triggered for any anomaly based on the security risk profile for the application. For example, every log entry should have at least the following:

  • An actor (who: username, IP address)
  • An action (what: read/write on which resource)
  • A time (when: timestamp)
  • A location (where: geolocation, browser, code script name)

3. Identify assets and events that need to be monitored

Log data is a huge volume of datasets that impact performance and costs. When determining what data you should monitor start by not leaving anything out. You need to identify which systems/applications should be monitored and what level of monitoring is required. You should also classify your data and systems according to the organization’s statutory, regulatory, or contractual requirements. Keep in mind that this classification may differ from your security system classification or your business data classification.

4. Determine the right solution for logging and monitoring

There are a many solutions—both commercial products and open source projects—to choose from when you want to build a scalable and resilient logging and monitoring program. Choosing the right technologies for a logging and monitoring architecture can be overwhelming. A few key points that you need to keep in mind are:

  • Automate as much of the monitoring process as possible
  • Constantly tune your alerts and log sources as threats evolve
  • Ensure that log and alerts are generated in a standardized format

5. Design logging and monitoring systems with security in mind

A logging and monitoring program by itself is an asset to the organization because it looks into organization wide activities and may contain sensitive information. Here are few points to consider to secure it:

  • Redact/mask/anonymize sensitive information from event logs beforehand, to prevent sensitive information from being logged in plain text (e.g., PHI/PII information)
  • Enforce role-based access controls
  • Perform log integrity checks to ensure that logs are not tampered with
  • Apply encryption at rest and transit
  • Follow the principle of least privilege when configuring log sources
  • Sanitize logs before storing and processing
  • Include capabilities for high availability and redundancy

6. Adopt organization-wide logging and monitoring policies

Work with security teams to enforce companywide policies and procedures that define logging requirements in detail for all systems. This ensures consistency and that protocols and procedures are followed in logging. Policies with a strong mandate and corporate backing ensure that logging and monitoring practices are followed.

7. Establish active monitoring, alerting and incident response plan

Without strong logging mechanisms, an organization is truly in the dark before, during, and after any incident. Attacks on sophisticated systems are often carried out for months or even years. Would your organization be able to detect and block a probe like this? If a motivated adversary can slowly pick apart an application for that length of time and go undetected, there is a high chance that an actual exploit will occur. The following steps are vital to prevent such a scenario:

  • Establish an incident response plan and rehearse it at regular intervals
  • Trigger alerts in an adequate amount of time
  • Take active automated actions on the alerts

Although it is no easy task to build a secure logging and monitoring program, it is an imperative part of any application architecture and it will make all the difference in detecting and blocking a sophisticated attack by a motivated and determined adversary.

Continue Reading

Explore Topics