In 2007 a handful of companies (including Google, Microsoft, and Yahoo) decided to draft a set of guidelines influencing the behavior of online businesses when it comes to the subject of policies and regulations dealing with human rights. It was to be a kind of unofficial voluntary code of conduct initiative thing.

According to this letter(pdf) from Yahoo to Senators Durbin and Coburn:

Principles on Freedom of Expression and Privacy [...] provide direction and guidance to the ICT industry and its stakeholders in protecting and advancing the enjoyment of freedom of expression and privacy globally. The Principles describe key commitments in the following areas: Freedom of Expression; Privacy; Responsible Company Decision Making; Multi-Stakeholder Collaboration; Governance, Accountability & Transparency

Along with censorship and freedom of speech, the idea was also to provide general requirements for privacy. The idea also calls for a way to determine if a company is compliant with the code and a way to hold companies accountable if they violate it.

This is important because it shows that some of the most relevant internet-based companies are taking the rights of their users seriously. So seriously, in fact, that they are willing to sponsor a set of guidelines that help other companies protect THEIR user’s rights as well. If more companies get on board, this could be a step in the right direction in helping to strengthen the trust between service provider and user.

One of our clients unintentionally DoSed themselves this weekend by switching registrars. In what turns out to be an honest mistake on someone’s part, the new registrar set the company’s DNS servers to the registrar’s (pretty standard action), but they didn’t copy the old DNS information from the previous registrar. Effectively denying service to the organization’s mail server (no DNS entry and no MX record), and some websites that generate revenue.

I would suspect that this is a common situation for smaller companies. They decide that they’re not happy with their current registrar for whatever reason, and switch. Unfortunately, not understanding how computers find each other and buying into the “complete hosting solution” packages offered by many registrars. In an effort to prevent other small companies from suffering the same fate, I present DNS, whois, and hosting for dummies.

(more…)

The Markle Foundation has just helped launch what can best be described as the first REAL effort at designing a framework for organizing healthcare information online. This project is backed by some pretty heavy parties on both the tech side (Google, Microsoft, Intuit, WebMD, etc) and on the provider side (Aetna, BCBS, Department of Veteran Affairs, etc).

The framework is designed to establish a common set of “best practices” that should be followed by applications and services that handle, process, or store personal health-related data online.

According to Markle :

The framework …includes four overviews and 14 specific technology and policy approaches for consumers to access health services, to obtain and control copies of health information about them, to authorize the sharing of their information with others, and sound privacy and security practices.

I think this is a great step in the right direction. With the increase in instances of personal health records being stored electronically, a framework for keeping things as secure as possible is essential.

Microsoft HealthVault and Google Health drew some attention from the security industry when they were announced; consequently, issues of privacy and security were raised. As more and more providers and insurance companies are experimenting with making health records available to both doctors and patients via the Internet, these same issues will become more and more important.

It is good that they are getting together to lay down some “ground rules.”

There’s an old saying that the great thing about standards is that there are so many to choose from. This is clearly evident in the Health Care IT arena. The standards landscape is getting a little crowded, despite the fact that the push to actually integrate and support these standards seems to take a back seat to refining and creating more and more of them. Right now, I’m dealing with several of these standards at once – SAFE, XAdES and CDISC ODM to be specific. And, this is just a tiny fraction of the health care IT standards collection – there are more than 200 entries on the so-called “short list” of standards that apply to electronic records in the industry.

As standards go, the SAFE specification is relatively simple, as it is mainly a set of guidelines for how signatures must be created and validated as opposed to a format specification. The XAdES standard, in contrast, is a more formal XML-based digital signature specification that can provide timestamping and embedded revocation information. A few forms of XAdES signatures may
be made SAFE compliant, but the SAFE specification does not entirely overlap the XAdES standard; not all XAdES signature forms are SAFE compliant.

XAdES, specifically XAdES-X-L and XAdES-A, seems well suited for use in various CDISC [Clinical Data Interchange Standards Consortium] standards, including the Operational Data Modeling standard. The ODM standard provides an XML schema for maintaining clinical trial results.

I don’t really have a problem with the proliferation of standards in the health care IT space so long as these standards aren’t redundant, and in this particular case they aren’t. However, the more standards that are devised, the more expensive it’s going to become for applications to be compliant, especially when there are standards that are tangentially related, and then more standards have to be created to formally correlate them.

This week brought with it the exciting news that Exostar is launching a federated identity service for the aerospace industry.

Next week, however, Exostar will launch a new capability, the Federated Identity Service, that does the process of “credentialing” on behalf of Exostar’s members, ensuring that individuals that attempt to use the systems of the community or its members are who they say they are — and are authorized to use the systems they are trying to access.

The concept behind federated identity is a simple one. Leverage existing investments providing identification / authentication of users, and build an authorization structure that works across multiple applications, systems, companies, and vertical markets. The U.S. Government has their E-Authentication initiative, there are also the Shibboleth, Liberty Alliance, and WS-Federation standards. Tons of companies have interests and products in this area including Oracle, Microsoft, Novell, Sun, Symlabs, Ping Identity, CA, Siemens, IBM, etc. Other industry groups are looking to stand up their own federated identity infrastructures, similar to that performed by the aerospace industry.

The fortunate thing is that the SAML 2.0 standard seems to be the standard that most products, standards, and organizations are moving toward. However, just because everyone settles on SAML doesn’t mean that everyone will interoperate. I suspect there still needs to be some federating of the federation standards before more universal adoption is achieved.

And now let’s look forward 5-10 years toward a future where the entire Internet shares a federated identity infrastructure; where you can use one single CardSpace card and/or OpenID login to get into your email, bank accounts, paypal, social security benefits, buy things from Amazon, and forward your mail. Now, an identity thief needs to steal just one username and password and everything goes up in smoke.

I was at the Microsoft Health and Life Sciences Developer Conference last week in Atlantic City, where I got the chance to listen to a good presentation from Les Jordan of Microsoft about 21 CFR Part 11 compliance. The talk centered around how Microsoft is trying to make dealing with the V Model more manageable for validated application as it pertains to applying security patches.

One interesting point that was made was that if there is a security patch available for a validated system, and that patch has not been applied to that system, then the system is not considered by the FDA to be compliant. However, full qualification tests must be run and documented while applying the patch, which takes time. The issue that this creates is that security patches are released frequently enough and validation testing takes long enough such that validated systems become a bit of a mess to manage.

So, what can be done about this? One important step that was discussed is this: since the part 11 requirements only cover patches that affect the validated part of the system, any security updates released for non-validated portions of the platform should be pushed immediately. For example, a printer driver update for a printer that will never be used by a web server machine can be applied without testing, since it does not affect the validated functionality of the system. However, this just makes the problem a little more manageable; it doesn’t eliminate it completely.

If a validated system is out of compliance in an unpatched state but also out of compliance when a patch is applied without formal testing, I’m of the opinion that a “patch first, test second” approach should be taken. True, this may break some application functionality, but I would much rather have a broken application than an insecure one handling my personal data. [This assumes that compliance is taken as a binary data point: compliant or not-compliant. If there are degrees of non-compliance, I may change my mind about this.]

Aside from that, the only other option I can think of is to throw more resources at patch validation so security updates can be rolled out quickly. But, as we all know, security is not a value-add, so the goal is typically to throw as little money at security services as possible so as not to lose customers or run afoul of the law.

ISO 17090:2008 Parts 1-3 were released on February 14. But is this a new standard or just a rehash of existing standards? ISO 17090 is not new (previously released in 2002), but there’s no clear indication on how it has changed.

ISO 17090 sets out PKI standards and interoperability requirements for the healthcare industry – including certificate profiles, CPs, etc. I’d love to be able to read those standards (they’re about $125 each) to see how they compare to already existing standards such as SAFE and the Federal Bridge PKI. SAFE’s bridge is explicitly for the healthcare industry, but complies with the Federal Bridge certificate policies which spans multiple industries.

Has the new updated version taken into account these existing standards? Does the ISO standard include encryption certificates? Neither SAFE nor the Federal Bridge focus on encryption (it’s allowed in certificate profiles, but not for identity).

Either way, published standards for PKI interoperability (and not just technical standards) are good for the industry because it allows more PKIs to interoperate and “trust” each other. This gets more certificates in to the hands of healthcare professionals and providers and allows them to protect electronic health records – whether that’s a doctor sending a signed e-mail to a pharmacist containing a scrip for a patient, or pharmaceutical companies submitting electronic information to the FDA for approval.

No offense to the post office, but bits on a wire move a heck of a lot faster than they do.

The IESG secretary has announced a proposed recharter of the IETF PKIX working group.

The PKIX Working Group was established in the fall of 1995 with the goal of developing Internet standards to support X.509-based Public Key Infrastructures (PKIs). Initially PKIX pursued this goal by profiling X.509 standards… most PKIX-generated RFCs are no longer profiles of ITU-T X.509 documents.

PKIX is now seeking to redefine itself not solely by its profiling of ITU-T standards, but also developing standards that are useful for PKI and related systems.

An example of this type of RFC is the informational RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building, which I co-authored and edited. It fills a need not expressed by any ITU standard document—providing useful information to the developers of a certification path building system. The IESG’s recommendation to change the PKIX working group charter is welcome, perhaps a little overdue.