<img alt="dcsimg" id="dcsimg" width="1" height="1" src="//www.qsstats.com/dcsuuvfw300000gkyg9tnx0uc_3f7v/njs.gif?dcsuri=/index.php/c/a/Trends/Secure-By-Design/3&amp;WT.js=No&amp;WT.tv=10.4.1&amp;dcssip=www.cioinsight.com&amp;WT.qs_dlk=XEW9PPGQE7jxLNYvQhC1ygAAAA0&amp;">

Winning User Cooperation

By David Raikow  |  Posted 08-20-2008 Print

Winning User Cooperation

Where user cooperation is necessary, even trusting and permissive planners cannot assume that well-meaning users will do as they are told. Planners should take workflows and user psychology into account and do everything possible to create an environment in which cooperation is the user's easiest and most attractive option.

Take the classic dilemma of user authentication policies. Users don't like to authenticate and will take any opportunity to simplify or avoid the process. If you force users to remember complex passwords, they respond by writing them down, trading one vulnerability for another. For years, security professionals have tried to counter with user education, only to find that users--even the IT staff--simply would not cooperate.

Addressing this behavior is the real benefit of non-password authentication technologies like smart cards and biometrics, which sidestep the impulse to simplify or write down passwords. However, in practice, users generally undermine these processes as well by refusing to log out unless forced to, leaving their smart card or token plugged into their computers when they leave.

At least one large software developer tackled this problem by tying user authentication and facility door locks to the same smart card. If employees want to use the restroom, they must take their smart card with them to unlock the restroom door, thereby logging them off the network at the same time.

Every security policy should also include provisions for managing the decision-making process for future policy changes. Effective implementation over time will always require temporary exceptions and long-term modifications in response to unforeseen circumstances, new business opportunities and technological developments.

PayPal, for instance, has a set of well-defined procedures by which departments can request exemptions from specific rules, complete with appeal mechanisms. Without such procedures in place, the resulting ad hoc process is at least as likely to be governed by interpersonal dynamics and office politics as by objective criteria.

Prepackaged, customizable security policies and standards libraries available from a number of vendors can be a useful starting point for many enterprises. This is particularly true for organizations regulated by legal or industry security standards that impose IT security and/or auditing requirements, including those for the Health Insurance Portability and Accountability Act, Gramm-Leach-Bliley Act, Sarbanes-Oxley Act, the Payment Card Industry Data Security Standard and numerous state laws.

But prepackaged products should be viewed only as a starting point--one that will require extensive, labor-intensive customization before it will be appropriate for any given organization. PayPal, like many financial services enterprises, uses a prepackaged library, but modified it heavily before implementation.


Submit a Comment

Loading Comments...
eWeek eWeek

Have the latest technology news and resources emailed to you everyday.