Enterprise Information Security Architecture Fundamentals

One of the big trends in enterprise security is creating and adopting an enterprise information security architecture. However, much of what has been written about the subject is quite ambiguous, and may leave IT pros wondering what an enterprise information security architecture even is--let alone how to implement it. That being the case, I wanted to try to simplify things to help organizations understand what comprises an enterprise information security architecture and how they can go about putting one into action.

Toward that end, let's take a step back and examine the way that IT security has traditionally been done in the enterprise. Historically, enterprise security was all about making the organization as secure as the IT budget would allow. IT pros would use various policies, procedures and products to harden the organization in response to perceived threats (or in response to regulatory requirements).

An enterprise information security architecture is an attempt to directly align the IT department’s approach to security with the organization’s business needs. There are two main benefits to this approach.

First, implementing an enterprise information security architecture forces the IT department to focus on the security challenges that have the greatest potential to impact the business. IT is no longer left chasing the latest security trends, but rather can focus intently on the issues that matter the most to the business.

Second, an enterprise information security architecture involves much more than just deciding which security products to buy or which security challenges to focus on. The model becomes tightly interwoven into the business. It becomes a key part of “how we do things.” This mindset forces the powers that be to think about security as a part of the business decision-making process.

No One-Size-Fits-All Solution

This, of course, raises the question of how an organization can go about implementing an enterprise information security architecture. The important thing to understand about the process is that “enterprise information security architecture" is a somewhat generic term. There isn’t a single, set-in-stone process that defines what it means for an organization to have implemented the model.

So, how can a security-conscious organization implement an enterprise information security architecture if no clear standard exists? Fortunately, there are several frameworks available. Some of the more popular frameworks include SABSA, COBIT and TOGAF.

To describe these frameworks, let me first take a moment and delve into something completely unrelated. If you have worked in IT for a while, you have probably heard of the OSI model. The OSI model defines the layers that make up the network stack. These layers include the application, presentation, session, transport, network, data link and physical layers. Each layer has a specific job to do, and each is designed to interface with the layer above it and the layer below it.

Generally speaking, the previously mentioned frameworks also take a layered approach that defines the structure of the security architecture. The SABSA framework, for example, includes layers such as the contextual, conceptual, logical, physical and component security architectures. These layers collectively form the overall security architecture.

By and large, the various frameworks provide things like architectural diagrams, flow charts and documentation. These resources can be used to drive the implementation of an enterprise information security architecture within an organization.

Keep in mind that there is no rule stating that an organization has to strictly adhere to one of these frameworks. An organization might instead choose to design its own architecture, or to create a mashup of two or more of the available frameworks.

Regardless of how an organization chooses to approach its enterprise information security architecture, the goal should always be to tie the organization’s security efforts to key business objectives. If, for example, a business states that its online store must be available to customers at all times, the next step in the process would be to identify risks that may impact the availability of that resource.

Some of the risks have nothing to do with security, but drive IT decisions in other ways. For instance, a power failure in the organization’s data center could impact the availability of the online store, and so IT would need a plan for controlling that risk. Similarly, a denial of service attack could prevent customers from accessing the online store. In this context, a denial of service attack is an identified security risk that is directly tied to a key business objective. This provides the rationale for the IT department to focus on preventing denial of service attacks.