[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes 14 April 2016 TC Meeting
|Time: 4:30 PM EDT (-0400 GMT)|
Access Code: 620-103-760
Minutes for 14 April 2016 TC Meeting
I. Roll Call & Minutes
Hal Lockhart (Co-chair)
Bill Parducci (Co-chair)
Voting Members: 6 of 9 (67%) (used for quorum calculation)
Bill Fisher NCCoE (NIST)
Sudhi Umarji NCCoE (NIST)
Approve Minutes 31 March 2016
Approved unanimously, no objections heard
NCCOE Presentation Follow-up
I have read through the comments and believe that Martin's point re: the
business value is quite pertinent. The technical people I have spoken with
are finding it a challenge to present ROI, so Use Cases that show value
would be quite useful.
Yes, this has been an ongoing challenge.
When I worked for the government such analyses we common. Cost benefit
analysis was particularly difficult because attributing costs to
maintenance of ACLs, etc. The savings are, I believe, real but represent a
challenge to define and require significant estimation.
What is being compared to is an obvious key point. Framing this in the
larger sense can make the more compelling case on the benefit side.
This can be extended to incorporate things are simply not being done today.
This can be looked at probabilistic side by looking at a variety of likely
scenarios (hacks, reorgs, mergers, etc.)
The administrative aspects of audits, management, etc. can also be
effective on the cost side. ON the auditing side, the key questions center
around on finding: (a) what does a user have access to?; (b) Who has
access to X?
I think many of these questions are not feasible because of things like
federation, timing (state) issues. In other words, there are situations
where "reversing" a query is not possible.
I think the questions: (a) what has this person done?; (b) how was he able
to see it?; (c) who else may have accessed this?
All of these are possible today.
I think that ABAC tends to be an IT project, rather than a Security/Risk
project. I think that this is a major roadblock to validation for adoption.
I don't think technical explanations will get us traction in the market.
I think Bill's approach of a plain explanation of benefits in business
terms is likely to be more fruitful. I think the work NCCOE is doing is on
target, especially regarding the deployment processes that are established
that enable people to apply the technology in a very cost-effective way to
see if it will work in their environment.
One of the things we have been thinking about in our "1800 series" documents
that introduce mechanism that help make decision like, "Is ABAC right for me?"
This is where we are trying to develop details to help answer these questions.
There is a perception that ABAC has a high barrier (business) to entry because
it requires a relatively custom solution. I have been pushing the concept of
Oasis coming up with a "standard model" for ABAC that reduce the risk of
deployment and lengthy evaluation.
The reality is that new standards require adoption. The nature of the problem
makes this an integration project.
This implies that the vendor has tested compatibility. The question remains
how do you choose a vendor?
The problem is complex. It has a lot of variables.
Hal reviewed the topics in the email thread on the list with general
I have heard XACML as being “policy" based while OAuth is "consent" based.
Consent is just one way of granting access, but it is consistent with policy
In the OAuth demo there are about 5 places where a policy comes into play in
the flow. ( https://lists.oasis-open.org/archives/xacml/201604/msg00007.html)
I will go through the notes and determine what will work as an update to the current document work and then what will require a separate effort.
There is general agreement that a follow-up discussion in a month or two would be a good idea.