Tuesday, 21 December 2010

Only as strong as the weakest link in the chain

A security system is only as strong as the weakest link in the chain to paraphrase a well known saying.   There can be lots of links to think about in a federated security system.  How do you ensure a thorough analysis and an acceptable baseline level of security?  The NIST levels of assurance framework provides a valuable metric against which to make an assessment.

One argument that could made for example is that we only need an authentication mechanism at some low level of assurance, say X  (worse still - no analysis is made and there's an implicit assumption!).  You develop your system to meet that requirement and deploy it accordingly but what happens when you find that your system needs to secure slightly more sensitive data?  Your original analysis breaks down and your system is no longer fit for purpose.  With a large federated system, that's potentially a lot of infrastructure to have to tear down and re-implement and deploy.  Wouldn't it have been better to design the system so that the respective links in the chain could support something more secure?  That way you could provide a degree of future proofing.

Clearly there would be some cost benefit analysis to weigh up but maybe many of those chain links could be made more secure to encompass a broader spectrum of use cases.   There's only so far you could take this approach.  An alternative is to pass level of assurance information - SAML supports this concept and this interesting presentation looks at the 'policy impedance' introduced where protocols that would not otherwise by combined together are joined - in this case OpenID and SAML.  

It seems to me though that the value of expressing an assurance level is poorly understood and the case is made, why bother with this when you can express this in your authorisation policy?  - A given user authenticates via an insecure mechanism therefore don't give them access rights to dataset 'A'.  That's not going to help though if your trying to apply an authorisation policy to sensitive data but your system supports an authentication scheme that is only very weakly secured.  It doesn't matter what hoops you have to go through to register for the required authorisation, the authentication link in the chain has made that a pointless exercise.

No comments: