The Data Management Oath
I give my word to keep according to my ability and my judgement, the following Oath.
"To consider dear to me the trust placed in me to faithfully protect and be a good steward of the data and information with which I come in contact. I will enact proper procedures and security for the good of my company's customers according to my ability and my judgment and never do harm to any data entrusted to me.
To please no one will I cause any data to be breached nor will I give advice which may cause a data breach.
All that may come to my knowledge in the exercise of my profession or in daily commerce with men and comapnies, which ought not to be shared, I will keep secret and will never reveal.
If I keep this oath faithfully, may I enjoy my life and practice my art, respected by all men and in all times; but if I swerve from it or violate it, may the reverse be my lot."
Well, this seems to have struck a nerve. There have been several comments posted directly on the blog (feel free to continue to do that) and I have also received some e-mail on the subject (feel free to continue to do that, too). One e-mailer in particular, Adam Gilinsky, gave the topic quite some thought, and I am including it below (mostly verbatim) to see if it sparks some additional comments:
I enjoyed your article; it sparks off thoughts on a range of issues, some of which I have been thinking about recently anyway.
First of all, let me agree that there is a commercial pressure on some DBAs, some of the time, to provide data sets which contain confidential information in ways which might violate laws, regulations, or just ethics. (Nor are data professionals necessarily ethical, some may do so when faced with non-commercial pressure or for personal advantage.)
While having an Oath (should it be named for Fisher, Shannon, Codd, or perhaps Mullins?) would be a sign of personal and professional maturity, as an active acceptance of responsibility, I suggest that - human nature being what it is - without recognition by a reasonably powerful professional organisation to enforce it, it would quickly become a dead letter.
Furthermore, without recognition in law of a (perhaps limited) DBA/Data Subject confidentality relationship (as there is for lawyers, doctors, and priests), it could become a serious liability for data professionals. ("Why won't you testify that the Mr. Smith in your database has the same Social Security number as the Mr. Smith under trial for hacking, Mr. Mullins?" "I took the Oath, Your Honor"...)
At the same time, there are some encouraging signs that more advanced business leaders are beginning to think about really talking with their customers - and one result of this could be increased demand by data subjects to be able to see for themselves who has accessed their data, when, and for what purpose. Such self-policing could be more effective than an Oath given by DBAs on behalf of people (unlike lawyers and doctors, in theory anyway!) whom they are unlikely to ever meet or talk to (such personal contact must work to enhance the relationship value of the general Oaths such professions take).
However, it seems to me that while 'privileges' over systems may be extensively catered for in underlying RDBMS design, these 'rights' are granted top-down and are very hard to audit (especially over time) (I'm working on a CMDB at the moment, so I feel qualified to judge). These privileges and rights are linked to the system itself as well, so when a data snapshot is taken into another form almost all traceability is lost.
Some steps can be taken at the 'system' level and probably should be part of a standards process - for example, requiring a double password system (yes, dual key does seem a bit Cold War-ish) for high level admin access, default hard passwords with an automated rejection of 'patterned' choices (like $User_ID$+'xxx'), using those funny web graphics for human only confirmation, and so forth. (While on one level, allowing computer 'services' log ons is a secure way of processing sensitive data, on another, such services are profoundly insecure. For example, an Excel Spreadsheet might use a secure method to obtain data - but how is the spreadsheet itself to be controlled?)
However, I would suggest that ultimately the flow of control should come from the data subject - and that can only be done by having databases which can support a 'User-Auditable' datatype. Data of such types should be (partly) encrypted within the database and require an 'authorisation' cookie or somesuch to be viewed individually, and - in the encrypted part - be unable to be viewed as part of a list of any type (one thing to copy down my details off a screen, quite another for someone to copy thousands of credit card or bank account numbers). Counts and aggregates should be possible on such data. Ideally, user-audit data should be able to be set at various levels of trust - I don't mind the Amazon deliveries department to be able to see what books I'm waiting for in my current orders, but I can't see why they need to know what books are in my wish list, shopping basket, or in my old orders. On the other hand, I may want to authorise a new doctor to be able to see all my medical history. And let's face it - the tax man will want to see where our income comes from!
Now, I'm a wee bit skeptical of the long run value of encryption itself, so I'd also want - as a data subject - to know who has looked at my data, when, and why. So I would suggest that part of the definition of 'User-Auditable' datatype is the specification of triggers which records creation, update, delete and select (or select distinct, if as suggested it was the method for seeing the encrypted data), and of course of the resulting audit table and a method to access the relevant portion of that table. ((Aside - at the very least why oh why doesn't any RDBMS have a way to simply designate a given table as an audit table when it is created, rather than always having to build these yourself!))
So in essence I'm suggesting that data security should be, will be, built in at the database level, with 'active' data that controls privileges and rights coming from the data subjects - and that rather than take the Oath (or perhaps as well as!) DBAs should be insisting that only 'security certified' RDBMS with these kinds of features should be used to hold such sensitive data. Yes, it will take a while for all the existing data on us as data subjects to fade into inaccurate unusability, but it will over time.
With the coming into force of legislation like SOX, EU data protection rules, and also the discussions of National ID DBs (shudder), plus the advance of customer/business interactivity, I think the environment is ripe for such an approach, in a way never before available. Indeed, if this idea can make it into open source RDBMS like MySQL (which could provide a forum for this kind of development) then the commercial pressure on the likes of even such business facing giants like IBM and Oracle to provide compatible User Data Security could well force the change.
Regards, Adam Gilinsky Remedy/Oracle/SQL Server D/D/A
PS I am affected personally by two separate 'Oaths' but which only apply in particular contexts, one as an 'Authorised Person' under the UK Financial Services Authority, and another as a member of the Bar of the State of Connecticut - and possibly a third in terms of the implied confidentiality/whistleblowing agreement with my current employer, though that is not directly for the benefit of any Data Subjects (unlike the first two).
Mr. Gilinsky raises many interesting points. I think most salient is the potential for technology in the form of 'security certified' RDBMS products with built in controls for 'active' data allowing privileges and rights to be set based on data subjects. This may happen, but it will take time. Perhaps this, in conjunction with "the Oath" (as Mr. Gilinsky suggests) can help to move the industry forward.
Mr. Gilinsky also rightly points out the potential pitfalls of such an oath if it were not supported by the "fabric" of the law. Now I'm all in favor of passing and enforcing legislation to facilitate better data security and protection (as I've written here before). But simply passing laws won't do it - we need strict enforcement, too, and that is always costly.
Well, dear reader, what do you think? Don't be shy, join in the conversation...
