Coordinating Our Network Defenses

Jan walks into the office at 8 a.m. with a hot cup of coffee and a calm look on her face. After a few minutes, she notices that the dreaded “Fawlty” virus tried to bring the corporate network to a grinding halt last night, but didn't. At first glance it looks like a visitor to the Executive Briefing Center inadvertently infected the guest wireless network, but a deeper trace suggests that a malicious Russian hacker spoofed a VOIP call to gain access to the core data center.

Finally, the records show, that amidst the chaos of last night's maintenance window, Jan's coordinated defense system correlated the “Fawlty” virus and the VOIP session to an infected, but authenticated, laptop running Windows XP in the EBC and quarantined it. She now has a name and number of an executive to follow up with today. She decides that she'll walk this one up herself.

Jan's fictional coordinated defense system sounds too good to be true. For most cost-sensitive buyers of off-the-shelf network security systems, it is too good to be true. For starters, Jan would need to know exactly where to look to find out what devices are on the network, who is associated with those devices, where those devices have been, what the network traffic from those devices looks like, and as much activity history of those network devices as possible.

Unfortunately, for most, this information is scattered among the various logs and records of firewalls, provisioning systems, and switches to name just a few places. In most organizations, gathering this data would require a heroic effort if it is possible at all. Furthermore, individual security components, such as firewalls, IDs and IDPs, antivirus gateways, client software, and authentication systems look for vastly different types of threats and are not configured to coordinate with each other. One component may perceive a system-wide threat as a network worm, another may see it as a compromised endpoint, and another may see it as a distributed authentication attack.

The various systems have no common way for contributing their piece of knowledge to a common picture to gain a more complete view of network and endpoint activity and status. Without such mechanisms, it is impractical, or impossible, to provide appropriate, coordinated responses to attacks using heterogeneous components, even if they are from the same vendor.

What about NAC – Is It Enough?

The concept of fine grain regulation of network connectivity by Network Admission Control (NAC) has been developing for the last five years. However, Jan's story requires something more; it requires a coordinated network defense.

Regulating the admission process with NAC is only the first step. With the variety of capable and proven NAC technologies available on the market today, we are entering an age where multi-vendor coordinated defense is the logical next step. What is coordinated network defense, and is it possible?

In a coordinated defense system, the various pieces of network infrastructure which are involved with providing services to devices (sometimes called "endpoints”) share information. The shared information helps build a holistic picture of network activity in order to better inform each component about specific actions.

The various components can be broadly categorized into the following groups: logical devices, access requestors, policy enforcement/decision points, sensors, core network and identity management services (see side bar for definitions).

The ideal multi-vendor coordinated defense system would allow various products which act in the roles above to share information and act on that shared information.

While proprietary systems from Microsoft (NAP) and Cisco (NAC) admission technologies can play a role in a multi-vendor coordinated network defense, the Trusted Network Connect (TNC) Work Group of the Trusted Computing Group has already defined and released an open architecture and a growing set of standards for endpoint integrity.

The TNC architecture enables network operators to enforce policies regarding endpoint integrity at or after network connection. The standards ensure multi-vendor interoperability across a wide variety of endpoints, network technologies, and policies. For example, the UAC product line from Juniper (which is an active TNC member) is proprietary, yet still appears to have the most coordinated behavior of any mature, commercially available system.

This kind of approach can provide a new kind of visibility, allowing IT teams to focus on what is actually happening on network and identify emergent properties and associations for comprehensive security, enterprise wide.

Some Key NAC Solution Considerations

For coordinated network defense to Work, IT teams should look for solutions that offer, multi-vendor support, agreement on information models, quick response times, detailed auditing, improved visibility and profiling of clientless endpoints.

Choreographing Network Defense

Coordinated Network Defense requires some critical well choreographed, inter-related steps:

click image for larger view

1. A user initiates an 802.1X connection to a layer 2 switch (i.e. PEP). The L2 switch captures the identifying information (i.e. the L2 Switches IP address, the physical port number to which the AR is attached, the MAC address of the access-requestor as seen by the switch) and communicates it to the policy decision point (PDP).

2. The PDP uses EAP to authenticate the user against RADIUS.

3. Based on the authentication identity, credentials, endpoint integrity data, the PDP applies local policy to define the roles, capabilities, VLAN, and device-attributes.

4. The PDP assigns the "access-finance-service-allowed" capability to the endpoint.

5. The PDP assign the roles "finance" and "employee" to the user "john.smith".

6. The PDP has chosen to assign the access requestor to VLAN 123 (the corporate VLAN) so it combines the information it received in the RADIUS request from the PEP with this assignment to create the link to the Layer 2 PEP.

7. Finally the PDP determines the proper device identifier name. The PDP can also attach optional device-attributes, and in this example the device-attribute 'anti-virus-running' is attached.

8. The AR leases an IP address from a DHCP server.

After Step 8, the holistic picture of the network endpoint might look something like this:

click image for larger view

9. An indirect PEP (firewall) sees a network session that it has not seen before and needs to determine whether to allow or prevent access by fetching the roles, capabilities, events and device-attributes.

10. The indirect PEP will use the capabilities, roles, and device-attributes as well as local policy to determine the access privileges allowed for this connection. For example john.smith might be allowed to access the finance server but not allowed access to the CXO data server.

11. A handshake occurs that causes evaluation of the device-attributes and the capabilities to change.

12. The output from the handshake indicates that the antivirus signatures are out of date. The PDP's local policy requires that access to the finance server is not allowed in this case.

13. The PDP removes the "access-finance-server-allowed" capability.

14. The PDP also changes the device-attribute from "anti-virus-running" to "anv-signatures-out-of-date".

15. The indirect PEP will detect the change in the capabilities, roles, and device-attributes as well as local policy to determine the access privileges allowed for this connection. For example john.smith is no longer allowed to access the finance server but not allowed access to the CXO data server.

16. The PDP, based on local policy, might also choose to assign the access-requestor to the remediation VLAN.

17. The PDP could then communicate the change of VLAN via RADIUS, and the L2 switch would place the access-requestor on the remediation VLAN

18. A sensor detects vulnerability on a specific endpoint. In this example, a vulnerability is found on the access requester device, and both the indirect PEP and the PDP both discover this and cut off or limit access.

Inside the Acronyms of Network Access/Admission Control

There are many acronyms in network access control and some unique to the Trusted Network Connect specifications. Here is a short guide to some of those acronyms:

Access Requestor (AR) – A logic software endpoint such VPN client or trying to gain access to the network.

Logical Device – A logical hardware endpoint such as a laptop or phone on which access requestors reside. Sometimes no access requestor is present and the logical device becomes a “clientless endpoint”.

Policy Enforcement Point ( PEP ) – Firewalls, VPN gateways, security enabled switches, and other inline devices which control sessions and flows on the network in real time.

Sensors (IDS, IDP, ILP) – Devices which monitor and classify network traffic.

Policy Decision Point (PDP) – Servers and software were real-time decisions are made about who and what is allowed on the network and what they are permitted to do.

Core Network Services (DNS, DHCP, RADIUS, LDAP) – Stateful runtime data concerning the presence, configuration, location, and ownership of networked devices and networked users.

Identity Management Services (Active Directory, Single Sign-on,Corporate Directories) – User provisioning systems.

About the author: Stuart Bailey is the Founder, serves on the Board of Directors, and is presently the Chief Technology Officer for Infoblox, a leading developer of core network services solutions for enterprise networks. Stuart defines the company's technological vision and direction. He assembled Infoblox's founding team in 1999 to execute a vision for supporting next-generation networks. This idea evolved during his time as the technical lead for the National Center for Data Mining at the University of Illinois at Chicago . He has been a principal participant in acquiring early stage venture capital for Infoblox in both the Midwest and Silicon Valley and has filled several leadership and technical roles in the company. Bailey is becoming known as an expert in creating and evangelizing the future of networking. He has been published and cited in journals including the Chicago Tribune, ISPworld, and ZDnet. Bailey earned his bachelor's degree in computer engineering from University of Illinois in 1994.