Log Management for a Security Pro

Version 1

    With rob.johnson


    Having worked with log management and SIEM (Security Information and Event Management) for several years, I have learned how critical it is to create a log collection plan and determine what you need from your logs.


    Companies that have staffed a specific security department are unique in that they must collect and secure logs from devices, systems, and applications that fall under several different departments. Because of this diversity, a lot of coordination and communication is required to ensure that you have a successful log collection plan created that won’t impact performance in each area.


    So what logs should you collect?


    Regardless of how you plan to manage your log collection, there are a few items to consider about what logs you should collect and what impact the process will have on your network. Below, I present a couple of recommendations that may be helpful. Also, I’m curious about your experiences, and more importantly, what has been the most effective process for you? Feel free to offer your thoughts on this topic.


    1. How will log collection and storage impact your system resources? Whether it’s a free Syslog Server that you spin up on Linux® VM or a full-blown log management solution, you will need to provide resources (i.e. memory, CPU, and storage).
      • Storage is almost always the most expensive resource. Make sure you have a detailed understanding of how your logging solution interacts with storage and whether there is any compression that is either configurable or automated. Virtual appliances or even VM-based Syslog Servers are a little more flexible. However, if you plan to use a standalone physical box, you will need know your storage costs ahead of time. Performance monitoring tools in your hypervisor or on the physical servers are a great way to test the impact of logging. I recommend using one of your busiest systems for testing, such as a domain controller or a firewall. Configure the maximum level of auditing or logging, then monitor disk performance to measure the impact.
      • Memory and CPU will take the next hit. Real-time collection tends to use more sustained memory and CPU. The amounts vary based on volume because log collection and storage occur simultaneously. Scheduled collection or polling may create a spike in usage for a short time; however, you can create a collection schedule for off-peak hours to minimize the impact. Spend some time and figure out how you want to use the logs you collect. Is it just for storage and reporting? Real-time incident response? Knowing how you will use your logs helps you make the right choices when it comes to collection. As described in the previous statement, you can perform tests with some high-volume systems to get a good idea of resource impact.
      • Review your documentation to understand the impact logging will have on your devices, servers, and applications. I have found that, in most cases, it is important to disable or limit any “local” logging on network and security devices. As an example, here is an article from Cisco® on logging best practices for an ASA: http://www.cisco.com/web/about/security/intelligence/firewall-best-practices.html#_Toc332805980. Windows® systems also allow you to limit the amount of events that are stored locally. I advise storing only a small amount of data on the local server and set your event logs to “Overwrite as needed.”
    2. Determine the log storage requirements for either online, or direct access and archived. One of the first steps to managing log data is figuring out how much of this data you want to be easily accessible (online) and how much needs be available in an archive.
      • Read your regulatory documentation to determine if there is a specific time frame or amount of data.
        1. For example, PCI Requirement 10.7 on page 58 of this guide,  (https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf) specifically states that you must maintain 90 days of "immediately-available" data and an audit trail history for at least one year.
        2. HIPAA states (on page 7 of this document: http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/pprequirements.pdf) that covered entities are required to retain data for at least 6 years from the date of creation. However, it does not define the need for available data versus archived data.
      • If compliance is not a primary factor in deciding your storage process, then you will want to figure out what is needed to assist with a security incident response. Check out this thwack® post to get some insight on retention that log management users typically maintain:
    3. Determine if you have any specific requirements for logging. Compliance regulations usually drive this conversation. However, you may also have specific internal requirements for legal or security purposes. Either way, a detailed understanding of any requirement ensures that you collect the right information from the right devices.
    4. Understand what your systems log, and how. As I mentioned in the previous suggestion, the amount of logging generated by different devices, operating systems, and applications can be enormous. So, along with determining the actual requirements for which logs you need to collect, it is important to understand how each system logs information. For example, Windows operating systems offer a detailed audit configuration that allows you to be selective about which logs will be generated (i.e. logons/logoffs, privileged use, system events, and others). Additionally, you can choose whether to use successful or failed events, which allows you to take a more granular approach to log configuration.
      • winauditconfig.png
    5. Schedule and secure archives. Data compression rates have grown significantly over the years, allowing for longer time frames for available data. However, log archiving is still a critical function of log management.
      1. Before scheduling archives, make sure you understand the compression ratio of the archive. This will be especially important as your log store grows compared to the amount of your available archive space.
      2. Become familiar with how your log management system archives data (i.e. by device? the entire database? specific logs?) Understanding the available methods of archiving can save time, and more importantly, storage space.
      3. Secure your archives, even if it’s not a regulatory requirement. You can secure active or available data by requiring some authenticated access. This is also a good practice to prevent any changes to the data. At a minimum, you should encrypt historical archives. Any additional security measures, like signing, are an added benefit.


    Hopefully, the suggestions above provide some insight into preparing your logging environment.  Logs contain a ton of useful information, and when they are collected properly, they can help you improve security and quickly resolve network and systems issues. Creating a logging plan before you set up your log collection process can be the difference between long hours of digging through useless data and quickly finding what you need.


    This post is part of our Best Practices for Log Management Series. For more best practices, check out the index post here: Best Practices for Log Management