1.
Security Patterns:
Overview and Best Practices
for Securing Enterprise Systems
SEIS 720: Computer Security
Dr. Brad Rubin
Brian Machart
December 10, 2014

2. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
SEIS 720 –Computer Security Brian Macharti
Table of Contents
Abstract..........................................................................................................................................ii
Introduction................................................................................................................................... 1
Security Pattern Definition .......................................................................................................... 1
Security Pattern History............................................................................................................... 2
Misuse & Attack Patterns ............................................................................................................ 4
Benefits, Best Practices, & Recommendations........................................................................... 5
Conclusions.................................................................................................................................... 7
References...................................................................................................................................... 8
Appendix A

3. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
SEIS 720 –Computer Security Brian Machartii
Abstract
Security patterns were introduced in software design in the late 1990s. These patterns provide
proven solutions to reoccurring security problems following a template format, like the “Gang of
Four” design patterns, that is understandable to the expert and novice developer. Security
patterns assist system designers in providing security against attacks to increasingly complex
enterprise system. Their use in design should strongly be considered a requirement in enterprise
applications that can reduce the long-term costs of the system and provide security continuity.

4. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
SEIS 720 –Computer Security Brian Machart1
Introduction
Enterprise systems are complex. They often consist of multiple applications on a distributed
across a network and connected to the Internet. Access to the system may be through a multitude
of devices on- or off-site. Due to this complexity, the systems are difficult to develop and
maintain. In their design, end-to-end security often is not the primary emphasis. With such a
gargantuan task at hand, security patterns provide an aid to those IT professionals who may or
may not be security experts.
Security Pattern Definition
Before any arguments can be made regarding security patterns, a widely accepted definition of
what exactly a security pattern is must be stated. According to Schumacher et al., “a security
pattern descries a particular recurring security problem that arises in specific contexts, and
presents a well-proven generic solution for it. The solution consists of a set of interacting roles
that can be arranged into multiple concrete design structures, as well as a process to create one
particular such structure.”[B1,p.31]
While security patterns developed following the “Gang of Four” design pattern template [B2,
p.30], Fernandez recently added additional objectives. The following details this template:
• Pattern Name
• Example
This is an example of a problem situation that this particular pattern may provide a
solution.
• Context
This is the context in which the pattern is applicable.
• Problem
This is a general description of the happenings without a good solution and the forces that
affect a possible solution.
• Solution
This documents the idea of the pattern itself.
• Structure, Dynamics
This details the structure of the solution and some dynamic aspects, such as a sequence
diagram or use case.

5. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
SEIS 720 –Computer Security Brian Machart2
• Implementation
This describes considerations when implementing the solution.
• Consequences
This describes the benefits and drawbacks of the solution in this pattern.
• Known Uses
As a general practice, a minimum of three examples of the pattern’s use should be found
prior to acceptance as a pattern.
• See Also
A list relating this pattern to other similar patterns; these may be variations of the same
pattern in some instances.
Security patterns may be further classified by criteria, such as procedural, structural, and
architectural. Pattern classification following such granularity is beyond the scope of this paper.
Blackwell and Zhu analyze security patterns to this degree and also present the aspects of
patterns in the development lifecycle using the Zachman framework. [B3, pp. 21-24]
Security Pattern History
Patterns in software design trace their history to architect Christopher Alexander who created an
approach to architecture using patterns back in the late 1970s. Using these principles, Ward
Cunningham and Kent Beck adapted his ideas to software development. In 1995, four software
designers, known as the “Gang-of Four” wrote “Design Patterns-Elements of Reusable Object-
Oriented Software” that produced wide acceptance of design patterns [B1, p. 4].
The first security patterns were developed two years after the Gang of Four introduced design
patterns. Yoder and Barcalow published a sentinel paper documenting security patterns
following the Gang of Four template for design patterns. This paper, entitled “Architectural
Patterns for Enabling Application Security”, was presented at the Pattern Languages of
Programs Conference in 1997 [B4]. In it they documented seven basic security patterns
described briefly below:
• Single Access Point
Create access to the system through a single login and create a means to launch only the
necessary sub-applications

6. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
SEIS 720 –Computer Security Brian Machart3
• Check Point
Create an object that uses an algorithm based on the enterprise’s security policy to
authenticate a user by organizing the needed checks.
• Roles
Create the roles that groups of users have and their access rights.
• Session
Creates a session object that includes any and all variables that need to be shared for that
given session.
• Full View with Errors
Designs the application showing user all items they have access to and validates
operations performed. Sends error message, if illegal operation attempted.
• Limited View
Designs the application only showing users what they have access-privileges to use.
• Secure Access Layer
Build application around existing system, network, and/or database security. If non exist,
build low-level security followed by a secure access layer to provide access in/out of
system.
The security pattern, Single Access Point, is included in Appendix A to serve as an example.
(Note: This uses the original Gang of Four design template and not the revised version as
documented by Fernandez in 2014.)
These patterns are presented here, as they were not only a foundation for security patterns, but
they also serve as baseline in later documentation coding in Java, for example [B5]. Many
additional security patterns have been added since, including three books on the topic [B2, p.5].
Munawar Hafiz operates a website documenting 97 known security patterns as of early 2013
[B6]. Other security patterns resources are provided on websites maintained by Markus
Schumacher (securitypatterns.org), The Hillside Group (hillside.net), and The Open Group
(opengroup.org).
Security patterns are now accepted practice at many of the leading software development
companies with Microsoft, Sun (now part of Oracle), and IBM having papers, books, and/or
websites on the topic [B2, p.5].

7. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
SEIS 720 –Computer Security Brian Machart4
As previously stated, Blackwell and Zhu recently classified the catalogs of patterns with greater
granularity. [B3, pp.17-29]
Misuse & Attack Patterns
In terms of securing enterprise software, it is necessary to briefly discuss misuse patterns and
their relevance to security patterns. Misuse patterns describe how an attack occurs from the
attacker’s viewpoint, analyzes how to stop it using possible security patterns, and how to trace
the attack to its origin using forensic data. [B2, P384]. Misuse patterns are not to be confused
with attack patterns. Attack patterns are specific actions to take advantage of vulnerabilities,
such as a buffer overflow [B2, p.22]. Attack patterns will not be discussed further.
Misuse patterns use a template similar to security patterns. The template and each attribute is
fully-defined in [B2, pp. 386-390] and summarized below:
• Pattern Name
The name should correspond to the specific type of misuse that occurs.
• Thumbnail Description
This is a short description of the intended purpose of the pattern.
• Context
This describes the general environment, primarily the conditions under which the misuse
occurs.
• Problem
The problem is how the hacker goes about finding a means to attack the system. It looks
at which vulnerabilities can be exploited and what factors may delay the hacker from
accomplishing the attack.
• Solution
This solution describes how the hacker accomplishes the misuse and what the
repercussions of the attack.
• Consequences
The consequences are the benefits and drawbacks that the attacker views by
accomplishing the attack.
• Countermeasures and Forensics
This describes the security measures necessary to mitigate the attack or trace it back.
• Known Uses & See Also
“Known uses” defines particular incidents where this type of attack has occurred. “See
also” describes other misuse patterns that have different objectives but are performed in a
similar fashion or similar objectives but just performed differently.

8. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
SEIS 720 –Computer Security Brian Machart5
Three examples of identified misuse patterns are: the worm pattern, the denial-of-service in
VOIP pattern, and the spoofing web services pattern. Based on current information available,
misuse patterns remain in their infancy and more research and development is necessary to
clearly and completely provide security pattern countermeasures for these attacks, although
mitigative means are documented in the pattern definitions [B2, pp. 394-408].
Benefits, Best Practices, & Recommendations
It is not a stretch to conclude that security patterns are underutilized in the world of enterprise
software since securing software platforms has historically been on one of the lowest rungs of
the development ladder. Unfortunately, security is still too often an afterthought in development.
Budgets are tight and software clients want to get the most “bang for the buck” and focus on all
the features they require and can afford. In some ways, spending part of the business’ budget on
security is similar to garbage collection: it is absolutely necessary but no one wants to pay for it.
As security breaches have become more frequent, are constantly in the media, and are affecting
everyone; it is possible, if not likely, security’s importance (and therefore security patterns) in
enterprise software rises to near the top of design concerns. Isn’t spending on security during
development cheaper than the public relations hit and associated costs of a security breach?
Security patterns serve as a security “handbook” or guideline to coders. Programmers and
engineers involved in the software design may not be security experts. As a result, they may not,
unfortunately, have the insight or experience necessary to consider all the potential security
threats. Employing security patterns can assist in filling the gaps in a designer’s security
background, yet a security expert can add more analysis on which patterns and how to apply
them given a particular threat or misuse pattern. This assumes, however, that the “expert” is
properly trained and proficient in the use of security patterns.
Security pattern use has the potential to keep development budgets in check. If, for example, a
software consultant makes use of security patterns in a proposal to a client, a number of benefits
may be achieved. First, in cost estimation, programmers can use patterns as a guide relative to
how much effort will be necessary to code a particular problem that pattern solves. Second,

9. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
SEIS 720 –Computer Security Brian Machart6
since security patterns are written in layman’s terms, the consultant can use them as a basis to not
only to defend the proposal to the client, he or she can use them to explain in plain English what
is to be secured and the threat it is preventing. Third, when potential threats are identified in
advance, costs are integrated into the design proposal instead of adding at the end resulting in
budget overruns.
Security patterns use is a matter of best practice for enterprise software systems. Use of security
patterns implements a holistic approach in software architecture [B2, p.496]. Piece-meal design
invites attacks; security patterns aid in integrated architecture. In the case of the Java enterprise
edition, use of security patterns is integral in providing end-to-end security. In Sun
Microsystem’s book, Core Security Patterns, the authors present a software architecture to
secure a Java-based development at the web, business, and web service tier levels [B7]. They
include a case study of what security patterns to use for each tier in order to mitigate possible
threats. It is also noted in this 1000-page text, while many new patterns are introduced to
document how the end-to-end security solution can be made possible, the basic patterns
introduced by Yoder and Barcalow play a prominent role [B5]. End-to-end security is
increasingly important in an age when accessing a system is with BYOD, “bring your own
device” and at a location on- or off-site.
When analyzing potential threats in enterprise software development, security patterns provide
measures to mitigate those threats. If a software architect is to strategize how a software package
could possibly be attacked, security patterns (and misuse patterns for that matter) should be
integral in that analysis. Security patterns are “proven solutions to reoccurring problems” and
are designed to aid non-security experts implement good solutions [B8]. In developing software
for financial transactions or medical records, security is of utmost importance. It certainly
should be a priority to use security patterns in developing these types of software systems and
would seem almost negligent not to use them. Essentially, lack of security pattern use is
considered an “architectural inefficiency”[B7, p.5].

10. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
SEIS 720 –Computer Security Brian Machart7
Conclusions
Complex enterprise systems are difficult to design, implement, and maintain. Their design is
most-often assembled piece-meal. As a result, security is often not incorporated end-to-end. A
holistic approach is a better option to solve this problem. Since these designers may not be
security experts, security patterns are a useful means to assist them with security. Security
patterns provide the developers with free advice from the experience of others; practical
experience in how to solve the problem and mistakes made in developing that solution. In the
Java environment, security patterns allow software architects to take full advantage of built-in
Java security features.
Security pattern usage among enterprise systems is difficult to quantify (in terms of frequency of
use in design). It appears to the casual observer that enterprises with a web presence, such as e-
commerce sites, may follow along with the principles of the security patterns declared by Yoder
and Barcalow (e.g., single point access, checkpoint); however, without internal access to the
development team there is no means to be certain.
Security patterns are a helpful tool for the enterprise developer to evaluate common security
problems and how to avoid them. However, they are not a be-all-end-all to cyber threats. They
provide proven security solutions based on experiences of others and help non-security experts
develop a more secure solution. They are most useful when end-to-end security is a goal and a
holistic approach to system design is followed. As more attacks take place and new means to
compromise systems arise, not only must security patterns be integrated into the entire enterprise
system development process, but academia and industry must continue to create, revise, and
promote security patterns and their effectiveness.

11. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
SEIS 720 –Computer Security Brian Machart8
References
[B1] M. Schumacher, E. Fernandez-Buglioni, D. Hybertson, F. Buschman, P. Sommerfeld,
Security Patterns: Integrating Security & Systems Engineering. West Sussex, England: John
Wiley & Sons, Ltd, 2006.
[B2] E. Fernandez, Security Patterns in Practice: Designing Secure Architectures Using
Software Patterns. West Sussex, England: John Wiley & Sons, Ltd, 2013.
[B3] C. Blackwell, “Towards a conceptual framework for security patters,” in Cyberpatterns:
Unifying Design Patterns with Security and Attack Patterns. C. Blackwell, and H. Zhu, Ed.,
Switzerland: Springer International Publishing, 2014.
[B4] J. Yoder, and J. Barcalow, “Architectural patterns for enabling
application security, “ Proceedings of the 4th
Annual Conference of Pattern Languages of
Programs, 1997.
[B5] “41. – Designing for Security: Security Principles and Patterns.” ADF Architecture TV.
Hosted by Frank Nimphius. Oracle Corporation. 5 Mar. 2014.
B6] M. Hafiz. (Accessed: 2014, Nov. 28) “Security Pattern Catalog.” [Online]. Available:
http://www.munawarhafiz.com/securitypatterncatalog/index.php
[B7] C. Steel, R. Nagappan, R. Lai, Core Security Pattern[s: Best Practices and Strategies for
J2EE, Web Services, and Identity Management. Upper Saddle River, NJ: Pearson Education,
Inc., 2006.
[B8] S. Romanosky. (Accessed: 2014, Nov. 23) “Sasha Romanosky, Ph.D.” [Online]. Available:
http://www.romanosky.net/

12. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
Appendix A
Sample Security Pattern:
Yoder & Barcalow’s Single Point Access Pattern (1997)
Motivation:
A military base provides a prime example of a secure location. Military personnel must be allowed in while spies,
saboteurs, and reporters must be kept out. If the base has many entrances, it will be much more difficult and
expensive to guard each of them. Security is easier to guarantee when everyone must pass through a single guard
station.
It is hard to provide security for an application that communicates with networking, operating systems, databases,
and other infrastructure systems. The application will need a way to log a user into the system, to set up what the
user can and can not do, and to integrate with other security modules from systems that it will be interacting with.
Sometimes a user may need to be authenticated on several systems. Additionally, some of the user-supplied
information may need to be kept for later processing. Single Access Point solves this by providing a secure place to
validate users and collect global information needed about users who need to start using an application.
Problem:
A security model is difficult to validate when it has multiple “front doors,” “back doors,” and “side doors” for
entering the application.
Forces:
• Having multiple ways to open an application makes it easier for it to be used in different environments.
• An application may be a composite of several applications that all need to be secure.
• Different login windows or procedures could have duplicate code.
• A single entry point may need to collect all of the user information that is needed for the entire application.
• Multiple entry points to an application can be customized to collect only the information needed at that
entry point. This way, a user does not have to enter unnecessary information.
Solution:
Set up only one way to get into the system, and if necessary, create a mechanism for deciding which sub-
applications to launch. The typical solution is to create a login screen for collecting basic information about the
user, such as username, password, and possibly some configuration settings. This information is passed through
some sort of Check Point that verifies the information. A Session is then created based upon the configuration
settings and the user’s access privileges. This Session is used to keep track of the global information that deals with
the user’s current interaction with the application. When opening up any sub-application, requests are forwarded
through the Check Point for handling any problems and validations.
UNIX is an example of a system with multiple access points. Each network port can provide access to a separate
service. These multiple access points make it difficult to secure a UNIX system as a hole. Individual applications
running on a UNIX system can still be secured, however. For example if an application has web, email, and
programming interfaces, steps must be taken to ensure that each of these interfaces are forced through a shared
Single Access Point before accessing the rest of the application.
The “Putting It All Together” section describes the initialization process in more detail. The important idea here is
that Single Access Point provides a convenient place to encapsulate the initialization process, making it easier to
validate that the initial security steps are performed correctly.

13. Security
Patterns:
Overview
and
Best
Practices
for
Securing
Enterprise
Systems
Example:
There are many examples of Single Access Point. In order to access an NT workstation, there is a single login screen
which all users must go through to access the system. This Single Access Point validates the user and insures that
only valid users access the system and also provides Roles for only allowing users to see and do what they have
permissions to do. Most UNIX systems also have a Single Access Point for getting a console shell. Oracle
applications also have many applications such as SQLPlus and the like that provide a Single Access Point as the
only means for running those applications.
Consequences:
• A Single Access Point provides a place where everything within the application can be setup properly. This
single location can help ensure all values are initialized correctly, application setup is performed correctly,
and the application does not reach an invalid state.
• Control flow is simpler since everything must go through a single point of responsibility in order for access
to be allowed. Note, Single Access Point is only as secure as the steps leading up to it.
• The application cannot have multiple entry points to make entering an application easier and more flexible.
Related Patterns:
• Single Access Point validates the user’s login information through a Check Point and uses that information
to initialize the user’s Roles and Session.
• A Singleton could be used for the login class especially if you only allow the user to have one login session
started or only log into the system once. A Singleton could also be used to keep track of all Sessions and a
key could be used to know which session to use
Known Uses:
• UNIX telnet and Windows NT login applications use Single Access Point for logging into the system.
These systems also create the necessary Roles for the current Session.
• Most application login screens are a Single Access Point into programs because they are the only way to
startup and run the given application.
• The Caterpillar/NCSA Financial Model Framework has a FMLogin class, which provides both Single
Access Point and Check Point.
• The PLoP ’98 registration program provides a Single Access Point for
logging into the system and entering in credit card information when users registered for PLoP ’98.
• Secure web servers, such as Java Developer’s Connection appear to have multiple access points for each
URL. However, the web server forces each user through a login window before letting them download
early access software.
Non-security Known Uses:
• Any application that launches only one way, ensuring a correct initial state.
• Windows 95, also uses a login window which is a Single Access Point, but it is not secure because it allows
any user to override the login screen.
• Single creational methods provide for only one way to create a class. For example, Points in VisualWorks
Smalltalk guides you to creating valid points by providing a couple of creational methods that ensure the
Object is initialized correctly. Kent Beck’s describes Constructor Methods as a single way to create well-
formed instances of objects. These are put into a single “instance creation” protocol. This becomes the
Single Access Point to create new objects.
• Constructor Parameter Method initializes all instance variables through a single method, which is really a
Single Access Point for that class to initialize its instance variables.
• Concurrent programs can encapsulate non-concurrent objects inside an object designed for concurrency.
Synchronization is enforced through this Single Access Point. Pass-Through Host design deals with
synchronization by forwarding all appropriate methods to the Helper using unsynchronized methods. This
works because the methods are stateless with respect to the Host class.