By Razvan Peteanu (razvan.peteanu@home.com) for SecurityPortal
June 11, 2001 - When The Gang of Four's Design Patterns [2] came out in 1994, it quickly became a classic. Its publication marked a moment of maturity and thought crystallization in software development. The book and its follow-ups have been a great source of inspiration and advice to any architect who had an analysis document (if lucky), started up the favorite modeling tool and then stared at the blank screen with the UML icons by it, wondering which of the ideas simultaneously floating in the mind should be modeled first.
Traditionally, security has been behind development in terms of resources: there are way more programming books than security books, universities still teach several languages but little about security, and the list can go on. There is a fair amount of information now about what not to do in order to avoid a security disaster, but what to do in order to get it right when you do have the chance of starting from scratch? The Design Patterns book has been followed by a stream of other works, but was there anything similar for the security architect?
It turns out there has been, and for a few years already, not on the mainstream security sites but hidden in a (excellent, by the way) research site, ResearchIndex. When I found Yoder's and Barcalow's paper there, I had some initial apprehension: much as research is critical, a paper with many Greek letters and symbols recalling university exams is not likely to be immediately useful in the design of the next e-business-portal-wireless-m-commerce-whatever due in 3 months. However, the paper is a down-to-earth catalogue of design patterns with excellent examples and an overall quality indicating previsions must have existed.
Let's look at some of the patterns described and how they relate to the real world:
The Single Access Point represents, as the name suggests, the one and only allowed path into the system. It exists because a commonsense approach to managing complexity: it is much easier to control a single entry & exit point into the system than several or dozens. By no means is it something invented by security professionals: the first people who built a fence around their land and watched the gate were instinctively applying the same pattern.
The Internet connection of most companies reflect this pattern: all traffic goes in and out through a single point. "Easy to control" would think the defender. "Easy to attack" would smile the aggressor and indeed, the Single Access Point becomes the Single Point of Failure if the attack is not targeted against the infrastructure beyond it but against the "gate" itself. Does this mean the pattern is useless? Not at all. A pattern is not supposed to be a panacea. One point still is easier to protect than a dozen.
What defenders need to carefully consider though is how resilient the gate itself is, how monitored it is and what the behavior is when the gate cannot keep up. Resilience of and trust in the Single Access Point is critical for the entire system: if the gate doesn't do its job, it's even worse then no gate at all because the users will assume they are protected when in fact they are not. Monitoring the gate ensures any incidents involving the gate itself can be identified and dealt with in time. This means multiple systems of checks (all buildings with security staff also have video cameras monitored by other staff). It also means applying defense-in-depth techniques: implementing the conceptual Single Access Point as a chain of access points, layered physically or logically, that would allow the defenders to isolate the system if the first layer is broken through. And finally, the gate should have a fail-safe behavior: if the conditions are such that the gate can no longer correctly control the traffic, it should lock itself in a state in which all traffic is disabled (as opposed to letting all traffic through).
I'll confess to fudging the meaning of "access" in the above paragraph: I've started with using 'access' as a right of entry/use and then continued to talk about access as provision of a service. While linguistically different, in the IT world they often merge into the same entities like the Internet connection in the example. And assaults against the access points themselves are not at all unheard of: one of the Denial of Service attacks Microsoft experienced earlier this year was directed against the border routers. By flooding the routers, regular traffic through them was affected as well, practically rendering the sites inaccessible.
One interesting twist to the Internet connection as a single access points is brought in by the deployment of wireless networks. The traditional access point is both a single-entry, single-exit point. A wireless LAN, while potentially still having a single entry point (the gateway), it has many exit points: any transmitter in the network broadcasts to the entire world around. The solution is to turn the physical access point into a virtual, information-based, access: by encrypting the traffic, the access is now controlled through the knowledge of the decryption key. This brings its own share of challenges, but I should stay focused on what this text started to talk about.
The Check Point is a tightly related pattern: if the Single Access Point is the Internet connection, the Check Point is the firewall (nota bene: no pun or no covert advertising here). While the S.A.P. is the place, the Check Point is the policy that is enforced at that point. Passport control, packet inspection, a login page are all examples of applying the pattern. Needless to say, a correct behavior of the Check Point is paramount for the security of the system. In real life, attacks against this pattern consist of brute force, forgery or bribe. While it's harder to bribe a firewall (but wait until artificial intelligence will be used here :-), the other two attacks are common: under extreme stress, the algorithm or simply the implementation of the Check Point mechanism may break. In the streets we see drivers trying to break through a police filter by speeding up. As far as the forgery goes, well, spoofing network packets comes to mind before the time needed to read this sentence. Spoofed packets attempt to bypass the control point by confirming to the existing policy and not by breaking it. This is useful to note: if a spoofed packet can bypass a firewall but still do harm (i.e. still be different from a regular packet), that probably means the firewall policy is not good enough. Since the policy mechanism is ultimately implemented with software, a vendor's quality assurance practices directly impact the resilience of Check Points
Roles are a third design pattern that comes to be very handy in managing access control lists. ACLs are used in many places, from the straightforward file permissions to controlling privilege levels in a bank. A typical ACL links a resource (like a file) to a number of principals (users and groups) and, optionally, to a set of operations. As the system grows both in size and complexity, managing ACLs becomes harder not from a technological point of view but from a human & business standpoint. If a file can be accessed by John Smith, Danny X, Christine Y, Peter T, Sven S and 20 other users plus 3 groups, it becomes very hard to understand the permissions assignment (by what virtue are these users allowed to access the file) and to spot any mistakes. The introduction of Roles decouples the specification of ACL's from end users and groups. If access to a particular file is granted to the BoardMembers role, than managing who is granted the BoardMembers role is easier and also more controllable. Associations between resources and roles would be rather static, leaving a single, more dynamic, relationship -the association between roles and principals- to be managed. If you look at it again, it is nothing else than another implementation of the Single Access Point pattern, perhaps more appropriately named here as Single Place For Doing The Work.
There often is confusion between roles and groups. To some extent, it is understandable, groups can do some of the tasks roles do. However, they are not exactly the same. Groups are primarily intended to manage users, not access control entries. A group is ... "a group of users". If a group is created in order to be manage access to a resource, than it starts to look like a role. Which is acceptable in environments where roles per se are not supported. A technology that clearly distinguishes between the two, though, is the Entreprise Java Beans. The EJB specs indicate that access to a particular enterprise bean or method is granted to a role, an abstract name that by itself doesn't mean anything more. The role-based access control list is specified in the deployment descriptor, ejb-jar.xml. The second half of the task, mapping these abstract roles to real users and groups, is left to the application container. (By the way, the lack of standardization here, while allowing flexibility for implementation, is responsible for the non-portability of EJB security across application servers).
The Session is a concept that should be familiar with anyone doing web development, although it is worth noting that not all HTTP authentication mechanisms necessarily use sessions. For instance, Forms Authentication does: after submitting a username and a password, the client browser is given a SessionID either through a cookie or through URL rewriting that is the "badge" proving the authentication. Basic Authentication, however, does not employ sessions and thus the credentials need to be sent to the server at every single HTTP request.
While HTTP Sessions are the typical example, the same concept is implemented by operating systems as well. When a user logs on, a session is created by the OS that will be used for authorization and auditing. An excellent coverage of Windows login sessions, for instance, is provided in Keith Brown's book [3]
There are other patterns discussed by Yoder and Barcalow but we won't dwell into them at this time. If the above has interested the reader in the topic, then do read the original paper, it is better than this quick introduction. On the other hand, the author would be interested to hear if you identified other patterns, perhaps the original collection can be improved and extended.
Joseph Yoder and Jeffrey Barcalow, Architectural Patterns
for Enabling Application Security,
http://citeseer.nj.nec.com/yoder98architectural.html
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addison-Wesley Pub Co, ISBN: 0201633612
Keith Brown, Programming Windows Security, Addison Wesley Longman, Inc, ISBN 0201604426