The Manager s Guide to Web Application Security A Concise Guide to the Weaker Side of the Web

by Ron Lepofsky

The Manager s Guide to Web Application Security A Concise Guide to the Weaker Side of the Web

Publisher :

Author : Ron Lepofsky

ISBN : 9781484201497

Year : 2014

Language: en

File Size : 1.96 MB

Category : Computers Technology

Introduction
Executives and security technologists need a common understanding of web
application security risks and how to find and fix them. This book provides common
points of understanding to enable both groups to collaborate on building secure web
application frameworks.
The book translates with simplicity and brevity the technical world of threats,
vulnerabilities, mitigation, prevention, and level of technical risk into language that
executives can quickly understand.
Similarly, the book shows executives how to express their need to understand cost,
risk and risk reduction, and return on investment in terms security technologists can
relate to.

About the Book
Chapter 1 explains how to calculate IT security risk, including descriptions of risk-related
terms that are applicable. These terms will then be used elsewhere throughout the book.
Chapter 2 identifies and explains the various types of web application security audits.
Chapter 3 identifies web application vulnerability classes, specific vulnerabilities, and
their risks. Chapter 4 covers the vulnerabilities’ remediation.
Chapters 5 and 6 discuss the prevention of web application vulnerabilities, including
how to manage security of third-party applications. Chapter 7 shows how to integrate
compliance to various standards with security. Chapter 8 brings it all together by
explaining how to create a business case to cost justify web application security, and
Chapter 9 offers some final thoughts.
Appendices A through H provide more details on compliance standards and sources
of expert information.

Companion Files
There are several companion spreadsheets which are used in Chapters 1, 7, and 8. You
can download them from the Source Code/Downloads tab on the book’s Apress web page
(www.apress.com/9781484201497).
These spreadsheets are designed for the reader to readily implement the various
strategies proposed in this book.
The first set of spreadsheets is used for various calculations of risk in Chapter 1.
Another spreadsheet provides a summary of vulnerability classes, specific vulnerabilities,
and their remediation and risks discussed in Chapters 3 and 4. The Summary of Risk and
Remediation, with Compliance Standards Added table from Chapter 7 also is included.

xxiii


■ Introduction

Finally, the Chapter 8 spreadsheets are calculators of risk, costs, and returns on
investment, which form the business case for cost-justifying web application security.
These spreadsheets include a template for creating a weighted score of the health of
security for any specific environment.

Contact and More Information
I would be happy to answer any questions or respond to any feedback from readers of this
book. Perhaps we can implement these discussions into a second edition! Please feel free
to contact me at [email protected] or request further documentation on security
subjects related to this book at my web site www.ere-security.ca.

Disclaimer
The advice and information I give in this book are of general applicability and may not
be suitable in specific applications. I urge managers always to consult their IT security
specialists before implementing any security measures. I cannot accept any legal
responsibility for any errors or omissions that may be made or information or advice given.

xxiv


Chapter 1

Understanding IT Security
Risks
There seems to be a lot of confusion about security terms and concepts. This confusion
often leads to poor decisions that waste both valuable time and money. A proactive
approach in determining the associated costs of potential losses should a web application
breach occur would be the first step in creating countermeasures to reduce the chance
of such events ever happening. Without a clear understanding of the proper security
requirements and the associated costs, security teams are often misdirected in their
persuits. This ends up being counterproductive and often ends in poor decisions or no
decisions at all.
For instance, I often hear executives say they want a penetration test, when what they
really want is a less expensive and more useful vulnerability assessment. Or management
will say it wants a security audit report, but they have no idea of what they will do with it,
because they are not familiar with the term risk analysis in relation to the security of web
applications.
This chapter will remediate the terminology problem.

Web Application Security Terminology
The core message of this book is about helping readers to quickly, clearly eliminate risk in
the realm of web application security. Chapters 2 and 3 dive right into identifying the key
classes of web application vulnerabilities and the business risks they pose. The terms in
Chapters 2 and 3 are those used by security technologists to describe elements of security
and how they relate to one another.
Prior to reading these two chapters, it will be helpful to review these elements
and their interrelationship with one another. What follows are definitions of the most
important terms that will be covered:


Risk: Risk is the possibility of loss as the result of a danger or
threat. In this context, we mean the loss of confidentiality,
availability, or integrity as the result of an IT security threat. Risks
are typically rated as high, medium, and low severity.

1


Chapter 1 ■ Understanding IT Security Risks



Relative risk: In the context of this book, relative risk refers
to risk severities in comparison to one another, in a specific
environment. For instance, the risk prior to addressing a threat
will be higher than after addressing the threat. Risks associated
with two separate threats are another more meaningful example.
Or the results of one type of threat may pose a greater risk than
those of another type of threat. When performing a risk analysis, it
is useful to allocate values to risk. A person creating a risk analysis
will want to use comparative values for various risks in order
to offer clarity to business decision makers. So, for instance, an
analyst may assign an 80 percent risk to a high-risk situation, but
he may assign a 20 percent risk to a lower-risk situation. These
risks are relative with respect to each other rather than being
absolute in relationship to the entire Internet world.



Temporal risk: A temporal risk is one that changes over time due
to changes in the security environment, and is not necessarily
directly related to any change to a particular vulnerability.
For instance, if a patch to the affected software that removes
vulnerability is made available to Internet users, the risk severity
decreases as soon as that patch is successfully implemented.
Temporal risk is defined for clarity, but this term will not be used
in this book.



Threat: A threat is a danger posed to a web application. There
are several sources of threats, such as malware, hackers,
cybercriminals, and others with malintent.



Vulnerability: A vulnerability is a weakness that is subject to
compromise by a threat. For instance, an unlocked door poses the
vulnerability of a thief opening the door, but only if it is unlocked.
If the door is locked, there is no vulnerability for the thief, who is a
high-risk threat if the door is unlocked but a very-low-risk threat if
the door is, in fact, locked.



Breach: A security breach is a threat that takes active advantage of
a weakness or vulnerability and may compromise the application.
In the example just given, a thief actively opening the unlocked
door is an act of compromise. A breach is more associated with
vulnerabilities.



Compromise: A compromise is a synonym for a breach
except the term is more associated with risk. I use breach and
compromise interchangeably.

2


Chapter 1 ■ Understanding IT Security Risks



Mitigation: A mitigation is a repair or a protection made as a
defense against a threat. A mitigation either repairs vulnerability
or reduces its seriousness in order to make the vulnerability
less susceptible to compromise by a threat. Risk is reduced by
mitigation.
As a physical analogy for a logical security problem, we can use
the example of an unlocked door to a building. A mitigation for
the unlocked door may have three components:





Locking the door immediately



Making a policy that everyone who opens the door must
subsequently leave it locked



Making a policy that once per day a designated person
checks that the door is locked, always at different times

Countermeasure: A countermeasure is often used instead of a
mitigation when the vulnerability simply cannot be removed and
a work-around is required. An example is where there are known
code vulnerabilities within a web application but the code cannot
be modified for valid business reasons. A countermeasure to
these vulnerabilities could be a web application firewall.
However, a countermeasure can also refer to a safeguard that
addresses a threat and mitigates risk. A countermeasure is usually
associated with a threat and a mitigation is usually associated
with a risk. I use the terms countermeasure and mitigation
interchangeably because, in practice, they are functionally
equivalent.



Residual risk: Residual risk is the risk that still remains after
mitigation. This may sound unclear at first, as one assumes
mitigation reduces risk to zero. However, in a situation with
high risk vulnerability, there may be reasons why the risk can
only be reduced but not completely eliminated. In the analogy
of the unlocked door, for example, if the locked door policy
is laxly followed and the designated lock checker misses an
unlocked door, residual risk arises. In addition, residual risk can
reoccur, particularly in a dynamic environment where changes
subsequent to mitigation virtually undo the mitigation or create
new vulnerabilities.

3


Chapter 1 ■ Understanding IT Security Risks

Risk Calculation Models
There are many models for calculating risk in the area of IT security. What follows is a
selection of the better-known risk-analysis methodologies or tools:


CRAMM: An acronym standing for the “CTCA risk analysis and
management method,” it refers to a process of analysis that
combines assets, threats, and vulnerabilities to evaluate risk and
come up with a list of countermeasures.



DREAD: “Damage, reproducibility, exploitability, affected users,
discoverability” is a Microsoft model focused on vulnerabilities
and their outcomes. DREAD comes with a scoring plan that
makes creating a quantitative DREAD score straightforward and
less qualitative.



STRIDE: “Spoofing identity, tampering with data, repudiation,
information disclosure, denial of service, and elevation of
privilege” is a model focused on types of threats.

■■Note DREAD and STRIDE are measurement systems that are sometimes used in
conjunction with each other. 


FRAP: The “facilitated risk analysis process” is a type of
qualitative risk analysis focused on organizing teams from
business units in order to address security.



OCTAVE Allegro: Developed by CERT, “operationally critical
threat, asset and vulnerability evaluation” is a suite of tools,
techniques, and methods for risk-based information security
strategic assessment and planning. There are two versions of
OCTAVE: full OCTAVE for large organizations and OCTAVE-S for
small organizations.



Spanning Tree Analysis: This is a technique for creating a “tree”
of all possible threats to a system.

There are other risk assessment models, and the reader can pick and choose which
components make most sense from each of them. I have chosen to focus on DREAD as an
example to drill down on simply because I use this model, as well as STRIDE, in all of my
audit reports.

4


Chapter 1 ■ Understanding IT Security Risks

DREAD
The DREAD model is a widely used methodology for calculating the degree of risk
presented by a threat. It involves attaching a numeric score to five risk variables and then
calculating another score for a particular threat. Information about DREAD is available
on the Open Web Application Security Project (OWASP) web page (www.owasp.org).
The five variables for calculating risk in the DREAD model are:


Damage potential: Assesses how much damage an exploited
vulnerability could cause. The more damage, the higher the risk.



Reproducibility: Determines the degree of difficulty of
reproducing or making an exploit happen. The easier the
reproduction, the higher the risk.



Exploitability: Evaluates the degree of expertise, time, and tools
needed to execute the exploit. The easier the process, the higher
the risk.



Affected users: Calculates the number and importance of users
that could be affected. The larger the number and the higher the
importance, the higher the risk.



Discoverability: Assesses the ease of identifying the threat, which
might range from one that is obvious and is shown in a web
browser address bar to one that is not documented and is very
difficult to detect. The more difficult to detect, the higher the risk.

You then assign one of the following values to each of the five variables to get a clear
indication of the security posture:
0 = Nothing
5 = Medium risk description
10 = High risk description
An example is a cross-site scripting vulnerability, whose DREAD score may be:
Damage potential: 10
Reproducibility: 5
Exploitability: 10
Affected users: 10
Discoverability: 5
Total score: 40
In this case, the reader can infer from the high total score that the vulnerability
has great large damage potential to a great number of users and should be mitigated
immediately.

5


Chapter 1 ■ Understanding IT Security Risks

How to Calculate Web Application Security Risk
Not to put too fine a point on this, but it is useful to understand how security
experts calculate security risk. An agreed-to understanding of the definition of
risk among executives and their security teams is a key element for more clear,
concise communication. This will be useful in Chapter 2, which associates classes of
vulnerabilities with risk; in Chapter 4, which explains how to remediate vulnerabilities;
and in Chapter 8, which explains the structure of a business case for justifying web
application security. In Chapter 8, actual values of risk are used.
Since executive management teams prefer to think of IT security in terms of risk,
currency, and return on investment, it is useful for them to instruct IT security technology
experts to translate technical security into language that they can understand. Chapter 8
explains how to do this in detail.

Standard Calculations
I will first look at the standard risk calculation method and then show a customized
version. Next, I will use the customized version to show examples of three types of risk
calculation:


Calculating any security risk



Applying that calculation to multiple risks threatening a
single asset



Calculating the monetary value at risk for an asset

In most real-life business environments, calculations of risk are based upon
estimated values pertaining to the technology side of risk, generating estimated values
for risk and the cost of risk. Industry experts such as ISC(2) (International Information
Systems Security Certification Consortium) and ISACA (formerly Information Systems
Audit and Control Association, but now known just by the ISACA acronym) publish
equations for calculating risk using the following variables:


The monetary value of loss associated with the compromise of
any specific asset



The probability that a specific type of security breach/event will
occur for a specific asset



The estimated number of times per year a specific breach/event
will occur. This type of statistic may be available from publishers
of information on risk. However, it is not easy to gather statistics
about security events, as many organizations are reticent to
divulge data about their security events.

Annual loss expectancy is calculated by multiplying
the expected loss in $ × the probability of a specific breach
× the estimated number of occurrences per year.

6


Chapter 1 ■ Understanding IT Security Risks

A Customized Approach
I have created a slightly different version of the risk calculation, which attempts to
estimate the risk of an event by articulating the variables that security technologists live
with on a daily basis:


Any key asset and the estimated monetary loss expected to result
from a breach



The existence of a threat to that asset



Any security vulnerabilities associated with that asset



Any mitigation/prevention steps currently being deployed

I believe that a meaningful way of calculating risk is to attach estimated values to
each of these variables, with an explanation to management of how the estimates were
derived. The values can be expressed in the following ways:


As a dollar value for the loss of any key asset. This is the dollar
value at risk if the asset were to be compromised. It could be the
cost of production downtime, legal costs, or other costs
associated with a loss. This is discussed in more detail in Chapter 8,
which identifies how to create business cases involving return
on investment. Management is the best source for providing the
monetary value of each key asset and the expected monetary loss
associated with any key asset.



As a percentage value indicating the possibility that a threat exists.
The existence of a threat could be 100% if there is a known threat.
However, in some cases the value could be less than 100%, such
as if the existence of a threat is predicted but not confirmed.



As a percentage value that a vulnerability to the known threat
exists. If there is no vulnerability susceptible to a threat, the
vulnerability value is 0%. If a vulnerability is highly susceptible to
a threat, the value is 100%. If there is a vulnerability that is difficult
to compromise by the threat, the vulnerability is assigned some
other percentage.

The confidence level in any mitigation/preventative step is expressed as a percentage
value. The value may vary widely depending upon in-house experience, shared
experiences among the professional-security world, in-house testing, and security-audit
testing by impartial third parties.

7


Chapter 1 ■ Understanding IT Security Risks

Calculating a Security Risk
The steps for calculating a security risk are:
1.

Identify each asset in scope. Use the following process
for each asset.

2.

Identify the existence of a threat to an asset. If a threat exists,
then the percentage value of the threat is, of course, 100%.

3.

Identify any security vulnerabilities associated with an asset.
The percentage represents the degree of risk posed by a
vulnerability. For instance, a medium-to-high risk may
be 80%, while a very low risk may be 10%.

4.

Identify mitigation steps and what percentage of risk remains
after they are taken. If the mitigation reduces risk completely,
then the risk is 0%.

The idea here is that when risk is multiplied by the currency value of an asset, the
value at risk will be zero value for a zero risk factor and at the other extreme will be simply
the currency value of an asset.
The following equation is an example calculation of security risk. Estimated values
for each factor are then given.
% risk = existence of a threat to that asset
´ any security vulnerabilities associated with that asset
´ any mitigation/prevention steps deployed

Factors for calculating risk

% values assigned by the
security technology team

Existence of a threat to the asset

100%

Risk posed by security vulnerabilities
associated with the asset

80%

Percentage of risk remaining after
mitigation/prevention steps are deployed

5%

If we replace the factors in the equation with these values, the calculation becomes
100% ´ 80% ´ 5%,
which results in the risk percentage being 4%.

8


Chapter 1 ■ Understanding IT Security Risks

Calculating Risk from Multiple Vulnerabilities for
Any Asset
In the typical case where multiple threats are posed to an asset, the total risk for all the
threats is calculated by adding up the sum of all risks. Because this calculation is designed
to give an overall impression of the risk faced by an asset, the idea is not to calculate
an actual value but to look at the relative values across all assets in scope. It is easy to
understand the reasoning here: as several risk factors for any one asset could total over
100%, it is the relative values that are important here.
This step is, of course, optional. It utilizes the risk calculations generated from the
previous calculations of risk for each vulnerability. The total risk is calculated as follows:
total % risk = sum of all the individual risks for each vulnerability, or
vulnerability A + vulnerability B + vulnerability C

Factors for calculating
$ value at risk

% values assigned by the
security technology team

Risk for vulnerability A

4%

Risk for vulnerability B

10%

Risk for vulnerability C

17%

If we replace the factors with their values, the calculation becomes
4% + 10% + 17% = 31% total risk

Calculating the Monetary Value at Risk for Any Asset
So far, we have just calculated pure risk for each asset. The next step is to add, for any key
asset in question, the estimated monetary loss expected as the result of a breach.
For simplicity, the currency in the following example is in dollars. Here, the dollar
value at risk, $1,000,000, is multiplied by the risk value previously calculated, 4%.
The value at risk might have been obtained using the executive straw poll in Chapter 8
for determining estimated values at risk from security breaches.
The calculation for monetary value at risk is
$ value at risk = $ value of the expected loss for a specific asset
× total % risk facing the asset

Factors for calculating $ value at risk

Value of factors

$ value of expected loss for a specific asset

$1,000,000

Total % risk facing the asset

4%

9


© 2018-2019 uberlabel.com. All rights reserved