Assurance

["RL 'Bob' Morgan" <>]

On Mon, 23 Jan 2012, Eric Goodman wrote:

> We have a vendor who is delivering a Shibbolized application that 
> requires an assurance assertion before users are granted access. The 
> assurance assertion is essentially the same as InCommon Silver 
> assurance. The vendor also requires that we provide an account they can 
> use to perform automated system logins via Shibboleth (to monitor the 
> system). Because their application is configured to require this 
> InCommon Silver(-like) assurance assertion, they want the monitoring 
> account to be flagged with an InCommon Silver(-like) IAQ. 

I think we all know that sometimes partners are unreasonable, and we have 
to pick our battles, and it's all about risk management.

Indeed if the assurance framework is Silver-like then it isn't possible 
for a process to be a Silver-qualified (identity vetting is just for 
people).  If the vendor doesn't care, and you're forced to qualify this 
monitoring account anyway, then you're taking some risks.  One risk is 
that making such an exception would taint your whole IdMS, and you'd lose 
your certification.  This would be between you and your auditor; I would 
hope that auditors would recognize that sometimes exceptions happen. 
Another risk is that this Silver-qualified account might get used at some 
other SP and get access that it shouldn't.  I'd like to think that other 
attributes (like affiliation or entitlement) would prevent that.  Your IdP 
could actively try to prevent this by limiting the SPs this account could 
go to.  I don't think Shib can do this out of the box, though.

Or you could stand firm and tell the vendor you can't Silver-like-qualify 
a process account, so they'll just have to accept, for this monitoring 
account, some other qualifier (or none).  Seems like this should be easy 
for them, but you never know, and it may not be worth fighting.

> It's at about this point that I start thinking: "This can't be a unique
> problem; I wonder what other people do in this kind of situation?" 

To me this falls into the general Testing Catch-22:  testing/monitoring 
needs to test real services of real systems, but from a security point of 
view you want to make sure test processes can't do real things (ie can't 
cause real damage).  It is unfortunate that these testing considerations 
tend to live outside operational frameworks such as assurance, but I think 
that's the state of things given the myriad approaches to testing.

 - RL "Bob"