While most of the public attention focused on the Consensus Audit Guidelines has been fairly positive, two key aspects continue to be overlooked that may work against the intention of the CAG to improve baseline security among agencies. The first issue — that the common controls in the CAG, even when automated, do not provide any insight into how effective they are in protecting agencies that employ them — is basically ignored by all of the more than 100 contributors to the effort to date. The second issue is one raised most recently by CAG co-developer John Gilligan as a shortcoming in NIST’s extensive 800-53 security control framework, namely that implementing such a complex control framework requires agencies to conduct effective risk assessments, and (Gilligan says) most agencies lack the resources and expertise to do this.
It seems the implication is that working through close to 200 controls in 800-53 is too overwhelming for agencies, but by focusing on the 20 common controls in the CAG agencies can address the most critical security risks in a consistent way. Less clear is why the controls in the CAG shouldn’t be subject to the same thorough risk assessment as any other controls — perhaps the threats and vulnerabilities they are designed to address are so pervasive that no risk assessment is needed to justify them? If the consensus is that the choice of security measures should be risk-based, then decisions about implementing the 20 common controls should also be risk-based, otherwise you run the risk of replacing appropriate security management practices with regulatory mandates.
A separate but related issue is how agencies can address the gap in their ability to conduct effective risk assessments, if in fact such a gap exists. For its part, NIST has made significant changes in overall security management focus to re-emphasize a risk-based approach (most obviously seen in the relatively new Special Publication 800-39), but NIST’s risk management approach remains centered on information systems, so agencies have little guidance to address enterprise risk management that goes beyond systems and data to include business processes and management practices (the inclusion of a “policy” control in each of the 18 control families in 800-53 is not a substitute for addressing operational practices). The revised 800-53 is itself a step in a less exclusively system-centric approach, with the addition of the provisions in the Program Management control family. Agencies might benefit by referencing the Risk Management practices addresses in the ISO/IEC 27000 series of security management standards, which are often used in coordination with IT management “best pratice” frameworks like ITIL.
While the information required to be submitted for this fall’s information systems security reporting under the Federal Information Security Management Act (FISMA) hasn’t changed significantly, OMB announced in a memorandum last week that FISMA reports will henceforth be submitted via an online data collection and reporting tool, rather than the spreadsheets used in past years. This is certainly a step in the right direction, and is a natural development given the declaration of FISMA reporting as one of the key services that could be provided to government agencies as a centralized service, rather than having every agency maintain its own reporting capability. Under OMB’s Information System Security Line of Business (ISS LOB), the Department of Justice and Environmental Protection Agency have been designated as service providers for FISMA reporting (the other ISS LOB service is security awareness training, provided by the Department of Defense, the Office of Personnel Management, and a joint Department of State-US Agency for International Development effort), so to the extent other agencies make use of these centralized services, the number of sources of FISMA report information will shrink significantly. Automating FISMA report submissions is also greatly simplified by consolidating the system instances used to collect the data and produce the reports. ISS LOB partner agencies gave every indication that one benefit of centralizing FISMA reporting would be greater automation, but it is important to recognize that the OMB memorandum applies to all agencies, and mandates use of the new submission mechanism for all agencies (the reporting deadline has been pushed back to mid-November to give agencies some time to adapt to the new format).
The initial beneficiary of this change is OMB. There has long been some value in having FISMA report data loaded into databases from which it can be associated to other relevant agency information submitted to OMB through other channels and processes. Under the Obama administration and especially under the direction of federal CIO Vivek Kundra, OMB is working with agencies to try to minimize the amount of overlapping or duplicative information requested in data calls or required submissions. For example, the Exhibit 300 business case justification form agencies must use to report their major (i.e., over $10 million) IT investments no longer requires information system security and privacy information to be included; instead, agencies are directed to ensure that FISMA reports include valid IT investment unique identifiers for each information system, which will allow each IT investment to be associated with relevant system-level security and privacy information submitted through the FISMA reporting process. This not only decreases the information reporting burden on agencies, but in theory also will improve data quality by replacing multiple (potentially conflicting) submissions of the same information with a single submission drawn from the authoritative data source for the information in question. This puts additional pressure on agencies and OMB to ensure that the linking fields (essentially the foreign keys in the database tables) used to associate data sets reported separately are consistently used across agencies.
The Department of Health and Human Services has published an interim final rule in the Federal Register formalizing requirements contained in the HITECH portion of the American Recovery and Reinvestment Act that that organizations provide breach notification for unsecured protected health information. This rule is another step in what appears to be the expansion of health IT security and privacy regulations to organizations and business entities beyond those explicitly named as covered entities in the Health Insurance Portability and Accountability Act (HIPAA). In parallel with HHS’ action, the Federal Trade Commission also published a final breach notification rule for electronic health information that applies to online vendors providing personal health records and related information. In general, personal health record providers such as Google, Microsoft, and myPHR are not covered by HIPAA requirements in the privacy and security rules, but under a clause in HITECH, are to be treated very similarly to covered entities at least in terms of requirements to disclose data breaches. Entities falling under both the HHS and FTC rules have one primary means to have the breach notification requirements waived — they can encrypt or otherwise render their data unusable, as implied by the emphasis on “unsecured” health information in both the HHS and FTC rules. HHS first issued guidance in April on technologies and methods organizations can use to secure their data and therefore become exempt from the breach disclosure rules.
NIST last week released the final version of Revision 3 of its Special Publication 800-53, “Recommended Security Controls for Federal Information Systems and Organizations.” This update has a number of really interesting characteristics, beyond the simple summary about the number of controls in the latest version of the 800-53 framework, which serves as the basis for determining which controls should be used in federal computing environments and for evaluating those controls as part of the process of certifying and accrediting information systems. The new release is among the first final products resulting from a NIST-managed effort to incorporate the perspectives of civilian, defense, and intelligence agency security programs, with a single control framework applicable to all federal agencies. (A separate but related effort will standardize the certification and accreditation process by normalizing aspects of the DIACAP process favored by the Department of Defense with the civilian agency standard guidance in Special Publication 800-37.) The influence of DOD and intelligence community contributions is evident in the new 800-53, especially in areas such as the System and Communications Protection security control family, where nearly a third of controls new to the framework appear.
From an overall perspective, the most notable change may be the expansion of the coverage of 800-53 to begin to address agency security programs in addition to information systems. The obvious change here is in the addition of an 18th security control family called “Program Management,” but the change in scope is apparent even in the title of the document, which in its two previous versions did not include the words “and Organizations.” This change in consistent with a need now recognized in Congress as well as among agencies that the existing emphasis on information system security fails to address the overall effectiveness of the agency information security programs mandated by FISMA. While the vast majority of current federal security standards and guidance is still focused on information and information systems (with little or no attention to business processes or programs), subtle changes in language and tone in 800-53 and other recent draft documents such as Special Publication 800-39, “Managing Risk from Information Systems: An Organizational Perspective” suggest that NIST is evolving away from this narrow system focus to try to raise the visibility of enterprise risk management and information assurance functions. Another significant new feature is the addition of a prioritization rating (1 to 3) that gives an indication of what controls to address first. These ratings don’t obviate the need to implement all required controls corresponding to the security categorization of an information system, but seems to be a practical recognition that you can’t address everything at once.
In the aggregate, the number of security control families went from 17 to 18, with 34 new controls added and seven withdrawn, bringing the total number of controls across all families to 198. Something else to keep in mind is that deltas don’t tell the whole story — some controls were re-named or had their emphasis changed so organizations will need to revisit these to make sure existing controls are consistent with the new intent in 800-53. While a detailed review of all the changes in the framework is well beyond the scope of this forum, a few noteworthy aspects are summarized here.
Putting 800-53 Revision 3 into effect by itself will have a reasonably significant impact on agencies, particularly as the re-authorizations come due for their existing production systems. It is not yet clear if agencies will feel the need to re-authorize sooner, perhaps based on required annual risk assessments that are bound to turn up controls that need to be addressed that weren’t included in 800-53 when the previous certification and accreditation was performed.
In what has become a consistent theme out of the Office of the National Coordinator for Health IT, it seems the idea is still under consideration to try to require private-sector organizations to comply with the Federal Information Security Management Act (FISMA) in order to participate in health information exchanges with federal agencies. As currently in force, there are a couple of real problems with this approach, at least if the goal is to make sure the systems in question are protected with at least a consensus minimum set of measures. Based on a subjective security categorization, FISMA does mandate a minimum set of control types that must be put in place via the control framework in Special Publication 800-53. The biggest problem is that the determination of how each of the required security controls is implemented is subjective, and there is currently no federal standard for evaluating controls to determine their effectiveness. The accreditation of information systems in federal agencies is also to a subjective decision, based not only on what controls are put in place but also on what level of risk the organization is willing to accept. Risk tolerance isn’t consistent among federal agencies (which is why, for example, you find a security policy from the Centers for Medicare and Medicaid Services that forbids its contractors to send personally identifiable information via the Internet, regardless of the encryption, VPN, or other protective measures that might be applied). It seems safe to assume that risk tolerance would be even more variable among the many types of private entities that might have a role in nationwide health information exchange. Applying FISMA would tell a private enterprise that they need to decide that their own implementation of security controls is “secure enough” to be put in production, but doesn’t require any entity to consider the security needs or preferences of its information exchange partners. Once the private entity says “yes” to that, under FISMA they’re good to go. Oh, and there isn’t any mechanism for an auditor or other overseer to follow up and see if they agree with the entity’s own assessment.
So now we might have a slew of private enterprises, all producing lots of system security documentation as federal agencies do now, self-proclaiming the sufficiency of their security, and moving happily into production with health information exchange. What happens when something goes wrong, like a breach or inappropriate disclosure of information? Under FISMA, the answer is “nothing.” The Office of Management and Budget, it its capacity as the receiver of FISMA report information from federal agencies, assesses agency information security programs as a whole, but does not as a general rule delve into the details of individual information systems. For really high profile systems, the Government Accountability Office might do its own assessment and produce a report, as is often the case when a member of Congress asks for a review of an important system that supports a key program. No one has yet suggested that OMB, ONC, or any NHIN-specific governance body would be staffed and tasked with the responsibility of evaluating exchange participants’ security, at least not beyond the time of initial “enrollment” or joining the NHIN. There is no penalty, civil or criminal, for failing to comply with FISMA, or for suffering an incident, even if it was due to an agency’s failure to properly implement a required security control. It is unclear how asking private entities to operate under these requirements would have any meaningful impact on securing information exchanges, aside from the huge increase in work for these entities to document their existing security mechanisms.