Percent Retained =
Information acquired
*100
Information presented
Security Awareness Content: Challenges of Using Punishment
Punishment is evident in all aspects of our life to everything from getting drivers to stop speeding, to getting the dog to not bark at the mailman. Because of this, it is no wonder that several go to punishment when wanting to change user behavior. While punishment is a very powerful tool- that can produce almost immediate change in behavior- it is very hard to control and very hard to maintain. For these reasons, I rarely recommend using punishment when creating and effective security awareness architecture.
What is the most effective punishment?
Want to know how to reduce user behavior with almost 100% effectiveness? Deprive users of food, water, and/or sex. Go forth and develop content.
…
No? I didn’t think so. When making security awareness content, we as info sec professionals are not able to use the most effective punishers and therefore have to evaluate our user base to figure out what is the next best thing. This punishment has to be easy to implement and applicable across your entire user base. Furthermore it has to be easy to maintain. Lets say you have an issue with users not properly disposing of PII so you decide to implement a termination policy for all instances of improperly handled or disposed of PII. While very effective (because it gets at the users ability to purchase food and water) it is not easy to maintain. You will either end up with a lot less employees REAL quick or you turn into the boy that cried wolf. Lets say that instead of termination, you force the employee to click through a 10-slide power point outlining what PII is and how to properly dispose of it. That won’t work either for the opposite reason- even though it’s easy to maintain, it’s effectiveness, as a punisher will wear off drastically. Think of this similarly to getting desensitized to a pop-up notification. It is for this reason choosing a contingency is often one of the hardest parts of using punishment in a content plan.
Indirectly punishing behaviors
Imagine that your organization has a major problem with users loosing mobile devices, laptops, and tablets. A loss is reported at least once every two weeks and each lost device exposes your organization to a data breech of some highly sensitive information (e.g., customer credit card information). In an effort to reduce this behavior, and keep your organization out of the news, you inflict a $100 penalty for loss of a phone, $300 for tablets, and $500 for a laptop. You see an immediate drop in device loss but after a few months some other patterns start to emerge. First, calls to report anything to the security team significantly reduce. This includes reports about phishing attacks and suspicious computer behavior. Second, when a device is lost, users are taking an average of 2 weeks to inform the security team. In the past, lost devices were reported within 24 hours. Both of these present a major problem to your organization and are the unfortunate side effect of a poorly used punishment. This example demonstrates how even though a punishment is inflicted upon a specific behavior it does not guarantee that the effect will be isolated. The plan was to reduce loss of devices, but users were also being deterred from reporting the loss as well as calling the security team at all.
While major, these two topics are just a few in a long list of reasons why using punishment to change user behavior is difficult to do. To be effective, a large amount of control is needed otherwise you can create more problems than you started with.
Security Awareness Content: Challenges of Using Reinforcement
Imagine that you are the head of security awareness at an organization (not a stretch for some) and have been charged with getting people to report issues to the help desk. You decide, in your infinite wisdom, to encourage them to report issues to the help desk by giving them $1 each time they report a valid problem. The week after implementing the new reward program the number of issues reported to the help desk has increased 100 fold. You program is getting great results. Not only are 99% of phishing attacks getting reported but shoulder surfing is down, you know when devices are lost, and compromised computers are being reported to the help desk rather than being discovered by them. Things are coming up roses.
See any problems here?
Of course you do! The budget for this program is going to be INSANE! No practical business will support paying $1 for each ticket at the help desk for any longer than 6 months- MAX. This leads into the second, and biggest problem with using reinforcement. If the only reason that users are reporting issues is because of a reward, the minute that the reward is removed the desired behavior plummets. Unless you can replace the reward with something of equal subjective value their incentive is gone and the trained behavior is lost.
*Finding something of equal subjective value to cash on a large scale is damn near impossible. I only say ‘damn near’ because I’m sure there is some magical place out there that can do it but I’ve never come across it. *
Finally, lets say that instead of $1 you gave them a free lunch- because your users really like lunch. How long will that be an effective reward? My guess is that after about a month of free lunches have been accrued the value of the reward will go down dramatically and so will your behavior. Suddenly, you have to switch the reward to something else – of equal subjective value- to keep them responding.
Vicious cycle anyone?
How to Use Reinforcement to Your Advantage
As you can see, reinforcement is a tricky thing but when can we use it to change behavior.
Lets go back to the help desk problem. Instead of paying for each help desk ticket, indefinitely, you make it a charity fundraiser for the holiday.
“Every time you call the help desk, $1 will be donated to buy gifts for families in need. Weekly progress will be reported!”
Some of you might look at this and say “even if we had the budget for that, we still have the same problem of removing the reward and loosing the behavior once the fund raiser was over” but consider two very important differences.
1- The reinforcement has a clearly defined ‘end point’ that has nothing to do with the user, the company, or their behavior but is a product of the reward. The gifts have to be bought at some point otherwise the fundraiser was pointless. Essentially you are isolating the reinforcement contingency and increasing your chances of the behavior persisting after.
-Not to mention periodic fundraisers to increase behavior –if needed- are MUCH more sustainable to the budget than constant reinforcement.
2- The second and most important is how closely the reinforcement (e.g., $1) and behavior are paired. In our first example the employee saw the DIRECT effect of calling the help desk on their pay check therefore it was very closely paired to their behavior
Just like if Pavlov’s dogs were fed EVERY time the research assistant came in.
The minute that the user realized the reinforcement was removed, the behavior that followed stopped (i.e., calling the help desk).
Back to Pavloc: The dogs would eventually stop salivating once they knew that the assistants were never going to feed them.
In our second example, the users see the money increase but it is NOT directly related to each time they call the help desk. Instead it goes into an anonymous pool that may jump $100 a week even if they just called the help desk once. Since the reinforcement is not closely tied to each behavior they perform, the chances of the behavior persisting after the reinforcement is removed increases significantly.
*For a more detailed look at this process see my previous blog on Pavlov and his dogs.
Based on all of this, be careful when using reinforcement. While it may provide an immediate result, it’s something that needs budget and time to maintain. If used wrong, you will just be setting yourself up for an uphill battle.