What is Security Architecture?
The idea seems straight-forward, a design for securing a complex system. However, if this were straight-forward, then many organizations I've worked within, and the large companies throughout the world wouldn't continue to suffer from inefficiencies, catastrophic breaches, data failures, and other harms which prevent them from efficiently offering the services many have come to rely upon. During my study of Security Architecture, we focused on a specific model, called SABSA®, or the Sherwood Applied Business Security Architecture. Here, I discuss the model, and in turn, help describe what a security architecture is, and what it requires to be successful.
SABSA® Security Architecture Model
Sometimes security systems fail catastrophically and other times they fail enough that they work poorly and hinder efficiency and frustrate the stakeholders who use them. For these reasons, information security is often viewed as a system hindrance rather than a system enabler. As a working security architect, I find this sentiment oddly inaccurate because ensuring systems are available and safe from harm is a core tenant to information security professionals. Yet, many times we fight to include requirements to enable business to survive catastrophe or remain safe because of a poorly constructed security system stakeholders have had to endure in the past. For this reason, a structured approach to creating a security enabled system is critical to prevent frustration and loss of profit, or even worse, catastrophic systems failure. The SABSA® security architecture model seeks to prevent failure, and plan, execute, and maintain a security system by following a thorough and structured approach to engineering information security architectures. Here we examine the six layers of this structure from the top down starting with the business view.
The Business View (Contextual Security Architecture)Zinatullin, an experienced risk consultant, shares in a blog posting describing a design case study using the SABSA architecture that we “[s]tart by reading [our] company’s business strategy, goals, and values, [and] have a look at the annual report” (Zinatullin, 2018). This helps to identify what the business and business context this architecture will be used. This activity ensures that the provided reasoning for the architecture drawn from our business documents is incorporated and describe what needs to be protected, why we need an architecture, how processes protect them, who are the stakeholders involved, where the location aspects lay, and when time-related aspects are critical. For example, a secure architecture to store customer health records in the US, can begin by looking at our business strategy, goals, and values which could be “protect our reputation, customer information, and meet US compliance.” These in turn help guide choices to identify risks and for incorporating required processes, and functions into our architecture. Knowing what to protect, how we want to protect it, who is involved, and where and when we want to place systems are all critical to creating an accurate vision for the architect.
The Architect View (Conceptual Security Architecture) The business view outlines a strategy and plan and critical contextual items and drives the conceptual security architecture, that is, it describes what we need and the architect view translates this into a vision of a larger system. As Sherwood et al describe it’s six W’s include “What you want to protect…” and “Why the protection is important..” and “How you want to achieve the protection…” and “Who is involve in security management…and the trust framework within which entities interact with one another” as well as “Where you want to achieve the protection…” and finally, “When is the protection relevant…” (2005, p. 37). These questions provide a high-level view of the architecture, however, as in any building architecture drawing, it still requires a logical structure and details to create the home such as what it’s built out of, brick, stucco, wood, steel, etc.). These details are translated from the vision of the architect from a designer.
The Designer’s View (Logical Security Architecture)The details are brought together and taken from a vision to a system of systems by the designer, who is an engineer. This process is the systems engineering process where the designer translates the architect concept into a logical system with system components, and sub-systems. The designer determines what logical representation will protect the information, specifies why it needs protection by using high level security policies, how the logical mechanisms work together to protect the information, and who is involved and how they interact and their authorization levels with a schema. They also specify where the security domains relationships are and how they interact, and finally when each process in performed. With these higher-level logical diagrams in place, a builder creates a physical security architecture which meets the business needs, architect’s vision, and designer’s logic.
The Builder’s View (Physical Security Architecture)The builder “is someone who can take the logical descriptions and drawings and turn them into a technology model that can be used to construct the building” (Sherwood, Clark, & Lynas, 2005, p. 38). One may think this is where the construction begins, but, this phase defines what the business data model and security-related data structures are involved such as labeling and defining the interactions, flows, and technologies needed to meet the designers view. They specify why rules are needed and how procedures and actions and conditions adhere to these rules, and how these security mechanisms such as encryption and authentication will be physically supported (e.g. what servers/systems). They then define who the users are and what they will use and interact with the systems, and where the physical infrastructure where exist and when the time-related sequences and events are dependent upon one another and how. At this point, the architecture has reviewed and conceptualized the business needs, determined a system and how it interacts logically, and now defined physical components needed for the system to function. The phase can now gather the required personnel and components and begin building the system using the skills required and specified in the previous phases.
The Tradesman’s View (Component Security Architecture)Merriam-Webster defines a tradesman as “a worker in a skilled trade” which is precisely what is required to put together a complex system of varying components as it has been defined at this point (Merriam-Webster, 2019). The tradesman skills required are numerous, for example, we need network engineers, server administrators, software engineers, project managers, and any number of specific skillsets to build the system. What specifications are required for each tradesman, why they are required as defined by security standards, and how they will be enabled through specific products and tools. These require knowing who will use the system and how to define them in the systems, and what privileges they need as well as where each specified process and protocol needs to be placed and finally when the security timing and synchronization process need to be implemented. These are all components of the system as a whole and there are any number of components which can meet the requirements, however, these were already specified by our designer, architect, and business views and now regular operations may begin.
The Facility Manager’s View (Operational Security Architecture)With a system built, the intended persons the system was built to support begin regular operational processes. Without a proper analysis and construction of the system up to this point many groups discover that they fail to be flexible to maintain with constant changing of personnel change, the slow creep of complacency, or even failure due to missed requirements. In a YouTube video, the presenter, Wilson, describes reasons why companies fail compliance initiatives (Wilson, 2013). Wilson’s observed that a group will readily alter their controls to pass an audit, rather than fix a poorly constructed architecture.
This architecture phase is unique in that it touches all aspects of the entire model, that is operational activities exist in each of the other five phases. For example, in operational support we seek to ensure that those who work with the system know what is required to maintain it, why they need to follow the policies, processes, and procedures outlined, and how to achieve the security architecture goals. These people know who provides the support, and execute the defined actions to ensure the security architecture remains sound. Finally, they know where they need to implement their operational activities, and how to audit them, and how often and on what schedule.
Every step of the SABSA ® Model is critical to interact and provide the next layer with answers to questions the layer may have and include the requirements necessary to avoid security failures in the form of a cascading failure. For this reason, it is also paramount for the five views and architectures already described (knowing the who, what, when, where, why, and how, for each phase) to ensure each layer’s responsible parties answer these six W’s for their respective phase completely. This is achieved by implementing all the phases and the SABSA® Security Architecture Model will often overlay the described operational security architecture across the other five views/architecture phases to ensure they are structured. By following a structured approach in this model, and providing a detailed set of information for the next layer a security system can be defined, envisioned, developed, and implemented to ensure it does not fail softly and end in frustrated stakeholders, or fail hard and end in catastrophe.
References
The idea seems straight-forward, a design for securing a complex system. However, if this were straight-forward, then many organizations I've worked within, and the large companies throughout the world wouldn't continue to suffer from inefficiencies, catastrophic breaches, data failures, and other harms which prevent them from efficiently offering the services many have come to rely upon. During my study of Security Architecture, we focused on a specific model, called SABSA®, or the Sherwood Applied Business Security Architecture. Here, I discuss the model, and in turn, help describe what a security architecture is, and what it requires to be successful.
SABSA® Security Architecture Model
Sometimes security systems fail catastrophically and other times they fail enough that they work poorly and hinder efficiency and frustrate the stakeholders who use them. For these reasons, information security is often viewed as a system hindrance rather than a system enabler. As a working security architect, I find this sentiment oddly inaccurate because ensuring systems are available and safe from harm is a core tenant to information security professionals. Yet, many times we fight to include requirements to enable business to survive catastrophe or remain safe because of a poorly constructed security system stakeholders have had to endure in the past. For this reason, a structured approach to creating a security enabled system is critical to prevent frustration and loss of profit, or even worse, catastrophic systems failure. The SABSA® security architecture model seeks to prevent failure, and plan, execute, and maintain a security system by following a thorough and structured approach to engineering information security architectures. Here we examine the six layers of this structure from the top down starting with the business view.
The Business View (Contextual Security Architecture)Zinatullin, an experienced risk consultant, shares in a blog posting describing a design case study using the SABSA architecture that we “[s]tart by reading [our] company’s business strategy, goals, and values, [and] have a look at the annual report” (Zinatullin, 2018). This helps to identify what the business and business context this architecture will be used. This activity ensures that the provided reasoning for the architecture drawn from our business documents is incorporated and describe what needs to be protected, why we need an architecture, how processes protect them, who are the stakeholders involved, where the location aspects lay, and when time-related aspects are critical. For example, a secure architecture to store customer health records in the US, can begin by looking at our business strategy, goals, and values which could be “protect our reputation, customer information, and meet US compliance.” These in turn help guide choices to identify risks and for incorporating required processes, and functions into our architecture. Knowing what to protect, how we want to protect it, who is involved, and where and when we want to place systems are all critical to creating an accurate vision for the architect.
The Architect View (Conceptual Security Architecture) The business view outlines a strategy and plan and critical contextual items and drives the conceptual security architecture, that is, it describes what we need and the architect view translates this into a vision of a larger system. As Sherwood et al describe it’s six W’s include “What you want to protect…” and “Why the protection is important..” and “How you want to achieve the protection…” and “Who is involve in security management…and the trust framework within which entities interact with one another” as well as “Where you want to achieve the protection…” and finally, “When is the protection relevant…” (2005, p. 37). These questions provide a high-level view of the architecture, however, as in any building architecture drawing, it still requires a logical structure and details to create the home such as what it’s built out of, brick, stucco, wood, steel, etc.). These details are translated from the vision of the architect from a designer.
The Designer’s View (Logical Security Architecture)The details are brought together and taken from a vision to a system of systems by the designer, who is an engineer. This process is the systems engineering process where the designer translates the architect concept into a logical system with system components, and sub-systems. The designer determines what logical representation will protect the information, specifies why it needs protection by using high level security policies, how the logical mechanisms work together to protect the information, and who is involved and how they interact and their authorization levels with a schema. They also specify where the security domains relationships are and how they interact, and finally when each process in performed. With these higher-level logical diagrams in place, a builder creates a physical security architecture which meets the business needs, architect’s vision, and designer’s logic.
The Builder’s View (Physical Security Architecture)The builder “is someone who can take the logical descriptions and drawings and turn them into a technology model that can be used to construct the building” (Sherwood, Clark, & Lynas, 2005, p. 38). One may think this is where the construction begins, but, this phase defines what the business data model and security-related data structures are involved such as labeling and defining the interactions, flows, and technologies needed to meet the designers view. They specify why rules are needed and how procedures and actions and conditions adhere to these rules, and how these security mechanisms such as encryption and authentication will be physically supported (e.g. what servers/systems). They then define who the users are and what they will use and interact with the systems, and where the physical infrastructure where exist and when the time-related sequences and events are dependent upon one another and how. At this point, the architecture has reviewed and conceptualized the business needs, determined a system and how it interacts logically, and now defined physical components needed for the system to function. The phase can now gather the required personnel and components and begin building the system using the skills required and specified in the previous phases.
The Tradesman’s View (Component Security Architecture)Merriam-Webster defines a tradesman as “a worker in a skilled trade” which is precisely what is required to put together a complex system of varying components as it has been defined at this point (Merriam-Webster, 2019). The tradesman skills required are numerous, for example, we need network engineers, server administrators, software engineers, project managers, and any number of specific skillsets to build the system. What specifications are required for each tradesman, why they are required as defined by security standards, and how they will be enabled through specific products and tools. These require knowing who will use the system and how to define them in the systems, and what privileges they need as well as where each specified process and protocol needs to be placed and finally when the security timing and synchronization process need to be implemented. These are all components of the system as a whole and there are any number of components which can meet the requirements, however, these were already specified by our designer, architect, and business views and now regular operations may begin.
The Facility Manager’s View (Operational Security Architecture)With a system built, the intended persons the system was built to support begin regular operational processes. Without a proper analysis and construction of the system up to this point many groups discover that they fail to be flexible to maintain with constant changing of personnel change, the slow creep of complacency, or even failure due to missed requirements. In a YouTube video, the presenter, Wilson, describes reasons why companies fail compliance initiatives (Wilson, 2013). Wilson’s observed that a group will readily alter their controls to pass an audit, rather than fix a poorly constructed architecture.
This architecture phase is unique in that it touches all aspects of the entire model, that is operational activities exist in each of the other five phases. For example, in operational support we seek to ensure that those who work with the system know what is required to maintain it, why they need to follow the policies, processes, and procedures outlined, and how to achieve the security architecture goals. These people know who provides the support, and execute the defined actions to ensure the security architecture remains sound. Finally, they know where they need to implement their operational activities, and how to audit them, and how often and on what schedule.
Every step of the SABSA ® Model is critical to interact and provide the next layer with answers to questions the layer may have and include the requirements necessary to avoid security failures in the form of a cascading failure. For this reason, it is also paramount for the five views and architectures already described (knowing the who, what, when, where, why, and how, for each phase) to ensure each layer’s responsible parties answer these six W’s for their respective phase completely. This is achieved by implementing all the phases and the SABSA® Security Architecture Model will often overlay the described operational security architecture across the other five views/architecture phases to ensure they are structured. By following a structured approach in this model, and providing a detailed set of information for the next layer a security system can be defined, envisioned, developed, and implemented to ensure it does not fail softly and end in frustrated stakeholders, or fail hard and end in catastrophe.
References
- Merriam-Webster. (2019, May 26). Tradesman | Definition of Tradesman. Retrieved from Merriam-Webster: https://www.merriam-webster.com/dictionary/tradesman
- Sherwood, J., Clark, A., & Lynas, D. (2005). Enterprise Security Architecture - A Business-Driven Approach. Boca Raton: CRC Press.
- Wilson, S. R. (2013). Why Companies Fail with Compliance Initiatives [Video file]. Retrieved May 23, 2019, from https://www.youtube.com/watch?v=RrGamuOHIlU
- Zinatullin, L. (2018, March 11). Leron Zinatullin's Blog. Retrieved May 25, 2019, from SABSA Architecture and Design Case Study: https://zinatullin.com/2018/03/11/how-to-solve-a-business-problem-with-security-using-sabsa/