I need 2 different Documents as one is for the discussion and the other one is for Assignment and both should be plagiarism free
I have attached the PPT just for reference:
Discussion Topic:
Length: Minimum of 400 words
Total points: 10 points
Due date: Sunday, February 2, 2020
Students will be required to create 1 new thread, and provide substantive comments on at least 3 threads created by other students. Make sure to explain and backup your responses with facts and examples. This assignment should be in APA format and have to include at least two references. Question:Given multivariate, multidimensional events generated by adaptive human agents, perhaps it would not be too far a stretch to claim that no two events are precisely the same. Given the absence of actuarial data, what can a poor security architect do?
ASSIGNMENT TOPIC:
Length: Minimum of 600 words
Total points: 10 pointsDue date: Sunday, February 2, 2020
Submission Title: [yourname]_ISOL536_Spring2020Main_Week4_Assignment.docx
Briefly respond to all the following questions. Make sure to explain and backup your responses with facts and examples. This assignment should be in APA format and have to include at least two references.
Faced with the need to deliver risk ratings for your organization, you will have to substitute the organization’s risk preferences for your own. For, indeed, it is the organization’s risk tolerance that the assessment is trying to achieve, not each assessor’s personal risk preferences.
1. 1. What is the risk posture for each particular system as it contributes to the overall risk posture of the organization?
2. 2. How does each attack surface – its protections if any, in the presence (or absence) of active threat agents and their capabilities, methods, and goals through each situation—add up to a system’s particular risk posture?
3. 3. In addition, how do all the systems’ risks sum up to an organization’s computer security risk posture?
University of the Cumberlands
School of Computer & Information Sciences
ISOL-536 – Security Architecture & Design
Chapter 4 – Information Security Risk
Spring 2020
Dr. Sherri Brinson
Chapter 4 – Information Security Risk
4.1 Rating with Incomplete Information
4.2 Gut Feeling and Mental Arithmetic
4.3 Real-World Calculation
4.4 Personal Security Posture
4.5 Just Because It Might Be Bad, Is It?
4.6 The Components of Risk
4.6.1 Threat
4.6.2 Exposure
4.6.3 Vulnerability
4.6.4 Impact
4.7 Business Impact
4.7.1 Data Sensitivity Scales
4.8 Risk Audiences
4.8.1 The Risk Owner
4.8.2 Desired Security Posture
4.9 Summary
4.1 Rating with Incomplete Information
• It would be extraordinarily helpful if the standard insurance risk equation could be calculated for
information security risks.
Probability * Annualized Loss = Risk
• However, this equation requires data that simply are not available in sufficient quantities for a statistical
analysis comparable to actuarial data that are used by insurance companies to calculate risk. In order to
calculate probability, one must have enough statistical data on mathematically comparable events.
Unfortunately, generally speaking, few security incidents in the computer realm are particularly
mathematically similar. Given multivariate, multidimensional events generated by adaptive human agents,
perhaps it wouldn’t be too far a stretch to claim that no two events are precisely the same?
• Given the absence of actuarial data, what can a poor security architect do?
4.2 Gut Feeling and Mental Arithmetic
• Experienced security architects do these “back of the napkin” calculations fairly
rapidly. They’ve seen dozens, perhaps hundreds, of systems. Having rated risk for
hundreds or perhaps many more attack vectors, they get very comfortable
delivering risk pronouncements consistently. With experience
comes a gut feeling, perhaps an intuitive grasp, of the organization’s risk posture.
Intimacy with the infrastructure and security capabilities allows the assessor to
understand the relative risk of any particular vulnerability or attack vector. This is
especially true if the vulnerability and attack vector are well understood by the
assessor. But what if one hasn’t seen hundreds of systems? What does one do
when just starting out?
4.3 Real-World Calculation
• For the purposes of architecture assessment for security, risk may be
thought of as:
Credible Attack Vector * Impact = Risk Rating
Where:
Credible Attack Vector (CAV) = 0 < CAV > 1
Impact = An ordinal that lies within a predetermined range such
that 0 < Impact >
Predetermined limit (Example: 0 < Impact > 500)
4.4 Personal Security Posture
• Personal risk predilection will have to be factored out of any risk
calculations performed for an organization’s systems. The analyst is
not trying to make the system under analysis safe enough for him or
herself. She is trying to provide sufficient security to enable the
mission of the organization. “Know thyself” is an important maxim
with which to begin.
4.5 Just Because It Might Be Bad, Is It?
• Given certain types of attacks, there is absolute certainty in the world
of computer security: Unprotected Internet addressable systems will
be attacked. The uncertainty lies in the frequency of successful
attacks versus “noise,” uncertainty in whether the attacks will be
sophisticated or not, how sophisticated, and which threat agents may
get to the unprotected system first. Further, defenders won’t
necessarily know the objectives of the attackers. Uncertainty lies not
within a probability of the event, but rather in the details of the
event, the specificity of the event.
4.5 Just Because It Might Be Bad, Is It? – Cont.
• We are interested in preventing “credible attack vectors” from
success, whatever the goals of the attackers may be. We are
constraining our definition of risk to:
• Human threat agents
• Attacks aimed at computer systems
• Attack methods meant to abuse or misuse a system
4.6 The Components of Risk
• There is a collection of conditions that each must be true in order for
there to be any significant computer security risk. If any one of the
conditions is not true, that is, the condition doesn’t exist or has been
interrupted, then that single missing condition can negate the ability
of an attack to succeed.
To illustrate how network defenders can act on their knowledge of their adversaries’
tactics, the paper lays out the multiple steps an attacker must proceed through to plan
and execute an attack. These steps are the “kill chain.” While the attacker must complete
all of these steps to execute a successful attack, the defender only has to stop the attacker
from completing any one of these steps to thwart the attack.
4.6.1 Threat
• The term “threat” is scattered about in the literature and in parlance
among practitioners. In some methodologies, threat is used to mean
some type of attack methodology, such as spoofing or brute force
password cracking. Under certain circumstances, it may make sense to
conflate all of the components of threat into an attack methodology.
This approach presumes two things:
• All attack methodologies can be considered equal.
• There are sufficient resources to guard against every attack methodology.
4.6.1 Threat – Cont.
• In order to understand how relevant any particular threat agent is to a
particular attack surface, impact or loss to the organization, and the
level of protection required to dissuade that particular type of attacker.
•
•
•
•
•
Threat agent
Threat goals
Threat capabilities
Threat work factor
Threat risk tolerance
Table 4.1 summarizes the attributes that can be associated
with cyber criminals.
4.6.2 Exposure
• In organizations that don’t employ any separation of duties between roles,
administrative staff may have the run of backend servers, databases, and even
applications. In situations like this, the system administrators can cause
catastrophic damage.
• Even in mature and well-run shops, administrative staff will have significant power
to do damage. The excepted protections against misuse of this power are:
• Strict separation of duties
• Independent monitoring of the administrative activities to identify abuse of administrative access
• Restriction of outbound capabilities at the time when and on the network where administrative
duties are being carried out
• Restriction of inbound vectors of attack to administrative staff when they are carrying out
their duties
4.6.2 Exposure – Cont.
• In the world of highly targeted phishing attacks, where a person’s social
relations, their interests, even their patterns of usage, can be studied in
detail, a highly targeted “spear-phishing” attack can be delivered that is
very difficult to recognize. Consequently, these highly targeted spearphishing techniques are much more difficult to resist. The highly
targeted attacks are still relatively rare compared to a “shotgun”
approach. If you, the reader, maintain a more or less public Web
persona with an email address attached to that persona, you will no
doubt see your share of untargeted attacks every day – that is, email
spam or phishing attacks.
4.6.2 Exposure – Cont.
• “Exposure” is the ability of an attacker to make contact with the vulnerability. It is
the availability of vulnerabilities for exploitation. The attacker must be able to make
use of whatever media the vulnerability expresses itself through. As a general rule,
vulnerabilities have a presentation. The system presents the vulnerability through
an input to the system, some avenue through which the system takes in data.
Classic inputs are:
•
•
•
•
•
•
The user interface
A command-line interface (CLI)
Any network protocol
A file read (including configuration files)
Inter-process communication
A system driver
4.6.3 Vulnerability
• Treatments to protect against the vulnerability tend to apply to many
variations of that vulnerability. Hence, the security architect performing
assessments must know the classes of vulnerability that can occur for
that kind of system. Understanding each variation of that class of
vulnerability isn’t necessary. Instead, what is required is the
understanding of how those vulnerabilities occur and how they may be
protected.
4.6.3 Vulnerability – Cont.
• Similarly, exploitation of any heap overflow will be unique to the organization of
memory in an executable, on a particular operating system. The techniques can be
generalized; the exploitation is always particular to a particular vulnerability. There
are literally thousands of exploits. Anley et al. (2007) include three examples of
heap overflows in their introductory chapter and several chapters of samples under
major operating systems, such as Windows, Linux, and Mac OS X. Again, a security
architect assessing a system that is written in a language that must handle memory
must understand the nature and attackability of heap overflows and should
understand the generalized value gained by the attacker through exploitation. But
an encyclopedic understanding of every possible heap overflow isn’t necessary in
order to proceed with a system analysis.
4.6.4 Impact
• Given the importance of customers trusting an organization, should
the compromised server get used to attack customers, or to display
inappropriate messages, such a situation might result in a more
significant loss. What if that server has become a base of operations
for attackers to get at more sensitive systems? In any of the foregoing
scenarios, a single compromised server among thousands that are
untouched may be seen as a much greater loss.
4.7 Business Impact
• The technical impact from a heap overflow might be the execution of
code of the attacker’s choosing in the context of an application at
whatever operating system privileges that application is running. These
technical details are certainly important when building defenses against
these attacks. Further, the technical impact helps coders understand
where the bug is in the code, and technical details help to understand
how to fix the issue. But the technical impact isn’t typically important
to organizational risk decision makers. For them, the impact must be
spelled out in terms of the organization’s objectives. We might term
this “business impact,” as opposed to “technical impact.”
4.7.1 Data Sensitivity Scales
• A mature security architecture practice will understand the data
sensitivity rating scale of the organization and how to apply it to
different data types. By classifying the sensitivity of data, the assessor
has information about the required security posture needed to protect
the data to the level that is required. Further to the point of this
section, loss or impact can be expressed in business terms by noting
which data are targets and by understanding the potential effects on
the system and the organization when particular data are disclosed or
tampered with. Data sensitivity, then, becomes a shorthand tool for
expressing the business impact of a risk.
4.8 Risk Audiences
• There are different audiences, different stakeholders, who need to
understand risk through unique, individualized perspectives. It’s a
good practice to craft risk messages that can be understood from the
perspectives of each stakeholder group. As has been noted, decision
makers, namely, organization leaders, typically prefer that risk be
stated in business terms, what I’ve termed “business impact.”
Business impact is the effect that the successful exercise of a credible
attack vector will have on the organization’s operations and goals.
4.8.1 The Risk Owner
• Raising risk means bringing the untreated or residual risk to a decision
maker for a risk decision. These decisions typically take one of three
mutually exclusive forms:
1. Assumption of the risk: “proceed without treatment,” that is, the
organization agrees to bear the burden of the consequences, should an
impact occur.
2. Craft an exception to treating the risk immediately, that is, “fix the risk
later, on an agreed-upon schedule.”
3. Treat the risk immediately.
4.8.2 Desired Security Posture
• There is no easy prescription or recipe to determine the desired risk
posture. One can turn to the organization’s security policy and
standards as a starting point. In organizations whose cyber-security
function is relatively mature, there may exist standard that point the
way to the controls that must be implemented.
Chapter 4: Summary
• In this chapter, we have narrowed the scope of the term “risk” to
precisely fit the purpose of security assessment and threat
modeling. We have proposed one methodology as an example of
how risk can be understood and rated fairly easily. Whatever
methodology is used, it will have to be repeatable by the
analysts who’ll provide security assessments, build threat
models, and provide requirements for a system’s security
posture.