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


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


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


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


5/31


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 )


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/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


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


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 .


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


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.


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.


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


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


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 .


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)


18/31


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 .


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.


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


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.


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


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)

----------------------------------------------------------------------------------------------------------------------


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


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


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.

--------------------------------------------------------------------------------------------------------------------------


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


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


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

------------------------------------------------------------------------------------------------------------------


31/31

application security cloud

Documents