Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

The projects aren’t all done yet, but I noticed that the specification documents that we’d uploaded to CodePlex weren’t getting indexed by the major search engines. (I think that’s because CP hides them behind JavaScript, which is lame.)

So here are doc snapshots as of today. If you’re looking for the CodePlex links, each doc references its respective CP project page.

[Updated links on 5/1/09]

Permalink | Comments (0)

Check out mdbg.

Ever have one of those situations where you need to debug a .NET application on a machine that doesn’t have Visual Studio installed? I stumbled across mdbg this week and couldn’t believe how lucky I was.

Permalink | Comments (0)

This is a shout out to the 16 teams that advanced to the final round of the University of Washington’s 2009 Business Plan Competition. Full list is here.

This is my third year as a judge. Thus far, each year, the BPC competition day rolls around and I think to myself, “Oh gosh, I’m so busy, I don’t have enough time to volunteer,” etc. What a huge mistake that would be! Every year the competition is amazing and includes several teams with big ideas and strong profit potential. I’m reminded that this is the future of the American economy in action, and I’m quite happy about that.

The best part of the whole process? The teams actually listen to judge feedback. It’s totally time well spent.

Notably absent at the competition yesterday? The press. I guess they’d already gotten their quota of good news for the day.

Permalink | Comments (0)

Screenshots at the end of the dev spec, posted here.

The XAML - the pretty version, that is, from the graphic designer - and some Hyper-V WMI code are checked in here.

Permalink | Comments (0)

The above has now been posted to its CodePlex page. Feedback is welcome, either via this blog or via the CodePlex Discussions forum for this project.

Permalink | Comments (0)

Read it here, from Micrsoft’s own Windows Security team. Prominently mentioned are three technology and feature areas where JW Secure has considerable integration experience:

  • Smart cards
  • Biometrics
  • BitLocker (our related work here is still confidential; hopefully we’ll have something public we can discuss in the next couple of months)
Permalink | Comments (0)
Permalink | Comments (0)

Leading up to the RSA security conference, which started yesterday in San Francisco, Microsoft has gradually been exposing its new security marketing strategy to the world. The new strategy is called Business Ready Security (that’s the best introductory link I’ve found so far).

There’s no question in my mind that Microsoft has an unrealized opportunity when it comes to end-to-end security and stealing security and compliance market share from CA, EMC, and Symantec. How will Microsoft start to capitalize on that opportunity? First, by integrating with its main enterprise asset - Active Directory.

All of the scenarios here - endpoint security, email security, network compliance and health, identity management, strong authentication, etc - can and should be managed via Active Directory. It should be the go-to repository for identity and authorization information, and it should be the go-to repository for management and configuration. This is the first key for achieving interoperability across product lines, and for driving down IT deployment and lifecycle costs, which is something that many customers have been complaining that the existing players in the security market (e.g. CA and Symantec) haven’t been doing well. Tight integration with AD for products coming out of Microsoft should just be a no-brainer; if customers don’t have AD installed, make ‘em get it first.

However, there’s a second aspect of AD integration that’s less obvious and that even Microsoft has been getting wrong. It’s one thing to have a single repository for identity and policy information; it’s another thing to have a consistent interface look-and-feel - call it the IT user experience - across every product and tool, for managing that information.

What do IT people think of when they want to manage AD? An MMC snap-in! It’s not always pretty, but it’s what everyone has been trained to use. But look at the management interface for Forefront 1.0. Or for Identity Lifecycle Manager. Those management interfaces are web-based. That’s not a problem in and of itself, nor is the root problem even that not every product uses MMC for management. The problem is that not every product has a consistent management interface.

The customers I’ve spoken with regarding the end-point security market, for example, expect all of the top-tier vendors to pretty much have feature parity. The differentiation is in how easy the product is to deploy and manage.

Along with tight AD integration, a consistent management UX is Microsoft’s best competitive tool in the security market. Don’t make the IT guy learn a new interface for every (or any) product. And if you’re not going to use MMC, consider that you have a huge installed base of those snap-ins already, plus legions of IT people to re-train.

Ok, so, integration with AD is one thing. What’s the second step? It’s a no-brainer: you have to actually ship the new security products - get them developed and ready for the market - and that just hasn’t been happening quickly enough.

When I was staffing the Forefront booth at TechEd last year, several attendees came up to me who had never heard of that brand (i.e. Forefront). When I told them what it is and what it does, a frequent response was, “Oh right - we looked at that, but it’s not yet on par with eTrust,” or etc. Their next question: when is the next version of Forefront shipping so we can take another look? Answer: we don’t know.

Big companies tend to move slowly - they have a lot to lose, lots of cogs to turn - that’s just the nature of the beast. But Microsoft would pose a bigger, more immediate threat to the aforementioned existing competitors in this space if it could turn the “get the products out the door” crank more quickly. Forefront Stirling and Identity Lifecycle Manager 2 both should have shipped last year. If that had happened, the new Business Ready Security realignment would have momentum behind it, along with real credibility, and the buzz would directly influence purchasing decisions. Competitors would be running scared.

Thus, I conclude that there’s huge potential for Microsoft here, but they’ve put the cart before the horse. First step: give the products a consistent management experience. Second step: ship them. Third step: spin up the re-energizing marketing campaign. Fourth step: count the truckloads of money.

Permalink | Comments (0)

See the Cloud Backup project site on CodePlex. There’s a link to the developer specification document on the “Home” page. That doc has a down & dirty Win32-based GUI mock-up that was done using Visio, along with two pretty Expression/WPF-based mock-ups that created from that. Feedback is welcome on that GUI - we expect to start writing the code next week.

Permalink | Comments (0)

A recent cnet blog post, and my comment, got me thinking about the issues surrounding credential sharing and strong identity.

Multi-factor authentication and password replacement technologies continues to build momentum in the market. Examples include smart cards, One-Time Password (OTP) solutions, and even the question-answer systems that are sometimes used in online banking.

New federation technologies are also coming online - examples include the Microsoft Geneva Framework.

What I’d like to see is those two worlds combined. For example, I want to securely store a strong cryptographic identity on my mobile phone. Then I use that identity to authenticate myself to a Secure Token Service (STS), and the STS issues a claims-based token which I can use to authenticate to other services (while not betraying any more information about myself to those other services than is required - that’s one of the key benefits of the claims-based model).

There are some challenges when it comes to federation, though. Suppose company A and company B want to collaborate. They create a document repository and an STS to authenticate users. At that point, the two companies have crossed the first hurdle: they’ve decided to trust each other, to the extent of the collaboration, and they’ve each decided to trust (to whatever limited degree) credentials issued by the other company.

That is, a user at company A may be authenticating to the STS with Active Directory domain credentials, and those credentials would not otherwise be trusted at company B. Outside company A, those domain creds are only trusted by the STS. And, in this scenario, the document repository presumably only accepts tokens issued from that STS (and then only grants access if the user is on an authorized list, etc).

Those are big steps! The key point is that company B has no control over company A domain credentials, and vice-versa. Instead, they exercise mutual control over the behavior of the STS and the list of users trusted by the document repository.

This raises some interesting questions. Would company B be as likely to enter into such an arrangement if the document repository were a pre-existing internal resource, i.e. behind their firewall? Maybe. However, generally, I’d expect not, especially if the repository contents had already exceeded a certain threshold of data that had been stored without external collaboration in mind. In other words, better to make a fresh start with a new process in place to scrub the stuff that gets shared.

But what’s interesting is that I frequently hear talk about sharing credentials across organizational boundaries that don’t have an agreement such as that which would exist between companies A and B in the scenario above.

For example, suppose I have a third-party strong auth applet stored on my phone which I use to sign into, say, eBay. To make things interesting, suppose I work in IT escalation, and that phone was provided to me by my employer. I.e. technically, they own it. Should I really have my personal eBay logon information stored on it?

Now suppose that my employer wants to install their own strong authentication application on that phone. Furthermore, because of the nature of my job, the purpose of that app is to securely store AD domain administrator credentials. Is my employer going to like that there’s an eBay applet on that phone that also has access to those AD creds? No way.

But is the situation different if I bought the phone myself? Yes, but I should still think twice about what can go wrong - what if I have a work password stored on the phone and the eBay app steals it? 

Suppose the credential applets are running on a chip (smart) card instead of a phone. If the card is issued by my employer, should my bank trust it to host their web sign-in applet too? I have my doubts.

I’m all for strong authentication, and for making federation much easier to do than it is today. But credential ownership is a key question, and it’s likely to stand in the way of any assumptions about cost sharing or device reuse.

Permalink | Comments (0)
Newer Posts »