To catch a cracker…

Actually, I'm more interested in deterring and thwarting than I am in catching one (though the latter makes a better movie, no doubt). But, all of these goals benefit from the ability to adopt the mindset, goals, and approach of your adversary. Part of the "Road to RTM" for products here at Microsoft is a period of intense activity that we call The Security Push. This is when a lot of the ongoing security efforts - spec and design reviews, threat modeling, code reviews, and so on, really come into sharp focus and are validated by penetration testing. Penetration testing is where we actually conduct some of the attacks our software is likely to face, and see where we're defending ourselves adequately, and where we need to do better.

We've done a lot of planning and preparation to get to this point, but as always, I'm curious to see what the community thinks about what security means for a version control system. There are some obvious threats - various ways to break in and copy, destroy, or tamper with the versioned data, and attempts to slow or completely deny access to the server come to mind. What else (if anything) worries you when you think about your version control system, and the data that resides within it?

I want to make sure we've got the bases covered, from the obvious and likely to the fairly obscure - the last thing a customer wants to hear when her data has been compromised was "well, we didn't think anyone would try to get at it THAT way..."

In the threat trees we’ve created, where obtaining credentials are required, we’ve called out the ‘valid user turns malicious’ but didn’t go beyond that (ie. did he do it for espionage, pique, revenge – the why doesn’t much matter from this particular perspective). This is an unmitigated threat – there’s not much an administrator can do if a trusted user decides to willfully violate that trust. Windows identities can be quickly and effectively disabled, but that’s still in the realm of manual reaction, not system defense.

You could spend a lot of effort to develop heuristics – consider how credit card companies attempt to identify *potentially* fraudulent activity rather than only responding to reports from the customer, for example. But this would be extremely hard to do effectively in version control, because you simply can’t create a tool that can detect, and prevent, the addition of malicious code (one of the most critical threats) by an authenticated, authorized user. Such a tool can never be 100% effective, and thus would provide more of a false sense of security than a real defense. This is why peer/maintainer review is still a critical part of accepting code from potentially untrusted sources.