Many people have vaguely heard of deperimeterisation – ‘isn’t it something to do with getting rid of firewalls?’ is a comment I often hear. Actually, de-perimeterisation is a whole lot more that that – it will turn the whole security world inside out and it will take ten years, at least, to implement. So, what is de-perimeterisation? It’s the challenge that the modern world is throwing down to perimeter-based security – which perimeter-based security will fail to meet. The answer is collaboration oriented architecture. Let’s talk about perimeter-based security. This is the approach that most organisations (or at least, their security departments) want to take towards security. Perimeter-based security, as the name implies, is about securing perimeters. Perimeters are fences around valuable assets. In the physical world, a perimeter is a physical fence with one way through controlled by a guard house. Real organisations have nested perimeters – fences, rooms, safes. It’s the same in the IT world – a corporate network is protected by layers of firewalls, de-militarised zones and so on. In perimeter-based security, the bigger the perimeter the better. With a big perimeter you get economies of scale – you can get the biggest, the toughest and the best managed firewall. Also, you keep the attackers as far as possible away from the delicate assets. Perimeter-based security tends to like multiple nested barriers that are managed independently. And, policy administration, policy decision and policy enforcement tend to be done in the same place. It’s designed to be difficult – who says that valuable assets should be easy to get at? Is perimeter-based security good? That depends on what you want. It’s easy to understand and verify; access policies, and their administration, tend to be simple; and, at least in the abstract, it works well. So why change it? The problem is that, in modern organisations, it’s very hard to find any form of meaningful perimeter to protect. Companies merge and de-merge, form joint ventures, and outsource critical processes; employees are replaced by contractors and home-based users; core systems are accessible on the Internet; and everyone wants to be able to access everything from the airport. In the modern world, perimeter-based security:
- Is infrastructure oriented, not business oriented.
- Leads to policies that are inflexible, and hard to keep up to date with reality.
- Leads to coarse grained access policies that do not do what the stakeholders want.
- Perimeters should be built around the assets; the smaller they are, the better.
- Access policies should be fine grained and business oriented. To see what I mean by that, a perimeter-based access policy might say ‘I want users Fred, Jim, Bert and Alec to have read access to folder C:\HR\Database\Promotions and I want user Alice to have read-write access to it’. In a collaboration oriented architecture I would be able to say ‘Information about promotions is covered by the Data Protection Act’ and leave it at that.
- Policy administration, decision and enforcement should be separable. To use a physical analogy, if I have a single office with a single fence and a single guard house, it’s not very difficult for me to make a trip to the guardhouse once a year to tell the guards who they should let in. But if I have a billion data items, each with its own fence and guard house, it’s not practical for be to go around and specify who should be given access to each one. Rather, I should be able to work out in my office what my access policy is and for the system then to work out what assets it applies to.
- Security decisions should be separated from business logic. And, in the general case, they may have to incorporate not just interpretations of encoded policies but also negotiations between stakeholders (where it’s not possible to encode policies in advance).