In his discussion with the TC last week Bill Fisher of NIST/NCCOE said he was looking for activities NCCOE might take to advance the implementation of ABAC in the private sector. He also described several of the past and present projects, including the ABAC Building Blocks publication (
). The XACML TC submitted comments on the latter, as you may recall.
Although it came up only tangentially in the discussion last week, the NCCOE's program is based on some diagnosis of why ABAC adoption has been disappointingly slow. I believe Bill mentioned NIST's perception that one obstacle is lack of detailed guidance on how to integrate and configure ABAC components; hence the Practice Guide. He also mentioned being interested in identifying technology or product/tool gaps.
Perhaps it would be useful for us to take a step back from ideas on "what to do" and have a look at "what's the problem." In other words, maybe we should consider developing and documenting a common understanding of ABAC implementation obstacles and their relative importance. This would then provide a sound basis for NIST/NCCOE (and others, including ABAC product vendors) to focus on activities that address the obstacles.
So, here's a "starter set" of obstacles (or categories of obstacles) for your consideration:
1. The elephant in the room: what is the business case for ABAC? Some possible answers below, but in all cases I'd say there's a lack of well-documented (preferably with some before-and-after metrics) "case studies" of how ABAC has delivered one or more business benefits. (A brief nod to Axiomatics who seem to be trying to address this with their recent series of WebEx events.) Possible business benefits:
a. Ability to put more sensitive information on-line (within the enterprise but especially for sharing with customers and business partners)
b. Compliance: demonstrated conformance with data-protection regulations like Sarbanes-Oxley, various jurisdictions' privacy regulations, HIPAA, etc.
c. Privacy and security: not the same as "compliance", which is process- vs outcome- oriented
d. Operating cost savings
e. "Agility" -- ability to implement access-policy changes quickly and consistently across the enterprise or other relevant environment. Also ability to reach a targeted user demographic quickly when a new information service is fielded.
2. Lack of understanding or engagement among enterprise "policy authorities" (CFOs, Counsels, CPOs, CISOs) on developing "digital-ready" policies in their respective areas of responsibility. "Digital-ready" means policy expressed in natural-language but unambiguous _expression_ (i.e., "if-then" statements.)
3. Lack of incentives for operators of "authoritative attribute" data sources to make their attribute data available for digital access-control use.
4. Lack of standards for how resource attributes (data tags, etc) can be identified and accessed (by a "context handler.')
5. Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)
6. Unapproachability of raw XACML (which means that implementer technical resources are dependent on vendor-specific tooling for policy/rule writing.)
7. Lack of a widely recognized or standardized logical architecture (with testable component functions and interfaces) for full ABAC, resulting in "customized" solutions that are therefore very expensive and also non-interoperable across different organizations.
Regards,
Martin
--
Martin F Smith, PrincipalBFC Consulting, LLC
McLean, Va 22102