Federal Information Security Management Act of 2002

From Wikipedia, the free encyclopedia

The Federal Information Security Management Act of 2002 ("FISMA", 44 U.S.C. § 3541, et seq.) is a United States federal law enacted in 2002 as Title III of the E-Government Act of 2002 (Pub.L. 107-347, 116 Stat. 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 February 2005, 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.^[1] This shows a marginal increase in how federal agencies prioritize cybersecurity, but experts warn that this average must increase for the Government to truly protect itself.

1 FISMA Compliance Process for an Information System
2 References
3 Sources
4 See also

[edit] FISMA Compliance Process for an Information System

FISMA imposes a mandatory set of processes that must be followed for all information systems used or operated by a US Government federal agency or by a contractor or other organization on behalf of a US Government 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.

[edit] Determination of Boundaries of System

The first step is determining what constitutes an "information system." 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 provides guidance on determining system boundaries.

[edit] Determination and Categorization of Information Types in System

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 all the criteria of all information types resident in the system.

[edit] Select and Implement a Set of Security Controls for System

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, 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 a system security plan.

[edit] Documenting 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. 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.

[edit] Performing Risk Assessment

Once the controls implementation are documented, a risk assessment can be performed. 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 accepted or mitigated. If mitigated, 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.

[edit] Certification of System

Once the system documentation and risk assessment is complete, the system needs to 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 3rd party is required. NIST SP 800-26 provides guidance on the self assessment process. NIST SP 800-53A provides guidance on the assessment methods applicable to individual controls.

[edit] Accreditation of 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 3 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.

[edit] 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.