Newly arriving from DHS: binding operational directives

The Federal Information Security Modernization Act of 2014 introduces a new term to the federal security management lexicon: binding operational directive. The text of the law defines binding operational directive as “a compulsory direction to an agency that is for purposes of safeguarding Federal information and information systems from a known or reasonably suspected information security threat, vulnerability, or risk.” While somewhat common in financial and military contexts – both the World Bank and the U.S. Department of Defense, for example, frequently use the term operational directive in official documents – its appearance in FISMA 2014 seems novel, at least for federal legislation. Its purpose here appears to be directly tied to the responsibility that the Act assigns to the Secretary of the Department of Homeland Security (DHS) to issue, in consultation with the Director of the Office of Management and Budget (OMB), mandatory instructions to agencies about implementing security measures and practices called for in FISMA or in policies, standards, or guidelines developed under FISMA’s authority. Binding operational directives will presumably supplement or replace the security-related memoranda regularly issued by OMB. Because DHS is an executive agency, not part of the Executive Office of the President like OMB, directives from DHS would presumably not be mandatory for peer agencies without the additional statutory authority that FISMA 2014 provides. Going forward under FISMA, operational information security directives issued by DHS will be compulsory for all federal executive agencies (Congress and the courts will remain outside FISMA’s scope), enabling DHS to more effectively perform its cybersecurity responsibilities under the law.

FISMA 2014 codifies many current federal security practices

The Federal Information Security Modernization Act of 2014, enacted by Congress in mid-December along with three other pieces of cyber-security-related legislation, is noteworthy primarily for its emphasis on continuous monitoring of the security of federal systems; increased attention on incident detection, response, and reporting; and formally assigning the Department of Homeland Security (DHS) responsibility for developing, implementing, and ensuring government-wide compliance with federal information security policies and practices. For the most part, however, the 2014 update to FISMA introduces little new to federal security management, but instead codifies roles, responsibilities, requirements, and practices already put in place through OMB memoranda and other official guidance to agencies. A side-by-side comparison of the 2002 and 2014 FISMA legislation shows substantial similarities in the text of both laws, with major differences in only four aspects:

1. Responsibilities assigned to the Secretary of DHS (§3553(b))
2. Agency reporting requirements (§3554(c))
3. New guidance and reporting requirements on security incidents (§3554(b) and (§3558(b))
4. Policies and guidelines on data breach notification (§3558(d))

The 2002 FISMA law assigned essentially all agency oversight responsibilities to OMB (with annual reports to Congress), the 2014 version divides these responsibilities between OMB and DHS. To be fair, at the FISMA was enacted, it would have been infeasible to delegate explicit responsibilities to DHS, since the Homeland Security Act establishing that Department passed just three weeks before FISMA. The 2014 law has OMB handling information security policies and practices and overseeing NIST’s development of standards and guidelines and DHS leading the implementation of those policies, practices, and standards as well as monitoring agency information security practices and, when asked, providing technical assistance to other agencies. This separation of duties under FISMA 2014 is consistent with a clarification of cybersecurity responsibilities between OMB and DHS spelled out in OMB Memorandum M-10-28, issued in July 2010. M-10-28 placed administrative, budgetary, and fiscal oversight with OMB and gave DHS primary responsibility for “operational aspects” of security in all executive agencies, importantly including government-wide incident response.

Much has been made of the provision near the end of the new FISMA legislation that instructs OMB to update its Circular A-130 to “eliminate inefficient or wasteful reporting.” Appendix III of Circular A-130, last revised in 2000 a little more than two years before FISMA was enacted, contains the requirement that agencies formally authorize each of their information systems before putting them into operation and re-authorize them at least every three years. The language in the new law, taken together with the emphasis on continuous diagnostics and monitoring, is assumed to imply that agencies will no longer need to undergo system assessment and authorization processes for the systems they already have operating. Despite the appeal of this interpretation, it is not at all clear that the time- and labor-intensive set of activities and security artifacts specified in the NIST Risk Management Framework will be set aside in favor of robust monitoring programs. Also overlooked is the fact that OMB somewhat quietly waived the every-three-year re-authorization requirement in an answer to a question in the “frequently asked questions” section of its fiscal year 2011 FISMA reporting instructions to agencies, which explained that the implementation of continuous monitoring programs by agencies would obviate the need for system re-authorization every three years.

With respect to security incident reporting and breach notification, FISMA 2014 both substantially augments the obligations of federal agencies for incident handling and reporting and incorporates provisions in official guidance to agencies issued since the 2002 law went into effect. FISMA 2014 provides its own definition of incident: “an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.” It also adds an agency obligation to report “major incidents” within seven days of their occurrence to designated Congressional committees, in addition to existing requirements to report incidents to appropriate agency officials. There is no reference in the new law to current reporting timeframes for notifying the U.S. Computer Emergency Readiness Team (US-CERT) of incidents, which in the case of incidents involving highly sensitive data require notification within one hour of discovery. This reporting requirement has been in place since 2007, and seems unlikely to change, even as US-CERT now officially falls within the National Cybersecurity and Communications Integration Center codified in the National Cybersecurity Protection Act of 2014 (one of the other bills enacted with the new FISMA legislation).

Three years in, FedRAMP offers 3 paths to compliance

In its December newsletter, the Program Management Office for the Federal Risk and Authorization Management Program (FedRAMP) rolled out a new FedRAMP logo and announced the addition of four cloud systems to its list of authorized service providers, bringing the total of authorized solutions to 27 since the program was first announced in late 2011. These cloud systems break down into three categories according to the approach used to achieve FedRAMP authorization:

1. Employing the services of an accredited independent third-party assessment organization (3PAO) to assess the security controls implemented by a cloud service provider and submitting the Security Assessment Report and other documentation prepared by the 3PAO to the FedRAMP Joint Authorization Board for approval (termed “JAB Provisional Authorizations”).
2. Working directly with a federal agency to produce the security documentation and assessment evidence needed to receive an agency authorization to operate (ATO), which can then be reviewed by the Joint Authorization Board for FedRAMP compliance and made available for other agencies to leverage.
3. Creating a security authorization package and submitting it to the FedRAMP program for review and verification of completeness, as a time-saving step facilitating subsequent review of a cloud service provider (CSP) by a federal agency to make an authorization decision.

The availability of multiple paths to FedRAMP compliance seems to support the program’s commitment to encouraging as many service providers as possible to participate. Both the 3PAO and CSP-supplied paths can be undertaken without an existing federal agency contract in place, although the finalization of the FedRAMP authorization process under the third approach still requires the involvement of an agency customer. The CSP-supplied approach is significantly less expensive than using a 3PAO – independent assessments typically require six-figure investments by CSPs – but leaves the CSP without an actual authorization to operate. To date, only one of the 27 cloud systems on the FedRAMP list falls under the CSP-supplied category, while there are 15 systems with JAB provisional ATOs and 11 agency-authorized systems (some of which have been authorized by more than one agency).

NIST updates security control assessment procedures

On December 12, the National Institute of Standards and Technology (NIST) Computer Security Division announced the final release of Special Publication 800-53A Revision 4, Assessing Security and Privacy Controls in Federal Information Systems and Organizations. This new update brings security control assessment procedures into alignment with the current version of the government’s security control framework, the latest revision of which was published in April 2013.

The final version of this guidance should lead to a revision in security control assessment practices in all agencies and also remove a practical obstacle to the adoption of 800-53 Rev. 4, as many agencies delay their migration from one version to the next until corresponding assessment guidance is available. The more than 18-month gap between the release of 800-53 Rev. 4 and 800-53A Rev. 4 can be attributed in part to the substantial changes seen in the control framework compared to the previous version, notably including the addition of separate set of 26 privacy controls and an expansion in program management controls, all of which are mandatory for federal information systems and security management programs.

The fundamental structure of security control assessment procedures in 800-53A remains the same as in previous versions (NIST skipped from Rev. 1 straight to Rev. 4 in the latest release, to synchronize the revision numbers with 800-53). For each control, 800-53A provides a set of assessment objectives, with each objective broken down into one or more determination statements that tell an assessor what to look for when deciding whether a system or agency satisfies an objective. Assessment procedures specify different methods assessors should use (examine, interview, and test) against the objects of the assessment (specifications, mechanisms, activities, and individuals). The guidance in 800-53A also defines various levels of detail (and effort) with which each method can be applied to help assessors appropriately tailor assessments to the assurance requirements specific to each system.

What is noticeably different in 800-53A Rev. 4 is the level of granularity in the determination statements found in the catalog of assessment procedures in Appendix F of the document. While the prior version included assessment objectives and determination statements for every security control and enhancement, those statements often were long phrases that included many details in each statement. In contrast, the new version has many many more determination statements, but each statement is short and explicit, addressing a single concept, action, or detail related to an assessment objective. For example, for the “Account Management” control (AC-2), the previous version of 800-53A had three numbered determination statements, the first of which incorporated nine attributes. The new assessment procedure for AC-2 has eleven primary determination statements, all but four of which are broken down further into subordinate statements (and in the case of one statement into a third level of detail). This results in a total of 30 numbered items each subject to a satisfied/other-than-satisfied finding.

Guidance for producing assessment reports carries forward the increased level of detail, as an assessor’s determination of “satisfied” or “other than satisfied” is applied to every determination statement in the assessment procedures. This change could make security assessment reports more closely resemble audit reports and compliance checklists commonly found in traditional financial and IT auditing contexts, but it also greatly increases the set of items for which individual findings would be recorded. Federal security control assessment procedures and the broader Risk Management Framework of which assessments are a part requires agencies to apply risk-based decision making and, where appropriate, corrective action to all “other than satisfied” findings. Organizations following the assessment reporting guidance in 800-53A Rev. 4 may initially find that they have a much higher number of findings to address, but the finer granularity of the determination statements and assessment procedures should greatly reduce the scope and, potentially, level of effort required to address each finding.

One other notable addition to 800-53A Rev. 4 is the introduction (in official guidance) of the concept of security and privacy capabilities, which are essentially functional descriptions that correspond to multiple underlying security controls. It seems the intent of recommending the use of capabilities to agencies is to increase the alignment between implemented security controls and the security or privacy requirements they are designed to meet or support. Based on the description in 800-53A Rev. 4, the concept of capabilities also reflects an acknowledgement that weaknesses in or absence of any single security control may not significantly impact the ability of an agency to delivery the capabilities it needs.

Update to FISMA signed into law

After several Congressional sessions that saw proposed information security legislation fail to pass, within the span of 10 days in December both houses of Congress passed, and the president signed into law, the Federal Information Security Modernization Act of 2014. This act, which provides the first comprehensive update to federal security regulations since 2002, is touted by legislators and the media as a significant and long-overdue effort to bring federal cybersecurity practice into the 21^st century, but upon initial inspection appears to be more of an incremental improvement rather than a sweeping change. The key provisions in the law – which handily condenses to the same FISMA acronym as its predecessor, the Federal Information Security Management Act of 2002 – serve to codify changes in federal policy and security management guidance to agencies that had previously been made through official memoranda issued by the Office of Management and Budget (OMB).

These changes to FISMA 2002 written into FISMA 2014 include:

• Formal describing the roles and responsibilities for federal security management oversight between OMB, the Department of Homeland Security (DHS), and several Congressional committees
• A shift in emphasis to continuous monitoring (termed “Continuous Diagnosis and Mitigation” to align with a DHS program of the same name) instead of the prior checklist-based documentation and reporting used since 2002
• The addition of mandatory security incident and breach reporting requirements that require agency to notify Congress of breaches and major security incidents

The new FISMA legislation remains limited in its applicability to federal executive branch agencies, although Congress also passed separate bills to codify the cybersecurity framework developed by the National Institute of Standards and Technology (NIST) as directed under a February 2013 Executive Order on critical infrastructure cybersecurity and to formalize the DHS National Cybersecurity and Communications Integration Center (NCCIC) as the government nexus for public and private sector information sharing about cybersecurity threats and incidents. The bulk of the FISMA 2014 legislation mirrors the text of the 2002 law and of the Government Information Security Reform Act of 2000, at least in terms of the primary obligations it imposes on federal executive agencies and their information security management programs.