Hi John
On 30/11/2010 12:27, Moehrke, John (GE Healthcare) wrote:
> I am saying that there are regional differences that we should view
> as different use-cases.
this is very vague and unless these use case are identified and
specified it makes it very difficult to standardise something
John (Mike) Davis and I work closely
> together, we are co-chairs of the Security Workgroup in HL7. I do not
> disagree with his use-cases, but I do recognize a few more use-cases
> need to be considered as there are regional differences.
>
> Note that we also need to consider not just the 'break-glass' state
> change, but also the return-to-normal state change. Is this
> return-to-normal a transaction based thing, Session based, timeout
> based, etc? Who controls the return-to-normal state change? This will
> also drive the design of the 'break-glass' state change.
I absolutely agree with this. In our ACSAC paper we identify three
different mechanisms: automatic, semi-automatic and manual resetting of
the broken glass. Automatic resetting means that the BTG PDP itself
resets the BTG variable to FALSE after a specified event has occurred.
The event must be specified by the policy writer when creating the BTG
policy. Semi-automatic and manual resetting of the BTG state are
initiated in a standardised way by either a system component or a human
being that is external to the BTG PDP. This requires a new reset action
to be specified for a BTG state. The policy writer must specify who
(e.g. which roles) has permission to perform this action (and which BTG
state it will affect, assuming there are multiple state variables).
We have implemented all three in our implementation e.g. with automatic
resetting the policy writer specifies the time after which the glass
must be reset. Our live demo at https://authz.tas3.kent.ac.uk:8443/btg
shows the automatic resetting in operation with a time of 30 secs
specified in the policy.
>
> I will also note that there is yet another use-case that people are
> hinting at. The use-case where a catastrophic event has happened
> (e.g. Katarina hurricane is our usual US example). The Healthcare IT
> systems were not working fully, but there was patients that needed to
> be taken care of. Further much of the normal staff had evacuated and
> was not coming back to work, to fill in was volunteers. The first
> thing to try is to identity proof these volunteers as real doctors
> with real medical credentials; and once that was done create real
> accounts with appropriate rights; so that normal access control is
> used. But at some facilities (very few actually) this was not
> possible as the system administrators were the missing people or the
> identity management system was damaged (under water --- basements are
> a bad place to put the IT department in a flood prone area). In
> these desperate cases they declared an emergency at the
> organizational level; this served to move the whole organization's
> access controls into a more relaxed mode. It did not expose highly
> sensitive data, but for example it did allow for dispensing specific
> drugs more freely, it did allow viewing (not changing) of normal
> charts by anonymous access (typically just to print for posting
> old-school at the bed side). I know that many facilities operated
> normally and did NOT need to do anything special. Whereas others just
> used pre-provisioned user accounts (printed on paper and placed in a
> secured cabinet... kind of behind glass) that were handed out * This
> would be an organizational level context change. As implemented it
> was not transactional, but rather put the whole system into a
> different set of policies.
Very interesting. As an aside I am currently involved in a bid to the EC
for an IT project to help the sharing of information after disasters. If
we win the bid I would be grateful if we could talk more about these
situation.
But in terms of BTG use cases, I dont think this is a new use case since
as your last sentence points out, this is a case of moving to a new set
of policies.
regards
David
>
> John
>
>>