Contributions to CSI Alert on Claims-Based Identity Management

The September issue of the Computer Security Institute Alert focuses on claims-based identity, and includes articles by CSI Alert Editor Sara Peters, policy expert Charles Cresson Wood, “Privacy Professor” Rebecca Herold, and SecurityArchitecture.com’s own Stephen Gantz. Claims-based approaches to identity management have received increasing levels of attention in the past couple of years, helped in part by Microsoft’s incorporation of a claims-based architecture in .Net 3.0, and fueled in particular by needs to balance privacy protections and minimalization of information disclosure with identification, authentication, and authorization in widely distributed or federated environments.

Health information exchange outside HIPAA

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.

Effective security demands effective risk assessment

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.

Federal cyber security oversight slowly moving towards automation

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.

Health data breach notification rules published

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.