Re: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)
I think I pretty much agree w the general points that both Hal and
Martin
are making, but I think both are addressing somewhat different
perspectives.
Based on my own experience w OpenAz and other multi-domain
endeavors,
I have found that syntactic agreement can usually be obtained fairly
readily,
if all parties are co-operating, but semantic agreement can remain a
roadblock
for a long time, which from a policy perspective, imo, is a
show-stopper because
it makes no sense to have a common policy if people interpret the
terms
differently.
Therefore, I think Martin's points 1 and 2 are compelling because
they appear
to represent real-world use cases, where semantic agreement, is, in
fact, a
primary requirement. Also, even though semantic agreement may be a
theoretical objective, which can never, in fact, be truly reached
(as for example,
demonstrated every day on the US Supreme Court, where, ultimately
what the
law means is what 5 or more judges on court say that it means), at
least having
the notion of semantic agreement can point the way to a process for
ultimately
resolving disputes, where presumably the holder of the policy could
bring it
to the Supreme Court to determine if the holder's interpretation is
correct.
Also, Martin's point 3, about existing profiles of XACML,
essentially performing
this role, which I will accept at face value, not having thought
about these
profiles in that perspective before, may point a direction to
"augmenting"
ABAC w a procedure for nailing down semantic agreement on specific
attributes that the cooperating parties can work with, while leaving
other
policies not covered by the profile in the current state of possible
semantic ambiguity until someone is concerned enough to nail these
down as well.
Thanks,
Rich
On 4/28/2016 1:25 PM, Hal Lockhart
wrote:
Don’t
get me wrong. I don’t disagree that semantic agreement would
be very desirable. I am just saying that if it is considered
a precondition to adoption, then adoption is never going to
happen.
Hal
From:
Martin Smith [mailto:]
Sent: Thursday, April 14, 2016 3:03 PM
To: Hal Lockhart
Cc: XACML TC
Subject: 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 <>
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:]
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
703 506-0159
703 389-3224
mobile
--
Martin
F Smith, Principal
BFC
Consulting, LLC
McLean,
Va 22102
703
506-0159
703
389-3224 mobile