Security Architecture
Security Architecture Artifacts
Security Architecture artifacts are key for maintaining consistency and tractability in security design as they provide the foundation for the basis of enterprise security architecture. Throughout the course we learn that these artifacts make sure that the security architecture design has an overarching view by defining principles, policies and standards by which a system will be designed and built. Without security architecture artifacts, the structure would not be strong and business requirements and benefits will not be met. So when looking to identify these artifacts, an information security professional would be able to utilize the Sherwood Applied Business Security Architecture (SABSA) framework.
SABSA
When looking to adopt a framework and methodology for your enterprise security architecture it would be recommended to utilize a well-known and trusted solution, that framework is the SABSA. This framework originated as a tool to be used in informational risk, assurance, and security domains and is now the leading methodology when developing a business operational risk architecture. It’s important to note that SABSA is not intended to compete or replace other risk-based standards or methods. It’s intent and use are to provide an overarching framework to assist all other existing standards. Think of it as an add-on to an already good productivity software that makes it even easier to use.
The SABSA Model embeds itself into the whole life-cycle of operational capabilities through its six layers. SABSA is comprised of six layers, Contextual, Conceptual, Logical, Physical, Component, and Operational (or service management). For each of these horizontal layers there are is also a vertical analysis based on the six questions. Those being What (Assets), Why (Motivation), How (Process), Who (People), Where (Location), and When (Time)? As shown in the diagram below:
Security Architecture artifacts are key for maintaining consistency and tractability in security design as they provide the foundation for the basis of enterprise security architecture. Throughout the course we learn that these artifacts make sure that the security architecture design has an overarching view by defining principles, policies and standards by which a system will be designed and built. Without security architecture artifacts, the structure would not be strong and business requirements and benefits will not be met. So when looking to identify these artifacts, an information security professional would be able to utilize the Sherwood Applied Business Security Architecture (SABSA) framework.
SABSA
When looking to adopt a framework and methodology for your enterprise security architecture it would be recommended to utilize a well-known and trusted solution, that framework is the SABSA. This framework originated as a tool to be used in informational risk, assurance, and security domains and is now the leading methodology when developing a business operational risk architecture. It’s important to note that SABSA is not intended to compete or replace other risk-based standards or methods. It’s intent and use are to provide an overarching framework to assist all other existing standards. Think of it as an add-on to an already good productivity software that makes it even easier to use.
The SABSA Model embeds itself into the whole life-cycle of operational capabilities through its six layers. SABSA is comprised of six layers, Contextual, Conceptual, Logical, Physical, Component, and Operational (or service management). For each of these horizontal layers there are is also a vertical analysis based on the six questions. Those being What (Assets), Why (Motivation), How (Process), Who (People), Where (Location), and When (Time)? As shown in the diagram below:
Conceptual
Conceptual, or architecture view, is the overall concept by which the business requirements of the enterprise may be met. This is where we focus on the business attributes of the concept and what those will be so we can capture then in a normalized form. Once we have these, we then need to know why the protection of these business needs are required and how we want to achieve the protection. After these are identified we can then choose where we want to achieve the protection in terms of our security domain and then when is the protection relevant. Only after these six questions are answered can we then begin to logically lay out our design.
Logical
As we now have our business and architecture views identified, it is now time to put those pieces into a logical, or designers view, interpretation from the architect. When creating this logical portion of the security architecture, we are concerning ourselves with representing all of the major security strategies in the conceptual security architecture. This should help address what information represented is secured, why specific security policies are required, how the logical security services fit together, along with who the entities are that are being secured. As those are identified we can then look at where the domain and inter-domain relationships are and when those security measures begin. Once the logical abstractions are created, they can then be handed off to the physical layer.
Physical
The physical layer, or builders view, is where we take the logical design of our secure information system architecture and turn it into a physical model to describe the actual technology used and specify the functional requirements of all the various system components within it. When looking to create that physical security architecture we look to identify what our business data model is. This could be digital certificates, data tables, etc. These are important to express why specific rules are in place to drive the logical decision-making in our system and how those security mechanisms will be hosted. How they will be hosted can drive who the personnel will be integrating our security applications and where they will live within our infrastructure. Our tradesman view will further expand on our personnel dependencies. These dependencies will also drive when these security mechanisms will execute their control throughout the systems life cycle.
Component
Our Component, or tradesman’s view, is assembling the right personnel to achieve success in building our secure system architecture. This view will heavily rely on the previous views to properly identify what our data structure may look like, why we have security standards in place and how to properly integrate them, who will integrate those products and tools within our secure hardware and software, where our tools will live from a computational aspect, and when those tools will execute based on timing and sequencing. This view along with all subsequent views allow our operational view to ensure the system is working as intended.
Operational
Our operational, or service management view, concerns itself with the overall system operations. Specifically, the security-related components and their functionality. This includes what the system is doing, does it do what it’s supposed to do from an operational continuity standpoint. Along with managing the operational risks to minimize failures or outages, it does this by performing security r-related operations like monitoring, administration tasks, logging, etc. It addresses who will be providing operational support for the security-related needs of the users and applications by identifying where the system integrity and security of said operational platforms live and when they are being used. What makes this view special, is its ability to expand its view to cover each of the other five layers to interpret the operational layer to be apart of each of them.
Conceptual, or architecture view, is the overall concept by which the business requirements of the enterprise may be met. This is where we focus on the business attributes of the concept and what those will be so we can capture then in a normalized form. Once we have these, we then need to know why the protection of these business needs are required and how we want to achieve the protection. After these are identified we can then choose where we want to achieve the protection in terms of our security domain and then when is the protection relevant. Only after these six questions are answered can we then begin to logically lay out our design.
Logical
As we now have our business and architecture views identified, it is now time to put those pieces into a logical, or designers view, interpretation from the architect. When creating this logical portion of the security architecture, we are concerning ourselves with representing all of the major security strategies in the conceptual security architecture. This should help address what information represented is secured, why specific security policies are required, how the logical security services fit together, along with who the entities are that are being secured. As those are identified we can then look at where the domain and inter-domain relationships are and when those security measures begin. Once the logical abstractions are created, they can then be handed off to the physical layer.
Physical
The physical layer, or builders view, is where we take the logical design of our secure information system architecture and turn it into a physical model to describe the actual technology used and specify the functional requirements of all the various system components within it. When looking to create that physical security architecture we look to identify what our business data model is. This could be digital certificates, data tables, etc. These are important to express why specific rules are in place to drive the logical decision-making in our system and how those security mechanisms will be hosted. How they will be hosted can drive who the personnel will be integrating our security applications and where they will live within our infrastructure. Our tradesman view will further expand on our personnel dependencies. These dependencies will also drive when these security mechanisms will execute their control throughout the systems life cycle.
Component
Our Component, or tradesman’s view, is assembling the right personnel to achieve success in building our secure system architecture. This view will heavily rely on the previous views to properly identify what our data structure may look like, why we have security standards in place and how to properly integrate them, who will integrate those products and tools within our secure hardware and software, where our tools will live from a computational aspect, and when those tools will execute based on timing and sequencing. This view along with all subsequent views allow our operational view to ensure the system is working as intended.
Operational
Our operational, or service management view, concerns itself with the overall system operations. Specifically, the security-related components and their functionality. This includes what the system is doing, does it do what it’s supposed to do from an operational continuity standpoint. Along with managing the operational risks to minimize failures or outages, it does this by performing security r-related operations like monitoring, administration tasks, logging, etc. It addresses who will be providing operational support for the security-related needs of the users and applications by identifying where the system integrity and security of said operational platforms live and when they are being used. What makes this view special, is its ability to expand its view to cover each of the other five layers to interpret the operational layer to be apart of each of them.
CSOL 520 Reflections
Having never worked with the SABSA framework before in my professional career, this was invaluable information to learn. More importantly being able to dive in and work to fully understand each layer while being able to identify the key questions of what, why, how, who, where, and when in respect to each layer was especially helpful when learning the framework. As a student or working professional (or both in my case), being able to understand the life-cycle of a proven security architecture framework that is widely adopted throughout multiple industries will only help in widening your understanding and effectiveness in providing a more effective secure information system. When utilizing the SABSA framework, I've come to understand this is not some step-by-step guide on how to design a secure system. While, sure it does offer some level of guidance, it allows security professionals to have a blank slate of sorts in which to see their required secure system to fruition. The CSOL 520 course offered a very high level overview of the framework while providing a substantial amount of effective content within the learning modules to allow myself and other students a means of applying the framework within a fictional company. After taking this course I feel a student can come out with not only a better understanding of IT and Operational integrations, but a more holistic view of the business process when designing a secure system.
Security Architecture References
Enterprise security architecture a business-driven approach
SABSA Executive Summary
SABSA architecture and design case study
Enterprise security architecture a business-driven approach
SABSA Executive Summary
SABSA architecture and design case study