CMS Security Guidelines for Contractors: Q and A
On April 12, 2013, the Centers for Medicare and Medicaid Services (CMS) issued a memorandum to its prime contractors advising them that by June 28, 2013, they must secure an “attestation” (management assertion) of compliance, along with a determination of how much such an attestation would cost.
Significantly, the memorandum explicitly extended the compliance requirement to subcontractors. The specific standards discussed are associated with the Federal Information Security Management Act (FISMA) and the Federal Risk Authorization Management Program (FedRAMP).
CMS is extending the security “umbrella” it requires of government owned and operated systems to non-government providers whose products and services directly or indirectly support CMS activities. If CMS proceeds as expected, failure to comply could result in providers being barred from participating in the CMS supply chain, following the pattern set in recent years by other government and industry compliance requirements like the Health Insurance Portability and Accountability Act (HIPAA), payment card industry (PCI), and Sarbanes-Oxley Act (SOX).
This article defines some of the challenges facing contractors that do business with the federal government and recommends a few ways to begin addressing the new requirements. And now that the initial June 28 deadline has passed, what can federal contractors expect next?
What is FISMA?
The E-Government Act, signed into law in December 2002, recognized the importance of information security to the economic and national security interests of the United States. Within the act, 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.
Why are contractors included in the FISMA compliance mandate?
The federal government recognizes that most of the technology-supported services in governmental systems are being fundamentally transformed. In the past, most agencies have owned and operated their own specialized, proprietary technology platforms, but the model is shifting to the shared use of highly portable, reusable, and flexible systems. Internet-based components living in a combination of public, private, and hybrid “clouds” is becoming the norm in the commercial world, and government is moving in that direction.
Part of the challenge is that federal technology systems were often built within an agency to support the agency’s mission, and were designed, implemented, and controlled by its own people. As the number and complexity of interfaces across systems has increased, it is more difficult to assure that the established controls are reliable. Contractors and commercial service providers are also included in the mix now, so maintaining the appropriate level of security has become a greater challenge.
What does FISMA require of contractors?
Although the requirements initially may seem like a significant investment of time and money, from an information security perspective, they follow best practices. Even if you never intend to work with government agencies, complying with the security guidelines and recommendations of the National Institute of Standards and Technology (NIST) — the guidelines FISMA uses — is an excellent way to secure intellectual property and client information. FISMA requirements include:
- An inventory of information systems. FISMA requires agencies to have an information systems inventory. The first step is to determine what constitutes the information system, because it could be defined as a collection of individual computers put to a common purpose and managed by the same system owner. NIST SP 800-18, Revision 1, Guide for Developing Security Plans for Federal Information Systems, provides guidance on defining systems.
- Categorizing information and information systems according to risk. All information and information systems should be categorized based on the appropriate levels of information security. The basic guidelines are provided by NIST SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories.
- Security controls. Organizations working with the federal government must meet the same minimum security requirements as federal information systems. Agencies have flexibility in applying the baseline security controls, and this allows them to adjust the security controls to fit their mission requirements and operational environments. The controls selected or planned must be documented in a system security plan. The appropriate security controls and assurance requirements are described in NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems.
- Risk assessment. A foundational level of security is required for all federal information and information systems. An agency's risk assessment validates the security control and determines if any additional controls are needed. A risk assessment starts by identifying potential threats and vulnerabilities and mapping implemented controls to individual vulnerabilities. One then determines risk by calculating the likelihood and impact that any given vulnerability could be exploited, taking into account existing controls. The culmination of the risk assessment shows the calculated risk for all vulnerabilities and describes whether the risk should be accepted or mitigated. If mitigation is necessary, the agency must describe the additional security.
- A system security plan. Agencies should develop a policy on the system security planning process. NIST SP-800-18, Guide for Developing Security Plans for Federal Information Systems, introduces the concept of a system security plan, which is a living document that requires periodic review, modification, plans of action, and milestones for implementing security controls. It should document who reviews the plans, keeps the plan current, and follows up on planned security controls.
The system security plan is the major piece of the security certification and accreditation process. During the security certification and accreditation process, the system security plan is analyzed, updated, and accepted.
- Certification and accreditation. Once the system documentation and risk assessment is complete, the system's controls must be reviewed and certified that they function appropriately. Based on the results of the review, the information system is accredited.
Security certification is a comprehensive assessment of the management, operational, and technical security controls in an information system. Security accreditation is the official management decision given by a senior agency official to authorize operation of an information system and to explicitly accept the risk to agency operations, agency assets, or individuals based on the implementation of an agreed-upon set of security controls. By accrediting an information system, an agency official accepts responsibility for the system’s security and is fully accountable for any adverse impacts to the agency if a security breach occurs. Thus, responsibility and accountability are core principles that characterize security accreditation.
- Continuous monitoring. All accredited systems are required to monitor a selected set of security controls. System documentation must be updated to reflect changes and modifications to the system. Large changes to the system’s security profile should trigger an updated risk assessment, and controls that are significantly modified may need to be re-certified.
How is FISMA compliance demonstrated?
“FISMA compliance” essentially means fulfilling the requirements established within the agency to receive an Authority to Operate (ATO) from the responsible “senior agency official,” or in most cases, that official’s designated approving authority (DAA).
Although the federal government’s executive departments and agencies must generally follow NIST guidelines, they have broad latitude in defining how they will grant and maintain ATO for their systems. Civilian agencies generally follow NIST guidelines, while defense agencies have the Defense Information Assurance Certification and Accreditation Process (DIACAP), which provides an approach appropriate to military services. National security systems (containing classified information), in general, are exempt from FISMA altogether.
For contractors, the compliance landscape is murky. An agency acquiring commercially-provided services might be extremely specific in its statement of work regarding IT security, or it may require its contractor simply to “adhere to all FISMA requirements.” The latter is very common, lacking any specific guidance as to what will be expected to demonstrate “adherence” to the satisfaction of the agency’s DAA.
Most agencies have a certification package for systems to be authorized that contains documentation like the System Security Plan, a Security Assessment Report, applicable Interconnect Security Agreements (ISAs) and/or Memoranda of Understanding (MOU).
Contractors should receive explicit direction from the agency regarding the expectations for security compliance (including FISMA). Significantly, there is no truly independent or authoritative guideline at this time for acceptable contractor performance. As a result, contractor-related risk may be managed inconsistently or not at all.
Although some consultants claim they provide “FISMA certification,” there is no such thing as a standard, independent “certification” of FISMA compliance. Only the government grants ATO to systems in its inventory; providers comply as government contracts require.
Finally, it is entirely unclear whether any prime contractor’s requirements under FISMA are directly extendable to subcontractors or third-party suppliers.
Can a SSAE 16 service organization report support FISMA compliance?
The primary purpose of the SSAE 16 is to provide a user organization with a report on the reliability of the design and implementation of the service organization’s controls.
The starting point in an assessment of whether a SSAE 16 report supports FISMA compliance should examine what the agency is asking for from a security point of view. The contractor should be able to work with the agency (ideally with the accountable DAA) to establish what is required to demonstrate compliance. The DAA is all that matters because s/he must accept the risk associated with granting (and maintaining) ATO for the system or systems in its inventory.
Each step in a service chain (subcontractors or other vendors) below the prime contractor is no longer in the purview of the original government contract, so subcontractors must work through the prime to establish what rules apply to their own service or product, and make a business decision regarding the reasonableness of the prime’s interpretation of the requirements against the cost, complexity, and time needed to comply.
What is FedRAMP?
The government implemented FedRAMP in December 2011 to promote the rapid deployment of shared services. It provides a standard approach to security assessment, authorization, and continuous monitoring for cloud products and services.
The goals of FedRAMP are to:
- Accelerate the adoption of secure cloud solutions through reuse of assessments and authorizations
- Increase confidence in the security of cloud solutions
- Achieve consistent security authorizations using a baseline set of agreed upon standards and accredited independent third-party assessment organizations
- Ensure consistent application of existing security practices
- Increase confidence in security assessments
- Increase automation and near real-time data for continuous monitoring
Conformance with FedRAMP program requirements is now mandatory for commercial and governmental cloud service providers (CSP) seeking access to the federal market for such services. A CSP works with a specific agency or with the FedRAMP program directly to initiate a request for FedRAMP authorization. If accepted, authorization will include:
- Documenting the system’s security controls using a specified subset of the NIST SP 800-53 controls selected for FedRAMP
- Contracting with an approved third-party assessor organization (3PAO) to conduct an independent test of the implemented controls
- Submitting the security assessment package to a joint authorization board to grant provisional authorization
A FedRAMP-approved CSP can then offer its services (and agencies can acquire the services) without additional requirements, though additional controls may be added as a part of the integration and customization.
The 3PAOs in the approved list have met qualifications by FedRAMP for:
- Independence and quality management
- Information assurance competence that includes experience with FISMA and testing security controls
- Competence in the security assessment of cloud-based information systems
For the purposes of the CMS announcement, it is important to remember that FedRAMP is intended as an authorization approach to improve industry’s time-to-market in making cloud-based services available to government buyers. It does not establish a new compliance regimen, but CMS expects providers to incorporate the controls recommended by the FedRAMP program into their systems security plans if they operate according to a cloud service provider model.
What should CMS contractors and subcontractors do now?
All CMS primes and subcontractors should have delivered an initial response to CMS in the form of a Cost Impact Proposal or a No Cost Impact Statement by May 8, 2013. In addition, as previously noted, management attestation regarding compliance was due on June 28, 2013. Primes should have been informing subcontractors of the required information and may have requested a response prior to this date. Based on the responses it received (or did not receive) in time, CMS may revisit the form and content of the attestations, and could determine whether or not some kind of assessment will be needed in the future to validate the attestation claims. It is simply too soon to tell.
However, one element of the future is clear: every contractor and subcontractor providing services covered by the new CMS Security Standards should be planning how best to incorporate federal security guidance into their current security planning and implementation processes. For those organizations closest to the federal government, this may already be happening. For subcontractors operating beneath a prime, these requirements are likely to be unfamiliar and challenging.
Contractors and subcontractors with strong security programs were likely able to make a positive attestation in time for the June 28 deadline. The next step is to consider their current security control environments and perform a gap analysis against the NIST-based control set required under the CMS guidelines. This will help define a roadmap for necessary remediation actions and/or assessment steps to validate control effectiveness.
Again, some of this work may already be done, for example if the organization is already having SSAE 16 work done, regular and routine vulnerability assessment and/or penetration testing, or is supported by a managed security services provider that provides assurance regarding controls. Although such gap analysis may not have been performed in time to support a positive attestation to CMS by the June 28 deadline, it will still be beneficial in order to demonstrate how your organization plans to comply with the new security standards.
For all contractors, the complexity and duration of the gap analysis, roadmap, and remediation activities will vary widely based on the initial security “capability maturity” of the organization and the specific nature of the products and services provided to CMS. But the time to begin this work is now. Assuming that CMS will need to evaluate whether the new guidelines are yielding better information on overall CMS security posture, it can only be seen as positive if contractors, even those not immediately asserting compliance, are taking steps in that direction.
Jeff Zalusky, Federal Government Director