Security Patterns - Just another Way to Share Best Practices?

SAP Developer Network E-mail This Document

Summary

In this article I outline a typical problem that many people have with security. It should be a mandatory feature, but there’s not enough time or know-how to get it right. A pragmatic approach could be to avoid at least the basic, well-known problems. This is where security patterns can help – they capture proven solutions for recurring security problems. After a short introduction on what security patterns are exactly, I discuss the potential of writing and using patterns.

By Markus Schumacher
19 Dec 2003

 

Introduction

The steadily increasing number of reported security incidents indicates that organizations need additional help in addressing basic security issues that range from enterprise plans to software systems to operational practices. However, there seems to be a gap between theory (“security is mandatory.”) and practice (“security as nice-to-have feature – if at all.”).

In general, security is not adequately addressed in enterprises and the systems that they build and operate. One reason is that security covers a broad area and it is a big challenge to define secure business processes and to develop and operate the corresponding systems and applications securely. The situation is becoming more challenging because of the increasing openness of systems and enterprises due largely to the rise of the Internet, e-business, and Web-service technologies. Especially in distributed environments it is very difficult achieve security, as there are many different organizations, individuals, technical components and mechanisms involved. In addition, trust relationships change frequently, which makes an analysis of all security requirements very hard. As modern e-business processes become more and more complex, the overall problem space is no longer easily comprehensible for the people involved. Or to say it in the words of the security guru Bruce Schneier: “complexity is the worst enemy of security”. More specifically, there are three issues:

  1. Security is often an afterthought in system design and implementation. The enterprise context and requirements that drive system security are not addressed explicitly, and are not incorporated into system architectures. What is needed is to begin addressing security up front rather than the “repair-service” approach we observe today.
  2. Many security breaches can be traced back to well-known security problems, which continue to appear over and over again. Default passwords that are documented in the software manual are one example. Logging sensitive information on a public Web server is another example. These are manifestations that security is being given a low priority, or of a lack of understanding of security issues. The dominant goal in these cases is to enhance functionality, usability and performance, not to mitigate risk.
  3. Enterprise planners, system architects and developers, and operations managers have inadequate knowledge of security; even basic security concepts seem to be alien to many people. As a consequence, they rely heavily on security specialists to understand their security needs and to provide security solutions. However, there are not enough security specialists to satisfy the need. Furthermore, in many cases, the security specialists find themselves repeating the same solutions for each enterprise or each system development project. This is an unnecessary waste of their time, and keeps them from addressing more complicated problems.

Learning from our mistakes plays an important role in every successful design - it would be great if we could apply this to the security learning process too. One key to a solution is that, while many security problems are new or complicated, a significant number of basic security problems in an enterprise context are well understood, and well-established solutions to those problems exist. Over time, the security specialists who have encountered the same basic problems and found themselves repeating the same basic solutions have developed a good understanding of these problems and solutions. To some degree, these have been captured in the security literature and in security-related standards. But the knowledge codified in the literature and standards is not readily accessible to those who do not devote all their time to security.

Security Patterns

Security patterns follow the approach of applying the idea of patterns, which are an established software development technique, to security problems as characterized before. Patterns offer a systematic way of capturing solutions to commonly occurring problems.

One could say that they are just another approach to documenting security stuff. That’s not necessarily wrong, but real patterns have differences. First, patterns are based on field experience; they are not about nice but theoretical problems. Second, they are relevant as they are written by (or at least under the guidance of) experts and offer the best available solution to real-world problems. Third, they are accurate as they are reviewed and validated by experts. Finally, they are generative, that is they help to build or create a solution and show the steps to a successful implementation.

Christopher Alexander, who first laid the foundations of the pattern movement developing a pattern-based approach to architecture, says that “each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.” In the following, I briefly introduce these key elements tailored for security patterns.

Noun Phrase Name

The name of a pattern should be evocative and “conjure up images which convey the essence of the pattern solution to the target audience.” Ideally, it should be possible to use the names in conversations. A common approach is to use noun phrase names, for example, you name the pattern after the result (for example a design, a piece of code, a configuration, a process, and so on) it creates.

Context Description

The context of a security pattern describes the general environment and conditions under which the problem occurs. In order to illustrate the context of the pattern, references to concrete examples should be provided. Analogies to real-world scenarios are also suitable. For example, the analogy between a medieval town and firewall technologies is sometimes used in order to explain situations in which problems can occur. It can also help to show where you came from, to list patterns that address problems you assume to be solved in advance. Such references might be required to assure that certain requirements or assumptions hold.

Problem Statement

In certain situations, you’ll find yourself in trouble. In other words, there will be a security problem that has to be addressed somehow.

In the field of security a problem occurs whenever a system component is protected in an insufficient way against misuse or there is a situation that may allow security violations. Generally speaking, we have to deal with generic threats, or a potential for the violation of security. In particular, we have to think about concrete attacks that exploit vulnerabilities and may lead to severe security violations. When you specify the problem, it helps to model the threats relying on the suitable modeling technique (the technique that is familiar to the target audience). Recently, new attack modeling approaches have been identified, such as attack trees, misuse cases or UML security extensions.

As a person in trouble you must take different considerations into account when you have to choose a solution to the problem. This is achieved by discussing so called forces where the relative importance of the forces is implied by the context (for example, performance is more important than usability). This reflects the fact that every security solution presents a certain trade-off and some forces are optimized at the expense of others.

The Proven Solution

The solution solves the problem. In fact, that sounds simpler than it is. Good solutions resolve the highest priority forces as determined by the given context in the best way. Ideally, you relate the description of the solution to the forces. That way, the reader of a pattern is in a position to understand why this solution was chosen.

When you have explained the core of the solution, you should provide guidelines for the implementation of the pattern. These are only a suggestion, not an immutable rule. As a pattern author you should adapt the implementation to meet your needs, by adding different, extra, or more detailed steps, or by re-ordering the steps. Whenever applicable, UML fragments should illustrate a possible implementation. That way authors can describe concrete processes, structures and dynamics of the solution. They can also refer to further patterns that are required to implement the solution. Another important issue is to present known uses of the pattern. There is an unwritten rule that there should be at least 3 known independent occurrences of the pattern.

Security never comes for free. You have to find a trade-off. Thus it helps to discuss the consequences of applying the solution. That way, the pattern reader is able to consider unforeseen side-effects and how security affects other requirements. Usually, patterns don't exist in isolation. There are relationships to other patterns. For example, there are other solutions to the same problem in a different context, more general or more specific variations of the pattern, and patterns that solve some problems that arise after the application of the pattern (in the resulting context). Such relationships provide links to subsequent patterns of a hierarchical collection of patterns. That way, you can address different target groups in a uniform and integrated way.

Discussion

Ross Anderson, widely recognized as leading security engineering authority, once found out that security is not a technical problem and that the technicians have to consider the human factor appropriately. He concluded that “a paradigm shift is underway, and a number of recent threads point towards a fusion of security with software engineering, or at the very least to an influx of software engineering ideas.” I’m confident that the pattern approach represents such a paradigm shift.

In summary, the purpose of security patterns is to capture some of these basic problems and solutions, and make them available in a form usable by enterprise planners, system architects and developers, and operations managers. In particular, security patterns can be used when the people responsible for enterprises or systems have little or no security expertise. They can now address basic security issues themselves instead of depending on security specialists to perform this for them each time. The security specialists can then be free to help them solve the new or the more complicated security problems.

There are some open questions and there are some answers.

For example, what is the potential of security patterns? First of all, we can expect that security patterns reduce project costs as you can systematically reduce the overall risk and can achieve more predictable results. That way, you also reduce the time-to-market as you have easy access to expert know-how. Second, patterns increase confidence of both customers in a product as the developers rely on proven, tested solutions. Finally, security patterns also lead to a competitive advantage for companies as their developers can focus on the “real” problems assuming that you have now a tool to handle the trivial problems effectively.

Do security patterns come for free? Certainly not. For example, you shouldn’t underestimate the effort of documenting and reviewing the patterns. The first issue requires a lot of discipline as practitioners usually don’t like to explain what they do (particularly not in an understandable way). The second issue is that you have to find other experts that are able to review and approve patterns. Note that you also need a significant amount of patterns in order to make them useful for the reader. Even if you have achieved that you still have to convince the “target audience” to use the patterns, to contribute to their improvement, and finally to contribute to the overall pattern repository that reflects the common sense in the field of security. Today, security patterns are discussed in dedicated workshops at conferences of the pattern community (people from academia, self-employed people, and employees of companies). By exchanging security know-how that way, patterns could be a chance to establish something like a common security standard between companies such as SAP as well as their partners and customers.

Are patterns over-hyped? Well, patterns are certainly not a panacea. Sometimes there are no proven solutions available. Sometimes you cannot show that the solution has been applied in more than one situation. Sometimes there are problems with no applicable solution.

Who is already involved in security patterns? There are several groups working on and with security patterns. Companies such as Computer Associates, Microsoft, and Cap Gemini already offer and use security patterns for their customers. Besides, there are communities that work on patterns (information about these activities can be found on the security patterns homepage).

A final thought - remember Bruce Schneier’s statement that complexity is the worst enemy of security. He also said that “there’s no other way to handle the complexity than by breaking it up into manageable pieces.” That’s exactly what security patterns do.

References

  • Christopher Alexander. The Timeless Way of Building. Oxford University Press, 1979.
  • Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A Pattern Language: Towns – Buildings - Construction. Oxford University Press, 1977.
  • Ross Anderson. Why Cryptosystems Fail. In 1st ACM Conference on Computer and Communications Security, ACM Press, 1993.
  • Doug Lea, Patterns-Discussion FAQ, http://gee.cs.oswego.edu/dl/pd-FAQ/pd-FAQ.html
  • Gerard Meszaros and Jim Doble, A Pattern Language for Pattern Writing, Pattern Languages of Program Design 3, Addison-Wesley, 1998
  • Markus Schumacher, Security Patterns – Origins, Theoretical Model, New Applications, Lecture Notes in Computer Science (LNCS 2754), Springer Verlag, 2003
  • Microsoft, Patterns & Practices, http://www.microsoft.com/resources/practices/
  • Henry Petroski, To Engineer Is Human: The Role of Failure in Successful Design, Vintage Books, 1992
  • Bruce Schneier, Secrets and Lies - Digital Security in a Networked World, John Wiley & Sons, 2000
  • John Sluiter and Aaldert Hofman, Shorten your Time-to-Market with Security Patterns!, Information Security Bulletin, CHI Publishing, 2001
  • Joseph Yoder and Jeffrey Barcalow, Architectural Patterns for Enabling Application Security. In Proceedings of the Conference on Pattern Languages of Programs (PLoP), 1997.

About Markus

Markus studied Electrical Engineering and Information Technology at Darmstadt University of Technology (TUD). He has a Ph.D. degree in Computer Science. Prior to working with SAP, Markus was director of the IT Transfer Office (ITO), an associated research center of the TUD, Department of Computer Science. ITO is working on applied research projects with partners from industry, e.g. SAP Corporate Research in Karlsruhe. Markus also hosts the security pattern community’s homepage (http://www.securitypatterns.org) and is editor in chief of the first book on security patterns in Wiley’s pattern series. The team of editors and authors aims to publish the book in summer 2004. He joined the SAP Product Security Team in December 2003.

Copyright © 2003 SAP AG, Inc. All Rights Reserved. SAP, mySAP, mySAP.com, xApps, xApp, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product, service names, trademarks and registered trademarks mentioned are the trademarks of their respective owners.

SAP Developer Network E-mail This Document