Security Architecture
Security Architecture Artifact Overview
Organizations and the information systems they use have grown increasingly complex over the years. However, regardless of size and complexity, leaders are accountable for designing and implementing secure architectural models in support of enterprise security objectives. While several such models exist, the Sherwood Applied Business Security Architecture (SABSA) framework takes a business-led approach to security architecture, highlighting several different perspectives by which to view the enterprise.
The SABSA framework is useful and well designed in that it takes into account the complex interrelationships between various aspects and functions of the business for the highest-level business goals and objectives in the Contextual layer to the lowest level operational needs to sustain a variety of systems implemented in the Operational layer. This six-layered approach with its variety of views of lenses into the secure enterprise architecture helps promote a design and implementation that is more likely to succeed in that it has received input from a variety of stakeholders at multiple levels within the organization. It also promotes a “measure twice, cut once" philosophy in describing a well-architected solution before systems selection and implementation begins.
The various artifacts presented on this webpage represent a subset of those that would be crafted for an organizational customer as part of a SABSA engagement. Each type of artifact (as described in the 36-cell SABSA matrix below) is crafted at a specific abstraction layer to address the overarching business interests to tactical deployment considerations. By crafting these artifacts first and referencing them frequently, the business can plan to a set of objectives and documents that should have received buy-in from leadership and therefore reflect a true enterprise-wide cybersecurity architecture.
Reflection
At first glance, the material in the CSOL520 Security Architecture course was perhaps the most intimidating. I was professionally familiar with technical security architecture (building security networks, authentication systems, endpoint system, etc.), but not formal security architecture such as discussed in this course and illustrated through the use of the SABSA enterprise security architecture model and framework.
SABSA is a popular model but is also quite intricate. The 36-cell matrix and model diagram (presented below) each represents a particular subject area or deliverable that the security architect may be required to produce. Each document either provides some sort of reference format on the SABSA website or course text or requires some imagination by the implementer based on the given criteria.
In the end, this course proved to be quite valuable. Thinking about formal security architecture requires the professional to step back and first think of the business as a whole. The Business Risk Model document reflects this interest. An enterprise architecture that fails to account for business needs and concerns is doomed to irrelevance. The modern CISO must be consistently aligned with business goals and interests.
The conceptual security architecture document drills down a level and maps business drivers and requirements to assets, motivation, process, people, location, and time. This document answers the classic “W” question of who, what, when, where, why, and how for the business.
The logical security architecture document chosen describes a logical level deployment of a security monitoring service at an example corporation. Rather than dive into specific products or techniques, it addresses the requirement for logical security controls that form a cybersecurity protective mesh over the business.
The physical security architecture document is intended to take design objectives laid out at the higher logical level and implement them as physical systems required to support the workload. This assignment explored building a physically resilient architecture that is designed to survive multiple component failures to ensure service continuity.
Finally, the 36-cell matrix and SABSA diagram are shown as presented on the SABSA site and in the Enterprise Security Architecture text.
By building out many of the documents required in an enterprise security architecture, I gained a greater understanding of the type of thought processes required to align cybersecurity with high-level business strategy. I also learned how to think at the logical and conceptual levels (the latter was the focus of my final project). I believe that these levels are specifically important when a cybersecurity director or Chief Information Security Officer (CISO) reviews current and future capabilities to address business requirements and risks. The leader at this level is not concerned with specific implementation details but instead focuses on capabilities and controls, which will form a functional protective barrier to defend the organization. Being able to think, speak, and present around the interactions between the capabilities and always mapping back to the business's interests and requirements is key to the success of a cybersecurity leader. Furthermore, this leader is ethically required to act in the best interest of the business in protecting its important data. A person lacking fluency in these architectural concepts may not be up to the challenge of defending the modern enterprise.
I ultimately enjoyed this course and expanded my knowledge of this new cybersecurity discipline greatly.
Organizations and the information systems they use have grown increasingly complex over the years. However, regardless of size and complexity, leaders are accountable for designing and implementing secure architectural models in support of enterprise security objectives. While several such models exist, the Sherwood Applied Business Security Architecture (SABSA) framework takes a business-led approach to security architecture, highlighting several different perspectives by which to view the enterprise.
The SABSA framework is useful and well designed in that it takes into account the complex interrelationships between various aspects and functions of the business for the highest-level business goals and objectives in the Contextual layer to the lowest level operational needs to sustain a variety of systems implemented in the Operational layer. This six-layered approach with its variety of views of lenses into the secure enterprise architecture helps promote a design and implementation that is more likely to succeed in that it has received input from a variety of stakeholders at multiple levels within the organization. It also promotes a “measure twice, cut once" philosophy in describing a well-architected solution before systems selection and implementation begins.
The various artifacts presented on this webpage represent a subset of those that would be crafted for an organizational customer as part of a SABSA engagement. Each type of artifact (as described in the 36-cell SABSA matrix below) is crafted at a specific abstraction layer to address the overarching business interests to tactical deployment considerations. By crafting these artifacts first and referencing them frequently, the business can plan to a set of objectives and documents that should have received buy-in from leadership and therefore reflect a true enterprise-wide cybersecurity architecture.
Reflection
At first glance, the material in the CSOL520 Security Architecture course was perhaps the most intimidating. I was professionally familiar with technical security architecture (building security networks, authentication systems, endpoint system, etc.), but not formal security architecture such as discussed in this course and illustrated through the use of the SABSA enterprise security architecture model and framework.
SABSA is a popular model but is also quite intricate. The 36-cell matrix and model diagram (presented below) each represents a particular subject area or deliverable that the security architect may be required to produce. Each document either provides some sort of reference format on the SABSA website or course text or requires some imagination by the implementer based on the given criteria.
In the end, this course proved to be quite valuable. Thinking about formal security architecture requires the professional to step back and first think of the business as a whole. The Business Risk Model document reflects this interest. An enterprise architecture that fails to account for business needs and concerns is doomed to irrelevance. The modern CISO must be consistently aligned with business goals and interests.
The conceptual security architecture document drills down a level and maps business drivers and requirements to assets, motivation, process, people, location, and time. This document answers the classic “W” question of who, what, when, where, why, and how for the business.
The logical security architecture document chosen describes a logical level deployment of a security monitoring service at an example corporation. Rather than dive into specific products or techniques, it addresses the requirement for logical security controls that form a cybersecurity protective mesh over the business.
The physical security architecture document is intended to take design objectives laid out at the higher logical level and implement them as physical systems required to support the workload. This assignment explored building a physically resilient architecture that is designed to survive multiple component failures to ensure service continuity.
Finally, the 36-cell matrix and SABSA diagram are shown as presented on the SABSA site and in the Enterprise Security Architecture text.
By building out many of the documents required in an enterprise security architecture, I gained a greater understanding of the type of thought processes required to align cybersecurity with high-level business strategy. I also learned how to think at the logical and conceptual levels (the latter was the focus of my final project). I believe that these levels are specifically important when a cybersecurity director or Chief Information Security Officer (CISO) reviews current and future capabilities to address business requirements and risks. The leader at this level is not concerned with specific implementation details but instead focuses on capabilities and controls, which will form a functional protective barrier to defend the organization. Being able to think, speak, and present around the interactions between the capabilities and always mapping back to the business's interests and requirements is key to the success of a cybersecurity leader. Furthermore, this leader is ethically required to act in the best interest of the business in protecting its important data. A person lacking fluency in these architectural concepts may not be up to the challenge of defending the modern enterprise.
I ultimately enjoyed this course and expanded my knowledge of this new cybersecurity discipline greatly.
SABSA: Contextual Security Architecture - The Business View
The Contextual layer of the SABSA model describes the highest-level business requirements and objectives for building a security architecture (Sherwood et al., 2019). It is a prerequisite for other layers as it is essential to understand the purpose behind the architecture as well as the high-level goals and constraints. The high-level goals here are recorded for use in the next layer.
SABSA: Conceptual Security Architecture - The Architect’s View
The Conceptual layer takes high-level information from the business view above and defines the principles and concepts that will be applied in selecting the logical and physical elements used in the security architecture by subsequent layers. Here the architect defines control objectives based on their knowledge and discovery of business risk and defines strategies to mitigate against this risk (Sherwood et al., 2019).
SABSA: Logical Security Architecture - The Designer’s View
The Designer’s role in the Logical layer is to take the high-level objectives and strategies of the architect and map them into logical component pieces of a design (Sherwood et al., 2019). At this point, specific logical and physical systems have not been identified, but the logical roles that systems should play in the architecture are described as abstractions.
SABSA: Physical Security Architecture - The Builder’s View
The role of the Builder in the Physical layer is to take the logical system abstractions provided by the Designer and map to the physical mechanisms and systems that will implement the design. The Designer takes abstract concepts and selects systems, data structures, logic, etc. in service of the delivery of the architecture (Sherwood et al., 2019). The Designer will not necessarily know how to actually implement each of these systems and will rely on the tradespeople described below to implement.
SABSA: Component Security Architecture - The Tradesman’s View
The Tradesperson is really representative of teams of domain experts that are needed to take the choices of the Builder and implement the concepts, logic, and systems required to deliver a secure and well architecture information system to the business. These deliverables are inclusive of hardware, software, and services (such as software-as-a-service in the modern era). The Tradesperson will require the support of the facilities manager to house and secure the systems they implement.
SABSA: Operational Security - The Facilities Manager’s View
The Facilities Manager layer represents the ongoing operations capability to sustain the secure information systems implemented by the Tradesperson. It represents both the physical (asthe name implies) and the logical continuation of the service (Sherwood et al., 2019). This includes various maintenance and administrative tasks to preserve the function of the system.
SABSA: 36-Cell Matrix
References
Sherwood, J., Clark, A., & Lynas, D. (2019). Enterprise Security Architecture: A Business- Driven Approach. Routledge.