OUTLINE

Seeren ...

..--
r ~~----·'.:.; m Secunng Web
Aopncauons

16. lntroduclion

16. lntroduclion

16. lntroduction

ie, lntroduclion

16.1. Prelirrunaries:
Govemance

16.2. Pre-development:
Threat Modeling and
Design

16.3. Oevelopment:
Architecture

. -

---- 16.4. Oevelopment:

Code Reviews
r&. lntr_oCluction
------
§]
REF
,~i, f.
. LABS VIDEO
OUTLINE

Search ...

2 Securing Web Applications

Securinq Web
' Apphcatrons

• 16 lntroducllon

This module focuses on the widely accepted best

practices necessary to secure web applications. lt ;:_:;~::: 16. lntroduction

is important to note that securing web applications - ...----··

~~~~~: 16. lntroduction

is a continuous process: Even a perfectly secure

=...- 16. lntroduclion

web application will eventually become vulnerable

as new attack vectors are discovered, • r=.:11
l==:J s.1. Prelirrunaries:
Govemance

vulnerabilities against libraries and software 16.2. Pre-development:

• ;-:::;;-::.::=.::=:
Threat Modeling and
:,.:;:::·-~=- Design

packages become known and published, etc. ~ 16.3. Oevelopment:

• ~ Architecture

elea rnSecu rity © 2013

. ---- 16.4. Oevelopment:
Code Reviews
16. lntroäuction §]
REF
,~i, f.
. LABS VIDEO
OUTLINE

Search ...

3 Securing Web Applications

Securinq Web
Apphcatrons

In some sections of this module we will mention • 16. lntroduction

the relevant sections of the Business Security In - ...----··

Maturity Model (BSIMM), a freely available study
~~~~~: 16. lntroduction

that analyzed fifty one well-known leading =...- 16. lntroduclion

software security initiatives including companies

• r=.:11
l==:J s.1. Prelirrunaries:
Govemance

like: Google, Microsoft, Visa, Intel, VMware, SAP, 16.2. Pre-development:

• ;-:::;;-::.::=.::=:
Threat Modeling and

Nokia, Symantec, etc. :,.:;:::·-~=- Design

~ 16.3. Oevelopment:
• ~ Architecture

elea rnSecu rity © 2013

. ---- 16.4. Oevelopment:
Code Reviews
16. lntroäuction §]
REF
,~i, f.
. LABS VIDEO
OUTLINE

Search ...

4 Securing Web Applications

Securinq Web
' Apphcatrons

Whether you already have management buy-in in

your company or you are interested in security but ;:_:;~::: 16 lntroducllon

need help to "convince management about it", the

BSIMM is a great resource with real-world metrics
• 16. lntroduction

that will provide a backup foundation to certain =...- 16. lntroduclion

parameters such as "how many in-hause security

• r=.:11
l==:J s.1. Prelirrunaries:
Govemance

testers should the company have?", this kind of 16.2. Pre-development:

• ;:.:::;;-::.::=.::=:
information has been collected and averaged out
Threat Modeling and
:,.::;::·-~=- Design

in the BSIMM study. ~

• ~
16.3. Oevelopment:
Architecture

16.4. Oevelopment:
• ---- Code Reviews
elea rnSecu rity © 2013
16. lntroäuction §]
REF
,~i, f.
. LABS VIDEO
OUTLINE

Search ...

5 Securing Web Applications

Securinq Web
Apphcatrons

1 -:· 116. lntroducllon

·-- --
.. ..--
:_::.::-: 16 lntroducllon

---·...----··
---------
.. --~
_______...--·-..-...
--
-·-·--
------ ----.. 16. lmrooucuon

An introduction to the BSIMM can be found here:

• 16 lntroduction

http ://bs im m. eo m/fa cts/

16.1. Prelirrunaries:
Govemance

. ----~-
---~---- ..-
;::.:.;::.;;~
16.2. Pre·development:
Threat Modeling and
Design

16.3. Oevelopment:
Architecture

elea rnSecu rity © 2013

. ---- 16.4. Oevelopment:
Code Reviews
 OUTLINE

Search ...

6 Securing Web Applications

Securinq Web
Apphcatrons

Security governance is perhaps the most important ;:_:;~::: 16 lntroducllon

element in any software security program: - ...----..

~~~~~: 16. lntroduction

Without management buy-in there will be no

=...- 16. lntroduchon

budget allocated to secure web applications, and

without a budget any security initiative will be very
161. Prehrmnaries
• Govemance
•

limited. • [!§:_J
~ 16.1.1.Strategyand
Metncs

~ 16.1.2. Preliminaries:
~ Govemance

• 1-===-~ 16.1.3 •. Policy and

Comphance

elea rnSecu rity © 2013

16.l!.l!. Strateg_"' anCI Metr.ics §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

7 Securing Web Applications > Preliminaries: Governance

Securinq Web
Apphcatrons

In order to make a software security program

successful, management must define: ·-- --
.. ..--
::=::::=-...:=.:.
==--~== 16 lntroducllon

A software This provides transparency of executive management

security strategy expectations to staff
=...- 16. lntroduchon
Objectives of the The objectives define the direction of the software
software security security initiative
program
Accountable Accountability of results is necessary to ensure the
owners of such success of the initiative ·~
- 16.1.1.Strategyand
fvletncs

objectives
Metrics to track Software security initiatives need to define metrics so
progress that progress can be measured

elea rnSecu rity © 2013

• 1 1 16.1.3. Policy and
16.l!.l!. Strateg_"' anCI Metr.ics §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

s Securing Web Applications > Preliminaries: Governance

Securinq Web
Apphcatrons

Example metrics:
·-- --
.. ..--
Time-To-Fix: How long it takes to fix a vulnerability (i.e. in
:_::.::-: 16 lntroducllon

days or hours) ---·...----

~~~-~=: ...--·-.....
16. lntroduction

=...- 16. lntroduchon

Annual Exposure: Number of days per year in which the

website was exposed to (at least) one serious security
vulnerability.
-
Remediation cost per defect: How much money costs to
fix each defect. •
161.1. Strategy
and Meines

elea rnSecu rity © 2013

• 1 1 16.1.3. Policy and
 OUTLINE

Search ...

9 Securing Web Applications > Preliminaries: Governance

More information and general guidelines to achieve

this can be found in the following BSIMM section: -
-
16 1 2. Prelrminaries:
Governance

• Governance: Strategy and Metrics {SM) L:'.j

• t:::=j
16.1.3. Policyand
Compliance

The overall goa/s for the Strategy and Metrics practice are
transparency of expectations and accountability for results. • 1==----=---
---::: __ "·:l 16.1.4. Training

Executive management must clarify organizational expectations

for the SSDL so that everyone understands the importance of the
initiative. In addition, executive management must set specific • ;:.:::z-::.::=.s:
16.2. Pre-development:
Threat Modeling and
=:::-::;::·-~=- Design

objectives for all SSDL stakeholders and ensure that specific

individua/s are made accountab/e for meeting those objectives. ~
• ~
16.3. Oevelopment:
Architecture

http://bsimm.com/online/qovernance/sm/
elea rnSecu rity © 2013
. ---- 16.4. Oevelopment:
Code Reviews
16.l!.3. P.olic'l anCI ComP-liance §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

10 Securing Web Applications > Preliminaries: Governance

,.. • 16.1.3. Pol1cyand

Policy and compliance are necessary to ensure the

Compüance

auditability of the software security program and

may be even required by vendors sometimes. • 1=----·
~~.:--
=--~---
::..116.1.4. Training

• ---~---
16.2. Pre-development:
--------
=--::=,;:· Threat Modeling and
Design

-~---
·---- ....--~
-- 16.3. Development:
Architecture

elea rnSecu rity © 2013

• 1 16.4. Development:
16.l!.3. P.olic'l anCI ComP-liance §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

11 Securing Web Applications > Preliminaries: Governance

While an in-depth discussion on policy and

compliance in software security initiatives is out of
scope for this course, the BSIMM study provides
excellent guidance on this topic: · 1-== --116.1.3. Pohcy and
Comphance

• Governance: Complianceand Policy {CP) ~ 161.3.Policyand

- Compüance
The overall goals for the Compliance and Policy practice are
prescriptive guidance for all stakeho/ders and auditability of • 1=~~.
----·:--
=--~---
::..116.1.4. Training

SSDL activities. Management-approved prescriptive guidance

must be available to all SSDL stakeholders, including vendors, for
use in meeting security and comp/iance objectives. All SSDL 16.2. Pre-development:
• ;:-=::.-::.::=.::=:
activities must produce artifacts sufficient to allow auditing for :.:·::.:-_:·-~=-
Threat Modeling and
Design

adherence to prescriptive guidance.

http://bsimm.com/online/qovernance/cp/
elea rnSecu rity © 2013
• 1 16.4. Development:
16.l!.~. iTraining §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

12 Securing Web Applications > Preliminaries: Governance

Training can be an excellent tool to reduce the

number of security defects introduced in web
applications (through developer training) as well as · 1-== --116.1.3. Pohcy and
Comphance

improve detection of security defects (through

secu rity testi ng tra in i ng).
• • 16 1 4. Training

However, this training will need tobe approved by

16.1.4. Training
-
management and is therefore part of the company
software security governance. EJ •
16.1.5. Further
Reading

16.2. Pre-development:
• ;'=2:."::.:::0E Threat Modeting and
=....::::::·-"=· Design

elea rnSecu rity © 2013 ::=-~:=~16.3. Development:

• :.-::-:.:2.=:::_ Architecture
16.l!.~. iTraining §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

13 Securing Web Applications > Preliminaries: Governance

The BSIMM study provides useful guidelines

regarding development training:
• Governance: Training (T) · 1-== --116.1.3. Pohcy and
Comphance

The overall goa/s for the Training practice are the creation
of a know/edgeab/e workforce and correcting errors in
processes. The workforce must have role-based knowledge • 1=~~.
----·:--
=--~---
::..116.1.4. Tra.nmq

that specifically includes the skills required to adequately

• 16.14. Tra1111ng

perform their SSDL activities. Training must include specific

information on root causes of errors discovered in process
activities and outputs.
EJ •
16.1.5.
Reading
Further

16.2. Pre-development:
• ;'=2:."::.:::0E Threat Modeting and
=...::::::·-"=· Design
http://bsimm.com/online/qovernance/tl
elea rnSecu rity © 2013 ::=-~:=~ 16.3. Development:
• :.-::-=:..=:;:_ Architecture
 OUTLINE

Search ...

14 Securing Web Applications > Preliminaries: Governance

More information about this topic can be found

in the following online resources:
NIST Information Security
The full BSIMM study can be
downloaded here
Handbook: A Guide for · 1-== --116.1.3. Poltcy and
Comphance
Managers

Managing Information Security

Risk
Information Security
Governance: Standardizing the
• 1=~~.
----·:--
=--~---
::..116.1.4. Tra.nmq
Organization, Mission, and
Practice of Information Security
Information System View
~ 16 1.4. Tra ning

OWASP OpenSAMM - Software 7 16.1 5. Further

.
Read1ng
OWASP OpenSAMM - Software Assurance Maturity Model •'
Assurance Maturity Model A guide to building security into
software development ---~ ---
---a----
;:;.--:::,;;~
16.2. Pre-development:
Threat Modeting and
Design

elea rnSecu rity © 2013 ·---- --

___ .._a--~
.. 16.3. Development:
Architecture
 OUTLINE

Search ...

is Securing Web Applications

---a-a
• 1=-··;- =--116.1.4.
=----=-----
Tranmg

Threat modeling attempts to guess the potential

attacks that will be performed against the web .,..
16 2 Pre-development:
Threat Modehng and
Design

application (ideally) before it is even designed or

•

16.2. Pre-
development: Threat

built.
Modeling and Design

This is a very important step in order to design the

application correctly later, reducing the attack
surface as much as possible.
. -----
::=-~:=~16.3.. Development:

.
::-.::.::.:--- Arerutecture

elea rnSecu rity © 2013 ---- 16.4. Development:

Code Reviews
 OUTLINE

Search ...

16 Securing Web Applications

---a-a
• 1=-··;- =--116.1.4.
=----=-----
Tranmg

This section focuses on specific defense strategies

to prevent security defects when they are the "' ;-==::.-:.::==-.::=:
:.=·-;;::·
16.2. Pre-development:
Threat Mode mg and
Design

cheapest to fix: Before they are created. --------

------
----
---
-----
----
16 2. Pre-
development Threat
Modellng and Design

A smart web application design will sometimes

prevent entire classes of attacks and in other
situations at least reduce the likelihood of a
successful attack significantly.
. -----
::=-~:=~16.3.. Development:

.
::-.::.::.:--- Arerutecture

elea rnSecu rity © 2013 ---- 16.4. Development:

Code Reviews
 OUTLINE

Search ...

11 Securing Web Applications

---·-·
• 1=-··;- =--116.1.4.
=----=-----
Tranmg

Threat modeling and web application design "' ;-==::.-:.::==-.::=:

:.=·-;;::·
16.2. Pre-development:
Threat Mode mg and
Design

should work together to reduce the attack surface 16.2 Pre-

development: Threat

of the application as well as facilitate centralized

Modeling and Design

162.Pre-

security controls during the architecture phase as

development Threat
Modeling ano Design
•

much as possible.

----.. .._--_
.. ___
·-----
::-
-------
16.3. Development:

-----
--·----- Architecture

elea rnSecu rity © 2013 . ---- 16.4. Development:

Code Reviews
 OUTLINE

Search ...

is Securing Web Applications > Pre-development: Threat Modeling And Design

------
• 1=-··;-
=----=-----
=--116.1.4. Tranmg

16.2. Pre-development:
"' ;-==::.-:.::==-.::=: Threat Mode mg and
:.=·-;;::-
In order to perform threat modeling, the first step Design

16.2 Pre-

is to determine the kind of attacker the web development: Threat

Modeling and Design

application should be defended against as well as 16.2 Pre-

development: Threat
Modeling and Design

the motivations behind such attackers. ____

--------
----- .,_
16 2.1 Types of

---- Altacker and

Mctivanons

B
16.2.1.Typesof
Artacker and
Motivations

16.2.1. Types of
Attacker and
Motivations

16.2.1. Types of
Artacker and
Motivations
elea rnSecu rity © 2013
 OUTLINE

Search ...

19 Securing Web Applications > Pre-development: Threat Modeling And Design

16.1.4. Tra nmg

The following are the three major attacker types:

Usual Attack
Attacker type Usual motivations Usual Skill
type
Insider (i.e. Personal gain, company embarrassment 16.2. Pre-development:
,.. ;-==::.-:.::==-.::=: Threat Mode mg and
disgruntled Targeted Low-High :.=·-;;::- Design
employee)
16.2 Pre-
Terrorists / development: Threat
Hacktivists / Political, ldeological, Farne Opportunistic Low-Medium Modeling and Design

Vandals
'- - 16.2 Pre-
development: Threat
Modeling and Design
Opportunistic
Corporate spy Steal company secrets for competitive advantage Medium-High
Targeted
.. - -
Opportunistic
Organized crime Financial gain Medium-High 1621.Typesof
Altacker and
Targeted Motivations

Steal company secrets for competitive advantage - 16.2. 1. Types of

Government spy Targeted High-Very High Artacker and
Gather intelligence an other country's secrets Motivations
~ - - -
16.2. 1. Types of
Artacker and
Motivations
elea rnSecu rity © 2013
 OUTLINE

Search ...

20 Securing Web Applications > Pre-development: Threat Modeling And Design

• 1=-··;- =--116.1.4.
---a-a
=----=-----
Tranmg

From the table above, it is easy to infer that a web 16.2. Pre-development:
"' ;-==::.-:.::==-.::=: Threat Mode mg and
:.=·-;;::-
application that requires to be defended from Design

16.2 Pre-
organized crime (i.e. a banking web application) development: Threat
Modeling and Design

will need to invest more in security than a web 16.2 Pre-

development: Threat
Modeling and Design

application that requires to be defended from

vandals (i.e. a charity web application).
B 16.2.. 1 .Typesof
Attacker and
Motivations

1621 Typesof
Altacker and
Motivations
•
16.2.1. Types of
Artacker and
Motivations
elea rnSecu rity © 2013
 OUTLINE

Search ...

21 Securing Web Applications > Pre-development: Threat Modeling And Design

• ---~---
=-.:;..~:-.:;.:.
16.2. Pre-development:
Threat Mode'ing and
=-...:::=..---
""··----·-·-- Design

16.2. Pre-
development: Threat

lt is also important to note the "attack type"

Model1ngand Design

16.2. Pre-

column:
development: Threat
Model1119 and Design

16 2 1 Types of
Altacker and
Motivations

16.2.1 Types of
Altacker and
Motivations

16 2 1 Types of
Altacker and

m
Motivations

162.1. Typesof
Altacker and
Motivations

16.2.1. Types of
Altacker and
Motivations

16.2. 1. Types of
Altacker and
Motivations

~ l:_::.:=:--116.2.2. Attack Models

elea rnSecu rity © 2013
 OUTLINE

Search ...

22 Securing Web Applications > Pre-development: Threat Modeling And Design

---·--- 16.2. Pre-developrnent:
,.. ;:--.::.=::-.:::. Threat Mode'ing and
::,:..:::.;::·-~=- Design

16.2. Pre-

Opportunistic attackers
development: Threat
Modeling and Design

Will simply try to find something easy to exploit

16.2. Pre-
development: Threat
Modeling and Design

and if they do not find it they will move on to the

next target. For example, an exploit for Apache/a
library you are using/etc. is published on Friday 16.2.. 1 .Typeser
Altacker and

night, and attackers search the internet for the

Motivations

16 2 1 Types or

vulnerable version for an easy target du ring the Altacker and

Motivations

following month. Opportunistic attackers will also 16 2.1 Types of

Altacker and

try a few things to exploit the application but

f\~otivatioos

. 1621 Typesof

move on to the next target if vulnerabilities are not •

Attacker and
Motivations

easy to find. 16.2. 1. Types of

Artacker and
Motivations

~ l:_::.:=:--116.2.2. Attack Models

elea rnSecu rity © 2013

 OUTLINE

Search ...

23 Securing Web Applications > Pre-development: Threat Modeling And Design

---~---
• ==.::.~-==·
16.2. Pre-development:

-----
Threat Mode'ing and
""·· ----·-·-- Design

16.2. Pre-
development: Threat
Modeling and Design

Targeted attackers 16.2. Pre-

development: Threat
Modeling and Design

Targeted attackers will be more persistent, their

motivation is something that the web 16.2.. 1 .Typeser
Altacker and
Motivations

application has and they will not give up easily 16 2 1 Types or

Altacker and

on their attempts to steal such information. Motivations

16 2.1 Types of
Altacker and

This type of attacker is much more difficult to f\~otivatioos

16.2.1 Types of

defend against. Artacker and

Motivations

1621.Typesor
Attacker and
Motivations
•

~ l:_::.:=:--116.2.2. Attack Models

elea rnSecu rity © 2013

16.2.2. Ättacl< Moi:lels §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

24 Securing Web Applications > Pre-development: Threat Modeling And Design

16.2.. 1 .Typeser
Altacker and
Motivations

16 2 1 Types or
Altacker and

Once the possible attacker types have been

Motivations

16 2.1 Types of
Altacker and

identified (i.e. we have an idea of who might attack f\~otivatioos

16.2.1 Types of

the web application and why), it is time to analyze

Artacker and
Motivations

16.2.1 Types of

the potential features of the future web Altacker and

Motivations

application. This will help determine how attackers 16 2 2. Atlack Models

may attem pt to breach security controls. ~ 16.2.2. Atlack

~Models

r-===I
bJ 16.2.2. Auack
Models

r-===I
16.2.2. Attaek
~Models

elea rnSecu rity © 2013

16.2.2. Ättacl< Moi:lels 1 §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

25 Securing Web Applications > Pre-development: Threat Modeling And Design

lnstead of creating attack models from scratch for 16.2 .. 1 .Types of

Altacker and

every project, companies should instead: Motivations

16 2 1 Types of
Altacker and
Motivations

16 2.1 Types of
Altacker and

Create a repository of attacks f\~otivatioos

16.2.1 Types of

•Add and tag previous attacks to the repository Altacker and

Motivations

16.2.1 Types of
Altacker and
Motivations

· l:_::.__ "":--l 1622At1ackModels

~ 16 2 2 Allack
~Models

r-===I
bJ 16.2.2. Atlack
Models

r-===I
16.2.2. Attack
~Models

elea rnSecu rity © 2013

16.2.2. Ättacl< Moi:lels §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

26 Securing Web Applications > Pre-development: Threat Modeling And Design

' .
Create a repository of attacks
16.2.. 1 .Types of
Altacker and
Motivations

16 2 1 Types of
Altacker and
Motivations

16 2.1 Types of
Altacker and
f\~otivatioos

16.2.1 Types of
Altacker and
Motivations

The attack repository needs tobe kept up-to-date. 16.2.1 Types of

Altacker and
Motivations

· l:_::.__ "":--l 1622AttackModels

~ 16.2.2. Attack
~Models

ii 16 2 2. Attack
Models

16.2.2. Attack
Models

elea rnSecu rity © 2013 16.2.2. Attack

r><1'"1rll"!"
16.2.2. Ättacl< Moi:lels §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

27 Securing Web Applications > Pre-development: Threat Modeling And Design

16.2.1 Types of
Artacker and
Motivations
Add and tag previous attacks to the repository 16.2.1 Types of
Altacker and
Motivations

· l:~:.__"":--l 1622AttackModels

~ 16.2.2. Attack
~Models

~ 1622.Attack

These can be attacks against the company or ~Models

liiii
against other companies. -
16 2 2. Attack
Models

~ 16.2.2. Attack
~Models

r::::::=I
16.2.2. Atlack
~Models

r====J
16.2.2. Atlack
~Models

l:=i
l==:J 16.2.2. Atlack
Models

elea rnSecu rity © 2013

16.2.2. Ättacl< Moi:lels §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

29 Securing Web Applications > Pre-development: Threat Modeling And Design

16.2.1 Types of
Artacker and
Motivations

16.2.1 Types of
Altacker and
Motivations

· l:~:.__"":--l 1622AttackModels

~ 16.2.2. Attack
~Models

Keeping a record of proven mitigations avoids r-===I

1622.Attack
~Models

reinventing the wheel each time and may help r-===I

16 2 2. Attack
~Models

reuse code and save development effort as well. ~ 1622.Atlack

~Models

liii!ii 16 2 2 Attack
- Models

r-===I
16.2.2. Attack
~Models

l:=i
l==:J 16.2.2. Attack
Models

elea rnSecu rity © 2013

16.2.2. Ättacl< Moi:lels §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

30 Securing Web Applications > Pre-development: Threat Modeling And Design

16.2.1 Types of
Artacker and
Motivations

16.2.1 Types of
Altacker and
Motivations

· l:~:.__"":--l 1622AttackModels

~ 16.2.2. Attack
~Models

Same possible application profiles could be: B 16 2 2. Attack

Models

banking, ecommerce, blog, education, utilities, etc. [a 16 2 2. Attack

Models

16 2 2. Atlack
- - Models

[3 16.2.2. Attack
Models

ii 16 2 2. Atlack
Models

16.2.2. Attack
Models

elea rnSecu rity © 2013 16.2.2. Attack

16.2.2. Ättacl< Moi:lels §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

31 Securing Web Applications > Pre-development: Threat Modeling And Design

16.2.1 Types of
Artacker and
Motivations

16.2.1 Types of
Altacker and
Motivations

· l:~:.__"":--l 1622AttackModels

~ 16.2.2. Attack

Once this attack repository is created and actively ~Models

r-===I 1622.Attack

maintained in the company, it will be easy to reuse ~Models

r-===I
the effort in new projects simply selecting the ~Models
16 2 2. Attack

application profile of the future web application. ~

~Models
1622.Atlack

r::::::=I
~Models
16.2.2. Attack

r-===I
~Models
16 2.2. Attack

16 2 2. Attack
Models
•

elea rnSecu rity © 2013

16.2.2. Ättacl< Moi:lels §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

32 Securing Web Applications > Pre-development: Threat Modeling And Design

r-===I
~Models
1622.Attack

r-===I
~Models
16 2 2. Attack

Knowing the attacker types that the web ~ 1622.Atlack

application should be defended against as well as

~Models

r::::::=I 16.2.2. Attack

having the attack repository, will facilitate analysis ~Models

r-===I
to determine how the most likely attacks will be
16 2.2. Attack
~Models

mitigated.
In many cases, having best practice mitigations
1622 Attack
Models
•

against each attack in the repository will facilitate ~ 16.2.2. Attack

~Models

effort reuse in new projects.

~ 16.2.4. Further
~ Readmg

elea rnSecu rity © 2013

16.2.2. Ättacl< Moi:lels §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

33 Securing Web Applications > Pre-development: Threat Modeling And Design

r-===I
~Models
1622.Attack

r-===I
~Models
16 2 2. Attack

The BSIMM study provides excellent guidance on

~ 1622.Atlack
~Models

attack models: r::::::=I

~Models
16.2.2. Attack

lntelligence: Attack Models (AM) r-===I

~Models
16 2.2. Attack

• The overall goal for the Attack Models practice is the 1 _ __ 1 ~!~e~sAttack

creation of customized knowledge on attacks relevant i='J

~Models
16.2.2. Attack

to the organization. Customized knowledge must guide ~ 16 2 2 Attack

decisions about both code and controls. - Models

~ 16.2.4. Further
http://bsimm.com/online/intel/iqence/am/ ~ Readmg

elea rnSecu rity © 2013

 OUTLINE

Search ...

34 Securing Web Applications > Pre-development: Threat Modeling And Design

r-===I
~Models
1622.Attack

r-===I
~Models
16 2 2. Attack

~ 1622.Atlack
~Models

In many cases, the vulnerability is introduced r::::::=I

~Models
16.2.2. Attack

through poor web application requirements. r-===I

~Models
16 2.2. Attack

The design stage of a web application is one of the 1 _ __ 1 ~!~e~sAttack

best phases to lock down the application and i='J

16.2.2. Attack
~Models

prevent a wide number of security issues. ~ 16.2.2. Attack

~Models

1623.Example
,,. Design
Requiremsnts
•

elea rnSecu rity © 2013

 OUTLINE

Search ...

35 Securing Web Applications > Pre-development: Threat Modeling And Design

This is best illustrated through examples:

B 16 2 2. Attack
Models

Requirement introducing a security issue Requirement avoiding a security issue

[a 16 2 2. Attack
Models

16 2 2. Atlack
-
- Models
".. users will get their forgotten password in an email .." ".. users will receive an email containing a link to reset
Reasoning: This implies passwords are stored in clear-text
in the database (i.e. no encryption). "
their password, that will only be valid during four hours ..
[3 16.2.2. Attack
Models

".. a list of all system users will be displayed on the home ".. No list of system users will be displayed on the home
screen, along with their email addresses .." screen, nor their email addresses ."
t3 16 2.2. Attack
Models

16 2 2 Attack
Models
Reasoning: This implies user enumeration by design ~

. 16.2.2. Attack

".. passwords should be at least 8 characters long and ".. passwords should be at least 16 characters long, users - Models

include upper and lower case letters, at least one number will be presented with links to tutorials to use password
16.2.2. Attack
and at least one non-alphanumeric symbol .. " managers and password generators so that they use
- - Models

Reasoning: 8 character passwords are too short by secure passwords and avoid reusing their passwords on
16 2.3 Example
different websites .. "
....
---
modern standards. Design
Requirements

=
162.3.
Example
Design Requ1 .

16.2.3.
elea rnSecu rity © 2013 Example
l)pc::ion RP<111i
 OUTLINE

Search ...

36 Securing Web Applications > Pre-development: Threat Modeling And Design

16 2 2. Auack
Models
Requirement introducing a security issue Requirement avoiding a security issue ~

".. screen flow for each data model will be custom, ".. screen flow for each data model will be consistent in the . 16 2 2. Atlack
full of Javascript, etc .... " application, the exact same screen flow will be used by all data - Models

Reasoning: Potentially unnecessary complexity models ." 16.2.2. Allack

will inevitably lead to security issues Reasoning: This will make the implementation of centralized - - Models

security controls significantly easier and more cost-effective to

16 2.3. Exarnple

---
implement. .... Design
Requirements
" a public search function will allow finding ".. the public search function will allow finding registered users,
registered users ... " however, the following mitigations will be in place to reduce the
Reasoning: Lack of mitigations against abuse of risk of extracting all this information from our database via the
the public search public search: ... "
1623.
Example
Reasoning: The design adds requirements to mitigate full data Design Requ1 „

extraction via abuse of the public search function.

-
1 1 ED1~;;pleR .
es1gn equ1 ...

".. we will store this valuable information ..."

".. in order to reduce the attack appeal of the application we will
Reasoning: Storing valuable information may not store X, Y and Z ... "
r:::;i
~
ED1~;;pleR .
es1gn equ: ...

make the application more appealing to be Reasoning: The impact of a security breach has just been reduced
attacked by a design decision. The easiest way to avoid becoming a target ~. ~~;;ple
~ Design Requi. ..
is oftentimes to prevent storage of sensitive/valuable information
from the point of view of a prospective attacker.
~ ED1~;;pleR .
~ es1gn equi ...

~ 16.2.4. Further
elea rnSecu rity © 2013 1;~:~-1 Reading
 OUTLINE

Search ...

37 Securing Web Applications > Pre-development: Threat Modeling And Design

l':=i
~Models
16 2 2. Auack

i=J
~Models
16 2 2. Atlack

~ 16.2.2. Allack
~Models

A good web application design will facilitate the

architecture and development phases by providing
the functionality the customer needs with the
most simple application complexity possible. 1623.
Example
Design Requi, ..
•

16.2.3.
Example
Design Requi, ..

16.2.3.
Example
Design Requi ...

16.2.4.
elea rnSecu rity © 2013 . Further
Rea d1ng
 OUTLINE

Search ...

38 Securing Web Applications > Pre-development: Threat Modeling And Design

l':=i
~Models
16 2 2. Auack

i=J
~Models
16 2 2. Atlack

~ 16.2.2. Allack
~Models

The design stage is also a great phase to devise

and create security requirements, so that attack
mitigationsbecome features that will be
consideredand unit tested from the early 16.2.3.
Example
Design Requi

development stages. 1623

Example
Design Requi, ..
•

16.2.3.
Example
Design Requi ...

16.2.4.
elea rnSecu rity © 2013 . Further
Read1ng
 OUTLINE

Search ...

40 Securing Web Applications > Pre-development: Threat Modeling And Design

l':=i
~Models
16 2 2. Auack

i=J
~Models
16 2 2. Atlack

~ 16.2.2. Allack
~Models

lntelligence:Standardsand Requirements (SR)

• The overall goal for the Standardsand Requirements practice is
to create prescriptive guidance for all stakeho/ders. Managers
and the SSG must document software security choices and convey
this material to everyone involved in the SSDLJ including external 16.2.3.
Example
parties. Design Requi

16.2.3
http://bsimm.com/on li ne/i ntel 1 igence/sr / Example
Design Requi

16.2.3.
Example
Design Requi

1623
Example
Design Requi, ..
•

16.2.4.
elea rnSecu rity © 2013 . Further
Rea d1ng
 OUTLINE

Search ...

41 Securing Web Applications > Pre-development: Threat Modeling And Design

16.2.3.

More information about this topic can be found Example

Design Requi

16.2.3

in the following online resources: Example

Design Requi

16.2.3.
Example
Design Requi

't5
III
16.2.3.
Example
E
„
Design Requi
3 Approaches to Threat V Microsoft SOL Threat
16 2 4. Further
Modeling ••• Modeling Tool - Read111g

-~_ .. _.... __
·---- --~
Microsoft's Free IOActive: Threat • ::..-::-:=:-.,:.::::_
16.3. Development:
Architecture
==·-==--=-
Security Tools - Threat
Modeling
Modelling Best
Practices . ---- 16.4. Development:
Code Reviews

16.5. Development:
• -·----
===-...:::::::=.
----· Security Testing

elea rnSecu rity © 2013 16.6. Deployment:

 OUTLINE

Search ...

42 Securing Web Applications > Pre-development: Threat Modeling And Design

16.2.3.
Example
Design Requi

16.2.3
Example
Design Requi
OWASP Development Guide: OWASPApplication Threat
16.2.3.
Threat Risk Modeling guidance Modeling Example
Design Requi

16.2.3.
Example
Design Requi

OWASPOpenSAMM - Software OWASPOpenSAMM - Software - 16.2.4. Further

Readmg

Assurance Maturity Model Assurance Maturity Model

16 2 4. Further
SAMM - Threat Assessment SAMM - Security Requirements Readmg

.. _.... __
•

-~_
·---- --
~
16.3. Development:
Architecture

OWASP OpenSAMM - Software

Assurance Maturity Model
SAMM
. ---- 16.4. Development:
Code Reviews

16.5. Development:
• -·----
===-...:::::::=.
----· Security Testing

elea rnSecu rity © 2013 16.6. Deployment:

 OUTLINE

Search ...

43 Securing Web Applications

16.2.3.
Example
Design Requi

A web application which was not architected with 16.2.3

Example
Design Requi
security in mind will generally be much easier to 16.2.3.
Example

attack. Design Requi

16.2.3.
Example

The architecture phase of web application

Design Requi

- 16.2.4. Further

development reuses the work from previous Readmg

phases, most notably threat modeling and design,

and tries to mitigate and provide default • -
-
16 3. Developmenl.
Arctutecture

protections against as many of the envisioned • 1·-;;:,._ - 116.3.1. Architeetural

Oecistcn Examples

attacks as possible.

~ 16.3.3. Further
elea rnSecu rity © 2013 1 i., :~ 1 Reading
 OUTLINE

Search ...

44 Securing Web Applications > Development: Architecture

The following are some examples of good 16.2.3.

Example
Design Requi

architectural web application decisions: 16.2.3

Example
Design Requi

Architectural decision Reasoning 16.2.3.

Example
Design Requi
lmplementing access control in a single centralized
"We will use a front controller to centralize access location will be significantly less error-prone than 16.2.3.
Example
control" "implementing access control in every single file of Design Requi

the application"
"All data models will inherit an 'application base - 16.2.4. Further
Readmg
lmplementing a generic mechanism to enforce
model' that will enforce data-driven access control
permissions will be less error-prone, architectural
permissions such as 'users cannot view records
decisions should focus on centralizing security

·----.._....__
outside of their department id', every model will
have a 'department id' to facilitate this data access
controls as much as possible, this is just another
example.
-~_ --
~
16.3. Development
Arctutecture
enforcement"
"Each user will connect to the database using their This is an architectural example of the principle of
.,.. ~ 163.1.Archileclural
own database user permissions, which will be "least privilege", now if there is an application flaw - Decision Examples

locked down to the tables and records they can that fails to restrict data access, the database
16.3.1.
access, a generic script will be created to setup permissions will still stop the user from viewing Architectural
Decision Examples
these permissions" information they should not be able to access
16.3.1.
Architectural
elea rnSecu rity © 2013 Decision Examples
 OUTLINE

Search ...

45 Securing Web Applications > Development: Architecture

16.2.4. Further
Rea d1ng

Architectural decision Reasoning

"After this research, we have decided that we will

use the following crypto library and algorithms
Using a vetted third-party crypto library is always a ... :::.=-=:=~_
:.:-=:.~:-=:...--
16.3. Development
great idea, crypto implementation is very hard and Arctutecture

instead of rolling our own. Third-party reviews of

this library give us enough assurance that their
crypto implementation is solid."
"rolling your own" is a guarantee for getting it
wrang. · I' ·m - 116.3.1 Archlle<:lural
Oecisron Examples

16.3.1.
Code reuse is a great architectural decision, Arctutectcrat
Oecision Exarnples
frameworks that provide good protections against
"We will use this framework because it will - 16.3.1.
a number of web application attacks by default are Architectural
provide us with mitigations against these web Decision Examples
an automatic reduction of risk because it will be
application attacks by default out of the box"
harder for developers to introduce security 16.3.2. Archite<:tural
problems by mistake. -- Decision Examples

"We will load all files from this directory, outside This architectural description provides mitigations
16.3.3. Further
of the webroot so that they are not directly against path traversal attacks (i.e. using a file id Reading

.
-
callable from the URL, a front controller will instead of the file path) as weil as a significant
dispatch these files using a file id, which we will attack surface reduction (all files are stored
check against a file map verifying user permissions outside the webroot, they cannot be attacked
---·-- 16.4. Development:
Code Reviews

before allowing access" individually)

elea rnSecu rity © 2013

. ------
..
----·__
:::.=.~:::.."":::....-
_,
16.5. Development:
Security Testing
 OUTLINE

Search ...

46 Securing Web Applications > Development: Architecture

16.2.4. Further
Rea d1ng

Architectural decision Reasoning

?.::.::.:=.-~ 16.3. Development

"Client-side validation can be bypassed and

• :.:-=:.~:-=:...-- Arctutecture

will make server-side validation difficult to

test for QA, for this reason, client-side
lt is often the case that server-side validation
is not implemented because of client-side
· I' -m - 116.3.1 Archlle<:lural
Oecisron Examples

validation will not be implemented or a flag validation. This architectural decision will 16 31
Arclutecturat
will be setup so that client-side validation facilitate server-side validation testing Decision Examples
can be turned oft to ensure server-side significantly and make server-side validation 16 3.1.
validation can be verified as efficiently as much more likely tobe implemented. Arcrutectcrat
Oecision Exaniples

possible"
16.3.2. Alchite<:tural

-- Decision Examples

"The web application will write user-

This small architectural decision just made 16.3.3. Further
provided files in the database, the web Reading

.
uploading a shell to the web root directory -
server should not be able to write files in the
of the application much more difficult.
fi lesystem"
---·-- 16.4. Development:
Code Reviews

16.5. Development:
Security Testing
elea rnSecu rity © 2013
 OUTLINE

Search ...

48 Securing Web Applications > Development: Architecture

16.2.4. Further
Rea d1ng

More information about this topic can be found

in the following online resources: ... =:-=-=:=~ _
:.:-=:.~:-=:...--
16.3. Development
Arctutecture

Classic ASP Design

OWASP Development · I' ·m - 116.3.1 Archlle<:lural
Oecisron Examples
Guide: Security
Mistakes
architecture guidance 16 31
Arclutecturat
Decision Examples

16.31
Arctutecturat
Decisron Examples
OWASP Development OWASP OpenSAMM -
Guide: Rich interface Software Assurance ~ 16.3 2 Archlle<:lural
~ Decision Examples
architecture guidance Maturity Model (1)
. 16 3 3. Further
Readrng

.
•
OWASP OpenSAMM - OWASP OpenSAMM -
Software Assurance Software Assurance ---·-- 16.4. Development:
Code Reviews

Maturity Model (2) Maturity Model(3)

elea rnSecu rity © 2013

. ------
..
----·__
:::.=.~:::.."":::....-
_,
16.5. Development:
Security Testing
 OUTLINE

Search ...

49 c.z . .ct. t-urtner

Securing Web Applications Readmg

_-~_
____.. .... __
_ __~ 16.3. Development
Arctutecture

,.. ~ 16.3.1 Archlle<:lural

~ Oecisron Examples

16 31
Arclutecturat
Decision Examples

16.31
Arctutecturat
Decisron Examples

Now let's move to code reviews. ~

~
16.3 2 Archlle<:lural
Decision Examples

16.3.3. Further
Readmg

16 4 Development.
Code Revisws

16.4.1. lntroduction

16.4.2. Static Analysis

Tools

elea rnSecu rity © 2013

16.4.l!. lntroauction §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

so Securing Web Applications > Development: Code Reviews c.z . .ct. t-urtner
Readmg

_-~_
____.. .... __
_ __.. 16.3. Development
Arctutecture

Code reviews serve a number of useful purposes: · I' -m - 116.3.1 Archlle<:lural

Oecisron Examples

16 31
Arclutecturat
Decision Examples

16.31
Arctutecturat
Decis1onExamples

~ 16.3 2 Archlle<:lural
~ Decision Examples

. ---·-- 16.4. Development

Code Reviews

----···
• ~ 16.4.1. lntroduction

~ 16.4.1. lntroduction
~
elea rnSecu rity © 2013
16.4.l!. lntroauction §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

sa Securing Web Applications > Development: Code Reviews

· I =- -- 116.3.1 Archllecturat
Dec1s1on Examples

16 3.1
Arcrntecturat
oectsioo Examptes

16 3.1
Architecturat
Decision Exa1nples
Code reviews can be useful to identify the type of errors
that each developer tends to make. This helps to identify:
• Developers who can teach security training to other developers
These are the ones creating the least amount of vulnerabilities, the
ones that tend to produce more secure code, can help bring the

•
other deve/opers up to speed.
Developers most in need of security training
. ------ 16.4. Devetopment.
Code Revie~vs

These developers are the ones producing the most insecure code in
the company, training these developers will likely reduce the • 1-- - 116.4.1 lntroduchon

number of future vulnerabilities in new applications.

~ 164.1. lntroduction
• The type of training that each developer needs
For example, if a developer tends to create XSS vulnerabilities,
~:;.-=-::: -~
their training can focus on that. 1 116.4.1. lntroduclion

1 ~-:-~-:~"!
116.4.1. lntroduction

elea rnSecu rity © 2013

16.4.l!. lntroauction §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

sz Securing Web Applications > Development: Code Reviews

· I =- -- 116.Dec1s1on
3.1 Archllecturat
Examples

16 3.1
Arcrntecturat
oectsioo Examptes

16 3.1
Architecturat
Decision Exa1nples

The earlier a security issue is identified, the most cost-

effective it is to fix.
Code reviews help identify security issues and . ------ 16.4. Devetopment.
Code Revie~vs

developers that produce them early, hence helping

provide such developers with guidance soon, before • 1-- - 116.4.1 lntroduchon

they keep extending such security defects to the rest of 1 m = 116.4 1 lntroduchon

the application being developed. iilii 164.1. lntroduclion

1 ~-:-~-:~"!
116.4.1. lntroduction
elea rnSecu rity © 2013
16.4.l!. lntroauction §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

53 Securing Web Applications > Development: Code Reviews

. ------ 16.4. Devetopment.

Code Revie~vs

· 1- - 116.4.1 lntroduchon

Dynamic testing of a web application is great but has

some limitations, like for instance, not being able to 1 m = 116.4 1 lmrocuction

detect administrative scripts reachable through the 1 ~:=--:::_;;;-l 16 4.1 tntrooucüon

webroot that are not linked from the application or - 164.1. lntroduction

poor cryptographic practices in the back-end (i.e.

'=_'."'--116.4.2.
storing passwords in clear-text or using a weak
· 1 Slalic Analysis
• ::.--~- Tools

algorithm such as mdS)

16.4.4.Further
Reading
-
elea rnSecu rity © 2013
 OUTLINE

Search ...

ss Securing Web Applications > Development: Code Reviews

RIPS
RIPS is a static source code analyser for vulnerabilities in PHP webapplications. lt was . ------ 16.4. Devetopment.
Code Revie~vs

released during the Month of PHP Security (www.php-securitv.org).

· 1- - 116.4.1 lntroduchon
PHP Security Audit Tool
This is an open source tool to do static analysis of php code for security exploits
1 m = 116.4 1 lmrocuction

Yasca
Yasca is a source code analysis tool that 1 started writing in 2007. lt could best be 1 ~:=--:::_;;;-l 16 4.1 tntrooucüon

described as a "glorified grep scrlpt" plus an aggregator of other open-source tools.

Yasca can scan source code written in Java, C/C++, HTML, Javascript, ASP, Cold Fusion, ~ 16.4.1 lntrocuction

PHP, COBOL, .NET, and other languages.

~ 16 4 2. Stalle Analysis
Sguale ·~Tools

Squale is a qualimetry platform that allows to analyze multi-language software ~-

applications in order to give a sharp and comprehensive picture of their quality: High E!lil
~ 1642 Staue
Analysis Tools

level factors for top-managers and Practical indicators for development teams
~ 16.4.2. Static
~ Analysis Tools

elea rnSecu rity © 2013

 OUTLINE

Search ...

56 Securing Web Applications > Development: Code Reviews

.NET developers:
FxCop
FxCop is an application that analyzes managed code assemblies (code that targets . ------ 16.4. Devetopment.
Code Revie~vs

the .NET Framework common language runtime} and reports information about
the assemblies, such as possible design, localization, performance, and security · 1- - 116.4.1 lntroduchon

improvements. Many of the issues concern violations of the programming and

design rules set forth in the Design Guidelines, which are the Microsoft guidelines 1 m = 116.4 1 lmrocuction

for writing robust and easily maintainable code by using the .NET Framework.
1 ~:=--:::_;;;-l 16 4.1 tntrooucüon

Gendarme ~ 16.4.1 lntrocuction

Gendarmeis a extensible rule-based tool to find problems in .NET applications
and libraries. Gendarme inspects programs and libraries that contain code in ~ 16 4 2. Stalle Analysis
ECMA CIL format (Mono and .NET} and looks for common problems with the ·~Tools

code, problems that compiler do not typically check or have not historically ~ 16.4.2. s1a11c
checked. ~ Analysis Tools

iBiiiii!i
lliiiil 16 4 2 Staue
Analysis Tools

elea rnSecu rity © 2013

 OUTLINE

Search ...

s1 Securing Web Applications > Development: Code Reviews • 1---- 1 Code Reviews

· 1- -
.NET developers: 116.4.1 lntroduchon

1 m = 116.4 1 lmrocuction

Yasca
Yasca is a source code analysis tool that I started writing in 2007. lt could best be 1 ~:=--:::_;;;-l 16 4.1 tntrooucüon

described as a "glorified grep script" plus an aggregator of other open-source

tools. ~ 16.4.1 lntrocuction

Yasca can scan source code written in Java, C/C++, HTML, Javascript,ASP,
ColdFusion, PHP, COBOL, .NET, and other languages. ~
·~ Tools
16 4 2. Stalle Analysis

~ 16.4.2. Stat1c
~ Analysis Tools

Squale ~
~
16.4 2 Stalle
Analysis Tools
Squale is a qualimetry platform that allows to analyze multi-language software
applications in order to give a sharp and comprehensive picture oftheir quality: llim
~ 1642 staue
Analysis Tools
High level factors for top-managers and Practical indicators for development
teams

~ 16.4.2. Static
~ Analysis Tools
elea rnSecu rity © 2013
 OUTLINE

Search ...

59 Securing Web Applications > Development: Code Reviews • 1---- 1 Code Reviews

· 1- - 116.4.1 lntroduchon

PMD 1 m = 116.4 1 lmrocuction

PMD is a source code analyzer. lt finds common programming fiows like unused variables,
empty catch blocks, unnecessary object creation, and so /orth. lt supports Java, Javascript, 1 ~:=--:::_;;;-l 16 4.1 tntrooucüon

XML, XSL.
Additionally it includes CPD, the copy-paste-detector. CPD finds duplicated code in Java, c; ~ 16.4.1 lntrocuction

C++, C#, PHP, Ruby, Fortran, Javascript.

~ 16 4 2. Stalle Analysis
·~Tools
Yasca
Yasca is o source code analysis tool that I started writing in 2007. lt could best be described ~ 16.4.2. Stat1c
as o "glorified grep saipt" plus an aggregator of other open-source tools. ~ Analysis Tools

Yasca can scan source code written in Java, C/C++, HTML, Javascript, ASP, ColdFusion, PHP, ~ 16.4 2 Stalle
COBOL, .NET, and other languages. ~ Analysis Tools

~ 16.4 2. Stalle
~ Analysis Tools
Squale
Squale is o qualimetry platform thot allows to analyze multi-language softwore applications
in order to give o sharp and comprehensive picture of their quality: High level factors for
top-managers and Practical indicators for development teams
!!!!!II Analysis
~ 16 4 2. Stat1c
Tools
elea rnSecu rity © 2013
 OUTLINE

Search ...

Go Securing Web Applications > Development: Code Reviews

1~:;.~::::-~116 4.1 tntrooucüon

1 ~7~--::~! 116.4.1 lntrocuction

~ 16 4 2. Stalle Analysis
·~ Tools

The main advantage of static analysis tools is code

~ 16.4.2. Stat1c
~ Analysis Tools

coverage: Static analysis tools will analyze all the ~

~
16.4 2 Stalle
Analysis Tools

application source code and for this reason alone ~

~
16.4 2. Stalle
Analysis Tools

they should always be part of the security arsenal

in the secure development lifecycle of a company. ~ 16.4 2. Stalle
~ Analysis Tools

16 4 2. Staue
Analysis Tools
•

i=1
·~Reviews
16.4.3. Manual

~ 16.4.4. Further
elea rnSecu rity © 2013 1 :~·:~ 1 Reading
•
 OUTLINE

Search ...

61 Securing Web Applications > Development: Code Reviews

1~:;.~::::-~116 4.1 tntrooucüon

1 ~7~--::~! 116.4.1 lntrocuction

Automated tools will fail to find many security ~

·~Tools
16 4 2. Stalle Analysis

issues, most notably business logic flaws, failure to ~ 16.4.2. Stat1c

~ Analysis Tools

centralize security controls, security vulnerabilities ~ 16.4 2 Stalle

~ Analysis Tools

where the tainted user input is altered and ~ 16.4 2. Stalle

changes files many times, etc. For this reason,

~ Analysis Tools

while static analysis tools are a must, they should

always be complemented with manual code
~ 16.4 2. Stalle
~ Analysis Tools

•
reviews. l':=i
t==.J 16.4.2 Stat1e
Analysis Tools

.., • 16 4 3. Manual
Rev1e„vs

r.::='1 16.4.3. Manual

elea rnSecu rity © 2013 I~~ 1 Revie„vs
 OUTLINE

Search ...

62 Securing Web Applications > Development: Code Reviews

~ 16.4 2. Stalle
~ Analysis Tools

Manual code reviews should be done by expert

l':=i
t==.J 16.4.2 Stat1c

security team members where possible but also Analysis Tools

encouraged to be done by other development

team members, this is a great best practice that •
16 4.3. Manual
Rev10„vs

will help spark healthy conversations about the .

16.4.3. Manual
Revie„vs

web application security and ideas to secure it. 16.4.4. Further

Reading
-

·-·--- 16.5. Development:

• -·:;. __ •• . Security Testing

elea rnSecu rity © 2013

 OUTLINE

Search ...

63 Securing Web Applications > Development: Code Reviews

~ 16.4 2. Stalle
~ Analysis Tools

When performing manual code reviews, the

l':=i
t==.J 16.4.2 Stat1c

reviewer should focus on how user input enters Analysis Tools

the web application (i.e. taint/source analysis) and

how that input ends up being processed (i.e. sink
analysis), especially "eval-like functions", system 16 4.3. Manual
Rev1e~vs
•

commands, SQL queries, etc. 16.4.4. Further

Reading
-

·-·--- 16.5. Development:

• -·:;. __ •• . Security Testing

elea rnSecu rity © 2013

 OUTLINE

Search ...

64 Securing Web Applications > Development: Code Reviews 1-

More information about this topic can be found

in the following online resources:
BSIMM Study - SSDL
OWASP Code Review
Touchpoints: Code
Guide vl.1
Review (CR)

OWASP OpenSAMM -
OWASP Code Review
Software Assurance
Project .
16.4.3 Manual
Revie·.vs
Maturity Model (1)
16 4 4. Further

.
Reading
•
OWASP OpenSAMM -
Software Assurance :.....:.-~.-
-·----
16.5. Development:
Security Testing

Maturity Model (2)

··-·--·-- 16.6. Deployment:

elea rnSecu rity © 2013

•
--·-
~-;::,-;::.--:;:. Hardening
 OUTLINE

Search ...

65 Securing Web Applications

~ 16.4 2. Stalle
~ Analysis Tools

In the spirit of detecting and correcting security l':=i

t==.J 16.4.2 Stat1c
Analysis Tools

defects as early as possible in the software

development lifecycle, security features should be
validated during development through a 16.4.3 Manual
.
combination of manual and automated analysis. Revie·.vs

16 4.4. Further
Readmg
-

·-~---
-·----
----·.. -
-----
-·----
r.::=1
• ~
16.5.1. Dynamic
Analysis Tools
elea rnSecu rity © 2013
16.5.l!. Dynamic AnalysisiTools §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

66 Securing Web Applications > Development: Security Testing

~ 16.4 2. Stalle
~ Analysis Tools

l':=i
t==.J 16.4.2 Stat1c
Analysis Tools

Expert security staff should engage in security

testing as early as possible during development. In 16.4.3 Manual
.
addition to this, developers should be encouraged
Revie·.vs

16 4.4. Further

to use dynamic analysis tools; -

Readmg

. :::::,.-=._.=::::-
-·----..-
·-·--- 16.5. Development
Secunty TesMg

------·-
-·---·
~ 16.5.1. Dynamic
~ Analysis Tools

elea rnSecu rity © 2013

j ,~-=-.,,=-= j 16.~.1. Dynam1c
'----
16.5.l!. Dynamic AnalysisiTools §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

67 Securing Web Applications > Development: Security Testing

the following is a not comprehensive list of free ~

~
16.4 2. Stalle
Analysis Tools

tools that may be of assistance here: l':=i

t==.J 16.4.2 Stat1c
Analysis Tools

The kd AttCJCk Proxy (ZAP)is an eosy to 1JSe inregrared penetration testina too! for ftndina wlnerabilities in web
OWASPZed applications.
Attack Proxy
~ ~~:1;.~anual
Netsparker Community Edition is a SQL lnjedlon Scanner. lt's a frtt edition of our web llllinerability scanner for the
Netsoarker GOmmunity so you can start securina )'OUr website now. lt's user friendly, fest, smart and CJS always False-Positillf!-Fnre.
Community lt shares many feotures with professional edition. lt can detect SQL lnjection and XSS issues better than many other
scanners (lf not al),and lt's completely FREE.
1§- .:;:..~I ~~: ;.~anual
1

Edition
• 16 4.4. Further
w3af is a Web Appkcmon AttCJCk and Audit Frameworlc. The project's aoal is to create a frameworlc to help you secure • Read1ng
w3af )'Our web appllcations by findina and exploitina all lllt'b appfcation 11ulnerabifti!s. -

16.5. Development
Secunty TesMg

Slcipftsh ls an acti~ web application securlty reronnaissanai tool. lt prepares an lnteroc(i~ sitemao for !he taraeted
skipfish site by carr/ina out a recursille crawl and dictionory-based probes. The result.ina map is then annotated with the · I =-=--
"..::·- · 116.Analysis
5.1 Dynamie
Tools
ovtput {rom a number of acti~ (but hape{ully non-disrupti~) security checlcs. The final report aenerated by the too! ls
meant to sen1e as a {oondation {OT professlonal web appllcation securlty assessments.
l!!iliim
11.!!m 16 5 1. Dvnarmc
Analysis Tools

elea rnSecu rity © 2013

j ,~-=-.,,=-= j 16.5.1. Dynam1c
'------
16.5.l!. Dynamic AnalysisiTools §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

68 Securing Web Applications > Development: Security Testing

~ 16.4.3 Manual
~ Rev1e-.vs

16.4.3 Manual
. Revie·.vs

As we have seen du ring this course, security tools

. :::::,.-=._.=::::-
-·----..-
·-·--- 16.5. Development
Secunty TesMg

are not a panacea and will miss security defects,

for this reason, although security tools provide · 1---
=-=-- ·- · 116.5.1 Dynamie
Analysis Tools

greater code coverage than a human ever would, ~

~
1651 Dynamc
Analysis Tools

automated testing should be complemented with 165.1.Dynamic

Analysis Tools
•

manual testing. l:=:1

l==:J 16.5.1. Dynamic
Analysis Tools

16.5.2. Further

- Reading

• ::::::::::::.:..::?-· 16.6. Deployment:

=-=_-:,y-::.. Hardeninq

elea rnSecu rity © 2013

 OUTLINE

Search ...

10 Securing Web Applications > Development: Security Testing

~ 16.4.3 Manual
~ Rev1e-.vs

More information about this topic can be found .

16.4.3 Manual
Revie·.vs

in the following online resources:

. :::::,.-=._.=::::-
-·----..-
·-·--- 16.5. Development
Secunty TesMg

BSIMM study - SSDL OWASP OpenSAMM - · 1---

=-=-- ·- · 116.5.1 Dynamie
Analysis Tools

Touchpoints: Security Software Assurance

Testing (ST) Maturity Model
~ 1651 Dynamc
~ Analysis Tools

~ 16.51 Dynamic
~ Analysis Tools

OWASP OpenSAMM - l:=:1

l==:J 16.5.1 Dynam c
Analysis Tools
Software Assurance OWASP Testing Project ____ ,,._

Maturity Model ·-- 16 5 2. Further

. ----_.
Readmg

... _ ... _
::::::::..~·
----·---·
16.6. Deployment:
--·-.. ·- Hardening

elea rnSecu rity © 2013

16.6. DepJ2yment: HarClening_ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

71 Securing Web Applications

~ 16.4.3 Manual
~ Rev1e-.vs

16.4.3 Manual
. Revie·.vs

In the spirit of the "defense in depth" security

principle, the deployment environment should be . :::::,.-=._.=::::-
-·----..-
·-·--- 16.5. Development
Secunty TesMg

as hardened as possible in order to mitigate · 1---

=-=-- ·- · 116.5.1 Dynamie
Analysis Tools

potential security vulnerabilities that may have ~ 1651 Dynamc

~ Analysis Tools

been missed and/or are not yet currently known at ~ 16.51 Dynamic

the time of deployment (i.e. a vulnerability ~ Analysis Tools

l:=:1
l==:J 16.5.1 Dynam c

published years after deployment). Analysis Tools

16 5.2. Further

- Readmg

16 6. Deptoyment:
Harderunq

elea rnSecu rity © 2013

16.6.l!. OS Bari:lening
'. §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

ri Securing Web Applications > Deployment: Hardening 1::....=,;;,--:;;J16.5.1Dynam c

~ Analysis Tools

The operating system should be up-to-date with

patches, disable all unneeded features, especially . =~==-:::.
·-·-·---- 16.6. Deployrnent:
=-=_-::.:;:. -=.. Harderung

those that may assist a prospective attacker such

as: tftp, ftp, wget, nc, powershell, perl, python, etc.
III 166.1.0SHardernng

• I ;:.;:.:·· --·-:, 116.6.2. Web Server

Where functionality is needed for administrative ;-~-:;:::.:::_ Hardeninq

purposes but not by the application: Ensure the • 1-- ---=.-:--116.6.3. Application
=-::==::::".:: Hardening

web server operating system user is not able to 16.6.4. Further

Reading
-
access or run unneeded functionality . :-_:_::-_::.;:::~ 16.7. Deployment:
------
• S::-.:.=.=~
-------· Penetration Testing

::-.:::=--::-: 16.8. Post-deployment:

• _ ·- -see- Regular Scanning
elea rnSecu rity © 2013 -:::::- --=- ~
 OUTLINE

Search ...

73 Securing Web Applications > Deployment: Hardening 1::....=,;;,--:;;J 16.5.1 Dynam c

~ Analysis Tools

The web server should be running under a very

restricted user that is not able to do anything eise
than what is strictly needed for the application to . =~==-:
·-·-·----
=-=_-::.:;:.
:.
-=..
16.6. Deployrnent:
Harderung

work.
For example, the OS user the web server runs • -
-
16 6 2. Web Server
Harderunq

under should ideally not be able to run shell r:::::l 16.6.2. Web Server
~ Hardening

commands, write files in the webroot directory, 16.6.2. Web Server

Hardeninq

access sensitive configuration files or directories, .

r::=l
i==.J 16.6.2. Web Server

etc. Hardening

· 1---·-::::·~
• §~-:: 16.6.3. Application
Hardeninq 1
elea rnSecu rity © 2013 j :;==;:··- j ~6.6.4. Further
 OUTLINE

Search ...

75 Securing Web Applications > Deployment: Hardening 1::....=,;;,--:;;J 16.5.1 Dynam c

~ Analysis Tools

Chroot jails are another popular form of . =~==-:

·-·-·----
=-=_-::.:;:.
:.
-=..
16.6. Deployrnent:
Harderung

sandboxing.
For example, ModSecurity now includes support of
Apache eh rooti ng. r:::::l
~
16.6.2. Web Server
Harderunq

- 16 6 2. Web Server
- Harderunq

r::=l
i==.J 16.6.2. Web Server
Hardening

http://www.modsecurity.org/documentation/apache-internal-chroot.html · 1--··-::::·~
• ::,:-_::-·-::
16.6.3. Application
Hardening

elea rnSecu rity © 2013

1
 OUTLINE

Search ...

76 Securing Web Applications > Deployment: Hardening 1::....=,;;,--:;;J 16.5.1 Dynam c

~ Analysis Tools

. =~==-:::.
·-·-·----
=-=_-::.:;:.-=..
16.6. Deployrnent:
Harderung

Whatever the technology used, it is very important

to restrict filesystem permissions and execution
access of binaries in the filesystem.
r:::::l
~
16.6.2. Web Server
Harderunq

16 6 2 Web Server
Harderunq
.
16 6 2. Web Server
Harderunq

· 1---·-::::·~
• ::,:-_::-·-::
16.6.3. Application
Hardening

elea rnSecu rity © 2013

16.6.3. Äf?Rlication HarClening_ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

77 Securing Web Applications > Deployment: Hardening 1=-=---=---·1 Analy~1~ 1 001:>

~ 16.5.2. Further
~ Readmg

. =~==-:
·-·-·----
=-=_-:::;;:.
:.
-=..
16.6. Deployrnent:
Harderung

Same web applications only require access to a

reduced set of IP network ranges, do not
technically require certain features, etc. When this
is the case reducing access to the only needed IP r:::::l
~
16.6.2. Web Server
Harderunq

network ranges and disabling technically c='116

~
6 2 Web Server
Harderunq

unneeded features will reduce the attack surface r::=l

~
16 6.2 Web Server
Harderung

of the application significantly. ..,. • 16 6 3 Apphcatron

Harderunq

elea rnSecu rity © 2013

16.6.3. Äf?Rlication HarClening_ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

78 Securing Web Applications > Deployment: Hardening 1=-=---=---·1 Analy~1~ 1 001:>

~ 16.5.2. Further
~ Readmg

. =~==-:::.
·-·-·----
=-=_-:::;;:.-=..
16.6. Deployrnent:
Harderung

The application should also avoid sensitive sinks as

much as possible. For example "eval-like" functions r:::::l
~
16.6.2. Web Server
Harderunq

or running system commands with user input, etc. c='116

~
6 2 Web Server
Harderunq

r::=l
~
16 6.2 Web Server
Harderung

elea rnSecu rity © 2013

16.6.3. Äf?Rlication HarClening_ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

78 Securing Web Applications > Deployment: Hardening

~ 16.6.2. Web Server

• ~ Harderunq

r:.:::::116.6.2. Web Server

~ Harderunq

i::::1
~
16 6.2 Web Server
Harderunq

The application should also avoid sensitive sinks as r::=l

t==-J 16 6.2. Web Server
Harderung

much as possible. For example "eval-like" functions

or running system commands with user input, etc. 16 6 3 Apphcation
Harderunq
•

16.6.4. Further
Reading
-
------
~---~-----
--~-- 16.7. Deployment:
• ;:;;.~=S:-

.
Penetration T esting

--------
·---- . -
-··- 16.8. Post-deployment:
Regular Scanning
1
~~~
elea rnSecu rity © 2013 '------'
 OUTLINE

Search ...

79 Securing Web Applications > Deployment: Hardening

More information about this topic can be found ~ 16.6.2. Web Server
• ~ Harderunq

in the following online resources: r:.:::::116.6.2. Web Server

~ Harderunq

d i::::1
BSIMM study - 16 6.2 Web Server
LSEC Security ~ Harderunq
Deployment: Software
Hardening 2012
Environment (SE) r::=l
t==-J 16 6.2. Web Server
Harderung

OWASP OpenSAMM - OWASP OpenSAMM -

Software Assurance Software Assurance r::=l
l.==.J 16 6.3. Apphcation

Maturity Model (1) Maturity Model (2) Harderung

16 6 4. Further
Read1119
•
OWASP OpenSAMM - Hardening Guide for
=-:===.=.::.... 16.7. Depfoyment:
Software Assurance EventTracker (v7) • ~~ Penetration Testing

Maturity Model (3) Console

• --------
~'::"'-=-·- 16.8. Post-deployment:
Regular Scanning
1
elea rnSecu rity © 2013 '---------'
 OUTLINE

Search ...

so Securing Web Applications

Once the application has been deployed and ~

• ~
16.6.2. Web Server
Harderunq

hardened, a penetration test should be conducted r:.:::::116.6.2.

~
Web Server
Harderunq

to verify all security controls are working as i::::1

~
16 6.2 Web Server
Harderunq

expected. r::=l
t==-J 16 6.2. Web Server
Harderung

The results from this test should feed into the

procedures in previous phases so that security r::=l
l.==.J 16 6.3. Apphcation

issues that may have been missed in earlier phases

Harderung

16.6 4. Further

are caught earlier in the development lifecycle on -

Readmg

-·
future projects. •
-
-
16 7. Deployrnent:
Penetration Test1119

elea rnSecu rity © 2013

 OUTLINE

Search ...

si Securing Web Applications > Deployment: Penetration Testing

r:.:::::116 6.2. Web Server
~ Harderung

Whether the penetration test is conducted by an i::::1

~
16.6.2. Web Server
Harderung

external company or internal team, the following l:=i

i==.J 16.6.2. Web Server
Harderunq

guidelines apply to get the most out of penetration

testing (i.e. maximum value for money):
l:=i
~
16.6.3. Appl cauon
Hardening
defecf
system 16 6.4 Further
Readmg
-

--- -~-
------
~------- 16.7 Deployment·
• ~=~::;::;~ Penetration Test ng

167.1 Max1m1z1ng
.,.. the value of a
Penetration Test
~

elea rnSecu rity © 2013

 OUTLINE

Search ...

sz Securing Web Applications > Deployment: Penetration Testing

r:.:::::116 6.2. Web Server
~ Harderung

i::::1
~
16.6.2. Web Server
Harderung

l:=i
i==.J 16.6.2. Web Server
Harderunq

This includes network and software architecture

diagrams, source code, documentation, design l:=i 16.6.3. Appl cauon

information, code review results and a ~ Hardening

knowledgeable point of contact for answering -

16 6.4 Further
Readmg

questions.
----·---
.... :::,;::-_::.;::~
:=.=::.:::=:.::.=:..
16.7 Deployment·
Penetration Test ng

Providing a penetration testing team with all the

information available will ensure a much deeper
security assessment likely to find significantly more
iii
16 7 1 Max1m1z1ng
the vslue of a
Penetration Test

security issues.
elea rnSecu rity © 2013
 OUTLINE

Search ...

83 Securing Web Applications > Deployment: Penetration Testing

L=:l
t:::=J 16.6.3. Apphcallon
Harderunq

16.6.4. Further
Readmg
-

An intrusion prevention system should only be

used as an additional security control, for this
reason, when a penetration test is being 16. 7 1 Maxirnizmg
the value ot a
Penetration Test

conducted, the IP address(es) the penetration 16 7.1. Maxun1z1ng

the value of a

testing team is going to use should be white-

Penetration Test

- 16.7.1. Maximizing

listed (i.e. allowed) in the IPS solution so that

the value ot a
Penetration Test

16.7.1. Maximizing

they can focus 100% of the time on testing the the vaiue of a
Penetration Test

web application (i.e. instead of wasting time •

16.7.1. Maximizing
the value ot a
Penetration Test

bypassing the WAF).

•
::-.:::=--::-.:
_ ·- -see-
16.8. Post-deployment:
Regular Scanning
1
elea rnSecu rity © 2013 -:::::- --=- ~
 OUTLINE

Search ...

84 Securing Web Applications > Deployment: Penetration Testing

L=:l
t:::=J 16.6.3. Apphcallon
Harderunq

16.6.4. Further

solution
Readmg
-

Paying a penetration testing team to test a web

16. 7 1 Maxirnizmg

application with a Web Application Firewall the value ot a

Penetration Test

(WAF) in front of it only makes sense when the

16 7 1 Max1m1Z1ng
the value of a
W Peoetration Test
•

only worry is "checking a box" for compliance iii

16 7 1 ll.1ax1rn1z1ng
the value of a
Penetration Test

instead of really testing the security controls of a 16.7.1. Maximizing

the value of a
Penetration Test

web application . •
16.7.1. Maximizing
the value ot a
Penetration Test

• ::-.:::=--::-.: 16.8. Post-deployment:

Regular Scanning
1
~~~
elea rnSecu rity © 2013
 OUTLINE

Search ...

86 Securing Web Applications > Deployment: Penetration Testing

L=:l
t:::=J 16.6.3. Apphcallon
Harderunq

16.6.4. Further
Readmg
-

The most important goal of a penetration team

is to get security vulnerabilities fixed (i.e. not just
16. 7 1 Maxirnizmg

found), in order to ensure this happens it is the value ot a

Penetration Test

16 7 1 Max1m1Z1ng

important to have all findings from the •

W
the value of a
Peoetration Test

penetration test entered in the software defect 16.7 1 Maxirniz•ng

the vaiue of a
Penetration Test

tracking system. This can be done directly by the 16.7 1 Maxuniz ng

the value of a
Penetration Test

penetration testing team or using a point of 16 7.1. Max1rn1ZJng

the value of a
Penetration Test

contact. ~ ,..,,.,. House 1

• Penetration Testing
Team
elea rnSecu rity © 2013
16.'l.2.:J.!. Wtiy. §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

88 Securing Web Applications > Deployment: Penetration Testing > ln-House Penetration Testing Team

--- -~-
------
~------- 16.7 Deployment·
• ~=~::;::;~ Penetration Test ng

An in-hause penetration testing team may 16.7 1 Maxirniz ng

the vaiue of a
Penetration Test

additionally be more familiar with defect tracking

systems in the organization. This means they will
be able to report security findings as other
software defects, which should increase the 16.7 1 Max1m1ZJng

likelihood of fixing the issue.

..,. the vaiue ot a

• - Penetration Test

• 16.7.2.1. Why

~ ~=~· 16.7.2.2. Tool

1
elea rnSecu rity © 2013 :::.---·- Customization
16.'l.2.2. iTool Customization §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

89 Securing Web Applications > Deployment: Penetration Testing > ln-House Penetration Testing Team •
lt> I 1 Max1rn1l ng
the value of a
Penetration Test

16.7 1 Maxirniz ng
the value of a
Penetration Test

16 7 1 Max1m1Z1ng
the value of a
fZ!F „
The in-hause penetratian testing team should •
Penetration Test

16.7 1 Max1m1z ng

focus heavily an autamating as much as passible

the value ot a
Penetration Test

16. 7 1 MaxirniZJng

withautcampramising the quality of the testing. In the value öf a

Penetration Test

particular, penetratian testing tools and in-hause

ii
16.7 1 Max1m1Z1ng
..,. the vaiue ot a
Penetration Test

security testing scripts should be custamized ta

test web applicatians created by the arganizatian.
-- 16 7 2.2. Tool
• Custormzanon
•

elea rnSecu rity © 2013

16.'l.2.2. iTool Customization §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

90 Securing Web Applications > Deployment: Penetration Testing > ln-House Penetration Testing Team •
lt> I 1 Max1rn1lng
the value of a
Penetration Test

16.7 1 Maxirniz ng
the value of a
Penetration Test

16 7 1 Max1m1Z1ng
the value of a
fZ!F „
Generally speaking, tailored tools will work better •
Penetration Test

16.7 1 Max1m1z ng

than generic tools.

the value ot a
Penetration Test

16. 7 1 MaxirniZJng
the value öf a

This should be taking into account when Penetration Test

ii
16.7 1 Max1m1Z1ng

purchasing commercial solutions: Commercial ..,. the vaiue ot a

Penetration Test

tools that can be customized with in-hause plugins

should be favored over commercial tools that only
offer generic testing.

elea rnSecu rity © 2013

16.'l.2.3. Knowletige Sliar.ing_ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

91 Securing Web Applications > Deployment: Penetration Testing > ln-House Penetration Testing Team 10./ 1 MoXHTilL!llQ
the value öf a
Penetration Test

16.7 1 Max1m1ZJng
..,. the vaiue ot a
Penetration Test

An in-hause penetration testing team will have

very comprehensive knowledge about the output
from given departments or development teams in
the company. This should help to identify those ,..
•
1672.3.
Knowledge
Shanng

most in need for training.

B
16.7.2.3.
Knowledge
Sharing

~ ~~~;!ge
~ Sharing

16.7.3. Extemal
• Penetration Testing
Companies 1
=-= 16.7.4. Regular
1- . -::: 1 Penetration Testing
elea rnSecu rity © 2013
16.'l.2.3. Knowletige Sliar.ing_ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

92 Securing Web Applications > Deployment: Penetration Testing > ln-House Penetration Testing Team 10./ 1 MoXHTilL!llQ
the value öf a
Penetration Test

16.7 1 Max1m1ZJng
..,. the vaiue ot a
Penetration Test

The penetration testing team could tailor the

training to the types of issues found so that they
are prevented in the future.
16723.
Knowledge
Shanng
•

~ ~~~;!ge
~ Sharing

16.7.3. Extemal
• Penetration Testing
Companies 1
=-= 16.7.4. Regular
1- . -::: 1 Penetration Testing
elea rnSecu rity © 2013
16.'l.2.3. Knowletige Sliar.ing_ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

93 Securing Web Applications > Deployment: Penetration Testing > ln-House Penetration Testing Team 10./ 1 MoXHTilL!llQ
the value öf a
Penetration Test

16.7 1 Max1m1ZJng
Having in-hause development teams and security ..,. the vaiue ot a
Penetration Test

teams share information will ensure that:

B
16.72.3.
Security controls can be gradually Knowledge
implemented into internal development Development teams should offer Sharing

=
frameworks to ensure they are significantly assistance to security teams so that 16723
less likely to happen in new projects.
Custom scanning solutions can be code coverage is improved as much Knowledge
Shanng
implemented to find certain types of issues as possible in new projects. 16.7.3. Extemal
in source code before deployment, etc. • Penetration Testing
Companies 1
=-= 16.7.4. Regular
1- . -::: 1 Penetration Testing
elea rnSecu rity © 2013
 OUTLINE

Search ...

94 Securing Web Applications > Deployment: Penetration Testing · 1-§:"..=--.,_-:;;;.

··.::;·-.:_-~1 Penetration Test ng
Team

1- · _ :-:· 116.7.2.1 Why

• ~
i=:J 16.7.2.2. Tool
Custormzanon

Experienced external penetration testing

companies will provide fresh thinking into the
security process. This is very important because
B
16.7.23.
Knowledge
Sharing

they will approach the web application with a ~ ~~~!ge

~ Sharing

different mindset based on their experience ..,

16 7 3 External
Penetration T est1119
Cornpanies
testing multiple customers. •

l~_:I ·.,,,~, 1
16.7.3.1.Why
•
--
I ""::",;:- -116.7.3.1. Why

elea rnSecu rity © 2013

16.'l.3.1!. Wtiy. §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

95 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies • l~I Penetration Test ng
~Team

~ 16.7.2.1 Why

i=:J
The findings of an external testing company will
16.7.2.2. Tool
"' t==.j Custormzanon

help to improve:

I=- ·--1 ~~~e~ge

Sharing

1-- -==-1 ~~~!ge

Sharing

16.7.3. Extemal
...,. Penetration Test ng
- comoames

16.7.3.1. Why

16.7.3.1. Why

elea rnSecu rity © 2013

16.'l.3.1!. Wtiy. §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

96 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies · 1-§:"..=--.,_-:;;;.
·-.::;--.:_-~1 Penetration
Team
Test ng

1- · _ :-:· 116.7.2.1 Why

All findings that were missed by the in-hause • ~

i=:J 16.7.2.2.Tool
Custormzanon

penetration testing team but found by the

external company should be carefully analyzed
to ensure the in-hause penetration testing
B
16.7.23.
Knowledge

team is able to find those types of issues Sharing

~ ~~~!ge

moving forward. This keeps the in-hause ~ Sharing

penetration team motivated to continuously

improve and get the most out of external
penetration testing companies each time.
I ""::",;:- -116.7.3.1. Why

elea rnSecu rity © 2013

16.'l.3.1!. Wtiy. §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

97 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies 1-··-""-.;:·1167.2.1 Why

• ~
i=:J 16.7.2.2. Tool
Custcmizanon

16.7.2.2.
Tool
customc

In additian to this, an external penetratian

B
16.7.2.3.

testing campany will keep the in-hause Knowtedge

Sharing

penetratian testing team accauntable through ~

~
~~~~ge
Sharing

their findings (i.e. Was a serlous vulnerability

missed by the in-hause team but found by the I· , · 116.7.3.1 Why

external campany?).
•
•
--
16 7 3.1 Why

16.7.3.1. Why

~ 16.7.3.1.Why
~
elea rnSecu rity © 2013
16.'l.3.1!. Wtiy. §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

98 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
16.7.3.1 Why

•
~
~
--
16 7 3.1 Why

16.7.3.1 Why

The internal development team will also • 16.7.3.1. Why

benefit from the extra testing provided by the I · . ., _: -_ -] 16.7.3.1. Why

external company: Security issues found by 16.7.3.2.

Choosinga
Penetration T...

external companies should help in-hause

B
16.7.3.2.
Choosinga
Penetration T...
development teams to analyze the possibility 16.7.3.2.
Choosinga

of centralized security controls.

Penetration T...

16.7.3.2.
Choosinga
Penetration T...

16.7.3.2.
Choosinga
1
Penetration T...

16.7.3.2.
Choosinga
Penetration T...
elea rnSecu rity © 2013
 OUTLINE

•=
Search ...

100 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
16.7.3.1 Why

Choosing a penetration testing company is •

~
~
--
16 7 3.1 Why

16.7.3.1 Why

unfortunately not an easy process. There are many ~ 16.7.3.1 Why

companies that will simply run a to ~

I · . ., _: -_ -] 16 7.3.1 Why

ol and paste the results of the tool in their report. 16732.

Choosmg a
Penetration T ...
•

These companies will provide a significantly less

B
16.7.3.2.
Choosinga
Penetration T...

thorough security test than penetration testing 16.7.3.2.

Choosinga
Penetration T...
companies that involve expert security testers in 16.7.3.2.
Choosinga

manual testing. Penetration T ...

16.7.3.2.
Choosinga
1
Penetration T...

16.7.3.2.
Choosinga
Penetration T...
elea rnSecu rity © 2013
 OUTLINE

Search ...

101 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
16.7.3.1 Why

16 7 3.1 Why

16.7.3.1 Why

16.7.3.1 Why

16 7.3.1 Why

The following guidelines will help organizations 16.7.3.2

Choosmg a
Penetration T
choose competent penetration testing companies: 16732.
Choosmg a
Penetration T ...
•
16.7.3.2.
Choosing a
Penetration T...

16.7.3.2.
Choosing a
Penetration T...

16.7.3.2.
Choosing a
1
Penetration T...

16.7.3.2.
Choosing a
Penetration T...
elea rnSecu rity © 2013
 OUTLINE

•=
Search ...

102 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
16.7.3.1 Why

Discard penetration testing companies that refuse

•
~
~
--
16 7 3.1 Why

16.7.3.1 Why

access to source code ~ 16.7.3.1 Why

Any security company that does not ask for the source I · . ., _: -_ -] 16 7.3.1 Why

code of the application is likely to not have 16.7.3.2

Choosmg a
Penetration T
penetration testers with background on source code
B
16.7.3.2.

reviews. There are many security issues that will only

Choosinq a
Penetration T

be found through source code reviews therefore, if a 16732.

Choosing a
Penetration T...
•

penetration testing company is unable to review 16.7.3.2.

Choosinga

source code or does not ask for the source code, it 1

Penetration T ...

16.7.3.2.

should not be hired. Choosinga

Penetration T...

16.7.3.2.
Choosinga
Penetration T...
elea rnSecu rity © 2013
 OUTLINE

Search ...

103 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
16.7.3.1 Why

•
~
~
--
16 7 3.1 Why

16.7.3.1 Why

~ 16.7.3.1 Why

Discard penetration testing companies that refuse

I · . .,._: -_ -]
turning oft WAFsfor them
16 7.3.1 Why

16.7.3.2
Choosmg a

Any security company that suggests that testing Penetration T

B
16.7.3.2.
Choosinq a

with a WAF enabled will provide good code Penetration T

16.7 3.2

coverage has no idea about security testing and Choosmg a

Penetration T

167.32.

code coverage and should not be hired. •

Choosmg a
Penetration T ...

16.7.3.2.
Choosinga
Penetration T...

16.7.3.2.
Choosinga
Penetration T...
elea rnSecu rity © 2013
 OUTLINE

Search ...

104 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
16.7.3.1 Why

•
~
~
--
16 7 3.1 Why

16.7.3.1 Why

IMPORTANT: lt is ok to turn the WAF back on for ~ 16.7.3.1 Why

them, after vulnerabilities have been identified I · . .,._: -_ -] 16 7.3.1 Why

efficiently (i.e. to see if they can be exploited with 16.7.3.2

Choosmg a
Penetration T

the WAF enabled), but trying to identify

B
16.7.3.2.
Choosinq a

vulnerabilities with a WAF enabled is a waste of Penetration T

16.7 3.2
Choosmg a

man hours. Penetration T

16.7.3.2
Choosmg a
Penetration T

. 16732
Cnoosmq a
Penetration T...
•
16.7.3.2.
Choosinga
Penetration T...
elea rnSecu rity © 2013
 OUTLINE

Search ...

10s Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
1 _- :::-J 16.7 31 Why

1- ."" __ --116.7.3.1 Why

16 7 3.2
Choosmg a
Penetration T

Discard penetration testing companies that refuse

B
16.7.3.2.
Choosmg a

access to documentation and diagrams

Penetration T

16.7.3.2.
Choosmg a
Penetration T

Security companies that refuse access to 16 7.3.2.

Choosmg a

documentation, diagrams, design information, etc

Penetration T

16.7.3.2
Choosmg a

are typically only interested in pasting the results Penetration T

III
16732.

of an automated tool in their report, these

Choosmg a
Penetration T ...

16.7.3.2.

companies should not be hired for penetration Choosinga

Penetration T...

testing. 16.7.3.2.
Choosinga
1
Penetration T...

16.7.3.2.
Choosinga
Penetration T...
elea rnSecu rity © 2013
 OUTLINE

Search ...

106 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
1 _- :::-J 16.7 31 Why

1- ."" __ --116.7.3.1 Why

16 7 3.2
Choosmg a
Penetration T

Discard penetration testing companies that refuse B

16.7.3.2.
Choosmg a
Penetration T

post-assessment involvement 16.7.3.2.

Choosmg a
Penetration T

Great penetration testing companies actively offer

16 7.3.2.
Choosmg a
Penetration T

remediation advice after the penetration test. lf a 16.7.3.2

Choosmg a
Penetration T

penetration testing company is afraid of talking to 16.7.3.2.

Choosinq a
Penetration T

developers to provide sound remediation advice 16732.

Choosmg a
Penetration T ...

they should not be hired in the future. •

16.7.3.2.
Choosinga
1
Penetration T...

16.7.3.2.
Choosinga
Penetration T...
elea rnSecu rity © 2013
 OUTLINE

Search ...

107 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
1 _- :::-J 16.7 31 Why

1- ."" __ --116.7.3.1 Why

16 7 3.2
Choosmg a
Penetration T

Discard penetration testing companies that B

16.7.3.2.
Choosmg a
Penetration T

suggest to test in production systems 16.7.3.2.

Choosmg a
Penetration T

Testing a real production system should generally

16 7.3.2.
Choosmg a
Penetration T

be avoided to prevent potential downtime or other 16.7.3.2

Choosmg a
Penetration T

side-effects from testing. For this reason, a 16.7.3.2.

Choosinq a
Penetration T

penetration testing environment should be 16.7 3.2

Choosmg a
Penetration T

provided whenever possible.

16.7.3.2.
Choosinga
Penetration T...
elea rnSecu rity © 2013
 OUTLINE

Search ...

ios Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
16.7 3.2
Choosmg a
Penetration T

16.7.3.2
Choosmg a
Penetration T

16 7 3.2
Choosmg a
Penetration T

This environment should ideally be an exact replica 16.7.3.2.

Choosmg a
Penetration T

of the production environment in order to ensure 16.7.3.2.

Choosmg a
Penetration T

the findings are as relevant as possible to the 16 7.3.2.

Choosmg a

prod uction system.

Penetration T

11
16732.
Choosmg a
Penetration T ...

lf there is no replica available, penetration testing 16.7.3.2.

Choosinga

should happen outside of normal usage hours (if Penetration T...

16.7.3.2.
Choosinga

possible) and full backups should be in place. Penetration T...

16.7.3.2.
Choosinga
Penetration T...
1
,......~ 16.7.3.2.
elea rnSecu rity © 2013 =--==- Choosing a
Penetration T...
 OUTLINE

Search ...

109 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
16.7 3.2
Choosmg a
Penetration T

16.7.3.2
Choosmg a
Penetration T

16 7 3.2
Choosmg a
Penetration T

16.7.3.2.
Choosmg a
Penetration T

16.7.3.2.

This is not ideal but is sometimes the only option Choosmg a

Penetration T

available to test a system.

16 7.3.2.
Choosmg a
Penetration T

lf a penetration testing company tells does not ask

to test on a test server, they should not be hired.
16732.
Choosmg a
Penetration T ...
•
16.7.3.2.
Choosinga
Penetration T...

16.7.3.2.
Choosinga
Penetration T...
1
,..._-. =-'"'I 16.7.3.2.
elea rnSecu rity © 2013 =--==- Choosing a
Penetration T...
 OUTLINE

Search ...

110 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
16.7 3.2
Choosmg a
Penetration T

16.7.3.2
Choosmg a
Penetration T

16 7 3.2
Choosmg a
Penetration T

16.7.3.2.

Have several penetration testing companies test

Choosmg a
Penetration T

16.7.3.2.

the same application Choosmg a

Penetration T

16 7.3.2.

Hiring different penetration testing companies test

Choosmg a
Penetration T

the same application will provide great insight

about the skill and talent available in each
16.7.3.2.
Choosinq a
Penetration T

company. 16732.
Choosmg a
Penetration T ...
•
16.7.3.2.
Choosinga
Penetration T...
1
,..._-. =-'"'I 16.7.3.2.
elea rnSecu rity © 2013 =--==- Choosing a
Penetration T...
 OUTLINE

Search ...

111 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies
16.7 3.2
Choosmg a
Penetration T

16.7.3.2
Choosmg a
Penetration T

16 7 3.2
Choosmg a
Penetration T

16.7.3.2.
Choosmg a
Penetration T

For cost efficiency reasons, it may be best to test a 16.7.3.2.

Choosmg a
Penetration T

new release of the web application by the second 16 7.3.2.

Choosmg a
Penetration T

company and, verify if the issues found apply to

earlier releases or not (i.e. check if the issues were 16.7.3.2.
Choosinq a

missed by the first penetration testing company). Penetration T

16.7 3.2
Choosmg a
Penetration T

elea rnSecu rity © 2013

 OUTLINE

Search ...

112 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies

16.7.3.2.
Choosinq a
Penetration T

16.7 3.2
Choosmg a
Penetration T

16.7.3.2
Choosmg a
Penetration T

16732

This is by far the most efficient way to tell •

Cnoosmq a
Penetration T...

competent penetration testing companies away

16.7.3.2.
Choosinga
Penetration T...

from incompetent ones. 16.7.3.2.

Choosinga
Penetration T...

16.7.4. Regular
Penetration T esting

16.7.5. Further

.
Reading

--------
·- . -
-··---- 16.8. Post-deptoyment:
Regular Scanning
~~~
elea rnSecu rity © 2013
 OUTLINE

Search ...

113 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies

16.7.3.2.
Choosinq a
Penetration T

16.7 3.2
Choosmg a
Penetration T

Systematically rotate penetration testing 16.7.3.2

Choosmg a

compan1es
Penetration T
•
16 7 3.2
Choosmg a
Penetration T

Even when a penetration testing company has ~ 167.32 .

Choosmga
Penetration T ...

been proven to be very valuable, it is important to •

16.7.3.2.
Choosinga

always use more than one company for external Penetration T...

r:::.:J 16.7.4. Regular

penetration testing purposes. ~ Penetration Testing

16.7.5.
. Further
Rea d1ng

•
::-.:::=--::-.:
_ ·- -see-
16.8. Post-deptoyment:
Regular Scanning
1
elea rnSecu rity © 2013 -:::::- --=- ~
 OUTLINE

Search ...

114 Securing Web Applications > Deployment: Penetration Testing > External Penetration Testing Companies

16.7.3.2.
Choosinq a
Penetration T

16.7 3.2
Choosmg a
Penetration T

16.7.3.2

Penetration testing companies should be aware of

Choosmg a
Penetration T

16 7 3.2

this in order to be motivated to out-perform Choosmg a

Penetration T

competitors . This benefits the organization hiring

16.7.3.2.
Choosmg a
Penetration T

external penetration testing companies to get the 16732.

Choosu19 a
Penetration T ...
•

most out of each penetration test. r:::.:116.7.4. Regular

~ Penetration Testing

16.7.5.. Further
Rea d1ng

•
::-.:::=--::-.:
_ ·- -see-
16.8. Post-deptoyment:
Regular Scanning
1
elea rnSecu rity © 2013 -:::::- --=- ~
 OUTLINE

Search ...

11s Securing Web Applications > Deployment: Penetration Testing

16.7.3.2.
Choosinq a
Penetration T

Whether performed by an in-hause team or an 16.7 3.2

Choosmg a
Penetration T

external company, penetration testing should be 16.7.3.2

Choosmg a

performed in a continuous fashion (i.e. not just Penetration T

16 7 3.2

after the first deployment), having a penetration

Choosmg a
Penetration T

16.7.3.2.

testing done on a website every year should be Choosmg a

Penetration T

considered a minimum for most ecommerce

16.7.3.2.
Choosmg a
Penetration T

~
applications. •
16 7 4. Regular
Penetration Testmq

16.7.5.. Further
Rea d1ng

•
::-.:::=--::-.:
_ ·- -see-
16.8. Post-deptoyment:
Regular Scanning
1
elea rnSecu rity © 2013 -:::::- --=- ~
 OUTLINE

Search ...

116 Securing Web Applications > Deployment: Penetration Testing

More information about this topic can be found

16.7.3.2.

in the following online resources: Choosinq a

Penetration T

16.7 3.2
Choosmg a
Penetration T

16.7.3.2
Choosmg a
BSIMM study Penetration T

Deployment: Penetration 16 7 3.2

Choosmg a
Testing (PT) Penetration T

16.7.3.2.
Choosmg a
Penetration T
OWASP OpenSAMM - OWASP OpenSAMM - 16.7.3.2.

Software Assurance Software Assurance Choosmg a

Penetration T

Maturity Model (1) Maturity Model{2) r:::.:J 16 7.4 Regular

~ Penetration Test ng

16 7 5. Further

.
Readmg
•

--------
·- . -
-··---- 16.8. Post-deptoyment:
Regular Scanning
1
~~~
elea rnSecu rity © 2013 '-------'
16.8. ~ost-aeP-lov.ment:Regular.Scannin~ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

117 Securing Web Applications

Once the web application has been deployed and

16.7.3.2.
Choosinq a
Penetration T

all identified security issues addressed, the next 16.7 3.2

Choosmg a
Penetration T

step is to implement/enforce: 16.7.3.2

Choosmg a
Penetration T

16 7 3.2
Choosmg a
Penetration T

16.7.3.2.
Choosmg a
Penetration T

~ A regular scanning 16.7.3.2.

A configu ration A vulnerability ' Choosmg a

program that
Penetration T
1

~
management ~
management r:::.:J
r ~ validates/enforces ~
16 7.4 Regular
Penetration Test ng
program program
1-2
...
16 8 Post-deployment:
Regular Scannrng
elea rnSecu rity © 2013
16.8. ~ost-aeP-lov.ment: Regular. Scannin~ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

118 Securing Web Applications

16.7.3.2
Choosmg a
Penetration T

16.7.3.2.
Choosinq a
Penetration T

16.7 3.2
Choosmg a

The main benefit of a regular scanning program is

Penetration T

r=;:'l 16 7.4 Regular

that it is more cost-effective than testing security

~ Penetration Test ng

for every minor change made to a web application.

::::::::::c--:-.:
In other words, a regular scanning program may "" _ ·- ·=-"="'
-=- -=- -::-\
16 8. Post-deploymenl
Regular Scannmg

help identify issues introduced during 168.Post-

deployment Regular
Scanninq

maintenance in a more cost-effective fashion.

•

16.8.1. Configuralion
Management
Program

elea rnSecu rity © 2013 1

16.8.l!. Configuration Management P.rogram §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

119 Securing Web Applications > Post-deployment: Regular Scanning

16.7.3.2
Choosmg a
Penetration T

16.7.3.2.
Choosinq a
Penetration T

16.7 3.2
Choosmg a
Penetration T

All configuration changes on the web application r=;:'l

~
16 7.4 Regular
Penetration Test ng

and its hosting infrastructure should go through a

configuration management program where each ::::::::::c--:-.: 16 8. Post-deploymenl
"" _ ·- ·=-"="' Regular Scannmg
configuration change is at least recorded and -=- -=- -::-\
16 8. Post-

requires approval by another member of staff. deployment: Regular

Scanntng

16 8 1 Configurat1on
tv1anagement
Program
•

elea rnSecu rity © 2013 1

16.8.2. X/ulneral5ilit~ Management ana Regular,Scannin~ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

120 Securing Web Applications > Post-deployment: Regular Scanning

16.7.3.2
Choosmg a
Penetration T

16.7.3.2.
Choosinq a
Penetration T

All web applications should be regularly scanned.

16.7 3.2
Choosmg a
Penetration T

This automated process should be combined with r=;:'l

~
16 7.4 Regular
Penetration Test ng

regularly scheduled manual testing of the web

application. This will provide some degree of ::::::::::c--:-.: 16 8. Post-deploymenl
"" _ ·- ·=-"="' Regular Scannmg
assurance that the security posture of the web -=- -=- -::-\
16 8. Post-

application is not being compromised through deployment: Regular

Scanntng

code changes overtime.

16.8.1 Configurat1on
Management
Program

1111
16 8.2. Vulnerabuity
...,. f\1anagement and
Regular Scanninq

16.8.2. Vulnerability
Management and
1
Regular Scanning
elea rnSecu rity © 2013
16.8.2. X/ulneral5ilit~ Management ana Regular,Scannin~ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

121 Securing Web Applications > Post-deployment: Regular Scanning

16.7.3.2
Choosmg a
Penetration T

r='l
~
16.7.4 Regular
Penetration Test ng

All identified vulnerabilities should be logged in a

vulnerability management database where they •
:::.::::::=:--::-.:
·- ·- ·=..-=-
16.8 Post-deployment
Regular Scanrunq

are prioritized, sent off as defects to be fixed by

-;::.- -::=- -r."""'L

16.8 Post-
deployment: Regular

developers, etc. Scanning

16 8 1 Confiqurauon
Management

There are some freely available tools that may help Program

automate parts of a vulnerability management

program. •
16 8 2 Vulnerab1hty
Management and
Regular Scann1ng

16.8.2. Vulnerability
Management and
Regular Scanning

16.8.3. Further

elea rnSecu rity © 2013 •

Reading
1
16.8.2. X/ulneral5ilit~ Management ana Regular,Scannin~ §]
REF
,~i, f.
LABS VIDEO
OUTLINE

Search ...

122 Securing Web Applications > Post-deployment: Regular Scanning

16.7.3.2
Choosmg a
Penetration T

For example: r='l

~
16.7.4 Regular
Penetration Test ng

lrhread-fix allows to manage https:Ucode.google.com/p/threadfix/

vulnerabilities and can be an :::.::::::=:--::-.: 16.8 Post-deployment
effective tool for regular • ·-
-;::.-
·- ·=..-=-
-::=- -r."""'L
Regular Scanrunq

vulnerability scanning too: 16.8 Post-

deployment: Regular
Scanning
Mozilla Minion also facilitates https:Ugithub.com/mozilla/minion
regular application scanning and 16 8 1 Confiqurauon
Minion overview slides: Management
Program
vulnerability management:
http:Upeople.mozllla.com/=vbolly/appsec-eu-2013

IAnother option for regular https:Ugithub.com/golismero/golismero 16.8.2. Vulnera.b hty

Management and
scanning can be Golismero: Regular Scanning

16 8 2 Vulnerabuity
tv1anagement and
Regular Scanoinq
•

elea rnSecu rity © 2013 1

 OUTLINE

Search ...

123 Securing Web Applications > Post-deployment: Regular Scanning

16.7.3.2
Choosmg a
Penetration T

More information about this topic can be found r='l 16.7.4 Regular
~ Penetration Test ng

in the following online resources:

:::.::::::=:--::-.: 16.8 Post-deployment

• ·- ·- ·=..-=- Regular Scanrunq
-;::.- -::=- -r."""'L

BSIMM study - Deployment: 16.8 Post-

~ Do You Have a Scanner or Do deployment: Regular
Configuration Management Scanning
You Have a Scanning Program?
and Vulnerability
(AppSecEU 2013) 16 8 1 Confiqurauon
Management (CMVM) Management
Program

OWASP OpenSAMM - OWASP OpenSAMM -

16.8.2. Vulnera.b hty
Software Assurance Maturity Software Assurance Maturity Management and
Regular Scanning
Model (1) Model (2)
16.8.2 Vulnera.b hty
Management and
Regular Scanning

. 16 8 3 Further
Reading
r
[
elea rnSecu rity © 2013 •