This section on vulnerability assessments includes the following topics: Documentation review Review of system logs, audit trails, and intrusion detection system outputs Vulnerability scans and other assessment tools Audits and personnel interviews Process analysis and output analysis System testing Best practices for performing vulnerability assessments within the seven domains of a typical IT infrastructure
Process analysis is performed in some systems to determine if vulnerabilities exist in the process. In other words, instead of just looking at the output, you evaluate the processes used to determine the output. Output analysis: the process of examining the output to determine if a vulnerability exists. Neither analysis is superior to the other. However, there are times when one will be preferable over the other.
The firewall in the previous figure is blocking and allowing traffic into and out of the network. Process analysis requires you to review all the rules to determine if the rules provide the desired security Output analysis will examine the input and output of the firewall to determine if only desired traffic is allowed through the firewall. If the firewall has only five rules, process analysis would be completed rather easily. However, if the firewall has over 100 rules, output analysis may be easier to perform.
This section on vulnerability assessments includes the following topics: Documentation review Review of system logs, audit trails, and intrusion detection system outputs Vulnerability scans and other assessment tools Audits and personnel interviews Process analysis and output analysis System testing Best practices for performing vulnerability assessments within the seven domains of a typical IT infrastructure
1. System test 2. Functionality test 3. Access control test 4. Penetration test 5. Transaction and application testing
System testing is used to test individual systems for vulnerabilities. This includes individual servers and individual end- user systems. The primary testing performed on systems is related to patches and updates. This is because the majority of vulnerabilities occur because of bugs that are resolved by patching.
For example, you could have a bank of servers that are running Microsoft Windows Server Several patches and updates have been released for the servers since they've been installed. System testing queries the servers to determine if they are up-to-date. You can do system testing with traditional management tools, with VA tools, or both. For example, Microsoft includes traditional tools such as Windows Server Update Services (WSUS) and System Center Configuration Manager (SCCM).
One of the problems that can occur with software development is scope creep. This occurs when additional capabilities are added that weren't originally planned. In other words, the add-ons are outside the scope of the original product specifications. While this looks good on the surface, it adds additional security issues. Each additional line of code that is added to an application represents a potential bug. If additional capabilities are added, they need to be tested. If they are added without being documented, it's highly unlikely that they will be tested.
When an application is developed with the original functions, functional testing ensures that the application works as expected. Functional testing often includes attempts to develop an application.
Access controls testing verifies user rights and permissions. A "right" grants the authority to perform an action on a system, such as to restart it. A "permission" grants access to a resource, such as a file or printer. Most organizations have administrative models in place that specify what rights and permissions regular users are granted. These models ensure that users have what they need to perform their job, but no more. They help support security principles of least privilege and need to know.
A company has some resources that only sales personnel should access. It has other resources that only IT department personnel should access. Access restrictions are enforced by putting employees into the appropriate groups and assigning permissions to the group.
Any member of the Sales group automatically has access to the Sales resources. Any member of the IT group automatically has access to the IT resources. Members of the Sales group do not have access to IT department resources. Members of the IT group do not have access to Sales department resources. Similarly, only certain users within an organization should have administrative rights to systems. From a usability perspective, it's easier to grant everyone administrative access.
Penetration testing attempts to exploit vulnerabilities. In other words, you'll often complete a VA to discover vulnerabilities. You'll then perform a penetration test to see if a vulnerability can be exploited.
Penetration testing verifies the effectiveness of countermeasures or controls. In other words, you've discovered a vulnerability and implemented a control to protect against the vulnerability. You can now perform a penetration test to see if the control works. If the penetration test is successful, you know the controls aren't adequate. You'll need to take additional steps to protect against an attack.
Transaction and application testing ensures that an application will function correctly with a back-end database. A transaction in a database is a group of statements that either succeed or fail as a whole. If any single statement fails, the entire transaction fails.
For example, imagine you are withdrawing $100 from your ATM. The ATM verifies you have the money in your account and gives you the money. However, just before it debits the $100 from your account, the ATM loses power. You have the money, but it hasn't been debited from your account. Instead, the ATM will record the actions this way. It checks your account and verifies you have the money. It debits the amount from your account. It then gives you the money. Once you have the money, it views the transaction as complete and commits the transaction, making it final. However, if the ATM loses power before giving you the money, the ATM does not commit the transaction. The debit is recognized as part of an incomplete transaction and it is rolled back.
This section on vulnerability assessments includes the following topics: Documentation review Review of system logs, audit trails, and intrusion detection system outputs Vulnerability scans and other assessment tools Audits and personnel interviews Process analysis and output analysis System testing Best practices for performing vulnerability assessments within the seven domains of a typical IT infrastructure
When performing vulnerability testing, you should ensure that each of the seven domains of a typical IT infrastructure is considered. Vulnerabilities exist in each of the domains. It's possible to focus on only a single domain at a time. However, you should examine all seven domains on a regular basis.
1. Identify assets first Asset management helps you identify what resources to protect. There is no need to perform VAs on all assets. You only want to take these steps on the valuable assets. 2. Ensure scanners are kept up to date Vulnerability scanners need to be updated regularly. This is similar to how antivirus (AV) software needs to be updated with malware definitions.
3. Perform internal and external checks Attacks can come from internal and external sources. You should perform VAs from internal and external locations. Check within the firewall. Check from outside the firewall. If you have a DMZ, check for vulnerabilities from outside the network. 4. Document the results Document the results of every VA. You can use this documentation in several ways. Older results can be compared against current results to track progress. Some VAs can be used to document compliance with laws and regulations. 5. Provide reports Provide reports to management. These reports will summarize the important findings and provide recommendations
Exploit assessments attempt to exploit vulnerabilities. In other words, they simulate an attack to determine if the attack can succeed. An exploit test usually starts with a vulnerability test to determine the vulnerabilities. It follows with an attempt to exploit the vulnerability
The first step in an exploit assessment is to perform a vulnerability test. The vulnerability test will provide you with a list of potential vulnerabilities that can be exploited. However, just because you know that a vulnerability can be exploited, you won't necessarily know how to exploit it. Some vulnerabilities are easily exploited through existing tools.
The following list shows some possible items to check in each of the seven domains: User Domain Common exploits against users are related to social engineering. If users can be easily tricked or conned, it indicates more training is needed. Workstation Domain Two common things to check on workstations are updates and antivirus software. LAN-to-WAN Domain This is the boundary between the public Internet and the private network. Attackers attempt to discover holes in the firewall and exploit them. An aggressive policy of only allowing required traffic through the firewall provides the best protection. Additionally, intrusion detection systems can detect and mitigate many of the threats.
WAN Domain This includes any Internet-facing servers. Common exploits against these systems are buffer overflow attacks. The best defense is to keep the systems updated. Remote Access Domain This includes dial-up remote access servers and virtual private network (VPN) servers. Common exploits attempt to break through the authentication and authorization process to access the internal network. System/Application Domain Exploits in this domain are dependent on the system or application. Database servers have specific exploits such as SQL injection attacks. Unpatched Web servers are commonly vulnerable to buffer overflow attacks. servers are vulnerable to spam infected with malware.
Social engineering attacks often succeed due to the trusting nature of people. As a simple example, consider piggybacking. Piggybacking occurs when one person follows another person into a secure area without using a key, badge, or cipher code. Imagine a company that has restricted access to a building. Personnel are required to use a badge and a personal identification number (PIN) to open a door. However, once the door is open, multiple people can walk through the door. The additional people that walk through the door are piggybackers or tailgaters.
An exploit assessment will identify exploits that are mitigated. It will also identify exploits that are not mitigated. The difference between what is mitigated and what is not mitigated represents a gap in the security. A gap analysis report documents these differences. A remediation plan is often included with a gap analysis. It includes details on what you would need to do to close the gap. The goal is to ensure that all serious exploits are mitigated once the remediation plan is completed.
Configuration management and change management can both help prevent or remediate exploits. In configuration management, you use standards to ensure that systems are configured similarly. Benefit of configuration management: 1. a higher level of confidence that systems are protected against exploits. For example, imagine that a well-known exploit can target systems that haven't had an update in three years. Configuration management techniques ensure that an update is always included in any new deployment.
Change management is a process that controls changes to systems. You perform changes only after they have been reviewed and approved. Change management is an important process because many IT outages occur due to unauthorized changes. Organizations with mature change management processes reduce these outages. A common example is a well-meaning administrator who makes a change to solve a small problem on a local system. She inadvertently creates a much larger problem on the network. For example, an application may not work with a specific update applied. The administrator removes the update, making the system vulnerable to the exploit.
After you have deployed countermeasures or controls to mitigate an exploit, you need to ensure that they work. In other words, you need to repeat the testing to ensure that the exploit has been mitigated. Two possibilities exist: 1. The control may not work at all. If this is the case, it needs to be replaced. 2. The configuration may need to be slightly modified to work completely. For example, certain settings may have been required when the control was first deployed, but were missed. You can go back, make these changes, and test the control again.
1. Get permission: ensure that management understands the risks and approves the process. Without permission, several issues can arise. 2. Identify as many exploits as possible:Use all of the tools available with vulnerability assessments to identify possible exploits. Examine all seven domains of a typical IT infrastructure.
3. Use a gap analysis for legal compliance: If you are identifying exploits for legal compliance such as for HIPAA, use a gap analysis. The gap analysis identifies the differences between what is needed and what you have in place. 4. Verify that exploits have been mitigated: After you've implemented controls to mitigate exploits, ensure that they work. Use the same techniques you originally used to discover the exploit to verify it is mitigated.