Detailed FISMA Logging Guidance Continued

Monday, April 18, 2011

Anton Chuvakin

Ebb72d4bfba370aecb29bc7519c9dac2

Detailed FISMA Logging Guidance Part One HERE

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 article, 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 a "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 article 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 the 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.

Conclusions

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...

Cross-posted from Prism Microsystems via Security Warrior

Possibly Related Articles:
7410
General
Information Security
Policy NIST Compliance Log Management Security Audits FISMA
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.