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.
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.
For example, the following umbrella page http://csrc.nist.gov/groups/SMA/fisma/overview.html covers how to plan a FISMA project at a federal agency. In addition to NIST, OMB was tasked with collecting agency reports on compliance – FISMA periodic validation regime.
The main source for detailed guidance is NIST Special Publication 800-53 “Recommended Security Controls for Federal Information Systems” , now in revision 3 (http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdf).
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.
Let’s review the guidance in detail:
NIST 800-53 Logging Guidance
The section “AUDIT AND ACCOUNTABILITY POLICY AND PROCEDURES” (AU controls) focuses on AU-1 “AUDIT AND ACCOUNTABILITY POLICY AND PROCEDURES” covers “Formal, documented procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls.”
This is indeed the right way to approach audit logging by starting from the logging policy and procedures for log collection and review. While audit controls in FISMA go beyond logging, the above guidance is very true for log management.
AU-2 “AUDITABLE EVENTS” refers to NIST 800-92, covered in the next part of the series. As expected, risk assessment as well as logging needs for other organizational units needs to be considered for creating a list of auditable events. Events that are only audited under “special circumstances”, such as after an incident, are also defined here.
Logically, after the list of events to audit is established, AU-3 “CONTENT OF AUDIT RECORDS” clarifies the level of details recorded for each event. Examples such as “time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked” which should be in every good log records are provided. Refer to CEE standard work (http://cee.mitre.org) for further discussion of high –quality logging.
AU-4 “AUDIT STORAGE CAPACITY” and actually AU-11 “AUDIT RECORD RETENTION” cover the subject critical for many organizations – log retention. Unlike PCI DSS NIST guidance only offers tips for selecting the right attention and not a simple answer (like, 1 year in PCI)
AU-5 “RESPONSE TO AUDIT PROCESSING FAILURES” mandates an important but commonly overlooked aspect of logging and log analysis – you have to act when logging fails. Examples that require action include “software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded” as well as other issues affecting logging.
AU-6 “AUDIT REVIEW, ANALYSIS, AND REPORTING” is about what happens with collected log data. Specifically it prescribes that organization “reviews and analyzes information system audit records for indications of inappropriate or unusual activity” at “organization-defined frequency.” Again, NIST/FISMA guidance stays away from giving a simple answer (like daily log reviews in PCI DSS)
AU-7 “AUDIT REDUCTION AND REPORT GENERATION” deals with reporting and summarization, the most common way to review log data.
AU-8 “TIME STAMPS” and AU-9 “PROTECTION OF AUDIT INFORMATION” as well as AU-10 “NON-REPUDIATION” address log reliability for investigative and monitoring purposes. Logs must be accurately timed and stored in a manner preventing changes. One mentioned choice is “hardware-enforced, write-once media.” The use of cryptography is another mentioned method.
AU-12 “AUDIT GENERATION” essentially makes sure that the organization “generates audit records for the list of audited events defined in AU-2 with the content as defined in AU-3.”
Next, logging guidance ends and security monitoring part begins: AU—13 “MONITORING FOR INFORMATION DISCLOSURE” focuses on information theft (“exfiltration” of sensitive data) and AU-14 “SESSION AUDIT” covers recording and analysis of user activity (“session data”). I often say that logging is largely futile without exception handling and response procedures.
Overall, here is what is likely needed for a successful FISMA-driven log management implementation. The way to address the requirement can vary across the type of an organization, as it is the case for all log management projects.
Approach to FISMA Logging
What do you actually need to do? The following distills FISMA/NIST guidance into actionable items that can be implemented and maintained, for as long as FISMA compliance is desired or mandated.
- Logging policy comes first. But it means nothing without operational procedures which are developed base and policy and then put into practice (AU-1)
- This will likely require configuration changes to multiple types of systems; updates to configuration standards prescribed elsewhere in the document is in order
- Based on the policy, define which event will be logged (AU-2) and what details will be generated and recorded for each event (AU-3). Start the logging as per AU-12
- Consider logging all outbound connectivity to detect exfiltration of data (as per AU-13) and make sure that user access sessions are recorded (AU-14)
- Define log storage methods and retention times (AU-4 and AU-11) and retain the generated logs
- Protect logs from changes, keep time accurate to preserve the evidentiary power of logs (AU8,9-10)
- Also according to policy, implement log review procedures and report generation (AU-6, AU-7). Distributing reports to parties that should see the information (also as per policy created in item 1)
At this point, your organization should be prepared for FISMA compliance on both policy level and technical level. It is now up to you to maintain that awareness for as long as needed. A dangerous mistake that some organization make is to stay on the policy and procedure level and never configure actual systems for logging.
Remember – documents don’t stop malicious hackers, policies don’t help investigate incidents when log data is missing and talking about “alignment of compliance strategy” does not make you secure – or even compliant…
While FISMA might soon be updated with a new law (“FISMA 2.0”) prescribing continuous monitoring, it is highly likely that logging, log analysis and reporting will still be in.
NIST 800-53 audit controls AU-1 to AU-14 as well as other references to audit logging in the document call for a comprehensive log management and log review program, linked to data leakage detection and security monitoring.
We have distilled FISMA logging requirements into a clear strategy that can be implemented using any log management tool. It is also important to note that while FISMA logging starts from the logging policy and procedures, it must not stop there. Procedures don’t make you secure – diligently following them does!
It is also useful to remember that FISMA is not about getting and storing logs, but about getting useful and actionable insight (AU-6 requirement).
In the next part, we will dig deeper into how such logging program can be defined and implemented, and also how to tie it to SANS 20 Critical Security Controls for picking the priority items to implement first.