Multipoint solutions are redundant and complementary countermeasures that are deployed throughout an IT infrastructure.
Redundant solutions, commonly referred to as defense-in-depth solutions, perform the same logical function. For example, antivirus software may be deployed on individual client devices and on a network appliance scanning all incoming and outgoing traffic. With redundant solutions, there is no single point of failure for a particular service; if one countermeasure is down, the service is still available from the other countermeasure(s). Also, a vulnerability in one implementation of a countermeasure might not exist in other implementations (see Figure 3.3).
Figure 3.3: Multipoint solutions deploy redundant countermeasures at different points in the network.
An attacker may be able to use a buffer overflow attack to disable a desktop implementation of antivirus software from vendor A, but the network appliance-based antivirus solution from vendor B does not have the same vulnerability and thus is not compromised by the attack.
Complementary solutions are combinations of countermeasures that compensate for weaknesses in each other. Consider database applications. Modern database management systems use listeners—applications that wait for requests for services on particular (usually TCP) ports. A single instance of a database might use several ports for a series of services. For example, one port might listen for query requests and another might listen for service discovery messages. Each of these ports might have different rules for legitimate use, and no single countermeasure can prevent compromises to the database.
The service listening for query requests may accept requests from any IP address, but service discovery messages are accepted only from devices on the same network segment. In this case, a firewall on the network segment might block all incoming traffic on the port used by the service discovery program but allow traffic to the query listener. This setup prevents unauthorized use of the discovery service of the database while still allowing legitimate queries through.
Queries are usually well-formed requests for data, but they are also venues for database attacks. A SQL injection attack, for example, is a specially crafted query that takes advantage of weaknesses in a database application to allow an unverified and unsanitized query to execute. A database function designed to return a single application username and password can be exploited to return all usernames and passwords established in the application. A countermeasure to SQL injection attacks is to verify and sanitize all text strings before passing them on to the query processor to ensure only legitimate code is executed. By using both firewalls—to block unauthorized traffic—and verification routines within database applications—to validate authorized traffic—the two countermeasures provide more protection for the database than either can offer alone.
Challenges with Multipoint Solutions
With the additional protection that comes with multipoint solutions come additional challenges (see Figure 3.4):
- Synchronizing the activities of multipoint solutions
- Leveraging data from multiple countermeasures
- Ensuring graceful degradation of performance
As these three challenges demonstrate, there are costs associated with the improved security that comes with multipoint solutions.
Figure 3.4: Events recorded by multiple security devices and servers may be related, but correlating events can be challenging; in some cases, a security device will not register an event that other devices log.
Synchronizing the Activities of Multipoint Solutions
Individual components of multipoint solutions should be coordinated for maximum effectiveness. To begin, each redundant component should be configured to address similar threats. For example, both network-based content filtering and client-side antivirus solutions should be configured to respond the same way when potentially malicious content is detected. A notebook user should not have one response to malware when connected to the corporate network and another when not on the corporate network.
Leveraging Data from Multiple Countermeasures
It can be difficult to aggregate log data from multiple countermeasures. They might record information at different levels of granularity, event timestamps are often not synchronized, and it is not always obvious whether two events are related. In addition, some data that might be of use in a security breach, such as the source of a SQL injection attack, may be found in a Web server log file not in a security device's log. Consider automating the task of aggregating log data from multiple countermeasures. There are numerous tools available, including many IDS packages that accomplish this task.
Ensuring Graceful Degradation
Multipoint solutions can support graceful, rather than drastic, degradation in a service. For example, when an appliance running content filtering software for a network shuts down, client-based antivirus software can provide protection against malware threats. However, other content-based threats, such as leaking confidential information or the distribution of harassing emails, could still get through. When developing procedures based on multipoint solutions, consider how the failure of one or more components will affect the security service; relevant questions include:
- Will other components be able to compensate?
- What is the performance impact?
- What exposures are created?
- How will the component be brought back online?
Multipoint solutions are becoming standard approaches to implementing defense-in-depth security strategies. When deploying these solutions, it is important to understand which components complement each other and which are redundant. Redundant components can provide failover services and reduce the likelihood that a vulnerability in one instance of a countermeasure will render the countermeasure ineffectual. Complementary solutions provide a similar property but use different techniques to combat the same threat. Security countermeasures are like any other IT resources, they must be maintained and monitored to ensure they continue to meet their objectives.
This was first published in January 2007