Another important consideration when reviewing the plan is to determine whether there is any overlap among the countermeasures. One countermeasure may reduce or resolve more than one risk. Additionally, some risks may be mitigated by more than one countermeasure.

The overlap may be purposeful or accidental. In other words, multiple countermeasures may be implemented for a single risk as a defense-in-depth strategy. This ensures that the risk is mitigated even if a countermeasure fails. An accidental overlap occurs when two or more countermeasures mitigate the same risk but the overlap wasn’t intentional. As long as the countermeasures aren’t mitigating the same risk in the same way, this isn’t a problem. However, any countermeasure overlaps should be identified.

If a countermeasure overlaps with another countermeasure, conflicts may occur between the two. Although many security countermeasures work together, some countermeasures may cause problems for other countermeasures.

For example, a vulnerability scanner and an intrusion detection system (IDS) used to protect a server may conflict. The vulnerability scanner could be configured to scan this server on a daily basis. However, the IDS will likely detect this scan and send an alert because it recognizes the scan as a potential attack. This notification could be an email to a group of administrators.

In this example, the IDS alert is a false alert, or false positive. It requires an administrator to investigate and review the alert. Because the internal vulnerability scanner is causing the alert, it clearly isn’t an actual attack. However, it still takes time to investigate.

This doesn’t mean that either of the countermeasures should be avoided, because there may be ways to avoid the conflict. Perhaps the IDS could be programmed so that it doesn’t detect scans from the vulnerability scanner. Maybe the IDS detects only one specific scan. Perhaps the scanner can be programmed to skip this scan. If the conflict can’t be avoided, personnel should at least be educated about the conflict. They should know what is causing the alert and that other alerts should be investigated thoroughly.

As long as two countermeasures don’t conflict with each other, overlapping countermeasures are OK. In fact, a defense-in-depth strategy encourages having more than one countermeasure for different risks. If one countermeasure fails or is circumvented, the other countermeasure still provides protection.

One of the methods that can be used to determine whether countermeasures overlap is to conduct a risk assessment, which maps the countermeasure to threats, vulnerabilities, and the assets being protected. This helps to paint a complete picture of risk, which is often represented with the following formula:

Risk = Threat × Vulnerability × Asset

A vulnerability is a weakness; by itself, it doesn’t present a risk. Similarly, threats by themselves don’t present a risk. Risk is the probability of a threat taking advantage of a vulnerability to cause loss, damage, or harm to an asset. Countermeasures either reduce or eliminate the impact of the threat or the vulnerability on the asset.

According to NIST 800-30, a risk assessment is used to identify, estimate, and prioritize risk to the operations of a business or organization. The risk assessment helps decision makers in these organizations identify and evaluate how these threats impact them and what countermeasures can be implemented to reduce vulnerabilities and harm to their assets. The eventual outcome is a determination of risk.

For example, consider user accounts of terminated employees. As a best practice, accounts should be disabled but not deleted when the employee leaves. If necessary, administrators can enable the account later with a different password. This allows a supervisor to access the ex-employee’s data. After the supervisor reviews and copies important data, administrators delete the ex-employee’s account.

Imagine that a company doesn’t do anything to old accounts. As long as the account is enabled, anyone can access it.

If previous employees have physical access to the network, they can log on. Some networks will even allow them to log on remotely. They would have the same permissions as if they had never left the job. They could then access all the same data as if they were an employee. They could read, modify, or delete the data.

Perhaps a previous employee still has friends on the job. The previous employee could give his or her credentials to a friend, and the friend could log on using the ex-employee’s credentials. At this point, nonrepudiation is lost. If any of the activity is logged, it looks as if the ex-employee is taking the action. For example, Bob is an ex-employee, but Sally learns his username and password. With that information, Sally can log on as Bob. Audit logs may record what Sally does, but they record Bob’s username. This might send security personnel on a wild goose chase trying to determine how Bob gained access to the network.

In this situation, the vulnerability is that inactive accounts are still enabled. User accounts aren’t managed, leaving them available even if they aren’t needed. The threat is that a previous employee or someone else may log on and access the account. The assets that could be lost, damaged, or harmed include valuable company information in the accounts.

Risks are mitigated by adding countermeasures. The following countermeasures could be implemented to mitigate the risks from not disabling inactive accounts:

• Creating an account management policy—An account management policy is a written policy that spells out exactly what should be done with accounts. The policy may cover much more than just ex-employee accounts. For example, it could also address the format used to create accounts, such as firstname.lastname. It could include requirements for an account lockout policy and details for a password policy.
• Creating a script to check account usage—Administrators could be tasked with writing a script to identify inactive accounts. An organization might define an inactive account as any account that hasn’t been used in the past 30 days. The script would scan accounts and automatically disable inactive accounts. Administrators could schedule the script to run once a week, log the results, and email the results to interested personnel.
• Controlling physical access to employee areas—Access to employee-only areas could be controlled. Limiting access can be as simple as posting signs to discourage nonemployees from entering or as involved as using physical locks, cipher locks, badges, or proximity cards.

Similarly, the risk assessment may determine that users are not using strong passwords or changing their passwords regularly. The vulnerability is that the passwords are weak because password-cracking tools can easily crack weak passwords. The threat is that an attacker may use one of the many tools available to crack the weak password. Attackers can then use the cracked passwords to log on to a system or network.

The solution is to implement a password policy. A password policy is often part of an overall account management policy. Password policies can be enforced using technical means. For example, Microsoft domains allow IT administrators to enforce strong password practices with Group Policy.

A password policy would specify the following:

• Password length—Common recommended lengths are at least 8 characters for regular users and at least 15 characters for administrators. Although 15-character passwords may seem outrageous to an administrator who hasn’t used them, they are used. However, passphrases are commonly used instead of passwords. For example, a password could be IL0veR1$kM@n@gement. This is a complex 19-character password, but it isn’t hard to remember.
• Complexity—The complexity refers to the mixture of characters. Complex passwords commonly have a mixture of at least three of the four character types. Character types are uppercase letters, lowercase letters, numbers, and special characters. Some requirements specify all four character types must be used. A complex password is more difficult to crack than a simple password.
• Maximum age—The maximum age identifies when the password must be changed. For example, a maximum age of 45 indicates the password must be changed at least every 45 days. Once the maximum age passes, the user is unable to log on until the password has been changed.
• Password history—Some users will try to use one or two passwords. They use password 1 until they are forced to change the password, and then they switch to password 2. When they are forced to change the password again, they switch back to password 1. They constantly swap back and forth between password 1 and password 2. However, when password history is used, users are prevented from using a password they used before. For example, the past 24 passwords for Windows domain systems can be remembered, which means that users are prevented from reusing passwords until they have used 24 other passwords.
• Minimum age—Establishing a minimum age prevents users from changing their passwords until a minimum amount of time has passed. Administrators commonly use one day as a minimum password age, which works with the password history to prevent users from changing their passwords right away to get back to their original passwords. With a password history set to 24 and the minimum age set to one day, users would have to change their passwords every day for the next 25 days to get back to the original password, which makes circumventing the intended policy too difficult for the users. Users will instead comply with the intention of the policy, which is to change the password to a new password.

At this point, the countermeasures can be matched with the threat/vulnerability pairs. TABLE 11-1 shows the threat/vulnerability pairs matched to recommended countermeasures.

The information in the table shows that the account management policy is addressing two threat/vulnerability pairs. This information can be valuable. If administrators recognize that a single countermeasure is addressing multiple risks, they may decide to increase the priority of the countermeasure. While the threat/vulnerability pairing is effective in evaluating threats and vulnerabilities, NIST 800-30’s risk assessment approach is also an effective alternative.