Protecting Network Assets

1. Protecting Network Assets CAMP: Bridging Security and Identity Management Christopher Misra 14 February 2008 Tempe, AZ

2. Agenda- DRAFT, needs to be updates • Automated Security and Policy Enforcement • History • New Challenges • Background/Roles of: • NAC • IdM • Network Segmentation • What might we do? • Firewall traversal • Grid case • Standards

3. Session Abstract • Can IAM be helpful in managing network intrusions and access policies? • Can IAM correctly correlate identity to an endpoint device by combining network registration and personal identification? • Can coupling network capabilities and IAM replace the use of IP addresses as the criterion for access with identity, roles, and related attributes? • This session will explore these questions and how one can identify the person behind the device or address.

4. Managing Network Intrusions? • Initial NAC deployments were not driven by architectural decisions • Large numbers of unmanaged systems connected to campus network • Primarily in residence halls • Battle scars from Code Red, Nimda, and Blaster • However, we did leverage campus IAM successfully • And we effectively created a device registry • Even if we didn’t integrate this data with our IAM

5. How we got here…or, before NAC was cool… • Why “Automate Security and Policy Enforcement”? From the SALSA-Netauth document Strategies for Automating Network Policy Enforcement: “(A) major security challenge facing university residential networks and other large-scale end-user networks is the thousands of privately owned and unmanaged computers directly connected to an institution's relatively open, high-speed Internet connections. Security policy enforcement is often lax due to a lack of central control over end-user computers and an inability to tie the actions of these computers to particular individuals. A few times a year there are surge events, including the predictable start of each semester and the unpredictable and increasingly frequent reactions to large-scale security incidents, that require massive support intervention.

6. Even though it wasn’t cool, we implemented NAC

7. And here we are…I guess NAC is cool now.. Network Access Control: Vendor Definitions • “Using the network infrastructure to enforce security policy compliance on all devices seeking to access network computing resources” – Cisco • “…combines user identity and device security state information with network location information, to create a unique access control policy…“ - Juniper

8. Why did we implement NAC systems? • Only automated approaches can scale and respond rapidly to large-scale incidents. • Preventative policy enforcement reduces risk: • overall number of security vulnerabilities • the success of any particular attack technique. • Automated remediation systems have a positive impact on a large number of hosts with a relatively small time investment from computing staff.

9. Network Access Control • Higher education created many early systems of what is now termed NAC (Network Access Control) • Southwestern Netreg, CMU Netreg, Packetfence, others • Currently there are many commercial offerings in the space • 30+ vendors at last count • Major deployments by Cisco, Microsoft, Juniper and others

10. Network Access Control in Higher Ed • Characteristics of higher ed networks lead to unique challenges • Large numbers of unmanaged systems connected to campus network • Residence halls • Heterogeneous computing base • Frequently no ubiquitous administration structure • Complex network Use Cases

11. Network Access Control in Higher Ed • Associating a device with an identity • Is the user a member of the campus community? • Leveraging campus IdM • Determining a host’s posture • Is the host compliant with local policy? • Measuring device state against campus IT security standards • Role-based network assignment • What network perimeter is appropriate for this host? • vLAN, subnet, firewalls, ids

12. NAC Basics • Registration options include: • Open DHCP (“free love”) • DHCP with MAC registration (“netreg”) • Web middlebox (“portal”) • 802.1x (“supplicant”) • Enforcement types include: • vLAN isolation/DHCP scope isolation • Network-based firewall/Host-based filters • Class of Service (rate limit)

13. NAC: Posture assessment • Original implementations used active network-based scanning • Windows XP SP2 rained on this parade • But security staff didn’t compliance • Many sites migrated to client-based posture assessment • Running code on endpoints to validate compliance • Could be implemented in the 802.1x supplicant

14. NAC is Complicated

15. Federations have a role here also • Enable members of one institution to authenticate to the wireless network at another institution using their home credentials • E,g, eduroam which stands for Education Roaming, is a RADIUS-based infrastructure that uses 802.1X security technology to allow for inter-institutional roaming. • “Being part of eduroam allows users visiting another institution connected to eduroam to log on to the WLAN using the same credentials(username and password) the user would use if he were at his home institution. “ • Effectively need to achieve identity discovery • Also applicable to Grid environments

16. Correlating identity to device to privilege • We’ve done a pretty effective job so far • But the drivers were not traditional IAM drivers • Can we assign a meaningful Level of Assurance to this correlation? • Not so sure. • Are we willing to use this correlation to grant privileges? • Dynamic vLAN assignments? • Firewall traversal capabiltiies?

17. Correlating identity to device to privilege • We need to understand the relationship between user identity, device identity, and host integrity (posture) • This is complicated further in a federated environment • Does (user + device) == privilege? • What about users with multiple roles? • Is this a network, security, or idm problem? • D) All of the above • Perhaps we need to step back and take an architectural view of this…

18. Drivers for NAC standards • Community desire for interoperable components • Heterogeneous campus environment • Modular network architecture • Ability to use commercial and open source components • Vendor-made switches • Open-source registration and remediation

19. NAC Standards space • Trusted Computing Group • Trusted Network Connect • Vendor ‘standards’ • Cisco NAC • Microsoft NAP • IETF NEA • Chartered only for client-server protocols