Critical Incident Management

Scan Modes | Nessus

2012-01-18T02:00:00.000-08:00

Nessus provides three types of checks or scan modes:

Discovery: This process uses basic discovery protocols such as ICMP echo request/reply and TCP sweeps to identify active hosts on the network. Some products today do not have the ability to simply perform a quick discovery but instead require a full audit. This capability represents a useful tool to narrow unknown network ranges when defining networks in a commercial product. Alternatively, similar functionality can be obtained using the command-line NMAP product.
OS fingerprinting: This is performed by a handful of methods that have already been described in this book. Simple malformed packets to legitimate SNMP queries are used to gather involuntary and voluntary information, respectively. These and other methods may not always work, depending on the target. Other vendors may have developed other means to gather this information.
Complete scans: This type of scan performs discovery and OS fingerprinting and adds numerous vulnerability checks, including brute-force password attacks. It is subject to all of the same limitations and concerns discussed previously in this chapter.

One other feature worth mentioning about Nessus is the availability of Web application checks. This capability is not available “out of the box” from many vendors. In many cases, one must pay extra for the feature. Nessus provides this without reservation. It requires some configuration to be relevant to the targets, but is certainly worthwhile. The user has the ability to test cross-site scripting (XSS), SQL injection, and Common Gateway Interface (CGI) vulnerabilities.

Nessus is a capable product with a greater level of control compared to most other products. However, it lacks the scalability of many commercial offerings because it’s a very centralized approach to scanning. All scans take place from a central location rather than having many physically distributed scanners with a central data-collection point. However, it may be well-suited to many business/IT architectures and quite suitable at a good price point.

Advantages and Disadvantages of Nessus

2012-01-13T08:00:00.000-08:00

Nessus is a popular open-source scanner for organizations that choose not to spend the money on other proprietary products. There are significant advantages to Nessus over many other products but there are also some disadvantages.

ITEM	ADVANTAGE	DISADVANTAGE
Single server performs scans and captures results to a database	High-performance capture of data with minimum results reporting impact on the network.	Forces centralized server architecture where all scans take place from a single server.
Open-source product	Low cost of ownership. Can be customized by the end user with technical knowledge.	No support without extra fee. Requires greater knowledge to install and operate the product.
The user can compile binary	Operates on multiple platforms: OSs/CPUs.	Requires strong knowledge about the target systems and open-source software.
Optimized version of Nessus is recommended for scanning Windows XP SP2 platforms to avoid false negatives	Scalability problem: If your organization has a mix of architectures (e.g., Linux and Windows), then it is possible that two versions may come into use, or you are better off using a Windows version.
Professional feeds provide immediate updates	Receiving immediate updates for latest vulnerabilities is obviously good.	You must pay for this but the cost is likely the same or cheaper than other products.
Home feeds provide free vulnerability updates	This is a good way to get started evaluating the tool.	This is not for commercial use.
Plug-ins	These elements of Nessus allow for extensibility and customization commonly beyond what other products offer.	The increased complexity requires considerable knowledge and experience to deploy.
NASL^[*]	This tool allows the user to script and run specific vulnerability checks. These checks provide a lot of control where most products do not.	Knowledge of NASL and how to use it at the command line is necessary.
^[*] Nessus Attack Scripting Language

Security Content Automation Protocol (SCAP)

2012-01-10T04:54:00.000-08:00

SCAP

Security Content Automation Protocol (SCAP, pronounced “ess-cap”) is an overarching suite of the aforementioned standards that include CVE, CVSS, CPE, XCCDF, and OVAL. The NIST maintains the SCAP content, which defines how all of these protocols work together in an automated fashion. It also contains the content of all of these standards in the NVD.

SCAP also has a product validation program to assist in evaluating products for compatibility with the various open standards. NIST provides detailed descriptions of the validation areas, abbreviated here to give you a sense of the possible areas of validation:

Federal Desktop Core Configuration (FDCC) scanner: A product with the ability to audit and assess a target system in order to determine its compliance with the FDCC requirements, which were the result of the U.S. government OMB Memo M-07-18. That memo states that the provider of information technology shall certify applications are fully functional and operate correctly as intended on systems using the FDCC.
Authenticated configuration scanner: A product with the ability to audit and assess a target system to determine its compliance with a defined set of configuration requirements using target system log-on privileges.
Authenticated vulnerability and patch scanner: A product with the ability to scan a target system to locate and identify the presence of known software flaws and evaluate the software patch status to determine compliance with a defined patch policy using target system log-on privileges.
Unauthenticated vulnerability scanner: A product with the ability to determine the presence of known software flaws by evaluating the target system over the network.
Intrusion detection and prevention systems: Products that monitor systems or networks for unauthorized or malicious activities. An IPS actively protects the target system or network against these activities.
Patch remediation: The ability to install patches on a target system in compliance with a defined patching policy.
Misconfiguration remediation: The ability to alter the configuration of a target system in order to bring it into compliance with a defined set of configuration recommendations.
Asset management: The ability to actively discover, audit, and assess asset characteristics, including installed and licensed products; location within the world, a network, or an enterprise; ownership; and other related information on IT assets such as workstations, servers, and routers.
Asset database: The ability to passively store and report on asset characteristics, including installed and licensed products; location within the world, a network, or an enterprise; ownership; and other related information on IT assets such as workstations, servers, and routers.
Vulnerability database: A product that contains a catalog of security-related software flaw issues labeled with CVEs where applicable. This data is made accessible to users through a search capability or data feed and contains descriptions of software flaws, references to additional information (e.g., links to patches or vulnerability advisories), and impact scores.
Misconfiguration database: A product that contains a catalog of security-related configuration issues labeled with CVEs where applicable.
Malware tool: The ability to identify and report on the presence of viruses, Trojan horses, spyware, or other malware on a target system.

When a product is assessed and validated, it is for one or more of these areas. The status of validation of products is posted on the NIST’s public Web site. Being validated does not assure quality or reliability of the product; only that it meets the criteria set forth by the SCAP program.

National Vulnerability Database

2012-01-06T01:50:00.000-08:00

NVD

The National Vulnerability Database is an online database operated by the NIST. It can be found at http://nvd.nist.gov/nvd.cfm. The NVD uses the Security Content Automation Protocol (SCAP). This protocol is a set of standards designed to support automation of VM, compliance management, and other security functions. We have already discussed some of those standards, which include OVAL, CVE, and CVSS. There are three items we have not discussed: CCE and CPE, which concern target enumeration, and XCCDF, which provides checklists for target evaluation and standard formats for reporting.

CCE refers to Common Configuration Enumeration identifiers. These are identifiers used to correlate checks performed on system configurations with documents and tools that provide related information. CCE identifiers will not be discussed in depth except to suggest reviewing the CCE lists provided by Mitre Corporation.

CPE

Common Platform Enumeration identifiers provide a standard naming scheme for technology systems and components. In practical VM terms, CPE identifiers are used to indicate what systems or components are subject to a particular vulnerability. When a new vulnerability is announced, “which systems are vulnerable?” is the first question that is asked. CPE is intended to clearly document a platform so that applicability of a vulnerability announcement is easily determined through both automated and human methods.

A particular computer system can be assigned a CPE name, which represents the complete enumeration of that platform in terms of what is installed. This includes the hardware, the OS, and applications. It does not include detailed configuration options such as the status of particular switches or security policies. So, the first thing that might occur to you is that there are millions of combinations that can be enumerated. This is quite correct, but CPE has a basic requirement that addresses this issue. If a vulnerability is announced for CPE name “cpe:/o:microsoft:windows_xp::sp2,” then a system enumerated with a CPE name like “cpe:/a:microsoft:office:2003::standard” is subject to that vulnerability. This is a “grouping” approach to enumeration of systems subject to vulnerabilities, which in CPE parlance is called a prefix property. The enumeration of a platform typically requires multiple CPE names since a platform can be composed of many parts.

1 Encoding

The encoding of CPE names is logically structured just as described in the previous section: hardware, OS, and application. The encoding format follows the URI format although it is not officially recognized by IANA, the governing body for Internet assigned numbers typically found in URLs. This format is used for convenience and to leverage an established convention that works well for naming a resource on the Internet. Here is the basic structure of a CPE name:

cpe:/ {part} : {vendor} : {product} : {version} : {update} : {edition} : {language}

So, there are seven parts to this format:

Part: The part is defined as either hardware “h,” operating system “o,” or application “a.” The people at MITRE have left the door open for other parts as well, such as driver “d.”
Vendor: This is usually specified as a portion of the domain name for the vendor. So, Mozilla.Org would have the vendor name Mozilla. Strictly speaking, it is the highest organization level of the DNS name of the vendor. If there is more than one organization with this DNS name, then the entire DNS name is used.
Product: CPE uses an abbreviation for the product provided by the vendor. It is common for computer users to use “IE” to indicate Internet Explorer. So, this is the abbreviation used.
Version: This is a version number for the product. For example, “5.0.”
Update: These are specific updates that may be applied by the vendor to a particular version. Use of fields becomes pretty sporadic, depending on how the vendor issues releases and updates. Some vendors tend to have smaller port releases (versions) to perform updates.
Edition: The edition field is typically used to distinguish among the various flavors of a product. So, Windows Vista^® would have several editions such as Home Basic, Home Premium, Business, and Ultimate.
Language: Intuitively, this is the language used in the target CPE name. This makes it easier to identify systems that are vulnerable based on their installed language pack.

2 Examples of CPE Names

Obviously, cpe:/a:adobe:flash_player:1.1 represents Adobe Reader version 8.1.1. But the specification is not specific to the OS. Any vulnerability using the name would apply to all version 8.1.1 instances of Adobe Reader on any OS. If we modify the name to apply only to Windows XP, then we could use the following name: cpe:/a:adobe:flash_player:9.0.20.0::windows_xp. If a specific OS is to be named for a vulnerability (e.g., Windows XP, all versions), then the following name would be used: cpe:/o:microsoft:windows_xp. However, if we wanted to be more specific (e.g., Windows XP SP1 Pro), we would use cpe:/o:microsoft:windows_xp::sp1:professional.

Hardware is identified in a similar fashion: cpe:/h:cisco:ip_phone_7960 represents a Cisco iPhone^® model 7960. Notice that the model number, and not a version, is built into the product. This is because Cisco has chosen to represent product versions with a different model number. When identifying hardware, it is possible not only to identify a computer system but also a specific motherboard such as the Intel D845WN (cpe:/h:intel:d845wn_motherboard).

XCCDF

Earlier, we discussed the need to standardize the vulnerability testing methods using OVAL. Also, we have discussed how a data structure might look in a vulnerability scanner. Similarly, the Extensible Configuration Checklist Description Format (XCCDF) is an XML-based set of documents that specify checklists for validating security compliance for various types of target systems. XCCDF also specifies a standard format for reporting compliance and scoring. This simplifies the interoperability of various security systems. It is not a substitute for OVAL, but rather a supporting technology that can actually extend OVAL and enhance its interoperability with proprietary technologies.

XCCDF has a primary use case in the definition of compliance checks, compliant machine states, and results reporting. The language is designed to allow for the definition of security benchmarks that are reflected in detailed configuration item settings. Checks can be developed and submitted to the NIST checklist program for review. If accepted, the checks will be available to anyone in the world who supports XCCDF in their product. This happens to be very few vendors. XCCDF is primarily used in U.S. government security in support of NIST publication 800-53 and FIPS 199. The big benefit is that a standard mechanism has been created to validate and report security compliance to checklists and rules across multiple vendors and security systems. XCCDF supports the idea of VM as an integrated part of configuration management.

At first, you might think that any such language must be confining when it comes to defining checks and scoring. However, XCCDF is designed to be customizable and flexible for achieving consistent results for a variety of systems. For example, one option is “selectability.” A particular XCCDF document will contain a set of rules describing the state of a target in order to be compliant. Those rules can be selectively turned on or off (selected), depending on the target under scrutiny. Similarly, parameters can be substituted to accommodate flexible rules. For example, the size of an encryption key for a VPN configuration may be 256 bits for a system communicating insignificant data, and 4096 bits for one carrying sensitive information.

XCCDF has four types of objects:

Benchmark is a master container for everything else in the document. It is similar to the definitions in OVAL.
Item is similar to an object or test in OVAL. It contains a description and identifier. There are three types or classes of item: group (holds other items), rule (holds checks, scoring weights, and remediation information), and value (provides the previously mentioned substitution ability).
Profile provides references to item objects. It contains many of the values needed for a particular profile of a system. This significantly helps apply asset classification to the values applied to the rules where appropriate.
Test result holds the results of the test performed. Most significant in this object are the “rule-result” and “target-facts” elements. This object contains the actual results of the tests performed and is very informative during reporting and remediation processes. The target-facts information can be sensitive information about the actual result of the test against the target that resulted in compliance or non-compliance.

An interesting attribute of XCCDF is that it can reference the content of OVAL in a rule. A child element of a rule called “check” allows the document author to reference the system from which a check is obtained. For example, ‘’ is then followed by the specific reference of the check within the source system: ‘. This is only a reference to the OVAL rule and not the actual rule. Software that performs the checks will have to properly interpret and execute these references. The use of OVAL is not a requirement for any system unless the goal is SCAP compliance.

Overall, XCCDF is a great idea for standardizing configuration compliance checks across vendors and organizations. However, its use is mostly restricted to the U.S. Department of Defense. If you work for the government or are a vendor, more details can be found in the document entitled “Specification for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.1.3 (Draft)” by Neal Ziring and Stephen D. Quinn.

The Standard for Vulnerability Severity Rating

2012-01-02T08:48:00.000-08:00

A very important part of evaluating a vulnerability is knowing the impact or risk to the organization. Many vendors have their own evaluation methods. But, there must be some standard with which all software makers and vulnerability researchers can agree on the criteria for rating severity. The Common Vulnerability Scoring System (CVSS) was developed to provide a standard framework for assessing the impact of a vulnerability and its basic characteristics. Although the contents and methodology are not the complete picture, they help to assess risk by doing much of the technical work in advance by the Forum of Incident Response and Security Teams (FIRST). FIRST is a non-profit group of vendors, researchers, and other volunteers who work to enhance security incident response practices.

CVSS provides relevant vulnerability metrics that the user can look at and quickly determine whether further action is necessary to address risk. These metrics are organized into three groups: base, temporal, and environmental. For each of these groups, a score is calculated. Each group has metrics that are combined to calculate the score for that group. Figure 1 shows the relationships among the metric groups, metrics, and equations. You can follow this discussion by referring periodically to the figure. For clarification, items indicated with dashed lines are subequations or subgroups that only provide intermediate values or logical groupings of metrics.

Figure 1: Metric relationships in the Common Vulnerability Scoring System (CVSS).

Base metrics are constant. They are fundamental and do not change over time. The metrics of the base group are access vector (AV), access complexity (AC), authentication (AU), confidentiality impact (C), integrity impact (I), and availability impact (A). As any CISSP^® should know, confidentiality, integrity, and availability (CIA) form the triangle of security, and so it is no surprise they should be included here.

Each of these metrics of the base metrics group has a value, depending on the severity or impact. For example, AV indicates what kind of access an attacker must have for the vulnerability to be exploited. If the vulnerability requires that the attacker be physically present and touch the keyboard (i.e., local access), then the value of this metric is 0.395. If the vulnerability can be exploited over the network (i.e., remote access), then the value of this metric is 1.0. This process is repeated for all of the metrics that apply to the vulnerability. The CIA metrics together are referred to as impact metrics and are combined in calculations to determine the total impact, which is then applied in equations for the base score. The equations are where all the work is performed to produce a total score for the group.

The reasons for the particular value of the metrics involves an understanding of the relative effect an exploit would have and how significant that metric is in the calculation of the score for the group. The greater the effect, the higher the value. But, not all metrics are created equal. AVs may be more important to the overall severity of a vulnerability than complexity of the exploit. The difference between low complexity (0.35) and high complexity (0.71) is 0.36. But, the difference between requiring local access (0.395) and network accessibility (1.0) is 0.605. AV, AC, and AU are three base metrics that work together to determine the overall exploitability (E) of a vulnerability. The equation for exploitability is E = 20 * AV * AC * AU. This may seem like a lot of trouble but the formulas and values of the metrics have already been worked out for you and save a lot of time.

Temporal metrics are optional and have values that can change over time. Base metrics are used as input into the “temporal” calculations and yield a score that may more accurately reflect the risk on a scale of 0 to 10. For example, a vulnerability may be in the proof-of-concept phase, which is less of a threat, and therefore is assigned a value of 0.9. As time passes, an automated script may become widely available that makes exploitation so simple a script kiddie can do it. Then, the value is 1.0 for this metric. The temporal equation uses a case function that adjusts the impact calculation from the base equations by multiplying by the previously mentioned metrics. Table 1 details the CVSS metrics and their values. Note that each value also has a numerical score not shown in the table. These numerical scores are subject to change as equations, described later, are refined.

Table 1: CVSS Metrics
METRICTYPE	CVSSMETRIC	DESCRIPTION	VALUE
Base	AccessVector	Requires local access	0.395
		Adjacent network accessible	0.646
		Network accessible	1.0
	AccessComplexity	High	0.35
		Medium	0.61
		Low	0.71
	Authentication	Requires multiple instances of authentication	0.45
		Requires single instance of authentication	0.56
		Requires no authentication	0.704
	ConfImpact	None	0.0
		Partial	0.275
		Complete	0.660
	IntegImpact	None	0.0
		Partial	0.275
		Complete	0.660
	AvailImpact	None	0.0
		Partial	0.275
		Complete	0.660
Temporal	Exploitability	Unproven	0.85
		Proof-of-concept	0.9
		Functional	0.95
		High	1.00
		Not defined	1.00
	RemediationLevel	Official-fix	0.87
		Temporary-fix	0.90
		Work-around	0.95
		Unavailable	1.00
		Not defined	1.00
	ReportConfidence	Unconfirmed	0.90
		Uncorroborated	0.95
		Confirmed	1.00
		Not defined	1.00
Environmental	CollateralDamagePotential	None	0
		Low	0.1
		Low–Medium	0.3
		Medium–High	0.4
		High	0.5
		Not defined	0.0
	TargetDistribution	None	0
		Low	0.25
		Medium	0.75
		High	1.0
		Not defined	1.0
	ConfReq	Low	0.5
		Medium	1.0
		High	1.51
		Not defined	1.0
	IntegReq	Low	0.5
		Medium	1.0
		High	1.51
		Not defined	1.0
	AvailReq	Low	0.5
		Medium	1.0
		High	1.51
		Not defined	1.0

The environmental metric group is another optional one that can be very useful. The metrics in this group are designed to work outside of, but as a complement to, the other metric groups. This group has no effect on the weight of the other metrics if it is not used. It is there for you, the CVSS user, to employ as you see fit. It is, however, structured with guidelines so that it is uniformly interpreted. The environmental metrics group includes collateral damage potential (CDP), target distribution (TD), and security requirements: confidentiality (CR), integrity (IR), and availability (AR). It also factors-in an adjusted impact score from the base metrics and an adjusted temporal score.

CDP is a classic risk-management-style metric that measures how much financial damage or death and injury damage potential exists should the vulnerability be exploited. In risk management terms, it is single loss expectancy (SLE). For those who are not formally trained security professionals, the SLE in risk management is how much you expect it to cost should a loss occur one time. Although it is a measure of damage potential, CDP is a scale from 0 to 0.5 and it does not equate to a dollar amount.

TD is the measure of what percentage of the organization is vulnerable. This helps you to assess the scope of the threat in your environment. If 50 percent of the target hosts have a particular vulnerability, then this metric is considered to have a value of medium. When the TD is calculated in an equation, high = 1.0, medium = 0.75, low = 0.25, none = 0.0, and interestingly, not defined = 1.0. This is interesting because if you don’t know the TD, the assumption should be “high,” which allows for conservative estimates of damage potential. I recommend that if you know the exact distribution of hosts with a vulnerability in your organization based on the results of a vulnerability assessment, then use this percentage in an exact decimal form. This approach is outside of the CVSS guidelines but it is more precise than the high/medium/low approach.

The environmental security requirements metrics are unique. These metrics create a weight to the base metrics for CIA. If your particular environment puts a high value on the confidentiality of data, for example, then the value is increased. If the value is medium, the weight of C is neutral. The security requirements are used to reweight the impact (I) metric calculation in the base score. This modifies the base metric group score according to the requirements of your organization. However, if an impact metric from the base group is 0 (i.e., not a factor), then the resulting modified impact score will be unaffected. This is because the equation for modified impact metrics includes a multiplication of the security requirement and the impact value from the base group:

where AdjustedImpact = min(10,10.41 * (1–(1–ConfImpact * ConfReq) * (1–IntegImpact * IntegReq) * (1–AvailImpact * AvailReq))).

For each of the metric groups, an equation has been designed to calculate a score based on a set of mathematical rules. The equations are based on a rationale that varies depending on the type of metric. The merits of each of these equations is widely analyzed and debated and is of little benefit to discuss here. CVSS is explained in more detail at http://www.first.org/cvss/cvss-guide.html.

If you want to calculate your own CVSS scores, you can try some Web-based calculators. One popular calculator can be found at http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2. You can enter whatever values you like and receive a set of CVSS scores. To understand the impact of a particular metric on the overall score, try changing only one and then recalculate. You will begin to get a feel for what score is good and what is really bad. I also suggest that you omit the environmental components so that you can become familiar with the CVSS scores you will find in the NVD

The Standard for Vulnerability Test Data

2011-12-18T09:09:00.000-08:00

Typically, the vulnerability information used by a particular vendor of a VM scanner or analyzer is stored in a database that is designed to work seamlessly with the software. Since standards are usually a few to several years behind industry, none of these databases are alike. The vulnerability data and method of identification vary widely from one product to another—that is, there is no standard.

However, MITRE has driven the idea of a standard for just this type of data structure. It is called the Open Vulnerability and Assessment Language or OVAL^®. As the name implies, it is a language that is structured using XML to record the details of the state of a machine (target) that has a particular vulnerability. It employs the state machine approach to identifying a vulnerability, which is a highly structured way of indicating the vulnerable state and the non-vulnerable state. So, let’s examine the OVAL process in Figure 1 to understand its benefits.

Figure 1: The OVAL process.

We start with the security researcher who discovers a new vulnerability in product X. Having firsthand knowledge of the vulnerability and how it can be identified in a vulnerable target, the researcher encodes the details of that vulnerability in an OVAL-standard-formatted XML document. This document describes exactly how to identify the vulnerability on a target by providing the information of the state of particular items that constitute a vulnerable machine. This method of vulnerability identification is called a test.

Definitions Schema

At a higher level, OVAL consists of three types of documents called schemas. The definitions schema is used to encode the state of various parts of a computer system that must exist in order to be subject to a particular vulnerability. For example, a target system may need to have a Windows 2003 server with Service Pack (SP) 2, IIS, and anonymous Web access configured to be vulnerable to vulnerability XYZ. These schemas provide the framework for encoding such conditions.

Other definitions exist to capture other important information to help round out the VM process. Patch definitions record the specific conditions that must be present in order to be eligible for a patch. The idea is to avoid haphazardly applying patches to a system inappropriately. So, the ability is provided to specify, for example, that a vulnerability that is fixed by Windows 2003 SP 2 is only applied when the target system is in fact Windows 2003 and has only SP1 installed. The patch definition capability can go far beyond this, but this understanding is sufficient for the scope of this book.

An OVAL inventory definition is just what it sounds like: a description of what defines a particular inventory item. If you want to specify that the SNMPv3 service is installed on a router, certain items must be checked to be certain it is present. The inventory definitions provide the XML schema to achieve exactly this. Since vulnerability scanning and automated configuration discovery are so closely related, it makes sense that OVAL should include this capability.

One additional area where the VM industry has very sensibly gone is compliance management. The MITRE team has understood this, and OVAL includes a schema for compliance definitions. Similar to the other schema, compliance specifies the conditions under which a system is compliant with a particular policy. Again, this is a natural extension to VM tools and processes.

System Characteristics Schema

This schema is designed to provide a standard definition of target system characteristics. These system characteristics, once collected, can be analyzed to identify vulnerabilities. When all of the target characteristics are collected, the vulnerability analyzer would compare them to the details in the definitions data to discover vulnerabilities. The design of the system characteristics schema is roughly parallel to that of the definitions schema. Although this schema is vulnerability focused, it also amounts to a list of configuration items in a configuration management database.

Results Schema

This third and final high-level schema is designed to provide a standard structure for recording the results of the vulnerability assessment. The primary benefit is that once a vulnerability is discovered, the details are captured in a format that many other security tools can interpret to properly apply patches, update configurations, initiate change processes, and take other mitigation actions as necessary. The results schema very specifically captures the details of a particular vulnerability on a specific target.

Nuts and Bolts^[*]

In the OVAL specification, tests are formatted in the OVAL definitions schema and are defined by a tag. Tests are recorded using three key XML elements: , which is the item being tested; are the values of the objects to be tested; and are the tests to be performed against those objects using the previously mentioned . An ID is assigned to each definition, object, state, and test using a notation resembling reverse DNS entries. Let’s take a look at a partial example of an OVAL definition, which is a check to see whether Windows XP^® is installed. This is an abbreviated ver sion, so we do not spend time on details that are not instructive on this topic:

------------------------------------------------
1
2 version="3" class="inventory">
3
4 Microsoft Windows XP is installed< title> 5 <reference source="CPE" ref_id="cpe:/ o:microsoft:windows_xp"/> 6 <description> The operating system installed on the system is Microsoft Windows XP. </ description> 7 </metadata> 8 <criteria operator="AND"> 9 <criterion comment="the installed operating system is part of the Microsoft Windows family" test_ref="oval:org.mitre. oval:tst:99"/> 10 <criterion comment="a version of Microsoft Windows XP is installed" test_ref="oval:org. mitre.oval:tst:3"/> 11 </criteria> 12 </definition> 13 </definitions> 14 <tests> 15 <family_test id="oval:org.mitre.oval:tst:99" version="1" comment="the installed operating system is part of the Microsoft Windows family" check_existence="at_least_one_exists" check="only one"> 16 <object object_ref="oval:org.mitre. oval:obj:99"/> 17 <state state_ref="oval:org.mitre.oval:ste:99"/> 18 </family_test> 19 <registry_test id="oval:org.mitre.oval:tst:3" version="1" comment="a version of Microsoft Windows XP is installed" check_existence="at_ least_one_exists" check="at least one"> 20 <object object_ref="oval:org.mitre. oval:obj:123"/> 21 <state state_ref="oval:org.mitre.oval:ste:3"/> 22 </registry_test> 23 </tests> 24 <objects> 25 <family_object id="oval:org.mitre.oval:obj:99" version="1" comment="This is the default family object. Only one family object should exist."/> 26 <registry_object id="oval:org.mitre.oval:obj:123" version="1" comment="Registry key that hold the current windows os version"> 27 <hive>HKEY_LOCAL_MACHINE</hive> 28 <key>SOFTWARE\Microsoft\Windows NT\Current Version</key> 29 <name>CurrentVersion</name> 30 </registry_object> 31 </objects> 32 <states> 33 <family_state id="oval:org.mitre.oval:ste:99" version="1" comment="Microsoft Windows family"> 34 <family>windows</family> 35 </family_state> 36 <registry_state id="oval:org.mitre.oval:ste:3" version="1" comment="The registry key value is 5.1"> 37 <value>5.1</value> 38 </registry_state> 39 </states></blockquote><blockquote><definitions><definition <br="" id="oval:org.mitre.oval:def:105"><metadata><title>Microsoft Windows XP is installed< title> 5 <reference source="CPE" ref_id="cpe:/ o:microsoft:windows_xp"/> 6 <description> The operating system installed on the system is Microsoft Windows XP. </ description> 7 </metadata> 8 <criteria operator="AND"> 9 <criterion comment="the installed operating system is part of the Microsoft Windows family" test_ref="oval:org.mitre. oval:tst:99"/> 10 <criterion comment="a version of Microsoft Windows XP is installed" test_ref="oval:org. mitre.oval:tst:3"/> 11 </criteria> 12 </definition> 13 </definitions> 14 <tests> 15 <family_test id="oval:org.mitre.oval:tst:99" version="1" comment="the installed operating system is part of the Microsoft Windows family" check_existence="at_least_one_exists" check="only one"> 16 <object object_ref="oval:org.mitre. oval:obj:99"/> 17 <state state_ref="oval:org.mitre.oval:ste:99"/> 18 </family_test> 19 <registry_test id="oval:org.mitre.oval:tst:3" version="1" comment="a version of Microsoft Windows XP is installed" check_existence="at_ least_one_exists" check="at least one"> 20 <object object_ref="oval:org.mitre. oval:obj:123"/> 21 <state state_ref="oval:org.mitre.oval:ste:3"/> 22 </registry_test> 23 </tests> 24 <objects> 25 <family_object id="oval:org.mitre.oval:obj:99" version="1" comment="This is the default family object. Only one family object should exist."/> 26 <registry_object id="oval:org.mitre.oval:obj:123" version="1" comment="Registry key that hold the current windows os version"> 27 <hive>HKEY_LOCAL_MACHINE</hive> 28 <key>SOFTWARE\Microsoft\Windows NT\Current Version</key> 29 <name>CurrentVersion</name> 30 </registry_object> 31 </objects> 32 <states> 33 <family_state id="oval:org.mitre.oval:ste:99" version="1" comment="Microsoft Windows family"> 34 <family>windows</family> 35 </family_state> 36 <registry_state id="oval:org.mitre.oval:ste:3" version="1" comment="The registry key value is 5.1"> 37 <value>5.1</value> 38 </registry_state> 39 </states></blockquote></div><div class="informalexample" id="N109"><pre class="programlisting" id="265-1" style="font-family: 'Courier New', Courier, mono; margin-top: 0.4em; max-width: 800px; overflow-x: auto;"><definitions><definition class="inventory" id="oval:org.mitre.oval:def:105" version="3"><metadata><title>Microsoft Windows XP is installed< title>5 <reference source="CPE" ref_id="cpe:/ o:microsoft:windows_xp"/>6 <description> The operating system installed on the system is Microsoft Windows XP. </ description>7 </metadata>8 <criteria operator="AND">9 <criterion comment="the installed operating system is part of the Microsoft Windows family" test_ref="oval:org.mitre. oval:tst:99"/>10 <criterion comment="a version of Microsoft Windows XP is installed" test_ref="oval:org. mitre.oval:tst:3"/>11 </criteria>12 </definition>13 </definitions>14 <tests>15 <family_test id="oval:org.mitre.oval:tst:99" version="1" comment="the installed operating system is part of the Microsoft Windows family" check_existence="at_least_one_exists" check="only one">16 <img src="http://img2.blogblog.com/img/video_object.png" style="background-color: #b2b2b2; " class="BLOGGER-object-element tr_noresize tr_placeholder" id="BLOGGER_object_8" data-original-id="BLOGGER_object_8" />17 <state state_ref="oval:org.mitre.oval:ste:99"/>18 </family_test>19 <registry_test id="oval:org.mitre.oval:tst:3" version="1" comment="a version of Microsoft Windows XP is installed" check_existence="at_ least_one_exists" check="at least one">20 <img src="http://img2.blogblog.com/img/video_object.png" style="background-color: #b2b2b2; " class="BLOGGER-object-element tr_noresize tr_placeholder" id="BLOGGER_object_9" data-original-id="BLOGGER_object_9" />21 <state state_ref="oval:org.mitre.oval:ste:3"/>22 </registry_test>23 </tests>24 <objects>25 <family_object id="oval:org.mitre.oval:obj:99" version="1" comment="This is the default family object. Only one family object should exist."/>26 <registry_object id="oval:org.mitre.oval:obj:123" version="1" comment="Registry key that hold the current windows os version">27 <hive>HKEY_LOCAL_MACHINE</hive>28 <key>SOFTWARE\Microsoft\Windows NT\Current Version</key>29 <name>CurrentVersion</name>30 </registry_object>31 </objects>32 <states>33 <family_state id="oval:org.mitre.oval:ste:99" version="1" comment="Microsoft Windows family">34 <family>windows</family>35 </family_state>36 <registry_state id="oval:org.mitre.oval:ste:3" version="1" comment="The registry key value is 5.1">37 <value>5.1</value>38 </registry_state>39 </states></pre></div><a name="266" id="266" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a><a name="IDX-120" id="IDX-120" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a><div class="section" id="ch04lev3sec90"><h4 class="sect4-title" id="annotationlabel-1" style="margin-top: 0.9em; margin-bottom: 0em; color: rgb(1, 1, 0); "> </h4><h4 class="sect4-title" id="annotationlabel-1" style="margin-top: 0.9em; margin-bottom: 0em; color: rgb(1, 1, 0); "><a name="267" id="267" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a><a id="ch04lev3sec90" name="ch04lev3sec90" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a>1 <Definitions></h4>In this example, there are a few basic components to know: definitions, tests, objects, and states. These are the high-level containers for the parts of a vulnerability check. The definitions come in four different classes as previously described: vulnerability, patch, inventory, and compliance. This example indicates in the “class” that it is an inventory definition in line 2. Line 3 is a metadata tag. This begins a descriptive section that can be used by vulnerability assessment software for the end user who may not need to know exactly what happens in this test. The title and description are not the most significant items here. Notice in the metadata there is a reference source in line 5. This refers to a CPE name. This CPE name will be explained later, but for now suffice it to say that this is a specification for a system enumeration.The ultimate goal in this example is to determine whether Windows XP is installed on a target system. The tests, objects, and states that are compared will evaluate to a true or false answer.<a id="268" name="268" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a><a id="IDX-121" name="IDX-121" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a>The criteria tag showing the value of “operator” set to “AND” is on line 8. This is a fundamental breakdown of the logic to be applied in the vulnerability check. If X AND Y, then the result is true. In other words, the result of all tests will have a logical AND operation applied. Following that on lines 9 and 10 are the two criterion type statements to which the operator is applied.Each criterion or “criteriontype” has a comment and a “test_ref” reference. This reference points to the details of the test that is to be performed. If the criterion is to be negated, then another item is added within the specific criterion statement. This is the “negate = ‘true’” statement within the criterion. If this is omitted from the criterion type, the value is assumed to be “false” or not negated.One other item to know about the criterion as in this example: the first criterion indicates that the test referenced as “oval:org.mitre. oval:tst:99” should be performed. This is a reverse-DNS-style notation showing that the test is from <a href="http://www.oval.mitre.org/" class="url" target="_top" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; color: rgb(0, 0, 128); ">oval.mitre.org</a> and is number 99. All of these references start with the word “oval” followed by org.mitre. oval. Since it is a test, the letters “tst” follow. Finally, a colon and an integer of at least one digit is included. Combined, this pattern forms a unique identifier. It is referred to as a “testIDpattern.”</div><div class="section" id="ch04lev3sec91"><h4 id="annotationlabel-2" class="sect4-title" style="margin-top: 0.9em; margin-bottom: 0em; color: rgb(1, 1, 0); "> </h4><h4 id="annotationlabel-2" class="sect4-title" style="margin-top: 0.9em; margin-bottom: 0em; color: rgb(1, 1, 0); "><a id="269" name="269" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a><a id="ch04lev3sec91" name="ch04lev3sec91" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a>2 <Tests></h4>After all of the tests are specified in the criteria of a definition, then a new section begins, indicated by the <tests> tag. In this section, the first and very common element is the “family_test” on line 15. Notice that immediately following this element is an ‘id=“oval:org.mitre.oval:tst:99.”’ This is the item to which the earlier criterion reference was pointing. What follows are the objects and states to be compared. If the result of the comparison is true, then this is used in the previous definition to evaluate whether the results meet the goal of the definition. Also in the family_test element are “check_existence=” and “check=.” These are set to the values “at_least_one_exists” and “only one” respectively. This means that there must be exactly one check but no more. In this case, we will check object 99 against state 99, as indicated on lines 16 and 17.Then, there is one more test to be performed. In this case, it is a registry test on line 19. Lines 20 and 21 are the object and state to be checked. In this case, it is object number 123 and state number 3.<a id="270" name="270" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a><a id="IDX-122" name="IDX-122" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a></div><div class="section" id="ch04lev3sec92"><h4 class="sect4-title" id="annotationlabel-3" style="margin-top: 0.9em; margin-bottom: 0em; color: rgb(1, 1, 0); "> </h4><h4 class="sect4-title" id="annotationlabel-3" style="margin-top: 0.9em; margin-bottom: 0em; color: rgb(1, 1, 0); "><a id="271" name="271" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a><a id="ch04lev3sec92" name="ch04lev3sec92" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a>3 <Objects></h4>The objects section defines the objects to be tested. In this case, “oval:org.mitre.oval:obj:99” is the reference which is a “family_object” on line 25. This means that the object defines a particular system. It is referenced only by a “family_test” as on line 16. The point is to identify whether the target system is Windows, Mac OS X, UNIX, etc.The next object is a “registry_object.” This type of object applies only to the Microsoft Windows registry key system. That system has three components: <hive>, <key>, and <name>. If you have ever browsed the Windows registry, you will recognize these details. The structure and function of the Windows registry is beyond the scope of this book. It is sufficient to say that the values specified on lines 27, 28, and 29 are the values used to identify the particular item in the Windows registry that we need to test.</div><div class="section" id="ch04lev3sec93"><h4 class="sect4-title" id="annotationlabel-4" style="margin-top: 0.9em; margin-bottom: 0em; color: rgb(1, 1, 0); "> </h4><h4 class="sect4-title" id="annotationlabel-4" style="margin-top: 0.9em; margin-bottom: 0em; color: rgb(1, 1, 0); "><a id="272" name="272" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a><a id="ch04lev3sec93" name="ch04lev3sec93" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a>4 <States></h4>Finally, we have the states, which contain the values needed to test the objects. The first item is the “family_state,” which defines the state of the family of computer system. In the example on line 33, the “family_state” tag tells us that we are dealing with family state number 99. You may recall that the “family_test” described earlier references this state on line 17. Back on line 34, the simple value of the “family” is set to “windows.”The one and final state to be defined is the state of the previously mentioned registry key specified in the object on line 26, also known as object 123. To clarify, we are testing that object number 123 (the registry key) has a state number 3 (value 5.1). On line 36, we define the “registry_state” element with a value found on line 37.The following summarizes, in a more natural-language style, what the definitions, objects, states, and tests do in this example:<div class="informalexample" id="N178"><pre class="programlisting" id="272-4" style="font-family: 'Courier New', Courier, mono; margin-top: 0.4em; overflow-x: auto; max-width: 800px; ">----------------Definition: Inventory (line 2) This is a Windows OS (test 99, line 9) AND (line 8) Windows XP is installed (test 3, line 10)Test 3: Test the Windows family (line 15) Which has object 99 (line 16) and state 99 (line 17)Test 99: Test Windows XP Which has object 123 (line 20) and state 3 (line 21)Object 99: family_object (line 25)Object 123: registry_object (line 26) Which is "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows NT\CurrentVersion\CurrentVersion" (lines 27, 28, and 29)State: family_state (line 33) Which is Windows (line 34)State: registry_state (line 36) Which has the value 5.1 (line 37)------------------</pre></div><a id="273" name="273" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a><a id="IDX-123" name="IDX-123" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a>Since some tests cannot be performed using a single <state> value, another type of <state> is available in a section called <variables>. This allows the end user to select the value that would constitute compliance.The folks at MITRE recognized that they could not be everything to everyone, so they made OVAL extensible using a special XML tag in a <metadata> section.The vulnerability scanner uses a collection of these XML documents to identify a vulnerability in a particular target. Before making the comparison, the scanner assesses the state of the target machine and records this state information in a similarly formatted XML document. Then, an analysis is performed using the vulnerability state information and the target state information. The system state information is collected in a format called the OVAL System Characteristics Schema. This XML document has the configuration data for a target system. Having a standard format helps to standardize communication of this information to other systems. For example, system characteristics could be useful in a configuration management tool or an SEIM.If a vulnerability scan were to result in the identification of a vulnerability, then that fact and related details are recorded for further processing. It is after this analysis/results step that the real vendor-distinguishing features can be built. But first, the process of identifying the vulnerability is standardized for consistent results. The results are reported consistently by the specification of an XML schema similar to the OVAL definitions schema called, not surprisingly, the OVAL Results Schema.Note that OVAL only supports authenticated tests that require authorized access to the target. This is a necessary limitation since there may be many innovative ways to perform unauthenticated checks.</div></div></div><div class="footnotes" style="font-family: Arial, Helvetica, sans-serif; text-align: left; background-color: rgb(255, 255, 255); font-size: small; "><div class="footnote" id="ch04footnote05"><a id="264" name="264" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; "></a>[<a href="http://www.books24x7.com/assetviewer.aspx?bookid=30514&chunkid=665099775&noteMenuToggle=0&leftMenuState=1#ch04footnote05" name="ftn.ch04footnote05" style="text-decoration: none; outline-style: none; outline-width: initial; outline-color: initial; ">*</a>] This discussion assumes that you have a basic understanding of HTML and XML. Specifically, you should know how XML tags are constructed. It is also helpful to understand the general idea of an object in the object-oriented design sense of the word.</div></div>

Common Vulnerabilities and Exposures | CVE

2011-12-15T06:27:00.000-08:00

Once vulnerability information has been collected, it must be categorized and evaluated. The methods of evaluation and categorization vary by vendor. This is one key area where many products attempt to distinguish themselves. When a vulnerability is identified, the category is typically assigned according to the type of exploit required or the level of access that is granted. For the purposes of this discussion, we will avoid any vendor-specific approaches and use MITRE’s CVE methodology. According to MITRE’s Web site:

CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this common enumeration.

Structure

MITRE is a non-profit organization that has been making a valuable contributions to VM for years. They have been able to provide an open, standardized platform for the sharing of vulnerability knowledge. When someone discovers a new vulnerability, they frequently (but not always) report this discovery and its details to MITRE, who quickly publishes the information. Unfortunately, standards are still difficult to get adopted in products.

Every CVE is given an identifier. In effect, this identifier allows a variety of tools from different vendors to speak the same language. A CVE provides the same description for all vendors and the same references to additional information sources. For example, “CVE-2001-0010: Buffer overflow in transaction signature (TSIG) handling code in BIND 8 allows remote attackers to gain root privileges.” This is the same understanding for everyone. It cannot be confused among various vendors.

The references in the CVE will ultimately lead a vulnerability manager to the National Vulnerability Database (NVD) run by the NIST. CVE-2001-0010, mentioned earlier, has related information in the NVD, as shown in Figure 1:

Overview: This is a summary of the vulnerability that resembles the CVE description.
Impact: The impact section attributes a score to the vulnerability should it be exploited. More on this later when we discuss the Common Vulnerability Scoring System (CVSS).
References to advisories, solutions, and tools: These are typically Internet references to obtain more-detailed information about the vulnerability, how to detect it, and how to remediate. In this example, information about patches from various vendors is supplied.
Vulnerable software and versions: A list of the version numbers that are known to possess this vulnerability. This further helps with the detection process.
Technical details: This is information about the exact nature of the vulnerability; for example, how the software will react when exploited and why this is bad. Again, this item usually contains links to the site where the researcher has published information about his discovery.

Vulnerability Summary CVE-2001-0010

Original release date: 2/12/2001

Last revised: 5/2/2005

Source: US-CERT/NIST

Overview

Buffer overflow in transaction signature (TSIG) handling code in BIND 8 allows remote attackers to gain root privileges.

Impact

CVSS Severity (version 2.0 incomplete approximation):

CVSS v2 Base score: 10.0 (High) (AV:N/AC:L/Au:N/C:C/I:C/A:C) (legend)

Impact Subscore: 10.0

Exploitability Subscore: 10.0

Access Vector: Network exploitable

Access Complexity: Low

Authentication: Not required to exploit

Impact Type: Provides administrator access, Allows complete confidentiality, integrity, and availability violation , Allows unauthorized disclosure of information , Allows disruption of service

References to Advisories, Solutions, and Tools

CERT/CC Advisory: CA-2001-02

Name: CA-2001-02

Type: Advisory , Patch Information

Hyperlink: http://www.cert.org/advisories/CA-2001-02.html

External Source: Security Focus (disclaimer)

Name: bid 2302

Type: Advisory , Patch Information

Hyperlink: http://www.securityfocus.com/bid/2302

External Source: PGP Security (disclaimer)

Name: Vulnerabilities in BIND 4 and 8

Type: Advisory , Patch Information

Hyperlink: http://www.pgp.com/research/covert/advisories/047.asp

External Source: REDHAT (disclaimer)

Name: RHSA-2001:007

Hyperlink: http://www.redhat.com/support/errata/RHSA-2001-007.html

External Source: NAI (disclaimer)

Name: 20010129 Vulnerabilities in BIND 4 and 8

Hyperlink: http://www.nai.com/research/covert/advisories/047.asp

External Source: DEBIAN (disclaimer)

Name: DSA-026

Hyperlink: http://www.debian.org/security/2001/dsa-026

Vulnerable software and versions

Configuration 1

IS, BIND, 8.2.2 P7
IS, BIND, 8.2.2 P6
IS, BIND, 8.2.2 P5
IS, BIND, 8.2.2 P4
IS, BIND, 8.2.2 P3
IS, BIND, 8.2.2 P2
IS, BIND, 8.2.2 P1
IS, BIND, 8.2.2
IS, BIND, 8.2.1
IS, BIND, 8.2

Technical Details

Vulnerability Type No vulnerability type mapping is available.

CVE Standard Vulnerability Entry:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0010

Common Platform Enumeration:

http://nvd.nist.gov/cpe.cfm?cvename=CVE-2001-0010

Figure 1: CVE-2001-0010.

Notice that CVEs are identifiers and not actual technical details. The main purpose of a CVE is to provide a cross-platform standard for identification of vulnerabilities. To support the quality of this identification mechanism, each vulnerability is subjected to a review process. At first, candidate status is given. This status means that the information is out there but has not been granted CVE status. A CVE editorial board discusses the merits of the candidate and votes on whether or not the vulnerability should receive full CVE entry status.

There are some caveats to the CVE database. First, it is not a vulnerability database. It is a database of vulnerability references. Second, it does not include all known vulnerabilities. It only contains those that are publicly known. So, it is possible that a vulnerability exists of which a vendor or researcher is aware but it does not appear in the CVE list. In some cases, this is because the researcher has agreed with the maker of the software that he will not reveal the vulnerability until a public patch has been released. Naturally, the researcher will want credit for the discovery.

To continue our CVE discussion, CVEs have one of two statuses: candidate or entry. An editorial board must vet the proposed vulnerability prior to it being granted entry status. Until that time, the vulnerability has candidate status. This status is provided on the CVE list when you view the details. When reading a CVE, check this status and review the reference to form your own opinion about the credibility and accuracy of information provided.

Limitations of CVE

CVE has definite limitations and is by no means an answer to all standards issues related to VM. As previously mentioned, CVE does not have a comprehensive list of all vulnerabilities in existence. Some vendors are able to identify vulnerabilities that CVE does not seem to record. Also, it does not necessarily contain all of the metadata needed to make a vulnerability system perform all of the functions that a technology vendor wishes to perform. Naturally, it shouldn’t since it is intended to provide the common-denominator information useful to everyone.

CVE is not always kept up to date. Many vulnerabilities remain in “CAN” or candidate status for years. One wonders if these vulnerabilities will ever be updated when they are known to be accurate. It is possible that some of these are configuration best practices but not necessarily to be considered vulnerabilities. Inversely, CVE does not contain all product best-practice configuration vulnerabilities since they are too numerous to review and include for the many thousands of products in use around the world.

Inference Scanning | Vulnerability Management

2011-12-11T05:26:00.000-08:00

One final method of scanning that is seldom used exclusively for vulnerability identification is inference scanning. This method involves the analysis of data that has already been obtained for another purpose to detect the presence of a vulnerability. For example, a configuration management system may have collected detailed configuration data on targets throughout an organization. The inference scanning process would use non-intrusive methods that involve reading the configuration details from the asset database and analyzing them for vulnerabilities. Easy examples of this are discreet configuration items such as SNMP community string or vulnerability application versions.

Since inference scanning is based on factual information provided during the normal course of gathering configuration data, the reliability of an identified vulnerability is very high. Also, because the vulnerability detection process is not performed by actively probing the host on the network, there is no impact to the target. When used strictly by itself, inference scanning is not always reliable or complete since it would not involve verification by other means. It can, however, be used to augment the previously mentioned scanning processes or as an additional feature to a configuration management product. Furthermore, inference techniques can be used architecturally to make vulnerability scanning more efficient. For example, an active vulnerability scanner might collect all of the possible vulnerability information and record it for analysis; then, the inference engine would be used to analyze that data for vulnerabilities in the host. In a later phase, certain vulnerabilities would be flagged for verification by other means before being given the designation of vulnerable. Overall, inference scanning is a valuable tool but is not sufficient to deliver the most complete, reliable results on its own.

Hybrid Approach | Vulnerability Management

2011-12-08T00:05:00.000-08:00

Combining more than one solution for VM from different vendors can be helpful in responding more quickly and thoroughly to emerging vulnerabilities. However, normalizing the output may be difficult. If you are fortunate enough to deploy more than one type of technology from the same vendor, then perhaps a unified console will eliminate this problem.

Alternative approaches are to allocate the assessment resources by organization or network. For example, it may be beneficial to use passive vulnerability scanners on a public DMZ in order to get 24-hour coverage of the security posture of the hosts. This most current assessment information can be automatically fed to a security event/incident management system (SEIM). This provides a significant advantage, for newly published vulnerabilities can be taken into account quickly when new events occur to exploit them. Active vulnerability scanners can obtain more in-depth analysis of the back-end systems and workstations where rapid response may not be as critical.

The combination of agents in DMZs and active scanners in the internal network is an excellent choice. The agents are positioned on DMZ hosts so that it is unnecessary to actively scan through the network security systems, which would otherwise require a more complex configuration. Additionally, regular audits or penetration tests of the DMZ should be conducted and agents serve as a substitute for the regular monitoring provided by active scanning.

Performance Matters | Active Scanning Technology

2011-12-03T01:30:00.000-08:00

During a scan, the goal of the scanner is to get as complete and accurate a scan as possible. However, the performance and behavior of that scan is also important to the vulnerability manager. Ideally, we would like to scan as much as possible during an allotted time window and get complete results. However, we also want to avoid affecting production operations. First, let’s look at the potential negative impacts to production and how we might avoid them. Then, we can look at ways to optimize scans.

In most cases, there are four ways in which a scan can adversely affect a production environment:

By consuming bandwidth, preventing other applications from meeting service levels.
By consuming target CPU resources in an already-busy target. Again, this can cause service levels to be missed.
By breaking a target application or OS, causing a DoS and requiring the target to be repaired.
By breaking a component that is facilitating the scan but is not a target. Various network components could be adversely affected by the scan process even though they are not the subject of a scan.

Bandwidth is consumed by network activity. During the scan process, parameters provided by the vulnerability manager are used to size the footprint on the network. Not only is bandwidth a factor, the number of simultaneous connections can affect intermediate devices as well. Since TCP is so commonly used, a connection is established with each target. In some cases, a connection is only attempted, leaving potentially half-open connections. Devices that track the state of connections such as firewalls, IPSs, and possibly routers, can be affected by these connections. The total number of simultaneous connections, and the rate at which these connections are made, may have an effect. Limits on both will go a long way towards maintaining good relations with network management staff.

The most efficient location in the scanner to impose these limits is the IP protocol stack and interface drivers. Bandwidth limitations are best performed at the interface driver, whereas the connections limits are better applied at the packet-creation phase where the outgoing connections table is maintained. Exceptions must be made to accommodate the critical command and control functions of the scanner. Therefore, the location of the scanner management system should be exempt from such limits.

Bandwidth consumption has the biggest impact on the network when scanning is performed outside of the local segment to which the scanner is connected. In particular, WAN links can be impacted significantly. Using today’s most cost-effective technology, most scanners are not able to produce more than 10 Mbps of bandwidth in a typical scan. However, when a T1 is the only connection from a remote office back to the corporate WAN where the scanner resides, it is easy to saturate the link event with a small scan. In most companies, it is often necessary to perform such a scan during work hours when desktop and laptop computers are powered on and connected to the network. So, the impact to business operations is significant.

To determine the appropriate amount of bandwidth to allow for a given target network, I recommend the following strategy:

Determine the peak utilization of the WAN link over a two-month period to coincide with the time in the business cycle during which you plan on running the scan. Alternatively, plan to run the scan during a time in the business cycle when bandwidth consumption is relatively low but the targets are still available for scanning.
Agree with the local business manager and network operations manager on how much of the remaining bandwidth you will be permitted to use. Set expectations when making this agreement.
Perform a test scan of the target network for five or more typical target hosts to gauge how much bandwidth is required. This number will have to be scaled up to derive a more accurate number. One caveat: the accuracy of this estimate will increase when the test scan can more closely reach a maximum number of connections. Sometimes, limiting the number of connections will reduce the maximum bandwidth consumed, and in other cases, it will not. It will all depend on the configuration of each target. Given the highly dynamic nature of a scan, the amount of testing should be commensurate with complexity and variability of the environment and level of criticality of the WAN link to business operations. This is both art and science.
Always position the scanning activity as a critical security function that will ultimately provide reports and analysis to the IT and network managers at the site. They should want this as much as you do. In a site with critical hosts, it may be worth purchasing a small amount of additional bandwidth that is dedicated to performing the scans.

Simultaneous connections, on the other hand, are fairly straightforward to manage. As previously mentioned, this parameter may affect bandwidth. The primary goal is not to overwhelm the target or the intervening network and security infrastructure. Even at low bandwidth, small packet sizes and half-open connections can generate a sizable number of simultaneous connections. Since a firewall maintains a state table for each connection, it must perform a little more CPU work for each connection. Large commercial firewalls that typically front a public Web site generally have sufficient resources to handle huge numbers of connections. However, this is not always the case. Firewalls are complex devices running many simultaneous processes. Furthermore, they are mostly single-threaded applications, which limits their performance scalability. Just as DoS attacks are performed on routers by exploiting the reliance of certain features on notoriously limited CPU resources, a scanner can do the same to a firewall. Most of these scenarios can be addressed with the following guidelines:

Test the impact on a firewall under load for a variety of targets. Different targets can generate different connection rates. Monitor the firewall CPU reaction closely. The reaction is not linear. In some cases, packet forwarding latency may result. In other cases, it just takes longer to set up and tear down connections. Manufacturer performance specifications do not apply to traffic generated by vulnerability scanners.
Test scanning against targets where the firewall applies additional distributed DoS and intrusion prevention capabilities. Since firewalls typically interact with the environment at OSI layer 3 and above to provide these services, the firewall may interpret a scan as a threat. It could be blocked or the results of the scan clouded. This is because the firewall features can act like a proxy for a given application. TCP connection attempts will be terminated by the firewall and then re-established from the firewall to the target only after the handshake is completed with a sanitized upper-OSI-layer result. Any probing performed with a SYN-SYN/ACK-ACK that is not fully completed by the scanner may appear to be an active host where none exists. A solution to this is to configure the firewall to allow the scanner source traffic to bypass all of the firewall inspection filters.
Routers can also be affected. Some routers use their limited processor power to handle invalid TCP flag combinations. This is a common probing or discovery technique used by vulnerability scanners to fingerprint the OS or application. It is also a method for performing a DoS attack against a router. Although it is unlikely that a scanner will generate enough malformed traffic to have a major impact on network devices, you should be mindful of the possibility.
Simulate the typical latency on a WAN circuit in the lab during a scan. This will help gauge scan performance as well as impact to production systems. Some vendors provide tools that can use a packet capture from a network segment and a performance profile, and then re-create the user experience with the scan traffic and any given application injected. For example, an accounting system could be placed on one side of such a device while the scanner is on the other side. The device simulates the traffic conditions at a peak time for a particular office using a previously gathered profile.
Limit the number of TCP and UDP ports that are scanned during discovery and scanning. The tendency is to be as comprehensive as possible because you are not sure what will be found. This may work for an initial scan of a limited number of hosts. But later, you should settle on an acceptable number of ports to minimize the impact on the environment and maximize effectiveness. This is an area with diminishing returns on port numbers scanned at a logarithmic rate. You may also find that reducing the number of ports scanned will substantially lighten the bandwidth load. This is because packets can be large and numerous.

Web Application Testing

With so many competitive pressures, it was inevitable that organizations would have to find a way to distinguish themselves in the online world. So, millions of custom applications have been built to deliver customer service and application services that add value beyond original core competencies. It naturally follows that hackers would find common ways to exploit these applications, especially because they are more closely linked to valuable data. What has made these applications even more exploitable is their dependence on standard technologies and infrastructure. This is not intended as a criticism, only an observation. For example, most databases in use today are based on the SQL language. Also, many Web applications use JavaScript™. Both of these technologies are exploitable, depending on their method of implementation. No inherent security controls can be configured to prevent their exploitation at the application level.

An even greater concern is the exploitability of the open-source PHP language. It is commonly used to build Web applications and yet has many critical vulnerabilities around which the programmer must code. Since this powerful scripting language is closely integrated with the Web page and user interaction, and since it has so many powerful commands with great flexibility, exploitation is very possible.

Naturally, this Web application phenomenon presents another area of vulnerability testing. These checks have become increasingly important, as customer applications have become the primary focus of the serious hacker. There are simple methods to exploit vulnerabilities by simply manipulating the content of the URL in the Web browser. It is also quite easy to manipulate inputs on fields on the screen. So, vulnerability checks must do the same thing in many combinations using many common techniques to replicate possible attack vectors. Following is a list of some of the most common vectors:

Input field manipulation: This involves modifying the input of one or more fields on the screen beyond what is expected by the software in normal operation. Many programmers fail to validate these inputs for size and value boundaries as well as validity. Hackers exploit this by entering characters that will cause the application to process them in a way not originally intended.
SQL injection: This very popular attack vector is used to manipulate the database query language of the back-end database programming to reveal information or even modify the database contents. The process is started by entering the partial SQL string (‘ or 1=1—) in an input field without the parentheses will extend an underlying SQL statement to detect the presence of an unfiltered field and the fact that the SQL language is in use and accessible. This works because the first tick mark (‘) ends the current input string expected by the SQL code and then adds the logic “or 1=1.” The remaining portion tells the SQL server to ignore the remainder of the SQL statement. This is a harmless modification of the SQL query that will determine whether SQL injection is even possible. Vulnerability scanners will perform more in-depth penetration acts to reveal more details about the flaws in handling this input, including what can be discovered about the database configuration.
Cross-site scripting (XSS): This extension of input field manipulation is used to inject JavaScript into a Web site that will appear on other users’ browsers and perform actions against other users of the system. These actions include but are not limited to directing user input to another site, capturing user data, and presenting false information. The script information can be combined with a SQL injection attack to store malicious script code in the database of the target system. When this information is retrieved by the Web application for a user, then the script is loaded into that user’s Web browser and executed to fulfill the purposes of the attacker.

So Web application checks are available in many VM systems to detect the presence of these vulnerabilities in the code of a Web site. There are other products that analyze the actual programming code, but they are no substitute for the hacker-mimicking process of attacking the application from the outside. By their very nature, these checks are brute force but usually non-destructive. The application checks are run against every field, every hyperlink, and every possible URL of a Web site. The following are more types of checks that can be performed against applications:

Boundary check: This is a test of a range of values that are accepted by an application. It is applied to every field that is found and applies values that can be below, above, and within the range of permitted values, as well as trivial values that are outside of the expected data types. For example, an 8-bit ASCII numeric field may have 16-bit Unicode data entered. This is also called stress testing.
Branch test: This program is used to check all of the links and possible paths to be taken in an application. The goal is to achieve as close as possible to 100 percent branch coverage, meaning that every possible program pathway is exercised. This is partly a discovery process and partly a vulnerability identification process. Some vulnerabilities in this area are the result of branches of code that are so obscure they are seldom accessed. Because of this, it is possible that some code is vulnerable because it was never tested.
Brute force: This type of check is typically used against user ID and password fields. It differs from a boundary check in that there is a large practical range limit for what can be entered. A password field that is eight alphanumeric characters long, for example, has 8**36 possible combinations.
Buffer overflow: This type of check is designed to challenge the target software for scale factors; that is, those inputs whose range affects the allocate memory space. Two types of scale factors can be tested: buffer definition and buffer usage. For example, if a program is designed to accept a certain size of input and store it in a memory buffer, a larger input can cause a buffer overflow. This is an example of a buffer usage scale factor, which occurs when an entered parameter directly or indirectly determines the allocated buffer space. If the parameter causes the creation of buffer smaller than the input size, then the buffer can overflow on the corresponding input.
Code injection: In many scripting languages, it is possible to accept code as a parameter passed from one process to another. Programmers use this technique to efficiently reuse code or pass advanced parameters from one program to another. Some faults in a program can allow the inadvertent introduction of code by accepting instruction-terminating characters to be entered into a field. This is similar to SQL injection attacks.
Session hijacking: HTTP is a stateless protocol. That means that it receives transactions over the network but does not know that the transaction is part of a particular user’s session. To keep track of this session or “state,” a file called a session cookie is implemented. There are various checks that can be performed to determine whether the session cookie can be manipulated to become a different user, and therefore gain access to that user’s data.

All of these tests, however, are typically used alone when run automatically. This is a key distinguishing factor between vulnerability testing and penetration testing. A person conducts basic reconnaissance testing using these application-vulnerability scanning tools, and then combines the results to form augmented attacks with more revealing results. For example, an SQL injection attack can be used to insert malicious code to obtain another user’s session cookie. Then, the session cookie, encrypted or not, can be used to obtain that user’s information or change his password to gain his privileges.

Application Fingerprinting: Banners | Active Scanning Technology

2011-11-30T07:50:00.000-08:00

An important activity in a scan is to determine what applications make themselves known on the network. Similar to OS fingerprinting and IP stack fingerprinting, a vulnerability scanner can attempt to connect to a variety of possible applications on known or unknown ports, a process known as featureprinting. Among the best-known featureprinting methods is banner checking.

Some common applications on systems produce a banner whenever you attempt to connect. The contents of this banner can provide valuable information in determining the version of the OS and the software running on the host. This type of fingerprinting can often be performed by an individual using a simple program available on almost all OS platforms: Netcat.

Let’s take the example of a Web server. Figure 1 shows a typical Netcat session. When using Netcat, you can specify the TCP port to which you wish to connect. So, in the command line, we type “nc 10.1.1.10 80.” This will run the Telnet application and establish a connection to the server listening for connections on port 80.

$ nc 10.1.1.10 80                  Apache Example 
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 06 May 2008 23:32:00 GMT
Server: Apache/2.2.8 (Unix)
Last-Modified: Tue, 29 Apr 2008 21:52:29 GMT
ETag: "ea9d61-48f6-44c0a0c71a140"
Accept-Ranges: bytes
Content-Length: 18678
Cache-Control: max-age=86400
Expires: Wed, 07 May 2008 23:32:00 GMT
Vary: Accept-Encoding
Connection: close
Content-Type: text/html
$_

(a)

$ nc 10.1.1.20 80                    IIS Example 
HEAD / HTTP/1.0

HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 142
Content-Type: text/html; charset=utf-8
Location: /en/us/default.aspx
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD
TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
X-Powered-By: ASP.NET
Date: Tue, 06 May 2008 23:58:41 GMT
Connection: keep-alive
$_

(b)

Figure 1: A typical Netcat session.

From here, we are able to issue a command to the remote server. Since this is port 80, it is likely a Web server; so we issue the command: “HEAD/HTTP/1.0” (Figure 1a). The server responds with some detailed header information, which tells the type of Web server software and OS. In this case, it is Apache^® running on a UNIX^® system. This eliminates the possibility of any version of Windows and makes searching for vulnerabilities much easier.

For security reasons, however, server administrators should conceal this header information, particularly that information which is in the “Server” section. But, that will not deter a good vulnerability scanner. The scanner may also be able to check for the type of Web server by making an invalid request. By using an invalid version type in the HEAD command, we can see different responses from the various Web server makers. Notice that the Apache Web server comes out with a “400 Bad Request” message (Figure 1b). The connection also gets closed; however, on IIS 7.0, the connection is not closed but the same “400 Bad Request” message is received. But, you will also notice that more server information is provided that was not found in the valid request. In earlier versions of IIS, you could distinguish it from a reaction of providing a message of “200 OK.” Similar methods are used where valid and invalid responses are captured and analyzed. In some cases, these are reported as vulnerabilities or simply information exposures.

Fingerprinting with TCP/IP

2011-11-26T02:32:00.000-08:00

A simple method of fingerprinting is to use the well-understood ICMP. ICMP packets are used to monitor the state of an interface on a host or report the status of access to a connected device. Nine message types are available: four for making queries and five for reporting errors. Each type is defined by a number, as shown in Table 1. PING is a very popular program that sends ICMP type 8 messages. Type 8 is an echo request whereas a type 0 is an echo reply. In addition to an ICMP type, there is a code that is used to report more information about an error. By manipulating these codes into invalid values, the target’s response or failure to respond can be captured. This in itself can tell us something about the OS. Some systems do not look at the code field on an echo request. Others do and respond with an error.

Table 1: ICMP Types
ICMP CODE	TYPE
0	Echo reply
1–2	Unassigned
3	Destination unreachable
	Code	Meaning
	0	Net unreachable
	1	Host unreachable
	2	Protocol unreachable
	3	Port unreachable
	4	Fragmentation needed and don’t fragment was set
	5	Source route failed
	6	Destination network unknown
	7	Destination host unknown
	8	Source host isolated
	9	Communication with destination network is administratively prohibited
	10	Communication with destination host is administratively prohibited
	11	Destination network unreachable for type of service
	12	Destination host unreachable for type of service
	13	Communication administratively prohibited
	14	Host precedence violation
	15	Precedence cutoff in effect
4	Source quench
5	Redirect
6	Alternate host address
7	Unassigned
8	Echo
9	Router advertisement
10	Router selection
11	Time exceeded
	Code	Meaning
	0	Time to live exceeded in transit
	16	Fragment reassembly time exceeded
12	Parameter Problem
	Code	Meaning
	0	Pointer indicates the error
	1	Missing a required option
	2	Bad length
13	Timestamp
14	Timestamp reply
15	Information request
16	Information reply
17	Address mask request
18	Address mask reply
19–29	Reserved
30	Traceroute
31	Datagram conversion error
32	Mobile host redirect
33	IPv6 Where-Are-You
34	IPv6 I-Am-Here
35	Mobile registration request
36	Mobile registration reply
39	SKIP
40–254	N/A

Another method of reconnaissance is known as IP fingerprinting. The concept is an elegant form of manipulating inputs into the protocol stack of a target and measuring the results. For a brief review, let’s look at the TCP header structure in Table 2.

Table 2: TCP Segment
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 SOURCE PORT DESTINATION PORT SEQUENCE NUMBER ACKNOWLEDGEMENT NUMBER Header Length Reserved URG ACK PSH RST SYN FIN Window Size Checksum Urgent Pointer Options (up to 40 bytes) End of Option Data

Table 2: TCP Segment

                     0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15                                   16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31

                                             SOURCE PORT                                                                                      DESTINATION PORT

                                                                                           SEQUENCE NUMBER

                                                                                  ACKNOWLEDGEMENT NUMBER

Header Length       Reserved    URG      ACK    PSH       RST     SYN       FIN                                             Window Size
                                                 Checksum                                                                                            Urgent Pointer
                                       Options (up to 40 bytes)                                                                                                                     End of Option
                                                                                                        Data

The most useful operational benefit of TCP is the fact that it guarantees delivery by acknowledging the receipt of each packet. That set of flags—SYN, ACK, and RST—are what tell the recipient the purpose of what is transmitted. Our vulnerability scanner is sending SYN packets to the target. But it is the behavior of the rest of the contents of the packet that can reveal something about the target. Sequence number is a good example. So that TCP listeners on hosts do not become confused, every packet includes a sequence number. Since the creation of the protocol, it was found that it is easily possible to “wrap” the sequence numbers because they are of limited size (32 bits). To address the potential for wrapping and having a duplicate sequence number with an old packet being mistaken for a sequence number of a new packet, a time-stamp option was introduced in RFC 1323. This is an optional field and not all operating systems’ TCP/IP implementations set the value. When the scanner sees such value sent when the time-stamp option was never used, the choice in operating systems is narrowed considerably.

Another phenomenon to measure is the incrementing of the time stamp. By first determining the RTT between the scanner and the target, you then know how much time should elapse between TCP segments. The remote OS will increment the time stamp on each segment by a certain value. The way in which the target increments the value can reveal the type of OS.

For example, we know that OS XYZ increments the time stamp by one for every 500 ms of uptime. The average RTT between the target and the scanner is 100 ms, which is 50 ms in each direction, as shown in Figure 1. We receive the first segment with a time stamp (TS1) of 100. We acknowledge this segment and start a timer. The second segment with a time stamp of 102 (TS2) arrives and we stop the clock. The elapsed time between segment 1 and segment 2 is 1100 ms. We know that the time in transit for the segments is 100 ms. So the clock value, 1100, minus the RTT, 100, gives us 1000 ms of elapsed time on the host between segments. The difference between TS2 and TS1 is 2. This means that, in 1000 ms, the time-stamp value went up by two, which is 500 ms per time-stamp increment. Looking at a table of time-stamp values over time, we know that the target has incremented the time stamp by one for every 500 ms, which is OS XYZ. This technique combined with other fingerprinting methods will ultimately narrow the choice of OSs. This choice is important in determining future steps of vulnerability scanning.

Figure 1: The average round-trip time (RTT) between the target and the scanner is 100 ms, which is 50 ms in each direction.

Invalid flag combinations are another approach. The normal combinations, SYN, SYN-ACK, and ACK, are expected. But various host OSs react strangely to combinations such as FIN+URG+PSH, which is a combination not seen in a normal handshake. It is referred to as an Xmas or Christmas scan because it lights up the TCP flags like a Christmas tree. Another combination that can possibly fingerprint an OS is SYN+FIN. In addition to host discovery, these types of scans can determine whether a port is open on a host without establishing a TCP connection or half-open connection. That is because IP stacks that adhere to the RFC will respond with an RST packet if the port is open. If closed, there will be no response from the host.

Use of these flags can get more sophisticated as well. If it has already been established that a port is open using a harmless TCP-SYN scan, the same port can be probed with a FIN-ACK combination. It turns out that systems implementing the IP stack from Berkley Standard Distribution (BSD) will not respond according to the RFC with an RST packet. This provides more evidence as to the likely system type of the target.

By combining these and many other types of probes, a decent guess can be made as to the type of system. The work for this has been well-established by the creators of NMAP (www.nmap.org). They continue to discover new ways to scan and map targets on a network and build those techniques into their open-source tool. A little reading and experimentation with this can be very educational.

However, the topics of OS fingerprinting and IP stack fingerprinting can be tricky, unreliable, and confusing. Some OSs may share the same IP stack code but be different OS versions. For example, a variety of Linux distributions will use the same stack but this does not necessarily reveal the flavor of the OS. Virtual machine technology can further cloud the issue because the underlying hypervisor OS may respond to network traffic and proxy the connection to the actual host OS. The fingerprinting result can be quite unexpected. Firewall and virtual machines can perform network address translation (NAT) that will conceal the true nature of the target OS.

Performance Issues | Active Scanning Technology Detection Methods

2011-11-23T07:45:00.000-08:00

We have discussed at some length the process of identifying ports and handling TCP connections. All of these factors have to be taken into consideration during the scan; however, the scanner cannot wait too long. At some point, the transaction attempt will “time out.” This phenomenon can be referred to as discovery tolerance. Various vendors have different levels of discovery tolerance. The amount of tolerance is loosely proportional to the accuracy of the discovery with rapidly diminishing probability of successful identification. Fortunately, we know from experience that there is no point waiting for a reply beyond a certain amount of time. Determining that point is the real skill in any fingerprinting activity. The goal is to be complete and accurate, but there is a law of diminishing returns. Two key timers affect the speed of the discovery process: the connection establishment timer and the retransmission timer.

For many TCP implementations, the connection establishment timer (TCP_KEEPINIT parameter) waits 75 seconds for response. A simple scan on a single port for 200 hosts would require over four hours to complete if none of the hosts responded. This must be adjusted to wait far less time. One effective approach is to take the maximum roundtrip time (RTT) of ICMP echo reply exchanges and add two seconds. This provides ample time for an application to respond on the required port and is likely to be far shorter than the default of 75 seconds.

With TCP connections, a discovery process can also vary the retransmission timer when additional packets are to be exchanged with the target. In normal communications, the timer begins with a value of 1.5 seconds. If no response is received, then the value is doubled to three seconds. If there is still no SYN-ACK, the timer is doubled again and we wait six seconds. This continues repeatedly until we reach a limit of 64 seconds. The process is called exponential backoff (EB). In theory, this should parallel the exponential probability that a response will ultimately be received. However, this is often impractical for host discovery purposes in vulnerability scanning. A typical OS can spend several minutes waiting for a connection to time out.

A more practical approach would be to sequentially increase the retransmission timer by smaller values for a total period of time to be some factor above the average for the target IP range. For example, let’s suppose that we are performing a discovery of network A (192.168.10.0/24) with an upper limit of 30 seconds for retransmission. If the first 16 hosts required an average of 10 seconds to respond and the mode was five seconds, we might start our retransmission timer at five seconds and increase the value by five seconds until an upper limit of 20 seconds was reached (2× average). This is a more sensible approach that will avoid a common IP stack value that can reach several minutes for a single connection. Remember that our goal is discovery of open ports and live hosts, not the reliable transmission of data to another host.

There is one other item that can be manipulated, which is not exactly a timer and can speed the discovery process considerably:

to implement all the timers TCP only requires that two functions are called periodically: (1) the fast timer is called every 200 ms and (2) the slow timer every 500 ms. TCP uses these two periodic ‘ticks’ to schedule and check all the timers described…as well as measuring round trip times.^[*]

Basically, the OS kernel must check every 200 ms to see if an acknowledgment has been received. In modern networks and operating systems, this is a very long time.

By decreasing this period, the discovery processes can recognize that the probing SYN packets it has sent have been acknowledged in a shorter time, and move on to the next probe. If the RTT from SYN to SYN-ACK is 10 ms, then under normal circumstances, the discovery process can wait for up to 190 ms to proceed with the next action. Multiply this number by hundreds of hosts and dozens of ports, and the wasted time can be tremendous.

The one caveat to modifying TCP timers is that some applications are simply slow to respond. This approach works best when probing for open ports but not necessarily for applications. There is a lot of room for creativity in scan performance optimization. This section simply illustrates some of the challenges designers can be confronted with when trying to optimize the scan process and minimize the impact on the network.

1 Black Box Testing

Once the presence of a host has been established and that presence recorded in the memory of the scanner, a series of tests or “checks” are performed to find vulnerabilities. The types of checks are dependent upon the type of host and the configuration of the scanner. Generally, two types of checks are performed. A network-based or surface check is performed, which involves the probing and analysis of what is evident with limited or no access to services on the machine other than what is offered to any other peer on the same network as that which exists between the scanner and the target. This is also known as an unauthenticated check. The other type of check is an authenticated, internal check or white box test. It is performed when the scanner is given special information and credentials to access details of the host, which are generally reserved for trusted entities.

The difference between surface and internal checks is obviously significant not only in the way they obtain information, but also in the value and quality of that information. Clearly, more detailed data can be obtained by logging into a host and perusing its configuration. Although the information tells us a lot about the host, it does not typically represent the view of an attacker who performs reconnaissance on an unknown host. Although valuable from an analysis standpoint, some attacks take place by probing the host from the view of an outsider; therefore, information that can be obtained in the same fashion is often more valuable. To summarize, a vulnerability discovered and exploitable from outside a host represents a greater exposure than if the same vulnerability could only be discovered and exploitable from a credentialed or internal check.

There is a common perception that authenticated checks are more accurate than remote checks but that’s often not true. The Windows registry is commonly used for authenticated checks but is often wrong. It’s important to consider that not all authenticated checks are created equal and that a remote check is a good method of validating authenticated information.

The black box testing process involves some straightforward testing over the network and possibly some creative use of IP and other protocols. Usually, the simple tests are harmless and efficient. The more exotic manipulation of IP protocols can cause problems on scanned hosts with applications that are ill-prepared to handle many variations. This is a vulnerability in itself. The IP stack of the host is usually capable of handling nearly any variety of traffic, but the overlying applications sometimes are not. It is another area that calls for extensive testing in order to avoid adverse effects on production systems. Most vendors are able to provide a list of known negative application interactions.

Following is a list of some common methods of reconnaissance:

Malformed packets are sent to the host to identify the presence of a vulnerability in the response. This is similar to the discovery process and is sometimes incorporated into the same phase for efficiency. The information sent to the target can be at any one layer or multiple combinations of layers 3 through 7 in the OSI Model.
Normal packets are sent to a known application to obtain results that will reveal vulnerability information. This is very common in the http protocol to obtain information about the Web server, application server, or back-end databases.
Valid information is sent to the target to gather valid header response data that will reveal the version of software answering the service request. This is known as banner checking. Many software applications can obfuscate this information with simple configuration changes, so it is not the most reliable method.

These methods can be summarized conceptually in pseudo code form:

Send X to target
Listen for response Y
Match Y to possible response list
If Y is on list, note vulnerability
If Y is not on list, ignore
Get next check; Loop

Manipulating TCP | Active Scanning Technology Detection Methods

2011-11-20T07:38:00.000-08:00

Some scanners do not consider ICMP to be reliable since some hosts are configured not to respond to ICMP. So, a TCP SYN packet is sometimes sent using several common ports found on a variety of network devices. Table 1 lists some common ports that are scanned to determine whether a host is present.

Table 1: Commonly Scanned Ports
PORT	PROTOCOL
20	FTP
21	FTP
22	SSH
23	Telnet
80	HTTP
443	HTTPS
137	NETBIOS Name Service
138	NETBIOS Datagram Service
139	NETBIOS Session Service

Other ports may also be scanned, depending on the vendor and how one might configure this phase. Once the SYN packet is sent to the host, a reply of SYN-ACK is expected. Should this reply not arrive in time, the scanner will consider the port not responsive and the host not present, that is, unless the host responds on another port. The discovery of these ports is not necessarily a serial process. The scanner may “spray” the TCP SYN packets on many ports and at many hosts simultaneously. This saves time and makes more efficient use of bandwidth. Some performance issues will be discussed later.

One potential side effect of the TCP discovery method is the potential for leaving open or half-open sockets. This can have an adverse effect on a system, depending on the application listening and the integrity of the OS protocol stack. Half-open sockets occur when the scanner does not complete the connection setup with an ACK packet. The effects range from memory consumption to denial of service (DoS) for production systems. Normally, this is not a problem since only one active connection is attempted per TCP port. However, a misconfigured scan can change this. A similar phenomenon exists when scanning through a firewall. Many firewalls will function as a proxy for the connection to the host. This imposes a load on the firewall when hundreds or thousands of hosts are scanned at once. Some routers can be impacted as well when they are undersized for their operating environment.

If the connection handshake is completed with an ACK packet, an entry in a connection table is maintained on the host and/or on a firewall. The result is a further consumption of resources until the connection times out or is reset. For that reason, it is important to test the behavior of a scanner and determine whether or not a TCP reset is sent to the host and how that behavior might affect your network on a large scale. If it is possible that a large amount of scanning will be performed through a firewall, then test this scenario. The setup and breakdown of connections on a firewall are two of the more processor-intensive tasks and can degrade performance. This is not absolute, however. Proper scheduling, bandwidth shaping, and connection limits in the scan configuration can help prevent these problems. Figure 1 illustrates a scenario where a firewall may be significantly affected by multiple simultaneous scans. As you can see, the total number of connections per second can add up quickly. A scan is far more intense than regular network traffic because it is concentrated into a short time period.

Figure 1: A scenario where a firewall may be significantly affected by multiple simultaneous scans.

Conversely, a firewall, with all the additional security features that vendors have added, can interfere with a discovery scan. For example, some firewall vendors have added intrusion prevention capabilities as well as a SYN proxy. These features can provide false information to a vulnerability scanner, making it seem as though a host exists where there is none. This is because many scanners consider a closed port “response” to indicate the presence of a host. Otherwise, why would there be a response?

These security features can also do the reverse and obfuscate the host and its open ports. Hopefully, the firewall vendor will have the built-in ability to make an exception to the traffic by source IP address. With the correct IP address of the scanner configured in an exception list, the scan should proceed without error.

However, not all firewalls are created equal. For this reason, we will spend a little time discussing packet processing in a firewall as it is related to VM. Figure 2 shows the basic structure of how a firewall might handle traffic. Notice the stacked architecture. The reason for this is to qualify traffic for the most fundamental flaws prior to investing more processing cycles. For example, if the TCP flags are an invalid combination, the traffic should be dropped. Much of this processing can be performed in silicon and avoid burdening the firewall CPU further. On the other hand, if traffic is to be processed by some rules, more CPU cycles are required.

Figure 2: The basic structure of how a firewall might handle traffic.

The next step in packet processing is to save and monitor the connection state. If a SYN packet is received from a vulnerability scanner, it is compared to entries in a connection table. If the connection already exists, then this is likely a duplicate and the packet is dropped. If the connection does not exist, then an entry is made in the table. When a SYN-ACK packet is received, the same comparison is made to keep track of the state of that connection. The same is true with all related packets. If an RST packet is received, then the connection is deleted from the table. This process can take a lot of CPU if there are many thousands of connections per second and other firewall activities taking place. The constraints of this connection table data structure and the related programming code to handle the packets are the parts most crucially affected by discovery scans. If the state table is too small a data structure, then the SYN/SYN-ACK discovery process will rapidly fill this table. If that constraint shows up in testing, you will have to make sure that you limit the number of open connections during discovery.

On the other hand, if the processing code that makes comparisons to this table is inefficient, there will be a significant impact on firewall throughput. In this case, it is vital to maintain a limit on the rate of connections.

Most firewalls process rules in order. A packet is taken from a queue for comparison against the rules. Once a rule matches the traffic, the inspection process stops. The packet is then forwarded to the network interface and the next packet is extracted from the queue.

Another way to avoid a large impact on firewalls is to relocate the scanners around them. This is largely dependent on your network design. Careful placement of scanners is a primary consideration and can be crucial to scanning effectiveness.

Passive Network Analysis Advantages and Disadvantages

2011-11-16T08:06:00.000-08:00

The passive analysis approach has several advantages:

The analyzer does not interact with the network to discover hosts and their related vulnerabilities. Only the interface through which the user accesses the software to get reports is active.
Little to no testing is required to be certain there is no negative impact on the network or hosts. Since the technology is completely passive, little verification is required. Even if the device physically fails, it is not placed inline where it would have to handle the bits on the wire.
Sometimes, the device can be installed in tandem with an existing IDS. This greatly simplifies implementation without any changes to the network switch.
The discovery process takes place continuously. New hosts are revealed as soon as they are connected to the network and begin communicating. In contrast to the active scanning and agents, vulnerabilities may not be known until the next scan cycle.
Hidden hosts can be discovered that do not listen for active probing traffic on the network. Instead, these hosts only communicate by initiating conversation on the network, and can therefore only be detected passively.
Since routing protocols and other network information are also visible to the traffic analyzer, it may also be able to map the topology of the network and use this information to create a picture of the attack surface of a more complex network. This type of information can also be obtained by authenticated active scans and by providing configuration data to specialized tools.

There are also some interesting disadvantages to this technology:

The device typically must be installed on the switch that carries the traffic to be monitored. Remote monitoring of a network is often not practical over a busy WAN connection. This will limit the number of locations that can be scanned. If your organization requires monitoring on a broad geographic scale, this may not be the right technology.
The mechanism that copies switch traffic to the physical device can cause additional CPU load on the switch. That additional load can lower the performance of routing, access control, or other CPU-intensive operations.
There is limited visibility into vulnerabilities. Many of the vulnerabilities that can be detected with a host agent or active, authenticated network scan cannot be detected by analyzing network traffic.

Overall, passive analysis may not see as many vulnerabilities on systems but they function 24 hours a day and provide network topology information that would otherwise be unavailable. Changes to the environment on the network and hosts would be detected first using the passive analysis method if those vulnerabilities have a network footprint.

2 Detection Methods

Detecting vulnerabilities using passive analysis is completely dependent upon being able to dissect and interpret the communication content in all layers of the OSI Model.

3 Physical Layer

The physical network layer is generally not checked for any vulnerabilities by passive technology. Physical connections are terminated at the network interface adapter on the hardware platform on which the software is deployed. The silicon usually provides minimal information about the physical connection state.

4 Data Link Layer

This layer is only tested when the vulnerability scanner is connected to the network in a non-promiscuous mode. This means that the scanner will be able to interact with this layer of the network to acquire an IP address in a dynamic environment. The detection capability is generally limited to the switch to which the device is connected. Information can be gathered about other hosts connected to the switch, basic switch configuration items such as speed and duplex, as well as how the switch responds to variations in collision sensing and detection protocols such as CSMA/CD in the IEEE 802.3 specification. In general, a passive vulnerability analyzer will look for deviations from the IEEE standards.

5 Network Layer

The network layer is subject to substantial variation. IP addressing, flags, routing information, and option parameters can combine uniquely to identify a host and vulnerabilities. Suffice it to say at this point that there is an abundance of information to be obtained from the network layer in any network-connected vulnerability assessment technology.

6 Layers 4 Through 7

The remaining layers can provide large amounts of information about the targets under examination. The passive analyzer will dissect these layers and search for patterns of behavior in the interaction of systems, as well as the specific content of a single packet. It is a complex process with many methods of analysis, and is more akin to an IDS in design.

Active Scanning Technology Advantages and Disadvantages

2011-11-13T05:47:00.000-08:00

Active scanning involves using software that can generate packets on the network to actively engage the targets in order to detect their presence and vulnerabilities. It is a more complex but highly scalable approach that is the most popular today. The scanner is connected to the network just as any other host. The position of the scanner relative to the targets is critical in getting the best results. We will talk more about this later.

Active scanning essentially emulates the behavior of hackers to discover targets, with one critical difference. Hackers use tools and techniques designed to conceal their activities, whereas legitimate active scanning tools do not. Scanners also can perform some of the exploits to determine susceptibility. The degree to which these exploits are performed depends on options selected in the scan configuration. Most products avoid using exploits that might have adverse effects on the target without specific selection by the administrator in the scan configuration. Furthermore, it should be understood that most commercial tools are designed to detect vulnerabilities, not exploit them. Although they can be used as part of a penetration test, there are other, more appropriate tools to complete such a task.

Advantages and Disadvantages

Some key advantages of active scanning:

Highly scalable because scanning takes place from a central location or distributed locations of the security architect’s choice and does not require software installation on the targets.
The technology can provide a hacker’s view of the network and targets, so the vulnerability manager can have a realistic view of their risks in the production environment.
Potential to support any networked device, that is, not limited to a compatible platform for an agent.
Can provide incremental information regardless of platform support (e.g., open ports, identified protocols/applications, banners) even when the VM system has not previously seen the device.

Disadvantages:

If the target is not connected to the network, it will not be scanned. Agents can detect a vulnerability when it occurs and report the results the next time the host is connected to the network.
A potential exists for impact on the network infrastructure since all scanning is so performed. However, some basic planning will prevent such adverse effects.
Scanning is slower over slow network connections. This is typical in small offices with weak links. Today, we see this frequently in South America, Africa, and some parts of Asia.

Passive Network Analysis | Vulnerability Management

2011-11-10T00:34:00.000-08:00

Passive network analysis involves installing a piece of equipment on a network switch to listen to a copy of the traffic and analyze it for vulnerabilities. This is similar in functional design to an intrusion detection system (IDS) or a sniffer. A piece of hardware with a network port is connected to the network switch carrying the traffic to be examined. A command on the network switch sends a copy of much of the switch traffic to that physical port where the analyzer can read it. Alternatively, a network tap can be used to inspect traffic in a single physical network connection. That connection may carry large amounts of consolidated traffic from multiple networks.

The analyzer looks for several things that can reveal vulnerabilities. The IP addresses, network, application protocols, and general communication patterns are all checked for anomalies or attributes that reveal an exploitable flaw. Table 1 shows what the passive vulnerability scanner might get to see when a network tap or port mirror feature is applied compared to what is seen by a vulnerability scanner. Notice that the active scanner has access to information that is not found on the network, whereas the passive scanner possibly has access to information for which the active scanner does not scan.

Table 1: Active and Passive Scanner Comparison
TYPE OF NETWORK TRAFFIC	ACTIVE SCANNER	PASSIVE ANALYZER
ARP	From single VLANs	From multiple VLANs, including remote ones
TCP.IP of target	From actively scanned target	From multiple targets, any talking on monitored VLANs
VLAN tags	From connected VLANs	From multiple VLANs
Protocols observed	Only those in the parameters specified for the scan	Any and all protocols used by the host
Applications discovered	Those which the scanner knows to find, including non-network applications	Any applications that use the network connection

Port mirroring, also called a switched port analyzer (SPAN) by Cisco, is a very commonly available technology in modern network switches. Figure 1 explains how SPAN works. This is a basic SPAN configuration where the contents of a pair of VLANs are copied to a physical port on the switch. The network administrator has the option of specifying ingress traffic only, egress traffic only, or both ingress and egress traffic; typically, both are desirable so that the analyzer can see each side of the conversation. There are complications and limitations to the SPAN function that will vary by model, brand, and features installed on the switch. Some simple switches can only copy traffic that is coming in via a physical port and not off the backplane of the switch. Some can see traffic on a single VLAN, and others can look at trunked VLANs.

Figure 1: A basic SPAN configuration where the contents of a pair of VLANS are copied to a physical port on the switch.

One interesting aspect of SPANs that you might notice is that it seems that the analyzer must be connected to the physical switch carrying the traffic to be analyzed. But, there is a modification of SPANs that addresses this issue to limited extent. Remote SPAN (RSPAN) is available on some switch models that allow SPAN results from remote switches to be forwarded to another switch to which the analyzer can be connected. Some of the capabilities for SPANs can become quite exotic at this point. Your network administrator will have to evaluate the requirements carefully and determine the most efficient way to provide the appropriate information to the analyzer. Figure 2 shows an RSPAN implementation where targets A and B are monitored on a remote switch (#1). The copy of the traffic is sent to the local switch (#2), where the passive analyzer is connected.

Figure 2: An RSPAN implementation where targets A and B are monitored on a remote switch (#1).

Generally, the traffic that is copied is referred to as being “flooded” onto a special VLAN shared between two or more switches. On Cisco products, this approach requires the creation of an RSPAN VLAN. This is a special VLAN that the switch understands is designed for remote monitoring. With this technique, it is possible to assess vulnerabilities using multiple devices in multiple locations.

It is also possible to include this RSPAN VLAN connection in a WAN configuration where the remote switch is 100 miles away. This would be an atypical configuration with some bandwidth risks. This leads us to a key disadvantage of the passive approach to vulnerability scanning. You cannot necessarily target remote locations for vulnerability assessment cost-effectively using the SPAN technique. Passive vulnerability analyzers are expensive. Remote locations with 20 to 30 targets talking to each other at 100 Mbps or even 1000 Mbps are difficult and expensive to monitor since it is necessary to provide sufficient hardware to analyze a large traffic volume. Since it is unlikely to have a WAN link installed at 1 Gbps for monitoring purposes, and purchasing a unit to install locally is impractical, the use of a passive device is not always optimal.

Problems can occur with SPANs and RSPANs that must be assessed by a qualified network administrator. The monitor port, the one to which the analyzer is connected, can become oversubscribed. That is to say, more traffic is going to that port than the port can sustain. Much of that traffic is saved in a buffer that is shared with the networks being monitored. If that buffer becomes full, traffic will slow down for all the ports involved in the SPAN operation. This is easy to see if an analyzer is connected to a 100-Mbps port and is monitoring four other physical network ports with utilization exceeding 40 Mbps each. The total monitored is 160 Mbps. That means there is an additional 60 Mbps that the switch has to save until it can be delivered to the passive analyzer’s port. To avoid this scenario, careful analysis of the peak traffic of each target/monitored port must be assessed. If there is an existing IDS/IPS implementation, these SPAN ports can be shared to economize.

An alternative approach to SPAN is a tap, which is precisely what it sounds like: a physical installation into a network connection that allows a passive analyzer to see the traffic. The tap can be electrical in the case of Ethernet, or optical in the case of fiber. The Ethernet tap is a little more complex because it requires that power be supplied to the unit. Some taps even have built-in batteries to keep the tap operating should the power supply fail. The optical taps do not typically require any electricity but instead employ a prism known as a beam splitter.

A tap has the disadvantage of managing duplex. Since most networks today are built to send and receive data simultaneously, the analyzer must be able to do the same. In a 100-Mbps Ethernet example, a single cable connected to the analyzer can only listen to either the sending or receiving traffic among the monitored targets. Between two targets, there could be transmission and reception each occurring at up to 100 Mbps. So, the total throughput is 200 Mbps, which exceeds the capability of the single analyzer port connection. This problem is addressed by the tap by breaking the conversation up into two separate cables connected to the analyzer. The analyzer then bonds these two sides of the conversations together internally in order to analyze them accurately.

Agents Advantages and Disadvantages

2011-11-06T03:30:00.000-08:00

A significant advantage of this agent approach is the scalability gained from its distributed nature. Since the number of agents deployed is only limited by the number of compatible hosts and licensing costs, it is theoretically possible to perform an audit of every machine without generating any network activity except to configure the agent and report results. Although the audit is not performed over the network, the communication between the agent and the server is not always minimal. Depending on the complexity of the host and vulnerabilities, considerable reporting traffic can be generated. Nevertheless, the scan does not take place over a network link.

Some obvious advantages are that there need be little concern for deploying additional hardware, and there is less concern that sufficient bandwidth and scanner resources are available.

Agents are encumbered, however, by a few basic problems:

They may conflict with other applications running on the target. This is a common problem for all software running on complex computer systems today. Testing is the only solution.
They may not have sufficient privileges in local security policy to audit every configuration item.
They may have errors that cause them to terminate and notification of failure may not come to the management server for some time, during which an audit window could be missed.
Agents may not be available for the OS maker and version in use. Almost everyone makes an agent for Microsoft Windows^®, but far fewer will support Linux^®, FreeBSD^®, or Solaris™.
Imbedded systems such as cash registers and other point-ofsale devices are tightly built and leave no accommodation for agents. Yet, payment card industry (PCI) security standards require file integrity monitoring on these systems.
Given the limited size, space, and performance of an agent, it will not likely have the ability to cover the thousands of possible vulnerabilities.
On virtual machines, there can be many agents running simultaneously, which can adversely impact the performance of the underlying hardware and host OS.
The agent itself can become a target of an attacker as a result of a vulnerability. Since agents typically listen on the network for instructions from a server, an opening is available for exploitation.

The vulnerability audit agent has many advantages over other methods:

It sees all vulnerabilities, some of which are not available over the network unless the scan is authenticated.
The agent can run even when the system is not connected to a network.
It does not actively engage with the software installed on the system to find a vulnerability, thus minimizing the chance of disrupting operations.
Since it does not operate over the network, it will not draw the attention of a network intrusion prevention system (IPS), nor will it create excessive network traffic. In fact, the total traffic load is likely far less than typical Web surfing activity.
As locally running software, it can extend functionality into more active end point security functions.

Agent Architecture | Vulnerability Management

2011-11-03T05:01:00.000-07:00

Agents typically execute one or more services in the background of a system with system privileges sufficient to carry out their purposes. These services normally consume very little CPU resources except when requested to perform a major task. Usually, at least two services are running at any given time with other active services, depending on the architecture of the product. Vulnerability assessment agents are inextricably linked to the audit of the target, whereas appliances can be used for more than one audit method.

As shown in Figure 1, one service listens on the network for configuration and assessment instructions from a controlling server. This same service or an additional service may be used to communicate assessment results back to the server. The second service is one that performs the actual vulnerability assessment of the local host and, in some cases, adjacent hosts on the network.

Figure 1: Agent architecture.

The basic kinds of agents include the following:

Autonomous: They do not require constant input and operation by another system or individual.
Adaptive: They respond to changes in their environment according to some specified rules. Depending on the level of sophistication, some agents are more adaptive than others.
Distributed: Agents are not confined to a single system or even a network.
Self-updating: Some consider this point not to be unique to agents. For VM, this is an important capability. Agents must be able to collect and apply the latest vulnerabilities and auditing capabilities.

A VM agent is a software system, tightly linked to the inner workings of a host, that recognizes and responds to changes in the environment that may constitute a vulnerability. VM agents function in two basic roles. First, they monitor the state of system software and configuration vulnerability. The second function is to perform vulnerability assessments of nearby systems on behalf of a controller. By definition, agents act in a semiautonomous fashion. They are given a set of parameters to apply to their behavior, and carry out those actions without further instruction. An agent does not need to be told every time it is to assess the state of the current machine. It may not even be necessary to instruct the agent to audit adjacent systems.

Unlike agents, network-based vulnerability scanners are typically provided detailed instructions about when and how to conduct an audit. The specifics of each audit are communicated every time one is initiated. By design, agents are loosely coupled to the overall VM system so they can minimize the load and dependency on a single server.

The method of implementation involves one or more system services along with a few on-demand programs for functions not required on a continuous basis. For example, the agent requires a continuous supervisory and communication capability on the host. This enables it to receive instructions, deliver results, and execute audits as needed. Such capabilities take very little memory and few processor cycles.

Specialized programs are invoked as needed to perform more CPU-intensive activities such as local or remote network audits. These programs in effect perform most of the functions found in a network vulnerability scanner. Once completed, the information gathered is passed onto the supervisory service to be passed back to the central reporting and management server.

The detection of local host vulnerabilities is sometimes carried out by performing an audit of all configuration items on the target host in a single, defined process during a specific time window. An alternative approach is to monitor the configuration state of the current machine continuously. When a change is made, the intervening vulnerability assessment software evaluates the change for vulnerabilities and immediately reports the change to the management server. This capability is intertwined today in the growing end point security market. The detection of configuration changes and added capability of applying security policy blurs the relationships among end point protection, configuration compliance, and vulnerability audit. This combination will ultimately lead to tighter, more responsive security.

Hardware: The Appliance Model

2011-10-31T07:59:00.000-07:00

The hardware appliance model is exactly that: hardware with built-in software to perform the desired vulnerability scans. The devices are typically placed throughout a network and report back to a central server. The scanning appliances are usually complete but simple computer systems. A typical design has an operating system (OS), supporting software modules, and the specialized code written by the developers to perform scans and communicate results. Some vendors use open-source tools and others will use a commercial OS and components.

One major advantage of a hardware-based system is that the vendor will have in-depth knowledge about the configuration of the host. The vendor takes responsibility for the maintenance and stability of that configuration. Any failure of the software to perform as advertised should be addressed in the client–vendor relationship.

In deployment, the hardware approach has the disadvantage of having to be shipped to the location and installed by someone who may not be qualified to do so. In most cases, however, deployment is not so complex. If the local technologist can configure a typical host computer, he or she can configure a vulnerability scanner. If you are uncertain about the capabilities of local personnel, then you may be well-advised to preconfigure the device and provide simple installation instructions.

In most designs, each scanner will report back to a central server. The vulnerability and compliance information collected will be transmitted back to the server for analysis and reporting. Devices will also receive assessment instructions over the network. Those instructions may be delivered by polling, on-demand connection, or through reverse polling. The impact of these strategies will be minimal but important, depending on your network security architecture.

Polling is the process of taking a poll of the vulnerability scanners associated with a central server. Each scanner is typically contacted through a TCP port with special authentication methods that keep the entire conversation encrypted. The devices that are polled may be only those for which the server has a job prepared or in progress. The server checks the status to see if any data is available or if the unit is ready to accept a job. This approach can be cumbersome but has the advantage of only requiring a connection originating from the server. In some cases, not all scanners are polled unless there is scheduled work that can result in not knowing the status of a scanner until that time. Most vendors that poll will poll all scanners. Figure 1 illustrates the simple polling approach.

Figure 1: The simple polling approach.

Reverse polling is the process whereby each scanner contacts the server on a regular basis. Should there be a job scheduled for the scanner, it would then be provided. The same strong authentication and encryption methods apply. The scanner will send the results of the scan back to the central server either during the scan or at the conclusion, depending on the software designer’s choice. This approach has the added advantage of allowing the scanner to complete a local job even if the connection with the server is lost. The scan results may simply be cached until a connection can be re-established.

Reverse polling also has an advantage when deployed in a secure zone where in-bound communications to the scanner may be undesirable in order to limit possible external connections. This is also a disadvantage should the scanner be deployed outside the organization’s boundaries because accommodations must be made in the security infrastructure for connections from the scanner.

Compliance and Governance | Vulnerability Management

2011-10-27T02:30:00.000-07:00

Eventually, the progress in remediation has to be monitored by someone to maintain good governance. In an organization of less than 10,000 hosts, it is often sufficient for this individual to be the person responsible for scanning. However, in larger organizations, it is preferable to have a compliance group perform this function. Additionally, Compliance would monitor the configuration and operation of the system on a regular basis.

Figure 1 shows how the compliance organization uses the current operations documentation, process documentation, and scan results to verify compliance. These three pieces of data have an important relationship. Operations documentation tells the compliance group what activities were undertaken by the VM group. Compliance should verify that VM activities are conducted in accordance with policy.

Figure 1: Compliance data flow.

Process documentation defines in unambiguous detail the steps to perform the VM function. It is against this documentation that the compliance function will verify the operations activities and supporting output documents. The process documentation itself should be checked against policy to assure conformity. In some cases, this step is not necessary in the compliance monitoring function because compliance may be a part of the creation of the VM process. In that case, an external audit is occasionally warranted.

Finally, the scan results data is detailed in reports from the vulnerability scans. These reports should reflect the level of compliance achieved by each IT group responsible for remediation. Later, we will discuss in some detail the content of these reports and their relevance in a mature, successful VM program.

1 System Audit

Another critical step in the governance of VM is auditing. During an annual audit of security mechanisms, it is advantageous to have an external party review the configuration and operation of the system. The elements of any audit should include the following:

Process: Auditors should verify that there are no critical flaws in the scanning, remediation, and verification processes. The auditor should provide recommendations on improvements.
Scope: With an understanding of the structure and application of existing network segments, auditors must verify that a complete and appropriate set of targets is scanned. Depending on the program charter and policy, the list of targets may include vendors or business partners. In addition to existing targets, it is important to recognize that organizations, systems, and networks are dynamic. Changes to the environment will change the scope of scan targets. Processes and configurations of scanners should be sufficient to adapt to this changing environment.
Training of operators: Those working on the technical details of the system must be sufficiently well-versed in its operation. Not only must they understand operations, they also have to understand how vulnerabilities work, the threats associated with them, and the risks posed to a company realizing those threats. Knowledge of operating systems, networks, protocols, and various relevant applications is highly desirable.
Policy alignment: Do the VM operations align with current policy? As we discussed earlier, VM processes are derived from policy, which is derived from program charter or business objectives. Over time, policy can drift and no longer meet the program requirements. This is not through negligence but a natural tendency of individuals to adapt to a changing environment without the perspective of overall impact to the program charter.

As circumstances gradually change in networks and systems to respond to the changing business environment, the business needs will no longer be reflected in the policy. For example, the business may typically sell its products through personal sales contacts. Therefore, there are no policies regarding proper use of encryption or handling of customer financial data. Then, they discover untapped markets that are accessible online. The current policy may state that electronic payment data must be exchanged through bank transfers and not through company systems. However, in the newly adopted online sales model, customers provide payment information, which is handled by company computer systems. Now, numerous vulnerability and compliance issues in encryption, network design, and system configuration arise. Since the policy has never been amended, it is difficult to discover and remediate compliance problems in these systems. Furthermore, the systems in question may be out of scope for VM altogether.

New Policy | Policy and Information Flow

2011-10-24T07:50:00.000-07:00

VM compliance policy is sometimes necessary for enforcement of remediation activities. Depending on your organization, a policy that directs IT managers to make remediation a priority is helpful. The policy should provide for the following:

Prioritization of vulnerabilities: The vulnerabilities found will be prioritized. In many cases, more vulnerabilities are found than can possibly be fixed in a reasonable amount of time. You will have to specify what gets done first. It is even possible that you may want a policy statement of the circumstances under which systems administrators should drop everything they are doing and remediate or shut down the system in question.
Valuation of assets: Every system is a company asset. It has to be given a value, which can be used in the prioritization process.
Time limits: Depending on the severity and type of vulnerability, time limits for remediation must be set. This is, in effect, an SLA for the organization. You will have to consider the risk or threat to the organization based on several criteria. Those criteria, however, would be left to a supporting standard.

1 Usage Policy

Another important type of policy pertains to the usage of the VM system itself. This policy would highlight key operational constraints. Among the types of constraints necessary are the following:

Types of systems exempt from scanning: This can include other security devices or critical network devices that are known to be adversely affected by scanning.
Operational requirements for scanning approval: One must have consent of a system owner and/or administrator.
SLA parameters: This requirement specifies what parameters must be included in any scan specification for a given network or group of targets. This might include time of day, bandwidth limitations, operational impact assessment, and scan termination request response time. These parameters in particular are important to maintaining a healthy relationship with system owners. If scans interfere with the systems and their operating environment, system owners are not likely to grant ongoing permission to continue scanning.

2 Ownership and Responsibilities

Once a system proves itself to be a powerful tool in managing a critical part of the enterprise, questions such as “who is responsible for the scanning schedule?” and “who decides what gets scanned and when?” are likely to arise. These questions are reasonable, given the insecurity that comes with what is perceived as an invasive activity. The best thing to do is avoid contention over these issues by getting it all decided in advance. Be forewarned that ambiguity is the enemy of process.

The first step in establishing clear ownership is to build it into the policy. The roles for key functions in the process should be clearly specified in the title. At a minimum, these roles must at minimum include the following:

Scan parameters definition: The business and technical parameters used for scanning must be defined and carefully controlled. Although others may participate in the process of scanning, careless changes to parameters can cripple a host or an entire network.
Scan scheduling: The schedule for a scan has a lot of thought built into it. These considerations should not be trifled with. A change in a schedule can have as big an impact on business operations as a change in parameters.
Report distribution: Vulnerability reports are confidential data. In the wrong hands, these reports can be very damaging. For a hacker or motivated, disgruntled employee, a vulnerability report is a road map to trouble.
Local host remediation: When a host cannot be patched or fixed through an enterprise host management tool, it has to be remediated by a local administrator or other individual appropriate to your organization.
Global remediation: Conversely to local host activities, global tools also remediate hosts over a network. One or more organizations are responsible for this remediation. For example, the desktop team may be responsible for general host patching and the security group may have to keep anti-virus and encryption programs updated. All such organizations should be identified in advance and made active participants and contributors to VM process development.

Contributing Roles | Vulnerability Management

2011-10-07T06:11:00.000-07:00

The groups most commonly having a contributing role in the VM process are asset owners, Human Resources, IT, and Security. The last group, Security, may be surprising to you in that one would expect a direct operational role rather than a contributing one. Although it may be the case that Security is the principal operator of the system, we discuss it at a higher, abstract level as a customer that contributes requirements.

1 Asset Owners

Asset owners are those who ultimately pay for things and derive the most benefit. They control the purse strings, and therefore have considerable say over what gets done. In many organizations, the asset owner is the line of business. This either happens through a chargeback mechanism or direct purchase. This becomes most apparent at the middle and upper levels of management.

It is natural for typical IT workers to consider the systems they administer as their own. This sense of ownership is not founded in reality but only from an emotional attachment. Working through their managers will ultimately yield better cooperation in a large organization when making plans to assess the security posture of an asset. Maintaining emotional separation from the asset will enhance objectivity when making key decisions about the asset’s security posture. Two very important contributions of an asset owner are the asset classification and valuation functions, which cannot and should not be performed by the administrator of a system. There will be more on this topic when we discuss planning and execution of the VM program.

2 Security

Security departments are often the groups dealing directly with VM. However, organizations with a strong focus on service management as described in the ITIL service management framework may consider this a subset of the existing framework. In either case, a close and cooperative relationship between the security function and IT should exist. A partnership will make VM implementation easier and you will likely receive better internal support.

Since security is the ultimate goal of a VM system, it is natural that Security is a key participant and possibly full owner and operator of the VM program. Depending on the type of business, however, it is possible that other groups such as Compliance will take on this role. For example, companies that depend heavily on payment card industry (PCI) standards compliance may wish to have the compliance organization take ownership of the process while partnering closely with Security as a customer and key constituent.

3 HR

Human Resources is one of the most overlooked groups. VM systems often find critical compliance problems, which can expand into evidence of security incidents perpetrated by an employee. HR is an instrumental part of the reporting process as well as the “stick” part of security policy. Ultimately, HR is there to help manage the risk to the company from things that employees do. Any reporting process that is developed should probably consider the relationship with HR should action other than patching and configuration management be required.

HR is also involved in the creation and maintenance of performance management programs. With careful planning, it is possible to tie vulnerability remediation performance to employee performance objectives. To achieve this, it may be necessary to give HR a clear understanding of how the VM program and support systems work. HR can then work with the VM program manager to determine what their role will be in mediating any potential conflicts that may arise with managing an employee.

4 IT

Information technology is obviously heavily involved in technology and process. If you are working as a separate security or compliance group, I recommend partnering with an IT project manager to get the technology deployed. A senior IT manager would also be very helpful in getting systems and networks remediated. The VM program manager should work with senior IT managers to develop the process and identify the key individuals who will oversee the work. In all likelihood, you will have to get some initial guidance from managers and then propose a process. Be sure to furnish a diagram. IT people work well with drawings and seem to commonly prefer analyzing existing design.

Operational Roles | Vulnerability Management

2011-10-03T04:34:00.000-07:00

Other roles to be filled in the ongoing operation of a VM program have both direct and indirect participation and contribute greatly to the program’s effectiveness. The roles are defined early in process development with more concrete modifications when hardware and software are procured. This is because the selection of technology will impact how people work, their involvement in the communications among other groups, and the nature of their interdependencies. If an automated process fulfills a key activity in a role, then the requirement for the role may be diminished altogether.

For example, at the outset it may be planned to have a role of an administrator to take discovered critical vulnerabilities and distribute the remediation requests to the appropriate system owners or administrators. However, it may subsequently be determined that the selected technology can automate this process, and therefore the role is minimized to one of monitoring.

1 Vulnerability Manager

This role is responsible for assuring the correct configuration and operation of the technology, as well as creating, monitoring, and distributing reports as needed. It is by no means a simple administrator role. The individual must be able to interpret technical reports produced by the system and to explain the cause and remediation for a vulnerability. Knowledge of operating systems, networks, and security practices is required. This individual will interact with system administrators and network managers to assure that the vulnerability identification and remediation processes meet goals.

2 Incident Manager

When vulnerabilities require attention, one person must take responsibility for remediation. It is often the owner or administrator of the vulnerable target. This individual should have insight into the configuration and operation of the target and be able to assess the impact of a change to that system. This person, known as an incident manager, will work with the vulnerability manager to complete the required remediation tasks. It is the responsibility of the incident manager to follow up on the assigned remediation tasks until they are complete. In some cases, this role in combined with the role of change manager. For example, smaller organizations may have one person to field all work for engineers and administrators. This person could be responsible for receiving incidents, coordinating changes, and distributing remediation work.

3 Change Manager

In a more complex remediation scenario where multiple systems or business functions may be affected by a complex change, the change manager will act as a project manager to oversee the full extent of the change. This manager will inform the affected parties, coordinate activities, perform testing or assure that proper testing is completed, and work with the vulnerability manager to verify compliance.

4 Compliance Manager

This role is primarily one of a recipient and end user of the VM system, and also one of the principal beneficiaries. In a normal compliance function, the compliance manager is tasked with assuring that the systems in use by the company adhere to policies and standards. This manager is generally a recipient or consumer of reports from the VM system. More importantly, in a dynamic environment the compliance manager will review trend reports to determine whether there is a continuous or repeating activity that results in a system being out of compliance. This allows the compliance manager to discover processes in the organization that may be flawed in a way that leads to repeat policy deviations.

In an environment where service level agreements (SLAs) are used to establish service levels, the VM program manager may create an SLA for the compliance manager to assure that audits take place at the required frequency and the appropriate checks are run on each target. Metrics for this are simple and easily derived from the vulnerability scan results.

The VM Program and Technology Development

2011-09-30T09:00:00.000-07:00

There is also a major technology development component to the program. This development process can also inform the previously mentioned phases. So, if we add to our diagram the technology development process, as in Figure 1, we can see a parallel set of activities.

Figure 1: Vulnerability management and parallel development process.

When the development of technology takes place in parallel with the organizational and procedural phases of the program, feedback must also inform upwardly, adjacently, and downwardly. Adjacently, policy development may inform engineers on how to design a system. Or, innovative design of the system may provide the ability to simplify procedures. We saw this in the previous chapter where a systems integration effort could have a major impact in simplifying incident and change management processes. Downwardly, a subtle policy change may make coding of the system much simpler by removing an unnecessarily onerous internal audit capability. A good example of this would be if the audit function required that every scan track each action taken by the system to detect vulnerabilities. This would be an ill-informed policy, because such recording activity would overwhelm any scanning software, hardware, or supporting network with audit information that would equal or exceed the actual vulnerability information discovered. It would be more effective to consider the vulnerability result data as audit information itself.

Often overlooked, upward feedback across disciplines is quite important. For example, the development of the VM program can cause a contradiction in policy to surface. Evidence of that contradiction can be fed back into the earlier policy development phase. For example, during VM program development, it may be discovered that a particular vulnerability is simply not found on the types of systems being scanned. So, a policy that requires all systems to be scanned for UNIX^® shell vulnerabilities would not apply to the part of the business that relies solely on Microsoft applications. The policy would have to be modified with words such as “where appropriate.”

The feedback from the technology development program will inform the parallel organizational program. For example, the discovery of a feature in the VM system technology may affect the intrusion prevention capability in a positive manner. So, an enhancement of the intrusion prevention policy, technology, and related procedures may be necessary. Performing this function during the earlier planning phase will naturally integrate VM into other parts of the organization as well as identify where technical planning is required to integrate with the intrusion prevention system (IPS). However, not all good ideas occur before development. It is the job of the technology project manager to work with the team to determine whether such discoveries merit additional development effort.

In Figure 1, you can see how the technology development track of the program might work in conjunction with the overall program. Try moving in all directions and consider the scenarios under which one phase may inform another.

Case Study: Technology Integration Challenge

2011-09-26T05:55:00.000-07:00

Abacus Corporation is a global manufacturer and distributor of electronic abacuses that employ LCD technology and a special gesture interface that enables calculations to be performed much faster than with a conventional calculator. By all measures, Abacus resembles a rapidly growing but small electronics company holding a few key patents.

Abacus has manufacturing facilities in Nebraska and Alabama. Syllog, a business partner based in Germany, where most of the exotic devices are purchased, handles distribution. Syllog is a distributor of multiple unique electronic devices mostly to Asian customers and niche retailers in the United States and the United Kingdom. Most of the devices are provided by only three manufacturers with which Syllog maintains close relationships in business and infrastructure. About 40 percent of Syllog’s infrastructure was co-funded by Abacus and serves Abacus directly.

At Abacus, the IT infrastructure is very mature with solid ITIL-based change management and incident management tools. All business partners are required to meet or exceed Abacus’ policies and standards. They have implemented a “service desk” model with a few essential modules from the ITIL framework. This service desk is the central point for receiving and managing incidents and escalating changes. Since Abacus is a manufacturing operation with unpredictable order volume, all production is performed on a just-in-time basis. That is to say, they don’t design and manufacture their products until they have an order. Furthermore, they are committed to delivering the products within 10 calendar days of order receipt. So, there is little tolerance for downtime.

Sales-related IT operations at Abacus are managed locally with market-specific applications. The varying languages, cultures, and unique business relationships in each market require equally varying hardware, software, and applications. Common operating system and underlying utility software is provided and managed by the global operations. However, the applications and non-ubiquitous software are handled locally. To keep this arrangement, specific service levels have been established between global and local operations groups.

Naturally, management has decided that the next step is to implement a full VM initiative throughout the company. There is strong connectivity to all the sites, including business partners who have also agreed to participate. Abacus uses primarily Microsoft software on desktops and Linux^® on servers, with certain offices using a few implementations of Solaris™.

In addition to cleaning up vulnerabilities, Abacus wants to verify compliance and patch status in as many parts of the extended enterprise as possible. They have mature internal processes but few systems support resources. The ratio of support engineers and technicians is about 300 to 1. Automation is a key factor for Abacus. For example, there are about 20 standard systems maintenance and data collection shell scripts that run weekly on Linux systems, so scanning for vulnerabilities by an automated system rather than relying purely on internal processes is essential. The head of the systems engineering group, Carl, is given responsibility for implementation.

1 Events

November 2: With full backing of senior management, Carl has assembled a small team representing the systems support team, desktop engineering, and the director of networks to select a tool and modify existing processes. A budget of $350,000 is approved for the project.
November 23: On time and within budget, the team has selected a combination of two tools that appear to work well with all systems, including network devices for vulnerability scanning of desktops and agents on servers. The original idea was to have the agents run on all systems but the impact to local operations was too great to install and maintain yet another agent on an already-crowded desktop. Since the agents seemed to have a low impact on server operations and the reporting provided unique features such as integrated patching, the thinking is that automated patching will help with workload. The compliance reports are exactly what are needed to keep managers focused on achieving the desired results. Total cost: $330,000 installed.
November 30: Acquisition is completed, the software is installed on a server, and hardware devices are deployed throughout the offices as needed. With the consent of the management of the business partners, certain locations that could have experienced problems scanning over the WAN connections have also installed scanners, but have complained about the high cost for only a few hosts. To adapt, some of the server agents have been tasked with scanning local desktops without agents.
December 6: A freeze on all non-critical change control items has gone into effect due to the holiday period when many key employees will be on vacation. This lasts for 30 days. Not all of the network scanners have been installed.
January 15: Everyone is back from vacation and Carl has put together a communication plan to keep all key managers in the loop on vulnerability scanning. He has created the initial user names with passwords and privileges representing the six IT directors in key offices. They will be the primary users of the system. One of the agreed-upon process changes is that the IT directors will log in to the system to see the status of vulnerabilities in their area of the company. Access to the vulnerability information for each of these areas is defined by IP address range.
February 2: Initial scans have been completed and IT directors are automatically informed on the results. They are very satisfied with the quality, content, and accuracy of the reports. It appears to be another technology and process triumph at Abacus. Carl has turned over the system to the production systems support group, which also had members on the VM system development team. Some of the IT managers have complained that they have to go into two separate systems to see all of their hosts. The system that operates the agents is giving them server vulnerability information and the network scanning system provides desktop information. Carl begins a discussion with vendors on the best approach.
February 10: The IT director in Nebraska asks that all nine of his desktop support group be given access to the system so they can pull reports and perform the remediation. The system administrator provides a list of information items required to be completed in a form for setting up the users. The form completion, return, data entry, and password verification/reset takes about two days to complete for both VM systems.
February 12: The business partner, Syllog, complains about getting strange scan results. It appears that the names of the desktops on Syllog’s network are incorrect and instead are showing hosts on Abacus’ server farm. Checking with the IT manager at HQ, it appears that the Syllog manager is in fact getting scan results from both networks. The cause turns out to be due to the fact that they use the same IP addresses. The vulnerability scanner is reporting correctly to the server but there is overlap with the IPs.
February 14: The IT manager in another office requests similar access for all of this desktop support team, a total of six people. They must have access to perform their remediation as well. With more users, detailed procedures have to be developed for the two systems operating in combination and separately.
February 18: A technical solution is developed to rely on computer name, not IP address, to identify the host on a report. All of the network definitions and privileges have to be updated to reflect the change. Separately, an initiative is started to integrate the two vulnerability systems into a single reporting infrastructure. This is done by a single systems engineer with extensive experience in Perl programming.
February 23: The remaining IT directors in other locations, six locations in all, also request that their support people be permitted to have access to the VM system. Two of the directors want to divide the responsibility for their systems between two different support groups: servers and desktops. This is because of the specialized skill required in remediation. This makes for the addition of a total of 32 users to the systems.
February 25: After three days of work for one person, the changes to the network definitions and permissions are complete. There are now 47 users of the systems. Some server managers complain that the patches that are installed are not thoroughly tested and need to be scheduled more carefully to not affect production operations.
March 1: The VM team is informed that a user in Nebraska resigned two weeks earlier and his access should be revoked. Following the user-termination process, the user’s access is revoked. A replacement user has not been found. Therefore, only the IT director in Nebraska can run those reports.
March 4: Initial reports show a significant lag between the time when vulnerabilities are reported and the time they are finally fixed. After about a day of calls, the VM administrators determine that the delay is caused by the time between finding the vulnerabilities on the report and entering them into the incident and change management systems. The process that was defined in the beginning works fine but requires up to three weeks to enact remediation. Carl has a meeting with the compliance director and the information security director to discuss the current performance of the new system and the slow remediation issue. The compliance director points out that the maximum allowed time for remediating a critical vulnerability is seven calendar days. According to the reports in the system, this is taking two to three weeks.
March 5: The Microsoft-based systems are configured with credentials using Active Directory^® to perform in-depth scans. In effect, these credentials allow the scanner to log in to the system to check critical patches and configuration items. Management reports have been consolidated from the two systems into a single report that is run on demand through a Web interface. The system engineer begins work on detailed remediation reports. However, many of the data elements from the two systems do not directly match. One uses CVE (Common Vulnerabilities and Errors) codes to identify vulnerabilities and the other uses Bugtraq identifiers.
March 10: Carl has spent the last week trying to perfect the current process for reporting and remediation and has only gained about one day of time on average. The central problem seems to be that those entering the information into the incident and change management systems have other responsibilities, including performing the actual fixes. Issuing patches through the patch management system can fix some items. These changes happen quickly with little problem that can be addressed within a day or two. However, about 30 percent of the vulnerabilities require manual intervention. Furthermore, the agent-based VM system seems to be designed to use its own internal change management system with no ability to automatically export changes and import change release status.
March 11: The UNIX^®-based systems are not yet being scanned. Each one of then has to be set up manually with the appropriate credentials for in-depth inspection by the new system. This is a time-consuming process that requires numerous change management events to be created. To save time and work, some changes are bunched together in the system. But they can only combine those events for systems that have the same configuration, that is, virtually identical systems such as in a load-balanced configuration.
March 12: After careful consideration and discussion with his boss, Carl decides that the best course of action is to bring in a special developer to interface the patch, change, and incident management systems with the new agent-based VM system. However, the system engineer who has been coding Perl reports has no time to work on the system further, given a hectic change schedule. The engineer turns over all the code to Carl.
March 20: An initial assessment with the developer and the vendor’s support team results in an estimate totaling $152,000. There are three primary reasons for this: First, the system is designed to generate only SNMP traps when a vulnerability is found. None of the change or incident management systems are compatible with this protocol. A custom interface will either have to be written into the VM system or into the internal systems. Second, the workflow from incident management to change management allows for automatic generation of change events only when an incident is entered manually. An automated interface will have to be developed to put entries into both systems and link them together using information from the incident management database. Furthermore, the process is different for vulnerabilities than for other incidents because there must be a verification scan before the change can be closed out. Finally, the VM system uses CVE and BugTraq numbers to identify what patch needs to be applied to a system. The patch management system uses a proprietary set of codes that is more specific about which patch is required. Additional data would have to be developed to properly match these codes and identify where they do not properly align.
March 23: Total estimated costs of the system in a fully functional state are now $482,000 (initial $330K + $152K). Senior management senses that this might turn out to be a money pit and limits total expenditure to what was initially requested ($350,000). For the money that is left ($20,000), the developer can send the required XML-formatted messages to the incident management system to save some data entry time. After that, Carl’s budget is depleted.
Epilog: For the remaining year, VM system users are pleased and yet confused about the incomplete process involved in remediation. Considerable ongoing effort is put into remediating and closing out incidents. Users still have to create change requests, run verification scans manually, and then close out changes. Carl continues to believe that senior management is pennywise but pound-foolish. Some wonder why the company didn’t just go with a single system and avoid all the confusion.

2 Analysis

Events seemed to unfold rather smoothly at the start. This was clearly a very mature IT operation with strong process management and supporting systems. Project management seemed very structured. There was good executive support for the initiative and a budget was set and agreed upon. Carl, the project manager, involved all the right parties to get mutual ownership. This last factor is what allowed the systems to stay in operation even after shortcomings became apparent.

First, let’s address the issue of process, so that it is clearly understood how it works at the Abacus Corporation. Although they are very disciplined and efficient, IT seems to suffer from this process.

An incident, in the ITIL framework definition, is some event that disrupts the agreed-upon service level and underlying business activity. Service levels are set for vulnerabilities and remediation time frames, and a newly discovered vulnerability will result in a potential failure to meet SLAs if not corrected in a timely fashion. When a vulnerability is discovered by Abacus’ new VM system, an incident must be generated in the incident management system to track the resolution. Since Abacus runs a lean IT shop, the service desk functions are performed by a variety of IT staff, depending on the type of event to be handled. So, the service desk is a very dynamic entity with the support of software-based routing to the appropriate parties. See Figure 2.2 to follow this process.

Vulnerability information is assessed by the appropriate individuals depending on the network and host type affected. If a vulnerability is critical, an incident is created to track the vulnerability to resolution. Non-critical vulnerabilities are put into a scheduled change process for non-urgent changes.
When a resolution involves a change that is complex, and it is determined that to implement the change may impact other functions, a change is initiated in the change management system and a change ticket is generated. This allows affected parties to be included in the change process with appropriate notification of potential impacts. It also informs the manager of the change of the technical configuration elements of the target.
Once a patch is applied or a configuration updated to remediate the vulnerability, a change ticket is conditionally closed. The change ticket is closed with the caveat that the same vulnerability must not appear in the next vulnerability scan.
A vulnerability scan is run again, either as a part of the regular schedule or manually upon request. The scan performed on request is typically faster and only targets the systems affected by the change.
The incident ticket will be closed after the change ticket closes. This takes place automatically between the change and incident management systems, but only if the incident management system automatically produced the change ticket.

Figure 1: Abacus Corporation vulnerability service desk process.

To the uninitiated, this may seem like a cumbersome process, but the staff at Abacus is very disciplined and well-trained. The process works exceptionally well at providing the critical production systems, typically uninterrupted and predictable service. So, in this case the process seems to be well-managed. However, there are several deficiencies in the systems integration process.

One obvious problem is the continuous interplay between the incident management system and the change management system. For every critical vulnerability, IT personnel in a service desk role have to create an incident for tracking purposes. Then, if it is determined that a significant change is required, a change ticket has to be created to notify others who might be affected by the change.

An example of a vulnerability that would be well-managed by this process would be if a Microsoft SQL server system were found to have a weak password on a commonly used user ID. That password weakness would be a vulnerability. If that database server were accessible by a large number of people, possibly even from outside the company, this could be a very serious attack vector. To fix this, the password would have to be changed, but doing so might break several applications that rely on that password. So, a change ticket is created and the application owners are notified. Once the application owners coordinate the change to affected systems, the change can be completed.

Now, once a change is completed, the change ticket is closed. At Abacus, the ticket is closed but not the incident. First, a scan must be performed on the system to verify the remediation success. In this example, the strength of the password would be tested. If the vulnerability is no longer present, then the incident is manually closed.

So, we have now performed four manual tasks that could have been automated. Follow this procedure in Figure 1. The boxes are shaded to indicate which steps are manual and which are automated. There is little to no automation in this diagram. The diagram has numbers, which correspond to the following:

1. A vulnerability manager reviews a report to identify critical vulnerabilities in hosts. This activity is ideally suited to an automated system. Vulnerabilities are typically well-known and evaluated by experts around the world. An automated system has this assessment built in and is able to take action based on that information.
2, 3. If a critical vulnerability is found, the manager opens an incident ticket and assigns it to the owner of the system.
4, 5. After remediating, the change ticket is closed and the vulnerability manager rescans the host in question.
6, 7. The report is reviewed to determine whether the vulnerability still exists. This is essentially a repeat of step 1, which again can be easily automated.

The creation of an incident ticket is a simple tracking and interface activity that can be performed by a machine. In step 3, the rescan activity can be automated by interfacing the change management system with the VM system to allow for notification that a change was complete, thereby initiating a follow-up scan. Alternatively, the action may take place manually, depending on the process used. If the process called for waiting until the next scheduled scan, then step 4 is not required. If a manual scan is called for in the process, then a rescan may be necessary. One refinement of the rescan process is a limitation or parameter applied to the target. For example, a particular host or network of hosts may have a constraint that only allows them to be scanned at night in case service is affected. This would prevent any potential outage during business hours. Therefore, once the change is complete, the rescan will only take place later that night and not immediately.

Now, let’s look at the process from an automated perspective. Refer to Figure 1 again. The following process closely resembles the earlier process. However, in the diagram I have indicated some steps with double boxes to indicate where automation can be performed (Version 2 Automatic). In each automated step, the process is greatly accelerated to require only seconds to complete. The following numbers are also indicated in the diagram:

Critical vulnerabilities cause the VM system to automatically create an incident ticket and assign it to the individual specified for the network where the host resides. In this case, this individual is known as the incident manager. The incident ID is captured by the VM system.
The incident manager reviews the required change and determines whether it requires significant work or can affect other systems.
The incident manager goes into the incident management system to flag the incident as a required change, which is instantiated in the change management system using the existing interface between the two systems.
The change is performed as planned by an engineer, possibly the incident manager.
The change activity is closed out via the incident management system user interface by the engineer who performed the work. There is no way to automate this action but it requires little effort. In fact, some change management systems have the ability to listen for e-mail message replies to update status. This update automatically triggers notification to the incident management system to tentatively close the incident.
The incident management system then sends a confirmation message to the VM system using the incident ID. Indexed using the incident ID, another scan on the single host is initiated, checking for the specific vulnerability and any others.
If the vulnerability is not present on the follow-up scan, a confirmation is sent to the incident management system to close the incident. If the vulnerability is still present, the incident confirmation is rejected, causing another notification to the incident manager. Steps 3 through 6 are repeated.

Another problem with the implementation is the selection of two separate products that were never designed to work together. Although some products on the market can perform both agent-based and network-based vulnerability assessments, the previous scenario is a common one. This is often the case when two seemingly ideal products lack the key compatibility to “hit a home run” in the VM game.

As a result, users were initially forced to work with two different systems. At first, the agent-based system scanned only servers and the host-based system scanned only desktops. This logical separation fit the company management model of local versus global separation of responsibilities. But, when the agent-based system was used to scan desktops where a network-based scanner was not financially feasible, the division of responsibilities and system usability broke down.

An enthusiastic attempt to rescue the effort was made by a knowledgeable system engineer. However, the low hanging fruits were the management reports. Since no system interaction was necessary, data gathering and normalization were simpler. There were still issues with data structures and standard values across systems. These are all the same problems that would be found in any other application. Later, we will see where the industry is making strides towards avoiding these problems.

In addition to the automation surrounding identification, remediation, and unified reporting, other systems can be integrated to great advantage.

On February 10, nine user IDs are requested for addition to the system. At this point, the system administrator should perhaps be wishing that this was an easier task. It has been time-consuming to collect the data and enter it into the system. Since Abacus is a Microsoft shop, why not integrate the user identification and authentication with Active Directory? Or even use the almost-ubiquitous RADIUS protocol. This piece of system integration is essential for most enterprises today that employ some standard type of authentication mechanism. We can also see that several other users have to be added to the system as well on February 13, 14, and 25. There were eventually almost 50 users to set up. When one user left the company, Carl’s team only found out two weeks later that they could remove the user’s access. It is more likely that the user assigned to an Active Directory group had already been removed or disabled.

An example of how a directory structure might align with a VM system is shown in Figure 2. There are objects and actions in the VM system. A group or user can be a member or a role, which includes various combinations of object and actions. For example, an individual with the administrator role would be responsible for maintaining all areas of the system. Therefore, he would be given access to all objects and all actions. However, the previously mentioned engineer would only have access to reporting capabilities in a particular office. So, that group’s permitted action would be “Report” and the permitted objects would be those “Networks” that are in the local office.

Figure 2: Vulnerability system roles aligned with directory structures.

Each of the groups or users could be assigned to one or more roles and networks to give them the capabilities required as shown in Figure 3. The power of this arrangement comes from the fact that when a user changes to another group, the user will assume the roles of that group and not the one from which he came. For example, if an engineer moved from the IT department in California to the Desktops group in Nebraska, that engineer would then be able to have access to vulnerability information only for his new position. Vulnerability managers would similarly only be able to perform scans on the assigned networks associated with their group.

Figure 3: Directory structure and VM system roles.

This kind of integration seems obvious now, but at the beginning, this many users might have been inconceivable to Carl or the rest of the team. This also sends us back to our earlier discussion about how vulnerabilities get created. This scenario is similar to one in which the original system designers fail to take into account all the ways a system may be used. It is a requirements gathering activity with too many assumptions. Carl’s design and selection team should have worked out precisely who would use the system, how many users there would be, and what types of activities were likely to take place with those users. There would be terminations, new hires, analysts reviewing reports, and perhaps others who change the scanning parameters or schedules.

Critical Incident Management

Scan Modes | Nessus

Advantages and Disadvantages of Nessus

Security Content Automation Protocol (SCAP)

SCAP

National Vulnerability Database

NVD

CPE

1 Encoding

2 Examples of CPE Names

XCCDF

The Standard for Vulnerability Severity Rating

The Standard for Vulnerability Test Data

Definitions Schema

System Characteristics Schema

Results Schema

Nuts and Bolts[*]

Common Vulnerabilities and Exposures | CVE

Structure

Limitations of CVE

Inference Scanning | Vulnerability Management

Hybrid Approach | Vulnerability Management

Performance Matters | Active Scanning Technology

Web Application Testing

Application Fingerprinting: Banners | Active Scanning Technology

Fingerprinting with TCP/IP

Performance Issues | Active Scanning Technology Detection Methods

1 Black Box Testing

Manipulating TCP | Active Scanning Technology Detection Methods

Passive Network Analysis Advantages and Disadvantages

2 Detection Methods

3 Physical Layer

4 Data Link Layer

5 Network Layer

6 Layers 4 Through 7

Active Scanning Technology Advantages and Disadvantages

Advantages and Disadvantages

Passive Network Analysis | Vulnerability Management

Agents Advantages and Disadvantages

Agent Architecture | Vulnerability Management

Hardware: The Appliance Model

Compliance and Governance | Vulnerability Management

1 System Audit

New Policy | Policy and Information Flow

1 Usage Policy

2 Ownership and Responsibilities

Contributing Roles | Vulnerability Management

1 Asset Owners

2 Security

3 HR

4 IT

Operational Roles | Vulnerability Management

1 Vulnerability Manager

2 Incident Manager

3 Change Manager

4 Compliance Manager

The VM Program and Technology Development

Case Study: Technology Integration Challenge

1 Events

2 Analysis

Nuts and Bolts^[*]