1. Security Architectures and Advanced Networks Ken Klingenstein Day Job: Middleware Night Job: Network Security

2. CHANGE DATE 2 SALSA Overview  Technical steering committee composed of senior campus security architects Create understanding in the community regarding the multiple aspects of security as it applies to advanced networking Advise on deliverables that address need of members and produce tangible benefits  Prioritizing opportunities and identifying resources Focused activities Interested in R&D security topics that can be smoothly transitioned to deployment Intended to complement other activities in the Internet2/EDUCAUSE Security Task Force

3. CHANGE DATE 3 Membership  Chair: Mark Poepping, CMU  Founding members drawn from the Security at Line Speed Workshop – e.g. Jeff Schiller (MIT), Terry Grey (UW), Jim Pepin (USC), Doug Pearson (Indiana), Chris Misra (UMass), Steve Wallace (Indiana), Rodney Petersen (EDUCAUSE), James Sankar (Ukerna), etc…  Working on a charter  Minutes, etc at http://security.internet2.edu/salsa.html

4. CHANGE DATE 4 Possible SALSA Priorities  Developing core security architecture Common campus network reference model Common R&E internet network reference model Nomenclature and architecture  Additional case studies for S@LS and revisit the basics  Increase data collection, sharing and integration between security researchers and backbone activities  Net Authentication/Authorization  Federated Security Services and Capabilities

5. CHANGE DATE 5 Data Sharing  Assemble knowledge, experience and tools to identify useful security data to be directed towards a comprehensive, operational security solution  Identify associated privacy issues.  Working with REN-ISAC on plan, process and structure to share data: Data guidelines Information exchange frameworks Sharing agreements Escalation process  Increase integration and sharing between security researchers and network backbone activities (e.g., diagnostics, Abilene Observatory)

6. CHANGE DATE 6 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

7. CHANGE DATE 7 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

8. CHANGE DATE 8 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.)

9. CHANGE DATE 9 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  And also a trust fabric that permits multiple levels of authentication and fine-grain authorization

10. CHANGE DATE 10 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

11. CHANGE DATE 11 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

12. CHANGE DATE 12 Advancing Network Security  An architecture instead of piece parts Too many parts with too much interactions Diagnostic hell and innovation ice age Current approaches are doomed anyway…  Federated services and possible market making Inter-institutional authn/z activities Perhaps, with funding and trust, other federated security tools and services