OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [EXTERNAL] Re: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)


From the Healthcare perspective I agree with Martin.  The vast majority of our work nowadays involves interoperability, standards, standard vocabulary.  The most current healthcare models for ABAC have involved standards for labeling including Implementation Guides, a Classification System, world-wide interoperable vocabulary, standards for Security and Privacy labeling services, Privacy protection services based on labeling etc.

We have integrated traditional XACML with OAUTH and UMA for further expansion of business needs.

 

Biggest gap in XACML?  Inability within the standard to exchange obligations between organizations for the post receipt handling of labeled information.

 

 

John “Mike” Davis

VHA Security Architect

760-632-0294

 

 

 

From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Martin Smith
Sent: Thursday, April 14, 2016 12:03 PM
To: Hal Lockhart
Cc: XACML TC
Subject: [EXTERNAL] Re: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)

 

Hal--thanks for the response. 

 

Regarding the semantic standards issue, I think we're going to have to agree to disagree. I will agree you have a lot of company in the view you express, but I'd make three points: 

 

1.  There is considerable movement to develop semantic standards, not for everything but to support specific transactions within a business community of interest. Both OASIS' UBL and the National Information Exchange Model NIEM) have recently come out with revisions. For NIEM the the approach is to delegate coordination of standardization of specific exchanges (so-called IEPDs)  to domain coordinators within broad sectors such as health, law-enforcement, emergency management, defense. etc.

 

2.  Many--perhaps most--information-access policies are not local. This is the biggest change from the traditional view where a local database admin keeps a list of names on an ACL, according to his own best lights. But many policies are based in law that has wide application, which means that the legal concepts (like the ones I mentioned -- law-enforcement officer, physician) are also widely applicable. In this increasingly compliance-oriented world, having standardized concepts for required info access policies should be of significant value to enterprise officers responsible for documenting compliance. 

 

3.  Most important I think is that a lot of the potential value of ABAC will be left on the table if the model cannot be extended outside a single enterprise. And cross-organizational sharing of sensitive information requires semantic "interoperability" between business partners, which may start as bilateral agreement on terms but has to be broader than that (but not universal) if it is to scale. The XACML TC's IP and Export Control profiles are examples of standardizing attribute semantics for two specific classes of transactions. 

 

Regards,

 

Martin

 

 

 

 

 

On Thu, Apr 14, 2016 at 1:50 PM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

I agree with most of this, Martin. Thanks for putting it all in one place.

 

----

The main point I disagree with you on is:

 

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"?) 

 

IMHO this is not going to happen. Any AC scheme that has this as a precondition is not going to be adopted. For the foreseeable future, policies are local with rare exceptions.

 

-----

To your elephant in the room, I suggest that to answer this question we have to be very specific about what we are comparing XACML or ABAC to. Many people implicitly compare it to permissions or ACLs or even RBAC. However, far and away the most common form of access control is program code written in a Turing-complete language and embedded within the application.

 

In this context the greatest benefit is simply to be able to identify what the policy is, as distinct from various aspects of the application logic or UI.

 

Hal

 

From: Martin Smith [mailto:bfc.mclean@gmail.com]
Sent: Sunday, April 03, 2016 12:59 PM
To: XACML TC
Subject: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)

 

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 ( https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf )  and the more recent NIST 1800-3 ABAC Practice Guide ( https://nccoe.nist.gov/library/nist-sp-1800-3-attribute-based-access-control-practice-guide ).  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, Principal

BFC Consulting, LLC

McLean, Va 22102



 

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102

703 506-0159

703 389-3224 mobile



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]