Critical Incident Management

External corrosion threat

2019-06-17T18:16:00.003-07:00

Definition of hazard

• A characteristic or group Of characteristics that provides the potential for a loss.

• Examples: Internal and external corrosion, stress corrosion crack, material defects, third-party damage and environment including toxicity, flammability, exposed pipes, lack of signage, etc. Pipeline Corrosion Control

• Coating is the main corrosion control technique.

• But dependence on one source for protection is not a very wise approach - No coating is perfect.

• To protect coating flaws, cathodic protection (CP) is applied.

• Coatings and CP are successful combination for corrosion control. External corrosion on a pipeline could be microbiologically induced corrosion (MIC), or from galvanic action or elec- trochemical reaction, where the steel pipe becomes an anode in an electrochemical cell. This is a tinl&dependent hazard,and occurs after some time iri service.

To address these threats, collection of data is carried out, and based on the analysis of those data, a risk assessment plan is prepared. This is an important step. The data collection process is a painstaking and detailed activity. In the beginning, the collected data may be verwhelming and intimidating, but a good risk assessment program is data dependent. In fact, most of these data are already in the computers of the pipeline op erators but they keep sitting as dead data. In the world ofcomputers, it is easy to share, download, and transfer most of these valuable data and put them to better use. "Better use" IS the availability of the data for analysis that helps manage the risk. Periodically this collection ofdata can be refreshed and updated. There is no limit to the available data and its possible use. However, the basic data that needs to be collected in this context is listed below:

a. Pipeline year of installation

b. Pipe grade (ASTM A 106 Grade B, API 5L Grade B, X42, X65, X70, etc.)

c. Pipe diameter and wall thickness

d. Maximum operating pressure (MAOP) (or design pressure) and temperature e.

seamless, double submerged arc welding (DSAW)

f. Pipe seam type, e.g., electric resistance welding (ERW), Coating type, e.g., coaltar enamel, fusion bonded epoxy (FBE), three-layer polyethylene (3LPE)

g. Coating condition at the time of lxst inspection (updated periodically)

Active Scanner Deployment: Physical

2012-05-31T05:10:00.000-07:00

The first step in implementing a strategy for deploying physical scanners is to select a central location to which all scanners will report in the future. In the case where there may be multiple central reporting servers, select a location with the most hosts on the local network, and preferably one that has unfettered network access to other major locations. Verify that there is sufficient bandwidth available to support a schedule structured using the method previously discussed. Then, follow this iterative process:

Perform test scanning and remediation reporting on the local network where the reporting server is installed or is on another less critical network. A 24-bit classless inter-domain routing (CIDR) block would be sufficient.
Review the report results and any unexpected impact on the environment.
Adjust the system and scan parameters to compensate. Be sure that any adjustments you make are scalable to hundreds or even thousands of networks once the deployment proceeds.
Add as many similar network ranges in the local office as possible, one at a time.
Repeat the previous steps to validate the reports and impact on the environment. Adjust accordingly.

While waiting for a few cycles of this activity to complete in the local area, plan and coordinate the next phase of scanning over the WAN to other offices in the scope of your scanning strategy. These are offices that will not receive equipment but have the capacity to be scanned through their WAN connection without impact to operations. Again, repeat the evaluation and refinement process and update the scanning standards documentation accordingly.

As the expansion of scanning begins outside of the local office, begin generating and refining the management reports. At this stage, management will become quite curious about the results of the new system. Be sure that the reports are reconcilable and that questions about their content can be addressed. If the pre-acquisition testing has been done properly, this should be easily done with possibly minor assistance from the vendor. Having an executive sponsor who is willing to preview these reports before they go to a wider audience can help identify discrepancies and questions earlier.

At this point, as much as 75 percent of the initial zone of scanning should be deployed and processes beginning to take firm, repeatable shape. The next zone of deployment should then be planned by selecting another major office with as many good connections to other target offices. Then, repeat the gradual expansion process discussed in the previous steps.

Deployment Methods | Vulnerability Management

2012-05-28T01:09:00.000-07:00

There are many ways to deploy a system, and what is needed for the operating environment will possibly affect the solution chosen. In some ways, this is related to architecture, as discussed earlier in this chapter. But, there are other considerations to be made related to how you will deploy a system. In this section, we will discuss the major issues affecting deployment.

The goal in the approach to deployment is to achieve maximum effectiveness in the shortest period of time with the least investment. Following is the basic deployment strategy to achieve this:

Establish a foothold with maximum access to target systems.
Test processes on a small scale and refine.
Expand deployment by adding targets until the foothold is 75 percent deployed.
Simultaneous to item 3, create and refine management reports at all levels.
Take additional steps in other locations.

We will review each of these steps for active physical scanners, active virtual scanners, passive analyzers, and agents.

Access Control

2012-05-25T01:03:00.000-07:00

Access control is an essential feature of any application. Depending on the infrastructure standards, it is valuable to insist on an external authentication mechanism. Roles and access rights likely will have to be defined in the VM system but external authentication should be possible.

Active Directory

Active Directory^® is one of the most commonly used authentication mechanisms for Windows systems. Later versions support lightweight directory access protocol (LDAP) and LDAP over SSL for directory loading. Kerberos and NTLM are common options for authentication. Since Active Directory capabilities are so common in the corporate environment and standards are available to interface with other systems, this is a good choice. However, any LDAP directory service should work. There are two common approaches to Active Directory integration.

One method synchronizes directory information periodically, looking for additions and deletions. A copy of the directory entries is stored in the VM database for quick reference to access privileges. This is the most common and compatible approach that will use LDAP. Usually, special credentials have to be created to log into the directory system and retrieve the basic information about the users. Using LDAP also affords the system the option of portability to other directory services platforms.

Later, when a user attempts to log into the VM system, the credentials supplied by the user are sent to the authentication system using NTLM or Kerberos. Once the credentials are accepted, the VM system will apply the privileges stored in the VM database for that user.

A second approach is to natively integrate with Active Directory using the Active Directory in Application Mode (AD/AM) capability that comes with Windows .Net™ erver 2003. This enables the VM application to have its own instance of a directory service with schema extensions and built-in attributes but still participate in the security structure of the Active Directory domain. Naturally, the services that support this capability must run on a Microsoft-technology-based server. This provides a tightly integrated directory product for Microsoft-directory-committed organizations. A significant advantage of this approach is that Active Directory groups can be used to grant privileges in the VM system rather than creating an internal set of roles or user groups. The disadvantage is that you may be committed to the Active Directory platform.

RADIUS and TACACS+

In a more network-centric environment, RADIUS is a very common protocol option. It is an old method typically used for dial-in systems. However, the protocol is no less useful for network equipment. With RADIUS and TACACS+ , however, the user ID must be entered into the VM system since no directory service is provided. This user ID must exactly match that which is expected by the authentication server. The most significant difference between RADIUS and TACACS+ is the use of UDP versus TCP, respectively. TCP has the security advantage of being able to communicate with an authenticating source without spoofing since there is a handshake process in the protocol.

Some vendors of network authentication products go so far as to support RADIUS, LDAP, Kerberos, TACACS+, and other methods. These authentication products are able to effectively “glue” together various authorities and protocols, allowing a variety of methods to be employed.

Changing from one authentication method to another can be difficult, depending on the implementation. To avoid complications in the future, select a method from the beginning and stay with it.

Authorization

Authorization capabilities should be able to meet the various roles you have planned for operations. This is one key reason that requirements must be defined prior to beginning the RFP process. One of those requirements is a definition of who will perform what functions and what capabilities are needed. Role-based access control is the mechanism that will have to be vetted during the selection process. You should consider some of the following capabilities:

Separation by network: Some users will be permitted only to take actions against certain networks. Local IT personnel in Mumbai should not be able to examine any vulnerability reports for Chicago, for example. Scan parameters should not be modifiable by anyone except the VM administrator.
Actions: Closer to the definition of a role, there are the specific activities to be performed, such as defining a network or administering IP ranges.
Running reports: Many people are likely to be able to perform this function. Being able to generate a report is fundamental.
Conducting a scan: Few people should be able to conduct a scan. Active scanning capabilities are potentially disrupting to operations, and therefore should remain in the custody of those who are qualified to assess the impact on the network and the need for current audit results.
Maintaining the health of the overall system and available audit parameters: The parameters of audits should rarely be tampered with unless extensive testing has been done. Adding TCP ports or additional checks can impact the entire scanning schedule. Only a few people should be able to make changes to this. These people likely have a combination of security and compliance roles.

A good way to document authorization requirements is with a permissions grid. This grid should indicate the capabilities across the top and the roles down the side. See Table 1 for an example. Where a particular function can be performed, a “Y” or “N” is indicated. If access type is specified, then an “R” and/or a “W” are specified for “Read” and “Write,” respectively.

Table 1: Permissions Grid Example
ROLE/CAPABILITY	REPORT	SCAN	SCHEDULE	MAINTENANCE	PARAMETERS
System administrator	N	N	Y	Y	R
Local IT	Y	N	N	N	N
Regional security manager	Y	N	N	N	N
Global security	Y	Y	Y	N	RW
Global compliance	Y	N	N	N	R

Scoring Method | Vulnerability Management

2012-05-22T01:00:00.000-07:00

A close examination of the scoring method employed on the VM system is essential. Following is a list of basic requirements of a scoring system as it relates to security operations:

Take asset value into consideration. More valuable assets in your organization should definitely receive higher priority handling than those with little value. Somewhere in either the scoring method or alerting capabilities should be a consideration of an asset value in either numeric or category terms. The process of valuing assets may be time-consuming if it cannot be obtained from an existing asset management system.
Severity can be logically or intuitively determined from the score. If the number seems arbitrary or relative to zero, then it is difficult to determine if a score of 300 is severe, moderate, or informational. At some point, either from experience with the system or from knowledge of the method by which the score is derived, you should be allowed to determine the category of severity.
Current knowledge of available exploits should be included in adjusting the severity. Vendors would have to revise their scoring method if a new, easily scriptable exploit is released to the general public. The score should be dynamic to keep pace with a dynamic threat environment.
A standards-based primary or secondary score such as CVSS should be included for comparison to public databases. This will prevent any confusion about the meaning of a score that may be derived from a proprietary scheme.
Optionally, a score should have a cardinality component. This means that the score will vary, depending on the source of the assessment. If a vulnerability can be detected over the network from the public Internet, then it should have a higher score than a vulnerability detected from the local segment.

Determining the appropriate score for a vulnerability is partly mathematical and partly a matter of requirements. It is not unlike the computation of risk:

where p(x) is the probability of occurrence, ε is the loss expectancy from a single event, and ρ is the rate of occurrence per year. An example of a vulnerability score computation might be based on the following variables:

Severity of compromise (α)	Remote control of system = 100 Remote access to system = 75 Remote reconnaissance = 50 Local control of system = 50 Local access = 40 Local reconnaissance = 30
Ease of attack (β)	Easy (scripted) = 1 Medium = .75 Difficult = .5
Existence of exploit code in the wild (χ)	Exists = 1 Proof-of-concept only = .5 None = .25

So, the computation is a simple multiplication formula:

This simple approach to creating a score confines the score to a value between 3.75 and 100. That is, if “local reconnaissance” (30) is the severity, “difficult” (.5) is the ease of attack, and “none” (.25) is the state of exploit code availability, then:

Should the severity of compromise become “remote control of system,” which is very bad, and all other factors remain the same, then the score rises to 12.5. By extension of this simple approach, the worst possible score is 100, with the β and χ factors equal to 1 and “remote control of the system” being the outcome.

Many scoring methods are more sophisticated than this and consider additional factors such as the length of time the vulnerability has been in existence. Furthermore, other scoring methods do not confine themselves to a simple scale of 0 to 100, but rather have no upper limit. This will naturally occur when unbound numbers such as age of vulnerability are considered. Also, the example given here has very limited bounds because it uses simple multiplication; but other methods prefer to make a clear distinction between that which is really bad and that which is of low risk by comparison. Operators such as squares and factorials can drive the score very high for greater risk distinction. But such scores may be more difficult to interpret. Whatever method is preferred, be sure that it can be transformed into a form suitable for input into any risk assessment methodology in use.

Customization and Integration | Vulnerability Management

2012-04-16T00:18:00.000-07:00

Although frequently overlooked or treated as an afterthought check box, custom development is a significant area for specifying requirements. Very often, those who implement VM initiatives discover too late that significant customization is needed to maximize the potential of their security systems. This can happen when there are change management systems, often custom-developed, around which entrenched internal processes are built. Since it is unlikely that a new change management system will be purchased, the ability to efficiently extract information from the VM system and initiate a change and/or incident process is critical.

At a high-level, as previously described, when interfacing to a change or incident management system, the following items will need to be managed by the interfaces:

Extract vulnerability data from the VM system.
Initiate a change or incident in the internal system while retaining the reference provided by the VM system.
Take a provisional closure of the incident and update the VM system. This will optionally start a verification assessment.
An event from the VM system will trigger closure of the incident or reinitiation of the incident, depending on the outcome of verification.

Depending on the process and systems in your enterprise, these steps can vary the data structures and processing required in the interface code. A clear understanding of the interface capabilities of the candidate vulnerability systems is essential prior to purchase. Once understood, assess what coding requirements there will be for each candidate. This will help highlight any potential shortcomings that may significantly limit overall effectiveness. For example, the planned internal VM processes may require that detailed recommendations on remediation be transmitted from the VM system to the change management system. If this critical data element is not provided in the ticket generation process, then this may cause a critical gap in achieving IT security service goals.

System Integration | Architecture

2012-04-12T07:27:00.000-07:00

It is not unusual for an organization to simply purchase and install technology without consideration of its active role in the rest of the IT infrastructure. The end result is often a system with greatly limited technical functionality requiring significantly greater effort to integrate with other systems or major process changes to compensate.

There are numerous ways that a VM system can provide data to maximize the benefits to security and operations. Among those systems to be considered are change and incident management. These systems are commonly found in mid-size to large organizations trying to maturely and consistently extract higher performance from IT services.

1 Change Management

Change management is a critical component of the remediation process. As previously discussed, when a vulnerability is found, the details can be sent automatically to a change management system to initiate a change process.

The ability of the VM system to be interfaced with change management is never as straightforward as vendors tend to suggest. Some custom development is almost always needed. Development of this type is typically for the conversion of data types, format, and communication method. The vendor’s product may deliver SNMP traps for newly discovered vulnerabilities; yet the change system will require XML or use an e-mail listener process. Someone will inevitably have to code an interface between these two completely different technologies. The following common data elements are exchanged, whatever the interface method:

vulnerability details sent to change system,
vulnerability event identifier sent to the change system,
change status update sent to vulnerability system once remediation is complete, and
reopening or re-creating the change if the vulnerability is still present.

2 Incident Management

Similar to interfacing to change management, incident management may be a part of the portfolio of an operational support system in your organization. Interfacing issues are similar and will vary by process. In some cases, organizations prefer to handle changes in a change system but incidents are reserved for a very specific set of circumstances.

On the other hand, it is not unusual to generate an incident for tracking the vulnerability and remediation process, and then to use the change management system to track only the impact on systems, resources, and processes when that change is made.

In either case and as previously mentioned, the completion of a change will initiate either the closure of an incident or the immediate notification of completion to the VM system. The VM system will then reassess the target to determine successful compliance.

3 Intrusion Prevention

Some vendors have attempted to integrate their products with IPSs only to find that IPS vendors have dreams of competing against the VM vendor. This has led to a few failed attempts by vendors that would have otherwise benefitted the customer greatly. If you are lucky enough to have an IPS that is compatible with vulnerability data from a selected vendor, then by all means have a hard look at the benefits, as there are many obstacles.

Standards of format compatibility are a significant obstacle. Although we discuss standards at length in this book, few vendors fully support them in the IPS world, or the vulnerability world, for that matter. At this time, the two industries are so far apart in interoperability that only a demanding customer base will be able to influence change. However, the basic idea is that if a new vulnerability is discovered on a target system, then the appropriate upstream IPS will be notified to activate the signature that would protect the asset until it is properly remediated.

There are two major benefits to this type of integration. First, a vulnerability is protected until full remediation can be completed, which lowers the overall dynamic vulnerability level in the environment. Second, the IPS optimizes its performance since only the necessary rules are activated above the standard policy implementation. This is particularly important when a very expensive IPS is heavily loaded on a busy DMZ segment and a hardware upgrade does not offer sufficient cost–benefit.

4 SEIM

Security event and incident management (SEIM) integration is generally easier to accomplish. SEIM vendors make compatibility with myriad data sources an important selling point. The collection of data is their strongest suit and it is very likely that they will accept data from VM systems with little modification.

If your organization has an SEIM program, you would be remiss in not accepting this important data feed. Where the IPS integration is not possible, the SEIM program can at least use the data to determine the severity of an incident and escalate it accordingly. If your vendor does not easily support one of the major vendors of VM products, then they have likely chosen poorly.

Active Scanning Architecture

2012-04-09T04:43:00.000-07:00

Basic architecture of active scanning and the considerations to be made concerning consumption of bandwidth. One other key consideration is the management of several hardware devices. While this may seem trivial to an organization with hundreds or even thousands of servers, usually the staff maintaining the VM system is limited and requires unique training. They rely on resources of other locations and departments to maintain devices with which they are generally unfamiliar. Many of these devices have command lines, serial ports, and network requirements that may not be fully understood. Although many of the administrative responsibilities can be centralized and automated, there are inevitably malfunctions in the device or the environment that need to be corrected on-site.

For example, network connectivity can be lost at some point between the management server and the device itself. Despite all of the available tools, it may not be possible to determine the cause of the failure. A local engineer will have to check the physical connections, switch configuration, device power, and logical network configuration. This may involve plugging in a serial cable, configuring a terminal, logging in with local administrator privileges, and performing command-line functions. In all likelihood, the engineer has not done this in the six or eight months since the device was deployed. The VM operator will have to provide written or verbal instructions and receive some feedback. The use of a network KVM (keyboard video mouse) device is helpful but not perfect. The physical environment may still require inspection. If the network connection to the site is lost, then little can be done remotely.

Additionally, replacement of devices that have failed may be difficult but not for want of technical expertise. Some countries have import duties and restrictions on technologies that can extend the replacement cycle for months. Certain locations seem particularly unfriendly to commerce, particularly where technology is concerned. Russia, Venezuela, and even Mexico can be very resistant to receiving technology, to the detriment of their own citizens. It is even possible that final delivery in some locations may call for a small bribe to the delivery person. Ultimately, a virtual machine version of a product, if available, can be sent electronically and made operational overnight.

With an understanding of these issues, your plan will have to carefully consider the number of devices, location of each, skills of local personnel, languages, reliability of network, available bandwidth, power requirements, environmental conditions, customs procedures, and vendor presence and inventory. There are some clever ways to accommodate deficiencies in many of these components. Depending on your specific challenges, one or more of these strategies will help.

1 Determining the Number of Devices

Determine the number of devices required and include a growth factor. Volume is simply more difficult to manage. Determine the number of networks, strength of network connections, and number of targets. From this information, an estimate can be made for total load for scanning:

Then, estimate the amount of time required to scan a set of those targets with the candidate vendor’s product. A test of a scan under specific conditions provides the average time per host. Extensive testing is recommended since every environment is unique and will respond differently to the various approaches of vendors.

For example, a company has several networks in separate physical locations, as shown in Table 1. This table shows the amount of bandwidth provisioned, used, and available. In order to get an accurate estimate of the amount of time required to audit a network, there are two tests performed with these sites to determine the average amount of time required to scan a host. Some simple math gets a close estimate of how much time is overhead for gathering and transmitting results to the reporting server. Two tests are required with the largest practical target sample size. The key is to make sure the difference between the two samples is substantial enough to meaningfully calculate the difference, indicating the time required to scan a target. Following is the overall process for determining the number of required scanners:

Review the networks and select a representative sample of sites, WAN connection types, bandwidths, and host types. The type of WAN connection and bandwidth will impact the response time of scan activities and impact the total time on a large scale. Connections such as frame relay will show longer response time than higher speed Asynchronous Transfer Mode circuits (ATM) or dedicated private lines. Bandwidth will have an impact as well, but only up to a limit. Scanning activity has limits in device hardware and protocol connection limits.
Select a sample size (S1) of targets to scan in the representative networks. This sample size should be at least 10 percent of the total number of hosts but not less than 10. A second sample size (S2) should also be taken that is larger than the first by at least 50 percent and not less than 20. This will assure that the sample size is sufficient to show a meaningful difference in the results.
Capture measures to complete the table in Table 1. In the table, calculate the time required to scan each target (ST) by subtracting the time to scan the first sample (T1) from the time to scan the second sample (T2), and dividing by the difference in the sample number of hosts. This is the total time required to scan a single host (TT) absent the overhead for gathering, formatting, and transmitting results.
Calculate the amount of time required for the scanning overhead (OH) mentioned earlier. The overhead for the larger sample is the amount of time required to audit S2 minus time to scan all of S2 targets: S2 – (S2 – hosts * ST). The point is that there is a significant difference in the amount of time to scan targets versus the time to complete all of the activities of the audit.
Extrapolate and estimate the time to scan the entire network by multiplying the number of total hosts in the network by TT and add overhead: X = TT * OH. The final column in Table 5.1 shows this number. The sum of these figures shows the number of hours required if a single scanner were to audit all of the networks from a single location one after another. Although this scenario almost never happens with so broad a geographical distribution, it does provide a feel for the amount of device time required.
Decide on how often an audit of every target in the organization is needed. This will indicate the amount of time you have to allocate a single scanner for scanning targets and ultimately lead to the total number of scanners needed. A typical network should have audits performed at least weekly to be sure that newly discovered or reported vulnerabilities are captured on reports and that remediation activities are taking place in a timely fashion.
Create a proposed schedule for auditing. Since many targets will have to be in use during a scan, a schedule will have to be created with the information from the previous step. With a schedule, you can determine how many targets can be audited by a single scanner over a day or week. Note that you will have to consider local time, office customs, and target availability when making this schedule. Figure 1 shows a sample schedule. Looking at each time slot for audits will show how many audits must take place at a given time. This sample has four time slots per day each spanning a six-hour period on a Greenwich Mean Time (GMT) clock.

Figure 1: Audit schedule GMT chart.
Get the vendor’s recommendation on how many simultaneous audits can be performed by one device and how much impact that will have on scan performance. For example, a scan of network A may take 45 minutes when performed alone. But, when performed with another simultaneous scan of a network of equal specification, the scan may take 30 percent longer on average, assuming none of the network devices in between introduces more delay.
Estimate the number of devices needed. Referring again to Table 1, you can assess how many scanners are required by counting the recommended number of simultaneous audits to be performed and dividing by the number recommended. In some cases, you can reduce the number of scanners by rearranging the audit schedule. N.B.: Always leave room for error and growth. This arrangement shows us that if an audit of networks is performed from a central location, it is probably manageable with a single device, provided the device can conduct two audits simultaneously without significant performance degradation.

Table 1: Scan Time Estimation Chart
					AUDIT TIME
LOCATION	TARGETS	BWDTH	UTIL	AVAIL	10 TARGETS	20 TARGETS	TIME PER TARGET	ESTIMATE 20 TARGETS
HQ	450	N/A	N/A	N/A	9	11.5	0.25	119.0
Dallas	260	2000	72	560	13	15	0.2	63.0
Hong Kong	241	4000	45	2200	12	16	0.4	104.4
Santiago	75	384	80	76.8	11	15	0.4	37.0
Mexico City	245	4000	52	1920	8	13	0.5	125.5
Chicago	325	4000	62	1520	11	14.5	0.35	121.3
Atlanta	175	1544	70	463.2	13	16	0.3	62.5
San Francisco	310	4000	55	1800	9	12	0.3	99.0
						Total Hours Required		12.2

If it were determined that, due to operational constraints, the audit of “Chicago-Mfg” could only be performed on Wednesdays, then there may be contention for a time slot. Negotiating compromises among the operational requirements of each site can resolve such issues and further minimize devices. Also note that server networks can often be audited on weekends and late evenings, providing some relief to audit user workstation networks during the daytime.

Every network is unique and results may vary. Testing is an effective tool but not perfect in predicting the idiosyncrasies of networks and systems. Leaving some flexibility in requirements for adaptation is essential. Some advance planning and testing can save a lot of money when making a purchase. It will also enhance the credibility of the system and its operators in the eyes of the user population. Once the scanners are deployed, any top-end VM system should provide a means to report on scanner resource utilization, so the system manager can reallocate in a changing environment.

2 Select Locations Carefully

The location selection should be based on:

the number of targets to be scanned locally,
the bandwidth available to other adjacent networks,
the skill availability and skill level of the support staff for the location, and
the regulatory restrictions on IT issues such as privacy and union work rules.

Naturally, other factors such as shipping costs, taxes, and other important considerations should be made. Also, basic deployment logistics such as power supplies, rack space, and network physical layout should be considered but are typically minor factors.

Agent-Based Architecture | Vulnerability Management

2012-04-05T03:09:00.000-07:00

With agents, it is necessary to install software on every host to be evaluated, with the exception of some agents capable of performing network-based audits of adjacent systems. In some cases, vendors will charge a higher price for server agents versus desktop agents. There is no significant functional difference in the two that merits this pricing model but rather a matter of sales volume and cost recovery. Some VM architecture strategies will deploy agents solely on servers in order to minimize the impact on the network connections with the assumption that the agent itself will not impact other software. Vendors often recognize this and pricing is understandably higher.

The use of agents can become more complex when virtual machines are used. The agent can be installed on several guest OSs, yet they are deployed on a single physical server. The impact on the hardware is multiplied. One should seek some guidance from the vendor on how significantly the agent can impact the CPU and memory resources of a virtual machine and the underlying host OS and hardware. It is also likely that the vendor will charge for each OS and not per CPU core.

Since agents have to be deployed and maintained on every host under assessment, the solution is less prone to network limitations and more a problem of operating the software on every host. It can complicate installation and deployment but virtually eliminate the cost of shipping. Organizations with a large, mobile sales force will benefit greatly from an agent-based system, since the WAN connection speed is unpredictable and the frequency of presence in the local office seldom.

Architecture | Vulnerability Management

2012-04-02T08:58:00.000-07:00

The architecture of a VM system is an important part of its ability to work in your corporate physical structure. It also will probably be the largest factor affecting the cost of the system. Considerations such as geography, office size, network equipment, security architecture, WAN bandwidth, and government regulations will impact greatly your decision regarding vendors, type of product, and cost.

The last item, cost, is our starting point for making a decision on vendors. Begin with a survey of the VM market, pricing, and products. Determine what the approximate cost per active IP address would be to your organization. An estimate of the number of IP addresses would be sufficient if you can stay within 10 percent. Multiply the average price per IP in the market by the number of IP addresses in your organization, and then add 20 percent for annual maintenance. Then, add 10 percent for shipping and customs if you have foreign offices, and another 10 percent for consulting services if you have more than 15,000 IPs. For example, 20,000 IPs × $8 per IP = $160,000; then add 10 percent for shipping and 10 percent for consulting = $32,000. Total fixed costs: $192,000. Then, calculate the recurring cost of maintenance: $32,000 annual maintenance (160,000 × .20). Total cost of the system for the first year is $224,000.

This is only a cost estimate and will be impacted significantly by the previously mentioned architectural factors. In an active scanning system, physical scanners must be purchased and installed in good vantage points in the network. In an extreme example, if your environment has 100 offices with the only good scanning point being in each office, that is, no strong WAN links, then you will end up purchasing up to 100 devices. These devices can be expensive, depending on the product. There are sometimes less expensive solutions, including a virtual machine version of the product or the use of host agents with no per-instance charge. However, there will be some hardware costs for the buyer who supplies his or her own. It may be more cost-effective if CPU cycles are available in a virtual machine.

Passive Architecture

Passive scanners that observe network traffic may even be more subject to this limitation since the traffic on each inspected network switch must be copied to the device. For large but complex central offices, a passive scanner is a very workable solution where connections are typically very fast and can withstand the loads that can be imposed by the remote switched port analyzer (RSPAN) function. For organizations that have several large offices with ample WAN bandwidth, active scanners can be an excellent solution. Since bandwidth is becoming less expensive and more abundant in remote areas of the world, careful planning and scheduling of audits can allow scanning to be more cost-effective with fewer scanners and lower shipping and customs costs.

Centralizing the VM function as much as possible can result in considerable savings.

Automation Technology

2012-03-30T02:56:00.000-07:00

Automating as much of the VM process as possible will go far to having it embraced by the organization. The automation must take the form of integrating with existing systems and providing a virtually invisible footprint. More out-of-the-box integration is called for, using well-established standards rather than labor-intensive customer programming. Standards such as XML and RPC are very useful items to look for.

1 Ticket Generation

The creating of change or incident tickets is a key area for automation. The system should be able to interface with the ticketing system in a way that all of the required fields are supplied or synthesized, and also supply the most relevant information to the ticket recipient. Make a list of the items your ticketing system requires and verify that all of those items are available in a ticketing interface or that they can be easily created. For example, some ticketing systems require a user ID of the person who created the ticket. If it is acceptable to the ticketing system users, a “vuln-system” user or equivalent can be created to accept entries from the system. Alternatively, perhaps the interface from the VM system can provide the target owner name or network owner name as a user ID. Small details like this will quickly derail your plans unless they are all spelled out.

Completing the VM process is support for remediation. Once a ticket has been accepted and the remediation completed, a provisional closing of the ticket should be performed. This event should then automatically notify the VM system that the remediation has been completed and verification should take place. A follow-up scan can either be immediately performed or performed at the next scheduled time. If the target is free of the vulnerability, then the ticket can either automatically complete closure, or the VM system can send a message to the ticketing system to close the ticket. If the vulnerability has not been properly remediated, then the ticket should be reopened or a new one generated, depending on the internal process requirement.

Involving the owner of the ticketing system in the product selection process is an important factor if you are considering integration. The amount of work required for the integration should be accurately assessed since it could be expensive, depending on the flexibility and ease of use of system interfaces. Besides, one can never expect the integration to take place without the support of the system owner.

2 Process Integration

Any VM system should have some flexibility in integrating with existing IT processes. Although some of these processes may not be present in an organization prior to acquisition of hardware or software, the basic idea of a VM process is unavoidable. Vulnerabilities are detected, analyzed, and remediated. Even though each step may not be thorough or well-documented, they will nevertheless probably exist and should be documented to the extent necessary to validate requirements against system capabilities. In many cases, it may be easier to re-engineer the process into a more standard form. Remediation through patch management is an area significantly impacted by process and technology integration, and this demands greater flexibility as well.

3 Process and System Flexibility

Some VM systems are built around a specific and relatively rigid process. During the sales cycle, vendors often tout this process at the outset to demonstrate excellence of the product in how it delivers consistent results. Unless the buyer of these products is very flexible, efficient, and adaptive to changing critical and ingrained organizational processes, the tool will consistently deliver poor results.

This can become a limitation on the tool’s effectiveness rather than an enhancement to the vulnerability state of your organization. Having a rigid process around which the tool is built helps the product developer because it simplifies design and coding and it also simplifies the tool for the end user. But, organizations requiring easy cultural and technological integration have much more to gain if the tool can be molded to their requirements. Following is a list of types of flexibility required in technology:

Provide reports in the format suitable to your environment and culture. Some companies are averse to logging into a system and selecting parameters to receive a report. This is usually because users are so busy that they cannot include a process and system change in their daily routine. A great method for getting the important data in front of them is to send it automatically to the right manager. E-mail is a common delivery mechanism that everyone already uses.
Alternatively, some IT managers have Web portals that they use daily in their routine. Some critical information about their networks would be useful on their personalized home page. For example, a “top-10 hosts” report showing the hosts with the worst scores in their network will help them quickly assess and assign remediation tasks. For more senior managers, a “top-10 networks” or “vulnerability trend” report would help to quickly show where problems might exist with a 10-second review.
Allow for individual IT managers to set up and perform audits of their area of responsibility outside of the standard, agreed-upon schedules. In active scanning, this is known as scan-on-demand. It is a valuable remediation verification tool that can minimize error in remediation. Engineers sometimes remediate the wrong vulnerability, or misunderstand and incorrectly remediate one. Another common mistake is failure to reboot after installing certain patches. The verification process, driven by the system owner or IT manager, can enhance the quality of remediation results.

4 Patch Management Support

Patch and change management interfaces have already been discussed. If the related processes are present in your organization, then some basic data requirements should be met. But the VM system should also provide an interface that is sufficiently flexible to respond to processes. For example, internal processes may not perform a verification audit of the vulnerability and wait until the next audit. Although the change process may have completed and, in doing so, have informed the VM system, a verification scan should have the flexibility to be performed as part of the next, regularly scheduled audit. Anything else may demonstrate too much rigidity in the workflow of the tool.

Professional services are typically required for customization. Beware of this challenge and look deeply into the implementation requirements for your process adaptation. If the product vendor informs you that customization is only reliable or most reliable with the use of professional services, then the cost of the deployment may be deceptively low. Include with the purchase the delivery on specific process integration requirements.

Advanced Reporting Vulnerability Management

2012-03-27T08:54:00.001-07:00

Beyond the reporting discussed so far and related to customization, more advanced reporting capabilities are yet to be fully demonstrated by vendors. We will discuss this in a separate section of this book because, for organizations that have not yet begun to mature their processes, these capabilities may not be immediately needed. However, if you think that your organization will have a firm need for reports in support of process optimization, consider the following basic requirements:

The product should be able to allow for customized reporting based on access to raw audit results.
Summary tables of audits should be available in an open database structure (schema).
Add-on functionality should permit some statistical analysis of vulnerability data.
Beyond data analysis, the information should be combined with or readily able to combine with network topology information to assess risk by attack vectors.

These capabilities are more complex and require greater discipline in staffing and process. They directly feed risk management functions as well as security incident management. Products already on the market can combine this information from the major VM vendors and combine it with firewall, intrusion prevention system (IPS), and network equipment products to map and identify threats. Some vendors can even permit you to assess risks at a high level and then drill down into the specific configuration items on host, network, and security elements that can be altered to remediate an impending threat.

Assess your candidate vendor’s compatibility with these advanced products to leave a path for future enhancement. As of this writing, the most advanced of these risk management products are few and expensive but offer great functionality to the technical risk manager.

Reports | Vulnerability Management

2012-02-13T04:54:00.000-08:00

Reporting is an important part of vulnerability management and managing any process that can be measured. Before completing your evaluation of any vendor, a clear understanding among the key people involved in VM should be in place as to how the process of identifying and remediating vulnerabilities should be conducted. Then, ask critical questions about what managers, engineers, administrators, auditors, and risk managers need to know to perform their part of the process and get the most out of the system. This will lead to a definition of the reports needed. Consider distributing sample reports to stakeholders to make sure they are acceptable. Those reports have the following high-level requirements:

Scheduling (frequency with which the reports will be needed): In some cases, reports are needed weekly to remediate the latest vulnerabilities, and in other cases, monthly to evaluate the security posture of the organization. In still other cases, reports may be needed every time a certain event occurs such as a threshold being reached on total risk to a critical target. Having an idea about the timing and frequency of all the reports will reveal what kind of scheduling flexibility is needed in automated reporting.
Objective: Knowing the exact purpose of the report will often help identify whether the right report is present in the system or needs to be developed. Some reports produced by a system are titled differently but still may meet the objective. On the other hand, it is possible that the reverse may happen. A report may be titled “Audit Review,” which seems intended for the use of auditors; however, close observation may show that the report will not meet your specific auditor’s role definition. An ancillary point here may be that you should not be too quick to check a requirements box until you have verified the details of the reports.
Format: Most reports are not very customizable. The order of the columns, sorting and filtering options, and header and footer content may be unsuitable for your organization. The latter requirement can be a significant problem. If a vulnerability report does not have the company-required document classification statement in the footer, and company logo or department name in the header, some concerns could arise with auditors looking for compliance in document handling. Also, the utility of a report can vary greatly with the sorting and filtering capabilities. If a scan results report can only be sorted by IP address and not by severity, perhaps the prioritization process cannot be efficiently conducted.
Customization: When appropriate canned reports are not available, some access needs to be given to the database and schema to allow reports to be generated that simply aren’t available in the core product. This can also be provided with a report writer add-on. Any such add-on will have to be equally vetted with the requirements. Also, one must consider that additional products or consulting used will raise the overall cost of the system.
Types: The most common critical areas for reporting are remediation, security posture, and process monitoring. The type of reports you will need will naturally depend on how your process works. Remediation reports should specifically facilitate the methods by which your process remediates. This sounds obvious but it is not. For example, a company may have a different group remediate vulnerabilities in each city or office network. So, the reports should be available by location.

Alternatively, your organization may remediate by device type. For example, server administrators may all work for a global server group. Vulnerabilities for those servers would be assessed and prioritized, and work allocated by a central group. This may be the case even though the audit of those servers by the system took place as an audit of the overall network.
Triggers: Some reports need to be generated when a certain set of conditions are met. These reports are typically e-mailed or copied to a specific location for retrieval. The triggering event can be when the vulnerability score or a particular target reaches a certain level or when a critical host has a certain severity of vulnerability. These reports would then be automatically e-mailed to specified persons who are necessarily authorized users of the reporting system.
Roles: Any report should be configurable to be viewed or modified by specific roles. Those roles would be defined as system administrator, network owner, network group owner, or system (target) owner. There are two purposes for specifying which roles or combination of roles are permitted to access or modify a report:
- Separation of duties: This assures that reports cannot be manipulated for a favorable outcome and contradict any performance penalty that may be weighed against a responsible party who fails to remediate systems.
- Confidentiality of the data: Each report contains a potential gold mine of information to a hacker that could surely be used to assess targets and attack vectors.

The most flexible approach to implementing roles is to allow the VM system administrator to create the roles and assign the users and user groups to those roles. More about role definitions later.

Control: The reports should be filterable by network, IP range, system type, scanner, application, or network owner. You will quickly find that once the availability of good data is known by managers and engineers, they will ask for more. Having in-depth knowledge of the structure of local networks, network managers may ask for particular subnet reports and IP ranges even though the audit process takes place on all IP addresses that can be found. Essentially, what is audited for vulnerabilities is a superset of the reports requested by the network owners.

Owners of applications may ask for reports showing the vulnerability state of the systems supporting their applications. This may include a combination of routers, firewalls, database servers, application servers, and Web servers. This may be especially important for SOX compliance or limited PCI audits. Large organizations with very limited PCI exposure will need to assess the vulnerability of any systems directly or indirectly related to payment processing. Being able to readily identify and audit those systems without clouding reports with vulnerability data from irrelevant systems can save time and cost in an audit. The same principle holds true for non-PCI financial systems. SOX compliance should not be seen as a reason to accept or reject functionality from the VM system; however, it can be helpful in evaluating controls related to financial systems. Public companies should carefully consider the real requirements of SOX in accordance with the 2007 SEC guidance on the topic. Vendors would be hard-pressed to provide solid advice and rationale directly related to SOX compliance and their products.

Standards | Vulnerability Management

2012-02-13T01:41:00.000-08:00

Every vendor has a different approach to detecting vulnerabilities. In the early days of VM products, this proprietary approach was the primary means of distinguishing one product from another. The ability to be accurate yet fast was essential. However, this has led to a severe lack of sharing of information among product vendors, which threatens the effectiveness and consistency of security as a whole for customers. Since the results of vulnerability assessments may vary from one vendor to another, how can you be sure which results should be used to take remediation action? If one product detects a vulnerability by looking at a registry key, and another misses the vulnerability because it uses file detection, how can the security manager rely on either product since no single, reliable best-practice detection method has been employed? Discrepancies will exist if multiple VM systems are used that can create additional work to resolve them. So, that is not an efficient solution either.

Conversely, similar results can occur when software distribution methods used by organizations do not result in the common footprints on a system that result from a standard local installation. In some cases, applications on the Microsoft Windows^® platform can be installed with certain registry keys missing. When the vulnerability scanner looks for these registry keys and does not find them, then the vulnerability status can be misread.

A more global problem is the lack of standard vulnerability identifiers. For example, if the vulnerability management system uses proprietary identifiers for vulnerabilities and the patch management system uses Bugtraq ID numbers, how can the two be reconciled? In some cases, there is no identifier available for a particular vulnerability that was discovered by the VM system vendor, and therefore only a proprietary index is available. Some kind of standard adherence is needed to maximize the effectiveness of the overall VM process and assure consistent identification worldwide.

Solutions are available. If it were agreeable to vendors and MITRE Corporation alike that vulnerabilities they discover can be centrally identified and described, then patch management systems could rely on those identifiers.

Alternatively, some vendors have already integrated functionality such as patch management so that compatibility in vulnerability identification and corresponding remediation is not a concern. However, this limits the choices of products and functionality. The VM systems buyer is committed to the vendor for both functions. As of this writing, no vendor provides comprehensive patch support for all OSs and all vulnerabilities, nor are they likely to do so in the future. Oddly enough, at the time of this writing, there are more than 33,000 Common Vulnerabilities and Exposures (CVEs). Yet, top VM vendors cover less than 75 percent of that number. Why do so many customers tolerate this obvious deficiency? If a vendor told you that his product was no more than 75 percent effective, would that be acceptable? Customers need to recognize this key deficiency and demand more.

Recognizing that they cannot do everything, vendors will build-in the ability to interface with key management and tracking systems such as change management and incident management. The number of compatible vendors may be limited. In that case, vendors have built an API that will allow the creation of a custom connector between the VM and other systems.

We previously discussed technology and the support for standards such as the Common Vulnerability Scoring System (CVSS), CVE, and OVAL^®. There are great benefits to adopting a standard for any technology. But, given the rapid proliferation of security technologies and their competitiveness with one another, the adoption of standards should become a more critical requirement. Initially, it would seem foolish for a vendor to “give away” functionality to another vendor. However, by providing the flexibility to choose the needed products, vendors can increase their chance of selection. This creates a chicken-and-egg problem where the vendor must support the open standard and the customer must demand it. OVAL is one of the more specific and important standards that should be seriously considered on a requirements list.

Scheduling | Vulnerability Management

2012-02-09T06:34:00.000-08:00

In the previous section, we discussed how audit scheduling may be a requirement. This granular requirement is the specification of the type of controls needed on the assessment process. Related to the previous discussion, the timing and resource controls available to a scanner or agent can vary considerably from one vendor to the next. For example, the ability to set the time of day and day of week for an active scan is pretty standard. But, the business cycles of your firm may require that the assessment be performed at the same time each week and, if that schedule is missed for any technical reason, the assessment is performed on the next available day at the same time. Such a requirement is not uncommon in a busy financial environment where compliance is continuously monitored. Following is a list of considerations for other scheduling requirements:

Time of day, day of week: A pretty common scheduling method, selecting a day of the week or a time of day is very typical. Generally speaking, this setting should be adjustable for a particular time zone.
Day of month (first, last, particular day): This schedule is most useful in business operations where the targets must be assessed on a workday but the exact date cannot be reliably determined. Instead, the day of the week or day of the month would be specified. So, the parameter could be the first workday of the month, last workday, or even the last Monday. Some business cycles require that assessments only take place monthly or weekly on a certain day. For example, a retailer may perform collection of critical sales data on Monday mornings. In this case, it may be desirable to perform vulnerability assessment on Mondays after 12:00 noon (weekly) or on the last workday of the week (weekly) or the last Friday of the month (monthly).
Only during/after local work hours: The assessment of desktop computers generally needs to happen during work hours when the computers are switched on. It is increasingly important to have this level of control with the focus of companies towards curtailing energy consumption.
Start/suspend/resume during a time/date window: This is useful when an assessment requires more time than is available during a certain time window. For example, if a scan must be performed during work hours but needs more than 12 hours to complete, the assessment should be paused for the night and resumed on the next work day. The process should continue until the assessment is complete. If the schedule for the assessment overlaps with the next assessment, the next one should be deferred for one cycle. This may sound like a complex requirement but it is not uncommon and is currently not well-addressed by the products available.
For all scheduling of assessments, the date and time parameters should be adjusted for local time zone. There are varying methods of implementation; however, the result should be that if an assessment is supposed to start at 10:00 a.m. on Monday in New York, the same parameter applied to San Francisco would be 10:00 a.m. Pacific Time or 1:00 p.m. Eastern Time. This becomes even more critical for large, globally distributed environments. I have seen systems perform all scheduling to Coordinated Universal Time (UTC) to accommodate deficiencies in local scheduling capabilities. Assuming the network is in the same time zone, a very good approach is to specify the time zone for the target network or host. Then, the schedules applied can have a parameter, which indicates whether or not the time zone of the target should be respected.
If all of a network segment is not in the same time zone, then it would be prudent to divide the network definition by time zone logically in the VM system. This will allow the system to scan on an optimal schedule for each part of the network segment. If this is not possible, then it may be necessary to confine the scan window to a common time frame during which all hosts are available.

Division of Responsibilities | General Requirements

2012-02-06T03:33:00.000-08:00

The basic division of responsibility can be critical for meeting compliance and audit requirements in a large institution. The primary concern is to avoid having the vulnerability check parameters changed by a group or an individual with a vested interest in not appearing vulnerable. In addition to concealing vulnerabilities, this behavior is not unlike the age-old accounting problem where a business unit reports better results from one quarter to the next by changing the accounting rules. In the security realm, this leads to an overall security weakness that can threaten a large portion of an organization since vulnerability audit parameters can be applied globally.

Divided responsibility may not only have a compliance component, but a simple operational excellence one as well. In the delivery of IT services to the business, various groups are accountable and yet dependent upon other groups. This is no less true for the role of VM in the delivery of IT services. For example, the network group may have service level agreements (SLAs) to maintain that may be impacted by vulnerability scans. Those service levels are subject to change, depending on internal customer requirements, and may have many complex elements. The internal service provider, which may be a network group or server platform group, will need to exercise some control over when a vulnerability assessment takes place and perhaps how much of the provided service’s resources are consumed in the process. The network team may be concerned with how much bandwidth is consumed on a particular WAN link during an active scan.

A server team, however, may be concerned about the system resources required to operate an agent in different modes. Perhaps during an active assessment of the host, the agent consumes an excessive amount of CPU or conflicts with a single business-critical application service. So, limited control of the auditing process may be necessary, while control over the quality elements should be restricted to security and/or compliance.

A virtual machine environment can amplify the impact of an agent where multiple guest OS instances will require the operation of multiple vulnerability assessment agents. Also, the impact risk on multiple OSs simultaneously is increased by the fact that the host OS running a hypervisor may also have an agent running. Regardless of the group managing the resource scheduling for an assessment, given the testing and management required for certain activities, a single security group may not want to have this responsibility when there are already knowledgeable individuals who would prefer to take ownership.

In summary, the message here is that each group in an IT organization is accountable for the services it provides. The introduction of a new IT function has an impact on operations in other groups. Inclusion of representatives from the affected groups will be instrumental in identifying the impacts and requirements of the VM product. One good tool to facilitate the identification of these requirements is the process dependency diagram. Figure 1 shows an example diagram where the VM service is the focal point. However, this diagram can be expanded to identify dependencies that may be created for other services where their requirements may change.

Figure 1: Identifying VM system requirements.

From Figure 1, we should be able to quickly identify requirements for the VM system that not only achieve the objectives of identifying vulnerabilities, but also enhance the service levels of the affected systems. In this diagram, Network Services has provided requirements that affect the existing service levels:

audit scheduling around business hours;
bandwidth consumption requirements per site or other grouping such as source network; and
simultaneous network connections to minimize impact on routers and firewalls.

The Business Applications Services group, however, has requirements that not only affect the performance of the applications, but also a requirement to perform certain types of vulnerability checks. This is a common result of enhancing SLAs to reflect the security of a system. An SLA for an application services group may specify that tests will be performed on every new release for cross-site scripting and SQL injection vulnerabilities. The VM system has, then, not only generated service delivery burdens for a particular IT service, but has also enabled enhancements to existing SLAs through an operational level agreement (OLA) arrangement.

Using Nessus

2012-02-02T00:31:00.000-08:00

This section assumes that the user has installed both the Nessus client and the server. No instruction on these topics will be provided as it is well-covered in other books and the Nessus documentation itself. Nessus has two areas in the user interface: Scan and Report. The function of each is self-explanatory. Figure 1 shows the scan target window. It allows the user to enter a host IP address, DNS name, IP address range, subnet specification, or an input file with a list of hosts/IP addresses. Each of these target specifications are saved so that scans can be repeated in the future.

Figure 1: Nessus target selection panel.

Next, the user can define the parameters of the scan by creating a scan policy. Shown in Figure 2, this policy contains:

Basic options about the scan (aggressiveness, packet captures, types of port scans, logging, etc).
Credentials if white box testing is to be performed.
Plug-in selection to employ the latest and most relevant checks. The library of plug-ins for Nessus is extensive. The key to efficient scanning is to select only the plug-ins needed for the target network.
Network congestion control settings (simultaneous connections, time outs, target disengagement rules).
Advanced parameter settings for various protocols and checks.

Figure 2: Nessus Scan Policy plugin selection.

Once all of these parameters are selected, the scan can be performed. When complete, the report is available in a hierarchical, navigable format. This report can also be exported to HTML. The report is easy to read, as shown in Figure 3. This example entry from the report shows the port and protocol used to obtain the information, SSL forNessus (tcp/1241). Then, the report shows that the Supported SSL Cipher Suites plug-in was used to find the vulnerability. In this case, it is not actually a vulnerability but an enumeration. After that, the remainder of the report item is self-explanatory. A very nice feature of Nessus is that it shows the output from the plug-in, which in this case reveals the extent of the information that was revealed by the SSL service. Even better than this, for the technically inclined analyst, the Nessus ID will link to the details of the plug-in on the Tenable Web site. This plug-in also has source code that can be reviewed so that the method of checking can be fully understood.

Figure 3: Nessus vulnerability details report.

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.

Critical Incident Management

External corrosion threat

Active Scanner Deployment: Physical

Deployment Methods | Vulnerability Management

Access Control

Active Directory

RADIUS and TACACS+

Authorization

Scoring Method | Vulnerability Management

Customization and Integration | Vulnerability Management

System Integration | Architecture

1 Change Management

2 Incident Management

3 Intrusion Prevention

4 SEIM

Active Scanning Architecture

1 Determining the Number of Devices

2 Select Locations Carefully

Agent-Based Architecture | Vulnerability Management

Architecture | Vulnerability Management

Passive Architecture

Automation Technology

1 Ticket Generation

2 Process Integration

3 Process and System Flexibility

4 Patch Management Support

Advanced Reporting Vulnerability Management

Reports | Vulnerability Management

Standards | Vulnerability Management

Scheduling | Vulnerability Management

Division of Responsibilities | General Requirements

Using Nessus

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

Nuts and Bolts^[*]