Balancing Security and Usability

Balancing Security and Usability

  • Comments 14

I'm often tempted to write about viruses and what I think the next "innovation" might be, but then I get scared that I might get put in jail (or deported) should any of my ideas ever see the light of day. (Not that I think the virus writers need any help coming up with new ideas, but you know what I mean). Anyway, one thing I have been meaning to talk about is how I approach this problem for VSTO solutions, and since Raymond just blogged about some new shenanigans in this area I thought I'd do it now.

Aside: I say "how I approach this problem for VSTO," but it's not as if I am the only person thinking about this problem at Microsoft. Many smart people are thinking about it both from the security and the usability side of things, and we have spent (and will continue to spend) a metric boatload of time going over many different ideas and designs for the secure sharing and deployment of Office solutions. Hopefully, together we will come up with something that strikes the right balance between security and usability and lets the good people get their work done while keeping out the bad people. But this is my blog and I don't want to speak for any other people. I know what my motivations / goals / guiding principles are, and I'll try to share them with you.

I have a very simple set of metrics for deciding if a method of code installation meets my personal "it's secure enough" bar -- it has to be harder than double-clicking on an e-mail attachment, and easier than copying and pasting the source code into a new VBA project. (I'll probably intermingle references to VSTO and VBA here because whilst I work on VSTO, it is not an end-user accessible technology whereas VBA is).

Let's look at the current "state of the art" in viruses. Most new e-mail viruses like MyDoom rely on user interaction to spread (although they are often incorrectly termed "worms" -- true worms like Blaster require NO user interaction). Running MyDoom "apparently" (I've never done it ;-) ) takes about three atomic actions:

1.       Open the attachment

2.       Accept the security warning

3.       Open the EXE inside the attachment

(You could say that the first two are one and the same, and I'll argue for that case below, so really there are only two user actions).

Clearly requiring only three (or two) basic user actions to go from "clean machine" to "virus infected spam bot zombie" is a little too easy. Now let's look at the typical "Linux virus" approach as applied to VBA: you get an e-mail message with some source code in it, and instructions similar to the following:

1.       Open Microsoft Word

2.       Hit Alt+F11

3.       Copy the code below into the clipboard

4.       Paste the code into the VBA editor

5.       Hit F5

Now five user actions isn't a huge step up from three, but to most users all but the first step is unfamiliar, and it is very easy to mess up step #3 if you copy too much or too little from the e-mail into the VBA editor. The point being though that any security mechanisms we put in place that require more than five user steps are a waste of time -- the hackers will just go with the copy-the-source-code route, which will still be easier for the end user than installing "legitimate" software through the imaginary 10-step "secure" process.

So we want a process that is harder than two trivial actions, but easier than five non-trivial actions. Time to focus our energies!

One important thing to note is that there are two entities involved in software distribution -- the publisher (developer) and the installer (end user). In an ideal world we would want to make the distribution experience as seamless and easy as possible for both parties, but in a hostile, broadly-connected world that doesn't cut it any more. Nevertheless, we can still try and simplify things for the developer; there's no point in making it really hard to develop solutions while keeping the barrier for installing them very low -- the bad guys don't mind doing hard work to write their viruses, and the good guys will give up and go do something else if it's too hard (and thereby not reach their full potential). And the end users will happily click on the attachments until the cows come home.

Instead, we want to make it as simple as possible to develop solutions, as simple as possible to install solutions from the "right" people, and virtually impossible to install solutions from the "wrong" people. Unfortunately, figuring out who is good and who is bad is the one thing in this equation that software alone can't do. Once you know who's naughty and who's nice, it's a Simple Matter of Programming:

if (publisher.Diposition == Disposition.Good)

  InstallAndRunCode()

else

  CallTheFBI()

But the burden of figuring out who is good and who is bad falls on the user of the computer (or perhaps their administrator). And, as history has shown us, users are less interested about who sent them the solution than they are about what the solution claims to do. It doesn't matter if an e-mail comes from a random e-mail address with a random subject line and some random text inside it -- if there's an attachment entitled BritneySpearsNude then a significant number of users will open it and disregard any warnings. Even if the attachment is DoNotOpenMeBecauseIAmAVirusAndWillDeleteAllYourFiles, some people will open it just out of curiosity or because they think it is a joke.

Another aside: Modal warnings are horrible. It's what we use today, but they are truly useless. I open BritneySpearsNude from my inbox. Clearly my intention is to open the attachment, but my e-mail program helpfully asks, "Are you sure you want to open this attachment?" OF COURSE I WANT TO OPEN IT! I would not have opened it if I did not want to open it!! Stupid computer!!! Stupid Microsoft!!!! Now where are my pictures of Britney????? And where have all my documents gone?!?!?!?!!!!!!

It also doesn't help that you get redundant dialogs. I open a Word document from Outlook, and it tells me "Hey, y'know this could have a virus in it, don't you?" even though the Word document may not have any macros in it. Then it opens in Word and (depending on my security settings and whether or not the document really has code in it) Word might warn me again. Now there's a good reason for this -- we call it "defence in depth" -- since either of the two mechanisms could fail. Outlook is being ultra-paranoid: maybe you have your Word security settings at "Low," so all macros can run. Maybe there's a problem with the way Word checks for macros (we have issued at least one patch for just this problem in the past) and it won't protect you from this particular virus. Maybe there's a buffer overflow in the normal parsing of Word documents that doesn't rely on VBA code to perform the exploit. You get the idea.

But of course the plain and simple truth is that Outlook is dumb and it just knows that .doc files need to prompt the user before being opened. It doesn't know why, it just follows orders. Now if we could have Outlook, Word, Windows, Windows Update, Office Update, the virus scanner, the virus scanner's update server, the firewall, and maybe a managed PC service provider all working together behind the scenes, maybe we could do away with the prompts altogether (or at least only show one prompt, and only when it was really necessary). But that's a pipe dream right now.

That's our goal -- run good code and block bad code. But we can't really get there without massive user education and a lot of infrastructure. So our next-best approach is to make it hard for end-users to run solutions. The idea here is that if it's too hard to open the BritneySpearsNude attachment, then most people will give up and get on with their job. At the same time though, if it's too hard to open Budget.xls with some cool Excel user-defined functions (UDF) in it, then people won't be able to get on with their job.

Stalemate.

Rant: I just tried looking for a good hyperlink to Microsoft documentation on UDFs in Excel. Could I find one? I'll leave that as an exercise to the reader (thankyou Google). Anyway, when we did customer research on how people use VBA with Excel, we found that most people don't know half of the things they can do. Workbook events -- what are they? Worksheet functions -- what are they? We have all these cool technologies and nobody knows about them. We suck. We need to do much better in the future, both in terms of increasing discoverability and in terms of documenting this stuff. And people say there's no reason to keep building new versions of Office!

So anyway, back to where we left off the conversation... if it's hard to install all solutions, then it's equally as hard to install the good ones as it is the bad ones (remember, we can't tell the difference between them). So the next best thing is to front-load all the pain of installing good code and require some kind of pre-arranged client setup (or, in the case of an enterprise, perhaps some domain-level policy) that will help to ease the installation of good code.

In this case, maybe we can require more than five non-trivial steps to setup the machine as long as those steps are done out-of-band and in a way that makes it very clear you should not do them as a normal part of your daily computer use. After all, you only need to do it once, and then all the good code runs with little or no fuss. You might note that not only am I a big fan of killing modal dialogs, I'm also a big fan of "out-of-band" activities for security-related actions. Don't let somebody trust a piece of code while they are in the process of trying to run it! Force them to have thought about it before hand. That is what policy is all about -- having a set of well-thought-out, generally applicable rules, and sticking to them. Don't make ad-hoc decisions at the worst possible time!

And I'm going to stop here. Not because I don't have anything more to say -- I have lots to say -- but because this entry is already quite long, and after all, I only ever said I'd tell you how I approach the problem, not how we solve it. We're a long way from having a good solution to this problem at this point in time, although we're all full of ideas.

Final aside: Regular readers will know I'm a huge fan of the Pet Shop Boys, but I'm also a big fan of Howard Jones. I think his song Someone You Need from the Perform.01 or The Very Best Of CDs is one of the most romantic songs I've heard in a long while. The lyrics are very simple, but it gets to the heart of the matter. Thanks Howard!


  • "So anyway, back to where we left off the conversation... if it's hard to install all solutions, then it's equally as hard to install the good ones as it is the bad ones "

    Funnily enough, what about the coming Windows Installer 3.0 that will, like older versions, require admin rights and a reboot. How having troubles installing an installer is in any way helping gain back confidence over third party software?
    Isn't the awful end user experience related to installing an installer before installing the app adding up to the mess of clicking OK on highly technical prompts without bothering anymore?

  • I don't know much about the Windows Installer, but installing a system file always requires Admin rights (as well it should, just like installing critical updates). You could argue that there needs to be a per-user install of an installer that can only install per-user applications, but most things that need "Installers" these days do so to register machine-wide resources like COM objects or Shell handlers. ClickOnce in Whidbey is trying to address this though and provide per-user, non-impactful installs of managed code solutions.

    Silently installing a new system component as a normal user is about the worst possible thing we could do, and my main point was that up-front installation *should* be hard, but that subsequent running of previously-vetted software should be a relatively pain-free experience.

    But that's just my opinion; it makes the desktop somewhat more secure, but it also make it unusable for the vast majority of our customers. It's no use having more secure technology if people stick to the older stuff because it's significantly easier to use.

    So we will probably continue to prompt users for the forseeable future, because there's nothing better we can do right now.

  • "ClickOnce in Whidbey is trying to address this though and provide per-user, non-impactful installs of managed code solutions."

    If I refer to the PDC talks, ClickOnce is NOT a replacement for MSI. So it's useless for a lot of scenarios and, as implicitely mentioned, only adds dependencies (IIS is required for instance to deploy your vs project, serve the manifest file, ...). I wonder how is this going to help simplify things. ClickOnce is for Longhorn, essentially, since assemblies and run-times have introduced a whole new can of versioning problems.


    "but installing a system file always requires Admin rights (as well it should, just like installing critical updates)."

    Since pretty much anything significant can be labelled as system objects, and you say this in turn requires elevated privileged, this means it is not possible to install software on Windows without being a local admin, threby reducing the actual freedom of end users. Fine.


    "Silently installing a new system component as a normal user is about the worst possible thing we could do"

    This is what customers want, unfortunately. Indeed, why should they bother the install pages when all this stuff shows is technical things and an horrible EULA which one has to agree anyway. I mean, there is no sandbox anyway, so why is silent installers so much frightening? Or, does explicitely showing a UI and getting the user to check the EULA box allows the publisher to install and damage the target machine without being liable, as you seem to imply?

    "need "Installers" these days do so to register machine-wide resources like COM objects or Shell handlers."

    The shame here is how little has Microsoft been able to virtualize the registry, make it local to a single app only, and thus allow COM components, shell handlers and so on to work on restricted spaces. VMWare did it. You are just too lame to acknowledge you are lagging behind your own technology, or in other words that you have no clue of what customers are doing with software outside and what they expect from it. Hint : they want to get their work done, and couldn't care less about all your crappy technicalities.


    "But that's just my opinion; it makes the desktop somewhat more secure"

    Just in time for a .NET virus to come up and blast the "secure .NET shit" PR Redmond has boasting so much about.


    "So we will probably continue to prompt users for the forseeable future, because there's nothing better we can do right now."

    And you'll keep getting customers angry at you.










  • Stephane, you have no argument from me that we need to do better. And hopefully things will get better over time. One of the things .NET has been trying to do *is* to move away from the registry and other such things that require "impactful" installs.

    Talk to Rob if you want to know more about large scale deployments:

    http://weblogs.asp.net/robmen/

    A normal user CAN install software on their machine, IF the software is written to support the scenario. There is such a thing as per-user COM registration, but nobody uses it.

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/per_user_installations.asp

    We'll have to agree to disagree on the "silent install of system components as normal user" point -- if you really want a normal user to be able to replace core OS components without any warnings, we're not talking the same language.

    http://blogs.msdn.com/ericlippert/archive/2003/10/18/53241.aspx

  • "Talk to Rob"

    I have read every single posts from him already, and I am not sure what I am supposed to think about an installer plumbing that :
    - has several flaws in its design (as the weblog explains)
    - requires users to install the installer (and consequently reboot) before installing someone's app. It seems that you guys forget that the setup is the first impressions when installing software, and it'd better be working well.

    By the way, have already given feedback to other people about unsupported MSI scenarios, including "runas non-admin profile".


    "A normal user CAN install software on their machine, IF the software is written to support the scenario"

    Unfortunately, deployment is not a given output from the development tools. Deployment is ad hoc and thus prone to all possible surprises. The irony in this is that it tends to sanctuarize machines with MS-only software installed on them, or in other words the bad reasons inflicted by means of PR (security, bla bla bla) on the fact there is no question that installing/reinstalling IE is good, while installing any alternative browser is bad. This shows the limits of trying to back things, like useability, with technical claims...



  • No argument; we need to do much better here, and better tools for the developer is one way we are moving forward (ClickOnce support in Visual Studio "Whidbey" for instance).

    But security and usability are at *polar opposites* here, which is the thing I was trying to get across in this blog.

    Can you go into a bit more detail about what your "installing any alternative browser" comment means?
  • I assume (based on some basic Googling) that this is your blog:

    http://www.arstdesign.com/BBS/BulletinBoard.php?qs_id=1480

    You raise some good points but unfortunately monolithic installs of applications have at least one very big problem:

    Assume there is a (security) bug in a shared piece of code, and the bug needs to be fixed.

    * If the bug is in a shared DLL, you fix it once.

    * If the bug is compiled into every application, each vendor has to fix it individually.

    Each approach has its ups and downs, but we've seen with things like SQL Slammer that the second approach just doesn't scale.

    I'm sure I've seen other MS bloggers talk about this very problem; it's not an easy one to fix (there is no silver bullet...)
  • Actually the latest viruses (can't remember the name, might be one of the Bagle variants) has a password-protected ZIP file attached to the email, with the password in the email's text. So there _is_ a five-step process:

    1. Open the attachment

    2. Accept the security warning

    3. Find the password in the email and copy it

    4. Paste it into the appropriate password prompt box

    5. Open the EXE inside the attachment

    The fact that this is spreading speaks volumes for the general lack of attention of a lot of users.

    The trouble is, computer users are like BMW owners (in the UK, at least). The equipment is mostly owned by their employer - so they don't care if anything bad happens to it, or anyone else, because they're not liable.

    (Speaking after having a BMW behind me on a motorway at 100mph, honking at me to get out of the way, when overtaking a car transporter that was overtaking a lorry...)
  • You're absolutely right of course. I don't know how successful the latest ones are compared to the earlier ones. It just makes our lives harder...

    I don't think people have a lack of attention though. They're just trying to be good citizens and follow orders (most of the e-mails claim to be security patches or fixes from their ISP) and we can't expect users to be reading BugTraq and know what viruses are.

    Especially since computers have been romanticised by the popular media as these wonderful benign objects that can do us no harm...
  • But why does outlook, word and (maybe) excel need this ability to run scripts/macros. The majority of users - especially home users - do not require this level of functionality.

    Those that do require it - companies/organisations have the resources to instruct their employees and monitor traffic thereby theoretically stopping the problem.
Page 1 of 1 (14 items)