of technical vulnerabilities to include how technology is configured or maintained.
For example, poor passwords can be considered a technical vulnerability as they can be technically exploited by someone who guesses the passwords. This results in an external malicious attack directly against the computer, as the result of a technical vulnerability that was enabled by a user, who in turn was enabled to do so by their IT department, which happened to be governed by the existing policies of the organization. So, as you can see, the technical vulnerability is not just something that is inherent in the software or hardware independent of any user interaction. Users are involved at many levels.
As we are primarily interested in UIL, it is also important to recognize that technical vulnerabilities include the user interface design. While this can refer to computer interfaces, it can also refer to any interface on any piece of equipment. Such technology can cause users to initiate a loss. Interfaces can be confusing and almost force errors. For example, the DBIR highlights that a significant percentage of data breaches are caused by the email address autocomplete function filling in the wrong email address, after which sensitive data ends up being sent to the wrong person.
Generally, you can consider a technical vulnerability as anything in the organization's environment that can be exploited or can cause an error or damage. This is an important distinction to embrace as too many people are intimidated by the underlying technology (such as esoteric programming languages), but it is the surface technology (such as user interfaces) that they regularly interact with that can be the most damaging.
THE TWO WAYS TO HACK A COMPUTER
People are in awe of computer hackers, believing that they are some form of modern-day magicians who can manipulate computers at will. The reality is that these hackers in general know a few extra tricks that the average person does not. Fundamentally, there are two ways to hack a computer: take advantage of problems built into the software (or hardware) or take advantage of the way that users or administrators set up and maintain the computer.
Regarding problems built into a computer, everyone can accept that all programs have bugs. Some bugs cause the computer to crash. Other bugs create bad output. Some bugs cause elevated privileges or information leakage. These are all examples of security vulnerabilities.
Regarding how users and administrators set up and maintain a computer, consider how bad passwords can be guessed by another party. Administrators can configure computers to provide users with unnecessary privileges. They can leave the computer open to people from outside of the organization. They can fail to enact encryption on files. There are countless ways that such user actions can make a device vulnerable.
Again, all technology fails either by its design or through its use. Other than researching the track record of known vulnerabilities in software and hardware before you acquire it and knowing what patches can be applied to existing problems, there is little that you can do to affect technology design. That makes it all the more important to do what you can to help protect your users from hackers.
Countermeasures
When you look at the risk equation in Figure 4.1, you can see that countermeasures can be used to mitigate threats and vulnerabilities. However, you must consider that mitigating threats is frequently not possible or realistic. For example, you are not going to prevent hurricanes. Hurricanes will always exist. You are not going to prevent a nation-state from existing, unless you are likewise a nation-state and willing to invest significant resources. The average organization is not going to prevent outside criminals from making attacks. Even if you work with law enforcement, your abilities to stop a threat from existing are negligible.
You should plan to implement countermeasures to mitigate what is within your control. So while you might not be able to prevent a hurricane, you can choose to locate resources outside of hurricane zones. You can create backup systems and files. You can have backup power sources in case of power outages.
Also consider that when you mitigate a vulnerability, you mitigate the opportunity for a threat to exploit that vulnerability. For example, if a user has a bad password, the password can be exploited by any threat, from nation-states to nosy co-workers. However, if you implement multifactor authentication, it helps prevent nation-states and other attackers from exploiting the bad password.
For these reasons, you want to prioritize countermeasures that mitigate vulnerabilities that are most likely to be exploited and result in loss. This is a critical theme in Part III of this book.
Protection, Detection, and Reaction
It is also important to recognize that countermeasures not only apply to protection but apply to detection and reaction as well. When people think of countermeasures, they typically perceive them to provide protection, in other words, stopping a loss from occurring in the first place and keeping the bad guys out. The reality is that countermeasures can provide protection, detection, or reaction. There is no such thing as perfect protection. Because protection will inevitably fail, it is just as critical to invest in detection and reaction capabilities.
Different studies indicate that up to 80% of investment in countermeasures is in protection. This unfortunately results in massive success for perpetrators who are able to get through the initial protection measures. In many cases, it is sometimes more feasible to focus on detection of malicious activity and not put effort into prevention, as it is too costly. For example, if you are trying to secure a public network, any people with malicious intent are already allowed on the network. Likewise, even well-meaning users might violate policies. For that reason, it might be more effective to look for potentially harmful activities and, where appropriate, reduce the users' capabilities.
Accept, Avoid, Mitigate, Transfer
When you consider countermeasures, you must consider that the goal of countermeasures is not always to stop an attack. There is a widely accepted risk management paradigm known as accept, avoid, mitigate, and transfer.
Accepting risk implies that you acknowledge the risk exists but consciously choose not to take further action on the risk. This is appropriate, for example, when a risk involves an inconsequential loss or has a low probability of occurring.
Avoiding risk implies that as opposed to directly addressing the risk, you find a way to make it a moot issue. For example, a company might decide that it is not worth doing business within a specific region.
Mitigating risk means that you implement specific countermeasures to address a risk.
Transferring risk implies that you will not mitigate the risk directly, but you acknowledge it occurs and choose to transfer liability. This is the primary purpose of insurance, where you choose to be financially compensated, if a loss is realized, as opposed to proactively stopping the loss.
As you examine a potential risk, you need to consider how you want to manage that risk. There are many factors that are unique to your organization, and you must determine which method of addressing risk is best for your circumstances.
TIME'S ROLE IN COUNTERMEASURES
It is critical to understand the importance of time in a security program. When author Ira Winkler worked at the NSA, he learned that any encryption algorithm will inevitably by cracked. Given sufficient time and resources, an attacker can eventually crack an algorithm. However, you can endeavor to use encryption that is strong enough to prevent the code from being cracked for as long as the data is valuable.
For example, a commander in battle has to give tactical commands to troops in the field. Knowledge of the individual commands becomes worthless at the end of the battle in most cases. In this case, very low-grade encryption can be used. However,