Capping IT Off

Capping IT Off

Security Access Permisisons Considered Harmful

Category :

Look at the way we set up access permissions today on, say, a windows file. We go into a form and state the exact users and files that will have permission for the file. If we want to set the same permissions on a different file, we have to go through the whole process again, manually. At home, I have an XP PC, a Vista laptop, a Mac laptop and a network storage drive. My XP PC has 3,000,000 files on it, each file must have its permissions set correctly; my other computers are similar. I have many other applications that control access to my information, not to mention web sites. I have a Capgemini laptop, of course (actually, I’ve just remembered, I have two). Then I have my desktops at client sites; that’s without even starting to think about the clients’ infrastructure. I have no idea whether my security setup meets the Data Protection Act, or whether it’s sufficient to meet the threats that are out there. In the unlikely event that, by some random chance, I’ve got everything right, if the threat changes, or the interpretation of the Data Protection Act changes, then I’m back to the beginning again. This should give you some idea of the scale of the security problem we all face. The response we are forced to take, that is, setting access permissions, is rather less powerful than assembly programming. There must be a better way. Ideally, I would want the following:

  • The capacity to specify an access policy that applies to many different objects simultaneously.
  • The capacity to specify an access policy in a single place in a single style, which is then interpreted consistently by many different applications and locations.
  • The capacity to offload security policy setting into the cloud – security as a service.
The good news is, this is now a possibility. The new XACML v2 standard from OASIS describes how a security policy decision point can be separated from the policy enforcement points; along with protocols for them to talk to each other, and a language for specifying rich security policies. The bad news is, support for XACML v2 in real-world applications is still pretty patchy. I hope I have now explained why security access permissions, as currently implemented, cannot hope to solve the security problem, and justified the provocative title of this blog entry. XACML-style rich policies are, I believe, a crucial component for building a collaboration-oriented architecture and meeting the de-perimeterisation challenge.

About the author

jarnold
2 Comments Leave a comment
I agree that the movement towards XACML would be a good one, but v2 has been in existence since 2005 and we're awaiting something close to GTRBAC flexibility in v3, and hopefully something implementable in v4 - there's a long ways to go yet.
I wrote my dissertation on GTRBAC flexibility using Sun's XACML and found the date processing to be wanting, but there's a terrific foundation there which could easily re-make a filing system into a very useful and secure file server.
instead of waiting till for instance Microsofts implements XACML as the default, one could opt for storing everything online using for instance Amazon's S3 file storage system.
the disadvantage with these online solutions is that you have to deal with the vendor's own layer of security but it does work cross platform.

Leave a comment

Your email address will not be published. Required fields are marked *.