Information security has, over time, evolved from a collection of esoteric security issues and technical remedies to its current state, in which it is more tightly integrated with the area of enterprise risk management. One effect of this move from technology to management discipline is the growth in the deployment and use of vulnerability management (and its primary technical constituent, vulnerability assessment [VA]) systems. These systems are considered fundamental to modern information security practice and have matured in architecture, features, and interfaces to accommodate the changing landscape of modern enterprises.

46.1.1 What Is Vulnerability Management?

Vulnerability management is a process of assessing deployed IT systems in order to determine the security state of the system. It includes the determination of corrective measures to mitigate issues identified that represent exposures for the enterprise, and managing the application of those measures. Vulnerability assessment is the key technology component of vulnerability management. However, there is a synergy between VA and the other elements of vulnerability management such that these elements drive what features are supported by VA technology.

The vulnerability management process is often defined in terms of four key functions. They are:

Inventory. Before an examiner can determine the extent of testing, one must identify all systems resident within the domain of interest. At this time, the operating system platforms and functions associated with each system are articulated and documented.
Focus. Once an examiner has an idea of the systems that reside within the network, he must determine what information he (or his assessment tools) needs to see in order to find those vulnerabilities that are relevant to him and the enterprise. Some include the tuning of vulnerability assessment tools as a part of this step.
Assess. The examiner runs any tests (both automated and manual) necessary to identify vulnerabilities resident on the systems. She then assesses the results of these tests. Finally, she evaluates (and ranks) the actual risk to her organization's systems security, making that judgment guided by security policy and current risk management criteria.
Respond. Finally, the examiner must execute procedures that act on the results of the assessment in order to address the problems identified.

Now that we have laid the cornerstones of the vulnerability management process, let us proceed to the technology particulars of vulnerability assessment.

46.1.2 What Is Vulnerability Assessment?

Vulnerability assessment is the analysis of the security state of a system on the basis of system information collected on demand. The four-step strategy for VA follows.

Sample a predetermined set of target system attributes (e.g., specific parameters for particular firewalls).
Place the sampled information in a data store.
Organize and compare the data store to a reference set of attributes.
Document and report the differences between the data store and the reference set.

46.1.3 Where Does Vulnerability Assessment Fit in Security Management?

Vulnerability assessment and its parent function, vulnerability management, are key elements of virtually all modern system security management strategies. There are many reasons for the popularity and acceptance of these functions, including:

When systems are first deployed, VA allows you to baseline the security state of those systems.
When security breaches are suspected, VA may allow you to quickly identify likely paths of attack and, furthermore, determine whether they have been exercised.
When new vulnerabilities are reported, VA can allow you to identify systems that are subject to the vulnerabilities so that you can patch or otherwise address the exposures.
The results of individual VAs can be archived and used to document the security state of systems at a specific time. This is often used to satisfy regulatory audit or other oversight requirements.

Although VA and vulnerability management are accepted as important system security functions, they are not sufficient to protect systems from all security threats. Such measures should be included in a more comprehensive security strategy that includes security policy and procedural controls (see Chapters 44, 45, 47, 48, 49, 50, 51, 52, and 53 in this Handbook), network firewalls and other perimeter defenses (Chapter 26), strong identification and authentication mechanisms (Chapters 28 and 29), access control mechanisms (Chapter 32), file and link encryption (Chapters 7, 32, 33, 34, and 36), file integrity checking (Chapters 3, 7, 39, 40, 41, 47, and 53), physical security measures (Chapters 22 and 23), and security training and education (Chapters 74 and 75). There are references and insight into building the rest of a comprehensive security strategy throughout this book.

46.1.4 Brief History of Vulnerability Assessment.

Early vulnerability assessment systems (VASs) include the COPS (Common Open Policy Services) system, developed in the late 1980s by Eugene H. Spafford and Daniel Farmer at Purdue University.¹ COPS was a UNIX-targeted credentialed vulnerability assessment product that gained wide acceptance in security circles. The initial freeware version of the Internet Security Scanner (ISS) was also released in the early 1990s, as was Farmer's and Wietse Venema's vulnerability assessment software, SATAN (Security Administrator Tool for Analysing Networks).²

Subsequent trends of note include the advent of open source tools for performing various forms of VA (e.g., NESSUS,³ which provides vulnerability scanning capabilities, and NMAP (Network Map),⁴ which provides an inventory of the systems on a specific network, along with the network services resident on those systems). Also of note is the move of VA to the network “cloud” (i.e., the vulnerability assessment is actually performed over the network, controlled by the security administrator over a Web interface, with results stored off site.)

46.2 TAXONOMY OF VULNERABILITY ASSESSMENT TECHNOLOGIES.

VA products snapshot the security state of systems, diagnosing problems that indicate that the system is vulnerable to specific attacks.

VA performs an examination of key indicators within systems that are known to correspond to security vulnerabilities. Some consider some types of VAS a special case of a host-based, interval-based intrusion detection process and describe it in terms of the intrusion detection process model outlined in Chapter 27.

46.2.1 Vulnerability Assessment Strategy and Techniques.

As noted, there is a four stage high-level strategy for conducting VA: sample, store, compare, and report. This four-stage process becomes quite complex when fleshed out to cover the full range of vulnerabilities that are commonly exploited by modern adversaries. A standard VA process may involve the use of any or all of these techniques:

Network scanning. Maps network nodes and associated services by use of a “port scanner.” This articulates issues at a network and network services layer of abstraction. See Section 46.2.2 of this chapter.

Vulnerability scanning. Takes the port-scanning functions of network scanners to the next level by testing for operating system and application software system vulnerabilities resident on hosts connected to the network. See Section 46.2.3.

Password cracking. Identifies weak passwords (see Chapter 7 in this Handbook).

Log review. A feature rooted in the earliest production computing platforms, log review remains one of the most powerful means of identifying weaknesses in systems (see Chapters 15, 18, 21, 25, 28, 36, 29, 40, 47, 53, 56, 57, 61, and 63 in this Handbook). Log review is mentioned throughout this book.

Integrity checking. Uses checksums, hash totals, and digital signatures to allow quick and reliable detection of tampered files and system objects (see Chapters 3, 7, 39, 40, 41, 47, and 53 in this Handbook).

Virus detection. Scans for known viruses infecting systems (see Chapter 16 in this Handbook).

War dialing. Scans enterprise systems for unauthorized modems (see Chapter 4 in this Handbook).

War driving. Scans enterprise systems for unauthorized wireless LAN connections (see Chapter 15 in this Handbook).

Penetration testing. Reenacts attackers' behavior in order to gain access and thereby test technical and procedural security measures.⁵ See Section 46.3 of this chapter.

As many of these techniques are complex enough to merit a full chapter of their own, we focus on only three of them in this chapter: network scanning, vulnerability scanning, and penetration testing.

46.2.2 Network Scanning.

Network scanners run a function called a port scanner, which uses a feature of ICMP, part of TCP/IP, in order to identify hosts available in a specified network address range. The port scanner then scans identified systems for open network ports and associated services.

Some network scanners use inference and other techniques to make intelligent guesses about the operating systems being run on open systems. These inferences are based on the combinations of active ports observed on a specific host (e.g., if Port 80 is open on a given host, it is likely running a web server.) Some scanners listen to ports for traffic that provides additional information about the system connected to that port. One example of this type of surveillance is called banner grabbing, and can provide a great deal of detail about the connected system.

As a primary security policy decision involves specifying what systems are allowed on an enterprise network, network scanners provide a vital piece of information for VA. They also provide collateral information regarding the connected systems on a network, which is critical for tuning and refining the VA process. It is important, however, to understand that although the operation of a network scanner is automated, the identification of vulnerabilities discovered by network scanning is not. There is minimal, if any, decision support in network scanning products—some will identify certain port numbers as associated with a known Trojan attack. Therefore, it is important that the results from a network scanner be evaluated by someone familiar with the assessed network and associated security policy.

46.2.3 Vulnerability Scanning.

Vulnerability scanning is the heart of traditional VA systems. In some ways vulnerability scanning appears to be the same as port scanning, but it differs in a critical way: It takes the additional step not only of collecting data regarding traffic, connections, and system attributes but of analyzing the data to determine whether they match a known vulnerability. Many systems (credentialed; see Section 46.2.4.1) also attempt to correct the vulnerabilities identified in the scan, either with human interaction or automatically.

As vulnerability scanning usually targets specific hosts, it often conducts a deeper inspection than network scanners, identifying software versions, specific software applications, and configuration attributes of systems. The policy checks available to host-based vulnerability scanners can include usage patterns for software.

Perhaps the most valuable feature of vulnerability scanners is the current database of known vulnerabilities. Virtually all commercial offerings in this area include updates to these vulnerability databases as a core feature of the product. Many products offer features that assist security managers in configuring scanners to fit their environments, including a wide variety of configuration, reporting, and support features.

Vulnerability scanners can perform extremely fine-grained security assessment, in far more detail than network port scanners. However, this degree of detail comes at a price. Vulnerability scanners are typically slower and more resource greedy than network port scanners. The range of available assessment techniques is usually richer for vulnerability scanners; some (e.g., DDoS testing) can disrupt the normal operation of an enterprise network. False positive rates (i.e., vulnerabilities spotted where none exist) can be high for many vulnerability scanners, requiring more human intervention. Finally, as the value of the vulnerability scanner resides in its vulnerability database, it is critical that the database be updated frequently. A vulnerability scanner with a noncurrent database leaves users open to compromise.

46.2.4 Assessment Strategies.

As in intrusion detection systems, VASs have features that allow differentiation between individual systems. The primary descriptors for VASs involve the information sources and how those information sources are generated.

46.2.4.1 Credentialed Monitoring.

Credentialed monitoring approaches for vulnerability assessments are those that utilize system data sources such as file contents, configuration information, and status information. This information is gained from nonintrusive sources; that is, it is gained by performing standard system status queries and inspection of system attributes. These sources are accessible only when the entity gathering them has legitimate access to the system (i.e., the entity possesses access credentials). In UNIX systems, this information is gathered at the host or device level; therefore, credentialed approaches are also host-based approaches. As many modern operating systems (e.g., Windows) handle status information differently, often providing it in the form of Application Programming Interfaces (APIs), the credentialed = host-based equivalence does not always apply in those environments.

46.2.4.2 Noncredentialed Monitors.

Noncredentialed monitoring approaches are those approaches that stage system attacks and record target system responses to the attacks. These approaches are much more intrusive than credentialed attacks and do not assume (nor do they require) any legitimate access to the target system; they are launched from an attacker's perspective. Noncredentialed approaches are often called active approaches and have detection and monitoring features that complement those of credentialed approaches. In particular, noncredentialed approaches are usually superior for diagnosing vulnerabilities associated with network services. As noted, in UNIX systems, noncredentialed assessments are usually considered network-based assessments. For instance, network scanning is a noncredentialed monitoring process. It bears repeating that here, as in credentialed approaches, the equivalence relationship does not necessarily apply in Windows and other modern operating system environments that provide status information in API form.⁶

46.2.5 Strengths and Weaknesses of VAS.

Knowing that security point products (e.g., firewalls, NIDS, and access-control systems) that defend particular features of a security perimeter cannot be perfect in the dynamic world of network and system attack, VASs serve an important function in the overall strategy for protecting information assets.

A list of the benefits associated with vulnerability analysis follows.

VASs conserve time and resources, as they allow even nonexpert personnel to check systems automatically for literally thousands of problems, any one of which might result in an intrusion.
VASs can be extremely helpful in training security novices to make systems more secure.
VASs can be updated to reflect new knowledge of vulnerabilities found by vendors and researchers.
VASs can be configured to address specific vulnerabilities and configurations affected by regulatory requirements. They are a critical component in IT security regulatory compliance.
As VASs are used in more environments as a part of a risk management regime, they are helpful for benchmarking the security state of systems in order to document progress toward a protection goal.
VASs are systematic and therefore consistent. These attributes allow them to be used as quality assurance measures for network or security managers. Many security professionals routinely recommend that operational security policies include provisions for using VASs to check systems for problems after major changes have occurred (as might be the case whenever software is updated or system recovery is required).

Weaknesses in vulnerability assessment include these:

Although vulnerability assessment is necessary for system security, it is not in and of itself sufficient to secure a system.
Many VASs serve only to diagnose problems, not to correct them. They are part of a more comprehensive vulnerability management process. User follow-through is still required.
If the VASs are not kept up to date, they may mislead users into underestimating the risk of penetration.
VASs can negatively impact the performance of an operational network. It is critical to balance demand for the network with the performance hits associated with running some types of VAS.
As in many other knowledge-based security tools, VA can be used for either productive or malicious purposes. In the hands of a security manager, VA is a valuable diagnostic technique. In the hands of an attacker, VA may optimize efforts to identify targets of attack and provide insight as to exactly how those targets might be compromised.

46.2.6 Roles for Vulnerability Assessment in System Security Management.

Vulnerability assessment products can be used at several points in the system security management life cycle.

First, when a new program is put into place, a VA can baseline the security state of the system. This application is particularly valuable in establishing the case for a security program, as it provides hard evidence that security problems exist.

Next, when an operational system changes (as might be the case when software updates are installed or new equipment is connected), a VA can help. It can find specific security vulnerabilities that occur as side effects of such changes.

Finally, when security incidents occur or are suspected, VA results can assist investigators in diagnosing possible paths of entry for attackers, locating artifacts of attacks (such as backdoors or Trojan horses), and identifying the system resources affected by an attack so that they can be restored to their original states.

46.3 PENETRATION TESTING.

Even the best designed VA scan is not a complete test of a system's security against a specific threat or adversary. When one considers whether illicit access to an information system might allow an attacker to inflict significant damage to an organization, VA of the systems yields, at best, a partial answer. Penetration testing expands the scope of VA to include the physical, personnel, and procedural controls that would be targeted by an adversary in an attack. This is done manually, by a penetration test team. Although many think of penetration tests as no-holds-barred hacker exercises, they should be thoroughly planned and staged with a great deal of forethought and consideration. In this section, we discuss the various techniques employed by penetration test teams and about the serious issues that arise in the context of penetration testing.

46.3.1 Penetration Test Goals.

As mentioned, the goal of penetration testing is to conduct a realistic test of adequacy of security measures for a given enterprise system. In particular, several goals are associated with penetration-testing activities:

Penetration testing is intended to model real-world attacks as closely as possible.⁷ Note that this differs from the goals of VA in this way: Vulnerability assessment is carried out within the policy context of the target system being assessed. In penetration testing, testers take the assessment outside this context, allowing security planners to make realistic judgments about whether operational systems are adequately protected from specific threats at a particular point of time.
Penetration testing allows the testing of simultaneous levels of security measures at once. This is useful in situations when the complexity of fielded systems (and the measures employed to protect them) surfaces questions about conflicting goals of security and availability and other operational conflicts.
Penetration testing allows one to better identify potential access paths to critical information or system assets that other VA techniques failed to locate.
Penetration testing should be carried out in a way that does not jeopardize normal business activity. As it is by definition carried out on operational systems in live environments, this is a critical requirement.
Finally, as in the general case of VA, penetration testing often serves as a dramatic demonstration of security issues to senior management, helping win buy-in for funding security initiatives. This means that testing should produce unambiguous results that balance business and technical considerations.

46.3.2 Attributes of Penetration Testing.

As mentioned, there is a wide range of possible activities that can fit into the general classification of penetration testing. As an exhaustive set of penetration test cases can be extremely expensive (and furthermore jeopardize normal business operations), it is critical to specify exactly what assets a penetration test team is to target and the techniques it is allowed to employ in its test activity.

Examples of attributes commonly associated with penetration testing include:

Testing models. Penetration testing can be conducted in the total absence of system information (also known as zero knowledge test scenarios) or, at the other end of the spectrum, with the test team provided with full documentation for both the systems and organization alike (full knowledge). Some security experts believe that the best penetration tests provide for a test team that is equipped not only with full knowledge of the systems involved, but also full risk modeling information for the enterprise.⁸
Scope of penetration testing. Penetration testing can include physical and communications exploits as well as system exploits. It can be designed to allow social engineering attacks, and, if so, specify to what degree these attacks will proceed.
Assumed level of sophistication of penetration testers. As in the real world of attackers, the sophistication of penetration team activities can vary widely. Novice attackers are usually less targeted than more expert attackers (i.e., marked more by shotgun or brute-force techniques, which are usually easier to detect). Expert attackers usually do more target surveillance and make far better uses of the information gathered. Finally, the goals of novice versus expert attackers usually differ, with experts usually focusing more on the business impact of attacks while novice attackers often settle for more visible targets (e.g., system defacement or other trophies of successful attack.)

46.3.3 Social Engineering.

As penetration testing usually tests procedural and physical security measures in combination with classic system protection, social engineering techniques are often included in the testing resources available to penetration test teams.

Social engineering is defined as the use of any of a number of techniques to induce employees or other authorized personnel to divulge confidential information that can then be used to gain illicit access to systems. Many of these techniques are used in classic criminal enterprise—thus their use in the context of penetration testing should be both constrained and accompanied by administrative measures to protect the testing team. For instance, before any social engineering techniques are used in a penetration test, the team should have signed statements from the client organization explicitly permitting the use of such techniques; the client staff should also be prepared for the use of social engineering techniques in the context of security testing.⁹

Examples of specific social engineering techniques sometimes used in security testing include:

Piggybacking. A test team member, in business attire, follows an authorized employee through badge-accessible door.
Shoulder surfing. A test team member, in business attire, loiters with organization employees outside an entrance, looking over their shoulders as employees enter a key code to unlock the door.
Faux service. Test team members, attired as service technicians, appear in an employee's office and ask for access to a system; if the employee resists, the test team makes veiled bureaucratic threats.
Dialing for passwords. Test team members, equipped with internal phone lists and an internal phone line, call employees, posing as system maintenance personnel, asking for password information.
Bribery. A test team member poses as a representative of a competitor, approaches an employee of the organization, and offers a significant bribe ($50,000) for information enabling an attack.¹⁰
Overload. Multiple members of the test team converge on an employee who can enable access to controlled area. Team members demand so many decisions of the employee that they start forcing simple decisions, (such as enabling access). In a common utilization of this technique, team members lock out specific accounts (by exceeding the number of failed logins) multiple times, then pressure system administrators to change the password to the account to a known value “until we have time to deal with this access issue properly.”
Fascination. Multiple members of the test team stage a play involving an employee charged with maintaining access control or another security function. The object of the play is to compel the employee to act in a fashion that is at odds with his or her security responsibility.
Bullying. In this, perhaps most extreme, technique, a test team member pulls rank on an employee (e.g., in military situations, presents himself as a senior officer) demanding that the employee honor a direct order to violate security policy.¹¹

46.3.4 Managing Penetration Testing.

Given the relatively unconstrained spirit associated with penetration testing, it is critical that the process be managed properly. Some of the requisite management considerations mirror those of the more generic process of VA. Independent oversight is required for the conduct of VA; it is especially critical to the success of penetration testing. Test scenarios should be documented and approved in advance by at least two representatives of the organization being tested, and the employees of the organization should be prepared for testing, especially when social engineering techniques are included in the scope of penetration testing.

This set of agreements and preparation for testing is key to balancing the need to perform realistic and relevant VA (including penetration testing) with the need to minimize the impact of such testing on normal business operations.

As human systems and constructs are as much a part of business operations as information systems, minimizing impact involves consideration of the ethics of social engineering. The first ethical tenet asserts that social engineering tests should not cause psychological distress to test subjects. Most employees are conscientious with regard to security and other company policies and may consider being targeted by social engineering tests as a breach of trust. Their reactions to that perceived breach may range from anger to resignation, or to a lawsuit.

Another ethical tenet states that those who fail social engineering or other penetration tests should not be subject to humiliation; this requires that test results be treated as confidential information. Finally, testers should not rely unduly on verbal misrepresentation or acting to achieve the goals of testing¹²—the objective of such testing is to establish whether security measures are appropriate and effective for the organization, not to score a win for the test team at all costs. To leave a tested organization in worse condition than the test team found it is a hollow victory for all involved.

46.4 FURTHER READING

Foster, J. C. Writing Security Tools and Exploits. Norwell, MA: Syngress, 2005.

Hurley, C. Penetration Tester's Open Source Toolkit, Vol. 2. Norwell, MA: Syngress, 2006.

Hurley, C. Wardriving & Wireless Penetration Testing. Norwell, MA: Syngress, 2006.

Manzuik, S., A. Gold, and C. Gatford. Network Security Assessment: From Vulnerability to Patch. Norwell, MA: Syngress, 2006.

Van Der Walt, C., H. D. Moore, R. Temmingh, H. Meer, J. Long, C. Hurley, and J. Foster. Penetration Tester's Open Source Toolkit. Norwell, MA: Syngress, 2005.

46.5 NOTES

1. D. Farmer and E. H. Spafford, “The COPS Security Checker System,” Proceedings of the Summer USENIX Conference, Anaheim, CA, June 1990, pp. 165–170, www.deter.com/unix/papers/cops.pdf.

2. D. Farmer and W. Venema, “Improving the Security of Your Site by Breaking into It,” Internet white paper, 1993, www.porcupine.org/satan.

3. www.nessus.org.

4. www.insecure.org/nmap.

5. J. Wack, M. Tracy, and M. Souppaya, “Guideline on Network Security Testing,” NIST Special Publication 800-42, National Institute of Standards and Technology (October 2003), http://csrc.nist.gov/publications/nistpubs/800-42/NIST-SP800-42.pdf.

6. A. Shostack and S. Blake, “Towards a Taxonomy of Network Security Assessment Techniques.” Proceedings of1999 Black Hat Briefings, Las Vegas, NV, July 1999, www.blackhat.com/presentations/bh-usa-99/AdamS/shostack-blackhat.pdf.

7. Siemens Insight Consulting, “Penetration Testing,” April 2006, www.insight.co.uk/files/datasheets/Penetration%20Testing%20(Datasheet).pdf.

8. G. McGraw, “Is Penetration Testing a Good Idea?” Network Computing, July 1, 2005, www.networkcomputing.com/showArticle.jhtml?articleID=164901611.

9. M. E. Kabay, “Social Engineering in Penetration Testing—Planning,” Network World Security Strategies, November 1, 2007, www.networkworld.com/newsletters/sec/2007/1029sec2.html.

10. M. Fisher and M. E. Kabay, “Penetration Testing, Part 3,” Network World Security Strategies, February 11, 2003, http://www.networkworld.com/newsletters/sec/2003/0210sec1.html.

11. P. Schumacher and M. E. Kabay, “Social Engineering in Penetration Testing—Intimidation,” Network World Security Strategies, November 8, 2007, www.networkworld.com/newsletters/sec/2007/1105sec2.html.

12. J. Orlando and M. E. Kabay, “Social Engineering in Penetration Testing: Analysis,” Network World Security Strategies, October 30, 2007, www.networkworld.com/newsletters/sec/2007/1029sec1.html.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for CHAPTER 46: VULNERABILITY ASSESSMENT

Create new playlist

Sign In

Sign Up

CHAPTER 46

VULNERABILITY ASSESSMENT

46.1 SCOREKEEPER OF SECURITY MANAGEMENT.