Security Architecture
| #CSOL
The security architecture artifacts are valuable tools for maintaining consistency and traceability in security design because they break up the complexity to present greater simplicity and thus make the design activity more comfortable to manage. One of the ways to simplify complexity is to create architectural reference models that use layering of functionality for less-complex conceptual layers.
Security Service Management Architecture - Image place-holder
The Sherwood Applied Business Security Architecture (SABSA®) model is a framework and methodology for developing business operational risk-based architectures. The SABSA® methodology guides aligning architecture with business value. The SABSA® model consists of six layers, Contextual (the Business View), Conceptual (the Architect View), Logical (the Designer’s View), Physical (the Builder’s View), Component (Tradesman’s View), and Operational (Facilities Manager’s View).
Security Service Management Architecture - Image place-holder
Each of these layers of the architecture model are supported by vertical analysis based on six key questions: What (Assets), Why (Motivation), How (Process), Who (People), Where (Location) and When (Time).
Security Service Management Architecture - Image place-holder
Contextual
-
Contextual Security Architecture (the Business View).
This layer is the top-level business view which describes the business context in which your secure system must be designed, build and operated. This layer is concered with the following:
What The assets to be protected such as brand, reputation, etc. and the business needs for information security. Why The business risks in terms of assets, goals, success factors, and the threats, impacts, and vulnerabilities that put these at risk, driving the need for business security. How The business process that requires protection. Who The organizational aspects of business security. Where The business geography and location-related aspects of business security. When The business time dependencies and time-related issues of business security in terms of both performance and sequence (Sherwood, Clark, & Lynas, 2005). Once the requirements of the business are captured in the contextual security architecture layer, the architect can begin the work in conceptualizing the business requirements in the next layer. Once the requirements of the business are captured in the contextual security architecture layer, the architect can begin the work in conceptualizing the business requirements in the next layer.
Conceptual
What | |
Why | |
How | |
Who | |
Where | |
When |
Logical
What | |
Why | |
How | |
Who | |
Where | |
When |
Component
What | |
Why | |
How | |
Who | |
Where | |
When |
Physical
What | |
Why | |
How | |
Who | |
Where | |
When |
Operations
What | |
Why | |
How | |
Who | |
Where | |
When |
Reflection
In the Security Architecture course, I learned how the **SABSA® **model provides a framework for developing risk-driven enterprise information security and information assurance architectures to help undertake complex security implementations. The model covers the whole lifecycle of operational capabilities and is made up of six layers that identifies each of the stakeholders and their role in the architecture. Each layer is dependent on the layer above for building a high-level architecture down to the implementation and operations.
The model aligns the architecture with business value, in addition to addressing a critical need for greater integration between security and enterprise architectures within organizations. The SABSA model is an open standard, generic, and vendor-neutral, although it is copyright protected, it is an open-use methodology and not a commercial product. It is owned, governed, protected, and maintained by the SABSA Institute. It is designed for the development of security architectures and can be used by any industry or organization. It can be integrated with TOGAF, ITIL, and COBIT, as well as other governance, compliance, and audit frameworks.
From a professional standpoint, the knowledge I gained through this course will help me interact with di!erent stakeholders at each layer while staying relevant and focused. Understanding what is relevant will help anticipate challenges at each layer and also allows for traceability between the layers. In addition, ethical standards and professionalism should be maintained at all times to protect the team morale.
I would like to leave with this statement from Sherwood, et al.
“Enterprise security architecture must be driven from a business perspective and must take account of a wide range of requirements that may often be in conflict with one other. The successful architecture balances the tensions between these conflicting objectives.”
References
- Sherwood, J., Clark, A., & Lynas, D. (2005). Enterprise Security Architecture a Business-Driven Approach. Boca Raton: CRC Press.
Security Architecture Related Links
- DoDAF Viewpoints and Models
- Enterprise Architecture Center of Excellence (EACOE)
- Enterprise Architecture Frameworks: Documenting Your Roadmap to Change
- Enterprise Security Architecture – A Top-down Approach by Rassoul Ghaznavi-Zadeh
- SABSA Enterprise Security Architecture
- The Fog of war: Security and Cloud Computing with Symantec’s CEO, Enrique Salem at Tuck