Secure or useful: pick one

December 18, 2009

A great deal of time, pragmatic security involves striking a balance between actual security and usefulness. The more secure you are, the less useful you are; the more useful you are, the less secure. Here, I am taking a broad view of 'useful', one that encompasses not just things like features but also how easy your system is to use, and how much the security gets in the way.

(Sometimes, very rarely, this is not the case. When this happens, celebrate and take full advantage of it.)

There is no single right answer to where to strike this balance; you have to make a tradeoff based on your environment, your risk factors, and so on.

For example, the consider the tradeoffs involved in having shared filesystems and common logins across a group of somewhat disparate machines. Users really like this and it makes your environment much easier for them to use, but it drastically increases the worst-case results of a compromise, especially if you are cautious about security; with everything in one security domain, you have to assume that all of the machines are compromised if any of them is.

So, do you use shared filesystems and common logins, or do you isolate machines and force users to copy things around by hand (probably typing one-time passwords in each time)? Clearly it depends. In many environments, you share and probably are less paranoid when a compromise happens; you tilt towards usefulness and away from absolute security. In some environments, things are sufficiently important that you isolate and protect very strongly, tilting the balance the other way.

(Bearing in mind that security is people, you need to be careful not to wind up being so useless that people work around your security in order to get things done.)

Written on 18 December 2009.
« The good and bad of SQL
Local CAs and an interesting consequence of the SSL security model »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Dec 18 01:24:02 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.