Security Architecture
06/09/2021
Why is Secure Systems Architecture Important?
Secure architecture is exceedingly difficult to get right and even harder to get right if you are trying to overlay it on an existing business architecture. Unless security is built-in from the beginning into the very core of the business model, it will suffer from gaps. Attackers don't often go for the front door -- they attack the seams. To minimize seams, we need a proven way of developing security architecture that is flexible across all business types, and ensures a minimum attack surface when properly followed.
Describing the Six Layers of the SABSA Architecture
The SABSA model is a
six-layer approach to developing an enterprise security
architecture. This paper will look briefly at each layer of the model,
discuss the stakeholder view for that layer, the typical questions asked
within the layer, and the inter-relationship between our target layer
and others in the model. The SABSA model uses a top-down development
method moving from abstract concepts to concrete implementation.
Overlaying all five of the initial layers is a sixth "operational
security" layer which must be considered at every phase in the SABSA
model.
Secure architecture is exceedingly difficult to get right and even harder to get right if you are trying to overlay it on an existing business architecture. Unless security is built-in from the beginning into the very core of the business model, it will suffer from gaps. Attackers don't often go for the front door -- they attack the seams. To minimize seams, we need a proven way of developing security architecture that is flexible across all business types, and ensures a minimum attack surface when properly followed.
This course centered around
SABSA Enterprise Security Architecture which does an excellent job of
ensuring security is properly implemented within the business. This
framework and methodology uses a top-down approach that begins with
abstract questions such as "what is important to our business" and moves
all the way to concrete implementation of a specific control.
Secure
architecture is exceedingly difficult to get right and even harder to
get right if you are trying to overlay it on an existing business
architecture. Unless security is built-in from the beginning into the
very core of the business model, it will suffer from gaps. Attackers
don't often go for the front door -- they attack the seams. To minimize
seams, we need a proven way of developing security architecture that is
flexible across all business types, and ensures a minimum attack
surface when properly followed.
Coursework
Describing the Six Layers of the SABSA Architecture The SABSA model is a six-layer approach to developing an enterprise security architecture. This paper will look briefly at each layer of the model, discuss the stakeholder view for that layer, the typical questions asked within the layer, and the inter-relationship between our target layer and others in the model. The SABSA model uses a top-down development method moving from abstract concepts to concrete implementation. Overlaying all five of the initial layers is a sixth "operational security" layer which must be considered at every phase in the SABSA model.
Contextual Security Architecture - The Business View
This is the highest level
of the SABSA model, also known as the "business view". Comparing the
SABSA model with traditional architecture, this phase would determine
what type of building is going to be built. Is it "a domestic house, a
factory, an office block, a sports centre, a school, a hospital, a
warehouse, a theatre, a shopping centre..." etc. (Sherwood, Clark, &
Lynas, 2005, p. 35). Then, having informed what type of building is to
be built the Business View must state why the building is needed, what
problems it solves, how it will be used, where it will be
located. These are all items of context for the solution and therefore
this phase is called the contextual security architecture phase.
In
enterprise security architecture this phase will be concerned with what
business assets are going to be protected, the scope of the protection,
the risk mitigated by protection, and time-based goals for
implementation. This phase interrelates with every other phase in the
model by providing the vision that will drive all decisions made in
subsequent phases of the model. In fact, the other phases could not
exist without the business requirements view first determining what will
be protected.
Conceptual Security Architecture - The Architect's View
The Architect takes the
business requirements from the business view and creates the high-level
description or concept of how the business requirements will be
met. This phase "defines principles and fundamental concepts that guide
the selection and organization of the logical and physical elements at
lower layer of abstraction" (Sherwood, Clark, & Lynas, 2005, p.
37). This is an easy phase to skip but is vitally important to
developing the right security solution.
In the conceptual security architecture phase, we are asking the following types of questions:
The fact that these requirements are similar to other organizations allows us to leverage industry policies and best practices in our logical layer. We can utilize policies developed with respect to the NIST framework or ISO specifications to ensure that our defensive strategies are properly met. In fact, the NIST framework is almost entirely describing logical security services - e.g. "services that are specified independently of what physical mechanism might be used to deliver them" (Sherwood, Clark, & Lynas, 2005, p. 294). In reviewing stackoverflow's logical architecture, we can see how the presentation layer, business logic layer, and data layer all have services identified without a physical mechanism specified. This is the core concept of design at the logical layer. Physical Security Architecture - The Builder's View Taking over from the designer, the builder choses the physical elements that will fill each of the logical building blocks identified in the previous phase. This selection of physical security elements is why this phase is referred to as the physical security architecture. The logical abstractions "need to be turned into a physical security architecture model that describes the actual technology model and specifies the functional requirements of the various system components" (Sherwood, Clark, & Lynas, 2005, pp. 38-39).
Component Security Architecture - The Tradesman's View After the builder has identified all of the concrete components a team of tradesmen can be developed who are subject matter experts in their various domains. If the builder identifies a PF Sense firewall is to be deployed, then the team should include someone well versed in pfsense. These can be employees or independent contractors. The team must also include members with integration skills who are able to tie the whole project together to meet the needs outlined by the Business View.
Questions considered at this phase all from (Sherwood, Clark, & Lynas, 2005, pp. 39-40):
Operations - The Facilities Manager's View Once the development of the enterprise security solution is complete someone needs to run the day to day operational aspects during the lifetime of the developed solution. Reverting back to our building architecture analogy, "the job of the facilities manager is to deal with the operation of the build and its various services, maintaining it in good working order, and monitoring how well it is performing in meeting the requirements" (Sherwood, Clark, & Lynas, 2005, p. 40). The operational security layer is unique in that it needs to be considered at every phase in the SABSA model.
In the conceptual security architecture phase, we are asking the following types of questions:
- What do the business requirements state we must protect?
- Why is the protection important?
- In high-level strategies define how we want to achieve protection?
- Who is involved in security management?
- In terms of security domains, where do we want to achieve protection?
- What points in time and what periods of time are important? When is the protection relevant?
- What security policies are needed or will be met?
- What are the re-usable building blocks for the security solution?
- Who is involved, what are their inter-relationships, attributes, authorized roles, privileges?
- What are the specific security domains, where are they located and what are the inter-relationships between domains?
- What is the security processing cycle?
The fact that these requirements are similar to other organizations allows us to leverage industry policies and best practices in our logical layer. We can utilize policies developed with respect to the NIST framework or ISO specifications to ensure that our defensive strategies are properly met. In fact, the NIST framework is almost entirely describing logical security services - e.g. "services that are specified independently of what physical mechanism might be used to deliver them" (Sherwood, Clark, & Lynas, 2005, p. 294). In reviewing stackoverflow's logical architecture, we can see how the presentation layer, business logic layer, and data layer all have services identified without a physical mechanism specified. This is the core concept of design at the logical layer. Physical Security Architecture - The Builder's View Taking over from the designer, the builder choses the physical elements that will fill each of the logical building blocks identified in the previous phase. This selection of physical security elements is why this phase is referred to as the physical security architecture. The logical abstractions "need to be turned into a physical security architecture model that describes the actual technology model and specifies the functional requirements of the various system components" (Sherwood, Clark, & Lynas, 2005, pp. 38-39).
Component Security Architecture - The Tradesman's View After the builder has identified all of the concrete components a team of tradesmen can be developed who are subject matter experts in their various domains. If the builder identifies a PF Sense firewall is to be deployed, then the team should include someone well versed in pfsense. These can be employees or independent contractors. The team must also include members with integration skills who are able to tie the whole project together to meet the needs outlined by the Business View.
Questions considered at this phase all from (Sherwood, Clark, & Lynas, 2005, pp. 39-40):
Operations - The Facilities Manager's View Once the development of the enterprise security solution is complete someone needs to run the day to day operational aspects during the lifetime of the developed solution. Reverting back to our building architecture analogy, "the job of the facilities manager is to deal with the operation of the build and its various services, maintaining it in good working order, and monitoring how well it is performing in meeting the requirements" (Sherwood, Clark, & Lynas, 2005, p. 40). The operational security layer is unique in that it needs to be considered at every phase in the SABSA model.
Stackoverflow Logical Security Example
Stack Overflow is s handling a very large amount of HTTP requests per day and as a business they need to ensure the validation of the request and handling of the requests are timely. The business requirements from Stack Overflow are largely similar to other online social media companies focusing on ease of use, redundancy, confidentiality of information and speed.The fact that these requirements are similar to other organizations allows us to leverage industry policies and best practices in our logical layer. We can utilize policies developed with respect to the NIST framework or ISO specifications to ensure that our defensive strategies are properly met. In fact, the NIST framework is almost entirely describing logical security services - e.g. "services that are specified independently of what physical mechanism might be used to deliver them" (Sherwood, Clark, & Lynas, 2005, p. 294). In reviewing stackoverflow's logical architecture, we can see how the presentation layer, business logic layer, and data layer all have services identified without a physical mechanism specified. This is the core concept of design at the logical layer. Physical Security Architecture - The Builder's View Taking over from the designer, the builder choses the physical elements that will fill each of the logical building blocks identified in the previous phase. This selection of physical security elements is why this phase is referred to as the physical security architecture. The logical abstractions "need to be turned into a physical security architecture model that describes the actual technology model and specifies the functional requirements of the various system components" (Sherwood, Clark, & Lynas, 2005, pp. 38-39).
Component Security Architecture - The Tradesman's View
After the builder has
identified all of the concrete components a team of tradesmen can be
developed who are subject matter experts in their various domains. If
the builder identifies a PF Sense firewall is to be deployed, then the
team should include someone well versed in pfsense. These can be
employees or independent contractors. The team must also include
members with integration skills who are able to tie the whole project
together to meet the needs outlined by the Business View.
Questions considered at this phase all from (Sherwood, Clark, & Lynas, 2005, pp. 39-40):
Operations - The Facilities Manager's View Once the development of the enterprise security solution is complete someone needs to run the day to day operational aspects during the lifetime of the developed solution. Reverting back to our building architecture analogy, "the job of the facilities manager is to deal with the operation of the build and its various services, maintaining it in good working order, and monitoring how well it is performing in meeting the requirements" (Sherwood, Clark, & Lynas, 2005, p. 40). The operational security layer is unique in that it needs to be considered at every phase in the SABSA model.
Questions considered at this phase all from (Sherwood, Clark, & Lynas, 2005, pp. 39-40):
Operations - The Facilities Manager's View Once the development of the enterprise security solution is complete someone needs to run the day to day operational aspects during the lifetime of the developed solution. Reverting back to our building architecture analogy, "the job of the facilities manager is to deal with the operation of the build and its various services, maintaining it in good working order, and monitoring how well it is performing in meeting the requirements" (Sherwood, Clark, & Lynas, 2005, p. 40). The operational security layer is unique in that it needs to be considered at every phase in the SABSA model.
Reflection
Professional Considerations:As we are evaluating security policies we must realize that they have a large impact on architectural considerations. Let's assume an organization is going to accept credit cards and needs to comply with PCI regulations. One of the architectural impacts is the creation of a separate payment network LAN or VLAN within the organization. By creating the separate network we can exclude computers in IT or Sales or some other department from the PCI scope. This is just one area that PCI impacts, but shows how a security policy can affect overal architecture.
Because security policies affect the overall architecture and how employees go about their day-to-day job, it is very important that those policies match the goals of the organization. We can consider a hypothetcial beach umbrella company with a physical security policy calling for 10 foot walls, concertina wire, and armed security. The two don't really go together and the expense of implementing the security policy would be a complete waste for an umbrella company.
Ethical Considerations:
Secure Systems Architecture might not seem at first to be a morally challenging topic, but let's consider a security practitioner who finds themselves employed at a business which does not have any cohesive framework for architecture design. What should they do?
I think it is important our hypothetical employee point out the primary reasons for secure architectural failure and coach the executive team toward an understanding of why implementing secure architecture design is worthwhile. It WILL slow things down. But it will also ensure a better ecosystem for risk management, information assurance and ongoing operational management.