Learning Center
Plans & pricing Sign in
Sign Out



									Security Architectures
and Advanced Networks

        Ken Klingenstein
               Day Job: Middleware
               Night Job: Network Security
          Security Topics
 Educause/Internet2 Security Task Force
   • Effective Practices
   • I2 Resource Commitments
 S@LS workshop
 SALSA – a steering group for advanced
  network/security technologies
 Federated security services
   • Collaborative incident analysis
   • New security-aware capabilities
 Going forward

                                           CHANGE DATE   2
   EDUCAUSE/Internet2 Security Task Force

 Overarching umbrella for a variety of coordinated
 Activities include education and awareness, policy,
  technologies, etc.
 Two important recent activities
   • Effective Practices -
   • NSF Security at Line Speed Workshop

                                                  CHANGE DATE   3
              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
 Extensive on-line follow-up discussion to refine and
 White paper is at

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

                                                 CHANGE DATE   5
          S@LS Security topics
 Information leakage: access to data by unauthorized
 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

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

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

                                                                 CHANGE DATE   8
 Host versus border security
 Deny/Allow versus Allow/deny approaches
 Unauthenticated versus authenticated network
 Central versus end-user management
 Server-centric versus client-centric
 False positives versus zero-day attacks
 Organizational priorities between security and
 Perimeter protection versus user/staff confusion

                                                   CHANGE DATE   9
 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

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

                                                        CHANGE DATE   11
             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,
 Host Tools include host-based encryption, local
  firewalls, host-based intrusion detection/prevention,
  secure OS, automated patching systems, etc.

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

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

                                             CHANGE DATE   14
         Case Studies/Examples
 Generic Academic Case
 Novel Academic Alternative
 LBL and Bro
 Lightly Authenticated Wireless Network
 Denial of Service Protection
 Network Auditing at CMU

                                           CHANGE DATE   15
          Case Study Structure
 Background and Intro
 Alternative Approaches and Selected Implementation
 Pros and Cons
   • Specifics on attack vectors
   • Ramifications on advanced computing
   • etc

                                             CHANGE DATE   16
                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
   • Intended to complement other activities in the Internet2/EDUCAUSE
     Security Task Force

                                                                 CHANGE DATE   17
 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

                                                  CHANGE DATE   18
          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
 Increase data collection, sharing and integration
  between security researchers and backbone activities
 Net Authentication/Authorization
 Federated Security Services and Capabilities

                                                   CHANGE DATE   19
                  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
                                                    CHANGE DATE   20
                   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

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

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

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

                                                            CHANGE DATE   24
           Federated Security-aware
Federated user network authentication for on-the-road science
Control spam through federated verification of sending
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

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

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

                                                            CHANGE DATE   27

To top