Seminar Overview

2. Seminar 1A Improving Security with Identity Management: Whoa Nelly!Mark S. BruhnIndiana UniversityMichael R. GettesDuke UniversityA seminar sponsored by EDUCAUSEEDUCAUSE Security Professionals ConferenceApril 10, 2006Denver, Colorado

3. Seminar Overview • Michael will talk about what Identity Management (IdM) is. • Mark will talk about why he thinks IdM is important to security, and throw in some policy issues. • You will discuss and share your thoughts and experiences.

4. Introductions Who are you, and what are you here?

5. So, what is Identity Management, practically-speaking?

6. “IAM” is… • “Hi! I’m Lisa.” (Identity) • “…and here’s my NetID / password to prove it.” (Authentication) • “I want to do some E-Reserves reading.” (Authorization : Allowing Lisa to use the services for which she’s authorized) • “And I want to change my grade in last semester’s Physics course.” (Authorization : Preventing her from doing things she’s not supposed to do)

7. What questions are common to these scenarios? • Are the people using these services who they claim to be? • Are they a member of our campus community? • Have they been given permission? • Is their privacy being protected? • Policy/process issues lurk nearby

8. Vision of a better way to do IAM IAM as a middleware layer at the service of any number of applications Requires an expanded set of basic functions

9. Identity Mgmt System Systems of Record Stdnt Registry LDAP Reflect HR Join Other Credential Basic IAM functions

10. Role- and Privilege-based AuthZ • Privileges are what you can do • Roles are who you are, can be used for policy-based privileges • Both are viable, complementary for authorization

11. Privilege Management Feature Summary

12. Identity Mgmt System Systems of Record AuthN Reflect Join Credential Mng. Affil. Mng. Priv. Basic IAM functions mapped to theNMI / MACE components

13. Apps / Resources Identity Mgmt System AuthN Systems of Record AuthN Log Reflect Provision Join Credential AuthZ Pass Attributes Mng. Affil. Mng. Priv. Log The Environment

14. How full IdM layer helps • Improves scalability: IdM process automation • Improves agility: Keeping up with demands • Reduces complexity of IT ecosystem • Complexity as friction (wasted resources) • Improved user experience • Functional specialization: App developer can concentrate on app-specific functionality

15. The Environment Apps / Resources Identity Mgmt System AuthN Systems of Record AuthN Log Reflect Provision Join Credential AuthZ Pass Attributes Mng. Affil. Mng. Priv. Log Grouper Signet Shibboleth

16. Grouper • Grouper project of Internet2 MACE • Infrastructure at University of Chicago • User interface at Bristol University in UK • $upport from NSF Middleware Initiative (NMI) • http://middleware.internet2.edu/dir/groups

17. Signet • Project Signet of Internet2 MACE • Development based at Stanford • $upport from NSF Middleware Initiative • http://middleware.internet2.edu/signet

18. IAM functions

19. Terminology • CSP - Credential Service Provider - A trusted entity issuing electronic credentials to subscribers (aka Identity Provider) • RA - Registration Authority - Vouches for the identity of a subscriber to a CSP • Identity Proofing - Process by which CSP and RA uniquely identify a person/entity • RP - Relying Party - an entity relying upon the credentials issued by a CSP (aka Service Provider) • LoA - Level of Assurance - Classification of ID proofing suitable for electronic use to control access to information

20. What is a Federation? A collection of organizations, having implemented some form of Identity Management, where Credential Service Providers (CSP, Universities) and Service Providers (SP, Content Providers) agree to “rules of engagement” (policy and attributes) using federating software (Shibboleth, SAML, PKI)

21. What is a Federation? Continued • Sounds simple? It can be. It can be made really complex, really fast. • www.nmi-edit.org for more info • CSPs and SPs retain control over their environments (identity data and access ctrl) • www.InCommonFederation.org • Approx 25 participants, Launched 4/2005 • Inqueue.internet2.edu • Testing/Playground for InCommon • >140 participants and growing

22. Shibboleth and Federation • It’s real, uses SAML • Open source, freely available • Takes between 3 hours and 3 years to install -- depending on IdM infra • In production at various schools (Duke!) • For internal apps & external Univ vendors • shibboleth.internet2.edu

23. Inter-institutional integration • Virtual Organization (VOs) • GridShib development to enhance VOs working with Institutional Identity Mgmt Systems • Federations • Federal E-Authentication Initiative • League of Federations • The Interfederation Interoperability Working Group (IIWG). yes, it’s real

24. One key resource to help you start building the IdM infrastructure • Enterprise Directory Implementation Roadmap http://www.nmi-edit.org/roadmap/ directories.html • Parallel project planning paths: • Technology/Architecture • Policy/Management

25. The Environment Apps / Resources Identity Mgmt System AuthN Systems of Record AuthN Log Reflect Provision Join Credential AuthZ Pass Attributes Mng. Affil. Mng. Priv. Log Grouper Signet Shibboleth

27. BREAK!

28. Identity Management… Why? For whom? And, what troubles will you have?

29. Scope of “Identity Management” • Identification, authentication, authorization services • Directory services • Extract/load processes • Potential Out-feeds • Maintenance services (support and self-service) • Application interfaces • Logs • Inter-institution sharing • Other stuff…

30. Identity  Authentication  Authority • Identity represents an entity • Authentication proves that the entity presenting the identity is the entity to whom/which that identity was assigned (with some caveats…) • Authority is associated with the identity, post-authentication • Accountability maintained across these domains means that the authority can’t be/isn’t hijacked

31. Business Goals of IdM • Identity can be used to • Protect the interests and rights of the organization • Satisfy the obligations of the organization • Protect the interests of the individual • Security can exist without privacy; privacy cannot exist without security

32. So, why are you doing IdM? • Because you have to… …implement a directory? …identify users? ...authenticate users? …authorize users? …track users? …track usage? • No…these are not reasons!

33. IdM based on policies Implementation of IdM must be as a reaction to organizational philosophies and attitudes (which should be represented by policies) Or at least as a result of stated business and functional needs (which should be represented by requirements documents) • Nothing in IdM should be done without fully understanding the business requirements; it can get complicated, and sensitive information is involved – risks may not be worth exposing data and systems

34. Why then? • Having said that…there are pressures that institutions SHOULD be feeling: • Obligations to revenue sources • Legal requirements • Ethical considerations • “Prudent stewardship” • Deter/prevent nefarious deeds • Support/security issues in maintaining disparate services • Systems interoperability • Depending on local decisions in response to these, and (hopefully) resulting policy statements, you will implement IdM and supporting infrastructure

35. Who wants to see IdM? • For a variety of reasons: • Functional managers and staff as users of various applications • Student affairs • Medical centers, clinics, health centers • Distance Ed/Outreach • Counsel • Auditors • Judicial authorities • Law enforcement • Prosecutors • Others

36. In the end, who decides what is implemented? • Technicians hear the requirements, and present potential solutions to • Data stewards • Counsel • Functional managers • Administration • Then, audit might weigh in up front, or later • Organization culture and philosophies • Intellectual property policies/interests • Local access policy (classifications, role assignments, need-to-know)

37. So, since you really do have to do IdM…some issues • Planning -- presentation • Creating a single name space • Building a directory – getting the data • Determining access eligibilities • Delivering credentials • Authentication strategies • Where • How • Strength • Static passwords, expiry, password generators, pass- phrases, symmetric keys, digitized signatures, biometrics • Look across your entire scheme, determining where there are weak points where accountability may be lessened to an unacceptable level

38. And some more issues… • Applying authorization rules • Privacy implications with collecting, storing, validating, and passing personal attributes • Ensuring controls appropriate to applicable legal protections (need-to-know, suppression, etc.) • Privacy – voluntary and required suppression • Secondary markets for directory data • Risks inherent in “security domains” • Logging strategy

39. Getting the data • Feeds from • Central student system • Central HR system • Central faculty records • Affiliated “permanent” organizations • Departments that do not participate in central systems • Onesey-Twosey entry form (affiliates form) • Entry done by the sponsoring department • Custodians of the data – primarily central IT

40. Who worries about implications of IdM? • Counsel • Libraries • Faculty • Privacy advocates • Informed end users

41. Why are they (should they be) concerned? • Privacy • Tracking • Tracing • Logging • Storing • Inconsistent application of policies (e.g., suppression; but don’t we already have this problem?) • Stifling free exchange of ideas • Freedom of speech • Freedom of association • Unlawful search and seizure… • Stalking • “I don’t want anyone to see my information in an online address book.” • “You mean you can tell what web pages I visited last night?” • “You mean you can tell who I’ve been communicating with via email?”

42. So, finally: relationship between IdM and security • Pressures may not be related to IdM per se, but to interest in improving security, which relies heavily on well-managed IdM processes: • E.g., if it’s easy to gain unauthorized access to sensitive data via shortcomings in the implementation of IdM, technically securing the host computer is for naught

43. Security and Privacy: CIA • Essentially, these are basic security goals: Confidentiality Integrity Availability

44. Defining Confidentiality • Ensuring that data is not disclosed to unauthorized viewers • Protection against disclosure is required by • Law • Organizational policy • Prudent stewardship

45. Confidentiality: Some Laws • 4th Amendment • FERPA • HIPAA • GLBA • ECPA • Federal Wiretap Law • Open Records Laws

46. 4th Amendment • Applies to public/government entities • Prohibits unreasonable searches and seizures • Based on “reasonable expectation of privacy” • Organizational policy defines reasonable expectation of privacy • User accounts versus department folders; user accounts versus scratch space • Physical or logical IdM mechanisms may be deployed to facilitate 4th Amendment protections

47. FERPA • Limits disclosure of student educational records to • Individuals with “Legitimate Educational Interest” • Third parties with student’s prior written consent • Third parties in response to federal grand jury subpoena, and any other valid subpoena or judicial order • Appropriate persons where necessary to protect health and safety • Prior notice to student required except as otherwise expressly prohibited in law • Generally records of each request and disclosure of data must be kept • While there aren’t civil or criminal penalties for FERPA violations, they may result in loss of Federal monies • Clearly, IdM mechanisms are required to ensure compliance

48. HIPAA • Governs use and disclosure of “protected health information” by “covered entities” • PHI is defined as “individually identifiable information regarding health care or payment (other than student health data) that is transmitted or maintained in electronic or other media” • Covered entities include: health plan/benefits, units who provide health care services and engage in electronic transactions involving PHI

49. HIPAA (con’t) • Privacy Rule: Effective April 1, 2003 • Need to identify who within system handles PHI or may be “business associate” of third parties handling PHI • Need to draft accurate notice to patients about uses of PHI • Security Rule: Effective April 21, 2005 • Requires rigorous access controls to limit internal and external access to health care data • Physical and electronic controls, oversight, education • Requires significant and ongoing communication and partnering among IT, legal, relevant personnel within affected units • As opposed to FERPA, there are civil and criminal penalties violations of HIPAA • Clearly, IdM mechanisms are required to ensure compliance

50. Federal Wiretap Law • Generally prohibits intentional interception, use, or disclosure of wire and electronic communications • Allows senior DOJ officials to apply for court order authorizing capture of real-time wire, oral, or electronic communications relating to federal felonies • (There are some exceptions) • (Question: are we providing service “to the public”?) • Service providers can authorize law enforcement to intercept communications of trespassers on our “protected computers” (used in interstate commerce) • IdM will help us distinguish between authorized users and trespassers