Data confidentiality issues

Last week I met with Jim Weise of Tablus, who I had met at last month's RSA conference. Tablus focuses on enforcing data confidentiality rules. The concept is, you would set up a database or file system, and apply a confidentiality rule against all the contents of that set. If a confidentiality rule is broken -- if a document is emailed outside the company, for example -- an alarm is issued for administrator review. They also have a sexy desktop app, which addresses the issue of someone cutting and pasting content from a confidential document into an email.

So there are some larger issues here, such as the fact that we'd all prefer preventive over detective controls, but this could be a good solution until better preventive controls come into place. Data classification is just such a horrendously annoying problem. In Secrets and Lies, Bruce Schneier discusses the Bell-LaPadula model of multilevel security, which offers a preventive concept. Basically, if I am working on a Secret computer or session, I have no access to write unclassified work, only Secret work, eliminating my ability to email a classified document, or reduce its security level. (Of course, this naturally supposes that our brains are purged of the information we read in a secure session, once we open an insecure session.) The problem is that everything -- user experience, expediency, etc -- is sacrificed for the sake of confidentiality. Great for the military, lousy for the real world.

Should we even be attacking this problem at all? Who has read access to data is not a key control for SOX, and the FDA hasn't focused attention here either. Much worse than dealing with data confidentiality in an ad hoc basis is coming up with controls which will fail under audit or inspection. In other words, if we take the time to classify all our data, develop rules, publish them, train users and put in detective controls, are we confident we can get to 100% compliance? Independent auditors are much more interested in how we comply with our own policies than whether these policies cover data confidentiality at all. I just fear that for the moment, this is a technically unsolved problem, much like controls around spreadsheets, our favorite elephant in the SOX living room.

But I digress. So Jim and I talked about the things which are easy to miss in an implementation of a detective control like Tablus. For example, I have a file system which I assign to a certain confidentiality level. What other instances of this file systems exist? Is this included in a regular backup, or in disaster recovery exercises? How is the data in these separate locations secured?

Which leads me to a concern about SOX. A company needs to compile a great deal of documentation for auditor review -- access control lists and rules, authorization schemes, network diagrams, processes for ensuring data integrity and nonrepudiation -- great stuff, and lots of it. Material that, should it fall into the wrong hands, could cause severe damage. While it's tempting to assemble all that material in one place for reference purposes, companies need to reflect on the potential threat models, and secure the data accordingly. Ideally, data should continue to reside in the organizations responsible for it -- root password rules with the sysadmins, for example -- so that the data can follow appropriate security rules. So yes, this will be more inconvenient for audit staff, but we can't compromise security for the sake of expediency.