Header

Policy Structure

Writing an effective op risk policy statement, especially in a large organization, is almost an art form. For example, one of the fundamental IS policies is that all employees need to protect their passwords. You could issue a simple policy that stated, "Employees must not share their passwords." The language is clear and to the point. Since password sharing is a common problem, the statement provides a simple rule that is an effective reminder for employees when someone asks them for their password.

But then the lawyers take over. Does the policy apply to temporaries and consultants who use company computers? What are the consequences if an employee does share a password? If someone steals your password, are you still responsible? What if I write down my password so I won't forget it and then hide it under my keyboard, but someone finds it? What if I use a dynamic password token and someone sees the password on the token? What if I type in my password on the screen and I am able to read the password as I type it in?

They are all good questions and a good policy should attempt to resolve them. So you propose something like:

  • Users are accountable for all activity associated with their User ID and password.
  • Static passwords will:
    • Never be shared, made known to others or written down.
    • Never be displayed on the screen in clear text.

But then the techies take over. What about a password sent over the Internet in clear text as part of an FTP session?

Ok, we need to stop using FTP and switch to a secure communication protocol where we can encrypt the password. So you add another provision to the policy that, "Passwords will always be encrypted when sent or stored electronically."

But then the security administrator objects that he needs to be able to send new passwords to users by email and that those passwords are in clear text. So you add an exception at the end of the encryption section allowing administrators to send passwords in clear text as long as they are one-time or single-use passwords (i.e. the user has to change the password as soon as they log on for the first time).

At this point you begin to wonder if you will ever be able to write a policy that everyone agrees to. At least you have learned that despite the value of clear and simple rules, the best policies are structured and thorough, and they follow an agreed upon format that ensures all critical elements are addressed.

 

©2009 ISRMC, LLC