A journey into application security will cover the relation and evolution of application security with the different approaches to development from Waterfall to Devops.

1. A
Journey
into
Application
Security
Christian
Martorella
ISACA
Italy
2014
Venezia,
3rd October

2. Who
am
I
• Principal
Program
Manager,
Product
Security
Skype
– Microsoft
• Edge-­‐Security:
Wfuzz,
theHarvester,
Metagoofil,
Webslayer
• Presented
in
many
Security
conferences:
Hack.lu,
BlackhatArsenal,
Source,
OWASP
Summit,
OSIRA
• CIS(A,M,SP),
OPS(T,A)

3. My
background
• Started
as
internal
security
auditor
(Offensive)
• System
and
network
security
responsible
of
a
small
ISP
(Defensive)
• Penetration
tester
-­‐>
Team
leader
(Offensive)
• Practice
lead
for
Threat
and
Vulnerability
in
EMEA
(Offensive)
• Product
Security
Analyst
in
Skype
(Defensive)

4. Introduction
This presentation is about the evolution of software development and
the relation with Applicationsecurity.
How application security teams adapted over time and the challenges
we are facing

6. Waterfall
development

7. Waterfall
development
• Originated
from
the
manufacturing
and
construction
industries.
• Hardware
oriented
model
adapted
to
Software
development
• Sequential
design
process
• Introduced
by
Winston
Royce
in
the
’70

8. Waterfall
development
• Make
sure
each
phase
is
100%
complete
and
absolutely
correct
before
proceeding
to
the
next
phase
• Emphasis
on
documentation
• Project
span
across
long
period
of
time
• Time
spent
early on
making
sure
requirements and
design are
correct
saves
much
time
and
effort
later.

9. Application
Security
Microsoft
Secure
Development
Lifecycle
(SDL)
Set
of
software
development
process
improvements
Born
in
2002
and
established
in
2004,
as
result
of
MS
Trustworthy
Computer
(TWC)
initiative.
More
than
50%
less
vulnerabilities
in
shipped
code

10. SDL
Methodologies

11. SDL
evolution

12. Security
approach
Influence
in
the
Design
phase:
• All
functional
and
design
specifications,
regardless
of
document
size,
should
contain
a
section
describing
how
the
component
impacts
security
• Threat
Modeling:
Understand
assets
to
protect,
threats
and
vulnerabilities
to
the
product
and
how
will
be
mitigated.
Critical
to
create
a
secure
software
Most
important
phase
in
Waterfall

13. Security
approach
Development
phase:
Implement
security
tools:
• Static
analysis,
Banned
Apis,
FxCop,
/Analyze
Implement
security
checklist
Secure
coding
best
practices
Verification
/
Release
phase:
Fuzzing
Verify
/
validate
Threat
Model
Final
security
review
(FSR)
Security
testing
by
another
team
or
third
party

14. Challenges
• Lack
of
security
requirementsin
design
phase
will
make
it
difficult
to
add
them
in
later
stages
• Non
iterative
nature
makes
difficult
to
fix
issues
identified
in
advanced
stages
of
development
• Issues
detected
in
the
Final
review,
will
be
expensive
to
fix

15. Agile
development

16. Agile
development
• Cross
functional
teams,
self
organizing
• Short
time
boxed
development
iterations
• Delivery
of
small
functional
stories
• Listen
to
customer
needs
and
adapt
• Usually
low
in
documentation

17. Agile
Manifesto
Individuals
and
interactionsover
processes
and
tools
Working
software
over
comprehensive
documentation
Customer
collaboration
over
contract
negotiation
Responding
to
change
over
following
a
plan
That
is,
while
there
is
value
in
the
items
on
the
right,
we
value
the
items
on
the
left
more.

20. Challenges
• SDL
too
complex
to
fit
in
each
release/Sprint
• Design,
requirements
evolve
over
time
• New
interactions
with
third
parties
are
not
known
in
advance
• Teams
usually
don’t
have
an
Application
Security
specialist
• Teams
move
faster
than
Waterfall
• New
code
is
being
pushed
to
production
every
week
or
even
days.
• Low
on
documentation

21. SDL
for
Agile

22. SDL
for
Agile
The
categorization
of
SDL
requirements
into:
• every-­‐sprint
• one-­‐time
• Three
bucket
groups
(Verification,
design,
Response)
is
the
SDL-­‐Agile
solution
for
dealing
with
SDL
in
Agile
environments

23. Recommendations
• Training
the
teams
and
providing
them
with
tools
is
the
most
important
aspect
in
order
to
implement
SDL
in
Agile
teams
• Security
specialist
assigned
to
a
few
teams,
to
provide
consultancy
• Useful
to
participate
in
Sprint
planning
to
understand
what
is
going
on
• Sprint
Security
Checklist
(FSR),
after
Sprint
planning
• Get
familiar
with
Agile
tools,
backlog.

24. SDL
for
Agile
• Continuous
Integration
(Automation):
Secure
Code
analysis
Security
unit
test
Vulnerability
scanning
Secure
configuration

25. Happiness

26. Cloud
fotos

27. Cloud
• “We
want
to
start
using
Cloud
services”

28. Challenges
• Security
of
the
data
• Security
of
the
servers
• Who
is
responsible
for
the
servers
• Where
is
the
data
located
• Encryption
at
rest
• Disks
reutilization

29. Security
Approach
• New
Security
policy
for
Cloud
services
• Security
Onboarding
for
teams
• Inventory
of
cloud
services

31. DEVOPS

32. Why
Devops?
• Continuous
software
delivery
• Faster
delivery
of
features
• Faster
resolution
of
problems
• Less
complex
problems
to
fix
More
Deploys
Means
Faster
Time
to
Market
and
Continual
Improvement

34. Challenges
• Rapid
releases
cycles
(every
day,
multiple
times
a
day)
• Autonomous
teams
• Teams
are
doing
development
and
operations
now
• Infrastructure
also
changes
fast

35. Development
cycles
Waterfall
Agile
Devops

38. Surviving
Devops
• Providing
security
training
to
teams
• Provide
security
policies,
guidelines
• Security
and
abuse
stories,
driven
by
business
• Situational
awareness:
• What
do
we
have?
• Changes,
alerts.
• Attack
surface,
priorities

39. Surviving
Devops
• Automation:
• Integrate
testing
into
continuous
integration
and
release
process
(Chef
&
Puppet)
• Integrate
and
extend
production
configuration
monitoring
• Develop
your
own
security
testing
tools,
more
focused
and
adapted
to
your
particular
needs

40. Surviving
Devops
Situational
awareness
&
Automation
example:
-­‐Source
code
Product
attack
surface
analyzer,
alerts,
prioritization
of
efforts.
-­‐Internet
footprint,
scanning
and
inventory.
Updated
every
hour.

41. Surviving
Devops
• Integrate
InfoSec
and
IR
into
the
Ops/Devs escalation
process
• Harden
the
production
environment
• Provide
guidelines/baselines
on
what
is
a
hardened
environment
• Automate
hardening
(Chef/Puppet)
• Tolerate
failure
in
production
environments
(Chaos
Monkey)

42. Surviving
Devops
• Metrics:
• Identify
if
teams
are
repeating
certain
type
of
vulnerabilities,
train
them
to
prevent
repeating
again.
• Prioritize
training
• Modify
policies
and
baselines
• Tune
tools
• Interact
more
closely
with
teams,
attend
to
standups
• Be
more
flexible
and
adapt
to
team
processes
• mesh
with
the
unique
development
cultures
of
individual
teams

43. The
Future?
Rugged
software
“Rugged”
describes
software
development
organizations
which
have
a
culture
of
rapidly
evolving
their
ability
to
create
available,
survivable,
defensible,
secure,
and
resilient
software
Rugged
is
NOT
a
technology,
process
model,
SDLC,
or
organizational
structure.
It’s
not
even
a
noun.

44. Rugged
software
Rugged
describes
staying
ahead
of
the
threat
over
time
“We
are
convinced
that
negative
and
reactive
approaches
to
application
security
cannot
scale
and
are
doomed
to
fail.
These
approaches
primarily
rely
on
finding
vulnerabilities
and
fixing
them.”

45. Rugged
Manifesto
I
am
rugged
and,
more
importantly,
my
code
is
rugged.
I
recognize
that
software
has
become
a
foundation
of
our
modern
world.
I
recognize
the
awesome
responsibility
that
comes
with
this
foundational
role.
I
recognize
that
my
code
will
be
used
in
ways
I
cannot
anticipate,
in
ways
it
was
not
designed,
and
for
longer
than
it
was
ever
intended.
I
recognize
that
my
code
will
be
attacked
by
talented
and
persistent
adversaries
who
threaten
our
physical,
economic
and
national
security.
I
recognize
these
things
– and
I
choose
to
be
rugged.
I
am
rugged
because
I
refuse
to
be
a
source
of
vulnerability
or
weakness.
I
am
rugged
because
I
assure
my
code
will
support
its
mission.
I
am
rugged
because
my
code
can
face
these
challenges
and
persist
in
spite
of
them.
I
am
rugged,
not
because
it
is
easy,
but
because
it
is
necessary
and
I
am
up
for
the
challenge.

46. Conclusion
• Development
methodologies
and
processes
changed
considerably
over
time
• More
things
happening
in
shorter
period
of
time
• Security
tools
and
techniques
needs
to
adapt
to
this
situation
• Automation
is
key
in
Devops environment
• Security
professionals
need
to
be
flexible
and
engage
more
than
ever
with
development
teams

47. ?

48. Thank
you
cmartorella@edge-­‐security.com

49. Resources
• Microsoft
SDL
-­‐ http://www.microsoft.com/security/sdl/default.aspx
• Rugged
Software
-­‐ https://www.ruggedsoftware.org/
• http://labs.securitycompass.com/appsec-­‐2/the-­‐cultural-­‐challenges-­‐of-­‐
application-­‐security/
• http://devops.com/features/the-­‐unexpected-­‐benefits-­‐of-­‐devops/
• http://newrelic.com/devops/benefits-­‐of-­‐devops