« LaTeXMath, a Kwiki Plugin for Mathematics | Main | Identity Reading List »
Aggregating Risk
Jamie Lewis reacts to the recent security breach at George Mason University where intruders made off with information about 30,000 students, faculty, and staff, saying “[A]s identity systems aggregate information, they also aggregate risk.”
Kim Cameron, on the same subject, says that we need to assume our identity stores will be compromised at some point and plan accordingly:
We need to base our approach to these scenarios on the idea that one day, the store will be penetrated. We need then to reduce information in the store to the minimum required. We need to distribute information so breaking into one system gives away as little as possible. And more than anything, we need unidirectional identifiers such that only access to a metasystem allows assembly of cross-aspect information.
For example, there was no need for George Mason’s ID system to contain social security numbers. Nor, bizarrely, is there probably any reason for it to contain student identification numbers. It could - I know this sounds primitive - just contain single-purpose identity card numbers. A metadirectory - which itself contained no substantive information - could provide glue to other identification contexts for those who merit it - and on a case by case rather than carte blanche basis. This allows many more controls and balances to be built into the system. (All of this is Law 4)From Kim Cameron’s Identity Weblog
Referenced Thu Jan 13 2005 09:07:55 GMT-0700
Kim’s got a great point here. We frequently, because it makes the programs easier to write, gather all the data together in one place. Identity systems should be architected to return only the necessary information and have to ability to gather than information on-demand from various places.
Posted by windley on January 13, 2005 9:01 AM




Comment from Fazal Majid at January 13, 2005 11:27 AM
France has an interesting privacy law that requires any database containing personal information to be vetted by a "National Commission on Computing and Liberty". Even government databases like the police's criminal incident database is covered.
The commission is understaffed and overworked, and would not catch everything (if they do not respond within a certain time frame, your data model is approved by default), but at least this kind of process prevents wrong decisions being taken purely on the basis of the path of least effort for lazy programmers or administrators.
Comment from Eric at January 13, 2005 9:02 PM
Good point. This reminds me of designing relational databases and separating out into tables such that each table has just the information it needs with the right referential integrity constraints built in. Hard work, but the elegance pays off in the end. Web service orchestration, "identity systems that gather information on-demand," or whatever you want to call it seems like that same type of design work except spread out over the Internet rather than happening inside one RDBMS. I guess the plumbing for this is becoming less of a pipe dream, but I still want it yesterday. :)