Scoring Method | Vulnerability Management

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

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

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.

Agent-Based Architecture | Vulnerability Management

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

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.

Advanced Reporting Vulnerability Management

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

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

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

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.

Inference Scanning | Vulnerability Management

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

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

Hybrid Approach | Vulnerability Management

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

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

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

Passive Network Analysis | Vulnerability Management

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

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

Table 1: Active and Passive Scanner Comparison 

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

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

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

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

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

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

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

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

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

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

Agent Architecture | Vulnerability Management

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

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

Figure 1: Agent architecture.

The basic kinds of agents include the following:

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

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

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

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

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

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

Hardware: The Appliance Model

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

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

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

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

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

 
Figure 1: The simple polling approach.

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

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