Tobias Christen
Oct 28, 2010
Posted in category: 2010 Member Articles

Creating an Enterprise Security Architecture

ICT Standard for Management identified 4 architectural areas that together make up an enterprise architecture: the business architecture, the information architecture, the application architecture and the technical architecture.

In this article we first make the case that an “Enterprise Security Architecture” runs across all four of those major disciplines. We then argue that a security architecture needs to be based on a proven and well maintained controls catalogue, and needs to be presented in a that is easy to understand for a wide set of stakeholders.
Security Architecture in the Enterprise

Security Architecture comprises the design artifacts that describe how the security controls (= security countermeasures) are positioned, and how they relate to the overall IT Architecture. These controls serve the purpose to maintain some of the enterprise architecture’s quality attributes, among them confidentiality, integrity, availability, accountability and assurance.
Security in the business architecture

Generally speaking, baseline security controls are valuable for establishing a minimal protection level, systems and processes that face extraordinary threats will need to be protected with controls that go beyond the baseline. However, today one of the biggest threat for many enterprises comes from organized crime that attacks business processes dealing with valuable goods or money. The resources that the organized crime can use for an attack go beyond the resources that an enterprise can put into security controls.

Over the past years we have acknowledged that business processes that deal with money or valuable goods (including IP rights) must be protected by additional controls that are embedded right into the logic of the business process implementation. The credit card industry has long since observed that fraud is best detected and prevented as part of the business process. The insurance industry as well as the credit industry are following the example and instantiate more and more fraud protection controls directly in the business process.
Security in the information architecture

Information security starts with determining which enterprise information and systems are particularly valuable and must be protected with great care. Today for most enterprises it is still a significant challenge to find owners for the information assets and let the owners rate the criticality and confidentiality of these assets. In the lack of such “data classification” enterprises often use the IT department as the data custodian, who then applies the baseline controls to all data. This does not reflect best practices in risk management and is not cost-efficient.
Security in the application architecture

Applications are systems that serve to facilitate or fully implement a business process. Applications can process different classifications of data. Often this fact is ignored and the strongest security controls (e.g. authentication, authorization, audit trail, etc) are applied. Best practice would be that the application is is aware of the data classification and can apply security controls in a risk based manner.


Security in the technical architecture

Typically network security and common security controls such as central authentication system, central authorization system, central audit trail etc can be provided as shared components in the technical enterprise architecture.


Creating a Security Architecture 

An effective security architecture provides high-level guidance on how to achieve legal compliance, adherence to corporate policies & standards and protect data and systems in a way that reflects best practice.

Applying a security architecture should be as easy as describing the corresponding system type and data usage from the security architecture and adding/removing security controls based on the risk exposure.

The greatest challenge in communicating and teaching an enterprise security architecture is that to understand the architecture, the individual needs to understand the whole. It is hence extremely important to represent the architecture in a way that is easily understood and keep it as simple as possible.

Or as Wolfgang Amadeus Mozart put it

“Simplicity is the most complex thing, but with simplicity you find the way to the heart (and mind) of your audience”.


The Open Security Architecture 

A very large community of security architects (more than 700 members at the time of this writing) started in 2007 to put together the foundations and security patterns that describe a generalized enterprise security architecture. The Open Security Architecture (OSA) is based on the strong controls catalog of NIST (800-53). In addition to this controls catalog NIST continuously produces also new technical guidelines and maintains existing guidelines.

OSA chooses a highly visualized approach and combines a security design pattern approach with a modular architecture. Security modules such as “server”, “desktop”, “mobile device”, “DMZ” are typical components that you find in almost all technical enterprise architectures. Reusing these components in a security (design) patterns allows to keep the latter as simple as possible and express in these patterns only the use-case specific parts.


Security Patterns in OSA:

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.

Let us assume that the notion of “design pattern” can be translated directly to IT security, for example: “A security pattern is a general reusable solution to a commonly occurring problem in creating and maintaining secure information systems”. It is then interesting to see how security design patterns can be combined with other ways to describe best practices for securing information systems. Both NIST 800-53 as well as ISO 27001 are best practices that describe technical, organizational as well process controls. While both of them are far more complete than any of the security pattern collections that can be found on the web [3],[4], neither of them leverages the power of visually illustrated design patterns. In the Open Security Architecture community we try to improve the expression power of best practice standards by combining them with visually illustrated (design) patterns.

You may consider the OSA patterns to be similar to “Lego” building blocks for security solutions, they provide a set of standard components that encapsulate the complexity of applying the controls catalog to solve commonly occurring problems.
The OSA Landscape

The OSA landscape is an attempt to structure and layer controls areas that protect components of an enterprise architecture (infrastructure, processes, applications, services). There are is no right or wrong landscape but the below illustrated landscape reflects long discussions and many iterations among security architects that have set up corporate security architectures. Each of the small-boxes could point to a pattern. The patterns hence can be very different in nature and topics range from “Securing the deliverables of outsourced software development” to “Setting up central security audit trail servers”. The area “Governance” and Service Security Patterns might be of particular interest for the members of ICT Standard Forum.




About OSA:

OSA is licensed in accordance with Creative Commons Share-alike. Open Content principles result in more secure systems, and help to make the computing architectures that we depend on for our daily lives to be as secure and reliable as possible.

Find all information under

Contact us Download BT Standard as PDF


Looking for answers to your questions about the BT Standard? Get in touch!