It’s 10 PM; Do You Know Where Your Logs Are?

Creating and Maintaining an Audit Log Management Process

Written by Brice Dickinson, Forward Edge Cybersecurity Engineer

An attacker has just silently infiltrated your network. Once in the network, they were able to sneak around for several months, gathering data on the best way to carry out their attack. Finally, they find their attack path and create a new user account so they can deploy a targeted malware payload to send to your treasury department and steal as much money as they can. However, this activity has not gone unnoticed. The SIEM begins to alert with some unexpected behavior and once the data has been analyzed, it’s clear there is an attacker on the network and you must act fast before it’s too late. As soon as the activity is noticed you disable the account the attacker created and begin working backward to patch the point of initial compromise. The attacker’s months-long plan has now completely unraveled and would now require months to regain access, so instead, they pack up and find a new and hopefully, easier target. While this is a dramatized look into an active security incident, one thing that was not dramatized is the importance of logs and being able to efficiently and effectively parse through them. In this article, we are going to look at how to create and maintain a robust audit log management process.

Before diving into log management we first need to be clear on what we mean by logs in this article. The NIST Special Publication 800-92 Guide to Computer Security Log Management has a great explanation of what are logs in their executive summary and will be what we use to help us define logs, “A log is a record of the events occurring within an organization’s systems and networks. Logs are composed of log entries; each entry contains information related to a specific event that has occurred within a system or network. Many logs within an organization contain records related to computer security. These computer security logs are generated by many sources, including security software, such as antivirus software, firewalls, and intrusion detection and prevention systems; operating systems on servers, workstations, and networking equipment; and applications.”

Now that we have an understanding of what logs are, the first step toward better audit log management is to create an Audit Log Management Process/Policy. This Policy will cover the collection, review, and retention of audit logs for enterprise assets and will help guide us in establishing a robust log management strategy. The collection of logs process should cover both the devices that the logs are being collected and some baseline events that will be collected as well as any tools that would be used for log collection like a SIEM solution. The review process should cover how the logs will be reviewed and the frequency of those reviews. Also covered in this section is the use of any SIEM or log analytic tools that will be used to analyze and review the collected logs. Finally, the retention process should cover where the logs are stored as well as how long they will be stored.

Knowing what devices we are collecting logs from is important because it directly correlates to how much visibility we have in our environment. More logs mean greater visibility. On the other hand, not collecting enough logs can lead to insufficient data and little to no help when investigating a security incident.. At a minimum, our districts should enable auditing and logging on core infrastructure, which are Domain Controllers, File Servers, Virtualization Hosts, Firewalls, and Switches. Outside of core infrastructure, other key devices for log collection are any additional servers, like print servers or video surveillance servers, and user endpoints.

Next, we need to understand how we collect the logs. There are several ways to do this but the most common and industry standard way is through a SIEM solution. SIEM, which is an acronym for Security Information and Event Management, is a software solution for collecting logs in a single location and then being able to efficiently look through and parse the logs. Additionally SIEM’s can create alerts and notifications from behaviors and events that are seen in the logs. These alerts and notifications are set up through a set of predefined rules that are either generic or customized to the environment. The log collection of the SIEM happens in two ways, either through an agent on a device or an agentless sensor on the network. That agent or sensor then sends the collected logs to the SIEM through either a TCP or UDP connection. The SIEM solution that the Forward Edge Cybersecurity Solution uses is the Perch Security SIEM and chances are if you are reading this article it is already or is about to be deployed on your network. This SIEM uses agents to forward logs and also has the added benefit of being monitored by an additional SOC team for complete 24/7 monitoring.

Now that we know the devices we will be collecting logs from and how we are going to collect them, we need to know what logs we want to connect. To get a good minimum baseline, the following events should be consistently and/or uniformly logged: Changes to programs and system settings, Changes to critical hardware elements, All server system startups and shutdowns, Abnormal system events (e.g. performance deterioration, files filling up, programs ending abnormally), Changes to security parameter settings, Changes to network configuration settings, All successful and unsuccessful login attempts, All logoffs, All access to restricted information, All additions, deletions and modifications to user accounts, user privileges, access rules, and permissions, Attempts to perform unauthorized functions, All password changes, All activities performed by privileged accounts, and All access to sensitive transactions. As well, the following information (regarding system events) should be consistently/uniformly logged: Hostname, User account, Date and time stamp, Description of the activity performed, Event ID or event type, Reason for logging event, Source and destination network addresses, Referring page (in case of HTTP access), and Type of browser used (in case of HTTP access).

These baseline events and information will help us build a picture of what our environment looks like in log form. It is important to remember these are the acceptable minimum requirements but logging additional information is always helpful to better understand and build context around events and behavior. Now that we know what devices we are collecting logs from and what logs we are collecting, we can now look at our log storage and retention process. Logs should be stored in a central location either on or off-premises and be stored for 30 days before being overwritten in a first in first out (FIFO) system. For the Forward Edge Cybersecurity Solution, we use Perch to gather all of these logs in the cloud and then normalize them for easier analysis. They are then stored for at least 30 days in the cloud before being overwritten.

While an Audit Log Management Process may not be the flashiest security policy to implement, it is absolutely essential to have an understanding of what’s happening in your environment with real and actionable data. If your district does not yet have an Audit Log Management Policy in place, there is no better time than now to get one drafted up. As always, if you are a Forward Edge Cybersecurity Solution customer and need help getting started in the policy creation process or need to review your current policy, our team of certified security professionals is available to assist you in that process.