The Social Security Administration (SSA) has essentially been the first government adopter of the Nationwide Health Information Network (NHIN), going into production early this year with an information exchange with MedVa to receive medical records in support of disability claims. By all accounts, this first effort has been an unqualified success, reducing the time to retrieve and process the needed documentation from weeks or months to under an hour. SSA is now in the process of looking for ways to expand the number of medical record sources it can access to do benefit eligibility determinations more efficiently. According to an announcement last week, one option under serious consideration is tying into Microsoft’s HealthVault personal health record system. There are a lot of interesting aspects to this potential relationship, but one aspect that may be a bit unusual in the overall health information exchange context is that prospect of having an end-to-end exchange of electronic medical records completely outside the coverage of HIPAA. Neither Microsoft nor SSA is a covered entity under HIPAA, and there’s even some debate whether PHR vendors like Microsoft, Google, myPHR, and others fall under the category of “business asssociate” either. An information exchange between Microsoft and SSA would fall outside the scope of HIPAA and the Privacy Act, and would only be subject to the breach disclosure requirements in the Health Information Technology for Economic and Clinical Health (HITECH) Act. If nothing else, the evolution of health IT in such a direction largely outside the existing regulatory and legal framework governing personal health information only highlights the need to address patient privacy protections explicitly, rather than as an adjunct to laws focused primarily on organizational entities.
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.