Overview

Our expert security consultants review every element of your FISMA compliance, including: policies, procedures, configuration management, certification and accreditation, remediation plans, and security awareness training.

Highlights

• Identifies gaps in your agency's security program and FISMA reporting.
• Provides detailed recommendations for remediating or maintaining compliance.
• Dedicated resources help allow your agency team members to focus on business issues rather than security matters.
• Designed to improve compliance and security by implementing appropriate solutions.
• Security expertise from Security Brigades team of experienced security professionals.
• Industry-leading security intelligence, support and guidance from our SB security research and development team.

Features

Our FISMA compliance solution helps enable you to evaluate, manage and improve compliance using a three-step approach that involves assessment, remediation and a comprehensive audit. Designed to result in a FISMA-compliant environment and an improved security position.

We review every element of FISMA compliance, including: policies, procedures, configuration management, certification and accreditation, remediation plans, and security awareness training. Security Brigade's consultants also assess the ability to achieve and improve compliance over time.

Key Features

• Addresses FISMA requirements to ensure protection of the confidentiality, integrity, and availability of systems and their information.
• Addresses information, personnel, and physical security and privacy, in a holistic manner, ensuring sound IT governance, operations security and business continuity – thereby fostering strong compliance with FISMA.
• Determines the level of risk assurance of security controls over information resources that mitigate risks to an acceptable level.
• Determines if adequate security controls have been implemented or there is a realistic plan for their implementation.
• Provides a cost effective solution designed to provide agency management with an assessment of the adequacy of their information security program, and if needed, a remediation plan of what needs to be done to improve their program.
• Based on National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) and Special Publications.

Benefits

Security Brigade's Federal Information Security Management Act (FISMA) compliance solution helps Federal agencies evaluate your security posture against the requirements and best practices established by the National Institute of Standards and Technology (NIST).

• Consistent training across organisation.
• Prevention of security breaches and to protecting data integrity.
• Security Awareness provided to every computer user in organisation.
• Identify responsibilities with role-based Information Security training available to all employees and contractors with network access/responsibility.
• Prevents loss of customer’s confidential information.
• Helps to achieve and maintain compliance with federal and state regulations.
• Overcoming legal hassles due to failure of the application security.

Technical Information

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 organisation 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. Unfortunately, following these mandates only results in "compliance" and not "security." The flaws of the current process are addressed in the "Discussion" section.

Determine the Boundaries of the System
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 general 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 the Information Types in System 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. So 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," "directory server," etc.

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.

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

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 revision 1, 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. Perhaps the area where inconsistencies prevail most across the Federal computing enterprise is in this area. 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. Here is where FISMA has its soft underbelly. Theoretically, 100% of all Federal information systems can be certified and accredited, thus receiving full FISMA credit. However, it is possible (even probable) that all 100% cannot be considered "secure." The myth of FISMA is that the annual grades have something to do with security; in actuality, the grades are about the acceptance of massive amounts of risk.

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-53A provides guidance on the assessment methods applicable to individual controls. Even though SP 800-53A is in draft status it has become a requirement for Certification Testing and for the annual FISMA Self-Assessments.

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 (ATO). 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.

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.