Middleware and Security Update

1
Middleware and Security Update
2
Since we last talked

• Middleware
• Unified field theory of trust
• Shibboleth and InCommon
• Signet an authority system
• Diagnostics
• Corporate dimensions
• Tech transfer
• Trust relationships
• Government interactions
• Security
• Strategic emphasis for Internet2, within the
  context of STF
• Formation of Salsa and its working groups
• Federated Security Services
• Corporate dimensions
• RD in federated services
• Is there a business model?

3
Unified field theory of Trust

• Bridged, global hierarchies of identification-orie
  nted, often government based trust laws,
  identity tokens, etc.
• Passports, drivers licenses
• Future is typically PKI oriented
• Federated enterprise-based leverages ones
  security domain often role-based
• Enterprise does authentication and attributes
• Federations of enterprises exchange assertions
  (identity and attributes
• Peer to peer trust ad hoc, small locus personal
  trust
• A large part of our non-networked lives
• New technology approaches to bring this into the
  electronic world.
• Distinguishing P2P apps arch from P2P trust
• Virtual organizations cross-stitch across one of
  the above

4
Shibboleth Status

• Open source, privacy preserving federating
  software, developed by an I2 wg and implemented
  by I2 universities
• Being very widely deployed in US and
  international universities
• Work underway on intuitive graphical interfaces
  for the powerful underlying Attribute Authority
  and resource protection
• Likely to coexist well with Liberty Alliance and
  may work within the WS framework from Microsoft.
• Growing use and development interest in several
  countries, providing collaboration tools
• V1.0 released april 03 v1.2 release next week
  v2.0 likely top of the line
• http//shibboleth.internet2.edu/

5
Federations

• Associations of enterprises that come together to
  exchange information about their users and
  resources in order to enable collaborations and
  transactions
• Enroll and authenticate and attribute locally,
  act federally.
• Uses federating software (e.g. Liberty Alliance,
  Shibboleth, WS-) common attributes (e.g.
  eduPerson), and a security and privacy set of
  understandings
• Enterprises (and users) retain control over what
  attributes are released to a resource the
  resources retain control (though they may
  delegate) over the authorization decision.
• Several federations now in construction or
  deployment

6
InCommon federation

• Federation operations Internet2
• Federating software Shibboleth 1.1 and above
• Federation data schema - eduPerson200210 or later
  and eduOrg200210 or later
• Becomes operational April 5, with several early
  entrants to help shape the policy issues.
• Precursor federation, InQueue, has been in
  operation for about six months and will feed into
  InCommon
• http//incommon.internet2.edu

7
InQueue Origins2.12.04

• National Research Council of Canada
• Columbia University
• University of Virginia
• University of California, San Diego
• Brown University
• University of Minnesota
• Penn State University
• Cal Poly Pomona
• London School of Economics
• University of North Carolina at Chapel Hill
• University of Colorado at Boulder
• UT Arlington
• UTHSC-Houston
• University of Michigan
• University of Rochester
• University of Southern California

• Rutgers University
• University of Wisconsin
• New York University
• Georgia State University
• University of Washington
• University of California Shibboleth Pilot
• University at Buffalo
• Dartmouth College
• Michigan State University
• Georgetown
• Duke
• The Ohio State University
• UCLA
• Internet2
• Carnegie Mellon University

8
InCommon Management

• Operational services by I2
• Member services
• Backroom (CA, WAYF service, etc.)
• Governance
• Executive Committee - Carrie Regenstein - chair
  (Wisconsin), Jerry Campbell, (USC), Lev Gonick
  (CWRU), Clair Goldsmith (Texas System), Mark
  Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan
  Perry (Mellon), Mike Teetz, (OCLC), David
  Yakimischak (JSTOR).
• Project manager Renee Frost (Internet2)
• Membership open to .edu and affiliated business
  partners (Elsevier, OCLC, Napster, Diebold, etc)
• Contractual and policy issues being defined now
• Likely to take 501(c)3 status

9
The potential for InCommon

• The federation as a networked trust facilitator
• Needs to scale in two fundamental ways
• Policy underpinnings need to move to normative
  levels among the members post and read is a
  starting place
• Inter-federation issues need to be engineered we
  are trying to align structurally with emerging
  federal recommendations
• Needs to link with PKI and with federal and
  international activities
• If it does scale and grow, it could become a most
  significant component of cyberinfrastructure

10
Beyond web services

• Federated security services
• Collaborative incident correlation and analysis
• Trust-mediated transparency and other
  security-aware capabilities
• Federated extensions to other architectures
• Lionshare project for P2P file sharing
• IM
• Federated Grids

11
P2P arch over federated trust -Lionshare

• P2P file sharing application that is
• Enterprise-based uses authentication and campus
  directory and resource discovery
• Federated works between institutions, using
  local authentication and authorization
• Learning object oriented meta-data based
  linked to digital repositories, courseware, etc.
• Developed at Penn State University, now being
  extended with assistance from Mellon Foundation,
  Internet2, OKI, Edusource
• URL is http//lionshare.its.psu.edu/main/

12
Virtual organizations

• Need a model to support a wide variety of use
  cases
• Native v.o. infrastructure capabilities,
  differences in enterprise readiness, etc.
• Variations in collaboration modalities
• Requirements of v.o.s for authz, range of
  disciplines, etc
• JISC in the UK has lead solicitation is on the
  streets (see (http//www.jisc.ac.uk/c01_04.html)
  builds on NSF NMI
• Tool set likely to include seamless listproc, web
  sharing, shared calendaring, real-time video,
  privilege management system, etc.

13
Signet - an authority system

• As the number and complexity of applications
  grow, so does the burden of administering
  permissions within them
• A key juncture of end-user, system owner and
  auditor interests a big win if done with
  business process reengineering
• Applicable to enterprise applications as diverse
  as SIS, Financials, Calendaring, Course
  Management, Electronic Key Access, etc.
• Potentially of value to virtual organizations as
  diverse as Grids and museum curator associations.
• Based on pioneering work now in production at
  Stanford, being generalized and upgraded with NSF
  NMI grant funds pilots later this spring

14
Stanford Authz Model
15
Signet Deliverables

• The deliverables consist of
• A recipe, with accompanying case studies, of how
  to take a role-based organization and develop
  apprpriate groups, policies, attributes etc to
  operate an authority service
• Templates and tools for registries and group
  management
• a Web interface and program APIs to provide
  distributed management (to the departments, to
  external programs) of access rights and
  privileges, and
• delivery of authority information through the
  infrastructure as directory data and authority
  events.

16
Home
17
Grant Authority Wizard
18
Diagnostics

• The job no one wants to do, but is critical to
  successful and scalable enterprise and federated
  deployments of almost all technologies.
• Hard to sell until too late, after the pain has
  set in
• There is a need for an integrated approach to
  performance, security and middleware diagnostics.
  
• Internet2 is working hard right now to figure out
  how
• To integrate efforts
• To get traction in areas that are too busy
  inventing to work on diagnostics

19
Steps to Enable Diagnostic Applications

• Establish the common event record
• Enable the collection of events from a wide
  array of event sources
• Network NetFlow, SNMP, RMON, etc
• Security IDS, Snort, firewalls, etc
• Applications Shib, Dir, IM, P2P, smtpd, named,
  httpd, Kerberos, etc
• Hosts /var/log/, Syslog, etc

20
Steps to Enable Diagnostic Applications (2)

• Build tools to create dissemination
  infrastructures that,
• Allows access to the diagnostic data
• Provides operators to filter, anonymize,
  aggregate, tag, store and archive the data
• Enables pipelining of data operators to organize
  and manipulate diagnostic data based on an
  organization or federations policies
• Provide a common API so applications can access
  the diagnostic data

21
Enabling Diagnostic ApplicationsWith a Common
Event Descriptor
Diagnostic applications (Middleware, Network,
Security) can extract event data form multiple
data sets
Dissemination Network
Collection and Normalization of Events
Network Related Events
22
Diagnostic Data Pipelining
Data flows can be constructed to provide the
desired function and policy within a enterprise
or federation
Host or Security Events
C-1
C-2
P-1
P-2
P-4
C-3
Network Events
C-4
P-3
P-5
C- Collection Module Host P- Processing Module
Host
Filter
Archive
DB
Anonimization
Tagging
Aggregation
Normalization
23
Event Record
Event Descriptor Meta Field
Event Descriptor
Raw Event Data

• Version Number
• Observation Description Pointer
• ID unique event identifier
• Time - start/stop
• IP Address(es) source/(destination)
• Source Class application, network, system,
  compound, bulk, management
• Event Name Tag Native language ID, user
  defined
• Status normal, informational, warning,
  measurement, critical, error, etc.
• Major Source Name filename, Netflow, Syslogd,
  SNMP, shell program, etc.
• Minor Source Name logging process name
  (named), SNMP variable name, etc.
• Raw Data Encoding Mechanism Binary, ASN1,
  ASCII, XML, etc.
• Raw Event Data Description Pointer

24
Event Record
Event Descriptor Meta Field
Event Descriptor
Raw Event Data

• Observation Description Pointer
• Address type of observer (IPV4, IPV6, MAC, etc.)
• Address of observer
• Address type of collection agent (IPV4, IPV6,
  MAC, etc.)
• Address of collection agent
• Source Type (file, stream, polled, interrupt)
• Collection agent name (Netflow.1.0, named.2.3,
  etc.)

25
Event Record
Event Descriptor Meta Field
Event Descriptor
Raw Event Data

• Raw Event Data Description Pointer
• Schema of raw event data
• Parsing expression pointer

26
Event Record
Event Descriptor Meta Field
Event Descriptor
Raw Event Data

• Event Name Tag (null), user defined (can be
  multiple tags)
• Examples
• astronomy-app
• ShibUserHandlefoo
• DormTraffic
• Worm-W32B
• AMP
• MS-UPDATE-34333
• IE-Patch-2343

27
Event Record Overhead
Event Descriptor Meta-Field
Event Descriptor
Raw Event Data

• Version Number 1 byte
• Observation Description Pointer 4 bytes
• ID 10 bytes
• Time 24 or 12 bytes
• IP Address(es) (8 or 16 bytes) 2 for IPV6
• Source Class 1 byte
• Event Name Tag 0 to 16 bytes typical (can be
  as large as 256)
• Status 1 byte
• Major Source Name 0 to 32 bytes typical (can
  be as large as 256)
• Minor Source Name 0 to 16 bytes typical (can
  be as large as 256)
• Raw Data Encoding Language - 1 byte
• Raw Event Data Description Pointer 4 Bytes

28
Security Policy Discovery
Probing the Destination
Firewall
Probe

• Pros
• Actively tests a configuration of a device or
  path
• Cons
• Cannot discover past the first device that is
  blocking
• Destination being probed may think it is under
  attack

29
Security Policy Discovery
Publishing Policy

• Pros
• Fast and simple method for discovering policy
• Can look beyond the first blocking device
• Cons
• Policy may not be up-to-date
• Publishing policy may be looked at as an exposure

30
Security Policy Discovery
Using Diagnostic Event Records
Org 1 Records
Org 2 Records

• Pros
• Provides a audit trail of actions
• Enables repudiation by letting two
  organizations,
• share data through a common event record
• can anonomize sensitive data
• Cons
• Organizations must be willing to share data
• Passive auditing enough, active methods can
  augment

31
Example Shib failure

• Get a Shib failure message due to
• Network performance problem
• Firewall settings
• Host down
• Misconfigured Shib installation
• Shire failure
• Where are diagnostics done and remedies applied?

32
MW Corporate Dimensions

• Tech transfer
• Trust business relationships
• Government interactions

33
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
• A thread as much as a workgroup staffing is
  reallocated I2 personnel, corporate fellows, and
  a clone
• Created Salsa as member-driven steering group
• http//security.internet2.edu

34
Salsa Membership

• Mark Poepping - Carnegie Mellon University
  (chair)
• Chris Cramer - Duke UniversityGary Dobbins -
  University of Notre DameTerry Gray - University
  of WashingtonChris Misra - University of
  MassachusettsDoug Pearson - Indiana
  UniversityJim Pepin - University of Southern
  CaliforniaJames Sankar (European liaison) -
  UKERNAJeff Schiller - Massachusetts Institute of
  TechnologyJoe St. Sauver - University of
  OregonSteve Wallace - Indiana University

35
Salsa Work Groups

• Security Architecture Marty Schulman (Juniper),
  Chair
• Establish a common reference model and
  nomenclature
• Frame the tradeoffs
• As part of the early activities, create a body of
  discussion and practice around DNS-based,
  application oriented new networking ideas
• Network Authn/z Chris Misra (UMass), Chair
• First task is to create a set of effective
  practices around campus network registration
• Seond task likely to begin work responsive to the
  visiting scientist problem and the Terena JRA5
  activities

36
Federated Security Services and Capabilities

• A potentially significant addition to our
  security portfolio, but like everything else
  already there, not a magic bullet.
• Couples shared backbones (Abilene, NLR,
  Terragrid, etc.) with a common trust fabric
  (InCommon) leverages Abilene Observatory and
  REN-ISAC
• Two goals
• Collaborative security tools and analyses
• Security aware capabilities that permit science
  and innovation to continue despite security
  barriers
• Developed as a response to an NSF CyberTrust
  solicitation, but ready to be marketed elsewhere
  (DHS, industry)

37
Corporate dimension

• RD possibilities
• Is there a business model (internal or external)
  for federated security services?

38
Internet2 Webinars

39
Internet2 Webinars

• New seminar program
• Designed for corporate member audience
• Low-tech phone, web browser
• Security and Middleware topics
• Pilot series of 3 monthly webinars
• Launch May 19, 2004

40
Internet2 Webinars

• Securing Advanced Corporate Networks
• May 19, 2004 at 200 p.m. EDT
• Eric Metalla, McAfee Research
• New security technologies for advanced networks
• TBA, Ford Motor Company
• Network architectures for advanced security
• Ken Klingenstein, Internet2
• Internet2-led security activities

41
Internet2 Webinars

• Deploying and Supporting Federations-- June
• Privilege Management-- July

42
Internet2 Webinars

• http//webinar.internet2.edu