Assurance

["Roy, Nicholas S" <>]

“Perhaps another view on this question is, has anyone put together an overview of what the liabilities are of claiming compliance and then having a breach that was due to lack of sufficient IdP practices (as compared to user misconduct)?”

 

A good question, and it would be interesting to see a risk matrix from this kind of assessment.  My follow-up question is:  “Has anyone seen a high liability problem resulting from poor IAM practices happen on your campus recently?” (you don’t have to answer, it’s a rhetorical question.  My guess is that it’s a pretty rare occurrence these days, among the group of people reading this list.)

 

My take on the subject registration requirements are that if the process is broken up into multiple steps (e.g. you have one office vet the person’s identity and then another office issues their credentials, or they are issued their password via a different channel) then you have to tie the steps together with some kind of token that meets the rest of the requirements for that level of assurance (encryption at rest, on the wire, secure channel for the sessions, etc.)

 

Any type of registration process that you can reasonably say meets the requirements of the Silver IAP is good enough, as long as your auditor agrees, it seems.

 

Nick

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Monday, March 19, 2012 1:31 PM
To:
Subject: [Assurance] Silver assurance and process compliance

 

This is a question that I ask on various lists periodically, but as we're beginning to come out with "cookbooks" for the technical implementatoins, I'm wondering if we can perhaps get some more detailed insight from "ahead of the curve" campuses.

 

Do we have any formal advice as to what level of rigor is required to meet the process-based elements of assurance? By process-based, I mean those that aren't (inherently) technology driven, such as processes for delivery of passwords to individuals, phone or email based help desk password resets or defining assurance for pre-existing hires. The typical answer I get to this question is "it's a risk assessment that should be worked out with your auditor", but I'm still looking for some objective measure to base those assessments on.

 

For example, assuming a strong identity vetting process is completed for all new employees (e.g., I-9 processing in the US), which of these methods for actually delivering credentials to our new employees provide acceptable ("recommended"? "advisable"?) levels of rigor for meeting the NIST LoA2 requirements:

1. The help desk calls the campus department's main number and asks for the individual; once connected they deliver the initial account password
2. An envelope is sent to the employee's new department (marked "confidential") containing the initial account password
3. An initial password is sent via USMail to the home address of the new employee or via email to the individual's listed "personal email address"
4. After hire, the new employee independently authenticates to the account system by providing name, last 4 ssn and DoB (gathered from the HR system) to allow them to set their account password
5. We generate an initial password in the HR systems which is communicated to the employee at hire time and separately sent to the account system for password seeding.
6. After hire, the employee visits a designated office (e.g., Help Desk) where staff reviews a picture ID against HR data and authenticates the employee's account activation. 
7. During the I9 verification, HR staff have the employee set their initial password in the account system directly (assume the HR staff authenticates to validate the process)

I can make arguments in support of each of these methods, and even though some are clearly (or arguably) better than others, I imagine I could convince some auditors or executives of any of them depending on how they interpret the actual risk involved. I naturally lean towards the more rigorous methods, but to argue for money to be spent to meet a specific target, I'd like to have a sense of how each "reasonably" meets the LoA2 requirements. 

 

Perhaps another view on this question is, has anyone put together an overview of what the liabilities are of claiming compliance and then having a breach that was due to lack of sufficient IdP practices (as compared to user misconduct)? 

 

Thanks in advance,

 

--- Eric

 

Eric Goodman

UC Santa Cruz