Well-funded, highly resourced security projects often fail. Even with proficient staff, security expertise, and detailed project management, they still fail. Security projects can fail even before they are fully implemented. Why do they fail? The fault is often in the approach to the security architecture design. Without a sound security design methodology that takes into consideration business goals, environments, and operations, the security architecture can be costly project that does not achieve the desired impact on the organization.

When developing a security architecture, using a proven framework like the Sherwood Applied Business Security Architecture (SABSA), can help to yield a security model that works for the organization.  The SABSA framework has six integrated components that, if done correctly, can lead to a holistic and cost-effective security architecture.

The first, and perhaps most important, component is the Contextual Security Architecture. This piece of the architecture sets the stage for the downstream components and focuses on articulating the business drivers for the security model. Completing this component should enable the organization to answer the basic questions about the security requirements. What is important for the organization to protect? Why should these be protected (reputation, legal, financial, etc.)? How do the organizational processes function? Who are the subjects to the security (internal, partners, service providers)? Where (in what locations) will the security apply? And finally, when does the organization need to apply security? With the answers to these contextual questions in hand, the design of the security architecture can be aligned with the goals of the business.   

The second component in the SABSA framework is the Conceptual Security Architecture.  Once context is established from the previous stage, the concepts for the security model, the “vision,” can be created. The “W” questions can be asked but with a slightly different context. What are the business attributes that need to be protected? Why is the security/protection important or necessary? How will the targets be protected? Who is involved in the management of the security and how do they interact? Where is the protection implemented in terms of security domains? When should the security be applied and for how long?

The third component in the SABSA framework is the Logical Security Architecture. The Logical Security Architecture build on the Conceptual Security Architecture. In this stage, the security concepts are turned into logical plans that represent real solutions. Like with the previous stages, the “W” questions also apply. What information, systems, processes need protection? Why do these need protection – policy enforcement, compliance, other? How will the protection or security be applied? Who has privileges or access to the security systems? Where does the security apply – logical, physical, which domains? When does the security need to be applied, authentication, sessions, etc.?

The fourth component in the SABSA framework is the Physical Security Architecture. This model considers the Logical Security Architecture and selects the components that will satisfy the logical requirements. What are the security details of the required structure? Why, the drivers/rules used for making security decisions. How will the rules be enforced – what technology? Who are the dependent users of the systems? Where will the security be physically applied? When will the execution of the controls be enforced and for how long?

The fifth component in the SABSA framework is the Component Security Architecture. This component, like the others, builds upon its predecessor. The Component Security Architecture is applied to the specific hardware, software, or service where the security. It is the specifics of how the security is configured to address the requirements defined in the physical design. Again, our “W” questions are relevant to this model.  What are the specific details of the security application? Why are these specifications being addressed (operational risk management)?  How will the security be applied, which solutions specifically? Who will be subject to the controls and what privileges will they have? Where is the security applied in terms of specifically identified systems and addresses? When are the controls enforced in terms of order of events?

With the completion these components, the final part of the model is the Operational Security Architecture. As the name implies, this piece of the methodology concerns the day to day operations of the security systems. For this, our “W” questions are focused on the operating and maintaining the systems. The “what” is the ensuring the operational continuity of the controls. The “why” is to manage the operational risk. The “how” in this case is execution of specific security operations. The “who” is the users and their systems. The “where” is systems, platforms, and networks. The “when” is the specific timetable for the security operations.

The SABSA Security Architecture Model is more of an approach to security than a recipe. The methodology is designed to get the designers, builders, and operators of the security framework to think about how the model will be used and by whom. Each phase of the methodology builds upon the previous, helping to ensure alignment all the way through the process. As I pointed up earlier, many security models fail. Not because the security is bad or the team is incompetent, but because the security design is often incompatible with the business processes or the personnel charged with operating it. The SABSA approach aims to help set the foundation for which the security architecture can be built upon. If there are flaws in the foundation, the framework will likely not serve the intended purpose. The SABSA model, when performed in sequence, provides a logical model to pragmatically develop a security architecture that fits within the capabilities of the organization.