Designing For Security -Security Patterns

Introduction & Reasoning

We’ve all heard of, considered and know what a Design Pattern in software is. Or do we? Software design patterns were really made famous in 1994 by the gang of 4. These patterns provided the bedrock of many different software design patterns that we use in software today. Steve McConnell advanced the idea of software patterns in his book Code Complete. The majority of these patterns can be classified into several major categories:

• Creation Patterns
• Structural Patterns
• Behavioral Patterns
• Concurrency Patterns

However, there seems to be a fundamental category missing, Security Patterns which is going to form the basis of a new series I am working on. Security patterns themselves aren’t that new, the first idea of a security pattern came out in 1993 prior to really recognizing the whole concept of patterns in software. There was some more work done on security patterns in the late nineties, however idea, formalization really took shape in 2007 and later. One might argue that 7 years is a really long time, however within the confines of the Internet & computing, it’s really not that long. I am going to examine how to build various patterns, building up a secure framework for a variety of different patterns and ideologies.

What is a Security Pattern?

Descartes said – Each problem that I solve becomes a rule which served afterwards to solve other problems

In a sense, Descartes was right, and when thought about and applied to the context of security, Descartes was right on the money, every time we solve a security problem in our systems, securing a front end, protecting data, preventing defacement, the manner in which we do it can be used as a pattern in the future to prevent similar kinds of abuse against our systems.

I say, security patterns is still a young and emergent topic is there is much debate on what exactly a security pattern is and how to classify a security pattern. Thomas Heyman published a paper in 2007, where he analyzed about 220 security design patterns but ultimately concluded that only 55% of them were core security patterns. In 2011, Munawar Hafiz published a paper of his own. Where he concluded that there are approximately 96 core security patterns. It’s also unclear how many security patterns have been actually designed and published, because of the likeness of a security pattern to an architecture, it stands to reason that some patterns could have easily been mis-classified.

A Security Pattern can be thought of as a type of architectural pattern. These are really similar in scope, because architectural patterns deal with global issues within your application, if you’re not thinking of security as a global issue in your application you’re doing it wrong. A security pattern is not a security principle, every security pattern should attempt to fulfill as many security principles as possible, however that will be discussed later. While a security pattern attempts to fulfill a security principle, security principles in general are to broad to be considered a pattern in of themselves.

I am not going to authoritatively define what a security pattern is for you; I’ll defer to the academics in the field to ultimately say yes or no to any particular pattern. However for the purposes of this series, here is my simplified idea of what a security pattern is. A security pattern is – A tool for capturing expertise & managing a prescriptive complexity, of security issues, while furthering communication by enhancing vocabulary between the security engineer and the engineer.

To that end, I firmly believe that a security pattern should do the following:

1. Describe technical solutions in context of business problems
2. Check essential Security Properties
3. Extend normal design patterns to security where these patterns come up short
4. Provide conclusive security architecture to the application architecture

What Goes into a Security Pattern?

Viegra and McGraw came up with a list of 10 principles that every application which wants to be secure should attempt to fulfill. They are:

1. Secure weakest link
2. Practice defense in depth
3. Fail securely
4. Principle of least privilege
5. Compartmentalize
6. Keep it simple
7. Promote privacy
8. Hiding secrets is hard
9. Be reluctant to trust
10. Use community resources

If an application can achieve these 10 principles, then it’s reasonable to say that the application is pretty secure against unwanted attention and hacking attempts. Security patterns attempt to help an application become secure by fulfilling some of these principles , some security patterns fulfill one others fulfill more. The obvious question that one has to wonder now is:

Well, which security pattern do I use?

The answer is a bit complex, keeping in mind that just like with design patterns, there is no single pattern that can be used to solve all your problems simultaneously. There really is no security pattern that meets all 10 of these principles and an engineer or developer can now employ and say yes the application is secure. Nor should an engineer/develop ever say I think we’ve covered all 10 of these principles and therefore our application is secure. These principles are a guide, and should be used in conjunction with other tools such as threat modeling and penetration testing. It would be easy to say our authentication mechanism fulfills all 10 principles. But we failed to secure database access, or there is a cross site request forgery vulnerability in our application.

Therefore with regular design pattern approach, it’s imperative when using security patterns to build one pattern in one particular area of the application on top of another. For example, one might use a Single Access Point pattern to manage the authentication of their application and it would be an appropriate choice. However, what about authorization? Therefore, it would be more appropriate to use the Single Access Point Pattern for authentication and then defer to Check Point, access pattern for authorization within the application itself if you’re application imposes authorization rules/roles. What you’ve successfully done at this point is build one pattern on top of another pattern to make your application much much more secure. Now if your application doesn’t use authorization or authentication, my example becomes a mute point, however I am sure there are other security patterns that would be appropriate to be considered.

As I explore different patterns implemented with different code samples, I’ll also dive into the different principles mentioned above that each security pattern attempts to fulfill to help the application engineer, architect design the most robust secure system they can.