Government enterprise: Peering into your network

A network without adequate security is a liability. From the ever-present threat of worms and viruses that can compromise network hosts to the potential for data leaks, the risk is far greater than the savings in resources and workhours saved by not protecting the network.

What’s more, if your company does business with the government, you can throw legal accountability into the liability mix. That’s because the Government Information Security Reform Act of 2000 required that government agencies manage information system security and its documentation. Then the Federal Information Security Management Act of 2002 (FISMA), part of the Homeland Security bill, made GISRA’s security provisions permanent. The upshot: Agencies must protect information from unlawful access, ensure the continued operation of information processing assets, and provide documentation and information that can be used to prosecute those who compromise security. It’s the law.

Given these strict guidelines, network administrators are now forced to grapple with a bewildering assortment of tools to ensure they know exactly what is moving through their networks. For government agencies and contractors — as well as many prudent corporations without governmental ties — the toolset generally comprises some combination of IDS (intrusion detection systems), IPS (intrusion prevention systems), and the requisite network forensics tools as critical foundations for a secure IT infrastructure. IDS, IPS, and network forensics systems are designed to detect unauthorized network access attempts, block those attempts that have been identified as illegitimate, and keep records of where the attempts came from. It is hard to imagine a secure network meeting FISMA requirements without relying on one or more of these anti-intrusion mechanisms.

Though the array of network forensics and analysis tools may seem endless, only a few need be implemented to gain significant insight into the network as a whole. As a practical matter, network admins will likely choose between an IDS and an IDP for defense at the network edge (see “A Dollop of Detection or a Dose of Prevention?”). IDS systems have come under fire recently for their passive operation, whereas IDP solutions are viewed as much more intrusive, because they must be implemented inline on a network segment. But either solution will provide a granular view of the security of the network.

To round out the defense team and to prepare for the very real possibility of a network intrusion, you’ll also need a forensic system. Don’t confuse a network forensics system with a network analyzer. The former runs continuously and focuses on issues such as archiving and analyzing data streams to provide an audit trail of network activity, packet payloads and all, to be used in civil or criminal cases. The latter, an essential component in any network toolkit, troubleshoots network problems, but does not monitor security. You can expect to pull out a network analyzer when problems occur, whether to determine why an application isn’t working right or to ferret out the cause of overall network performance issues. But forensics systems and network analyzers aren’t an either/or proposition; you will often deploy them in tandem. Besides, government compliance strongly suggests you employ forensics; good common network sense says you’ll need analyzers as well.

Keeping Intruders Out

Though they appear superficially similar, IDS and IDP are fundamentally different. IDS solutions are akin to a rear-view mirror: They can tell you what happened, but only after it’s already occurred. This can be of benefit when used as a verification tool for intrusion diagnosis, especially when implemented to notify administrators of an attack that is currently underway. It’s up to the network admin to take steps to halt the attack. But IDS solutions provide only a limited audit trail of an attack, which renders them largely ineffective for use in subsequent investigation and prosecution of offenders.

IDS systems are generally implemented on one side of a firewall at the network edge. Best practice is to place an additional monitor just behind the firewall to look for malicious traffic that may have breached the firewall. Taken further, an IDS could also be implemented at the network core. Some IDS solutions function with IDS agents placed at these strategic points on the network, with gathered data sent to a controlling server responsible for analyzing it. Others are contained in a single unit with a management interface and one or more monitoring interfaces.

Unfortunately, warnings generated by misconfiguredIDS solutions are often ignored because of their potentially high number of false positives. Administrators often blithely dismiss any alerts generated by an IDS solution. Furthermore, an IDS implementation is never complete; you must update and maintain it on a regular basis to flag false positives and to update signatures to identify new threats. Also, you may be regularly required to manually configure and categorize traffic types in order to limit the number of false positives — a misconfigured or outdated IDS system is of little benefit to anyone.

IDP solutions are related to IDS in that they can function as IDS systems, hence the “intrusion detection” in “intrusion detection and prevention”. But IDP takes the further step of actually filtering traffic.

IDP solutions are usually implemented inline, just behind the firewall. This placement permits them to detect and filter traffic that has passed through the firewall but has yet to reach its destination inside the network.

IDP solutions bring standard firewalling up several notches. Most firewalls operate at layer 4 (the transport layer) and classify and filter traffic based on what it claims to be, rather than what it actually is. This allows an attacker or undesirable application to use common ports to send or receive data. Many spyware applications use port 80 to contact servers on the Internet and pass through the firewall without raising alarms. The ability to determine the contents of a packet and make the decision to permit or deny access based on that data is much more complex than merely checking the packet’s header for source and destination information.

IDP solutions generally function through signatures, requiring a data stream to match a known pattern. These signatures are similar to virus databases provided by antivirus vendors, simply inspecting traffic patterns rather than file and process patterns. Some IDP solutions maintain an up-to-date signature database automatically, whereas others require a manual trigger.

When a data stream or packet matches a signature in the database, it is filtered at the input interface of the IDP. The signatures need not be limited to malicious traffic, but may also be used to detect specific functions of specific protocols. For example, it is possible to permit instant messaging traffic while filtering instant-messaging file-transfer attempts. Many IDP solutions allow you to construct manual signatures as well. For instance, you could create a signature that filters any traffic containing a specific word or phrase using any non-encrypted protocol or service.

If they’re not correctly configured, however, IDP systems can wreak havoc on networked communications. Whereas IDS false positives are just annoying, IDP false positives can be critical, erroneously filtering legitimate traffic and impeding everyday business operations. Be sure to plan carefully and conduct plenty of lab testing before implementing and further configuring an IDP system.

Sleuthing Out Activity

How deep and far ranging do you want your reports to be? You’ll need to answer that question before implementing any forensics system. If all you need is to determine which Web sites certain internal users are visiting, the scope is rather limited. If you want to determine which users are distributing specific information, to whom, and via what transport, then you’re looking at a much wider scope and a more complex implementation.

You can install simple network analysis tools at key areas on the network to monitor traffic and generate reports on that traffic. These tools can determine which internal and external hosts are generating the most traffic, the source and destination hosts, and the protocol used as the transport. Layer 3 (the network layer) and layer 4 network analysis packages generate reports by scanning the headers of packets seen on the wire and collating the data from a monitoring session. More complex network forensics tools can generate reports based on packet header information, but can also inspect the packet payload, with the ability to recognize and categorize traffic based on layer 7 (application layer) data.

Most admins appreciate being able to reconstruct data streams into their original format. For instance, when working on data collected during a monitoring session, a layer 7 network analyzer can determine that a source host transmitted a Microsoft Excel document to another host. Some analyzers can reconstruct the session completely, and are capable of completely reproducing the Excel file for perusal by the administrator. Some products can even detect and reconstruct an Excel file that was renamed and compressed into a .zip archive before transmission.

This type of deep analysis requires significant CPU and storage resources. Most forensic solutions are sold as appliances, arriving as fully configured devices built on rack-mount server platforms with significant local disk space to store packet captures. This makes for some powerful tools, and some expensive ones as well.

Staying Ahead of the Game

Given the critical nature of the task at hand, it makes sense to deploy these tools with care. After all, they are only as useful as the data that they can capture, store, and analyze; and the placement and archiving capacities of each solution will dictate its overall usefulness to the network. Although it may not be possible to permanently archive every packet flowing across the network for analysis, for example, it may be beneficial to archive that data for a few weeks or a month, with manual archiving of certain traffic for litigation or evidentiary purposes. Be sure to factor these needs into any decision.

But don’t let the complexities keep you from plunging into the fray. A network with only a firewall is lacking in security; intimate knowledge of the data carried over the network is a requirement in the quest for overall network security. Implementing an IDS or IDP and a network forensics solution will shed light on the day-to-day operations of the network, and provide a greater level of knowledge and control over the network. Without that insight, any network is a great unknown, and potentially a great liability.