Points of View. CxO s point of view. Developer s point of view. Attacker s point of view

Points
of
View


•  _{CxO’s
point
of
view} – Measurable
security
 – SCAP
(Security
Content
Automation
Protocol)
 •  _{Developer’s
point
of
view} – Secure
coding/Software
security
 – CWE
(Common
Weakness
Enumeration)
 •  _{Attacker’s
point
of
view} – Find
vulnerabilities
 – CAPEC
(Common
Attack
Patterns
Enumeration
and
Classification)


What
A
Developer
Needs…


•  A
starting
point
for
secure
coding
 –  A
stepping
stone
to
build
knowledge
 •  A
didactic
tool
 –  Iterative
learning
 •  Top
X
lists
 –  Implementation
insecurity
 –  Design,
installation,
etc.,
insecurity
 •  Facilitators
 –  An
API
that
embodies
secure
coding
 •  Put
knowledge
into
practice
 –  Secure
Design
Patterns
 •  Reuse
of
knowledge
and
experience


Seven
Pernicious
Kingdoms
(7PK)


•  Taxonomy
 – Common
vocabulary
 – Understand
how
failure
occurs
 •  Goal
of
7PK
 – Educate
developers
about
software
errors
with
 security
impact


7PK
Properties


•  Each
item
fits
into
one
category
 •  Not
intended
to
be
comprehensive
 •  Focus
on
real
issues
 •  Categorization
expected
to
change
 •  Detectable
by
static
analysis
tools
 •  Feedback
to
educate
developers
 •  Code‐level
security
for
software
applications
(not
OS)
 •  Phyla
(Vuln
classes)
and
Kingdom
(Vuln
classes
that
share
 same
theme)
 –  Buffer
Overflow
and
Input
Validation
 •  May
be
language
(C),
framework
(Struts)
specific


7PK


1.  Input
Validation
and
Representation
 2.  API
Abuse
 3.  Security
Features
 4.  Time
and
State
 5.  Errors
 6.  Code
Quality
 7.  Encapsulation
 •  _Environment

7PK
Online


Developer
Learning
Cycle


Code

Check Rectify and Learn

Why
7PK


•  _{A
good
place
to
start} •  Practical
‐‐‐
focus
on
real
issues
 •  A
learning
tool
 •  _{Part
of
OWASP/well
understood/common} language
 •  _{BUT
feel
free
to
use
others…}

What
About
Other
Insecurity?


7
 Kingdoms
 Statically Analyzable Insecurity Not Statically Analyzable Insecurity Critical Insecurity Design, installation Issues etc.

Pareto
Security


•  _{OWASP
Top
10} – Web
application
focus
 – Can
be
mapped
on
to
7PK
 •  _{CWE/SANS
Top
25} – Broader
focus


Quote
from
CWE/SANS
Top
25
FAQ


•  _{Does
not
prioritize
bugs} •  Addresses
only
bugs
during
implementation/ statically
analyzable
 •  _{Does
not
address
security
issues
in
design,} configuration,
installation,
and
other
SDLC
 phases


Landwehr
et
al./Viega


•  _{http://cwe.mitre.org/data/graphs/699.html}

Where

How

Landwehr
et
al./Viega
(cont.)


•  _Pros – Easy
to
determine
strategy
 •  If
most
issues
occur
because
insecurity
was
introduced
 in
design
phase,
then
probably
need
more
resources,
 e.g.,
security
architects
 – Easy
to
determine
when
to
look
for
what
 •  Depending
on
current
activity,
look
out
for
related
 weakness
 •  _Cons – Difficult
to
categorize
issues
 •  If
it
is
not
known
how
the
vulnerability
entered
the
 system,
it
is
difficult
to
categorize


Secure
Design
Patterns


•  _{Not
focused
on
the
implementation
of
specific} security
mechanisms
 •  _{Focus
on
elimination
of
accidental
insertion
of} vulnerabilities
into
code
or
to
mitigate
the
 consequences
of
vulnerabilities
 •  Generalize
existing
best
security
design
 practices

 •  Extend
existing
design
patterns
with
security‐ specific
functionality


Pattern
Definition


•  _{A
pattern
is
a
general
reusable
solution
to
a} commonly
occurring
problem
in
design
 •  _{A
description
or
template
for
how
to
solve
a} problem
that
can
be
used
in
many
different
 situations
 •  An
algorithm
is
not
a
pattern


Secure
Design
Patterns


•  _{Architectural} •  Design


Architectural‐level
Pattern


•  _{Underline
responsibilities
between
different} components
of
the
system
 •  _{Define
the
interaction
between
those
high‐} level
components
 •  _Example – Distrustful
Decomposition
 – PrivSep
(Privilege
Separation)
 – Defer
to
Kernel


Application
Design


•  _{Application
has
many
users} •  Each
user
may
be
assigned
into
different
 groups
 •  _{Each
user
needs
to
authenticate
to
the} application
before
performing
tasks


A very common requirement How do you go about this?

Design
Sketch


Application
 with
Access
 Control
 DB
 User Table Read/Write Access Internet
 LAN
 Admin Login

Privilege
Separation
(PrevSep)


•  _Intent – Reduce
the
amount
of
code
that
runs
with
special
 privilege
to
reduce
impact
of
successful
attack
 •  Motivation
 – Small
set
of
simple
operations
(easy
to
verify)
 require
elevated
privileges
 – Larger
set
of
complex
and
security
error‐prone
 operations
run
in
unprivileged
mode


PrevSep
(cont.)


•  _{Applicability} – Functions
that
do
not
require
elevated
privileges
 – Have
relatively
large
attack
surfaces
in
that
the
 functions
 •  Significant
communication
with
untrusted
sources
 •  Complex,
potentially
error‐prone
algorithms


Issues
with
Design
Sketch


Application
 with
Access
 Control
 DB
 User Table Read/Write Access Internet
 LAN
 Admin

Login does not require Write

Complex

algorithm, i.e., login, admin, etc.

Application
 with
Access
 Control
 Read/Write Access

PrevSep
Application


DB
 User Table Internet
 LAN
 Admin Admin
 Module
 Read/Write Access Read/Write Access Login

Defer
To
Kernel


•  _Intent – Separate
functionality
that
requires
elevated
 privileges
from
those
that
do
not
 – Take
advantage
of
existing
user
verification
 functionality
available
at
the
kernel
level
 •  Motivation
 – Reuse
of
user
verification
functionality
provided
 by
the
OS
kernel
 •  Don’t
roll
own
security
code
 •  Already
validated
code
 •  Portability


Application
 with
Access
 Control


Defer
To
Kernel


DB
 User Table Internet
 LAN
 Admin Admin
 Module
 Read/Write Access Read/Write Access Login /etc/passwd
 OS
 Kernel
 Login
 Module


Design‐level
Pattern


•  Address
problems
in
the
internal
design
of
a
 single
high‐level
component
 •  Not
the
definition
and
interaction
of
high‐level
 components
themselves
 •  Example
 –  Secure
Factory
 –  Secure
Strategy
Factory
 –  Secure
Builder
Factory
 –  Secure
Chain
of
Responsibility
 –  Secure
State
Machine
 –  Secure
Visitor


Builder
Factory


RTFReader ParseRTF() TextConverter ConvertChar() ConvertFont() ConvertPara() GetOutput() ASCIIConverter ConvertChar() GetOutput() HTMLConverter ConvertChar() ConvertFont() ConvertPara() GetOutput() if choice == “HTML” {

builder = new HTMLConverter } else {

builder = new ASCIIConverter }

while (t = get next token) { switch(t.Type) { CHAR: builder->ConvertChar() FONT: builder->ConvertFont() PARA: builder->ConvertPara() } } Abstract Builder Concrete Builders

Builder
Factory


•  _Intent – Separate
the
construction
of
complex
object
from
 representations
 – The
same
construction
process
can
create
 different
representations


Secure
Builder
Factory


•  _Intent – Separate
security
dependent
rules
involved
in
 creating
a
complex
object
from
the
basic
steps
 involved
in
actually
creating
the
object
 •  Process
 – A
caller
for
Secure
Builder
Factory
pattern
based
 on
a
specific
set
of
security
credentials
 – Pattern
implementation
uses
the
given
security
 credentials
to
select
and
return
the
appropriate
 object
implementing
the
Builder
pattern
 – The
builder
object
builts
the
complex
object


Secure
Builder
Factory


DisplayData DisplayData (credentials, ID) PDMS SetName() GetJob() GetSSN() GetSQLResult() TrustedPDMS SetName() GetJob() GetSSN() GetSQLResult() UntrustedPDMS SetName() GetJob() GetSSN() => nil GetSQLResult() if credentials == “admin” { builder = new TrustedPDMS } else {

builder = new UntrustedPDMS } builder->setName(ID) data = builder->getSQLResult() show(data) Abstract Builder Concrete Builders NOTE: PDMS is persistent data management system

Implementation‐level
Pattern


•  Implementation
of
specific
functions
 •  Address
the
same
problem
set
addressed
by
the
 CERT
Secure
Coding
Standards

 •  Often
linked
to
a
corresponding
secure
coding
 guideline
 •  Example
 –  Secure
Logger
 –  Clear
Sensitive
Information
 –  Secure
Directory
 –  Pathname
Canonicalization
 –  Input
Validation
 –  Resource
Acquisition
Is
Initialization


Enterprise
Security
API
(ESAPI)


•  _{Enables
developer
to
focus
on
functional
goals} •  Discourages
developer
to
roll
their
own
 security
mechanisms
 •  _{Facade,
Bridge
pattern} – No
lock‐in
and
modular
ala
JCE


ESAPI
in
A
Picture


Architecture
Overview


38
 Custom
Enterprise
Web
Application
 Enterprise
Security
API
 Authen tic at or
 User
 AccessCon tr oller 
 AccessR ef er enceMap 
 Valida tor 
 Enc oder
 HT TPUtilities 
 Encr yp tor 
 Encr yp tedPr operties 
 Randomiz er
 Ex cep tion
Handling
 Log ger
 In trusionDe tect or 
 SecurityCon figur ation 
 Existing
Enterprise
Security
Services/Libraries


Coverage


OWASP
Top
Ten
 A1.
Cross
Site
Scripting
(XSS)

 A2.
Injection
Flaws

 A3.
Malicious
File
Execution

 A4.
Insecure
Direct
Object
Reference

 A5.
Cross
Site
Request
Forgery
(CSRF)
 A6.
Leakage
and
Improper
Error
Handling

 A7.
Broken
Authentication
and
Sessions
 A8.
Insecure
Cryptographic
Storage

 A9.
Insecure
Communications
 A10.

Failure
to
Restrict
URL
Access

 OWASP
ESAPI
 Validator,
Encoder
 Encoder
 HTTPUtilities
(upload)
 AccessReferenceMap
 User
(csrftoken)
 EnterpriseSecurityException,
HTTPUtils
 Authenticator,
User,
HTTPUtils
 Encryptor
 HTTPUtilities
(secure
cookie,
channel)
 AccessController


Backend


Handling
Authentication
and
Identity


Controller
 Business
 Functions
 User
 _Data
Layer ESAPI
 Access
 Con tr ol
 Log ging 
 In trusion
 De tection 
 Authen tic ation 
 Users


Cross‐Site
Request
Forgery


41


bank.com

attacker’s post at blog.net

Go to Transfer Assets

https://bank.com/fn?param=1 Submit Transaction

https://bank.com/fn?param=1

Adopted from Eric Sheridan (Aspect Security Inc.) OWASP