University of the CumberlandsSchool of Computer & Information .docx

University of the Cumberlands
School of Computer & Information Sciences
ISOL-536 - Security Architecture & Design
Chapter 5 - Prepare for Assessment
Chapter 5 - Prepare for Assessment
5.1 Process Review
5.1.1 Credible Attack Vectors
5.1.2 Applying ATASM
5.2 Architecture and Artifacts
5.2.1 Understand the Logical and Component Architecture of
the System
5.2.2 Understand Every Communication Flow and Any Valuable
Data Wherever Stored
5.3 Threat Enumeration
5.3.1 List All the Possible Threat Agents for This Type of
System
5.3.2 List the Typical Attack Methods of the Threat Agents
5.3.3 List the System-Level Objectives of Threat Agents Using
Their Attack Methods
Chapter 5 - Prepare for Assessment – Cont.
5.4 Attack Surfaces

5.4.1 Decompose (factor) the Architecture to a Level That
Exposes Every Possible Attack
Surface
5.4.2 Filter Out Threat Agents Who Have No Attack Surfaces
Exposed to Their Typical
Methods
5.4.3 List All Existing Security Controls for Each Attack
Surface
5.4.4 Filter Out All Attack Surfaces for Which There Is
Sufficient Existing Protection
5.5 Data Sensitivity
5.6 A Few Additional Thoughts on Risk
5.7 Possible Controls
5.7.1 Apply New Security Controls to the Set of Attack Services
for Which There Isn’t
Sufficient Mitigation
5.7.2 Build a Defense-in-Depth
5.8 Summary
Chapter 5: Summary
Information assurance is achieved when information and
information systems are
protected against attacks through the application of security
services such as availability, integrity, authentication,
confidentiality, and nonrepudiation. The application of these
services should be based on the protect, detect, and react
paradigm.
This means that in addition to incorporating protection
mechanisms, organizations need to expect attacks and include
attack detection tools and procedures that allow them to react to
and recover from these unexpected attacks.

5.1 Process Review
At the highest level, an assessment follows the mnemonic,
ATASM:
Architecture ➤ Threats ➤ Attack Surfaces ➤ Mitigations
Figure 5.1 shows the ATASM flow graphically. There are
architecture tasks that will help to determine which threats are
relevant to systems of the type under assessment.
Figure 5.1 Architecture, threats, attack surfaces, mitigations.
5.1.1 Credible Attack Vectors
Credible attack vector: A credible threat exercising an exploit
on an exposed
vulnerability.
Recalling the risk term discussion from Chapter 4, a CAV
encapsulates the three threat sub-terms into a single expression:
Threat
Exposure
Vulnerability
Risk is the critical governing principle that underlies the entire
risk assessment and threat modeling process. Ultimately, we
must mitigate those computer attacks that are likely to impinge
upon the use of the system under assessment and upon efforts to
obtain the objectives of the organization.

Table 5.1 summarizes the typical background information an
assessor brings to an assessment. These topics have been
arranged with the “3 S’s” merely for convenience and to provide
an ordering principle.
No matter how one may choose to order these topics, it remains
that before beginning an ARA and threat model, one will need
to have examined the current threat landscape into which the
system will be deployed.
– Cont.
Figure 5.2 orders those steps by the high-level ATASM
abstraction. That is, architecture steps are followed by threat-
related tasks. The results of these are applied to an enumeration
of attack surfaces, which, when prioritized, can then be
defended by building a set of risk mitigations, a defense-in-
depth of security controls.
Each of the steps outlined in Figure 5.2 is, of course, what
developers call a “nontrivial” activity.
Figure 5.2 ATASM procedure steps.
5.2 Architecture and Artifacts
Part of understanding a system architecture is to understand the
system’s overall functions and what objectives deploying the
system is hoping to achieve. An assessment should start at the
beginning by determining the system’s intended purpose and
how it fits into the overall goals of the deploying organization

and its users. This information will “ground” the architecture
into the real world and will place the architecture within its
intended context.
5.2.1 Understand the Logical and Component
Architecture of the System
The logical architecture represents each logical function that
will be in the system. These groupings are irrespective of how
many individual units of each function get instantiated and
irrespective of the physical architecture. Generally, that there
are computers (servers?) and operating systems is assumed and
not detailed; the physical network addresses assigned to each
network interface are unimportant in the logical view. Instead,
functions like business logic versus the presentation versus back
office accounting systems versus databases are separated out. It
is assumed that all of these are connected by some sort of
network architecture.
5.2.2 Understand Every Communication Flow
and Any Valuable Data Wherever Stored
Figure 5.4 AppMaker DFD with data types.
Data types have been added to the AppMaker diagram to create
Figure 5.4. There is a co-located repository containing various
types of static content to be served to users (customers).
Moving further back in the architecture, every application
server must contain configuration data and metadata about the
applications that the server is running. Usually, but not always,
there is local disk storage, or readily available storage for this
application server–specific data.

5.3 Threat Enumeration
We need to understand the attackers in order to know which of
them apply to any particular system. And in order to prioritize
attack surfaces and attack targets, we need to be able to
calculate the risk of any particular attack occurring.
These higher-priority areas are characterized by the existence of
threat agents who have the motivation and capabilities to take
advantage of likely methods that will lead them to their
objectives – and will in turn cause unacceptable losses . . .
5.3.1 List All the Possible Threat Agents for This
Type of System
The motives of these undirected attack sweeps are varied; many
of these sweeps are conducted by criminal organizations or
independent attackers. But there are many other reasons for
running constant vulnerability sweeps, as well. Increasing one’s
skill as a security tester is certainly among these reasons. Every
sweep is not conducted by criminals, though, in many
jurisdictions, conducting such a sweep is illegal.
Type of System – Cont.
There is one additional threat agent with which most public
sites and products must contend. Calling security researchers
“threats” is somewhat of a misnomer and might be perceived by
researchers as an insult? No insult is intended. Still, if an
organization is on the receiving end of vulnerability research,
the impact to reputation and brand
may be approximately the same as what can occur following a
successful compromise of systems or data.

Type of System – Cont.
Essentially, researchers need to find vulnerabilities. They need
to find tricky vulnerabilities and then must publish the research.
It doesn’t really matter if the vulnerability can result in
significant loss for the organization owning the problem. The
actuality of an impact does not play a big part of the research
equation. Any organization that has had to deal with a well-
publicized stunt hack against one of the organization’s systems
will know full well that the media attention of the research did
not benefit the public image of the organization, especially if
that organization’s customers expect a certain level of security
from the organization.
5.3.2 List the Typical Attack Methods of the
Threat Agents
Spending months or years creating a new method to execute a
series of randomly placed instructions in a program to create an
attack simply isn’t worth the effort: The research and
development costs are too high. At the time of the writing of
this book, so called “gadget” programs take too much time.
Running gadgets culled by finding bits of
code within widely distributed applications is much more likely
to fall into the category of “stunt hack.” Cyber criminals are
probably not going to waste their time unless there was a
readily available tool (even if on the black market) that would
make this attack trivial.
5.3.3 List the System-Level Objectives of Threat

Agents Using Their Attack Methods
For many exploits there is a system-level objective that must be
attained in order to prosecute the attack to its goal. For security
researchers, the system-level objective— that is, getting a piece
of scripting code (javascript) to execute in the user’s browser,
or
gaining system-level privileges—will be sufficient to prove
vulnerability. No more need be accomplished.
5.3.3 List the System-Level Objectives of Threat
Agents Using Their Attack Methods
The subsequent entries in Table 5.3 are drawn from OWASP.org
Top 10. In order to gain a place in the list, an attack method has
to be one of the most popularly executed as well as used on a
regular and continuing basis. When we analyzed cyber
criminals, we noted their predilection for well-known and
proven attack methods. The OWASP Top 10 list is
representative of the most often used attacks on the Internet.
Since the Web-Sock-A-Rama site is a typical web store, it will
be subjected to attacks drawn from the OWASP Top 10 list, at
the very least. Security researchers will also attempt well-
known attack methods in order to find and report
vulnerabilities.
5.4 Attack Surfaces
In the ATASM process, we try to enumerate all the attack
surfaces before we categorize the importance of each surface.
It’s useful to avoid the prioritization process during
enumeration. Think of it as an attack surface brainstorm: Any
discussion about the legitimacy or fitness of an attack surface
tends to bog down the enumeration into too many details. In this

way, the natural flow resulting from nonjudgmental observation
is broken. It’s easy to miss an attack surface, especially when it
seems inconsequential, or perhaps that function just seems to be
“part of the running program.” For that very reason, getting a
good flow of nonjudgmental inspection can help to uncover all
the attack surfaces. Prioritization can come later, once
everything has been uncovered. In the process being described
in this chapter, we simply enumerate all the attack surfaces and
try to avoid discussion of their importance and exposure until a
later step.
5.4.1 Decompose (factor) the Architecture to a Level
That Exposes Every Possible Attack Surface
An integrated web server collapses the web tier and application
server tier into a two-tiered architecture. Following the security
principles, defense-in-depth and fail securely, the three-tier
architecture is usually considered a more defensible approach.
Web-Sock-A-Rama, as depicted in Figure 5.5, demonstrates the
more standard three-tier web architecture.
Figure 5.5 Web-Sock-A-Rama trust boundaries.
20
That Exposes Every Possible Attack Surface –
Cont.
Figure 5.6 An obvious attack surface.

Figure 5.6 adds an arrow to Figure 5.5 that points at the most
obvious attack surface: the Web server’s Internet facing HTTP
receiver. The Web server is open to all Internet traffic, which
means that any attacker can probe it. The constant “doorknob
rattling” sweeps of the Internet will surely find and investigate
whatever interfaces are open and available to unrestricted
traffic.
Once an interested attacker finds and catalogs the open HTTP
port, then the fun really begins. Like web vulnerability
scanners, the attacker will probe every reachable page with
every attack variation possible.
That Exposes Every Possible Attack Surface –
Cont.
The injections for downstream destinations, such as LDAP and
databases, are aimed at the application server code because
that’s where the capability to pass on these attacks is typically
found. These are then attacks against the application code.
Contrast these injections with a Cross-Site Request Forgery
(CSRF) attack. These attacks can be mitigated at several
different layers, depending upon how session management is
implemented in the website. Although many would consider this
a vulnerability of the custom application code, depending upon
how the infrastructure is set up, it may be that the application
server handles user and transaction states. If so, then a CSRF
vulnerability would lie in front of the application code.
22

5.4.2 Filter Out Threat Agents Who Have No Attack
Surfaces Exposed to Their Typical Methods
Through the process of filling out Table 5.4, we have already
filtered out a series of attacks that do not have an appropriate
attack surface exposed to them. In fact, by attempting to apply
attack methods to attack surfaces, we have even eliminated, or
significantly reduced, a threat agent: security researchers.
Security researchers’ stunt level hacks are unlikely since the
attack surfaces required to execute these attacks are not
exposed.
23
5.4.3 List All Existing Security Controls for Each
Attack Surface
We have made a couple of assumptions for the sake of
understanding the process. Namely, we’ve assumed that Web-
Sock-A-Rama has a mature website management and
administrative function. In previous chapters, we’ve listed what
those functions typically are. This assumption provides the
usual set of controls to the backend of our website.
24
Sufficient Existing Protection
Authentication is an interesting security control because,
although it does reduce exposure to only those who’ve been
authenticated, there are plenty of techniques an attacker can use
to get an account, depending upon the site: steal or crack weak

credentials, or perhaps simply sign up for the free version. In
addition, once a site or system implements authentication, it
now has another system that will need protection!
Authentication systems are often considered critical, thus
requiring tight security control: a high security posture.
Implementing authentication adds significant complexity to the
security requirements of the system.
25
Sufficient Existing Protection – Cont.
26
5.5 Data Sensitivity
Data classification is a key component of risk, both for
assessing impact and for understanding likely targets in a
system. As has been explained earlier, attackers often string
more than one attack method together in order to achieve their
objectives. An attacker might execute an SQL injection against
the payment card database, thereby gaining financial
information, if applications accepting user input were poorly
written such that SQL injection to databases were allowed.
Data sensitivity mustn't become the sole measure of CAV or
impact. Each of these risk terms are multidimensional; terms
shouldn’t be reduced in a simplistic way or assessments will
suffer by possibly excluding other key factors.

27
5.6 A Few Additional Thoughts on Risk
The goal of risk calculation during ATASM is to identify those
CAVs whose lack of mitigation will prevent reaching the
intended security posture. Concomitantly, there is an imperative
to limit the number of risk treatments to that which is
affordable, that which is doable. Few organizations can “do it
all.” Hence, there has to be a process to eliminate unlikely
attacks while prioritizing the most dangerous ones for
mitigation.
28
5.7 Possible Controls
Due to the realities of email impersonation and payment card
theft, an authentication based upon these factors isn’t really
worth much, which leaves our Web-Sock-Arama website
without much attack mitigation based upon authentication.
Obviously, the organization’s security team will have their
hands full with fraud attempts, operationally removing
fraudulent and fake accounts as soon as malicious behavior is
observed. Still, at account initialization, there isn’t much that
can be done.
29

5.7.1 Apply New Security Controls to the Set of
Attack Services for Which There Isn’t Sufficient
Mitigation
Table 5.6 adds defenses to each of the attack methods that we
enumerated in previous ATASM steps. These are the five
attacks and their associated attack surfaces (the CAVs) that we
believe are applicable to this system, in this organizational
context. (Continued on following page 167 – Prepare for
Assessment)
30
5.7.2 Build a Defense-in-Depth
Because the system handles sensitive data from users
originating from the untrusted
Internet, the Transport Layer Security (TLS), most often
implemented as HTTPS,
must be used between the user’s browser and the web server, at
least for sensitive data
transmission. Some architectures would also require TLS (or
more properly, communication encryption of some sort)
between the web server and the application server, and perhaps
even between the application server and the database server?
We assumed that the networks in this system are tightly
controlled through a mature administrative practice. Therefore,
the networks can be considered a trusted infrastructure. Since
we’ve separated out three tiers, and there is only a single piece

of trusted networking equipment separating each tier (a new
assumption and requirement), the store doesn’t feel the need to
encrypt the data as it moves between tiers.
32
5.8 Summary
Defenses are applied such that these specifically interrupt each
CAV, as was discussed in the chapter on risk. Then, the entire
set of defenses is considered as a set of overlapping,
interlocking, and supporting defenses to build enough
redundancy to create a defense-in-depth. The security
requirements should be achievable, relevant, and “real world.”
ATASM has been presented as a series of linear steps. However,
in practice, an assessment might proceed to requirements and
uncover a previously unknown part of the system, thus returning
to the architecture stage of the process. Ultimately, the goal of
the ARA and threat model is to achieve a unity between security
posture and intended risk tolerance, to achieve balance between
defenses and resource limitations.
33
Chapter 4: Summary
END
image4.emf
image5.png
image6.emf

image7.emf
image8.png
image9.emf
image10.emf
image11.png
image12.png
image13.png
image14.png
image15.png
image1.emf
image2.emf
University of the Cumberlands
School of Computer & Information Sciences
ISOL-536 - Security Architecture & Design
Chapter 6: eCommerce Website
Chapter 6: eCommerce Website
6.1 Decompose the System
6.1.1 The Right Level of Decomposition
6.2 Finding Attack Surfaces to Build the Threat Model
6.3 Requirements
Chapter 6 - eCommerce Website
6.1 Decompose the System
Ultimately, the point of the architecture factoring exercise isn’t
to document a perfect architecture view, but rather, to find

those points in the system that are susceptible to likely attack.
An appropriate set of defenses can be built from the attack
surfaces.
Security is built at many levels, top-to-bottom, side-to-side, and
front-to-back. Security is the architecture domain that interacts
with every other domain; it is the “matrix” domain and must
permeate a system in order to build a defense-in-depth.
6.1 Decompose the System – Cont.
Looking at Figure 6.1, do you see anything missing? In the
chapter about the ATASM process, there were several views of
Web-Sock-A-Rama, adding data types, trust boundaries, and an
attack surface.
Figure 6.1 AppMaker web architecture.
6.1.1 The Right Level of Decomposition
Figure 6.2 adds these two attack surfaces for a more complete
picture of the message flow from the Internet and on through to
the data tier.
Figure 6.2 Attack surfaces touched by requests from the user’s
browser.
That is, at arrow 2b, the dynamically handled
messages are passed from the web server to the
Java application server. The application server calls

AppMaker,
which in turn passes the message to one of the appropriate
applications that were generated by AppMaker. In order to
find
the appropriate application, AppMaker will have to call the
database server (arrow 4) to query the application metadata:
data about which application handles which type of
message.
Then, while handling the request, “other web app” must also
query various databases, perhaps customer profiles and the
product catalog, in order to build the response for the user.
The
database server must continue to fetch data (“data fetch to
fulfill 4”) as requests come in and responses are built.
These
systems handle multiple requests in parallel.
5
6.2 Finding Attack Surfaces to Build the Threat Model
Since our web store has purchased AppMaker, let’s assume that
wherever the injection lies, it would be AppMaker’s maker (the
vendor) who would be responsible for the fix. So, in light of
this relationship, it probably doesn’t matter whether an XSS lies
within AppMaker itself or in a generated application, as long as
the vendor is responsive to vulnerability reports and practices
rigorous software security.
Traffic from various components is allowed into the subnet to
perform authentications, but traffic from the Internet is not
allowed; the authentication system is “invisible” from the
Internet; it is not reachable by Web-Sock-A-Rama’s customers

directly.
6
6.2 Finding Attack Surfaces to Build the Threat Model – Cont.
Figure 6.3 Data fetch and management interfaces.
The flow in Figure 6.3 is more
coherent with the description given.
AppMaker loads one of the
generated applications, which in turn
must generate a query for various types of data.
In this web store, every data store will be used.
For each dynamically generated HTTP response,
AppMaker must first find (and perhaps in part, build)
the appropriate application through its metadata.
Then, the application must itself consult the web
store and customer data. Hence, the database server
is an intermediary between the various data stores
and applications (AppMaker and the generated web
applications), These flows are shown in Figure 6.3
7
Figure 6.4 Management interface attack surfaces.

Figure 6.4 has already become visually busy enough. Still, in
the real world, every configuration file and any local, running
data set is and must be considered an attack surface. In this
case, we have already stipulated that, through the infrastructure
practices “investigation” (really, an assumption in this fictitious
example system), there are a series of existing controls
protecting the servers and their local hard disks. Thus, we
concentrate on just a portion of the attack surfaces in order to
keep the example focused. In the real world, I would absolutely
find out what management practices and protections are
implemented to defend the configuration files and metadatasets.
8
Figure 6.5 Authentication and identity flows.
A more complete picture of a management sub-network that is
restricted through a jump server is pictured in Figure 6.5. Please
refer to this figure for more clarity about the architecture and
components used to build this type of management interface
protection.)
Web authentication can be handled entirely by the web server.
The HTTP protocol contains primitives for authentication,
which then are implemented in most open source and
commercial web servers.

9
Figure 6.6 Authentication attack surfaces.
Finally, there is an arrow pointing towards Directory, itself, in
Figure 6.6. Gaining the directory gives the attacker all the
credentials, which are tied to all the user IDs. That very thing
happened to a company for which I worked. The attackers
compromised every account’s password. In other words,
attackers had access to every customer account and the services
and equipment for which the highest privileged accounts were
entitled. Ouch!
10
Figure 6.7 Web-Sock-A-Rama payment processing.
For our purposes, everything depicted in Figure 6.7 that lies
below the Internet, except the isolated authentication service,
would be subject to PCI requirements.
Since the authentication service lies within its own restricted
network, from a PCI standpoint the authentication service has
been separated. The authentication service never handles

payment cards and is not involved in financial transactions.
Therefore, it lies outside the PCI boundary. Customer’s user ID
are populated from the customer database. That is a “push”
function; the directory that lies within the authentication service
does not call out to the customer data.
11
6.3 Requirements
Table 6.1 outlines the requirements that we uncovered
throughout this chapter’s analysis.
(Continued on following page 210 - eCommerce
Website)
Most information security professionals are already familiar
with this body of knowledge. For exposed Internet sites,
networking restrictions and boundaries can become critically
important. Though there are other ways to create trust
boundaries, a common way is to use network segments and then
control flows between the segments and between the systems in
the segments. That’s the essential gist of the networking
requirements given in Table 6.1.
12
Chapter 6: Summary
As this is the first analysis in our series of six, I caution the
reader to understand these requirements fairly well. In order not

to be repetitive, the subsequent analyses will refer back to these
wherever they arise. Remember, architectural patterns repeat,
and I’ve attempted to use the same solutions consistently
throughout the examples. This is not to imply that any of these
is the only solution. Hopefully, this is clear. Still, one of the
points of this book is that there are patterns and their solution
sets that repeat. So some of the same solutions are being reused
set rather than introducing new security defense approaches for
the same recurring problem.
Chapter 6: Summary
END
image4.emf
image5.png
image6.emf
image7.emf
image8.emf
image9.png
image10.emf
image11.emf
image12.emf
image13.png
image1.emf
image2.emf

University of the CumberlandsSchool of Computer & Information .docx

Recommended

Recommended

More Related Content

Similar to University of the CumberlandsSchool of Computer & Information .docx

Similar to University of the CumberlandsSchool of Computer & Information .docx (20)

More from jolleybendicty

More from jolleybendicty (20)

Recently uploaded

Recently uploaded (20)

University of the CumberlandsSchool of Computer & Information .docx