Running head: Constructor Security Architecture 1
SABSA – The Builder’s View
G. Logan Gombar
University of San Diego
Ms. Michelle Moore
Constructor Security Architecture 2
Contents
SABSA – The Builder’s View.............................................................................................3
Layer Overview & Case Study Relation.............................................................................3
Case Study Background...................................................................................................3
Physical Layer Summary.................................................................................................4
Layer Inputs.........................................................................................................................4
Business Data Model.......................................................................................................5
Security Strategies & Break-out Documents...................................................................5
Security Services.............................................................................................................5
Layer Deliverables & Relevant Steps..................................................................................6
Updated Business Data Model.........................................................................................6
Security Rules, Practices, Procedures and Mechanisms..................................................7
Applications and User Communities...............................................................................8
Physical Layout of the Devices.......................................................................................9
Capacity Planning............................................................................................................9
Resilience Model.............................................................................................................9
Summary............................................................................................................................10
References..........................................................................................................................11
Constructor Security Architecture 3
SABSA – The Builder’s View
The Builder’s View of the SABSA framework focuses on the physical layout of the
security architecture, along with the functional requirements definitions. The Builder’s View also
goes by the name Constructor View and the Physical Architecture Context. This paper will
examine a case study completed by the SANS Institute on overall better network design that a
small, anonymous company eventually accomplished. This case study is included in PDF format
in Appendix A, for reference. This paper will go through a basic overview of the Physical layer,
how it relates to the case study, and then onto a section of inputs and deliverables for this layer.
The set of inputs and deliverables listed here is not comprehensive, and covers what the client
would deem useful and therefore what would be employed by them.
Layer Overview & Case Study Relation
The Physical layer is the “brick and mortar” (Sherwood, 2005, p. 331) of the process.
This process includes a discussion on capacity management, the number of machines on the
network, and how they’re physically protected. This layer is where concepts begin to take
concrete shape, where the previous four layers of conceptualizing actually become relevant. This
section will discuss the 5 W’s of this layer, and how each relates to the case study at hand.
Case Study Background
The SANS Institute case study “Securing the Gold through Better Network Design: A
Case Study” discusses the evaluation of a small, unnamed company’s network, and provides a set
of recommendations and final design proposal (Sheppard, 2003). This report will take the
“Before Network Redesign” section and related diagram, fabricate inputs for the Physical layer
from those items, and develop the deliverables expected of the Physical layer steps. Further, any
similarities with the “Network Redesign” will be called out where applicable.
Constructor Security Architecture 4
Starting the evaluation, the case study discusses the different operating systems on the
network and the infrastructure already in place. It dives deeper with the types of protocols used
across the network, and then an evaluation of password security and other types of security
policies in the company. The scrutiny continued with discussion of the firewall, backup
procedures, and the physical security in place (Sheppard, 2003). Overall, a professional didn’t
clearly didn’t design this network, and it grew organically as need dictated. The lack of concern
for security is clearly shown in the overarching state of the enterprise.
Physical Layer Summary
This layer is where the conceptual rubber meets the road of reality. The previous layer,
the Logical Layer, provided a series of outputs used as inputs into this layer, with one output
being security services and policies that need physical employment. The use of the word
“physical” is a bit liberal and misleading, however. This layer includes typical physical security
like doors, locks, and passcodes, but also includes discussion for the implementation of specific
cryptographic algorithms. The prescriptive book on this framework has the Physical layer
chapter discussing the specific SQL commands (Sherwood, 2005, p. 334) and RAID types
(Sherwood, 2005, p. 341), clearly demonstrating the large scope of this layer expanding beyond
just physical. Another major consideration of this layer is a discussion of the business rules,
procedures and practices that will be used to implement the specific controls and processes.
Generally, this layer is comprised of the steps needed to bring the concepts discussed in the
previous four layers out of pure documentation and into the real world, to a degree.
Layer Inputs
The Physical layer has a series of inputs that drive the development of further work. The
Logical layer outputs several of these, and others come from previous layers. The relevant
Constructor Security Architecture 5
deliverables are discussed below, with the information extracted from the case study document
where possible, parts are fabricated as needed, and the data is put into the deliverables. This
document doesn’t cover every input, just items relevant to the deliverables selected below.
Business Data Model
The Business Data Model (BDM) details specific data types and formats for use across
the enterprise. This document is “assumed to be a pre-existing model” and not something the
security team needs to develop (Sherwood, 2005, p. 332). There are security mechanisms in this
document that may need implementation, hence why this is an input at this layer.
Security Strategies & Break-out Documents
The Conceptual layer feeds the overarching strategy and break-out documents into this
process, per the Sherwood book on the topic (Sherwood, 2005, p. 121). These documents act as
the left and right bounds within which the more detailed specifications must occur. Taking these
documents as a guide, further security documentation can be developed. As the case study at
hand has no high-level guidance that could be interpreted as a directive, some will need to be
fabricated here. The main, overarching security strategy that will impact the Physical layer is to
keep data as secure as is needed while still enabling business operations.
Security Services
This is the main input that drives work in the Physical layer. The other inputs (strategies,
policies, architectures) put the framework in place and put the boundaries up, but the security
services are where the actual requirements begin to form. In terms of the case study, there
weren’t requirements put in place in the “Before Network Redesign” section, as it was just a
snapshot evaluation of the situation. Because of this, security service requirements will need to
be fabricated here. For this discussion, the Logical layer provided a deliverable containing the
Constructor Security Architecture 6
need for the following security services as input into the Physical layer: entity authentication,
data backups, and physical system security. This is a limited sub-section of the full list of
services that could be considered during this phase, and the below documentation reflects that.
Layer Deliverables & Relevant Steps
The following sections provide a discussion on the steps needed to work through the
Physical layer process, and the deliverables each step provides to the next layer. They will
reference the case study where applicable, but due to the imposed limitation of using only the
“Before Network Redesign” section, and having no access to the unnamed company’s Chief
Technology Officer, there is limited extra data for use in the following steps.
Updated Business Data Model
The first step examined here is the need to update the BDM. This report will be focusing
on the high-level items the Sherwood book delineates as relevant for this particular document at
this layer, including “file structures”, “file management tools”, “database structures”, and
“database management systems” (Sherwood, 2005, p. 332).
From the perspective of discussing file structures and management tools, there isn’t any
discussion in the case study at all. Given most organizational file structures are fluid, and change
day-to-day, defining this granularly can be problematic. However, something does need to be put
in the BDM. Therefore, all organizational documents will be stored on an encrypted network
drive protected by Discretionary Access Control protocols built into the operating systems
(Windows and Unix). Further, requiring file encryption continues down this vein of privileged
access only, adding on confidentiality and integrity protection. These updated pieces of
information are now part of the BDM deliverable.
Constructor Security Architecture 7
Databases and their relevant systems are a staple of most organizational systems in use
today. The persistence and accessibility of data across time and disparate locations are the main
driving forces in this situation. Having well-defined and rigorously enforced database schemas
can help keep a business running smoothly, and well-documented database structures enable
greater speed and flexibility in development of new business requirements in the future.
Therefore, defining this properly ensures one less roadblock in the future during new projects.
Further, adding the need for specific database management systems, security mechanisms, and
services is one further step towards a secure enterprise. Therefore, the BDM now has a stated
need for a secured database management system to be implemented across the enterprise.
Security Rules, Practices, Procedures and Mechanisms
This deliverable would be a listing of the needed items, without any substance to them
yet. Per the Sherwood book, these will not be written at this stage, but just listed out, and “only
certain procedures and practices” will be listed (Sherwood, 2005, p. 122). Rules are hard and
fast, with no room for interpretation. They are typically automated and enforced by systems such
as firewalls and applications. Practices and procedures are similar to one another, but slightly
different. Practices define the what to do, the general and generic steps. This differs from a
procedure because a procedure is a “documented step-by-step” set of what to do (Sherwood,
2005, p. 341). These are different than rules in they may have room for interpretation.
To enable the desired security services, there are some simple rules, practices, and
procedures that can be put in place. Starting with entity authentication, implementing a Public
Key Infrastructure dual-factor authentication system provides a set of automated rules for entity
authentication. Related practices would include not leaving a secondary authentication device
unattended, with a procedure and mechanism for login being that there is a username, password,
Constructor Security Architecture 8
and secondary authentication source such as a smartcard. Moving onto data backups, using an
automated backup system can enable very strong automated recovery options. The practice of
implementing backup systems is ideal, and the procedures used would be defined given a
specific application of backup software. Further extrapolation of implementing this backup
system would be mechanisms for media rotation, disposal, and storage. Physical system security
is simple enough, as it’s very tangible and thus easier to understand. Putting the servers in a
specific room with a lock is similar to a “rule” in that the lock isn’t leaving much room for
interpretation. The practice of physically securing your hardware with a lock every day, and the
procedures of locking the door every day, are almost identical in this scenario. For these reasons,
the server and database hardware will be locked in a secured server room, with limited access
granted to a specified group of authorized people who must use a proximity badge system to
authenticate themselves prior to entry. This can feed into logs for event tracking, as an added
bonus. This is a typical mechanism used for increase physical security of network related items.
Applications and User Communities
A significant issue in the case study is the lack of user and application security. The best
manner with which to solve this issue is to implement a Role-Based Access Control style
permissions schema. By creating a set of general groups, many security issues can be solved by
following the Principle of Least Privilege. The first groups to create would be as follows:
administrators, basic users, third-party users, automated business systems, automated security
systems, and external entity systems. These groups can be mapped to groups of permissions all
across the enterprise, and handled through an Active Directory implementation. These
permissions include file access, directory control, database permissions, server access rights, and
authentication requirements. Utilizing this centralized authentication system (Active Directory),
Constructor Security Architecture 9
all actions can be checked against permission levels prior to execution, ensuring a higher level of
security.
Physical Layout of the Devices
While most of this report can be discussed in some level of detail using the case study as
a jumping-off point, with a deliverable at the end, this section cannot be done as such. Without a
context of what the actual building looks like, there is no way to diagram out or describe where
devices are going to be placed. As the physical security piece was already described in the
Security Mechanisms section, and there is no way to reasonably discuss this concept without
entirely fabricating an entirely false building, organizational structure, office layout, employee
roster, wiring diagrams, network throughput requirements, average user data consumption, and
the like, this deliverable will not be done for this report. For the discussion on the types of
devices in those places, this is a case study on a network redesign. The equipment will be kept to
reduce business costs and accelerate the redesign effort forward.
Capacity Planning
The current capacity of the network at hand, as described in the case study, is good
enough as it stands to handle the currently expected traffic load. This goes along with the above
statement of keeping the same equipment, as the desired effects of this project are to increase
security through entity authentication, data backups, and physical system security.
Resilience Model
As a business, it is crucial to always be considering the impacts of every potential event.
This inherently leads to a need for redundancy and resilient configurations. Resiliency can be
attained through a series of avenues. In this case study, the easiest steps forward toward a
resilient network model in line with the security services focus on automated backups of data and
Constructor Security Architecture 10
automated recovery, given they have only rudimentary, and failing backup systems (Sheppard,
2003). By implementing automated backups and recovery, there is a copy of the data to fall back
on in the event of a partial to total data loss event. Further resiliency can be attained through
avoiding single points of failure, such as a single instance of the database server. Implementing a
multi-site, geographically disparate database setup would be an ideal goal for a future project to
increase resiliency in the network.
Summary
This report took the case study presented by the SANS Institute on how they redesigned a
small, private company’s network infrastructure, and attempted to use that to create the Physical
layer deliverables that could have been created during this process, if the SANS Institute used
this framework. It went through the steps of the layer, how it acted on the inputs, and generated
the deliverables. The overarching goal was to implement services for entity authentication, data
backups, and physical security of specific network devices. This was accomplished by discussing
the rules, practices, procedures, and mechanisms of implementing these services, as well as the
side effects of some of them, and how these efforts could be further enhanced down the line via
other services. The deliverables of this layer would feed into the next layer, the Component layer,
and provide further guidance on how the systems need to be implemented.
Constructor Security Architecture 11
References
Sheppard, T. (2003, June). Securing the Gold through Better Network Design: A Case Study. SANS
Courses, Certifications & Research. https://www.sans.org/reading-
room/whitepapers/casestudies/securing-gold-network-design-case-study-1183
Sherwood, N. A. (2005). Enterprise security architecture: A business-driven approach. CRC Press.
Constructor Security Architecture 12
Appendix A
Case Study Embedded PDF
securing-gold-netw
ork-design-case-study-1183.pdf
