Running head: Security Architecture Development Process 1
SABSA-Based Security Architecture Development Process
G. Logan Gombar
University of San Diego
Ms. Michelle Moore
Security Architecture Development Process 2
SABSA-Based Security Architecture Development Process
Driver - Control Objective Mapping
The company (Sudo DevTeam) has the following business drivers that map to a given set
of control objectives, shown in Table 1.
ID BD1 BD2 BD3 BD4 BD5
Competitor Customer
Business Driver Policy Litigation Resource prices
Activities demands
Providing return on
Business Attributes Compliance Legal Cost-effective Responsive
investment
Business Comply with Take advantage of Respond in real-
Avoid litigation Reduce costs
Requirement policy competitor missteps time
The company
Non-compliance Costs rise too Become non-
High Level Threat Litigation delays responses
breaks trust high competitive
to customers
Company loses Company pushed
Business Impact Customers leave Customers leave Customers leave
money out of the market
Impact Value H H H H H
Inadequate
Not following Lack of
Potential High- Over-priced Competitors gain response times
policy breaches oversight ends
level Vuln purchases advantage frustrate
trust in legal action
customers
Green Field Vuln
H H H H H
Value
Green Field Risk A A A A A
Implementing
Adding competitor
predictable,
Implementing Onboarding a analysis process and
Adding market achievable
policy review legal team market analysis
High-Level Control research process service level
process results results in process increase
Objectives results in agreements
in compliance reduced return on
reduced costs results in
litigation investment across
satisfied, return
the board
customers
Table 1: Business Driver to High-Level Control Objective Matrix
Security Architecture Development Process 3
Current State of Security
The current state of security for Sudo DevTeam is inadequate, at best. The De-Militarized
Zone that houses the internet-facing webpages doesn’t have the proper access lists and allows for
connections to the internal network. The VPN architecture has not been properly integrated with
Public Key Infrastructure best practices. There are no control review processes and the policies
that would enable secure operations are not in place. The desired end-goal of implementing the
Principle of Least Privilege on the financial servers has not been accomplished. All of these
together are indicative of the abysmal current state of security.
Security Domain Model
The ideal security domain model for the Sudo DevTeam company would be the
honeycomb and concentric egg model, sitting in line with the recommendation of the Enterprise
Security Architecture book (Sherwood, 2005). This is the ideal architecture as it allows for high
security while also allowing a large degree of flexibility.
Security Lifetimes & Deadlines
Security lifetimes and registration requirements being detailed and documented is a
highly integral requirement. Specifically, tracking licensing lifetimes and security certificate
registration timelines will enable financial stability and consistent security coverage through the
consistently upkept lifetimes of these documents. Additionally, the expiration and recreation
registration of passwords and tokens for the network should be tracked and documented to
ensure they are changed over at appropriate times. This will enable greater operational capability.
Extrapolating further on this, policies should have lifetimes as well. Regular review and
updating of security policies is required to ensure the ecosystem is kept healthy and secure.
Security Architecture Development Process 4
Implementing these review processes will keep the ecosystem abreast of any upcoming and new
threats, as well as bringing in new and improved security tactics and techniques.
Entity Model Naming & Trust Framework
To ensure explicit security, a defined trust framework needs to be implemented. A key
step in doing this is to generate a standard format to ensure explicitly unique identifiers for each
and every device and element in the enterprise. Doing this enables the creation of the requisite
trust framework. Creating this trust framework requires definition of the expectations and
assumptions of each step of each process and interaction between every element in every
network. This explicit statement of trust is crucial to the honeycomb and egg structure described
before as it will be what enables that framework. Every relationship provides an implicit level of
trust outright and the explicit statement of it ensure the proper documentation (Sherwood, 2005).
Naming each element in an easily definable and describable manner will enable the creation of
this flexible and powerful framework.
Security Strategies & Architecture Layering
The overarching, desired security strategy for Sudo DevTeam is the idea of defense in
depth, or “multi-layered security”. Defense in depth is the idea of layering multiple security
tactics and techniques that could and should cover the weaknesses in one another (Forcepoint,
2020). This style of security would be applied at each level of the honeycomb/egg architecture to
help work towards a network architecture that is powerful, flexible, and secure. This becomes a
reality as the layers of defenses become more restrictive as the network level becomes more
confidential – the most private data is protected the most, where the working environment is
flexible enough to enable operations.
Security Architecture Development Process 5
References
Forcepoint. (2020, March 24). What is defense in depth? [Link]
depth
Sherwood, J. (2005). Enterprise security architecture: A business-driven approach. CRC Press.
