Mitch has written a long series of articles (1, 2, 3, 4) on "why network security sucks", and what his proposed solution is. It's difficult to summarise four long blog posts down to just a couple of lines, but I'm going to try anyway. My summary – Mitch is espousing the usual litany of user complaints:

  • Too many identities need to be managed by the user in order to work effectively
  • It's difficult and time consuming to get access to the resources that are required to do the job

I agree wholeheartedly that network security can definitely be improved to provide a better and smoother experience for the end user. At the moment it is too difficult, and too cumbersome in many organizations to get access to resources. What I disagree with are Mitch's proposed solutions. The solutions that Mitch proposes are:

  • Make getting access work a little like Sharepoint. When you're denied access to something, allow the user to email the owner asking for access.
  • Understanding that Authorization is more important than Authentication per se. If the user can supply a digitally signed authority to perform the action, then they should be able to perform the action
  • Better support for delegation across the Windows platform, to make easier to support hierarchies of delegation (so as to allow a user to speak to their boss rather than having to speak to central IT to get access to something)

Mitch's Solution #1 The Sharepoint Solution
I'll leave aside the point that this solution already exists – you just email central IT asking for permission. Obviously this doesn't work for most users.

The real problem with Mitch's proposed solution is that it's too narrowly focused. It aims to make it easier for a user to gain access to a resource, but that's all. It's all about the individual user, and not the network as a whole.

The aim of giving users access to resources quickly is admirable. However network security is much more than that. We need to be able to determine, at any time, what the "state of play" is (i.e. determine what the effective permissions currently are), and we also need to be able to take away permissions. This is because network security is about ensuring that all authorised users have access to the resources they should have, and ensuring that all non-authorised users do *not* have access to those resources. So when an employee changes position we need to be able to work out which permissions they should keep, which additional ones they should be granted, and which ones should be taken away. And the more people you have changing permissions all over the network, the more difficult this task becomes.

This problem is summarized in general by the statement that complexity is the bane of security (I pinched that statement from Bruce Schneier's Secrets and Lies book, but it's also #8 on Microsoft's 10 Immutable Laws of Network Security). Complexity can come in many forms, for example: too many systems, too many processes or too many people making changes. Note that I didn't say "lots of people making changes" but rather "too many". When do we get from "lots of people making changes" to "too many people making changes"? When the resulting complexity is no longer manageable by the people charged with ensuring that the network is secure. Those people generally are the central IT unit. When they can no longer quickly determine whether everything is configured correctly and securely, then there's too much complexity and the risk that the network is no longer secure. How do we make it manageable? By using the correct tools, which I'll go into when I get to my section on solutions.

Mitch's Solution #2: The Signed XML solution
In Mitch's words:

The act of authenticating someones identity is certainly important, but when it boils down to it is the specific authority granted to an individual that counts. In fact a resource doesn't even really need to track the authority levels of individuals. Imagine a scenario where when trying to access a resource that you are challenged to provide evidence that you have the delegated authority to perform the operation requested. Rather than providing some authentication token, you (initially) provide a blob of XML which shows the delegation hierarchy from the resource to the system administrator to the business owner, to the mid-level manager and eventually down to you.

The only thing that the resource would need to know is who it delegated complete authority to in the first place (typically the installer). Then that person can sub-delegate as necessary without even informing the resource.

There are a few issues I see here. Firstly the user needs some method of managing all these bits of XML. Assuming we can overcome that, it seems ludicrous to me that an untrusted client can assert permissions to resources, rather than have the server consult a trusted list of ACLs maintained on the server itself.

Assuming we can get around that issue though, the biggest problem with Mitch's proposal is that it doesn't do anything to solve the problem. It presents exactly the same problems we have at the moment. Let's compare Mitch's proposal to what we have now:

Current/TraditionalMitch
User wishes to perform a privileged actionUser wishes to perform a privileged action
User presents authentication credentials to server (password, smartcard, fingerprint etc)User presents signed XML to server
Server consults ACL list to determine is action should be permitted or deniedServer consults Revocation List to determine if the XML is still valid, and that whoever signed the XML still has permission to delegate authority, and so on all the way back up to the original issuing Authority
Server permits or denies accessServer permits or denies access

In both cases the user needs to present some kind of token - whether it be "something the user knows" (a password), "something the user has" (smartcard/certificate, bank ATM card, signed XML), or "something the user is" (fingerprint).

In both cases the server needs to consult some kind of ACL (either in the traditional sense, or a revocation list to determine whether the signed XML is valid).

In both cases the user needs to get permission from someone who has the ability to grant that permission. In the traditional sense, the business owner would add the user to the file share's permission. Under Mitch's proposal the business owner would need to generate the XML.

The problem with Mitch's proposal is that unless there is some central store that records all the different bits of XML handed out, it's impossible for Central IT (or their security group) to actually known what the current effective permissions are for the enterprise, and that makes it very difficult to know whether we're in a secure configuration or not. And once we introduce the central store of permissions, we're right back where we began. We haven't actually advanced anywhere.

This discussion is continued in the next posting...