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.
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.