Identifying and Analyzing Vulnerabilities

CIS527 Week #4_ P2 IT Risk Management – Identifying and Analyzing Threats, Vulnerabilities and Exploits

In this lesson we will discuss Identifying and Analyzing Threats, Vulnerabilities and Exploits.

Next slide

Threat assessments, vulnerability assessments and exploit assessments.

Next slide

A threat assessment identifies and evaluates potential

threats. The goal is to identify as many potential threats

as possible, and then to evaluate the threats. One important

element is an estimate of a threat’s frequency.

As a reminder, a risk assessment is performed for a specific time. Risks that exist today may not exist in a year. Similarly, a threat assessment is performed at a specific time, and evaluates current threats in the existing environment.

A threat is any activity that represents a possible danger. This includes any circumstances or events with the potential to adversely cause an impact on confidentiality, integrity and availability.

When a threat is matched with vulnerability, a risk occurs. The equation is Risk equals Vulnerability times threat.

Threats are categorized as either human or natural. Human threats can be internal or external. They can also be intentional or unintentional. Internal threats are by far the biggest threats to a company. Natural threats occur from weather or other non-manmade events. External attackers can be hackers launching denial of service (DoS) attacks on your network. They can be malware writers trying to access, modify, or corrupt your organization’s data. They can even be terrorists launching attacks on buildings or entire cities.

Internal users can also cause damage. A disgruntled employee may be able to access, modify, or corrupt the organization’s data. If proper access controls aren’t used, other employees may also access, modify, or corrupt data. Although the disgruntled employee’s actions will be purposeful, regular employees’ actions are accidental.

Natural threats include weather events such as floods, earthquakes, tornados, and electrical storms. Fires can also be natural threats.

The goal of a threat assessment is to identify threats. You can identify threats by reviewing historical data. You can also identify threats using threat modeling.

After the threats are identified, determination of the likelihood of the threat is made. Some threats are more likely to occur, while others are less likely. Next, the threats are prioritized.

The last step in a threat assessment is to provide a report. This report lists the findings.

Next slide

If historical data is available, this is often the easier approach. Historical data provides specific information on past threats. Threat modeling is more complex, and requires an examination of systems and services from a broader perspective. The process can be very time-consuming.

One of the best ways to determine what threats exist is to analyze past incidents. This includes past incidents at the organization, at similar organizations, and in the local area.

Data can be gathered by compiling records and conducting interviews. Data can be compiled from any existing records. These can also be security records or insurance claims.

An organization’s historical data can be used to

identify past incidents from threats. Past incidents can take many forms. They can result from users accidentally or maliciously causing problems. They can also come from external attacker or from natural events.

A few possible examples include internal users, disgruntled employees, equipment failure, software failure, data loss and attacks.

Next slide

Primary considerations for the local area are weather conditions and natural disasters. If a location is on the coast, and the coast has had hurricanes in the past, it will likely have hurricanes in the future. If a location is in a flood zone, it will likely flood in the future. Anyone who has lived in the area knows what the natural threats are. If your organization is on high ground and not in a flood zone, steps do not need to be taken to protect the organization from a food.

Threat modeling is more complex than just researching historical data for threats. It is a process used to assess and document an application or system’s security risks.

Ideally, threat modeling will be performed before writing an application or deploying a system. This is done when security is considered throughout the full life cycle of a product or service. In other words, if security is only considered at the end of the project, it frequently falls short. When threat modeling is used, the assets to be evaluated must first be considered.

Some key questions to ask include:

What system are you trying to protect?

Is the system susceptible to attacks?

Who are the potential adversaries?

How might a potential adversary attack?

Is the system susceptible to hardware or software failure?

Who are the users? and

How might an internal user misuse the system?

Threat modeling for complex systems can become extensive. Depending on the system being evaluated, there may need to be specific objectives defined to limit the scope of the evaluation.

Next slide

For example, every time local police answer calls to crime scenes, they quickly evaluate the situation. Consider a domestic dispute. A wife calls to complain that her husband is abusing her. Police know that this can be a violent and explosive scene. The husband could have a weapon. Additionally, if the wife realizes her husband is being arrested, she may turn on the police.

Similarly, every time the president of the United States travels somewhere, Secret Service teams go there first and perform threat assessments. The teams evaluate every path the president will take and look for potential threats. They visit the ultimate destinations and evaluate them. They also consider the possibility of snipers and bombs. They evaluate employees with a focus on new employees and investigate any tips.

Next slide

By going methodically through each of the domains, the evaluation of the potential threats from different perspectives can be conducted. Some best practices used when evaluating threats include:

–Assume nothing, recognizing that things change;

-Verify that systems operate and are controlled as expected;

-Limit the scope of the assessment to a single domain at a time;

-Use documentation and flow diagrams to understand the system you’re evaluating;

-Identify all possible entry points for the domain you’re evaluating;

-Consider threats to confidentiality, integrity, and availability;

-Consider internal and external human threats; and

-Consider natural threats

Next slide

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.

Automated vulnerability scans of systems are usually performed more frequently. They can be done with assessment tools on a weekly basis, and audits can be performed on an annual basis to see if security controls are being used as expected. For example, an annual audit can detect if access controls are still being used as expected. Additionally, tests can be conducted to determine if personnel respond to social engineering tactics on an annual basis.

An added benefit of a vulnerability assessment is the resulting documentation. Several laws govern IT, including 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.

The following elements are considered in vulnerability assessments:

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; and

Best practices for performing vulnerability assessments within the seven domains of a typical IT infrastructure

Next slide

Any computer system has 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.

An audit trail is a series of events recorded in one or more logs. These logs are referred to as audit logs, but an audit trail can be recorded in many types of logs. Many organizations have automated systems that can review audit trails. An automated system has the capability of examining logs from multiple sources. These are sometimes combined with intrusion detection systems that can review the events to detect intrusions.

An intrusion detection system (IDS) is able to monitor a network or system 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. These three agents work together to identify what type of attacks are launched against the network. They also provide insight into the success of different mitigation techniques.

Next slide

These tools provide several benefits – they are an easy method to identify vulnerabilities, to scan systems and networks, to provide the metrics needed to determine how many vulnerabilities there are in a system or network, and to document the results of the reports and scans.

Vulnerability scanners do have some weaknesses. Scanners

must be updated regularly because the threats change as well as the systems. The scans must also change to ensure they are looking for both past and current vulnerabilities.

Many scanners also have a high false positive error rate.

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.

Also, some scanners can generate a lot of network traffic. This network traffic could interfere with normal operations if the network is already busy.

Next slide

zation is following the policies that are in place.

An audit determines if the policy is being followed. The audit can be quick and automated if the auditor has some scripting skills. An auditor could write a script to check for enabled accounts that haven’t been used in the past fifteen days. The output is then checked with the human resources department to determine if any of these users are still employed. A similar script could be used to determine if any accounts exist that haven’t been used in the past six months. Personnel interviews are completed to gain insight into possible new issues.

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, on the other hand, is performed by 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.

Next slide

System testing can be done 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). 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 SCCM can push the update to the system and double-check to ensure it has been installed.

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. 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.

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”.

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.

Next slide

A penetration test is performed to see if vulnerability can be exploited. A penetration test can be much more invasive than Vulnerability Assessment tests. Specifically, if a penetration test is successful, it may actually take a system down. Penetration testing verifies the effectiveness of countermeasures or controls.

Transaction and applications 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.

Application testing is used to ensure that the 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. This is true for applications that are on the Web as well as non-Web-based applications. Many tools are available that can automate SQL injection testing on systems.

Next slide

The best practices that apply to most of the domains include:

identify assets first, ensure scanners are kept up to date, perform internal and external checks, document the results, and provide reports.

Next slide

a vulnerability test to determine the vulnerabilities. It follows with an attempt to exploit the vulnerability. Many large organizations have dedicated security teams used to perform exploit assessments while others hire outside professionals to perform exploit assessments. These personnel spend close to one hundred percent of their work time learning about vulnerabilities and exploits. They learn how to identify the vulnerabilities and how to exploit them. They also learn what is needed to protect an organization from the exploits.

The first step in an exploit assessment is to perform a vulnerability test. The vulnerability test will provide the list of potential vulnerabilities that can be exploited.

Some vulnerabilities are easily exploited through existing

tools. Developers have already identified the exploit and written an application. Now the attacker only needs to run the appli-cation. These applications are so easy to use that kids can use them. A “script kiddie” is someone who has the application

but doesn’t really know what he or she is doing. Other vulnerabilities require the expertise of talented

programmers or developers such as the Microsoft

Security Bulletin MS zero eight – zero six seven that was mentioned earlier.

When attempting to identify exploits, you should look at all seven domains of a typical IT infrastructure. The following list shows some possible items to check in each of the seven domains:

User domain;

Workstation domain;

LAN-to-WAN domain;

WAN domain;

Remote access domain; and

System/application domain

Next slide

(continued)

Social engineering attacks often succeed due to the trusting nature of people. As a simple example, piggybacking can be considered. 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.

Most organizations replace hubs with switches to prevent unrestricted sniffing attacks. A sniffing attack allows an attacker to connect a network interface card into an unused

wall socket and capture data. If a hub is used, an attacker can capture any data traveling through the hub. If a switch is used, the attacker is not able to capture as much data. However, an attack on the switch can cause it to work like a hub. Switches build tables matching their physical ports to Media Access Control (MAC) addresses. Most systems have only a single MAC address. In this case, the switch matches one port to one MAC address.

In a MAC flood attack, the attacker sends hundreds of packets to the same port. However, she uses spoofing to change the MAC address so that the switch sees hundreds of MAC addresses from the same port. At some point, the switch can no longer keep up. It “fails open” and works like a hub.

The TCP Syn flood attack is a common attack against public-

facing servers. It helps to understand how a Transmission

Control Protocol (TCP) session works to understand this

exploit.

In a TCP Syn flood attack, the handshake never completes. For example, the systems send the first two packets. However, the originating system never sends the third packet. It’s as if one person stuck his hand out to shake, but when the other

person extended her hand, the first person pulled his hand away.

If this happens once, it won’t cause a problem. However, in a TCP Syn flood attack, an attacking system may send hundreds of Syn packets to start the TCP session. The attacking system never completes the handshake by sending the last Ack packet.

This leaves hundreds of open sessions on the server while waiting for the Ack packet to complete the handshake. A TCP Syn flood attack consumes resources on a server and can cause the server to crash.

A common way these attacks are mitigated is with an IDS. An IDS can detect the attack and mitigate it. For example, the IDS can close all the open sessions before they become a problem. It can also change settings so that all packets from the attacking

computer are blocked.

Next slide

(continued)

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. It is common to use both a gap analysis and a remediation plan for any company that is regulated by HIPAA or SOX.

Due to the highly technical nature of some of these laws, organizations will often bring in outside consultants to perform the gap analysis. The consultants can often perform the analysis by reviewing existing documentation and procedures

combined with interviews of appropriate personnel. If desired, they can also create a remediation plan.

Configuration management and change management can both help prevent or remediate exploits. In configuration management, standards are used to ensure that systems are configured similarly. Additionally, compliance auditing is performed to ensure that systems have not been

improperly modified.

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.

Next slide

(continued)

the exploit has been mitigated.

Two possibilities exist. One, the control may not work at all. If this is the case, it needs to be replaced. Two, the configuration may need to be slightly modified to work completely.

Lastly, the following list identifies several best practices that can be followed when performing exploit assessments:

Get permission first;

Identify as many exploits as possible;

Use a gap analysis for legal compliance; and

Verify that exploits have been mitigated

Next slide

First we considered threat assessments. In this section, we discussed the techniques used for identifying threats and

best practices for threat assessments within the seven domains

of a typical IT infrastructure.

Next we looked at vulnerability assessments. Here, we looked at the review of system logs, audit trails and intrusion detection system outputs.

Finally, we discussed exploit assessments. Here, we learned how to identify and mitigate exploits with a gap analysis and remediation plan.

This completes this lesson.