Assurance

["Jones, Mark B" <>]

For the record I did not add that table to the previous discussion.  I forget who did but that is what reminded me of the section in that doc.

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Monday, March 26, 2012 6:20 PM
To:
Subject: Re: [Assurance] Silver assurance and process compliance

 

Thanks Mark, 

 

And now that I see that, I think you posted a snippet of that in David Bantz' recent thread that was similar (in tone if not in content) to mine. Using that same table from the OMB doc should at least help with baselining the info. 

 

I still would love to see some general guidelines out of InCommon (either the formal project group or us as a general user community) on specific practices, but the doc is probably a better starting point than anything else I've got. 

 

--- Eric 

 

On Fri, Mar 23, 2012 at 1:55 PM, Jones, Mark B <> wrote:

I’m not sure if InCommon has similar documents or not, but considering Silver is intended to satisfy ICAM level 2 I would assume that the formal advice you are looking for can be found in NIST 800-63.

 

As far as risk…  I’m not sure if this was exactly what you are asking about, but OMB M-04-04 has a section that deals with “Assurance Levels and Risk Assessments”.

 

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