Cloud Application
Security
Technical 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 its
effect
on
Cloud
computing
paradigm.
Key words : Cloud computing , Application Security , cloud
security
M S Prasad
1/17/2011
INDEX
Cloud Application Security
1.0 Introduction
a. OWASP Threat analysis
b. Approaches to Application security
2.0 Threat Modeling
3.0 Threat Modeling Techniques
4.0 Threat Prioritization & Mitigation
Appx A : Penetration Testing
Appx B ; Ratings of various vulnerabilities
References & Bibliography
Page 2 of 31
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
Page 3 of 31
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 use
c. Often based on SOA architecture
d. Untrusted Public Network
Cloud has a higher application security risk due to its open web centric use and also a large
number of user's 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 application
specification 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
Page 4 of 31
*Buffer Overflows
*Directory Traversals
The threat perception is inherently unpredictable and in large part out of control of the
enterprise. At the most , the developers can help the security team in understanding attack
vectors and signatures to monitor for. Threat management has a large detection and response
component involved in it . Detection component involves a good monitoring and Auditing
process and its management. Threat Management tools and processes include: Security
Monitoring, Web Application Firewall, Security Incident Management Processes, Security Event
Management System, Incident Response Planning Processes and Forensic Analysis Process and
Tools.
For successful comprehending the Threat and its associated vulnerabilities, Threat Modeling
have been found a better concept and logical in its approach.
OWASP Threat Analysis
The OWASP Top Ten provides a detail document for web application security representing a
broad consensus about what the most critical web application security flaws are. Most of them
also applicable to normal applications also. The top tens are :-
A1 - Cross Site Scripting (XSS)
XSS flaws occur whenever an application takes user supplied data and sends it to a web
browser without first validating or encoding that content. XSS allows attackers to execute script
in the victim's browser which can hijack user sessions, deface web sites, possibly introduce
worms, etc.
A2 - Injection Flaws
Injection flaws, particularly SQL injection, are common in web applications. Injection occurs
when user-supplied data is sent to an interpreter as part of a command or query. The attacker's
hostile data tricks the interpreter into executing unintended commands or changing data.
A3 - Malicious File Execution
Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data,
resulting in devastating attacks, such as total server compromise. Malicious file execution
attacks affect PHP, XML and any framework which accepts filenames or files from users.
A4 - Insecure Direct Object Reference
Page 5 of 31
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 )
Page 6 of 31
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 .
Page 7 of 31
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": Survivable--or resilient--software 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 to
Software 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
Page 8 of 31
Threat Modeling
Security Requirements
definition
Development of security
Mechanism
Vulnerability
Collect Data
Risk analysis
analysis
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.
------------------------
Page 9 of 31
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 .
Page 10 of 31
Add New Comment