WyzGuys Tech Talk

Often it seems that security policies are designed with the assumption that average computer users are ID10Ts (idiot users).  Related terms such as PEBKAC (Problem Exists Between Keyboard And Chair), PICNIC (Problem In Chair, Not In Computer), IBM error (Idiot Behind Machine error) and other similar phrases illustrate the dark side of our interactions with our users.  Sometimes we allow our negative perceptions about our users to creep into security policies.  This can result in a draconian set of policies (i.e. up to and including termination) and security controls that may be excessively harsh and overwhelming for your user community.

In our last post we discussed ways to make your cybersecurity awareness training program both fun and informative.  Today we want to expand on that concept, and create a security policy environment that is positive and reinforces the training we just provided.  The policies we create should treat our user community as respected peers.

What not to do:

• Don’t punish ignorance – Sure many of them don’t know what we know, but expecting them to do our job is just going to create fear and frustration.
• No draconian policies – The game is not “how many hurtles can you clear for access.”  Try to avoid “mushroom management” (keep them in the dark and feed them lots of crap.)  Explain the why behind the policies
• To many warnings – Spamming your user team with email alerts will result in what it always does – even for you.  They will start to tune out the warnings.
• No access nightmares – I worked with a sheriff’s department where the admin required separate and unique user and very long password combinations for over two dozen law enforcement systems and applications.  The deputies all had a written password “cheat sheet” in their wallets to help them remember them all.  Not terribly secure in the end, when a deputy lost his wallet during an arrest.
• Don’t catch them doing something wrong – Making a specialty of catching bad practice and publicly shaming the offender will not create the environment we are trying to develop.
• Don’t deploy security “solutions” that don’t work – New security controls need to be functional at the least, and enhance or even replace existing controls at the best.

What to do:

• Create understandable policies – Keep it short and simple.  Check  out the template links at the bottom of this article.
• Tell them why – It is easier to get your users to comply if they understand that there are reasons for the policies and security controls, and what the reasons are.
• Encourage contact – If they see something suspicious, you want them to feel comfortable calling it in to IT.  The message you want to convey is “better safe than sorry.”
• Provide incentives – This ties into our training methodology we talked about in our last post.  Basically – more carrot less stick.  Recognition for desirable behaviors, prizes, snacks, even a lunch.
• Encourage threat awareness – Teach them about the current threat environment, threats that became incidents on your network (real life lessons), and how to recognize when it is happening to them.
• Have an incident response plan – A computer incident response plan ensures that everyone knows what to do if there is an intrusion or attack on the network.  Be sure to include your user community as “step one – user calls to report a suspicious event.”  Make sure they understand the importance of their vigilance and quick reporting.

Keep your users in mind when testing new solutions, or implementing new controls.  Try to stick with the “add one, drop one” approach.  When you implement a new control such as two factor authentication, try to remove a different control that has outlived it’s usefulness and ought to be deprecated (such as mandatory periodic password changes, or password complexity rules).  Or add something like single sign-on to make the daily chore of logging in to all your systems easier.  And explain the purpose of these changes in order to increase buy-in from your user group.

The idea here is to get your (now trained) user group to understand and support the security policies and controls in your company. Make them part of your security team. This should, ultimately, make your job easier, too.

More information:

• Wikipedia
• TechRepublic
  • Information Security Policy
  • Network Security Policy
  • Information Security Incident Reporting Policy 
  • Mobile Device Computing Policy