Enterprise and Federated Security: Some Frontiers

1. Enterprise and Federated Security:Some Frontiers

2. Topics • Background on Internet2 Security • Security at Line Speed Workshop • Security and Trust • Federated Security Services and Capabilities • Collaborative incident analysis and response • Security aware applications • Salsa and its Workgroups • Net Auth • Net Arch • Network Security and Applications • “Things like SPF” • H.323 and SIP Firewall/NAT approaches

3. Security • Designated as a strategic direction for Internet2 last fall • Intended to complement and augment other activities within the EDUCAUSE/Internet2 Security Task Force • Build on the success of the NSF-sponsored Security at Line Speed workshop • Created Salsa as member-driven steering group • http://security.internet2.edu

4. S@LS Workshop 2003 • NSF Sponsored workshop, in conjunction with Indiana University, Internet2, the Massachusetts Institute of Technology and the University of Washington. • Goal – to develop the issues and alternatives in coupling the need for advanced collaborative computing environment with growing network security threats. • 1.5 day Workshop 12-13 Aug 2003 • White paper is at http://apps.internet2.edu/sals/ • Ongoing maintenance needed

5. By “Line Speed”, we really mean… • High bandwidth • Exceptional low latency, e.g. remote instrument control • End-to-end clarity, e.g. Grids, desktop video • Exceptional low jitter, e.g. real time interactive HDTV • Advanced features, e.g. multicast

6. General Findings • First, and foremost, this is getting a lot harder • We seem to have hit a couple of turning points • New levels of stresses • Necessary but doomed approaches • High performance security is approached by a set of specific tools that are assembled by applying general architectural principles to local conditions. • The concept of the network perimeter is changing; desktop software limits security and performance options • There are interactions with the emerging middleware layer that should be explored • Tool integration is an overarching problem • We are entering diagnostic hell

7. Tradeoffs • Host versus border security • Deny/Allow versus Allow/deny approaches • Unauthenticated versus authenticated network access • Central versus end-user management • Server-centric versus client-centric • False positives versus zero-day attacks • Organizational priorities between security and performance • Perimeter protection versus user/staff confusion

8. Trends • More aggressive and frequent attacks, resulting in • Desktop lockdowns and scanning • New limits at the perimeter • Increased tunneling and VPN’s • More isolation approaches, straining the top of the desk • Hosts as clients only • Changes in technology • Rise of encyption • New attack vectors, such as P2P • Higher speeds make for more expensive middleboxen • Convergence of technology forces • New policy drivers • DHS, RIAA, etc. • LCD solutions to hold down costs

9. The Tool Matrix • For a variety of network and host based security tools, • Role in prevention/detection/reaction/analysis • Description • General issues • Performance implications • Operational Impacts • Network Tools include host scanning, MAC registration, VLAN, Encrypted VPN’s and/or Layer 3 VPN’s, Firewalls, Source Address Verification, Port Mirroring, etc… • Host Tools include host-based encryption, local firewalls, host-based intrusion detection/prevention, secure OS, automated patching systems, etc.

10. Local Network Security Design Factors • Size of class B address space • Local fiber plant • Medical school • Geographic distribution of departments on campuses • Distance to gigapops • Policy Authority of Central IT • Desktop diversity • …

11. Security and Trust • Security without external trust results in a defensive, highly constraining position with limited effectiveness • With trust, collaborative security and collaborative applications can be developed • Currently, there are two promising trust fabrics to leverage • Federations – emergent inter-enterprise • P2P (the trust fabric, not the architecture) – ad hoc, currently “non-scalable”, but new technologies will be appearing shortly and widely

12. Federated Security Services • Federated networks • Share a common network substrate • Share a common trust fabric • Together they could permit… • Collaborative incident analysis and response • Network-wide views • Leveraged diagnostic help • Ability for automated tools to use distributed monitors • Protect privacy at several layers • Security-aware capabilities • Trust-moderated transparency • Integrated security/performance diagnostics • Moving it into the broader Internet

13. Collaborative Incident Analysis • Moving beyond the “border” to see network-wide views • I’m seeing activity X? Are others seeing it? What variants are they seeing? Real-time attack recognition • From the central observatory, let me see the full address of the attacking node at site Y in the federation • I’m seeing an attack ostensibly from source address z at enterprise Y. Let me look at logging within site Y to verify • Correlate signatures and traffic among sites A-Z to provide an early warning system of DDOS • Let external experts from site Z examine our forensic information to assist our diagnostics • Requires federated backbone (meters, log files, etc) and federated trust fabric (for scaling, role-based access control, contact info, etc.)

14. Collaborative incident analysis • Scaling requires managing large data sets • Centralized – the Abilene Observatory, perhaps others • Distributed – on a per enterprise level • Which in turn requires a clear data model • Common event records, likely distilled and reformatted from native logs • Is enterprise-level security sufficient • And also pluggable modules for harvesting records by tools • Tools that permit analysis and yet preserve privacy • And also a trust fabric that permits multiple levels of authentication and fine-grain authorization

15. Federated Security-aware Capabilities • Federated user network authentication for on-the-road science • Control spam through federated verification of sending enterprises • Tell me which firewall is dropping which service request • Permit end-end videoconferencing through firewalls and NATs • Allow enterprise-specific patching paradigms to coexist • Create end-end transparency for use of Grids • Personal firewall configuration based on authorization

16. Moving it into the broader Internet • Picking approaches that are deployable and build on embedded bases • Federated substrata among those on common backbones • Interfederation issues – how hard will they be • International discrepancies in privacy • International IdSP’s - legalisms

17. Salsa Mark Poepping - CMU (chair) Chris Cramer - Duke University Gary Dobbins - University of Notre Dame Terry Gray - University of Washington Chris Misra - University of Massachusetts Doug Pearson - Indiana University Jim Pepin – USC James Sankar – UKERNA Jeff Schiller – MIT Joe St. Sauver - University of Oregon Steve Wallace - Indiana University • Technical Steering Group selected from Internet2 Member institutions’ • Intended to set directions and priorities for Internet2, create and manage workgroups, endorse community standards • Drawn from campus enterprise network security practititioners; typically the “best and brighest” • Two work groups right now – • Net arch • Net auth

18. Net Security Architecture • Get us to an architecture instead of piece parts • Too many parts with too much interactions • Diagnostic hell and innovation ice age • Current approaches are doomed anyway • Produce, as its first deliverables • Reference model (updated from various sources) • Common nomenclature • Ways to analyze application and middleware interactions with network layer security components

19. Network AuthN/AuthZ • Identify areas where middleware technologies can support intra and inter-realm security • Network access controls may depend on • The identity of the user • The identity of the device • The state of the device (scanned, patched, etc) • The role of the user • Other • Initiating organized activities to develop network authentication and authorization architectures and sample implementations, including responding to the TERENA mobility TF • http://www.terena.nl/tech/task-forces/tf-ngn/presentations/tf-ngn13/20040122_JR_GN2_JRA5.pdf

20. Network Security and Apps • Application-specific DNS-based • Leverage DNS with middleware based components to support applications • Things like SPF • H.323 and firewalls/NATs • Trust-mediated transparency