Assurance

[David Walker <>]

Since I did much of the work on that risk assessment ( https://spaces.internet2.edu/x/OIjNAQ ), I thought I'd make a few observations:

• The applications provided by InCommon for entity administration are different from most RPs, as they can affect the metadata that underlies technical enforcement of the federation's trust relationships.  This made it difficult to apply the controls in existing Bronze and Silver profiles directly.  (Also, of course, the current number of Bronze/Silver certified IdPs argues for an alternative approach.  Personally, I usually am the person arguing to use existing assurance profiles whenever possible, rather than customizing for each RP.  In this case, though, I think doing so is not practical.)
• The determination of assurance requirements for federation administration applications is a new thing. The risk assessment was an attempt to ensure that we were considering the issues raised by OMB M-04-04, recognizing that we may not be able to apply the controls in 800-63 directly.  As we gain more experience, we will likely want to revisit this and other issues from time to time.
• Regarding specifics of identity proofing, I think there's been some confusion in the thread between 1) whether it needs to be done and 2) who does it.  It definitely needs to be done (and it is done), but responsibility for doing it is shared between InCommon's administration and the member institutions.
• Regarding the classification of a "moderate" impact level for the Federation Manager, the risk assessment describes how that was reached.  As mentioned there, NIST SP 800-30 defines medium (moderate) impact as, "Exercise of the vulnerability (1) may result in the costly loss of tangible assets or resources; (2) may violate, harm, or impede an organization’s mission, reputation, or interest; or (3) may result in human injury."  I will observe, however, that that classification is based on the fact that the currently-defined profiles are Bronze and Silver.  If/when InCommon defines higher-level assurance profiles in the future, then the impact may need to be reclassified.
• Thanks, Mark, for keeping the non-technical aspects of assurance front and center.  It's nice to see someone else saying what I would otherwise spend time typing myself.

Great discussion.

David Walker

On Fri, 2012-11-30 at 20:41 +0000, Cantor, Scott wrote:
> On 11/30/12 3:18 PM, "Jones, Mark B" <> wrote:
>
> >Ok... so if InCommon bears no risk why bother with a risk assessment?
> >And how did the result come out to be 'moderate'?
>
> There's legal risk and there's reputational risk.
>
>
> I believe the assessment was done with respect to the question of whether
> to strengthen the authentication process for the directly issued accounts,
> but with an eye on how it would impact the plan for doing delegated access
> by federated accounts, but Tom is better able to answer that.
>
> >If there are two sets of accounts, which set have we been talking about?
>
> I think the directly issued ones primarily.
>
> >I agree that passwords are hopeless.  But if you don't care who is
> >authenticating then why care if they are using passwords?
>
> Because I might care that the ability to authenticate as a given
> *identifier* is suitably protected. The binding back to a physical person
> might be irrelevant *to the RP*. It is very relevant to the organization
> that provisioned the identifier, but the RP needs no explicit statement to
> that effect that such a binding was done in any particular way.
>
> To be honest, I think it's 800-63's desire to tie these concepts together
> that is flawed. You may find it inutitive and obvious, but I find it very
> clumsy and ineffective.
>
> -- Scott