Federal Information Security Management Act of 2002

The Federal Information Security Management Act of 2002 ("FISMA", usc|44|3541, "et seq.") is a United States federal law enacted in 2002 as Title III of the E-Government Act of 2002 (USPL|107|347, USStat|116|2899). The act was meant to bolster computer and network security within the federal government and affiliated parties (such as government contractors) by mandating yearly audits.

FISMA has brought attention within the federal government to cybersecurity which had previously been much neglected. As of|2005|2, many government agencies received extremely poor marks on the official report card, with an average of 67.3% for 2004, an improvement of only 2.3 percentage points over 2003. [ [http://reform.house.gov/UploadedFiles/Federal%20Computer%20Security%20Grades%20-%202001-2005.pdf Official Report Card: 2001-2005 (PDF)] ]

Compliance process

FISMA imposes a mandatory set of processes that must be followed for all information systems used or operated by a U.S. federal government agency or by a contractor or other organization on behalf of a federal agency. These processes must follow a combination of Federal Information Processing Standards (FIPS) documents, the special publications SP-800 series issued by NIST, and other legislation pertinent to federal information systems, such as the Privacy Act of 1974 and the Health Insurance Portability and Accountability Act. However, following these mandates only results in "compliance" and not "security".Fact|date=July 2008

Determine system boundaries

The first step is to determine what constitutes the "information system" in question. There is not a direct mapping of computers to information system; rather an information system can be a collection of individual computers put to a common purpose and managed by the same system owner. NIST SP 800-18 revision 1 provides guidance on determining system boundaries. In actual practice, no two agencies apply the guidance the same way, and the Office of Management and Budget has yet to provide useful clarification. Moreover, no two agency inspectors generally evaluate the definition of system boundaries the same way either. Therefore, no two departments or agencies are applying the same approaches to defining systems, applications, interconnections or controls.

Determine system information types and perform FIPS-199 categorization

The next step is to determine the information types resident in the system and categorize each according to the magnitude of harm resulting were the system to suffer a compromise of confidentiality, integrity, or availability. NIST SP 800-60 provides a catalog of information types, and FIPS-199 provides a rating methodology and a definition of the three criteria.

The overall FIPS-199 system categorization is the high water mark of the impact rating of any of the criteria for any information types resident in the system. For example, if one information type in the system has a rating of "Low" for "confidentiality", "integrity", and "availability", and another one has a rating of "Low" for "confidentiality" and "availability" but a rating of "Moderate" for "integrity", the entire system has a FIPS-199 categorization of "Moderate".

Document the system

Pertinent system information such as system boundaries, information types, constituent components, responsible individuals, description of user communities, interconnections with other systems and implementation details for each security control need to be documented in the system security plan.

A critical part of the system documentation is a hardware and software inventory of the systems and major applications that reside within the defined boundaries of the system. This inventory should include hardware make and model numbers, software version numbers, patch levels, and a functional description of the component such as "database", "webserver", "fileserver", or "directory server".

NIST SP 800-18 Rev 1 gives guidance on documentation standards. Additional documentation such as a contingency plan for the system also needs to be prepared at this stage. Guidance on contingency planning can be found in NIST SP 800-34.

Perform risk assessment

A risk assessments starts by identifying potential threats and vulnerabilities, and maps implemented controls to individual vulnerabilities. One then determines risk by calculating the likelihood and impact of any given vulnerability being exploited, taking into account existing controls. The culmination of the risk assessment shows the calculated risk for all vulnerabilities, and describes whether the risk is to be accepted or mitigated. If mitigated by the implementation of a control, one needs to describe what additional SP 800-53 controls will be added to the system. NIST SP 800-30 provides guidance on the risk assessment process.

elect and implement security controls

If the system in question is in the design or implementation life-cycle phase, a set of security controls must be selected and incorporated into the system implementation. Federal agencies must meet the minimum security requirements defined in FIPS 200 through the use of the security controls in NIST Special Publication 800-53 revision 2, "Recommended Security Controls for Federal Information Systems", which contains the management, operational, and technical safeguards or countermeasures prescribed for an information system. The controls selected or planned must be documented in the system security plan.

The area in which inconsistencies prevail most across the federal computing enterprise is in this area.Fact|date=July 2008 The concept behind "controls" is to mitigate risk, so that resulting risk can be accepted and the system can be accredited to operate. No two agencies interpret this concept the same way or apply controls the same way. Thus, it is possible for a system owner to accept infinite risk to operate a system, document the decision correctly, and accredit the system to operate.

Certify system

Once the system documentation and risk assessment is complete, the system must have its controls assessed and certified to be functioning appropriately. For systems with a FIPS-199 categorization of "Low", a self assessment is sufficient for certification. For systems categorized at higher FIPS-199 levels, a certification performed by an independent third party is required. NIST SP 800-53A provides guidance on the assessment methods applicable to individual controls. Although SP 800-53A is in draft status, it has become a requirement for certification testing and for the annual FISMA self-assessments.Fact|date=July 2008

Accredit system

Once a system has been certified, the security documentation package is reviewed by an accrediting official, who, if satisfied with the documentation and the results of certification, accredits the system by issuing an authorization to operate. This authorization is usually for a three-year period, and may be contingent on additional controls or processes being implemented. NIST SP 800-37 provides guidance on the certification and accreditation of systems.

Continuous monitoring

All accredited systems are required to monitor a selected set of security controls for efficacy, and the system documentation is updated to reflect changes and modifications to the system. Significant changes to the security profile of the system should trigger an updated risk assessment, and controls that are significantly modified may need to be re-certified. Guidance on continuous monitoring can be found in NIST SP 800-37 and SP 800-53A. According to NIST, the concept of "continuous monitoring" only means that "controls" are periodically checked to see if they are still appropriate and functioning as planned. The concept of continuous scanning and continuous testing of systems is almost nowhere to be found in NIST documents.

Issues

Security experts – such as Bruce Brody, a former federal chief information security officer, and Alan Paller, director of research for the SANS Institute – have described FISMA as "fundamentally flawed" and argued that the compliance and reporting methodology mandated by FISMA may be primarily a paperwork exercise that doesn't necessarily improve information security.

ee also

*System Security Authorization Agreement

Notes

References

* [http://csrc.nist.gov/groups/SMA/fisma/index.html] NIST: FISMA Implementation Project
* [http://www.fcw.com/article92421-02-24-06-Web] FCW: Security experts fault FISMA paperwork
* [http://www.gcn.com/print/25_7/40249-1.html] GCN: Interview with Bruce Brody
* [http://www.gcn.com/online/vol1_no1/43103-1.html] GCN: Experts: It’s time to fix FISMA

External links

* [http://csrc.nist.gov/publications/nistpubs/index.html NIST SP 800 Series Special Publications Library]
* [http://csrc.nist.gov/sec-cert/ NIST FISMA Implementation Project Home Page]
* [http://csrc.nist.gov/drivers/documents/FISMA-final.pdf Full text of FISMA]
* [http://csrc.nist.gov/ NIST Computer Security Resource Center]
* [http://www.intranetjournal.com/articles/200406/ij_06_23_04a.html Security Certification and Accreditation 101]
* [http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1059656,00.html Report on 2004 FISMA scores]