Security Architectures and Advanced Networks

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

2. Security Topics • Educause/Internet2 Security Task Force • Effective Practices • I2 Resource Commitments • REN-ISAC • S@LS workshop • SALSA – a steering group for advanced network/security technologies • Federated security services • Collaborative incident analysis • New security-aware capabilities • Going forward

3. EDUCAUSE/Internet2 Security Task Force • Overarching umbrella for a variety of coordinated security • Activities include education and awareness, policy, technologies, etc. • Two important recent activities • Effective Practices - http://www.educause.edu/security/guide/ • NSF Security at Line Speed Workshop

4. S@LS Workshop 2003 • NSF Sponsored workshop, in conjunction with Indiana University, Internet2, the Massachusetts Institute of Technology and the University of Washington. • 1.5 day Workshop, held in Chicago, Illinois, 12-13 Aug 2003 • Extensive on-line follow-up discussion to refine and recover • White paper is at http://apps.internet2.edu/sals/

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

6. S@LS Security topics • Information leakage: access to data by unauthorized parties • Integrity violation: destruction, modification, or falsification of data • Illegitimate use: Access to resources (processing cycles, storage or network) by unauthorized users • Denial of Service: Preventing legitimate users from accessing resources

7. Security x High Performance • Difficulty in realizing performance in end-end high bandwidth connections • Difficulty in deploying and using videoconferencing • Difficulty in deploying grids • Limited remote instrument control use • Lack of scalable approaches • Inability to identify what’s broken • Things not broken but just incompatible

8. Environmental Scan:Requirements of R&E • Cyberdiversity of machines and instruments on net • Mobility requirements of machines • Mobility requirements of users • Highly distributed network management • Distinctive privacy and security needs as public and academic institutions • Inter-institutional collaborations predominate and create exceptional wide-area needs • Widespread needs and limited resources preclude expensive point solutions • University=federation of hundreds of disparate and autonomous businesses

9. 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

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

11. General Findings • First, and foremost, this is getting a lot harder • 2003 seems to mark 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

12. 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.

13. The Architectural Frameworks • The virtual perimeter: a mix of perimeter defenses, careful subnetting, and desktop firewalls • Open and closed networks • Separation of internal and external servers (e.g. SMTP servers, routers, etc…) • Managed and unmanaged desktops • Client versus client/server desktop orientation • Types of authenticated network access control

14. Local 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 • …

15. Case Studies/Examples • Generic Academic Case • Novel Academic Alternative • LBL and Bro • Lightly Authenticated Wireless Network • Denial of Service Protection • Network Auditing at CMU

16. Case Study Structure • Background and Intro • Alternative Approaches and Selected Implementation • Pros and Cons • Specifics on attack vectors • Ramifications on advanced computing • etc

17. 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

18. 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

19. 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

20. 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)

21. 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

22. 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

23. 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.)

24. 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

25. 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

26. 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

27. 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