One of the complicating factors in AppSec these days is access control in distributed systems. Dividing up the roles and responsibilities for authN, authZ, attribution and identity management is a daunting task.A typical enterprise is used to putting a ring fence around its assets and managing everything within the fence with RACF/TopSecret, AD, and other technologies. But this is insufficient by themselves for today's integrated applications.
Identity has made a tremendous amount of progress in the last ten years, standards like SAML and OAuth give enterprises a way to make concrete progress on building defensible identity and access control systems for integrated applications like Cloud apps and services. But still we see mucho breaches in 2011. Chris Wysopal found the majority of big breaches to be AppSec related; while malicious code certainly looks to responsible for some of them others look like access control fails. We don't know the internal architectures of each of the big breach victims, but its not surprising to see authorization on the list.
The authorization logic is almost always bound up with the code which makes it hard to audit and hard to test. Externalizing authorization to Roles is a nice start but again insufficient for most systems. Attributes change program structure and behavior. This reality must be accounted for somehow, one approach is to externalize via ABAC a la XACML, but many enterprises are just in early stages here. Until then we can and should expect more authorization related breaches due to emergent behavior from unpredictable (and unmanaged authorization systems).
An additional complicating factor for enterprises is the mix of Push/Pull, Bob Blakley addressed the long term view of this so well. Bob also addressed a pragmatic, incremental way to move from Push to Pull via Virtual Directories. This is an important and as I mentioned I think practical, improvement over how enterprises operate authorization today, however there are code level issues that enterprises will live with unless and until they move to a pure Pull architecture.
Some of the struggles that i have observed are as follows:
- Unclear on granular roles in authorization framework - identity provider responsibility (who asserts) vs service provider (who decides) responsibilities
- Authoritative source of attributes
- How to resolve conflicts between authoritative sources
- Difficulty in seeing where authZ begins and ends in the app code
- Disentangling user identity from app identity
The above is not a complete list but does demonstrate some important challenges for enterprises progressing towards ABAC. (Note- almost all enterprises already use ABAC, in other words the apps' attributes change the structure and behavior of the app, they just don't recognize it as such)
To create clarity on roles in authorization framework - identity provider responsibility vs service provider responsibilities, I recommend mapping out Chain of Responsibility patterns to better understand what authorization decisions are made and where. For each key decision, there should be an approved authoritative source of those attributes.
Where possible, the authorization decisions should be adjudicated at a boundary such as proxy, presentation, business logic and data layers. Not every app is so clean as to support this, but its effective when viable. Resolving authorization conflicts is a tricky proposition in these cases (and made worse by various impersonation/delegation hacks that enterprises back into by cobbling together partial solutions for app/user identity disentanglement), many enterprises simply fail open, which can wind up ending on the big breach list.
This post isn't a complete overview of what to do, but practically speaking the list above is a subset of issues that enterprises need to solve for while they progress to Dynamic, Pull based authorization architecture.
Swapping out authorization systems makes swapping out authenticaiton systems look like a tea party. Don't expect this to be super-fast plug and play, its a journey, for many apps its invasive surgery. I mean that literally, like invasive surgery its short term painful and its long term worth doing. The problem must be diagnosed and due to the degree of change required, mapping that to a longer term vision and work through the subset of issues listed above through careful and likely incremental release planning is key to concrete progress.
Comments