1 / 22

Technical Issues with Establishing Levels of Assurance

Technical Issues with Establishing Levels of Assurance. Zephyr McLaughlin Lead, Security Middleware Computing & Communications University of Washington. Today’s Talk in one Slide. Overview of the University of Washington (UW) Drivers for Levels of Assurance (LoA) Application Perspective

dixie
Download Presentation

Technical Issues with Establishing Levels of Assurance

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. Technical Issues with Establishing Levels of Assurance Zephyr McLaughlin Lead, Security Middleware Computing & Communications University of Washington

  2. Today’s Talk in one Slide • Overview of the University of Washington (UW) • Drivers for Levels of Assurance (LoA) • Application Perspective • User Perspective • Exploring the Solution Space

  3. UW’s Environment • Central IT makes up about 1/4 of the IT staff • Central IT has very little control over what departmental applications do • Many diverse populations: • 80,000 + Faculty, Staff and Students (18,000 Med Ctr Employees) • 500,000 + Alumni and Affiliates • 1,000,000 + Patients • Other diverse populations (Cascadia Community College, WA State K-12 students, Library Patrons, etc.)

  4. UW’s Enterprise Credential (UW NetID) • A large amount of effort has gone into making the UW NetID UW’s single enterprise credential. • More than 360,000 active UW NetIDs • 300,000+ more potential users (1,300,000 + if we include patients) • Our credentials are stored in both Kerberos and Windows AD • We have 5 different UW NetID Types (not to be confused with LoAs!)

  5. What LoAs does the UW NetID Support? One size fits all… well almost! • ~ 7,400 people have 2-factor authn (SecurID) • We support a group of EAuth level 1 credentials (very small test group)

  6. A Tale of Two Populations • Two populations one old one new • 200K + K-12 Students and Educators (WA State Digital Learning Commons) • 18K + UW Medicine Employees • Some Commonalities • Both need to authn • Both are critical to UW’s mission • Some Directly Competing Requirements • Stronger password requirements vs. weaker password requirements

  7. A Tale of Two Populations (cont) Discussion starters: How do we support both populations and uses with the same credential? What are the advantages and disadvantages to using the same credential vs separate credentials?

  8. Drivers for LoA • Compliance Perspective - Supporting federal, state and university policy requirements • Access Perspective – Providing support for our diverse populations COMPLIANCE ACCESS

  9. Compliance Drivers for LoA • Regulatory – Government requirements • HIPAA • FERPA • WA State ISB Standards • WA State Security Breach Notification Law (6043) – 37 other states now have something like this • Contractual – Liability protection issues • Payment Card Industries/ Data Security Standards (PCI/DSS) • Professional and International Standards – Represent due care • E-Authentication • ISO, NIST, COBIT etc. • University Policy

  10. Compliance Requirements for LoA • Password Requirements • Expiration (120 days? 90 days? 30 days?) • Lockout (3 attempts? 100K attempts?) • Strength checking (minimum char length, dictionary checking, known info checking, etc) • Protections ( Encrypted Authn, Strong Password Management ) • Authn Requirements (Multi-factor) • Logging/ Audit Requirements • Identity Proofing Requirements

  11. Access Drivers for LoA • A subset of applications require a higher assurance level that’s costly to provide • A subset of apps require low bar for entrance • Globally distributed users create ID proofing challenges • Provide service to individuals with little or no known personal data • Password restrictions can be potentially unfriendly to certain classes of users

  12. Access Requirements for LoA • Support requirements of each individual application (Wireless network access vs. access to PHI) • Support many different types and levels of identity proofing • Allow users to access to certain applications when less ID proofing has been done • Allow different password requirements based on what the user needs access to.

  13. The Application Perspective • How can existing apps be converted to use LoA? • Why don’t you have population X in your system? • Aren’t all your credentials people? • Aren’t all your credentials highly secure? • Why can’t you make it easier for people to get IDs?

  14. The User Perspective • It’s hard to choose a usable password! • Why do I have to keep changing my password? • Why do I have to give my personal information? • What do you mean I have to come show my picture id? • What do I need to do to access application ____?

  15. Exploring the Solution Space • A well defined set of assurance levels • A collection of NetID and Authn characteristics are used to determine LoA • An application that allows users to view their current LoA • Clearly defined standards for what LoA each app type requires • Support for LoA in authn services (Web Signon, Kerberos, Windows AD)

  16. Characteristics that Defines LoA • NetID Characteristics • Type of Identity Proofing • # of failed authns • Password age • Is Compromised? • Shared, recycled or system credentials? • Authn Time Characteristics • Type of authn (single factor password authn? 2 factor? ) • Time of authn

  17. Types of Identity Proofing • High Assurance ID Proofing • Photo ID in person • Notarized Photo ID via mail/ fax • Phone verified ( 5 or more pieces of info ) • One-time password by mail • Low Assurance • Phone verified ( 2 pieces of info minimum ) • Email verified • Verified by trusted member

  18. How are LoAs Assigned? • A collection of characteristics that define level of assurance • As characteristics change, LoA may increase or decrease • The assurance level may change when ID proofing is done accompanied by a password creation/ change • The assurance level may be downgraded after a maximum password age or maximum number of failed attempts has been reached • Depending on the characteristics of authn, LoA may change • An additional factor or different mechanism

  19. UW NetID Levels of Assurance (Conceptual) NOTE: This does not reflect the current state of the UW NetID. The UW does not yet have plans to implement this or any other LoA scheme. • Level A – High assurance Personal IDs that authn with 2nd factor (securid for now). Compliant with EAuth Level 3 • Level B – Higher assurance Personal IDs… compliant with EAuth Level 2 • Level C – Lower assurance but meeting EAuth Level 1 standards • Level D – Low assurance personal UW NetIDs that have minimal id proofing • Level E – Shared and temporary IDs that have little or no assurance • Level F – Compromised IDs and other IDs that are not allowed to authn

  20. Credential LoAs are Just the Beginning… • How do we assert the level of assurance we have that any attribute associated with the id really belongs to the specific person authenticating? • How do we address back door system accounts? • How is the user assured that the app they are assigning on is really what it says it is?

  21. More Questions, Comments, Feedback? Directory Support directory-support@washington.edu Zephyr McLaughlin zephyrmc@washington.edu IDM Discussion List idm@listserv.educause.edu

  22. UW NetID Types • Personal UW NetID – A UW affiliated individual’s key to online resources at the UW and beyond • Shared UW NetID – Used to share centrally maintained UW computing services such as departmental websites • Temporary UW NetID – Used to provide temporary access to services via the UW NetID system • Applications UW NetID – Applications/ services that need to authn and can’t use x509 certs • Reserved UW NetID – UW NetIDs that can’t authn (eg. root, mailing lists, etc)

More Related