xml-dev - RE: Healthcare and Security/Privacy

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Transferring metadata is one means but you have no 
guarantor it will be applied.  That is unacceptable.  
See below on vetting of organization.  Simply, you 
will not transfer such information in the clear or 
to a non-trusted host unless locally authorized 
(sender is responsible and authoritative).

You have the additional value of the workstation itself 
to associate with the login.  This is another security 
technique where the room the device is in is part of 
the securing method.  In all cases, a separate information 
set is being used to apply security.  These may work in 
combination or singly.   It is not necessary to create 
an orthogonal set of security attributes and use them 
on a per field basis thus replicating that information 
in every part of the database although that is one 
technique.  It depends on where you want to put the 
security overhead.  Yes, you can create a security 
model of authorities and yes that can be transferred 
if applied to record types.  Do you want the secured 
data to be filtered out by the query or the query 
to be filtered?   

There are also the levels of 
security in terms of what is revealed by a negation.  
IOW, if you allow a name plus age on one query, but 
the next query only provides a name, you have a good 
chance that a juvenile has been located.  If the 
crime is rape and a relationship of victim to assailant 
is familial, you have incest and by law, this cannot 
be disseminated.  In some applications, security is 
applied through a separate module, a dissemination module, 
where the rules for filtering vary by such things as 
public requests or investigator requests (your transfer 
module).   

Role-based models must be consistent with the application (eg, 
public safety rules and nuclear security rules only 
have general security models in common).   So the 
model you describe must account for both the securing 
techniques and the content model to which they are 
applied.  Another issue is the medium by which information 
disseminated.  It is easier to secure a report than 
a QBE interface presentation.  

The problem with standard transforms are 
just how standard they can be and the effect on 
the presentation.   This is Walter's pipeline.

Guarantors are harder.  Klingons are notorious for 
their ancient promotion practices.  There is an accepted  
incentive to take out the head klingon, so the usual 
background checking doesn't apply to a culture of 
assasination.  Security includes a notion of vetting 
both the application and the organization.  Because 
of this, vetted organizations can exchange DNA 
records; a non-vetted one can not.  BTW, this is 
probably part of the CARNIVORE dilemma.  It is cheaper 
to put a black box in the loop than to vet all of 
the ISP employees.  The question is who do you 
trust more, the FBI or the ISP?   It has been discovered 
that gangs often try to infiltrate police department 
records organizations by getting girlfriends into 
records management positions.  There are deeper 
problems where internal investigations have to 
be shielded (who polices the police).  Anyone think 
it is easier to get hired at the ISP or the FBI?

Security and system auditing are related.  Every 
system we field has timestamped, user, workstation 
access models to determine if a record is changed 
or inspected, by whom, where and when.  There is 
more but that gives an inkling how deep it goes.

All of the above must be considered when creating a 
secure application.


Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://fly.hiwaay.net/~cbullard/lensongs.ram

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: KenNorth [mailto:KenNorth@email.msn.com]

Now let's say Federation East has to transfer the patient to Klingon West
Hospital. How do we preserve authorities or privileges to access data if
Klingon West manages database security by user instead of role, or stores
records using a primitive file system.