Legal Standards in a Technologically Bifurcated World

Posted by K Krasnow Waterman on Thu, Jan 29, 2009 @ 10:01 AM

Tags: access control, identity management, technology implementing law, privacy technology, technology for business managers, law about technology, public policy, technology b2b customer service, information security

It's not news that our society is divided into technological haves and have-nots.  Much has been written about the advantages lost or gained - education, professional, and social - based upon the primacy and recency of one's technology.  Recently, I've become increasingly attuned to another place where technological caste matters -- legal standards. 

It's been clear to me for quite some time that the lawyer who resonates with technology can do more successful and faster legal research; propound vastly superior discovery requests; and produce substantially more incisive disclosures.  It's now becoming increasingly clear to me that the law itself is being skewed by those of us who live to keep up with the next big thing in technology.  Debates among lawyers rage in my email inbox about the differences in things like encryption technologies and metadata standards, with lots of cool techie references to things like ISO, NIST, Diffie, OASIS, and XACML.  

In the meantime, I was on the the Social Security Administration website the other day and they wanted me to use an eight digit alphanumeric password (case insensitive, no special characters) to upload W2 and other sensitive tax information.  My bank's brokerage affiliate is using the same outdated and readily hackable password technology  I still see commercial and bar association websites seeking personal and financial information without indicating that they're using SSL or some other baseline method of securing the information.  I still get requests from security professionals to email my Social Security Number.  If you're not particularly technical, trust me, none of these are good things.

The distance between these two realities has got me thinking about all the places that these two technological castes will be competing to set legal standards.  For example, does a "time is of the essence clause" apply the perception of time of a blackberry owner or a person without a laptop?   

As the new administration provides the first coordinated national focus on technology, I'd like to add this to the list.  Perhaps the new national CTO (yet to be appointed) could work with the American Bar Association and other leaders to identify a rational strategy for standards setting in such a technologically bifurcated society.

 

 

 

Article has 0 Comments. Click here to read/write comments

Lucky 13, Nicely Nicely and User Attributes in Identity Management for Access Control

Posted by K Krasnow Waterman on Wed, Aug 15, 2007 @ 09:08 AM

Tags: technology innovation, access control, identity management, technology for business managers, technology, technology management

I've always loved the Guys and Dolls song in which a bunch of guys sing a catchy round about picking their favorite nag at the track. They're telling each other why they've made their pick. It goes like this:

"I got the horse right here
The name is Paul Revere
And here's a guy that says that the weather's clear
Can do, can do, this guy says the horse can do"
...
"I'm pickin' Valentine, 'cause on the morning line
A guy has got him figured at five to nine
...
I know it's Valentine, the morning work looks fine
Besides the jockey's brother's a friend of mine "
...
"And just a minute, boys.
I've got the feed box noise
It says the great-grandfather was Equipoise "

What does this have to do with computers? It provides an easy to understand example of how we make decisions. The gamblers are describing where they got their information and what categories of information matter to them. They rely on a favorite racing form, friends of friends, and gossip from the staff. In the brave new world of dynamic access control, we want to do the same thing to reach an automated decision about what data you can see. Instead of racing forms, we have "trusted sources" or "authoritative data" -- repositories we believe have reliable information. And, instead of the weather, lineage, and distance, we're looking for other categories of facts that consistently help us to reach our decisions.

I've recently done a project in which we attempted to define how many things you really need to know about a system user to decide whether or not s/he can have access to particular government work-related information. The idea was to see if there was an universal core of attributes that most system access rules are seeking. In other words, does the decision about what you can see in the human resources system rely on the most of the same categories of information about you as the decision about what you can see in a criminal case file or a person's tax filing. Our answer is "yes," if you create the right sort of categories. And, much to our surprise, our core list is only thirteen attributes.

What's the right sort of category? Other proposals have made each fact its own category. For example, imagine an attribute which indicates whether someone is a law enforcement officer and a different one for whether someone is a lawyer. Organized that way, you would need thousands (millions?) of attribute categories. But, if you say the attribute is "job description" then you can include officer, attorney, and a million other jobs in one attribute category.

Having a small number of needed attribute categories has a tremendous advantage. It means the software can be less complex, handling a smaller number of variables. It means the processing time should be faster. In this design, each system needs to know only the values it cares about. For example, if the access rules for a system only permit government auditors and law enforcement officers to view the data, the particular system doesn't need to know that a person can be a doctor or a dog catcher. It only looks to see if the person seeking access matches (or has an equivalent to) "government auditor" or "law enforcement officer" in his "job description" attribute.

We think the 13 user attributes are:

Employer Name
Employer Subgroup (as many hierarchical levels as needed)
Employer Type (e.g., federal government, private hospital)
Employment Type (e.g., permanent, temporary assignment, contractor)
Job Designation
Location (physical and virtual)
Location Type (permanent, temporary)
Special authorities/licenses (granted by others)
Management Level
Direct Reports
Rating/Reviewing Official
Skill (ability, irrespective of outside grants)
Skill Level

So far, we haven't come across a data access rule we couldn't parse into one of these attributes. If you do, please tell me.





Article has 0 Comments. Click here to read/write comments