Join Malcolm Shore for an in-depth discussion in this video Introducing SABSA, part of Cybersecurity with Cloud Computing.
- We've looked at the benefits and the risks of cloud, so now you've got enough information to make an initial informed decision on what's suitable for cloud deployment. It's useful, however, to have a structured way of addressing each of the risks, and defining the controls needed to mitigate them. This is where enterprise security architecture comes in. One of the most popular enterprise security architecture frameworks is SABSA, the Sherwood Applied Business Security Architecture. SABSA is used to capture business requirements and then determine what security is needed to meet those requirements.
In this section, I'll introduce some basic SABSA concepts, so that I can use them in the cloud context, but I'll only scratch the surface of SABSA, there's much more to it than this. The basic construct in SABSA is its architecture matrix. This matrix is used to capture all relevant activities and to make sure that the security architect considers six questions as the architecture is being developed. What? Why? How? Where? Who? And when? If we can answer all these questions, then we've done a pretty good job of completing our architecture.
Developing a security architecture using SABSA starts at the top left, in the Business Decisions box. By understanding the business decisions, the outcomes the business wants to achieve, the security architect is working, not from an abstract sense of security, a common complaint, but from real-world business needs. Once the business outcomes have been documented, then the security architect can look along the contextual row of the matrix at the Motivation, or the why, for doing security. That is, to protect the business outcomes.
This can be protecting a business service from a defined technical attack, or it can be protecting the business from a fine for non-compliance, both are equally valid. The next column is the How, the process involved with the business outcomes. Understanding the processes helps in determining the security risks, and making sure the processes are properly controlled. Likewise for the remaining columns, I won't go through all of them. While the Contextual row sets the business context, the security architect needs to describe the security context for the business, but still in business terms.
This is done by associating with each business requirement, a set of what is known in SABSA, as security drivers. These describe what needs to be done to ensure that the business outcomes are achieved. For example, the business requirement may be to allow online credit card payments. One of the security drivers associated with this would be compliance with pci dss. Another might be, ensure the web portal is continuously available. Once the business context has been set, and the security drivers identified, then the architect can begin to decompose the drivers enhance business needs into a form better suited to identifying the more traditional view of security and controls.
This happens at the left-hand cell of the Conceptual row, the next row down, by decomposing the business drivers into a structure known as a Business Attribute Profile. This captures business knowledge in a form understandable to both the business and the security team, and provides a means of specifying a suitable risk strategy for ensuring business outcomes are successfully achieved. Before we leave, let's take a quick look at the remaining cells in the Conceptual row.
These further describe aspects of the business in a security context. The Risk Management Objective cell is where Control Objectives are determined in order to mitigate the risks identified against each of the attributes. Enablement Objectives are similar to Control Objectives, but reflect security improvements, that, if made, would allow some business opportunity to be taken. At this point, the security architect would also start developing Security Policy Documentation. The next cell is where the key security strategies are created and Process Assurance is defined.
It's at this point that process decomposition takes complex processes and describes them as a set of coherent, simpler process, which can be more easily assured. The Roles and Responsibilities cell is where the architect sets up the frameworks for understanding who is accountable for each business outcome, and who is responsible for each of the processes necessary to achieve them. This is where raci charts are developed, and information ownership and custodianship defined. The Domain Framework cell is where the business is conceptualized as a set of domains, with policy authorities managing each domain.
For example, Finance would be a domain owned by the CFO, IT would be a domain owned by the CIO. This cell looks at the domain interactions. For example, the CFO owns the financial information, but the finance system is owned and run by the CIO. Understanding these relationships is important for clarity of decision making. The Time Management Framework is where the life-cycle of risk management and process maturity are considered. It's also where business performance measurements and specifically metrics and measurements of business outcomes, is defined.
Once the conceptual view of the business is complete, the more technical aspects of developing and implementing the security architecture can begin.
- Essential cloud concepts: infrastructure, deployment models, and more
- Defining trust models for clouds
- Identifying governance and risk
- Complying with legal and audit requirements
- Managing incident response
- Maximizing application security
- Managing encryption and keys
- Implementing virtualization
- Introducing SABSA and the cloud attribute taxonomy