Download - Application Security Cloud
-
8/4/2019 Application Security Cloud
1/31
Cloud Application
SecurityTechnical Review
Cloud computing is the latest bubble which is growing
rapidly with economics, and scalability of applications &
resources as the main factor. This technical review focuses
on some of the general application Security issues and itseffect on Cloud computing paradigm.
Key words : Cloud computing , Application Security , cloud
security
M S Prasad
1/17/2011
-
8/4/2019 Application Security Cloud
2/31
Page 2 of31
INDEX
Cloud Application Security
1.0 Introduction
a. OWASP Threat analysisb. Approaches to Application security
2.0 Threat Modeling
3.0 Threat Modeling Techniques
4.0 Threat Prioritization & MitigationAppx A : Penetration Testing
Appx B ; Ratings of various vulnerabilities
References & Bibliography
-
8/4/2019 Application Security Cloud
3/31
Page 3 of31
Application Security : Cloud
( key words : Cloud security , application security , Penetration testing , Threat
Models, Cloud computing , )
Introduction
Application security in a hosted environment such as Cloud computing has become a serious
concern A security flaw in the application is going to have multiple effect on number of
enterprise using the application on Cloud . It has reached pinnacle of importance due to
compliance and sophisticated methods of hacking.
There are two main reasons by which application security is affected : -
Vulnerability: An instance of an error in the specification, development, or configuration of
software such that its execution can violate the security policy"
Flaw: a flaw defines or implies what should have been done to prevent policy violations; it is a
problem at a higher level of abstraction that may potentially enable several different attacks
and create various vulnerabilities. example flaw: missing input validation
In this tutorial cum review paper , application security ,models and couple of threat
mitigation processes are explained. The aim is to high lite its importance in the cloud
environment.
Application Security
The application security is broadly defined as the protection of software applications against
threats(potentially including those not presently known).Although in general the application
security is a mix of followings :
1. Data security.( Mainly data under transit , under processing or data required for
computation)2. Network Security ( from where the application is being accessed )
3. Software Security
CERT, Cisco, FrSIRT, OVAL, NIST, Microsoft, SANS, and XForce publish near real-time software
vulnerabilities and fixes , which have been made publicly available . The latest data shows that
the NIST National Vulnerability Database (NVD) has been reporting 20 software system
-
8/4/2019 Application Security Cloud
4/31
Page 4 of31
vulnerabilities per day on average, and there are 17731 Vulnerabilities. The common
Weakness Enumeration ( CWE ) Project lists out a large number of vulnerabilities , attack
patterns and other details.
About 75 % of cyber( simple or complex ) attacks are based on exploitation of applications.
Giving most of the time an attacker capabilities to gain privilege access to sensitive information.
(Latest example is Wikileaks ). Generally it has been found out that more stress is given on
making the Operating System secure ,. Network access and application server is secure , where
as security of applications running on the server is taken as granted unless some attack or leak
of information does not occur. e.g. .attackers gain access to privileged accounts and thereby
potentially access thousands of "confidential" personal records.
In a cloud environment application security has an added dimension of Multi tenancy , Virtual
Image of host OS and residual data problems of an application .The importance of Application
security in cloud environment is also due to :-
a. WEB centric Access and applications.b. Session less http usec. Often based on SOA architectured. Untrusted Public Network
Cloud has a higher application security risk due to its open web centric use and also a large
number of users may be using the same application.
Application security can be achieved during development and after wards as well . Secure
application development implies having a security specification along with applicationspecification to be developed. The security specification becomes very important to safe
guard against Logical flaws which can give an attacker an entry to the system or it should
minimize the risk of security attacks. The security specs needs to be verified for its
presence in the code and tested under simulated conditions of attack.
Threats differ from vulnerabilities in that threats are the actors that breach or attempt to
breach security policies and mechanisms. The security gaps that are exploited by threats are
called vulnerabilities. The major attack profiles are :- ( More details listed at http:// www.
cwe.org)
Brute Force Attack
Denial-of-Service
SQL Injection
Cross Site Scripting
-
8/4/2019 Application Security Cloud
5/31
-
8/4/2019 Application Security Cloud
6/31
Page 6 of31
A direct object reference occurs when a developer exposes a reference to an internal
implementation object, such as a file, directory, database record, or key, as a URL or form
parameter. Attackers can manipulate those references to access other objects without
authorization.
A5 - Cross Site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a
vulnerable web application, which then forces the victim's browser to perform a hostile action
to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
A6 - Information Leakage and Improper Error Handling
Applications can unintentionally leak information about their configuration, internal workings,
or violate privacy through a variety of application problems. Attackers use this weakness to
steal sensitive data, or conduct more serious attacks.
A7 - Broken Authentication and Session Management
Account credentials and session tokens are often not properly protected. Attackers
compromise passwords, keys, or authentication tokens to assume other users' identities.
A8 - Insecure Cryptographic Storage
Web applications rarely use cryptographic functions properly to protect data and credentials.
Attackers use weakly protected data to conduct identity theft and other crimes, such as credit
card fraud.
A9 - Insecure Communications
Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive
communications.
A10 - Failure to Restrict URL Access
Frequently, an application only protects sensitive functionality by preventing the display of links
or URLs to unauthorized users. Attackers can use this weakness to access and perform
unauthorized operations by accessing those URLs directly.
( Ref OWASP org web site and documents )
-
8/4/2019 Application Security Cloud
7/31
Page 7 of31
Approaches to Application Security
The organizations resort to many approaches in achieving security in their applications. Most of
the times, the simplest approach is to use some automated Security & Vulnerability scanners
and apply security patches to make their applications secure. In this approach the security is
retrofitted as an external measure .It is one of the basic solution to provide security coverage at
little low cost as quickly as possible. Such quick solution fail to provide the assurance of
application security in its totality..
Penetrate and Patch
Organizations that are introduced to application security through actual production incidents
quickly go on a reaction based plan and remediate their issues by a fastest means by
collaborating with security team internal or external to plug the hole in the production
application.
The approach is something like RETROFITTING THE SECURITY OR FIGHTING THE FIRE .
Instead of having a security in software design and development , which can give repeatable
performance , this approach only gives a temporary solution which can reappear after
sometime in different forms..
The standard Penetrate and apply Patch never plugs in security concerns or indicate root
cause of the vulnerabilities. The best practice is to integrate security in application design in
the early stages of Software Development Life Cycle ( SDLC).
Application Security Plan
The approaches outlined above are capable of providing application security , but to improve
it further , all organizations are required to invest time , make a plan , have people, process &
technology There is requirement to establish a dedicated application security team to make a
plan , which is visible , have a concrete path and execute it. The plan should be based on
definable quality metrics of improvement.
The security needs to be treated as a Risk Management plan with respect to business cost
vs benefit analyses. ISO 15408 which outlines the relation between various processes
involved in Security management is a starting guideline and should be adhered to. Here the
security is taken as Risk Management in a sense if 100 % secure application can not be made
at least we have a risk plan which is 1oo % sure .
-
8/4/2019 Application Security Cloud
8/31
Page 8 of31
A Secure application should exhibit following properties :-
Dependability: Implies Application functions in a known & predicted manner in case of an
attack.
Trustworthiness: Trustworthy software implies , a verifiable and documented proof that the
present application do es not contain any known vulnerabilities / weakness which can be
exploited easily. There is no malicious logic that can cause it to produce malicious results .
Survivability or Resilience: Survivableor resilientsoftware is software that is capable
enough to (a) either resist or tolerate (i.e., continue operating dependably in spite of) most
known attacks plus other new attacks as possible, and (2) recover as quickly as possible, and
with as little damage as possible.
It has been noticed that an enterprise , having a Security focused SDLC , the developers find
themselves a number of vulnerabilities which needs mitigation at development level . Such
process generate a secure and assured Product at a considerable low cost that Ad HOC or
other methods.
Identifying the actual threat is essential for Security Engineering ( A process similar toSoftware engineering , to mitigate vulnerabilities or apply security to an application ) . Security
engineering is an approach as software engineering where we have a water fall model as
shown in Fig below
-
8/4/2019 Application Security Cloud
9/31
Page 9 of31
Automatic tools Code review Threat Model
Security testing
SW Architecture Review
The major aspect in secure software /application development is to have a sound Threat model
so that security requirements could be defined properly . To define a threat model , collection
of security breach data ( its situation in form of incidence report ) is essential. It is better to
consult and have some other enterprise experience also taken into consideration .
The most important consideration of a threat analysis is the Risk associated with each threat.
A proper risk analysis , justifies the development or mitigation effort of a threat . not all
threats leads to same severity of Risk.
------------------------
Collect DataVulnerability
analysisRisk analysis
Threat Modeling
Security Requirements
definition
Development of security
Mechanism
-
8/4/2019 Application Security Cloud
10/31
Page 10 of31
Section II
Threat Modeling
It appears to be simple to adopt industry standard security guidelines such as Common
criteria and accept an application as secure But the se being a general do not refer to all
types of vulnerabilities , at the same time compliance of these do make an application secure
to certain extent. Such details can be found only by Threat modeling process .
The threat modeling process is to be carried out during application design based on study and
possibilities which an attacker will use to gain access or exploit the application. This in turn
gives a detail idea of vulnerabilities and flaws which can be present in the system. Threat
modeling gives an overview and clarity of followings : -
Defines the security parameters in terms of identification of threats of an application
Level and repercussions of identified threats
Defines a logical process of system security design
Software architecture bugs discovery
The threat modeling provides documents like security specifications and how to do security
testing .By using threat modeling to identify threats, vulnerabilities and mitigations at design
time, the system development team will be able to implement application security as part of
the design process. The common approach to Threat modeling could be to decompose the
problems as under : -
a. Identifying the System and its dependent components
b. Access points and assets which can be accessed
c. Identification of threats.
OR
A Treat the system as adversary
B Identify Entry & Exit Points
C List out Assets & resources
D Define System Characteristics
Use case and scenarios
External Dependencies and its security Policies .
-
8/4/2019 Application Security Cloud
11/31
Page 11 of31
External system consistency and impact on application or system.
Internal Security instructions e.g. Working environment and type of data
being handled and any concessions made during development & assumption
made
Basic Threat Models ( Based on Classes of Attacks)
a) Network Threat Model.
A large number of application are WEB based making them vulnerable to external attacks
which can be done remotely and ubiquitously. Attacker goals typically include gaining
privileged access to the machine to carry out attacks for information retrieval etc.
b) Insider Threat Model.
It is presumed that attacker is an insider , that is he has some privilege to work on the LAN or
other systems of the enterprise. The attacker in such cases tries to gain more privileges, thanauthorized to steal the data or some sensitive information.
c) Un trusted Host Threat Model.( White Box Attack model)
when the application is running on untrusted Operating System , the application can be
subjected to attack from Kernel , device driver etc.( by having a malicious code e.g. Honey pots
or botnet) The white Box attacks such as Bot nets require special protection mechanism. This
could be more predominant in Cloud environment since Virtual Machines are multi tenant .
d) Advance Persistent Threat Model
-
8/4/2019 Application Security Cloud
12/31
Page 12 of31
Threat Modeling Techniques
STRIDE Model
STRIDE model developed by Microsoft is an excellent model for threat description and
elaboration . The Stride is an acronym for : Spoofing, Tampering, Repudiation, Informationdisclosure, Denial of service, and Elevation of privilege Prioritization
Spoofing Spoofing means posing to the system or application as an authorized user with
correct credentials. In case of spoofing of a server the authorized user is made to believe
that he is interacting with the correct server . A strong authentication process can mitigate
this threat.
However it is suggested to have TWO WAY authentication process i.e. server to user and user
to server as well. Or in case of secure Tunnel both end points should be authenticated i.e. Client
as well a server.
Tampering The modification of data within the system, including LOGS & audit reports
modification to hide the track. Mitigation could be to get hash codes of data , for checking
its correctness or encryption of the same.
In cloud environment it is suggested to have a chained HASH system for LOG management so
that it is Immutable.
Repudiation - The ability of an adversary to deny performing some malicious activity because
the system does not have sufficient proof otherwise.
Information Disclosure - The exposure of protected data to a user that is not otherwise suppose
to know this information or data .
Denial of Service - Occurs when an adversary makes the system un usable by the authorized
users . E.g. Sync flood attack , Distributed DOS, race condition resulting in eating a large
memory or bandwidth.
Elevation of Privilege : the aim is to gain Administrator privileges , possible due thru Buffer
Overflows , directory Traversal.
Mitigation Approach : Least Privilege Model , Input Validation.
This is the most commonly used Threat modeling process.
-
8/4/2019 Application Security Cloud
13/31
Page 13 of31
Attack Path Threat Modeling Process ( T MAP)
( Ref ; Value Driven security Threat Modeling based on Attack Path analysis :Yue Chen,
Barry Boehm Center for Software Engineering Luke Sheppard Information Technology Services,University of Southern California )
An Attack Path threat model tries to define the path which an attacker can take to access the
enterprise resources. :
How the attacker can gain access to the victim computer; Which vulnerability on which
software on which computer can be taken advantage by attackers; How technical damages
(i.e. confidentiality, availability, and integrity) can impact organization values (i.e. reputation,
productivity, privacy).
T-MAP Framework
In an organization there could be multiple systems running having different importance level
in terms of its effect in business core values . All these system / application would be having
different types of vulnerabilities and security holes. The T-MAP framework is based upon the
observation that the more security holes left open for an IT system, the less secure it is.
-
8/4/2019 Application Security Cloud
14/31
Page 14 of31
T-MAP working frame is a value driven , in which possible attack Paths are defined through
which an attacker can possibly be intrude into enterprise network and harm the organization
business values . T-MAP calculates the severity weight of each Attack Path (attacking scenario)
based on not only the technical severity of the relevant system vulnerability, but also its value
impacts. T-MAP then quantifies the IT system threat based on the total weight of all possibleAttack Paths.
In the figure above the inner most or core depicts the Organization values , ( Those which can
be jeopardized by attacks e.g. productivity or brand/ IPR of a company). On top is the IT infra
structure ( Hardware , network etc ) to support the organization values or core business .
The other layer is the COTS Software and application which is in use by organization. The
possible vulnerabilities and attacking paths are shown in Red.
The attack paths are described as an UML objects in four Classes :
A Access, Specifying how the attacker gains access to system e.g. port scanning , packet
sniffers etc
B. Vulnerability, Implies which open vulnerabilities are used by attacker and its effect on
information confidentiality and privacy.
C. Target Asset, The system on which the vulnerability caused this.
D Affected Value, specifying which organization value is impacted (i.e. loss ,reputation,
productivity,
privacy).
The class attributes are selected based on Common Vulnerability Scoring System (CVSS), a joint
effort
across CERT/CC, Cisco, DHS/MITRE, eBay, Internet Security Systems, Microsoft, Qualys, and
Symantec.
As for example :
Related Exploit Range (Access Vector),
Level of Authentication Needed(Authentication)
Attack Complexity (Access Complexity),
Port Number,
Protocol,
Vulnerability ID,
Based on this the weights are computed for each attack path . The threat model is based on
these weights and risk associated with each. T-MAP differentiates Attack Paths by calculating
-
8/4/2019 Application Security Cloud
15/31
Page 15 of31
their severity weights from Attack Path attribute ratings. The weight calculation is inspired by
the classic risk calculation formula:
Risk = Probability * Size of Loss.
The attack Path model needs through examination of possibilities of various paths ( loop holeswhich can be exploited by the hackers.
Fuzzy Threat Model
The fuzzy threat model can be used for a case where threats are not properly defined or
degree of its cannot be defined properly. This model is primarily based on STRIDE , but gives
the quantative analysis capability taking into account some intangibles as Fuzzy variables. It
uses the fuzzy logic and statistic to evaluate the threat.
Fuzzification:
Fuzzification is a process of generating membership values for a fuzzy variable using
membership functions. The first step is to take the real inputs from STRIDE and determine the
degree to which these inputs belong to each appropriate fuzzy set. This crisp input is always a
numeric value limited to the universe of discourse. Once the crisp inputs are obtained, they are
fuzzified against the appropriate linguistic fuzzy sets. Membership function is designed for each
S
T
R
I
D
E
Rule
Aggregation De fuzzifier
-
8/4/2019 Application Security Cloud
16/31
Page 16 of31
potential threat which is a curve that defines how each point in the input space is mapped to a
membership value (or degree of membership) between [0, 1]. Linguistic values are assigned for
each threat as Low, Moderate, and High while for threat level as Very low, Low, Rather low,
Medium Rather high, High, and Very high. For each input their values ranges from 0 to 10 while
for output, ranges from 0 to 100
The following tables contain the sample linguistic variables and their ranges
1. Linguistic variable: Spoofing, S
Linguistic value Numerical range
Low [0, 0, 3, 6]
Moderate [4, 6, 8]
High [6, 8, 10, 10]
2. Linguistic variable: Tampering, T
Linguistic value Numerical range
Low [0, 0, 2.5, 5]
Moderate [4, 6, 8]
High [7, 8.5, 10, 10]
The detail values are given in Paper under reference
Rule Evaluation: This is the second step where the fuzzified inputs are applied to the
antecedents of the fuzzy rules. Since the fuzzy rule has multiple antecedents, fuzzy operator
(AND or OR) is used to obtain a single number that represents the result of the antecedent
evaluation. We apply the AND fuzzy operation (intersection) to evaluate the conjunction of the
rule antecedents.Rules added to this system are about 139 which were derived by mapping the six inputs to one
output by using conjunction (AND).
Aggregation of the rule outputs: This is the process of unification of the outputs of all rules.
In other words, we take the membership functions of all the rules consequents previously
scaled and combine them into single fuzzy sets (output). Thus, input of the aggregation process
is the list of scaled consequent membership functions, and the output is one fuzzy set for each
output variable.
De fuzzification: This is the last step in the fuzzy inference process, which is the process oftransforming a fuzzy output of a fuzzy inference system into a crisp output. Fuzziness helps to
evaluate the rules, but the final output this system has to be a crisp number. The input for the
defuzzification process is the aggregate output fuzzy set and the out put is a number. This step
was done using Centroid technique because it is most commonly used method of de
fuzzification.
The Authors have used matlab to show a practical result .
-
8/4/2019 Application Security Cloud
17/31
Page 17 of31
Attack Tr
Attack trees provide a formal,
varying attacks. Basically, atatc
node is the root node and w
analyzing the system also dyn
application security process get
Attack trees allow threats aga
format. The effectiveness of i
installation and personnel securi
An attack tree is a tree in whic
global goal of an attacker. Child
represent attacks that can no lo
or disjunctive (choice).The arc connecting these two
which means that all sub-goals
are disjunctive, expressing that s
The top node is also known as
connected to Sub Goals by inter
known as Leaf. It is arranged li
nodes we can reach up to root
Sub Goal 1(OR)
attackergoal 1
e Model ( the term given by Bruce Schneier )
ethodical way of describing the security of sy
s are defined as node and leaf of a tree stru
ays to achieve this as leaf nodes. Attack tre
amically the ways to achieve can be accom
more & more mature
inst system security to be modeled concisel
ternet security, network security, banking
ty may all be modeled using attack trees.
the nodes represent attacks. The root node
ren of a node are refinements of this goal, an
nger be refined. A refinement can be conjuncti
components expresses that this is a conjunc
ave to be fulfilled. Refinements without such
atisfying one sub-goal success.
root node is attackers Goal & objective. T
ediate Nodes through edges. The unconnec
e tree so that traversal from Leaf node thro
ode.
Root node GOAL(OR)
attackergoal 2
subA
goal3 goal 4
stems, based on
cture. The GOAL
s thus help in
odated as the
in a graphical
system security,
f the tree is the
leafs therefore
ve (aggregation)
tive refinement,
a connecting arc
he root node is
ed child node is
gh intermediate
goal 2(ND)
-
8/4/2019 Application Security Cloud
18/31
-
8/4/2019 Application Security Cloud
19/31
Page 19 of31
surface measurement process was as an indicator of the systems security was first introduced
by Howard , Pincus & Wing They measured the attack surface of number of Windows OS
versions and another researcher measured of Linux
A systems attack surface is the set of ways in which an adversary can attack the system and
potentially cause damage. The surface definition takes into consideration of all resourceswhich are required for attacking. For example we know that buffer flow attacks requires
connectivity to the system through network resources i.e sockets, pipes etc .and connect
through system APIs or application APIs. to send data and receive data after buffer overflow.
(e.g., input strings, URLs, and files) into the system or receive data items from the system.
Hence , all these resources are a channel or we can say a surface penetration of which is
possible through any weak point.
we define a systems attack surface in terms of the systems methods, channels, and data items
(henceforth collectively referred to as the systems resources). Not all resources, contribute
equally to the attack surface; a resources contribution depends on the its being used in
attacks. The attack surface is measured as a total contribution of resources in three dimension
:
Methods
Channels
Data
The attack surface ,hence may be thought as the union of code, interfaces, services,
protocols, available to a user or attacker alike. In security design, therefore, the attempt is
always to analyze the attack surface and reduce it.
Note : Attack surface measurement does not define code quality;but a concept of surface
taking all collaborating actions in one space to define the system exposure to vulnerability.
The bigger the attack surface , more the vulnerable the system. In terms of effort required by
an attacker .
The attack surface model is more suitable to Cloud computing due to its channel being varied
and applications running being varied .
For any application that is Cloud-ready, security must be inbuilt within the application. The
design of the application also must be such that the attack surface for this application should be
as minimum as possible. In computers, only that part of the program will be a target of attack
that is accessible to a hacker. A piece of code or part of a program is exposed to the public as an
API (application programming interface) that can be the target of attack.
For a conventional enterprise set up , most of the a perimeter defence reduces the attack
surface of any application , due to its system architecture being static , fixed and enterprise
policy centric.
However, for cloud-attack surface reduction should be functional requirement .
-
8/4/2019 Application Security Cloud
20/31
Page 20 of31
Many authors have defined a set of questions to make the attack surface less or design a
system for that. However the crux is based on : -
a. Evaluation of APIs and its necessity for majority of users & others.
b. Privileges to be granted and associated with location i.e. in house or remote access
c. Inter connections with other subsystem or features of the application. If it is tightly
coupled then crash of one may cause others also to follow the line.
Attack surface analysis helps understand the areas that can be target of attack; and, through
threat modeling analyze possible threats. Combining these two will guide the action plan to
build a secured Cloud-ready application.
The threat analysis could be then carried out using Threat tree or DREAD model .
Threat analysis
One method that works well for the investigation process is to build a threat tree. Threat trees
can be expressed graphically or as text in a threat modeling document. A threat tree consists of
a root node or threat and child node(s).Each child node represents conditions needed for the
adversary to find and identify the threat. Threat trees are used to determine the vulnerabilities
associated with a threat. total by five to get an overall risk rating for each threat. The result can
further be divided into three To identify a threats vulnerabilities, begin at a node without any
children and traverse it up to the root threat.
Another step in analyzing the threats is to determine the risk of the threat and the threats
conditions or child nodes by using the DREAD model. Use a scale of 1-10 to rate each category,
where 1 is the least probability of occurrence and the least damage potential. Add the rating of
each category and divide the sections to generate a High, Medium or Low risk rating
DREAD Model ( an Evaluation Model )
Dread is a threat evaluation model which helps in quantification of a threat.
Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability though
retains full rights.
Damage potential Defines the extent of damage that will occur , once the vulnerability is
exploited.
Reproducibility It shows the reproducibility of vulnerability ,thats how often vulnerability
really works.
Exploitability Quantification of effort required to exploit the vulnerability. It also takes into
consideration , any precondition to exploit the vulnerability.
-
8/4/2019 Application Security Cloud
21/31
Page 21 of31
Affected users How many of installed bases of the e system , would get affected .
Discoverability Measures of the likelihood, a vulnerability can be detected by security
researchers, and the like.
Practical Threat Modeling & Analysis (http://www.ptatechnologies.com/PTA4.htm)
In the above figure a threat using two vulnerabilities are affecting two assets.
However , threat may not be mitigated by one countermeasure but multiple of them.
Threats exploit Vulnerabilities and damage Assets.
Countermeasures mitigate Vulnerabilities and therefore might mitigate Threats.
THREAT
ASSET B
ASSET A
Countermeasure 3
Countermeasure 2
Countermeasure 1VULNERABILITY 1
VULNERABILITY 2
-
8/4/2019 Application Security Cloud
22/31
Page 22 of31
Section III
Threat Prioritization & Evaluation
Risk Management
Despite the best efforts of security researchers, it is impossible to guarantee 100% security.However, we can work toward 100% risk acceptance. A good security system strikes a balance
between what is possible and what is acceptable via the risk management process. Risk
management consists of risk assessment, risk reduction, and risk acceptance. To assess the risk
of identified threats, the threats must be prioritized. The simplest way to prioritize threats is by
using two factors: damage and likelihood. First, calculate the overall risk factor for each threat,
and then sort the threat list by decreasing order of risk. Threats can be addressed starting at
the top of the list. There are four possible ways to manage the risk
Accept the risk - The risk is so low and so costly to mitigate that it is worth accepting.
Transfer the risk - Transfer the risk to somebody else via insurance, warnings etc.
Remove the risk - Remove the system component or feature associated with the risk if the
feature is not worth the risk.
Mitigate the risk - Reduce the risk with countermeasures. The threats selected for mitigation
must be addressed by some countermeasure. Designers should ensure that security does not
become more expensive than it is worth. Security measures should be employed only up to the
point where the cost to implement them does not exceed the expected risk. Failure to make
this judgment correctly can easily lead to a situation where no risk is judged acceptable, and
thus no acceptable system can bedesigned.
-
8/4/2019 Application Security Cloud
23/31
Page 23 of31
Security Architecture Process
A Security Architecture is a cohesive security design, which addresses the requirements (e.g.
authentication, authorisation, etc.) and in particular the risks of a particular
environment/scenario, and specifies what security controls are to be applied where. The design
process should be reproducible.
Risk management process drives the security architecture and implementation of the overall
enterprise security blueprint. The security architecture process is an iterative process that
unifies the evolving business, technical, and security domains. The four main phases in the
process are: Architecture Risk Assessment, Security Architecture & Design, Implementation,
and Operation & Monitoring.
Application Architecture Catalyst
Integrating application security with your application architecture functions provides reuse and
a cost effective approach to securing applications. The application security function shouldwork closely with the application architecture team to improve application security. Compare
this with a reactive approach that deals with application security late in the lifecycle. This
penetrate-and-patch approach is significantly more expensive and will never address the root
causes that lead to applications security problems. Instead of treating the symptoms, work
with application architecture to eliminate application security issues before they are a problem.
Vulnerability
Assessment
Business Cost/BenefitControlRisk
Determinatio
Threat
Assessment
-
8/4/2019 Application Security Cloud
24/31
Page 24 of31
Application architecture can be a catalyst to securing your portfolio of applications, providing
many of the fundamental people, process and technology capabilities required in improving
your applications security posture.
Security Architecture Life Cycle ( Ref : Arectec Group report Security Architecture Bluprint by
Gunnar Peterson)
----------------------------------------------------------------------------------------------------------------------
-
8/4/2019 Application Security Cloud
25/31
Page 25 of31
Appendices A
Penetration testing
Penetration testing can be overt or covert. These two types of penetration testing are
commonly referred to as Blue Teaming and Red Teaming. Blue Teaming involves performing a
penetration test with the knowledge and consent of the organization's IT staff. Red Teaming
involves performing a penetration test withoutthe knowledge of the organization's IT staff but
with full knowledge and permission of the upper management. Some organizations designate a
trusted third party for the Red Teaming exercises to ensure that an organization does not take
measures associated with the real attack without verifying that an attack is indeed under way
(i.e., the activity they are seeing does not originate from an exercise). The trusted third party
provides an agent for the testers, the management, and the IT and security staff that mediates
the activities and facilitates communications. This type of test is useful for testing not only
network security, but also the IT staff's response to perceived security incidents and their
knowledge and implementation of the organization's security policy. The Red Teaming may be
conducted with or without warning.
Of the two types of penetration tests, Blue Teaming is the least expensive and most frequently
used. Red Teaming, because of the stealth requirements, requires more time and expense. To
operate in a stealth environment, a Red Team will have to slow its scans and other actions to
move below the ability of the target organizations Intrusion Detection System) and firewall to
detect their actions. However, Red Teaming provides a better indication of everyday security of
the target organization since system administrators will not be on heightened awareness.
A penetration test can be designed to simulate an inside and/or an outside attack. If both
internal and external testing are to be performed, the external testing usually occurs first. With
external penetration testing, firewalls usually limit the amount and types of traffic that are
allowed into the internal network
from external sources. Depending on what protocols are allowed through, initial attacks are
generally focused on commonly used and allowed application protocols such as FTP, HTTP, or
SMTP and POP.
Stages of a Pen-Test
Gathering Information : In this we wish to collect maximum information about application
from all available sources. Analyzing the Infra-Structure
Analyzing the Machines
Fingerprinting
Port / Vulnerability-Scanning
Attacking the System / Proof of Concept
Analyzing Applications
-
8/4/2019 Application Security Cloud
26/31
Page 26 of31
Functional / Structural Analysis
Attacking Authentication and Authorization
Attacking Data and Back-End Communication
Attacking
Most vulnerabilities exploited by penetration testing and malicious attackers fall into the
following categories:
Kernel FlawsKernel code is the core of an operating system. The kernel code enforces the
overall security model for the system. Any security flaw that occurs in the kernel puts
the entire system in danger.
Buffer OverflowsA buffer overflow occurs when programs do not adequately check input
for appropriate length, which is usually a result of poor programming practice. When
this occurs, arbitrary code can be introduced into the system and executed with the
privileges of the running program. This code often can be run as root on Unix systems
and SYSTEM (administrator equivalent) on Windows systems.
Symbolic LinksA symbolic link or symlink is a file that points to another file. Often there
are programs that will change the permissions granted to a file. If these programs run
with privileged permissions, a user could strategically create symlinks to trick these
programs into modifying or listing critical system files.
File Descriptor AttacksFile descriptors are nonnegative integers that the system uses to
keep track of files rather than using specific filenames. Certain file descriptors have
implied uses. When a privileged program assigns an inappropriate file descriptor, itexposes that file to compromise.
Race ConditionsRace conditions can occur when a program or process has entered into a
privileged mode but before the program or process has given up its privileged mode. A
user can time an attack to take advantage of this program or process while it is still in
the privileged mode. If an attacker successfully manages to compromise the program or
process during its privileged state, then the attacker has won the race. Common race
conditions include signal handling and core-file manipulation.
File and Directory PermissionsFile and directory permissions control the access users andprocesses have to files and directories. Appropriate permissions are critical to the
security of any system. Poor permissions could allow any number of attacks, including
the reading or writing of password files or the addition of hosts to the list of trusted
remote hosts
-
8/4/2019 Application Security Cloud
27/31
Page 27 of31
TrojansTrojan programs can be custom built or could include programs such as
BackOrifice, NetBus, and SubSeven. Kernel root kits could also be employed once access
is obtained to allow a backdoor into the system at any time.
Social EngineeringSocial engineering is the technique of using persuasion and/or
deception to gain access to, or information about, information systems. It is typicallyimplemented through human conversation or other interaction. The usual medium of
choice is telephone but can also be e-mail or even face-to-face interaction. Social
engineering generally follows two standard approaches. In the first approach the
penetration tester poses as a user experiencing difficultly and calls the organizations
help desk in order to gain information on the target network or host, obtain a login ID
and credentials, or get a password reset. The second approach is to pose as the help
desk and call a user in order to get the user to provide his/her user id(s) and
password(s). This technique can be extremely effective.
--------------------------------------------------------------------------------------------------------------------------
-
8/4/2019 Application Security Cloud
28/31
Page 28 of31
Appendices B
Rating of various vulnerabilities : commonly used in various models
Attribute Rating RatingValue
Related Exploit Range(Access Vector) *
Remote 1.0
Local 0.7Type of Fix Available(Remediation Level) *
Official Fix 0.87
Temporal Fix 0.9Work around 0.95None 1.0
Report Confidence * Unconfirmed 0.9
Uncorroborated 0.95Confirmed 1.0
Attack Complexity(Access Complexity) *
Required 0.8
Not Required 1.0Level of AuthenticationNeeded (Authentication)*
Required 0.6
Not Required 1.0
Vulnerability GeneralPopularity
Listed as Top 1.0Not Listed as Top 0.8
Technical Severity * Complete 1.0
Partial 0.7None 0
Asset-Value Impacts Complete 1.0
High 0.9Medium 0.6Low 0.3None 0
Vulnerability LocalPopularity
Frequently exploited 1.0
Got exploited, but notfrequently
0.9
Never got exploitedbefore
0.7
Attractiveness of Asset
Computer
Attractive 1.0
Neutral 0.8Not Attractive 0.7
Value Importance High 1.0
Medium 0.6Low 0.3
-
8/4/2019 Application Security Cloud
29/31
Page 29 of31
References and Bibliography
1. Suvda Myagmar Adam J. Lee William Yurcik Threat Modeling as a Basis for Security
RequirementsNational Center for Supercomputing Applications (NCSA) , University of Illinois at Urbana-
Champaign.
2. Frank Swiderski, Window Snyder, Threat Modeling, 2004, Microsoft Press
3. Michael Howard and David LeBlanc, Writing Secure Code, Second Edition, 2003, Microsoft
Press
4.Jan Steffan, Markus Schumaker, Collaborative Attack Modeling,2002, http://www.ito.tu-
darmstadt.de/publs/pdf/sac2002.pdf
5.Pete Lindstrom, Model Making Without Glue, August 2004,
http://infosecuritymag.techtarget.com/ss/0,295796,sid6_iss446_art927,00.html
6.J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and AnandhaMurukan, June 2003,
7.Threat Modeling Resources,http://cyberforge.com/weblog/aniltj/archive/0001/01/01/550.aspx
8.Ambler, W. S (2005). Introduction to security threat modeling. Agile Modeling. Available at
http://www.agilemodeling.com/artifacts/securityThreatModel.htm
9.Casteele, S.V. (2005). Threat modeling for web application using STRIDE model.
Davis, N., Howard, M., Humphrey, W., McGraw, G., Redwine Jr., S. T., Zibulski, G., &
10.Graettinger, C.(2004). Processes to produce secure software: Towards more secure
software. A report at National Cyber Security Summit, Vol. 1. Available at
http://www.cigital.com/papers/download/secure_software_process.pdf
11.De Cock, D., Wouters, K., Schellekens, D., Singelee, D., & Preneel. B. (2005). Threat modelingfor security tokens in web applications. In Proceedings of the IFIP TC6/TC11 International
Conference on Communications and Multimedia Security (CMS 04) September 2004, pp 183-
193.
12. M. Howard. Fending off future attacks by reducing attack surface. http://msdn.microsoft.
com/library/default.asp?url=/library/en-us/dncode%/html/secure02132003.asp,
2003.
13 M. Howard, J. Pincus, and J.M. Wing. Measuring relative attack surfaces. In Proc. of
Workshop on Advanced Developments in Software and Systems Security, 2003.
14 P. Manadhata and J. M. Wing. Measuring a systems attack surface. In Tech. Report CMUCS-
04-102, 2004.
15. P. K. Manadhata, J. M. Wing, M. A. Flynn, and M. A. McQueen. Measuring the attack
Surface of two FTP daemons. In ACM CCS Workshop on Quality of Protection, October
2006
16. Griggs, I. (2004). Browser threat model. Retrieved from http://iang.org/ssl/browser threat
model.html
-
8/4/2019 Application Security Cloud
30/31
Page 30 of31
17. Hoglund, G. & McGraw, G. (2004). Exploiting software: How to break code. Addison Wesley
Professional.
18.Klein, S. A. (2005). Position paper on voting system threat modeling. Available at
http://vote.nist.gov/threats/papers/threat-modelling.pdf
19. Swiderski, F. & Snyder, W. (2004). Threat modeling. Microsoft Press Professional Book
Series20.Ellison, R. J. (2005, September).Attack trees. Retrieved March 1, 2006 from
https://buildsecurityin.us/cert.gov/portal/article/bestpractices/requirements_engineering/atta
ck-trees.xml
21.Meier, J. D., Mackman, A., Dunner, M., Vasiereddy, S., Escamilla, R., & Murukan, A.
(2003, June). Improving web application security: threats and countermeasures. MSDN.
Retrieved February 25, 2006 from http://msdn.microsoft.com/library/en-
us/dnnetsec/html/THCMCh03.asp?frame=true
22.MSDN (n. d.). Evaluating security threats. Retrieved March 1, 2006 from
http://msdn2.microsoft.com/en-us/library(d=robot)/ms172104.aspx
23.Software Protection and Application Security: Understanding the Battleground?
A. Main1 P.C. van Oorschot, Cloakware Corporation, Ottawa, Canada
Computer Science, Carleton University, Ottawa, Canada
------------------------------------------------------------------------------------------------------------------
-
8/4/2019 Application Security Cloud
31/31