To enhance the security of information systems, enterprises are developing and adopting information system management systems. However, if an information management system is exploited, applications and the data they contain will be compromised. Therefore, it is important to perform a comprehensive security analysis throughout the enterprise.

In your own words explain (a) the purpose of an security analysis, and (b) using fig 2.2 (“Knowledge sets that feed a security analysis”) as a guide, in your own words briefly explain what each knowledge domain entails. Please state your answer in a 1-2 page paper in APA format.  Include citations and sources in APA style.

University of the Cumberlands
School of Computer & Information Sciences

ISOL-536 – Security Architecture & Design

Spring 2020

Dr. Errol Waithe

• Chapter 1: Introduction

• 1.1 Breach! Fix It!
• 1.2 Information Security, as Applied to Systems
• 1.3 Applying Security to Any System

Chapter 1: Introduction
• 1.1 Breach! Fix It!

• Advances in information security have been repeatedly driven by spectacular
attacks and by the evolutionary advances of the attackers.

• The password file for millions of customers was stolen through the front end
of a web site pulling in 90% of a multi-billion dollar revenue stream.

• The chance of an attempted attack of one kind or another is certain. The
probability of a web attack is 100%; systems are being attacked and will be
attacked regularly and continually.

• Indeed, system complexity leads to increasing the difficulty of defense and,
inversely, decreasing the difficulty of successful exploitation. The number of
flows between systems can turn into what architects call, “spaghetti,” a
seeming lack of order and regularity in the design.

• If a breach or significant compromise and loss creates an opportunity, then

that opportunity quite often is to build a security architecture practice. A
major part or focus of that maturing security architecture practice will be the
assessment of systems for the purpose of assuring that when deployed, the
assessed systems contain appropriate security qualities and controls.

• Sensitive data will be protected in storage, transmission, and processing.
• Sensitive access will be controlled (need-to-know, authentication, and

authorization).
• Defenses will be appropriately redundant and layered to account for failure.
• There will be no single point of failure in the controls.
• Systems are maintained in such a way that they remain available for use.
• Activity will be monitored for attack patterns and failures.

Chapter 1: Introduction – Cont.
• 1.2 Information Security, as Applied to Systems

• Security architecture applies the principles of security to system
architectures.

• Without security architecture, the intrusion system (IDS) might be distinct and
independent from the firewalls (perimeter). Firewalls and IDS would then be
unconnected and independent from anti-virus and anti-malware on the
endpoint systems and entirely independent of server protections.

• The security architect first uncovers the intentions and security needs of the
organization: open and trusting or tightly controlled, the data sensitivities,
and so forth.

Chapter 1: Introduction – Cont.
• When standards do not match what can actually be achieved, the standards

become empty ideals. In such a case, engineers’ confidence will be shaken;
system project teams are quite likely to ignore standards, or make up their
own. Security personnel will lose considerable influence. Therefore, as we
shall see, it’s important that standards match capabilities closely, even when
the capabilities are limited. In this way, all participants in the system security
process will have more confidence in analysis and requirements.

Chapter 1: Introduction – Cont.
• Decision makers need to understand precisely what protections can be put

into place and have a good understanding of any residual, unprotected risks
that remain.

• A suite of controls implemented for a system becomes that system’s defense.
If well designed, these become a “defense-in-depth,” a set of overlapping and
somewhat redundant controls. Because, of course, things fail. One security
“principle” is that no single control can be counted upon to be inviolable.
Everything may fail. Single points of failure are potentially vulnerable.

Chapter 1: Introduction – Cont.
• The Open Web Application Security Project (OWASP) provides a distillation of

several of the most well known sets of computer security principles:
• Apply defense-in-depth (complete mediation).
• Use a positive security model (fail-safe defaults, minimize attack surface).
• Fail securely.
• Run with least privilege.
• Avoid security by obscurity (open design).
• Keep security simple (verifiable, economy of mechanism).
• Detect intrusions (compromise recording).
• Don’t trust infrastructure.
• Establish secure defaults.

Chapter 1: Introduction – Cont.
• 1.3 Applying Security to Any System

• A typical progression of security maturity is to start by building one-off security
features into systems during system implementation. During the early periods, there
may be only one critical system that has any security requirements! It will be easier
and cheaper to simply build the required security services as a part of the system as
it’s being implemented. As time goes on, perhaps as business expands into new
territories or different products, there will be a need for common architectures, if for
no other reason than maintainability and shared cost. It is typically at this point that a
security infrastructure comes into being that supports at least some of the common
security needs for many systems to consume. It is characteristically a virtue to keep
complexity to a minimum and to reap scales of economy.

Chapter 1: Introduction – Cont.
• Almost every type and size of a system will have some security needs. Although it

may be argued that a throw-away utility, written to solve a singular problem, might
not have any security needs, if that utility finds a useful place beyond its original
problem scope, the utility is likely to develop security needs at some point.

• Complex business systems typically have security requirements up front. In addition,
either the implementing organization or the users of the system or both will have
security expectations of the system. But complexity is not the determiner of security.

• Thus, the answer as to whether a system requires an ARA and threat model is tied
to the answers to a number of key questions:

• What is the expected deployment model?
• What will be the distribution?
• What language and execution environment will run the

Chapter 1: Introduction – Cont.
• Size, business criticality, expenses, and complexity, among others, are dimensions

that may have a bearing, but are not solely deterministic. I have seen many
Enterprise IT efforts fail, simply because there was an attempt to reduce this early
decision to a two-dimensional space, yes/no questions. These simplifications
invariably attempted to achieve efficiencies at scale. Unfortunately, in practice today,
the decision to analyze the architecture of a system for security is a complex,
multivariate problem.

• The answer to “Systems? Which systems?” cannot be overly simplified. Depending
upon use cases and intentions, analyzing almost any system may produce significant
security return on time invested. And, concomitantly, in a world of limited resources,
some systems and, certainly, certain types of system changes may be passed without
review. The organization may be willing to accept a certain amount of unknown risk
asa result of not conducting a review.

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.

• University of the Cumberlands�School of Computer & Information Sciences��

Welcome
Chapter 1: Introduction
Chapter 1: Introduction – Cont.
Chapter 1: Introduction – Cont.
Chapter 1: Introduction – Cont.
Chapter 1: Introduction – Cont.
Chapter 1: Introduction – Cont.
Chapter 1: Introduction – Cont.
Chapter 1: Introduction – Cont.
Chapter 1: Introduction – Cont.
Chapter 1: Summary

University of the Cumberlands
School of Computer & Information Sciences

ISOL-536 – Security Architecture & Design

Chapter 2: The Art of Security Assessment
Spring 2020

Dr. Errol Waithe

•

•

•

•

•

• 2.5 How Much Risk to Tolerate?
• 2.6 Getting Started

2.1 Why Art and Not Engineering?

The branch of science and technology concerned with the design, building, and use of
engines, machines, and structures.

Definition of “engineering”:

• In contrast, a security architect must use her or his understanding of the
currently active threat agents in order to apply these appropriately to a
particular system. Whether a particular threat agent will aim at a
particular system is as much a matter of understanding, knowledge, and
experience as it is cold hard fact. Applying threat agents and their
capabilities to any particular system is an essential activity within the art
of threat modeling. Hence, a security assessment of an architecture is
an act of craft.

2.2 Introducing “The Process”

• Because we security architects have methodologies, or I should
say, I have a map in my mind while I assess, I can allow myself to
run down threads into details without losing the whole of both
the architecture and the methodology.

• Practitioners will express these steps in different ways, and there
are certainly many different means to express the process, all of
them valid.

• This series of steps assumes that the analyst has sufficient
understanding of system architecture and security architecture
going into the analysis.

• As you read the following list, please remember that there are
significant prerequisite understandings and knowledge domains that
contribute to a successful ARA.

• Collect the set of credible attack surfaces.
• Enumerate threats for this type of system and its intended deployment

• Consider threats’ usual attack methods.
• Consider threats’ usual goals.

• Risk assess each attack surface. Risk rating will help to prioritize attack.
surfaces and remediation.

• Factor in each existing security control (mitigations).
• Intersect threat’s attack methods against the inputs and connections.

These are the set of attack surfaces.
• Enumerate inputs and connections

2.2 Introducing “The Process” – Cont.
• An analysis must first uncover all the credible attack vectors of the

system. This simple statement hides significant detail. At this point in
this work, it may be sufficient to outline the following mnemonic,
“ATASM.” Figure 2.1 graphically shows an ATASM flow:

Figure 2.1 Architecture, threats, attack surfaces, and mitigations.

2.2 Introducing “The Process” – Cont.

• These four steps are sketched in the Picture 2.1 – If we break these down
into their constituent parts, we might have a list something like the
following, more detailed list:

• Diagram (and understand) the logical architecture of the system.
• List all the possible threat agents for this type of system.
• List the goals of each of these threat agents.
• List the typical attack methods of the threat agents.
• List the technical objectives of threat agents applying their attack methods.
• Decompose (factor) the architecture to a level that exposes every possible attack

surface.
• Apply attack methods for expected goals to the attack surfaces.

2.3 Necessary Ingredients
• Just as a good cook pulls out all the ingredients from the cupboards and arranges

them for ready access, so the experienced assessor has at her fingertips information
that must feed into the assessment.

Figure 2.2 Knowledge sets that feed a security analysis.

Figure 2.3 Strategy knowledge, structure information, and system specifi cs.

• Figure 2.3 places each contributing knowledge domain within the area for which it is

most useful. If it helps you to remember, these are the “3 S’s.” Strategy, infrastructure
and security structures, and specifications about the system help determine what is
important: “Strategy, Structures, Specification.”

Figure 2.3 Strategy knowledge, structure information, and system specifics.

2.4 The Threat Landscape

• Differing groups target and attack different types of systems in different
ways for different reasons. Each unique type of attacker is called a
“threat agent.” The threat agent is simply an individual, organization, or
group that is capable and motivated to promulgate an attack of one sort
or another.

• Threat agents are not created equal.
• They have different goals.
• They have different methods.
• They have different capabilities and access.
• They have different risk profiles and will go to quite different lengths to be

successful.

• There are three key attributes of human attackers, as follows:
• Intelligence
• Adaptivity
• Creativity

This means that whatever security is put into place can and will be
probed, tested, and reverse engineered.

2.4.1 Who Are These Attackers? Why Do They
Want to Attack My System?
• Cyber crime can be an organized criminal’s “dream come true.” Attacks

can be largely anonymous. Plenty of attack scenarios are invisible to the
target until after success: Bank accounts can be drained in seconds.
There’s typically no need for heavy handed thuggery, no guns, no
physical interaction whatsoever. These activities can be conducted with
far less risk than physical violence. “Clean crime?”

2.4.1 Who Are These Attackers? Why Do They
Want to Attack My System? – Cont.
• There are documented cases of criminals carefully targeting a particular

organization. But even in this case, the attacks have gone after the weak links
of the system, such as poorly constructed user passwords and unpatched
systems with well-known vulnerabilities, rather than highly sophisticated
attack scenarios making use of unknown vulnerabilities.

• Further, there’s little incentive to carefully map out a particular person’s digital
life. That’s too much trouble when there are so many (unfortunately) who
don’t patch their systems and who use the same, easily guessed password for
many systems. It’s a simple matter of time and effort. When not successful,
move on to the next mark.

2.4.1 Who Are These Attackers? Why Do They
Want to Attack My System? – Cont.
• Sometimes a single set of data is targeted, and sometimes the attacks

seem to be after whatever may be available. Multiple diversionary
attacks may be exercised to hide the data theft. Note the level of
sophistication here:

• Carefully planned and coordinated
• Highly secretive
• Combination of techniques (sometimes highly sophisticated)

2.4.1 Who Are These Attackers? Why Do They
Want to Attack My System? – Cont.
• Figure 2.4 attempts to provide a visual mapping of the relationships

between various attributes that we might associate with threat agents.
This figure includes inanimate threats, with which we are not concerned
here. Attributes include capabilities, activity level, risk tolerance,
strength of the motivation, and reward goals.

• Next slide – Figure 2.4 Threat agent attribute relationships.

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.

• University of the Cumberlands�School of Computer & Information Sciences��

Chapter 2: The Art of Security Assessment
2.1 Why Art and Not Engineering?
2.2 Introducing “The Process”
2.2 Introducing “The Process” – Cont.
2.2 Introducing “The Process” – Cont.
2.2 Introducing “The Process” – Cont.
2.3 Necessary Ingredients
2.3 Necessary Ingredients – Cont.
2.4 The Threat Landscape
2.4 The Threat Landscape – Cont.
2.4.1 Who Are These Attackers? Why Do They Want to Attack My System?

• 2.4.1 Who Are These Attackers? Why Do They Want to Attack My System? – Cont.

2.4.1 Who Are These Attackers? Why Do They Want to Attack My System? – Cont.
2.4.1 Who Are These Attackers? Why Do They Want to Attack My System? – Cont.

• Slide Number 16

Chapter 2: Summary