18 September 2012

Enforcing data security

By Andrew Clifford

You can improve data security by implementing fine-grained security at the lowest level of data access.

Most attempts to secure data are flawed because they rely on developers and administrators doing their job properly. Administrators apply security at the level of whole files or database tables. Inside applications, programs have access to the entire database and it is up to the developer to implement security rules. If the administrator or developer makes mistakes or are acting dishonestly the security of the data is compromised.

One way around this is to apply fine-grained, system-enforced security. Done right, this means that administrators can not grant access outside of the owner's intentions and developers can not introduce features that can be exploited.

I can give a real-life example. I have been working on a new feature in our Advisor software to hold page-specific user preferences. I developed what I thought was a working solution. The solution created an object for each user's preferences, and on this held user preferences indexed by the page to which they applied. The solution seemed to work well, and I could store and access page-specific user preferences.

When I tested the solution as a different user it did not work. The test page kept showing the first test user's preferences. I was momentarily stumped.

The solution did not work because it broke system-enforced security rules. Advisor has fine-grained rules about who can access which data. If you create data, nobody else can see it unless you grant them access, and you can not grant access to people outside your account. Page content is built under the authority of the owner of the page, and if you create preferences for a page owned outside your account (for example, a page in a shared question library), there is no way that the page owner can see or be granted access to your preferences.

Once I understood the problem it was easier to understand what I needed to do. Page-specific user data is a way for the user and the page owner to share user preferences for the page, but they can not pass data between them directly. They therefore need a trusted third party to act as a go-between. I developed a feature that stores preferences centrally and allows access to the preferences by either the user or the page owner. I set this up under the ownership of the global admin authority, who has the special authority to make features available to all users.

The in-built security stopped me accidentally creating something that could be exploited. Although it was frustrating at the time, the problems I hit forced me to think. The eventual solution is secure - it separates user preferences (which have to be shared) from substantive data owned by the user or page owner, and gives both parties only the minimum access they need to a shared area, using a trusted go-between.

Where data security is critical, a similar solution could work for you. The key parts of Advisor are that it passes all data access through a layer which enforces fine-grained data ownership and authority controls and that it limits how widely authority can be granted in the system. Could something like this improve your data security?