Vulnerability Assessments
A vulnerability assessment is performed to identify vulnerabilities within an organization. Vulnerabilities are any weaknesses in an IT infrastructure. They can exist for a specific server, for entire networks, or with personnel.
For example, a single web server could be vulnerable to a buffer overflow attack. For example, a buffer overflow bug was discovered in May. If the web server is not patched until July, it will remain vulnerable between May and July.
NOTE
A buffer overflow attack occurs when an attacker sends more data or different data than a system or application expects. Buffer overflow vulnerabilities are fixed with updates or patches. If servers aren’t patched, the vulnerability remains.
Entire networks can be vulnerable if access controls aren’t implemented. For example, if all users are granted the same rights and permissions for a network, no access control exists. All data on the network could be vulnerable to unauthorized disclosure. However, administrative models can be used to implement access controls. The principles of least privilege and need to know ensure that users have the access they need and no more.
Vulnerabilities exist with personnel if they don’t understand the value of security. Social engineering tactics trick people into revealing sensitive information or taking unsafe actions. If users don’t understand the value of security practices, they are more likely to be tricked. For example, an employee may receive a phone call that goes like this: “Hi. This is Joe in IT. We’re doing a system upgrade and have discovered a problem with your user account. To fix it and ensure you don’t lose any data, we’ll need to log on to your account from the server. Can you give me your username and password?”
Of course, Joe doesn’t work in the IT shop. He’s a criminal and is trying to get a user to reveal a username and password. If users frequently give out their password to administrators, this ploy will easily succeed, but if they are told to never give out their passwords, it may not.
Vulnerability assessments are performed to check for any of these types of vulnerabilities, and some assessments will be performed more often than others.
FYI
Employees should never reveal their passwords to anyone, including responding to emails that may be phishing attempts and requests over the phone or in person that could be social engineering attacks. When an organization begins making exceptions, such as telling users it is OK to give a password to someone from the IT department, the users get confused. They may think that the phishing attempt or social engineering attack is another exception. Automated vulnerability scans of systems are usually performed frequently and can be done with assessment tools on a weekly basis. Audits can be performed on an annual basis to see whether security controls are being used as expected. For example, an annual audit can detect whether access controls are still being used as expected. Additionally, tests can be done annually to see whether personnel respond to social engineering tactics. The following website, hosted by the U.S. government, provides helpful tips on avoiding social engineering and phishing attacks: https://www.us-cert.gov/ncas/tips/ST04-014.
An added benefit of a vulnerability assessment is the resulting documentation, which can be used to show compliance with various laws and guidelines. Several laws govern IT, such as the Sarbanes-Oxley Act (SOX), the Gramm-Leach-Bliley Act (GLBA), and the Health Insurance Portability and Accountability Act (HIPAA).
Vulnerability assessment testing can be performed internally or externally:
- Internal assessments—Security professionals try to exploit the internal system to see what they can learn about vulnerabilities. Some large companies have dedicated staff who regularly perform assessments. A smaller company could assign internal assessments as an extra task for an IT administrator.
- External assessments—Outside consultants are hired to assess the security by exploiting the system to see what they can learn. They provide a fresh look at a company’s system and are usually very good at quickly identifying weaknesses.
TIP
If possible, personnel who own the system or are responsible for its security should not perform the assessment. Having an objective view is harder if the personnel have a stake in making the system look good. Being immersed in the details of the system also makes objectivity harder and impedes assessing vulnerabilities with fresh eyes.
Gaining permission to perform any vulnerability assessment is always important and should be done in writing. Security professionals often refer to this written document as the “get out of jail free” contract, which should be signed by someone senior enough to stand behind it. While most vulnerability assessments are nonintrusive and won’t affect operations, some vulnerability assessment methods can take a system down or simulate a DoS attack.
This section on vulnerability assessments includes the following topics:
- Review of documentation
- Review of system logs, audit trails, and intrusion detection and prevention 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
Review of Documentation
One of the steps that can be taken when performing a vulnerability assessment is to review the available documentation from multiple sources, including:
- Incidents—If any security incidents have occurred, the documentation from the incident should be reviewed. Often, the cause of an incident is directly related to a vulnerability. For example, a successful buffer overflow attack on an Internet-facing server may have resulted in a malware infection, which may indicate that the system is not being updated often enough.
- Outage reports—Any outage that has affected the mission of the business can be investigated. If the outage affected the bottom line, a vulnerability can probably be identified.
- Assessment reports—Past assessment reports should be reviewed to identify common problems and problems that have not been corrected.
Review of System Logs, Audit Trails, and Intrusion Detection and Prevention System Outputs
In addition to reviewing past assessment reports, other information can be reviewed to determine vulnerabilities. The three common sources of information are system logs, audit trails, and intrusion detection systems (IDSs). There is no particular order in which they should be reviewed. However, if the network has the data available, all of it should be reviewed.
System Logs
All computer systems have some type of system logs. These logs have different names for different operating systems but overall have the same purpose. They log data based on what the system is doing.
For example, Microsoft Windows systems have a log called System. This log is viewed using the Windows Event Viewer. The System log records system events, such as when systems and services start or stop, and errors, warnings, and information events.
What is happening to a system can be determined by reviewing the system logs. Some events, such as warnings and errors, will jump out, indicating obvious problems. Other events need a little more analysis to identify trends.
Audit Trails
An audit trail is a series of events recorded in one or more logs, which are referred to as audit logs, but an audit trail can be recorded in many types of logs. For example, Microsoft Windows includes a Security log that records auditable events. Additionally, security applications, such as firewalls, record auditable events.
Any type of audit log attempts to log at least the information about who, what, when, and where. If a user is logged on, the credentials are used to identify who accessed the data. For some logs, such as firewall logs, the “who” may be the source’s Internet Protocol (IP) address instead of a username.
Auditable events are any events to be tracked, for example, who has accessed a folder. Auditing on the folder could be enabled so that each time someone accessed any files within the folder, the access would be recorded. The event would include the username, what file was accessed, when it was accessed, and the server or computer where it was accessed.
Many organizations have automated systems that can review audit trails. An automated system is capable of examining logs from multiple sources. Sometimes, these systems are combined with IDSs that can review the events to detect intrusions.
NOTE
While intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) are commonly known as intrusion detection and prevention systems (IDPSs), they differ somewhat. An IDS analyzes and monitors network traffic, whereas an IPS prevents and controls network packets from coming into the network. An IPS is placed on the network like a firewall, between the internal network and the outside world.
Intrusion Detection and Prevention System Outputs
An intrusion detection and prevention system (IDPS) is able to monitor a network or system, capture network traffic, and send an alert when an intrusion is detected. A host-based IDS is installed on a single system. A network-based IDS has several monitoring agents installed throughout the network that report to a central server. A signature-based IDS detects attacks based on known malicious attack sequences or patterns. An anomaly-based IDS employs machine learning algorithms to detect unknown malware attacks. FIGURE 8-3 shows an example of a network-based IDS with three monitoring agents installed on the network.
FIGURE 8-3 Network-based intrusion detection system.
One monitoring agent is on the Internet side, one is in the demilitarized zone (DMZ), and one is on the internal network. An examination of the output of an IDS will reveal several key points. These three agents work together to identify what type of attacks are launched against the network, and they provide insight into the success of different mitigation techniques.
Events from agent 1 show how many attacks are launched against a network from the Internet. Events from agent 2 identify the attacks that are able to get through the external firewall, which shows the effectiveness of the firewall against specific types of attacks and helps reveal the vulnerabilities for any public-facing servers in the DMZ. Agent 3 shows the attacks that are able to get through the second firewall of the DMZ. These attacks on an internal network can be very damaging if not addressed.
Although the focus of Figure 8-3 is on attacks from the Internet, internal attacks are also possible. The network agent on the internal network monitors for internal attacks. A network having several internal agents installed to monitor an internal network is common.
Internal attacks aren’t necessarily from malicious users. They are often from malware that has infected one or more systems on the network. However, the benefit of a network-based IDS is early detection of an infection.
Vulnerability Scans and Other Assessment Tools
Many tools are available to perform vulnerability scans within a network. Some of the more commonly used tools include Nmap, Nessus, SATAN, and SAINT.
These tools provide several benefits, some of which include:
- Identifying vulnerabilities—They provide a fast and easy method to identify vulnerabilities. The scan is run and then the report is analyzed.
- Scanning systems and network—Vulnerability scanners can inspect and detect problems on the network and on individual hosts; detect vulnerabilities based on the operating system, applications, and services installed on the host; and detect open ports and access points on the network.
- Providing metrics—A key part of management is measurement. If something can be measured, its progress can be identified, and this is also true with vulnerabilities. At the beginning of running regular vulnerability scans, the scans will likely discover many vulnerabilities. Six months later, if the metrics are analyzed, the analysis should show that the issues have been significantly reduced. If they have not been reduced, then other problems are involved. If all of the same vulnerabilities are present six months after the first scan, the vulnerabilities are not getting fixed.
- Documenting results—The resulting documentation provides input for internal reports compliance. Scanner reports can be used to prove compliance with different laws and regulations.
Vulnerability scanners do have weaknesses. First, they must be updated regularly because threats and systems change. Therefore, the scans must also change to ensure they are looking for both past and current vulnerabilities.
Second, many scanners have a high false-positive error rate. In other words, they incorrectly indicate a vulnerability exists. While this can be annoying, it makes sense from a security perspective. If there’s a possibility for error, the scanner errs on the side of too many warnings, instead of not enough. Here are two examples:
- A system is vulnerable, but the scans are not detecting the vulnerabilities. This situation can occur from a low false-positive error rate.
- A system is not vulnerable, but the scans keep identifying vulnerabilities. This situation can occur from a high false-positive error rate.
TIP
When shopping for a vulnerability assessment scanner, paying attention to how often the scanner is updated is important. A scanner that isn’t updated regularly may be useful for only a short period of time, whereas a scanner that is regularly updated might be worth the extra expense.
Most security professionals want to avoid the first scenario. They don’t want their systems to have unreported vulnerabilities.
Last, some scanners can generate a lot of network traffic, which could interfere with normal operations if the network is already busy.
Audits and Personnel Interviews
Audits are performed to check compliance with rules and guidelines. A vulnerability assessment audit specifically checks an organization’s compliance with in-place internal policies.
For example, an organization may have a policy in place related to employees who leave the company. The policy may state that user accounts should be immediately disabled if an employee leaves and, six months later, deleted.
An audit determines whether the policy is being followed. The audit can be quick and automated if the auditor has scripting skills. The auditor could write a script to check for enabled accounts that haven’t been used in the past 15 days. The output is then checked with the human resources department to determine whether any of these users are still employed. A similar script could be used to determine whether any accounts exist that haven’t been used in the past six months.
Personnel interviews could be completed to gain insight into possible new issues. For example, personnel could be asked what they consider to be current vulnerabilities. Often, employees know what the issues are, but they aren’t asked.
In addition, personnel can be interviewed to identify their security knowledge. For example, employees could be asked when it is acceptable to give out their password. A secure organization will have a policy in place stating that users should never give out their password to anyone.
Process Analysis and Output Analysis
Process analysis is performed in some systems to determine whether vulnerabilities exist in their processes. In other words, instead of just looking at the output, the processes used to determine the output are evaluated. Output analysis, on the other hand, is performed by examining the output to determine whether a vulnerability exists.
Neither analysis is superior to the other. However, there are times when one will be preferable over the other. For example, the effectiveness of a firewall may be a concern. Firewalls use rules to determine whether traffic is allowed. Either process analysis or output analysis can be used to determine the effectiveness of the firewall.
FIGURE 8-4 shows that the firewall is blocking and allowing traffic into and out of the network. Process analysis requires reviewing all the rules to determine whether they provide the desired security. Output analysis examines the input and output of the firewall to determine whether only desired traffic is allowed through the firewall.
FIGURE 8-4 Firewalls control network traffic.
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.
System Testing
System testing is used to test individual systems for vulnerabilities. These systems include individual servers and individual end user systems. The primary testing performed on systems is related to patches and updates because the majority of vulnerabilities occur because of bugs that are resolved by patching. For example, a company could have a bank of servers that are running Microsoft Windows Server 2012. Several patches and updates have been released for the servers since they’ve been installed. System testing queries the servers to determine whether they are up to date.
System testing could be done with traditional management tools, vulnerability assessment tools, or both. Microsoft includes traditional tools, such as Windows Server Update Services (WSUS) and System Center 2012 Configuration Manager (ConfigMgr). Each of these server products can query systems in the network and ensure they have all the appropriate updates. If a system doesn’t have an update, WSUS or ConfigMgr can push the update to the system and double-check to ensure it has been installed. For example, Microsoft Security Bulletin MS14-011 identified a critical vulnerability in the VBScript scripting engine in Microsoft Windows. This vulnerability could allow remote code execution if a user visited a specially crafted website. The remote code could install malware. Information about this vulnerability is available at http://go.microsoft.com/fwlink/?LinkID=391023.
Microsoft has released updates for all affected systems. Any system that doesn’t have the update related to MS14-011 is vulnerable. WSUS and ConfigMgr can be used to check clients for the vulnerability and deploy the appropriate updates.
As an additional check, vulnerability assessment tools can verify that systems have appropriate updates, but most of them don’t deploy the updates.
Functionality Testing
Functionality testing is primarily used with software development. It helps ensure that a product meets the functional requirements or specifications defined for the product.
One of the problems that can occur with software development is scope creep, which 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, their being tested is highly unlikely.
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.
Edge testing is one technique that can often detect potential buffer overflow errors. For example, if an input between 1 and 100 is expected, edge testing enters numbers on the edges. The numbers 0 and 1 are on the beginning edge of the range. The numbers 100 and 101 are on the outer edge of the range.
Access Controls Testing
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.
In FIGURE 8-5, a company has certain resources that only sales personnel should access and 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.
FIGURE 8-5 Access controls applied to users.
All members of the sales group automatically have access to the sales resources, and all members of the IT group automatically have access to the IT resources. Members of the sales group do not have access to IT department resources just as 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. Even though from a usability perspective, granting everyone administrative access would be easier to implement, doing so would sacrifice security. It violates the principle of least privilege by giving all users rights to do anything, and it violates the principle of need to know by granting all users access to all data in the organization.
Access controls testing verifies that the users are granted the rights and permissions needed to perform their jobs and no more. It ensures that an administrative model is used as it was designed.
Penetration Testing
Penetration testing attempts to exploit vulnerabilities. It verifies the effectiveness of controls, or countermeasures. In other words, a vulnerability was discovered, and a control to protect against the vulnerability was implemented, after which a penetration test is performed to see whether the control works.
If the penetration test is successful, then the controls aren’t adequate. Additional steps will need to be taken to protect against an attack.
A penetration test is much more invasive than a vulnerability assessment test. Specifically, if a penetration test is successful, it may actually take down a system. With this in mind, the need to be cautious when performing penetration tests is great.
Transaction and Application Testing
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, a woman is withdrawing $100 from her ATM. The ATM checks her account and verifies she has the money. It then debits the amount from her account and gives her the money. Once she has the money, it views the transaction as complete and commits the transaction, making it final. However, if the ATM loses power before it gives her the money, the ATM does not commit the transaction. The debit is recognized as part of an incomplete transaction, and it is rolled back. Transaction testing ensures that transactions behave as expected.
NOTE
Penetration testing is also referred to as exploit testing. Exploit testing is explored later in this chapter.
Application testing is used to ensure that an application works with the back-end database as expected. A well-known vulnerability with front-end applications that interact with back-end databases is SQL injection. Many tools are available that can automate SQL injection testing on systems.
NOTE
In an SQL injection attack, the attacker can read sections of a database or the entire database without authorization. SQL injection attacks can also be used to modify data in the database.
Best Practices for Performing Vulnerability Assessments Within the Seven Domains of a Typical IT Infrastructure
When performing vulnerability testing, each of the seven domains of a typical IT infrastructure should be considered. These seven domains were mentioned earlier and are shown in Figure 8-2.
Vulnerabilities exist in each of the domains. The focus can be on only one domain at a time, but all seven domains should be examined on a regular basis.
A company may have tools that are focused on only the LAN Domain or the LAN-to-WAN Domain. However, if this is the only vulnerability testing the company does, the testing is missing many other potential problems. For example, social engineering attacks against the User Domain are often successful simply because users don’t understand the risks.
The following best practices apply to most of the domains:
- Identifying assets first—Asset management helps to identify which resources to protect. Not all assets need vulnerability assessments, only the valuable ones.
- Ensuring scanners are kept up to date—Vulnerability scanners need to be updated regularly, which is similar to how antivirus software needs to be updated with malware definitions. An antivirus program that isn’t kept up to date is only marginally better than no antivirus program at all, which is also true for a vulnerability scanner.
- Performing internal and external checks—Attacks can come from internal and external sources, so vulnerability assessments should be performed from internal and external locations. Check for vulnerabilities behind the firewall; from outside the firewall; and, with a DMZ, from the Internet into the DMZ.
- Documenting the results—The results of every vulnerability assessment should be documented. This documentation can be used in several ways. Older results can be compared against current results to track progress. Some vulnerability assessments can be used to document compliance with laws and regulations.
- Providing reports—Reports that summarize the important findings and provide recommendations are presented to management.