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/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