This week, I registered for the next Document Interop Initiative (DII) workshop being held at Microsoft. (Details here)

The meet-up is centered around the new XML Advanced Electronic Signatures (XAdES) support in Office 2010. In my opinion, this is a great step forward for Office’s digital signature support, as XAdES provides the appropriate XML schemata to embed timestamps, revocation information and countersignatures within a digital signature on a document. Timestamp and embedded revocation support are two of the chief advantages that Acrobat digital signatures have held over Office for the past several years. Finally enabling this functionality will allow Office to compete with Acrobat on a more even playing field in terms of allowing robust, more auditable signature workflows.

I’m interested in seeing what updates, if any, have been made to the Office digital signature interface to support this new functionality. In current and previous versions of Office, digital signature validation, from a UI perspective, has been abysmal. There has simply been no way to determine *why* a signature is judged as invalid by Office when there are myriad possible causes for such a failure. For example, a signature may be invalid due to an altered document, which is far more of a concern than a signature being invalid due to revocation data being unavailable because the validation was performed offline. These circumstances can lead to different trust levels from the user.

It remains to be seen how well the XAdES support is implemented, but I’ll tentatively state, sight-unseen, that this is at least a step in the right direction.

Dan Kaminsky posted on twitter the following:

http://eprint.iacr.org/2010/006.pdf Is it time to deprecate 1024bit RSA for, say, 1276bit? (2048 has perf issues.)

The link Dan provided is a research paper which reports the successful factorization of the 768-bit number from the original 2001 RSA challenge. I responded to him that NIST had already deprecated the use of 1024-bit RSA in the government, and it was time for industry to follow suit. Since I posted that, I’ve been surprised that a number of people don’t understand the upcoming changes in key lengths and algorithm strengths that have been mandated by NIST. So, this post offers some information about why I can confidently say the U.S. government has deprecated certain algorithms and key lengths.

(more…)

Les Jordan from Microsoft recently wrote a blog post entitled Identity Management: a key to seamless CTMS and EDC. In it, he presents some of the solutions Microsoft is introducing in the identity management space, currently under the name of Microsoft Geneva including the Geneva Framework, and the Microsoft Identity Federation Gateway.

The idea is fairly simple. Many (most?) large enterprises already manage their users and systems using Active Directory.  Geneva allows publishing the components of your Active Directory required for doing identity federation on the Internet.  The publishing is performed in a standards-compliant way (using WS-* and SAML 2.0) and allows it to be used for claims between enterprises.

…the issue of Identity Management, Username and Password proliferation, and cross-company collaboration is an issue that has hindered true (and secure) data availability and collaboration in the Life Sciences industry.  Perhaps now we can get the Identity Management issue behind us and move on.

Whether or not Geneva becomes the one standard way to allow interoperable identity management across multiple enterprises in the life sciences space, it is clearly going to lower barriers between organizations and increase our trustworthiness in digital identities.

According to the IRS:

The IRS has developed six new security and privacy standards to better protect taxpayer information collected, processed, and stored by Authorized IRS e-file Providers participating in Online Filing of individual income tax returns.

These new standards are based on industry best practices and are intended to supplement the Gramm-Leach-Bliley Act and the implementing rules and regulations promulgated by the Federal Trade Commission.

So, what does this mean for the average online tax-filer? It means that the company that you e-file through (TurboTax, efile, TaxACT, etc) will have to adhere to stricter policies and standards regarding the handling of customer information.

Most of these policies seem to be standard precautions from a security perspective. However, I can certainly understand how a provider may be unfamiliar with the risk involved with handling such sensitive information. The 6 suggestions are mostly focused on tightening the security around the provider’s web presence: they call for strong EV SSL certificates (SSL 3, 1024-bit RSA), weekly third-party vulnerability scans, a written privacy policy, CAPTCHA-like capability, an ICANN domain name from a registrar located in the USA, and the prompt reporting of security incidents.

These are all good policies and are definitely a step in the right direction. The only issue I see is that these “standards” are currently optional. Although the IRS suggests that providers follow them, they aren’t required yet. In a way, this defeats the purpose of having them in the first place.

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.