Security Awareness For Dummies. Ira Winkler

more memorable, so users can remember it for a few more weeks. This can be valuable to increasing the Forgetting Curve, which is discussed in Chapter 3.

      

Though social engineers don’t necessarily have transferrable skills for designing an awareness program, social engineering tests can be a useful way to gather metrics. Social engineering, when performed properly, can determine how people will actually perform when faced with a potential attack. However, don’t fall into the trap of believing that social engineers are competent awareness professionals by default. Awareness is much more than telling people what tricks not to fall for. It’s telling people how to behave properly on a consistent basis.

Addressing Mental Models That Don’t Work

      “Hackers are unstoppable geniuses.”

      “There may be computer crimes, but it won’t happen to me.”

      “I am too unimportant to be a target.”

      These statements represent common mental models that I deal with in security awareness programs, and these mental models are both harmful and wrong.

Mental models reflect the way a person perceives their environment. For example, in most countries, the hot water faucet is on the left and the cold water faucet is on the right. Red usually means something bad or to stop, and green means safe or to go. When I visit a US airport, I expect that flights on a monitor will be listed alphabetically by destination. When I am in Europe or Asia, I generally need to know the departure time before I look on a monitor to find my gate. I can usually pick up a TV remote control and figure out how to turn on and use any TV. You might naturally assume that working with mental models with regard to security awareness would also be useful, but this isn’t the case.

      People’s mental models regarding cybersecurity are both inconsistent and frequently wrong. This causes them to make bad decisions. Most computer criminals are opportunists who take advantage of bad cyberhygiene (basic computer practices), such as not installing antimalware software or not performing backups.

      Your goal is first to understand the current mental models that serve as a barrier to positive security behaviors within your user base. Then you must create correct mental models to replace them with. You need to instill strong security practices as a habit.

      If your users believe that hackers are unstoppable geniuses, you need to talk about how they are frequently caught and how someone in your organization thwarted attacks by practicing what you preach. If they believe it will never happen to them, talk about how the organization suffered attacks. Show people how theoretically unimportant targets were used to gain access to other parties. You need to understand and dispel the harmful mental models, not try to adopt them to your needs.

      Chapter 5 discusses getting to know the users, which includes how they perceive security concerns. When you can understand how mental models are failing security awareness efforts, you can start to address them head-on and begin to change perceptions.

Making Perfection the Stated Goal

      Perhaps the greatest form of self-sabotage you can commit as a security awareness professional is to overpromise what your program can deliver. For example, telling management to expect a human firewall to work — that your users will be both your first and last line of defense — sets you up for failure.

      In the first place, nobody will believe you. Because no experienced security professional would expect perfection, you lose at least some of the credibility you may have had from the start. Then, the first time you have an inevitable security incident, the occurrence chips away at your remaining credibility.

      As I discuss in Chapter 3, the goal of a security program is risk management. A competent CISO doesn’t promise perfect security. They say that they’re working to manage the organization’s risk by implementing a security program. They don’t promise to defeat bad people. They don’t promise that incidents will never happen. They essentially say that they will reduce loss.

Focus any and all claims you might make to be reasonable and based on the potential for risk reduction. To perform risk reduction, you must gather data and make reasonable and defensible claims of potential loss reduction.

Measuring from the Start

      You should always collect metrics before you start rolling out an awareness program. These metrics are commonly referred to as Day 0 metrics, and serve to show the value you create.

      Even if you want to strive for perfection, you need to figure out where you are beginning. Too many awareness practitioners start their programs without figuring out how to judge their success. With awareness, it’s easy to see failure — but almost impossible to see success without proactively looking for it.

      With all business processes, there has to be definition of success — and that is in the form of some metrics. I talk about various types of metrics in Chapter 8, but for now you need to understand that without knowing where you’re starting from, you may never know the level of success you have.

      

Even in the absence of perfection, by collecting metrics throughout the lifecycle of your program, you can demonstrate the real value you return.

Prioritizing Program Over Product

      When people think of security awareness programs, often the first things that come to mind are computer-based training (CBT) and phishing simulations. When implementing a program, the person responsible for a security awareness program typically chooses a vendor and then determines which of the vendor’s products to use. Awareness programs should be a strategy for effectively addressing the risk associated with user actions. Products are potential tactics, which may or may not address a piece of a strategy. Though some tactics are common, they are not a strategy to address user risk. If you want a program instead of a product, there has to be more than just a choice of which products to roll out.

      Consider what you would say, when asked about a technical security program, if a security engineer said they were buying a firewall and antimalware. Clearly, both of those products are required, but they don’t make for a complete security program, because attackers can bypass these products or find flaws in the implementation of the products. They leave too many other vulnerabilities addressed, even if they individually function perfectly.

With awareness, focusing solely on implementing products is also an incomplete approach. You need to determine how to roll out the entire program. You need to identify the components of the program and its metrics, the organization’s subcultures, and more. As mentioned previously in this chapter, if you’re incomplete in how you implement an awareness program, you will reach only a small population of users and in ways that may not impact them. Part 2 of this book covers the appropriate process.

      If a system exists to simplify implementation of phishing and CBT, it represents the implementation of products and not the implementation of a comprehensive awareness program. If your goal is just to implement a Check-the-Box awareness program, however, product implementation is likely all you need.

Choosing Substance Over Style

      When I worked for the NSA, it was clear that any mishandling of sensitive information could result in an