Slashdot Mirror
Security and Usability
ewuehler writes "I don't think I've ever heard a security application, be it a consumer anti-virus application or an enterprise IPS application, described as "user-friendly" or "easy to use". When I read the title of the O'Reilly book Security and Usability: Designing Secure Systems That People Can Use, I took the bait and requested a copy for review. The title could also double as my current job description, so I was equally interested from a "job education" point of view. The book is a collection of (mostly) academic articles, grouped in sections and chapters. Each article/chapter is written by different authors; from Bruce Tognazzini who founded Apple's Human Interface Group to Blake Ross of Firefox fame to names previously unknown to me. Read on for ewuehlers' review.
Security and Usability
author
Edited by Lorrie Faith Cranor & Simson Garfinkel
pages
714
publisher
O'Reilly
rating
8
reviewer
Eric Wuehler
ISBN
0-596-00827-9
summary
Designing Secure Systems That People Can Use
Along with the variety of authors, their backgrounds are equally diverse. The majority of the articles come from academia, with a few corporate names and open source authors. While not exclusively US authors, the majority of the articles come from US institutions. Generally, I would expect the "new author every chapter" approach to be a distraction, but the editors have done a good job at grouping the articles and cross-referencing chapters where appropriate. However, I did not find this a cover-to-cover read, the book lends itself well to "flipping and skipping" around.
The editors claim the goal of the book is "first for researchers in the field of security of usability, then for students, and finally for professionals." While I fit in the "professionals" category (not a term I'd use, but I had to pick one of the three), I found the information very helpful and educational with respect to my current job. With a majority of the chapters coming from an academic perspective, there is room for debate and interpretation of the conclusions. For example, several chapters discuss the fallibility of passwords, making it obvious the issue of password security is not just simply whether or not to write them down.
The book is divided into six parts. The first, Realigning Usability and Security, introduces the premise of the book. These five chapters discuss the importance of usability when designing security applications. It is well known that the human element is "the weakest link in the chain" of system security. For example, "Kevin Mitnick revealed that he hardly ever cracked a password, because it 'was easier to dupe people into revealing it' by employing a range of social engineering techniques. He points out that to date, attackers have paid more attention to the human element in security than security designers have." The implication being the less usable the security, the less likely it will be used correctly, no matter how good it actually is. The chapters go on to describe different processes for designing usable secure systems and applications.
The Authentication Mechanisms section discusses the usability requirements around passwords and other authentication techniques. The information in this section dealt more with implementation than theory as compared to the other sections. The expected chapters covering the prevailing forms of authentication; text passwords, challenge questions, graphical passwords, and biometrics are there. I found most interesting the chapter Identifying Users from Their Typing Patterns. This refers to "keystroke biometrics" which "seeks to identify individuals by their typing characteristics." The concept has been around for a while and first suggested for identification in 1975. (Random fact I found interesting, it finds its roots in 19th century telegraph operators who could often identify each other by listening to the rhythm of each individual's Morse code keying pattern.) Despite the fact that the concept has been around for quite a while, it does not seem to appear much on the authentication mechanism radar.
Secure Systems is the "make or break" section covering the secure user experience. These chapters cover things such as fighting "phishing" at the user interface, making PKI easy, and "deleting" files vs. really deleting files. One of the more interesting chapters looks at security tools and practices based on ethnographic field studies. While ethnography (the study of customs of individual peoples and cultures) initially does not sound like a "security or usability" issue, it is used (and the author claims quite effectively) to understand "the work practices of computer users in context, informing the design of computer systems to better suit their needs."
The section Privacy and Anonymity Systems contains a chapter discussing Google's Gmail privacy policy with respect to "informed consent". For the most part, the authors give Gmail high marks, with the privacy concerns rooted in differing definitions of "privacy". For example, if you believe that content-targeted advertisements should require the consent of all parties involved, you (in sending an email to a Gmail user) have not consented to the targeted ads the recipient sees. The chapter describes two other cases of informed consent and presents a list of ten design principles based on the information. Another chapter discusses leveraging social processes for managing browser cookies. The concept being when a cookie is saved stored, it will provide you aggregate community data such as X percent of the people visiting this site blocked the cookie. One obvious benefit is the ability to educate "less knowledgeable" users about "good" cookies vs "bad" cookies.
The remaining sections discuss usability of products, for which the chapter titles are description enough. Overall, I found the book useful. The variety of authors and subject matter made it easy to skip around and choose what piqued my interest at the time. Along with the academic feel of the book, each chapter is generally descriptive enough to get an idea as to what subject matter will be covered. While the book's target is "researchers and students" first, as a "professional" working for a security company, I found it helped me better explain the pros and cons of these topics to the less technical people I work with every day. I'd recommend it to anyone involved with the usability of security applications and systems."
You can purchase Security and Usability from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Along with the variety of authors, their backgrounds are equally diverse. The majority of the articles come from academia, with a few corporate names and open source authors. While not exclusively US authors, the majority of the articles come from US institutions. Generally, I would expect the "new author every chapter" approach to be a distraction, but the editors have done a good job at grouping the articles and cross-referencing chapters where appropriate. However, I did not find this a cover-to-cover read, the book lends itself well to "flipping and skipping" around.
The editors claim the goal of the book is "first for researchers in the field of security of usability, then for students, and finally for professionals." While I fit in the "professionals" category (not a term I'd use, but I had to pick one of the three), I found the information very helpful and educational with respect to my current job. With a majority of the chapters coming from an academic perspective, there is room for debate and interpretation of the conclusions. For example, several chapters discuss the fallibility of passwords, making it obvious the issue of password security is not just simply whether or not to write them down.
The book is divided into six parts. The first, Realigning Usability and Security, introduces the premise of the book. These five chapters discuss the importance of usability when designing security applications. It is well known that the human element is "the weakest link in the chain" of system security. For example, "Kevin Mitnick revealed that he hardly ever cracked a password, because it 'was easier to dupe people into revealing it' by employing a range of social engineering techniques. He points out that to date, attackers have paid more attention to the human element in security than security designers have." The implication being the less usable the security, the less likely it will be used correctly, no matter how good it actually is. The chapters go on to describe different processes for designing usable secure systems and applications.
The Authentication Mechanisms section discusses the usability requirements around passwords and other authentication techniques. The information in this section dealt more with implementation than theory as compared to the other sections. The expected chapters covering the prevailing forms of authentication; text passwords, challenge questions, graphical passwords, and biometrics are there. I found most interesting the chapter Identifying Users from Their Typing Patterns. This refers to "keystroke biometrics" which "seeks to identify individuals by their typing characteristics." The concept has been around for a while and first suggested for identification in 1975. (Random fact I found interesting, it finds its roots in 19th century telegraph operators who could often identify each other by listening to the rhythm of each individual's Morse code keying pattern.) Despite the fact that the concept has been around for quite a while, it does not seem to appear much on the authentication mechanism radar.
Secure Systems is the "make or break" section covering the secure user experience. These chapters cover things such as fighting "phishing" at the user interface, making PKI easy, and "deleting" files vs. really deleting files. One of the more interesting chapters looks at security tools and practices based on ethnographic field studies. While ethnography (the study of customs of individual peoples and cultures) initially does not sound like a "security or usability" issue, it is used (and the author claims quite effectively) to understand "the work practices of computer users in context, informing the design of computer systems to better suit their needs."
The section Privacy and Anonymity Systems contains a chapter discussing Google's Gmail privacy policy with respect to "informed consent". For the most part, the authors give Gmail high marks, with the privacy concerns rooted in differing definitions of "privacy". For example, if you believe that content-targeted advertisements should require the consent of all parties involved, you (in sending an email to a Gmail user) have not consented to the targeted ads the recipient sees. The chapter describes two other cases of informed consent and presents a list of ten design principles based on the information. Another chapter discusses leveraging social processes for managing browser cookies. The concept being when a cookie is saved stored, it will provide you aggregate community data such as X percent of the people visiting this site blocked the cookie. One obvious benefit is the ability to educate "less knowledgeable" users about "good" cookies vs "bad" cookies.
The remaining sections discuss usability of products, for which the chapter titles are description enough. Overall, I found the book useful. The variety of authors and subject matter made it easy to skip around and choose what piqued my interest at the time. Along with the academic feel of the book, each chapter is generally descriptive enough to get an idea as to what subject matter will be covered. While the book's target is "researchers and students" first, as a "professional" working for a security company, I found it helped me better explain the pros and cons of these topics to the less technical people I work with every day. I'd recommend it to anyone involved with the usability of security applications and systems."
You can purchase Security and Usability from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
security != easy.
In fact, lim v->oo s/v = 0, where s=security and v=variables in your environment. No real security, but you try.
I cringe when I see all those books at the local computer mart with titles like "TCP/IP Security" with a cheesy rainbox-colored logo beside it that says "Made Easy" in an italic font. Publishers actually think people trying to secure networks will be fooled by a logo that belongs on a home decorating book or manual can opener package?
Having ranted, I'm sure the O'Reilly book is probably good. It certainly helps to get on top of things if you can at least sort all of your marbles into buckets, instead of watching them roll around randomly underfoot.
Sometime this seems to work out well, sometimes not. I thought that the Pattern Languages of Program Design editors did a nice job on making that work, and the same goes for the excellent Game Programming Gems series.
:-)
On the other hand, sometime you can really tell that one author wrote a book and was interested in the topic - i.e., Component Development for the Java Platform by Stuart Halloway comes to mind. This was an excellent book for intermediate to advanced Java programmers and Stuart's interest in how things really work in Java serialization, classloaders, and so forth shines through.
And hopefully the same goes for PMD Applied
The Army reading list
Security/Cryptography is not easy, almost by definition, because you are building systems that withstand all attacks -- even ones you cannot foresee at the time of design. Defense is hard when you dont know exactly what to defend against. As opposed to traditional software design, where, you have a very well-defined goal to meet. Such paranoia almost always leads to lack of usability.
Social engineering will always be the broken part of security. You can have a system that requires users to have a 20 character randomly generated password, as well as a smart card, and they will still pass their password around along with their card, which will have the password written on the back. Until people start taking computer security seriously, there will be no end to the security breaches. One of the real problems is that we tend to put a lot of the blame on those breaking into the systems. The user is usually not only relieved from blame, but also get pitied for being the poor user that was attacked by the nasty con artist. While some of the blame lies with those doing the cracking, more blame should be put on the users, especially when they should know better. Phishing techniques when you get directed to some website, where you proceed to enter your username and password are in most cases completely avoidable. But people still sympathize with them, and blame it on the bad guys. Nobody would give people the same kind of sympathy if they handed their wallet over to the wallet inspector on a downtown street corner, or got their possessions stolen after leaving their door wide open. Why are we so quick to feel sorry for people, just because it happened on a computer?
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I'd say most consumer grade firewall applications are incredibly easy to use. I have had friends fire up that one really popular ZoneAlarm or whatever and get it to lockdown their connections, even as they barely know how to install a piece of software. It doesn't get much easier than that.
Then again, once the little popup messages start rolling in, they have a few questions for me, but all in all I'm impressed with the ease of use.
You're nothing; like me.
They either get away with them, or the users find subtle ways to work around them, thus negating the policy completely. Either that or the users ignore the policy completely. The best security policies are the ones you can explain to the people who are affected by it and have them understand both the risk, and why you've implemented the policy. If you can't explain how the policy addresses a security risk, it's probably not a good policy...