Data Security and Boundaries

Data security is a problem for everyone, even for colleges and universities, as a recent post in The Chronicle suggests. Paul Voosen quotes Daniel K. Nelson, director of UNC-Chapel Hill's Office of Human Research Ethics, the team supposedly in charge on protecting sensitive data, "We're really just all waking up as a community to both the power and challenges of dealing with this." It is a serious issue, but I'm wondering if it is being defined correctly. If I take seriously what I've been reading lately about complex boundaries, then I know that I have to change how I think about data security.

It seems to me that data security has largely been framed in the simple or, at most, complicated domains according to Dave Snowden's Cynefin framework. This means that organizations have framed data security as a problem of enclosing well-defined, discrete data within well-defined, discrete boundaries, with well-defined rules for managing the exchange of that data across those boundaries with managed entities outside the boundaries. In this simple domain, the relationship between cause and effect is well known and explicit and people interact with the data according to best practices. This is something, I think, like the data in my checking account. That data is protected within strict boundaries, and the transactions, such as deposits, withdrawals, and inquiries, with that data follow well-defined best practices.

At least, that is how we define or frame the issue of protecting the data in my checking account. We want it to be a simple, airtight procedure, with reliable maintenance and audits of the data and reliable, verifiable exchanges between that data and the bank, my creditors, my employer, and me. The bank especially wants the process to be simple because it has millions of accounts, and it wants a simple procedure that it can reproduce and apply across all those accounts and rely on to protect the data in each account. Another way to say this is that we all want clear, inviolable boundaries around the data in my account, with well-defined and well-managed gateways through the boundaries that control the exchanges between the data on one side and appropriate stakeholders on the other side. This simple arrangement defines a simple system: my employer deposits data which I can use as money into my account regularly, the bank holds and protects that data, and my creditors appropriate some of that data regularly to keep my lifestyle going. The boundaries around the data protect the data and manage the interactions of the various stakeholders in this simple system. And by the way, it hardly matters if I stick to a strictly cash system. I move from virtual boundaries to physical boundaries (a safe or a weapon) to guard my data (money), but the relationships and boundaries retain pretty much the same functions.

Wouldn't it be nice if boundaries were really this simple? Unfortunately, they don't seem to be.

Rather, boundaries are complex. They are not merely complicated, which is just the simple multiplied with more parts and more gateways. Think of the complicated domain as a person (not me) with lots of data in lots of bank accounts with transactions among all those accounts and with all those various outside deposits, transfers, and withdrawals. The data security for this sort of complicated system likely requires much expertise to design and administer—not only  expertise from data security people, but also accountants and lawyers. Fortunately, my bank account is still in the simple domain, but I understand there are people whose numerous accounts are necessarily in the complicated domain "in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge, the approach is to Sense - Analyze - Respond and we can apply good practice." However, as with the simple domain, the complicated domain still has one or a few really good answers and practices, even if we often require experts to help us figure out what those answers and practices are.

The complex domain is different, for in this domain "the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe - Sense - Respond and we can sense emergent practice." These are the financial systems of gamblers (aka day traders) who have completely uncertain deposits, transfers, and withdrawals with uncertain stakeholders, and all within ecosystems or markets almost completely outside of their control. They can win much and lose much, but they can tell why only in retrospect. They can sense emergent practices, and experience can improve their chances, but they can never guarantee an outcome.

Of course, I think that all financial systems, just like all other systems, are complex. Only a long, stable economy can give us the illusion that our financial systems—such as my little bank account—are simple systems with regular, secure deposits and withdrawals and a set of clear, secure relationships among stakeholders: me, my employer, my bank, and my creditors. As the 2008 recession taught us, all accounts are complex, with uncertain transactions among uncertain stakeholders within an uncertain, dynamic financial ecosystem outside the control of anyone.

Likewise, data security is a complex system with complex emergent properties, and we will profit if we view it as a complex problem rather than a simple or even complicated problem. More on that tomorrow.