In talking to Peter last week, I asked him a question which we realized was pretty much impossible to answer:

How do you measure security strength?

That is, we know that an 8-character password with upper-case letters, lower-case letters, numbers, and special characters is definitely stronger than a 6-character password with only letters and numbers. But how much stronger is it?

Unfortunately, that’s incredibly hard to answer.

Of course, we know that there is no such thing as bulletproof security; if an attacker has sufficient time and resources, any security measure can be surmounted. Passwords can be broken, encryption can be cracked, etc. Given that the goal of security is to keep an attacker out, perhaps the most direct way to measure the effectiveness of security is, “How much effort will it take for the attacker to defeat it?”

This can be expressed in a fashion rather similar to programming complexity, using “Big O” or “asymptotic” notation. Which is useful because it communicates a key concept: multiple layers of poor security are not equal to one layer of good security. One might be inclined to think that, for example, requiring three weak password authentications is better than just one weak password authentication. But, while the difficulty in breaking one password is O(n), the difficulty in breaking three passwords is just O(3n) – which is, asymptotically, the same thing!

For real security improvements, the cost of defeating the security must be a higher order of complexity – it must be O(n log n), or O(n^2) or the like. That’s a real improvement over O(n). In the real world, this means adding levels of complexity to a password, requiring a hardware token, or adding in biometric identifiers.

But even expressing security in terms of complexity won’t really work: it doesn’t account for the myriad ways which attackers might use. Keeping passwords as an example, you may require strong passwords which truly are an order of magnitude harder to defeat than simple passwords… but if you’re not using good encryption for transmission, you’re no more secure. And even if you’re using good encryption, a wrench can still get the password (not that I advocate this method, of course, and especially not when my kneecaps might be involved!)

So, realizing that there are no easy fixes, and that attackers can be resourceful, how do you measure the level of security?

Well, so far the best idea I’ve seen has been to create a composite score based on your vulnerability to various attack vectors, giving weight depending on the expected likelihood of a given vector. Yes, that’s right: benchmarks.

And ultimately, you don’t want to get too hung up on the score. With benchmarks, you can usually manipulate to get whatever score you want. It’s just a number; the question is whether you’re secure. So use a metric, or pick a team that uses a metric, which you believe realistically reflects the threats you expect to see. And whatever the answer you get, the question is binary: “Am I secure enough?”

OAuth is a protocol that lets applications request data or privileges you have on a remote service without you having to provide your credentials for that service. A classic use case for this “valet key” system is contact import – you can let a site load your address book from Gmail without giving that site your actual Gmail password. Twitter recently required that any third-party applications using their API must authenticate using OAuth.

Twitter’s implementation is based on OAuth 1.0, which was finalized in April but has been in development for several years and is already widely supported. But work on a new version is now under way, and Facebook has already implemented one variety of the draft specification for applications that connect to their service. OAuth 2.0 currently defines specific flows, or client profiles, for handling authentication: Web Server, User-Agent, Native Application, and Autonomous. The first two are most commonly used for web applications, and implementations of the third may end up being quite similar.

The process for most clients involves three broad parts. (Note that “client” in this context refers to the application seeking access, not the person using the application.) The first involves user authentication. For a web-based service, this will often mean ensuring the identified user is currently logged in and then asking for their permission to enable access if they have not previously granted it. Second, the client has to authenticate. In other words, the client making the request has to prove it is the same application that the user granted permissions to in the first step. If both of these steps complete without error, the client is given means to access the protected resources, typically with a temporary code known as an access token.

The specific details of how these steps happen depend on the client profile used. Facebook’s standard Graph API authentication is an example of the Web Server flow. When first requiring access to private user data, a third-party application will forward the user’s browser to Facebook’s authorization server. The request includes a public code identifying the application and a URI under the application’s control. Facebook prompts the user for the permissions and (if they are granted) redirects the browser to the provided URI, along with an authorization code. The client then makes a request directly to Facebook which includes this authorization code and a secret code identifying the client. Facebook then sends back an access token, which is used to authenticate specific access requests for the duration of the session.

The User-Agent profile differs in that it relies on a user-agent’s same-origin policy rather than a client secret for authenticating the client. This process provides OAuth capabilities for JavaScript-based applications that do not have a server-side component and thus cannot ensure identifying codes are kept secret.

Simplicity was a major factor in creating OAuth 2.0, and thus several parts of OAuth 1.0, such as signatures and nonces, no longer apply. However, OAuth 2.0 requires transport-layer security of TLS 1.2 at minimum (as of draft 7) for the interface used to request and receive access tokens. The spec also recommends that secure channels be used for other parts of the process. In Facebook’s implementation, all server interfaces are accessed via HTTPS addresses.

From a security perspective, OAuth is a good step in that it discourages the anti-pattern of one application requesting a user password for another application. It can also protect users in other ways; for instance, if someone intercepted the authorization code for a Facebook application, they would not be able to use it for data access without also obtaining the application’s client secret. However, OAuth only addresses particular issues with third-party access and should not be considered a silver bullet for security. As an example, access by Facebook applications vulnerable to cross-site scripting may still be hijacked once the application has been authorized.

While OAuth 2.0 is still in draft status, Facebook’s deployment makes it in wide use already, and we’ll likely see many more implementations in the months to come. The description above should help you understand the basics of how OAuth 2.0 works, but if you’re interested in further details, check out the full spec and Facebook’s specific authentication guide.

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.