Keeping administrative traffic off the core internal (i.e., production) network gives you a definite security advantage. In the event of a compromise, attackers will find little in the OOB network but administrative stations, which typically contain administrative consoles but no important data. To manage an OOB, a security administrator needs two computers (and two network jacks)—one for administrative tasks related to components of the core production network (e.g., email) and one for managing the OOB.
Placing the inner sensor. On the inside of the perimeter firewall, in this case, within the DMZ, you can place a second sensor (see the lower red line). This sensor provides assurance that the DMZ machines are behaving properly and also verifies your firewall rule set. Just as you need to evaluate what's happening outside your network, you need to know how much dangerous traffic gets through your access control (i.e., firewall). To verify that the firewall is successfully applying its rule set, you can compare data from the outer and inner sensors. For example, if, on the outer sensor, you find many instances of RFC 1918 addresses, you want to know whether those addresses also appear inside. If they do, you know that you must reconfigure your firewall.
The comparison doesn't occur automatically. You must know—from a port, protocol, and application perspective—what inbound traffic the firewall permits. If the internal sensor stops traffic that the outer sensor saw but let pass through the firewall security membrane, you've just identified a firewall rule or configuration error that you must correct immediately.
For administrative purposes, the OOB is connected to both firewalls. The OOB might also send outbound traffic to the Internet (e.g., to perform searches or to update software), but you should never permit access from the OOB to the internal network—it's simply too risky.
Managing Your Network IDS
After you place your network IDS sensors correctly, you need to manage the information you receive. Your organization's overall approach to security—its security posture—determines how you characterize the occurrences—events and incidents—that your security system reports. An event is an occurrence that you can observe; it might or might not be a problem. For example, you might see that a node Address Resolution Protocol (ARP) has been queried—or "ARPed"—for an IP address. An incident is also an occurrence that you can observe but that you identify as both purposeful and problematic.
You need to manage the security information for a couple of reasons. Because every organization has a different threshold (i.e., the point that determines whether you classify an occurrence as a security event or a security incident), you'll find few agreed-upon best practices that you can implement. In addition, initial classifications aren't absolute: Many occurrences remain classified as security events until related occurrences come to light that lead you to reclassify them as security incidents. Finally, when you monitor any security system, especially a network IDS, you're bound to see false positives—alerts that appear to be evidence of an incident but that you can eventually classify as events.
Understanding false positives. In essence, a false positive is a security event that's mischaracterized (based on your organization's security stance) as a security incident. For example, a sensor might give an event too high a priority, which then triggers unnecessary alarms. Although the organization sets the event-incident threshold, false positives are difficult, if not impossible, to avoid. To set up the explanation of false positives, let me first give you some common examples of "true" positives.
Despite the subjective nature of classifying security-related occurrences, some events are usually (and properly) classified as incidents. The following occurrences indicate that something or someone is trying to penetrate (or already has penetrated) your defenses:
- Incoming connections with internal IP addresses. Obviously, inbound (i.e., outside) connections shouldn't have inside addresses. This attack is geared to trick your firewall into believing that legitimate systems have initiated the connections.
- Packets with destination or source addresses that fall within the reserved address space ranges defined in IETF RFC 1918. RFC 1918 designates IP addresses 10.0.0.0 through 10.255.255.255, 172.31.16.0.0 through 172.31.255.255, and 192.168.0.0 through 192.168.255.255 as reserved address space set aside for internal use only. You should never see these addresses on or incoming from the Internet, but because of attacks and ISP misconfigurations, you do. (For more information about RFC 1918, go to http://www.ietf.org/rfc/rfc1918.txt.)
- Unexpected outgoing connections on suspect channels (e.g., the Internet Relay Chat—IRC—channel). Worms commonly use such channels to communicate back to their creator about their progress.
Prev. page
1
[2]
3
next page 
