It security has always interested me and while I’m not directly responsible for any IT security related decisions, it’s a bit of a hobby for me. One thing that I’ve observed over the years from experience working in multiple different industries and environments (IT and non-IT) that there is a tendency for employees to prefer the course of action which requires the least amount of work. It sounds silly when said like that, because of COURSE people in the aggregate are going to prefer working “smarter” not harder, but this has some pretty profound implications for IT security architecture. There was a specific graphic in the Fujitsu security architecture document in the readings this week that reminded me of this concept. The graphic (displayed here) shows three desirable traits of ESA: Cost, Security, and Convenience (usability), where maximizing one of those points is done so at the expense of one or more of the other. You may have a very secure system, but if it’s not easy to use, you will have a user population actively subverting security (either intentionally or unintentionally), netting lower security overall. Now for a couple of stories:
Figure 6-1 from the Fujitsu Enterprise Security Architecture document
Story 01: At my organization, the vast majority of internal web applications and services are authenticated via SAML and single sign on accounts in a browser. You even need to authenticate to the proxy to visit external websites. One of the biggest user complaints was due to the “chore” of having to type in their password each time they opened a new browser session. How long could this take? We’re talking the time it takes to tap out a extremely familiar set of characters, this SSO account is after all used for EVERYTHING. But the complaints from having to type in passwords every few hours or on a new browser session grew so strong, that IT introduced a concept known as “reduced sign on,” where now the password would only be required once every 12 hours and would persist even if the browser was closed. End user response to such a minor change was incredibly positive.
Story 02: Passwords again, sort of! For remote employees must first login to VPN service in order to access network resources while off network. Authentication happens with a physical RSA hardware token and a user known PIN. However, again, there was a huge uproar from the imposition of having to enter in the randomly generated digits from the token, to the point we had users even sharing tokens and PINs with each other, which is obviously against policy, but they claimed they NEEDED to in order to work. The solution was a new connectivity service, which rather than prompting the user to enter in a token+PIN combo, would create an application specific encrypted SSL tunnel and authenticate via a certificate installed on the PC, all in the background. It’s still VPN….just….hidden from the user. Again, this new service was received very very positively, and everyone now talks about the hellish days back when six digits had to be entered from a token.
The take away from these two stories is to not discount the user experience when architecting systems. I think also, that security can be improved at organizations who think of ways to shepherd users towards good security practices by making those practices desirable or easier.
I’m reminded by the concept of a Desire Path which I’m sure everyone has seen. This is a worn spot in the grass from foot traffic on campuses, parks, etc. It’s where enough people take take the short cut and cut the corner by walking where they shouldn’t, rather than staying on the pavement. Administrators there too have a decision to make: They could put up ropes and “Keep off the Grass” signs, probably to little avail…or they could simply pave the desired path!
Desire Paths – a path created as a consequence of erosion caused by human or animal foot-fall or traffic.