(Note―I don’t think this comment will
reach the list as I am an observer, not a member. If one of you--John/David―is
a Member an wants to forward this message to the list, please do so.)
In the contexts that we (in my part of
DHS) have been considering similar issues, we would basically agree that there
are two important “use cases” to cover, but we use slightly different terms,
i.e.,
1. Some access attributes may allow
the requestor to assert them (perhaps from a pick list of “authorized purposes”
for the info may be sought; perhaps with a warning (“You are asserting an
authorized purpose for accessing this info. Your access may be audited
and legal action taken if it is determined that the use was fraudulent or
unauthorized.”) For the BTG scenario, the assertion of “FIRE!”
may be the ONLY access attribute required, but of course the asserted “authorized
purpose” attribute might also be only one of several required attributes:
“JobRole=PassportOffice Clerk AND AuthorizedPurpose=”Validating Application”.
2. Access may also be conditional on
some environmental attribute obtained by the PDP or whatever at rule-evaluation
time (and not associated with or provisioned from the requestor’s credentials or
the requested resource’s metadata or value.) Examples: “CurrentThreatLevel;
“EmergencyDeclared”.
Martin
Martin
F. Smith
Director, National Security Systems
US Department of Homeland Security
NAC 19-204-47
(202) 447-3743 desk
(202) 441-9731 mobile
(800) 417-6930 page
David,
1.
BTG is a common healthcare concept. The Draft BTG profile seems to
describe a concept somewhat different. I've included a short paper which
provides definitions, descriptions and requirements for BTG and "emergency
access" as two distinct and different concepts within the healthcare
domain. Here is a short description from HL7's Access Control Service
Functional Model:
"Break‐glass is named after the glass panel that
protects a fire alarm. Everyone in the building is authorized to use the fire
alarm to report a fire, but the ramifications of misuse are substantial. The
fragile glass panel is sufficient to avoid accidental triggering, and it forces
the user to stop and think
before acting. In the context of this document, a
“Break Glass” scenario involves a situation where the access control policy
will authorize the user to access certain information or functionality, but
only after the user attests that one or more relevant conditions exist."
2.
As described in the draft profile, the most important concept is that the
profile requires a BTG permission. This does not match the notion of BTG
as used in healthcare which is much more like a user controlled
"gateway" much such as a fire alarm. I'll explain by means of a
use case:
In
this healthcare scenario, a user is authorized to access patient records (has
appropriate permissions). Some records (e.g., VIP) are sequestered behind
a BTG barrier. A user attempting to access a VIP record will be presented
with a warning banner indicating that the record is protected and that access
will subject the user to increased auditing (and perhaps other controls such as
notifications to system admins). In any case, the requester has two
options; 1) abort or 2) continue. If 2) is chosen the record is
presented. The distinguishing characteristic is that no elevation of user
permissions and no special "BTG permission" is required, the user is
already in the "clinician" group authorized to view records.
This is analogous to students in a high school. They are all members of a
group who are "authorized" to pull the fire alarm. Doing so
falsely will subject the student to discipline but the student does not need
the teachers authorization to pull the alarm when conditions warrant.
This
is distinguished from emergency access of the first kind (normal emergency room
operations). In emergency access #1, the context of the emergency
(significant harm or risk of death to the patient) needs to be presented so
that the access control system evaluates the appropriate policy set (e.g. A
clinician at one hospital may not be authorized access to records at another
under normal conditions of “treatment”). In emergency access #1, the XSPA
SAML attribute assertion profile provides an "Emergency Access"
purpose of use attribute. This purpose of use allows the PDP to select
and evaluate the appropriate policy for the "emergency" condition as
opposed to normal "treatment". Again, it is not the user
permissions that are evaluated but the fundamental context of the policy
environment.
There
is emergency access of the second kind which is a variation of emergency access
#1. In emergency access #2, the requester makes the request for
information under the purpose of use of treatment and clinical role.
Authorization to view the record under these conditions is denied (perhaps an
underlying privacy policy is being enforced). In response the clinician
responds by elevating permissions by asserting the “emergency role” in the XSPA
SAML Assertion profile thereby elevating privileges under the same POU of
“treatment” and overriding the original policy decision. In our work in HL7 we
have found the “emergency” role/permission unnecessary as POU has the added
benefit of putting in place (and managing) an emergency context vice a simple
role. Emergency #2 is probably closer to what is intended by the Draft
BTG profile but is significantly different from what is described above.
I
believe additional discussion is warranted on the fundamental concepts of the
Draft BTG profile, first to ensure common understanding of the different forms
of access, the uses of policy, purpose of use and permission and second to
establish sound use cases that will sufficiently clarify the purpose and
conditions under which use of such a profile is warranted.
Regards,
Mike Davis, CISSP
Department
of Veterans Affairs
Office
of Health Information
Security
Architect
760-632-0294
-----Original
Message-----
From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]
Sent: Tuesday, November 23, 2010 9:07 AM
To: xacml
Subject: [xacml] Draft BTG Profile
Dear
List
about
a year ago we discussed the standardisation of the Break The Glass response
(see Seth Proctor's message of 17 Dec 2009) and decided that a profile to
standardise the BTG response would be useful. Unfortunately Seth left Sun
before we got around to writing it.
Consequently
Stijn Lievens and myself from Kent
have produced a first version (attached) for your consideration. I know its not
in the correct format yet, but we can fix that once the technical content has
been agreed.
Comments
appreciated
regards
David
--
*****************************************************************
David
W. Chadwick, BSc PhD
Professor
of Information Systems Security School of Computing, University
of Kent, Canterbury, CT2 7NF Skype Name:
davidwchadwick
Tel:
+44 1227 82 3221
Fax
+44 1227 762 811
Mobile:
+44 77 96 44 7184
Email:
D.W.Chadwick@kent.ac.uk
Home
Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research
Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust
key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
*****************************************************************