Ira Winkler - You CAN Stop Stupid

Therefore, businesses should factor the users' limited awareness into their risk management calculations and plans. You should provide awareness training and opportunities to further reduce risk. Although we don't want organizations to rely too strongly on awareness, it is a critical component of any security program to reduce risk.

Although user ignorance can be partially improved with training, carelessness is another matter. Assuming you have properly instructed users in how they should perform their functions, if some users still consistently violate policies and cause damage, you may need to take disciplinary action against them.

Beyond ignorance and carelessness, you also must account for malicious actions. We discussed this in the previous section, and we will explore options to address it as we discuss security measures throughout the book.

It is important to follow our recommended strategies to ensure that your systems reduce the opportunities for users to make errors or cause malicious damage and then mitigates any remaining potential harm. Then regardless of whether the harmful actions are due to malice, ignorance, or carelessness, your environment should be far more powerfully positioned to minimize or even stop the resulting damage.

Users are expected to, and do, make mistakes, and some attempt to maliciously cause damage. However, those actions do not have to result in damage. There is a tendency to place all of the blame for mistakes on users. Instead, a better approach is to recognize the relationship between users and loss and work to improve the system in which they exist.

For this reason, we will use the term user-initiated loss (UIL), which we define as loss, in some form, that results from user action or inaction. As Chapter 2, “Users Are Part of the System,” discussed, users are not just employees but anyone who interacts with and can have an effect on your system. These actions can be a mistake, or they can be a deliberate, malicious act. Obviously, sometimes the system is attacked by an external entity, so the attack itself is not user-initiated. But when the user initiates an action that enables the attack to succeed, the user's action has initiated the actual loss.

It is important to also note that not all mistakes or malicious acts result in loss, and not all loss happens when the action takes place.

First, we must consider that some actions might not be sufficient to result in loss, or the loss may be prevented. For example, if a person clicks to open a ransomware program in a phishing message, if the user does not have admin privileges on their system, the ransomware should not be able to encrypt the system.

Then we must consider that should there be loss, the loss may or may not happen immediately. Consider that the data entry error may take years to create a problem, if at all, like the iconic error with the Hubble Space Telescope referred to in Chapter 2, where the error wasn’t realized until the telescope was already in orbit and ultimately required $150,000,000 in repairs. This error was years in the making.

The Target, Sony, OPM, and Equifax hacks all happened over a period of time. They each resulted in some form of user action or inaction as the initial attack vector. However, none of them had to result in massive damage from the single user failing. Yes, an Equifax employee was slow in patching a new vulnerability, but the massive data breach did not have to occur if there weren't the systematic technical failings within the Equifax infrastructure, especially given that the thefts took months to complete.

These examples begin to imply some potential solutions for UIL. However, before we begin exploring solutions, we intend to set a foundation of understanding the types of losses that may be initiated through user actions. With this foundation, we can then discuss how to avoid putting users in a position where they might initiate loss, instruct them how to take better actions, and then prevent their actions from resulting in loss. We will also explore how to take the opportunity away from malicious actors, as well as how to detect and mitigate the malicious acts.

Because there are an infinite number of user actions and inactions that can result in loss, it is helpful to categorize those actions. This allows you to identify which categories of user error and malice to consider in your environment and what specific scenarios to plan to mitigate. This chapter will examine some common categories where UIL occurs. We'll begin by considering processes, culture, physical losses, crime, user error, and inadequate training. Then we'll move on to technology implementation. Future chapters will explore ways of mitigating UIL.

Although this might seem to have no direct relationship to the users, how your organization specifies work processes is one of the biggest causes of UIL. Every decision you make about your work processes determines the extent to which you are giving the user the opportunity to initiate loss.

Clearly, the user has to perform a business function. If you can theoretically remove people from processes, you can reduce all UIL associated with those processes. For example, in fast-food restaurants, cashiers have the ability to initiate loss in multiple categories. A cashier can record the order incorrectly. This causes food waste and poor customer satisfaction, which can reduce profit and impede future sales. A cashier can also make mistakes in the handling of cash. They might miscount change, steal money, or be tricked by con artists. These are just a few of the problems. Restaurant chains understand this and implement controls within the process to reduce these losses. McDonald's, however, is going even further to control the process by implementing kiosks where customers place their orders directly into a computer system. This removes all potential loss associated directly with the cashiers.

Obviously, there are a variety of potential losses that are created by removing a human cashier from the process (such as loss of business from customers who find interacting with a kiosk too complicated), but those are ideally accounted for within the revised process. The point is that the process itself can put the user in the position to create UIL, or it can remove the opportunity for the user to initiate loss.

A process can be overly complicated and put well-intentioned users in a position where it is inevitable that they will make mistakes. For example, when you have users implement repetitive tasks in a rapid manner, errors generally happen. Such is the case with social media content reviewers. Facebook, for example, through outside contractors, pays content moderators low wages and has them review up to 1,000 reported posts a day. (See “Underpaid and Overburdened: The Life of a Facebook Monitor,” The Guardian , www.theguardian.com/news/2017/may/25/facebook-moderator-underpaid-overburdened-extreme-content.) This can mean that legitimate content is deleted, while harmful content remains. The situation is ripe for UIL and also for causing significant harm to the content moderators, who have stress both from the working conditions and from reviewing some of the most troubling content on the Internet.

A process may also be poorly defined and give users access to more functionality and information than they require to perform their jobs. For example, companies used to attach credit card numbers to an entire sales record, and the credit card numbers were available to anyone in the entire fulfillment process, which included people in warehouses. Payment Card Industry Data Security Standard (PCI DSS) requires that only people who need access to the credit card numbers can actually access the information. Removing access to the information from all but those with a specific requirement to access it reduces the potential for those people to initiate a loss, maliciously or accidentally.