Identity Assurance at The University of Chicago

1. Identity Assuranceat The University of Chicago Going for the Silver Winter 2010 CSG January 13, 2010

2. What is it? When The University (Identity Provider) … asserts to a third party (Relying Party) … that you (subject) are who we say you are, … then that third party can trust that we have appropriate policies and practices in place (Identity Verification Process or Proofing) … to insure that we knew with reasonable certainty who you were when your identity was created (Registration) and … we subsequently issued you credentials (Credential Issuance). Further, that we have sufficient policies, practices, and technologies in place that the relying party can be reasonably sure that the credentials have not been compromised.

3. Why? • For certain interactions with relying parties, we will have to be able to make assurances regarding identities in order for the relying party to allow our community to access the services their requesting. • Specific use cases: • NIH CTSA (Clinical and Translational Science Awards) • Teragrid and International Grid Trust Federation • National Student Clearinghouse • NSF Fastlane • Possible CIC private cloud services

4. What have we been doing? • Started a gap analysis toward the end of 2008 when InCommon guidelines were still in draft form • Discovered that we had many gaps of various sizes • Some technical • Some policy • Some process • Some not trivial • Decided that we should work toward an immediate goal of Bronze certification with a longer term goal of Silver • Put together a remediation plan over the summer of 2009 • In the mean time …

5. In the mean time … • Had the first contract appear that specified Bronze and Silver level assurances for different classes of access (National Student Clearinghouse) • We decided that there was little value in achieving compliance with the Bronze level profile • Tom came to this conclusion through his various peer interactions • Primary reason being judgment that not many (if any) high value government interactions will be at the Bronze level • Now we’re focused on being able to make Silver level assurances • CIC CIOs agreed that all CIC schools will be able to make Silver level assertions by Fall of 2011

6. The CIC and InCommon Silver • CIC CIOs decided in August 2009 that all CIC schools should be Silver certified by Fall 2011 • Why? • Sustain adoption of fundamentally sound campus business practices and technologies in Identity Management • Expand inter-institutional collaboration • Support emergent trends, relationships, needs on the national identity scene and elevate prominence of CIC in those dimensions • Project leads: Renee Shuey & Tom Barton

7. High level CIC Project Phases

8. Dissecting the problem • Category “A” Activities • InCommon specifications 4.2.1, 4.2.6, and 4.2.8 • Centered on documentation of policy, standards, and management of the operating infrastructure (SOP) • Category “B” Activities • InCommon specifications 4.2.3, 4.2.5, and 4.2.7 • Technical implementation issues regarding strength of authentication and shared secrets • Category “C” Activities • InCommon specifications 4.2.2 and 4.2.4 • Proofing, registration, and credential issuance and management processes

9. Whoneeds Silver assurance? CIC CourseShare Payroll later CIC storage cloud Benefits Student Loans Timeframe OSG CILogon sooner NSC Nat’l Labs NIH apps TeraGrid caBIG smaller larger User group size

10. What it will take us to do Silver • Documentation, documentation, and more doc • Review and strengthen the linkages between registration, proofing, and credential issuance • Create records management practices for registration, proofing, and credential issuance processes • Cleanup legacy problems (e.g. no account lockout and non-expiring passwords) • Possibly create a new credential (re)issuance process for people needing Silver • Create a risk management plan and documentation • Document operational management practices, e.g. change management, logging, administrative access controls, etc.

11. What else? • Have an internal audit to insure that our IdM policies and practices are consistent with all other institutional policies and practices for a service of this type • Address audit points • Have an audit specifically for Identity Assurance Profile compliance • Address audit points • Pop a cork • Rinse and repeat every two years

12. Lightweight Project Planning • Constraints • MS Project not ubiquitous • No Sharepoint service in place even if it were • Various OSS and Freeware project management tools were examined and rejected as too immature • Requirements • Has to be easily shareable to support collaboration, therefore low security bar • Shouldn’t require training • Should serve as an anchor to project collateral • Solution - Google Docs Spreadsheet

13. Observations of a reformed auditor • The InCommon “Assurance Profile Assessment Checklist” • Good starting point • Doesn’t express the requirements in terms of audit controls • What to expect to receive from an auditor • Qualified or unqualified opinion, hopefully without explanation, disclaimer or adverse opinion • Statement of Attestation or Attestation of Compliance • A type II external attestation puts the auditor’s name on a statement that the controls are operating effectively. • What will InCommon or relying parties require? • InCommon says that they want a letter from an independent auditor. Does InCommonneeds to better define the controls to be tested? • Is this an internal assurance argument? If so, then we need to define the controls (TBD). • What will be an acceptable number of exceptions and are there guidelines for compensating controls? • Compliance, an all or nothing state? • From the auditor’s POV, either you’re meeting the requirements or are not • Business judgment enters in. Need to understand the full cost, including damage to reputation • How do you put lightweight controls in place to meet the objectives? How do you have rigor without going overboard?