Logging for FISMA part 2 : Detailed FISMA logging guidance in NIST 800-92 and SANS CSC20
By Dr. Anton Chuvakin
The Federal Information Security Management Act of 2002 (FISMA) “requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.”
While some criticize FISMA for being ‘all documentation and no action’, the law emphasizes the need for each “Federal agency to develop, document, and implement an organization-wide program to secure the information systems that support its operations and assets.” At the very least, the intention of the law is noble indeed.
As we mentioned in the previous newsletter, the law itself does not prescribe any logging, log management or security monitoring since it stays on a high level of policy, planning and risk to federal systems. In accordance with the law, detailed guidance has been developed by NIST to cover the specifics of FISMA compliance. The main source for detailed guidance is NIST Special Publication 800-53 “Recommended Security Controls for Federal Information Systems” , now in revision 3 , that we covered in the previous issue. Among other things, the document describes log management controls including the generation, review, protection, and retention of audit records, and steps to take in the event of audit failure. On top of this, NIST has created a dedicated “Guide to Computer Security Log Management” . The guide states “Implementing the following recommendations should assist in facilitating more efficient and effective log management for Federal departments and agencies.”
In this newsletter we will offer practical tips on using the NIST 800-92 for building log management program for FISMA compliance and beyond. In addition, we would cover other sources for federal information security guidance related to logs, in particular “Twenty Critical Security Controls for Effective Cyber Defense: Consensus Audit Guidelines” by SANS (http://www.sans.org/critical-security-controls/) . One of the top controls, “Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs”, is about logging and log management. It maps to NIST 800-53 AU and other controls - in particular “AC-17 (1), AC-19, AU-2 (4), AU-3 (1,2), AU-4, AU-5, AU-6 (a, 1, 5), AU-8, AU-9 (1, 2), AU-12 (2), SI-4 (8)” that we also covered previously. Unlike end to end coverage of logging in NIST 800-92 which can be overwhelming for casual reader, SANS document contains “quick wins” that agencies can follow immediately to ramp up their FISMA efforts.
How can you use 800-92 document in your organization? First, let’s become familiar with what is inside the 80 page document. The guide starts with an introduction to computer security log management and follows with three main sections:
- Log Management Infrastructure
- Log Management Planning
- Log Management Operational Processes
Indeed, this is the right way to think about any log management project since organizations usually have challenges with planning, logging architecture building and then with ongoing operation – that has to be maintained for as long as the organization exists.
The guide defines log management as “the process for generating, transmitting, storing, analyzing, and disposing of computer security log data.” By the way, keep in mind that security log management must cover both ‘Logs from Security Applications’ (e.g. IPS alerts) and “Security Logs from Applications” (e.g. user authentication decisions from a business application). Focusing on just one is a mistake.
In the area of log management infrastructure, the guide defines three tiers of log management architecture
- Log Generation
- Log Analysis and Storage
- Log Monitoring
Following this order is simply log common sense; but many organizations, unfortunately, sometimes start from purchasing an expensive tool without thinking about their logging policy and they use for logs. Thinking of the needs (what you want to get from logs?) and logs (what logs can help me get there?) before thinking about boxes and software will save your organization many headaches.
Log management project planning starts from focusing on a key item – organization roles. Log management is inherently “horizontal” and touches many areas of an organization. NIST suggests that system and network administrators, security administrators, incident respondents, CSOs, auditors and – yes!- even internal application developers be invited to the party. This will help the organization choose and implement the right answer to their log management question.
Next – the real work start: creation of a logging policy. It is a common theme that security starts from a policy; this strongly applies to logging. According to the guide, such policies need to cover:
- Log generation: what events are logged, with what level of detail
- Log transmission: how logs are collected and centralized across the entire environment
- Log storage and disposal: how and where the logs are retained and then disposed of
- Log analysis: how are the logged events interpreted and what actions are taken as a result
What does this mean in practical terms? It means that configuring tools needs to happen only after the policy that covers what will be done is created. Goals first, infrastructure choices second! In case of privacy and other regulations on top of FISMA, the legal department should also have their say, however unpalatable it may be to the security team.
After defining policy and building the systems to implement the policy, as well as configuring the log sources, the hard work of building lasting ongoing program beings. The core of such a program is about performing periodic analysis of log data and taking appropriate responses to identified exceptions. Obviously, no external guide can define what is most important to your organization – but hopefully using this newsletter, NIST, and other guidance, you already have some idea about what logs you would care the most about.
On a less frequent basis, the agency will perform tasks related to long-term management of log data. It is a surprisingly hard problem, if your log data volume goes into terabytes of data or more. NIST 800-92 suggests first choosing “a log format for the data to be archived” – original, parsed, etc. It also contains guidance on storing log data securely and with integrity verification, just like in PCI DSS.
So, how does NIST 800-92 helps you with your FISMA effort?
First, it gives a solid foundation to build a log management program – a lot of other mandates focus on tools, but this contains hugely useful program management tips, all the way down to how to avoid log analyst burnout from looking at too many logs.
Second, you can use the guide to learn about commonly overlooked aspects of log management: log protection, storage management, etc. For example, it contains a few useful tips on how to prioritize log records for review.
Third, it provides you with a way to justify your decisions in the area of log management – even if you don’t work for a government agency.
At the same time, the guide is mostly about process, and less about bits and bytes. It won’t tell you which tool is the best for you.
In fact, even though NIST 800-92 is not binding guidance outside of federal government, commercial organizations can profit from it as well. For example, one retail organization built its log management program based on 800-92 even though complying with PCI DSS was their primary goal. They used the NIST guide for tool selection, as a source of template policies and even to assure ongoing operational success for their log management project.
Other technical log management guidance for agencies subject to FISMA is published by SANS in the form of their “Twenty Critical Security Controls for Effective Cyber Defense” or CSC20. If you are looking for a quick actionable tips (called “QuickWins“ in the document), that is the resource for you. For example:
- “Validate audit log settings for each hardware device and the software installed on it, ensuring that logs include a date, timestamp, source addresses, destination addresses, and various other useful elements of each packet and/or transaction. Systems should record logs in a standardized format such as syslog entries or those outlined by the Common Event Expression (CEE) initiative.”
- “System administrators and security personnel should devise profiles of common events from given systems, so that they can tune detection to focus on unusual activity… “
- “All remote access to an internal network, whether through VPN, dial-up, or other mechanism, should be logged verbosely.”
It is recommended to use all of NIST800-53, NIST 800-92 and SANS CSC20 to optimize your logging for FISMA compliance project.
To conclude, NIST 800-92 and SANS CSC 20 teach us to do the following, whether for FISMA compliance alone, for multi-regulation programs, or simply improve security and operations.
- Find the critical systems where logging is essential
- Enable logging – and make sure that logs satisfy the “good log” criteria mentioned in the standards
- Involve different teams in logging initiatives – logging cuts horizontally across the agency
- Look at your logs! You’d be happy you started now and not tomorrow
- Automate log management, where possible, and have solid repeatable process in all areas
On top of this, NIST 800-92 bring log management to the attention of people who thought “Logs? Let them rot.” Its process guidance is more widely represented than technical guidance which makes it very useful for IT management and not just for “in the trenches” people, who might already know that there is gold in the logs….
Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books "Security Warrior" and "PCI Compliance" and a contributor to "Know Your Enemy II", "Information Security Management Handbook" and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular in the industry.
In addition, Anton teaches classes and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups.
Currently, Anton is developing his security consulting practice www.securitywarriorconsulting.com, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.
Did you know? In addition to automating compliance with FISMA requirements, EventTracker is the only SCAP-validated SIEM/Log Management solution to automate configuration assessment against the FDCC standard for comprehensive compliance
Previously on EventSource Logging for FISMA Part 1, Logging for HIPAA Part 1 and Part 2, Logging for PCI Part 1 and Part 2.
Did someone forward you this newsletter? Don’t miss out on next month’s article –subscribe today to get your copy.
Prism Microsystems transforms the SIEM experience with EventTracker 7
User-configurable dashboards, risk-prioritized alerting, high-speed indexed search, point and click pattern analysis, and customizable behavior analysis deliver on Prism’s vision of SIEM, simplified. EventTracker 7 is available now.
Counter-measures: Protecting information assets from well-meaning employees
Malicious insiders aside, well-intentioned employees bear responsibility for a large number of breaches today. Whether it’s a phishing scam, a lost USB or mobile device that bears sensitive data, a social engineering attack, or downloading unauthorized software, unsophisticated but otherwise well-meaning insiders have the potential of unknowingly opening company networks to costly attacks.
Did you know? EventTracker helps companies balance employee usability with security – User activity monitoring, administrator account monitoring, USB device monitoring and user behavior correlation allow companies to filter out potential security issues in real-time while still allowing employees to perform their work with minimal intrusion.
Major US organizations hit by “Here you have” email worm
The messages contained a link that appeared to lead to a PDF file but actually directed users to a malicious .SCR executable. If a user clicked on the link, they were prompted to install the worm, which attempted to disable most anti-virus packages and other security software.
Did you know? As in the example above, employees can unwittingly introduce malware and other threats into an enterprise. In these cases, reactive anti-virus solutions are ineffective as by the time they update their signatures, the damage has already been caused. Read how you can detect malware such as the “Here you have” worm by monitoring for changes in the file system.
Log Management best-practices: Five tips for success
The right log management tool can go a long way toward reducing the burden of managing enterprise system log data. However, the right tool can quickly become the wrong tool unless an organization invests the time and effort required to make the most of it. Diana Kelley offers six log management best practices to ensure a successful implementation.
Did you know? EventTracker is the most comprehensive and intuitive Log Management solution in the market today. Instead of transferring the burden to the end-user to figure out what conditions to look for, EventTracker does all the digging for you with advanced analysis capabilities and a vast amount of pre-built knowledge.
Expanding Compliance to Critical Infrastructure
Date: September 23, 2010
Time: 4:00pm EST
Presented by: Black Hat® Digital Self Defense
Speakers: James Arlen, Michael Dahn, A.N. Ananth, CEO Prism Microsystems
This month's Black Hat webcast discusses the topic of expanding compliance into critical areas of infrastructure. For this webcast two security researchers will discuss the pros and cons of what seems to be the steady move of compliance into the SCADA world.
The presentation will consist of a lively debate between the two experts followed by a Q&A discussion with the webcast audience.
This document is provided for informational purposes only. The information contained in this document represents the current view of Prism Microsystems, Inc. on the issues discussed as of the date of publication. Because Prism must respond to changes in market conditions, it should not be interpreted to be a commitment on the part of Prism and Prism cannot guarantee the accuracy of any information presented after the date of publication.
INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED 'AS IS' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND FREEDOM FROM INFRINGEMENT.
The user assumes the entire risk as to the accuracy and the use of this document. This document may be copied and distributed subject to the following conditions: 1) All text must be copied without modification and all pages must be included; 2) All copies must contain Prism's copyright notice and any other notices provided therein; and 3) This document may not be distributed for profit. All trademarks acknowledged. Copyright Prism Microsystems, Inc. 2005.
Prism Microsystems, Inc.
8815 Centre Park Drive
Columbia MD 21045
Back to Newsletters