1 / 27

Security Architectures and Advanced Networks

Ken Klingenstein Day Job: Middleware Night Job: Network Security. Security Architectures and Advanced Networks. Security Topics. Educause/Internet2 Security Task Force Effective Practices I2 Resource Commitments REN-ISAC S@LS workshop

lael
Download Presentation

Security Architectures and Advanced Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related