Share via

Just because you're paranoid...

  • Article

...doesn't mean they're not out to get you -- more on that in a minute.

First, I apologize to the zero or more regular readers of my blog - it's been quite some time since I posted anything. This hasn't been for lack of things to talk or ask about, more of an issue of budgeting in time to blog about them. I'll do better.

Having said that, back to paranoia. One area of testing I focus on that is not "feature-specific" is security, and I haven't blogged about that so far, so now seems like a good time. If you think "security" is a separate feature, let me know - I don't view it as such, so that might make a good separate topic later on.

As you're probably all aware, the software landscape has changed a lot over time. Security was once an afterthought at best; anyone who disagrees, ask yourself why telnet, and ftp, two fundamental protocols upon which the internet was built, are (usually) authenticated yet transmit their authentication data in cleartext. It clearly wasn't critically important - YET - that such data be better protected than merely not displaying your password on the screen, and perhaps storing passwords in encrypted files.

Things have changed -- firewalled network connections are rapidly becoming the rule rather than the exception. Spam has, for many users, become a majority of incoming mail, rather than a tiny fraction (more on why Spam is a security issue in a moment). Any host connected to the public internet is a target for malicious attacks - if there was ever a time where only certain hosts or networks were worth attacking, it has long past.

<aside>

Spam is a security issue for several reasons -- many spam messages have viruses/trojans/worms/spyware embedded in them or their attachments; other spam messages attempt to trick the recipient into revealing private data (e.g. credit card numbers, or information used for identity theft, or to gain access to their banking or ebay accounts, among others). So, spam is as least as much of a security threat as any worm or door-to-door con artist.

</aside>

Security is of particular interest to me for several reasons. First, Microsoft software is automatically a target for intrusion and/or compromise. The reasons for that 'fact' are many, complex, and (some, at least) debatable, but I'm going to state it as a fact, for now. Second, Hatteras as a source code control and repository system is, by nature, a target for attacks. Whether a given company or group writes software for sale, for their internal productivity, or even to give away, that software is valuable and must be protected from theft, sabotage, espionage, or destruction (or any combination thereof). Finally, experience has shown us time and again that it is easier to build in security from the start, than it is to improve a product's security after the fact. Given that we're working on the initial release of Hatteras and the rest of the Visual Studio Team System, it's very important that we think about, plan for, and build a system that's as secure as possible the first time around, or we and our customers will pay the price down the road. Mangle it badly enough, and you won't have to worry about the 'customers' part of that, because there won't BE any.

I suspect security, as it applies to software in general, and to VSTS and Hatteras specifically, will be a recurring topic for me over the next few months. Given that, I'd like to start with a question to gauge interest and help me focus on topics that will be interesting and useful:

When it comes to source control, what does "security" mean to you?

I'm hope there's a couple "flavors" of response, but don't let these stop or limit you: Types/vectors of attacks, likelihood of attacks, detection and mitigation of attack, and last (but not least), the cost of security.

I'll end (for now) by answering my own question and asking a few specific follow-up questions/requests.

To me, security for source control means, mainly, ensuring that the source control system is reliable and trustworthy to its legitimate users. This means that only authorized and authenticated users can read and/or alter the state and contents of the repository. It means that malicious attempts to access, alter, hinder, or destroy the repository are detected, reported, and thwarted. It also means that the source control system provides these capabilities without an undue additional cost in terms of additional hardware, software, or staff.

As far as answering my question yourself goes, consider the following:

  1. Has your source control system ever been attacked?
  2. How did you find out?
  3. Was the threat external or internal?
  4. Was the threat technical, social, both, or something else?
  5. What did the attack attempt to accomplish? (code theft, code injection, deletion, etc.)
  6. Was the attack successful?
  7. How did you respond to the attack?
  8. What was the cost? This might be time, money, lost data - whatever way you view the "cost" to your company or team.
  9. If the attack was successful, or unsuccessful but disruptive, what could have reduced or prevented the severity of the damage/disruption?

As I hinted before, this is a complex and often lively subject, even if we apply a fairly narrow filter by framing it in the context of source control. I'm interested in it, and interested in the experiences and feedback of "y'all" for a fairly simple reason - the more we know about what "security" means to you, the more likely we'll be able to deliver a product that meets or exceeds your expectations.

I hope most of you can say "no" to number 1, and the rest of the questions become pretty much academic. But I know that it won't be "no" for everyone, and I suspect such attacks will increase in the future.

Comments

  • Anonymous
    September 06, 2004
    ;-) Attacked? LOL ...

    Sometimes only lazy person cannot access corporate sources. I know at least one company who has CVS server accessible from Internet using semi-anonymous access. This company develops not toys for kids - but software for banks.
    Decide everything yourself.

    I think that Source code and product documentation is most valuable asset that Software companies has. Servers/Computers/Laptops/office building are nothing compared to source code.
    So? If you company buys intruder/fire prevention system - why your company does not use any technical measures to keep source code secure?

    I think that SCS security subsystem must be easy configurable and allow plugings to be installed.
    For example IP address/date-time restrictions, active monitoring and auditing, cryptography checks for check-in/check-outs, bulk-access limitations.
    Or features like a non-copyable view-only source code access by proving a non-scanable picture instead of plaintext.
    Or source code watermarking to be able detect leaks if any.
    Or ... Add your own feature ...

    Source code security is something that every CEO/CIO/manager must think 25 hours per day / 8 days per week/54 weeks per year/ two lifetimes ;-)
  • Anonymous
    September 07, 2004
    Good points.

    Your comment about servers/computers/laptops raises an interesting aside, though. It's not just the server that has to be secure, but the clients that access it as well. If a malicious user can compromise a client, he gains at least read, and quite possibly write, access to the server as well.

    Of course, there are ways to mitigate this. Among the most basic is staying with authenticated/authorized users (as you alluded to) - if a machine is stolen, you can quickly lock out the compromised user's account until you can change his password, etc. Not sufficient by itself, but it IS a layer.

    Compromised clients is one thing; but at least they're likely to leave a back-trail after the fact. Compromising the server, or (if possible) modifying the server contents without leaving such a backtrail is naturally a much worse situation. It's a classic example of why security is often thought of as "links in a chain" in that it's only as strong as the weakest link.

    After all, limiting access to clients who are authorized and authenticated won't do you much good if an attacker can remotely gain admin access to the server via an OS or SQL server exploit, right? So, we have all the security challenges (and their associated defense strategies) of the OS, the application server technologies (e.g. SQL server, IIS), And those that apply to the source code control system itself.
  • Anonymous
    September 27, 2004
    Not sure where to find answers, so I post it here. Hope you can pick it up.

    I just installed VS 2005 beta refresh, testing the Source Control feature.

    My SourceDepot is extremely slow that it's not usable at
    all.
    I tracked down to the problem, that when I get latest of a
    file, a prc_get is called.

    I profiled this SP. It took 47 seconds for a file! run
    about 12 seconds without a profiler.

    Then I tracked into inside of the SP (it's envrypted, so I
    can not get more information.), it's trying to call a
    function, called:

    func_descendantsinclusive

    This function is fast, but it gets called more than 5000
    times inside that SP.

    What's story here? Is this a bug that needs to be fixed or
    I got a bad scripts?

    SCC is what I want most from Microsoft. :-) Now Hatteras has a problem, I can not continue my vs.net 2005 testing. :-)
  • Anonymous
    September 28, 2004
    The comment has been removed
  • Anonymous
    September 28, 2004
    The comment has been removed
  • Anonymous
    October 01, 2004
    Hello,
    Thanks for the reply.
    I have a 2.4G CPU + 640MB ram, SCSI HD.
    I have a SQL 2k installed before, I installed SQL 2005 above it (accidently), it overrides my previous SQL server (DANNN). :-)
    I reinstalled TEAM system, still the same problem. Actually because the SQL server is so slow and busy (CPU constantly hits 100%), and the TEAM server becomes unavailable in the middle of an operation. Which means if I get 20M source code/images, I will never succeed, as it always out of service.
    I start to suspect my SQL server, since I feel it should NOT hit 100% CPU no matter what. But the query of prc_get definitely has problem, as I run the prc_get myself in query analyzer caused so many calls to one function. Something is wronf. :-)

    I am very serious of the Source Code control, now it gives me too much headache. Maybe I can download your latest bits? :-) I am MSDN subscriber.

    Thanks,
    Calvin
  • Anonymous
    October 02, 2004
    Another question:
    Regarding branching in Hatteras, I didn't see any detail information. I want to know whether it's a copy or just a file link. In VSS, it's a copy action, which I think is not good. I'd like a perforce style braching, i.e., only the file link or folder link is copied.

    Thanks for the help, I found here becomes my primeayr place to solve all my hatteras problems. :-)

    As to my previous performance question, I am wondering maybe I have to uninstall SQL 2005 and reinstall it? (Actually I did it already once). I am just not sure how to make a clean installation on a win 2003 machine while I aleady have a SQL 2000 on it.

    One thing I really don't like regarding Hatteras is its requirement, it requires: .NET Framework 2.0 which is not a big deal, but it also requires Sql 2005, which I feel is unreasonable. And it doesn't have a VS 2003 plug in, not sure whether you guys working on it or not. SQL 2005 is only in beta 2, dev edition, I am not sure that's a problem or not. Why SQL 2000 won't fit anyway? I guess it's a Market strategy? Using Hatteras to boost SQL server and Whidbey sale?

    Thanks,
    Calvin