CSOL-520, Secure Systems Architecture, Summer 2019
I was introduced to the notion of SABSA architecture through CSOL-520, Secure Systems Architecture, during Summer 2019 with professor Thomas Plunkett.
Security Architecture artifacts are valuable tools for maintaining consistency and traceability in security design because the architecture concept is at the center of big realizations. My father told me that in their times, to enable cars to cross a river, they did not complicate themselves; they just cut a couple of big trees and roll them over the river. That is it, and cars can start crossing; this did not require any architecture design. But how about building a bridge of the size of the Golden Gate Bridge in California. This one certainly will require some architecture design as a lot of things and group of people with varied expertise will be involved so that all things come together. It is a huge undertaking, and this is where architecture comes into play, where a layered approach will be used to reach the goal.
With layered approach, specific steps are to be completed by individuals based on their expertise. The same concept is relevant to Security Architecture. To enable a successful implementation of information security, an architecture will be necessary to ensure consistency and traceability. The good thing in construction industry is that architecture design has proved to be instrumental in building complex structures. So, security will rely on this expertise and put forth their security architecture by leveraging some models, the Sherwood Applied Business Security Architecture (SABSA) model for example.
The SABSA model comprises six layers that follow closely the work done by John A. Zachman, which was adapted to the security view. The following table is the adaptation of enterprise architecture.
Table 1: SABSA Model Layered Architecture
At each layer of the model, the owner addresses six questions: What, Why, How, Who, Where, and When; hence, the following 36-Cell SABSA Matrix:
Table 2: SABSA Matrix
Contextual Security Architecture and Business Requirements
The Contextual Security Architecture is also called the Business View; it is mainly used to define business requirements that must be met by the architecture (Clark, Lynas, & Sherwood, 2005, p.35). A clear understanding of the business requirements will help to answer the questions about what type of information system is it and what will it be used (Assets to protect), why it will be used (Business risks expressed in terms of assets), how it will be used (processes), who will use it (management structures, supply chains, etc..), where should it be used (Location-related aspects of business security), and when it will be used (Time-related aspects of business security).
Clark, A., Lynas, D., & Sherwood, A. (2005). Enterprise Security Architecture: A Business-Driven Approach. Boca Raton. FL: Taylor and Francis, p.35.
Conceptual Security Architecture and Business drivers
After business requirements are well defined, now the time comes for an Architect to start making sense to the requirements put forward in the business view phase. The Architect's View is related to Conceptual Security Architecture in the SABSA model.
The architect is an individual with creative thinking who relies on skill, experience, and vision to do his part of the work so that he comes up with something meaningful based on business requirements (Clark, Lynas, & Sherwood, 2005, p.37). He will come up with concepts that will guide the selection and organization of the logical and physical elements at the lower layers of abstraction. Concepts and principles to be used are described. For example, what is that being protected, why should we protect it (business drivers), how it will be done, or the strategies to be used, who will be involved in security management, where do we want to achieve protection, when is protection-relevant over time.
Clark, A., Lynas, D., & Sherwood, A. (2005). Enterprise Security Architecture: A Business-Driven Approach. Boca Raton. FL: Taylor and Francis, p. 37
Logical Security Architecture
After the Architecture has come up with concepts as described above, a designer with a design’s view is called in. This view is related to Logical Security Architecture in the SABSA model.
The Designer's role is to interpret the architect's vision and turn it into a logical structure. He produces a set of logical abstractions that describe the system to be built. The result will show the major architectural security elements in terms of logical security services. This logical security will respond to what is logical, why securing business information, how to specify the logical security services, who are the entities, where are different associations of security domains and inter-domain, and when will respond to question about the processing cycle.
Clark, A., Lynas, D., & Sherwood, A. (2005). Enterprise Security Architecture: A Business-Driven Approach. Boca Raton. FL: Taylor and Francis,
Physical Security Architecture
Following the work from the designer, the builder will take over. He will turn whatever results from the Designer into something physical that describes the actual technology model; this is the reason it is called Physical Security Architecture in the SABSA model.
Again, here are the answers to the questions: what business data model and security-related data structures. Why for rules that drive the logical decision-making, how to dig on security mechanisms, “who” to specify the people dependency in the form of the users, “where” to provide security technology infrastructure and “when” for the time in the form of execution control structures. The builder will be in charge, so to speak, of assembling a series of products from specialist vendors and a team with integration skills.
Clark, A., Lynas, D., & Sherwood, A. (2005). Enterprise Security Architecture: A Business-Driven Approach. Boca Raton. FL: Taylor and Francis.
Component Security Architecture
After the builder has done his job in producing something physical describing the actual technology model, the tradesman's view is now getting involved.
The Tradesman will be important as he will be the one to play the role of integrator that a builder needs to join these different products based on corresponding skills. In the SABSA model, the Tradesman’s view corresponds to Component Security Architecture. It will address what data field specifications, why for security standards, how for products and tools, who to address user identifies, “where” to address inter-process protocols, and when for timing and sequencing.
Clark, A., Lynas, D., & Sherwood, A. (2005). Enterprise Security Architecture: A Business-Driven Approach. Boca Raton. FL: Taylor and Francis
Operational Security Architecture
As the whole structure is now completed, a facility manager should take over to manage it. In the SABSA model, this role is called operational security architecture. In this, the focus is on security-related areas of the structure (Clark, Lynas, & Sherwood, 2005, p.40). But, due to its nature, operational security is being applied to every step of the layer from Contextual to Component Security Architecture.
In the security architecture, what responds to ensure the operational continuity of the security system, why is to manage operational risks, how is to perform specialized security-related operations, who is providing operational support for security-related needs for users, and where is for maintaining the system integrity and when respond to scheduling security-related operations.
Clark, A., Lynas, D., & Sherwood, A. (2005). Enterprise Security Architecture: A Business-Driven Approach. Boca Raton. FL: Taylor and Francis, p. 40
During the summer of 2019, I have learned what Security Architecture is all about through CSOL-520- Secure Systems Architecture class with Professor Thomas Plunkett. It was a bit abstract in the beginning but the more we did projects and going through class material, the more it started making all sense.
It all comes down to the application of architecture as it is applied in construction industry. In a nutshell, Architecture is a set of rules and conventions that we need to apply sometimes in complex undertakings. Cybersecurity, as time goes by, is becoming more complex due to challenges businesses are facing every day in the face of increased security breach incidents. By following a set of rules and conventions, businesses can now start applying the rules that the construction business follows to avoid costly incidents.
I remember the Target breach incident of 2013, after understanding what happened, I"m convinced if security architecture was developed and in place, it would have mitigated the risk of it occurring (Krebs, 2013). When applying the SABSA model in the case of Target, business requirements should have been formulated, business drivers defined and business attributes isolated. After these are isolated, now comes the need to assess the threat and the impact, and perform a vulnerability assessment.