Centralised logging

What is centralised logging?

Centralised logging is the practice of keeping all log data in a central location to provide better visibility and monitoring of your IT environment. If done correctly, centralised logging will also provide better analysis and troubleshooting of events during an incident. 

Logs are a key part of understanding how an incident occurred and when it started. With that information, you can resolve incidents quicker and get back to business as usual. Without logs enabled it can be harder to detect when an incident happens or establish the full scope of the incident.

Enabling logs on everything will generate a lot of data and can become overwhelming. Trying to process this all by hand makes it hard to tell when there’s a problem. Configure alerts to notify you when key actions happen. This helps manage the noise, and the detailed logs are still available when you need to investigate them.

How to configure centralised logging

Enabling logs means you can monitor them to detect an incident and understand what happened during an incident.

Keeping them in a central place allows you to have a complete view of the events in your environment, while also managing access effectively.

Below are some steps you can follow to make the most of your resources when configuring logging.

1. List the events that should be logged

Record a list of events that are critical to the organisation. These might include events relating to the following:

• Business critical systems. You need to know when there’s suspicious traffic on your web application, or when security configurations that rarely change are modified.
• Likely attacks. You need to know when there are unauthorised or inappropriate connections to your internet-facing servers.
• Known vulnerabilities in your environment. For example, your organisation might need SMBv1 enabled for one legacy system. You'll want to know when that protocol is used inappropriately. Logging the usage of legacy and unsecure protocols within your environment should be considered.
• Failed authentication. You need to know when there are unsuccessful authentication attempts, particularly for administrative accounts.
• Physical access around your premises, such as swipe card access logs.

This list of events will be your goal for enabling logging. To capture these events, you will need to understand:

• what parts of your environment you need to collect these events from, and
• if you’re able to log them.

2. Understand and configure what logs are required

Consider each event you want to record and make a list of all the components that contribute to that event. You need to check each of those components to make sure that:

• you can configure these logs,
• they cover the information you would need to identify the event, and
• they’re in a format that you can consume.

For example, if you want to record events relating to unsuccessful multi-factor authentication (MFA) attempts, you’d need to configure logs for your:

• access gateways,
• authentication servers, and
• any cloud-based applications that use MFA. 

If any of those components can’t configure logs, discuss the impact of this with the business.

Assess the content, format, and size of the logs that each component would produce. You’ll also need to consider how long to keep these logs for. This may depend on different legal and regulation requirements.

This is important to ensure:

• you’re collecting information that is valuable and actionable, and
• the centralised logging database is sized correctly.

3. Configure a central logging system

Harden and configure a central logging system that will receive logs from each component. Configure it to preserve logs securely.

• Limit access. Follow the principle of least privilege so only the people who need access to the logs have access. All users should have read only access. If you need to allow a user to modify the data, make sure you log those actions. This is so you know who modified the data and when it happened.
• Disable unused services and ports.
• Disable default accounts that can be used to access the server or database.
• Set up logs to record access to the logging system.
• Consider how each component should respond if the logging system is unavailable. For example, should the system shut down or should it spool log events locally, and retry later? You may need redundant systems in place to avoid outages.
• Make sure that logs are protected in transit between the source and the destination.
• Configure backups for your log system.
• Make sure the logs have timestamps that can be matched easily. If you have servers in multiple time zones, you may need to:
  
  • set them all to the same time zone, or
  • have your logging system automatically convert timestamps to a single standard.

Having these configurations in place is important to preserve the logs’ integrity. You need to make sure the information in them is a valid re-telling of the event, so you need to make sure they’re protected against modification and deletion.

4. Maintain logs

Monitor your log configurations and centralised logging system. You should set up alerts to notify you when anything changes (as they likely don’t change often).

Decide how long you want or need to keep your logs for. This could be decided by legal or regulation requirements. Research from several organisations globally shows most incidents aren’t detected for a couple of months. You’ll want to keep your logs long enough to be useful in an investigation into an event or incident.

Configure alerts for high priority events such as failed authentication attempts on administrative systems. These can help you respond to incidents as soon as they occur. This could mitigate the impact of a potential breach.

Consider creating dashboards to show the current state of your systems. These will help identify less obvious events, or events where there is no single log entry to alert you. For example, a dashboard showing:

• an unusual spike in network traffic could indicate an incident taking place,
• URLs blocked by your web proxy could help identify a new phishing campaign affecting your staff.

How to measure success

Successful implementation of this control will look different for different organisations. Your organisation should:

• enable logging for events that are business critical or involve sensitive data,
• sync all systems to the same time source, with a consistent time zone to make analysis and correlation easier,
• send logs to a central system for storage and analysis,
• limit access to those who need it. Those users have read only access – there shouldn’t be a way to modify or delete data,
• record any modifications to the configuration of the logging system, and
• set up automated alerts and reporting for known suspicious or unusual log events. 

Key takeaways

• Consider which logs would be the most helpful to piece together or detect an incident. Logs can require a lot of resources, so make sure you are prioritising the logs that are important.
• Consider checking with your legal team or industry standards, when deciding which events you want to log. There might be specific logs you have to collect to comply with laws and regulations for your industry.
• Consider what sensitive data might end up in your logs (like usernames and passwords). Think about how you’ll mask that information, or how you might protect the logs from unauthorised access.
• Make sure you protect your log files from modification or deletion. You need confidence that your logs are accurate and haven't been tampered with for them to be useful.
• Many businesses don’t discover an incident until months after it happened. Keep that in mind when deciding how long you’ll keep your logs for. Having them available will allow you to carry out an effective investigation.