At the present moment, Cornell Information Technologies (CIT) is slightly embarrassed to be dealing with a leak involving the personal records of 45,000 members of the Cornell community. Just slightly. Sadly, the pattern of how this breach happened is a common one seen in similar leaks. Some employee downloads highly sensitive data to an unsecured computer, a computer which later is stolen. The person who stole the computer may not even have known it had that data on it, but it does not matter. In addition to a major embarrassment, Cornell now gets to foot the bill to monitor the credit of 45,000 individuals, some whom are quite angry right now. This leads to the inevitable questions of why it happened and who is to blame.
Initially, many will have a gut reflex to blame the Cornell administration or CIT or as a whole. Blaming a large, nebulous entity makes one feel good by railing against the man, but in reality it does little to address the root cause. Cornell for one cannot be blamed for having lax policies; the employee who stored this private information on a non-secure computer had violated existing security policies. Ultimately, a single individual, not an entire department, caused this fiasco.
Of course, this does not mean CIT is off the hook. Although they have solid policies in place that, if followed correctly, would have prevented this, one must wonder what mechanisms exist to enforce this policy. While I can describe the ideal method to enforce these security policies, I have little knowledge about CIT’s existing practices, other than to say that the current practices in place did not work too well.
In designing any solution to this problem, it is impossible to build a completely secure system. Well, I guess once could design a system that always denied access to sensitive personal information, but that level of security would come at a price: no one could access the information, including humans or applications that had legitimate reasons to use this information.
Someone will have a good reason to access this information. Now if this person was trustworthy but decided one day to turn evil, no one can really do anything. These scenarios are nigh impossible to deal with. Nonetheless, while not all leaks can be stopped, one can still raise the bar high enough so that a person would have to perform some voodoo magic to create a leak. Thus, leaking sensitive data would require either malice or negligent disregard for security policies.
First of all, one can control which users can access this information. In smaller companies, it is surprising how easily accessible personal information can be. In many cases, this sensitive data is stored on the same database as non-sensitive data with the same level of security. Thus, developers who need to access the non-sensitive data can also access the sensitive data as a corollary. Good security mechanisms tend to use separate levels of permissions for sensitive data, granting access to a smaller, more trusted circle of developers.
As a tangent to this, one can also control how this information is made available to different users. I imagine a lot of people in Day Hall might need to lookup information for one person. In this case, a web application can indirectly expose this data to a user. For most users, this web application would only display the information for one person at a time. While one could still in theory reconstruct the file containing all 45,000 records by using this application, they certainly could not do it by accident.
Yet while many people might need the records for one person, few would need the entire file. Likewise, while CIT may have many issues to deal with, they probably have few issues that require an entire file of sensitive data to diagnose. Any issues involving the latter scenario would be escalated to a small, trusted group of developers. Said developers would have a much better awareness of privacy concerns compared to an average developer or Day Hall employee.
Controlling who has how much access to this information is only one part of the picture, though. Our culprit whose computer was stolen, for example, seemed to have a legitimate reason to need the entire file, as said person appeared to be fixing a bug regarding how an application processed the file. However, they did not have a legitimate reason to store that file on an unsecure computer. Even if the question of who can access the data and how it can be accessed is resolved, there still is a problem with where the data was stored.
Once a file is downloaded from the server hosting it to a secure computer, little can be done to prevent it from being copied from a secure machine to a non-secure machine. Nonetheless, one can still prevent a file from being directly downloaded to a non-secure computer. With little effort, the server with private data can be configured so that it rejects connection attempts coming from any machine that it does not trust. One can additionally add in a clear warning shown to users who do connect from a secure computer. The file can still be moved to an unsecure computer, but one has to first go through a secure computer and then ignore a flagrant warning not to move the file off the secure computer.
Such mechanisms to enforce security policies, while they do not cover esoteric corner cases, would force users to jump through hoops to violate security policies. Certainly nobody could claim they accidentally or careless created a security breach if it happened again. And while once again I do not know what CIT currently does to enforce security, I imagine that I have listed both some things which they already do and also others which they do not. Where good security policies exist, one also needs good mechanisms to ensure that said policies are followed.