Work with federal information systems? Responsible for risk management, continuous monitoring, or FISMA compliance? Check out my book: FISMA and the Risk Management Framework.

Monday, July 27, 2009

No point in asking private entities to comply with FISMA

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.

Monday, July 13, 2009

Not everyone agrees what is (and isn't) personal information

Deliberations among European Union member countries made privacy headlines in early 2008 when Peter Scharr, data protection commissioner for Germany and leader of a group of EU data privacy regulators, while speaking at a European Parliament hearing on online data protection, concluded that Internet Protocol (IP) addresses should be considered personal information, insofar as they can often be used to identify an individual based on the individuals ownership or use of a computer associated with an IP address. This view — not pervasive across the European Community but at least indicative of a way of thinking that emphasizes personal privacy protections — has long been opposed by major IT industry players like Google, but is typically supported by privacy advocates like the Electronic Privacy Information Center. Last month a federal judge concluded just the opposite, ruling that IP addresses are not personal information while dismissing a class action suit against Microsoft in which plaintiffs had argued that Microsoft's practice of collecting IP addresses during automated updates violated its user agreement, which does not allow the company to collect information that personally identifies users.

Beyond the still unresolved issue of whether an IP address should be treated as personally identifiable information, and under what specific circumstances, the disagreement in federal level thinking between countries further highlights the challenges that organizations face in complying with privacy laws and regulations across the global economy, and the difficulty faced in overseeing and enforcing those laws and regulations.

Thursday, July 2, 2009

FISMA still being touted as best security for health information exchange

Coming out of the recent CONNECT User Training Seminar held this week in Washington, DC is a reiteration of the opinion previous expressed by federal stakeholders working on the Nationwide Health Information Network (NHIN) that non-federal entities seeking to participate in the NHIN need to step up their security and privacy to at least meet the level of federal practices under FISMA. The suggestion once again is that security practices of private sector healthcare organizations and other businesses are less rigorous and less effective than those of public sector organizations. The recommendation is that all would-be NHIN participants should adopt a risk-based security management and security control standard such as the framework articulated in NIST Special Publication 800-53, used by all federal agencies.

There's no question that a baseline set of security standards and practices would go a long way towards establishing the minimum level of trust needed for public and private sector entities to be comfortable with sharing health data. What seems a bit disingenuous however is the suggestion, repeated on Tuesday by the CIO of the Center for Medicare and Medicaid Services, that current government security and privacy practices are the model that should be broadened to apply to the private sector. Any organization currently following ISO/IEC 27000 series standards for risk management and information security controls is already assuming a posture commensurate with a federal agency using 800-53 — no less an authority than the FISMA team at NIST has acknowledge the substantial overlap between 800-53 and ISO 27002 controls, and NIST's more recent released SP800-39 risk management guidance was influenced by the corresponding risk management elements in ISO 27001, 27002, and 27005 as well.

The hardest piece to reconcile may be the need for organizations to certify the security of their systems and supporting processes. Here again, it's hard to argue that some sort of certification (or even objective validation) of security controls could help establish, monitor, and enforce necessary security measures in all participating organizations. The federal model for certification and accreditation is a self-accrediting form of security governance, so the logical extension of this model would be to have private enterprises similarly self-certify and assert their security and privacy practices are sufficient. Aside from the trust issues inherent to any subjective system of self-reported compliance, it's not at all clear what level of oversight would be put in place under the still-emerging NHIN governance framework, or what federal laws have to offer in terms of an approach. While there are explicit legal penalties for violation of health privacy and security laws such as HIPAA, the only outcome for a federal agency failing to follow effective security practices under FISMA is a bad grade on an OMB report card. FISMA simply isn't a best practice for verifying effective security.