Identify and evaluate relevant threats.
Identify and evaluate relevant vulnerabilities.
Identify and evaluate countermeasures.
Develop mitigating recommendations.
Next, management reviews the risk assessment. Management can approve, reject, or modify the recommendations. You then document the management decisions and include them in a plan of action and milestones document.
The following step is to translate the risk assessment into an actual risk mitigation plan. Before jumping into this, it’s a good practice to review the risk assessment. When reviewing the risk assessment, you should pay special attention to the following key items:
in-place countermeasures—The risk assessment may have addressed some of the countermeasures that are already being used. Some may need to be upgraded or reconfi gured. Others may need to be replaced completely. If a countermeasure is to be replaced, you shouldn’t remove the original countermeasure until the new one is ready to be installed.
Planned countermeasures—A planned countermeasure is one that has been approved and has a date for implementation. Planned countermeasures are documented in the risk assessment. Review these countermeasures to determine their status. A countermeasure may have been installed since the risk assessment was published. It’s also possible that the date the countermeasure will be imple-mented will affect the timeline for an approved countermeasure. You should document these countermeasures in the plan of action and milestones.
Approved countermeasures—Approved countermeasures are the controls previ-ously approved by management. They need to be added into the implementation pipeline. Some will be very easy to implement. Others may be complex and require extra steps. They may need to be purchased. They may need to be delegated. All will need to be tracked for completion.
Overlapping Countermeasures
Another important consideration when reviewing the plan is to determine if there is any overlap among the countermeasures. One mitigation countermeasure may 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 countermea-sures 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 inten-tional. As long as the countermeasures aren’t mitigating the same risk in the same way, this isn’t a problem. However, you should be aware of any countermeasure overlaps.
If a countermeasure overlaps with another, check for conflicts. Although many security countermeasures work together, some countermeasures may cause problems for others.
For example, consider a vulnerability scanner and an intrusion detection system used to protect a server. You could configure the vulnerability scanner to scan this server on a daily basis. However, the intrusion detection system will likely alert on this scan. It will recognize the scan as a potential attack and provide notification. This notification could be an e-mail to a group of administrators.
In this example, the intrusion detection system 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. However, there may be ways to avoid the conflict.
Perhaps you could program the intrusion detection system so that it doesn’t alert on scans from this vulnerability scanner. It’s possible that only a specific scan is detected.
Perhaps you can program the scanner to skip this scan. If you can’t avoid the conflict, you should at least educate personnel. Let them know what is causing the alert and stress that other alerts should be investigated thoroughly.
As long as one countermeasure doesn’t confl ict with another, there is nothing wrong with having overlapping countermeasures. In fact, a defense-in-depth strategy encourages having more than one countermeasure for different risks. If one counter-measure fails or is circumvented, the other countermeasure will provide protection.
Matching Threats with Vulnerabilities
One of the methods you can use to determine if countermeasures overlap is to map the countermeasure to threat/vulnerability pairs. You may remember the following formula:
Risk - Threat - Vulnerability
A vulnerability is a weakness, and by itself it doesn’t present a risk. Similarly, threats by themselves don’t present a risk. A risk occurs when a threat exploits a vulnerability. Countermeasures either reduce or eliminate the impact of the threat or the vulnerability.
For example, consider user accounts of terminated employees. As a best practice, accounts should be disabled when the employee leaves. This allows another employee to access the ex-employee’s data. Once the data has been accessed, the account should be deleted.
Imagine a company that doesn’t do anything to old accounts. Instead, they simply remain enabled. As long as the account is enabled, it can be accessed by anyone. Anyone with physical access and knowledge of the credentials can use the account.
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 of 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, you lose non-repudiation. If any of the activity is logged, it looks as if the ex-employee is taking the action. Imagine that Bob is an ex-employee but Sally learns his user name and password. Sally can log on as Bob. Audit logs may record what Sally does, but they record Bob’s user name. 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 may log on and access the account, or someone else may use the account.
Identifying Countermeasures
You mitigate risks by adding countermeasures. Consider the risks from not disabling inactive accounts. You could choose to mitigate these risks with several countermeasures:
- Create 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 require-ments for an account lockout policy. It could include details for a password policy.
- Create a script to check account usage—You could task administrators with writing a script to identify inactive accounts. An inactive account could be defi ned as any account that hasn’t been used in the last 30 days. The script could automatically disable the inactive accounts. It could also be scheduled to run automatically once a week, log the results, and e-mail the results to interested personnel.
- Countermeasure physical access to employee areas—You could control access to employee-only areas. This can be as simple as signs to discourage non-employees. You can also use 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. 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 use the cracked passwords to log into a system or network. The solution is to implement a password policy. A password policy is often part of an overall account management policy. You can enforce password policies using technical means. For example, Microsoft domains allow you 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 characters may seem outrageous if you haven’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, lowercase, numbers, and special characters. Some requirements specify all four character types must be used. A complex password is more diffi cult to crack than a simple password.
- Maximum age—The maximum age identifi es 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 is 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. When password history is used, it’s common to remember the past 24 passwords. This prevents a user from reusing a password until he or she has used 24 other passwords.
- Minimum age—This prevents a user from changing his or her password until a minimum amount of time has passed. It’s common to use one day as a minimum password age. This works with the password history. It prevents a user from changing a password right away to get back to his or her original password. With a password history set to 24 and the minimum age set to 1 day, a user would have to change the password every day for the next 25 days to get back to the original password. This makes it simply too difficult for a user to circumvent the intended policy. The user will instead comply with the intention of the policy, which is to change the password to a new password.
Summarized from the book Risk List and Control - Darril Gibson
Darril Gibson is the CEO of Security Consulting and Training, LLC. He regularly teaches, writes, and consults on a wide variety of security and technical topics. He’s been a Microsoft Certified Trainer for more than 10 years and holds several certifications, including MCSE, MCDBA, MCSD, MCITP, ITIL v3, Security , and CISSP. He has authored, coauthored, or contributed to 10 books including the successful Security : Get Certified, Get Ahead.
No comments:
Post a Comment