Adding Usable Security to the SDL

Adding Usable Security to the SDL

  • Comments 2

Adam Shostack here.   Lately, I’ve been focused on how we bring the engineering of usable security into the SDL.  When I say usable security, I mean that for those times when we need to ask a user for input on something only they know.  (For example, are you connecting to a coffee shop network or your work network?  Are you trying to print to a printer you’ve never used before?)  We want to ensure that those questions enable users to make security decisions in accordance with their preferences and goals.  So if you’re coming here to read about what’s made it into the SDL, stop now.  But if you’d like some insight into how we update and improve the SDL, and some insight into something we might add, read on.

Remember that, at Microsoft, the SDL is a collection of proven practices that integrate effectively into the software engineering process.   One of the key elements there is that the practices are proven to be effective without an expert in the room.   We know from our Experiences Threat Modeling at Microsoft that

rolling out a mandate too early can have unfortunate consequences, and we dread the idea of doing that again.

So as we think about usable security engineering, we’ve made some great steps forward.   We have guidance that’s in use in some of our product teams.  We’ve surveyed the engineers who are using it and they find it effective at producing better interfaces with less debate or churn.  What we don’t (yet) have is really crisp entry and exit criteria or tool support, and those are important gates to bring something into the SDL.  

All of that is background and context for some work that we’d like to share for your use and feedback.  It’s a pair of new mnemonics for important things to consider as you’re building security user experiences.  We hope you’ll agree that user interfaces should be NEAT:

  • Necessary to get the user’s input
  • Explained in a way that the target audience will understand
  • Actionable in that the user can realistically make a decision on what you’re asking of them
  • Tested in both benign and malicious scenarios

For more details, and even a second mnemonic, we suggest you look at the two pager by myself and my colleagues Rob Reeder and Ellen Cram Kowalczyk.

Click here to download a high-resolution PDF of the cards and the NEAT whitepaper.

All that said, we think this is pretty NEAT, and we wanted to share it and ask for your opinion and feedback.  Please give us your thoughts in the comments, or by email to tux@microsoft.com

 

Comments
  • Without reading your paper, I can say that you had me at NEAT.  

    The only thing I would add would relate to situations where there is some dialog being responded too and there may need to be a way for progressive disclosure of more detail if it is something that an user happens to want, perhaps for power-user or on-site support troubleshooting, or even to capture forensic information for a bug report (if there is not an easier way to get that).

    OK, now I'll read your two-pager.

  • Hi Orcmid,

    Thanks for your comment, and we're glad you like it! We have general guidelines about the use of progressive disclosure--do you think there's security specific content that would be useful there?

    Adam

Page 1 of 1 (2 items)
Leave a Comment
  • Please add 4 and 6 and type the answer here:
  • Post