The best approach to avoid the consequences of excessively secured systems is to not allow yourself to get talked into one in the first place.
That can be difficultmost people view things in a binary way, so, they believe, if no security is bad, more is always better. The simplistic all-or-nothing view doesn't reflect reality.
One technique I've seen work is to insist on the same kind of benefit/cost analysis that most shops insist on for other kinds of projects. What's the actual risk? How likely is the next gadget to decrease attacks, and by how much? The act of discussing a security initiative this way can be enlightening to all involved and help IT make more rational decisions.
If you're convinced you truly need the additional security, a conversation with the advocate of tighter security can still add value.
It can frequently expose a warped sense of perspective that will motivate the advocate to make protecting the system the primary mission, and not just a supporting feature. Once a person has outed herself as one whose world views are skewed by personal anxieties, you have insight into the usefulness of her advocacy.
One technique that always works is to run a pilot project with end users. Get them to keep a diary of experiences and how they believe the changes affect their productivity. More likely than not, you'll get feedback that will help you tweak the design to better avoid the three kinds of staff setbacks.
It's not intuitively obvious that at some point adding security processes and technologies actually degrades safety. It just happens to be true.
Read part 1 of this article to see why the most security conscious companies are often the least secure.
This article was originally published on 04-30-2005