When an information security incident occurs, you need to be able to gather as much information about it as quickly as possible. There’s also a very real possibility that you will have to involve outside parties - such as an incident response team - to help you as well. That means you can’t approach log management and retention as a simple checkbox. Instead, you need to have rich data that captures audit logs from all critical information systems. Otherwise, if your logs are incomplete, inaccurate or missing altogether, they won’t be of much help when you really need them. Don't waste days scrambling to answer auditor's questions. strongDM provides instant answers with a unified log of every permission change, query, ssh & RDP session. Schedule a demo to see for yourself.
Here are five questions to ask when writing your log management and review security policy:
Are your event logs complete and accurate?
It’s 10 p.m. - do you know what’s connected to your network? If you have had an IT or security audit in the past, you may have heard a saying similar to, “You cannot protect what you do not know is there.” It may sound simple or silly, but it’s true. There’s no way to know if you are gathering logs from all your endpoints and operating systems unless you complete a comprehensive software and hardware inventory. This is why so many of the security assessment frameworks set this as a high priority finding. The CIS Critical Security Controls (CSC), for example, put “Inventory and Control of Hardware Assets” as number one on their list.
What needs to be in your logs?
It’s not enough to simply be collecting logs. You might be filling terabytes of hard drive space with logs from your intrusion detection system and anti-virus solution as you read this post right now, but you could miss critical information if the security logs don’t capture answers to these questions:
- What happened? What were the relevant error messages, event IDs, etc. that speak to the security event?
- What systems are affected? Do logs collect relevant system names and IP addresses?
- When did it happen? Are all critical security systems, such as your intrusion prevention systems, synchronized with a centralized time source? And is the time zone set appropriately on all endpoints as well?
- Who was logged in? Are events tied back to a unique user ID?
Although this core information will give you a fighting chance to accurately triage and respond to issues, it’s the “who” question that is of particular importance in the world of SOC 2. Because you not only need to know who was tied to a specific event in case of an incident, but also have verbose system log files of:
- When a new user is provided with a system account
- When an account has access control granted or suspended, and by whom
- When an account accesses sensitive information, such as data associated with PCI DSS and HIPAA
- When an account shows signs of malicious activity, such as deleting large quantities of files or disabling security monitoring software
- When accounts change roles or permission levels
- When system administrators/engineers make changes to databases or servers
In addition to collecting the critical logging information, you need the ability to store it in a format that makes sense for auditing purposes. Some companies just turn “logging up to 11” and what they essentially end up with is a gigantic pile of logs. But if someone had to actually search and parse through those logs, it would be a living nightmare. Whatever tools you use to ingest logs need to have advanced searching capabilities. You need to be able to search by key fields and indicators, as well as run reports from a specified timeframe, as these are the kinds of operations you will be asked to do during an audit.
If you’re just getting started with logging in a Windows environment, Microsoft offers a free logging and threat hunting dashboard called WEFFLES (Windows Event Logging Forensic Logging Enhancement Services). It isn’t a full-blown SIEM, but it gathers information about user access and application logs into a dashboard you can use for basic audit logging.
Where are you storing audit logs?
As you might imagine, this amount of real-time log data needs to be retained for a period of time to satisfy audit and/or regulatory requirements. As a general rule, storage of audit logs should include 90 days “hot” (meaning you can actively search/report on them with your tools) and 365 days “cold” (meaning log data you have backed up or archived for long-term storage).
Store logs in an encrypted format. See our post on Encryption Policies for more information.
Are you regularly reviewing log entries?
Remember that just collecting the logs is not enough. You need to periodically review logs for unusual behavior, which can come from a combination of automatic and manual efforts. Your logging/alerting/correlation system, for example, can be configured as a first-level triage for alerting on unusual behavior. But don’t rely on tools to be the be-all, end-all of your log review. You should configure log summary reports that are automatically emailed on a periodic basis, and then assign resources to review them monthly. During the manual review, you can make sure the endpoints you are collecting logs from match up with what is in your inventory, and configure any new endpoints to generate logs as needed. You can also figure out if one or more log sources are failing collection for any reason, and/or if log disk space for the next month will be sufficient.
It’s also a good idea to schedule regular simulations of events to make sure the proper logs are generated. For instance, you could create a test account on the network, adjust its rights and permissions, and then log into it with the wrong password enough times to force a lockout. Ensure that logs were generated for each of these key events, and give you enough information to answer the questions above.
Many organizations have no idea what’s going on “under the hood” of their networks, and in the case of a breach or other security incident, they would have little evidence to help them figure out what happened. Turning up logging from your network endpoints is a great first step, but you also need to tune the logs so they provide you with insightful information. Make sure you have carefully planned for storing these logs for both the short and long term. Finally, be sure that you don’t just “set and forget” your tools to shoulder the logging burden for you. Schedule regular manual reviews to make sure all critical endpoints are being logged, and generating the level of detail that you define in your log management and review policy.