Keeping them in a central place allows you to have a complete view of the events in your environment, while also managing access effectively.
TIP: Many centralised logging systems can correlate events across logs from different systems, which can help you piece together an incident.
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:
- 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
- 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. In order 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.
TIP: Ask your vendors to see if there are any events you can log that are tell-tale signs that something is wrong. They can tell you if certain log events indicate possible attacker behaviour.
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 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
- that that centralised logging database is sized correctly.
TIP: Some laws and regulations may require logging for compliance, which usually depends on the type of data you manage. Check with your legal team or industry standards to understand if there are additional requirements that you have to comply with.
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.
TIP: Be careful of logs that capture sensitive content, like access tokens and personal information. Check to see if you need to record that content. If so, make sure you protect the logs from unauthorised access. Logs produce copies of this information – these should be protected in the same way as the original.
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 helpful was this page?
This site is protected by reCAPTCHA and the Google Privacy Policy External Link and Terms of Service External Link apply.