application security : going quicker - isaca excellium.pdfapplication security : going quicker ......

Post on 29-Mar-2018

233 Views

Category:

Documents

5 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Application security : going quicker

The web application firewall example

Agenda

Agenda

o Intro

o Application security

o The dev team approach

o The infra team approach

o Impact of the agility

o The WAF

Intro Context

• Who am I ?

• A web application firewall friend

• A pentester

• A developer

• Responsible of the appsec and pentest dpt at Excellium

From the Verizon DataBreach report

Intro Context

Intro Context

While the malwares are more

related to the users…….

… the hacking side is more

related to the servers

Intro Context : all begin here

Historical approach : the magic box theory (WAF)

Intro Context

• Managed by the infrastructure

• Not understanding HTTP

• Positive and negative security models

• Block 100% of the attacks (as the vendor said)

• Block more than 100% of the attacks in reallity

Team : Infra

Intro Context

• Quality oriented

• Limited by the reviewer knowledge

• Slow

Historical approach : peer programming

Team : Dev

Intro Context

Y

• Microsoft : up to 100 k€ / bug

• Google : up to 100 k€ / bug

• Facebook up to 15 k€ / bug

• Performed by security experts

• Only the visible surface

• No knowledge of the enterprise strengths/weaknesses

• How can the attacker be trusted or not ?

Bug bounty programs

Team : Red team

Intro Context

Historical approach : SDLC enhancement

Team : Risk and Compliance

Application Security costs

Intro Context : all begin here

Intro Context : the beginning

• Infrastructure team

• Production team

• Development team

• System team

• Testing team

• Architecture team

• GRC team

• Middleware team

• Business team

Intro Context : the beginning

• Infrastructure team

• Production team

• Development team

• System team

• Testing team

• Architecture team

• GRC team

• Middleware team

• Business team

Intro Context : the beginning

• Infrastructure team

• Production team

• Development team

• System team

• Testing team

• Architecture team

• GRC team

• Middleware team

• Business team

Agenda

o Intro

o Application security

o The dev team approach

o The infra team approach

o Impact of the agility

o The WAF

How to protect : the enterprise view

• How to assess the security if the application

changes continuously ?

• How to stay in the budget ?

• How to protect an application we don’t know ?

How to protect : the enterprise view

Infra

WAF

Rewriting engine

Signatures

Whitelist

Virtual patching

Code quality

Injections

Insecure crypto issue

Libraries analysis

Dynamic langagues

Dynamic frameworks

Vulnerability scanner

Bad configuration checks

Infrastructure checks

Generic vulnerabilities

SAST DAST

Network and security devices Application components

Web/Application servers

Application containers

Frameworks and libraries

Middlewares

Database

Business logic

Custom code

Communication channel

ob

fusc

ati

on

level

How to protect : the enterprise view

Agenda

o Intro

o Application security

o The dev team approach

o The infra team approach

o Impact of the agility

o The WAF

How to protect : the dev view

Code quality

Injections

Insecure crypto issue

Libraries analysis

Dynamic langagues

Dynamic frameworks

SAST

Frameworks

Can the security tools automate the tests for each kind of stacks ?

Knowing the frameworks are hidding the vulnerabilities (GWT…. )

How to protect : the dev view

How to protect : the dev view

How to protect : the dev view

Pro Cons

Automated Not fully security oriented

Ran for each change Doesn’t test the environment

Quick But slow if manual

Knowledge of the frameworks Not controlled by the security teams

Integrated with the repository

Agenda

o Intro

o Application security

o The dev team approach

o The infra team approach

o Impact of the agility

o The WAF

How to protect : the infra view

Infra

WAF

Rewriting engine

Signatures

Whitelist

Virtual patching

How to protect : the infra view

Web Attack types (from OWASP)

Client side Session side Server side Programming

language side

Application

side

Data

side

XSS

Reflective

Persistant

DOM based

CSIT

Flash

Applets

(HTML5 Web

Sockets)

Clickjacking

Cookie fixation

Cookie stealing

Cookie guessing

CSRF

SOP bypass (HTML5)

FingerPrinting

Exploit

Crowling

Path transversal

http methods

File Extension

Http spliting

Http smuggling

Error message

Exploit

File inclusion

Variable control

Variable Overwritting

Serialization

Error message

Business logic

Privilege

escalation

Replay

BufferOverFlow

Authentication

Code injection

WSDL

discovery

SOAP XML

DoS

XXE

Error message SQL

injection

SQL Wildcard

LDAP injection

XML injection

XPath injection

SMTP header

injection

How to protect : the infra view

WAF Capabilities

Client side Session side Server side Programming

language side

Application

side

Data

side

XSS

Reflective

Persistant

DOM based

CSIT

Flash

Applets

(HTML5 Web

Sockets)

Clickjacking

Cookie fixation

Cookie stealing

Cookie guessing

CSRF

SOP bypass (HTML5)

FingerPrinting

Exploit

Crowling

Path transversal

http methods

File Extension

Http spliting

Http smuggling

Error message

Exploit

File inclusion

Variable control

Variable Overwritting

Serialization

Error message

Business logic

Privilege

escalation

Replay

BufferOverFlow

Authentication

Code injection

WSDL

discovery

SOAP XML

DoS

XXE

Error message SQL

injection

SQL Wildcard

LDAP injection

XML injection

XPath injection

SMTP header

injection

How to protect : the infra view

WAF Capabilities

Client side Session side Server side Programming

language side

Application

side

Data

side

XSS

Reflective

Persistant

DOM based

CSIT

Flash

Applets

(HTML5 Web

Sockets)

Clickjacking

Cookie fixation

Cookie stealing

Cookie guessing

CSRF

SOP bypass (HTML5)

FingerPrinting

Exploit

Crowling

Path transversal

http methods

File Extension

Http spliting

Http smuggling

Error message

Exploit

File inclusion

Variable control

Variable Overwritting

Serialization

Error message

Business logic

Privilege

escalation

Replay

BufferOverFlow

Authentication

Code injection

WSDL

discovery

SOAP XML

DoS

XXE

Error message SQL

injection

SQL Wildcard

LDAP injection

XML injection

XPath injection

SMTP header

injection

How to protect : the security team view

Pro Cons

Exhaustive (as a security component) No knowledge of the application changes

Controlled by the security teams Ruleset to maintain

Good false positive tuning capabilities Not aware of the application business logic

Protect the environment Not Integrated with the repository

How to protect : the security team view

Vulnerability scanner

Bad configuration checks

Infrastructure checks

Generic vulnerabilities

DAST

How to protect : the dev view

How to protect : the security team view

Pro Cons

Automated No knowledge of the application changes

Controlled by the security teams Lack of framework support (JavaScript)

Quick Not aware of the application business logic

Test the environment Limited to known vulnerability patterns

Integrated with the repository

Agenda

o Intro

o Application security

o The dev team approach

o The infra team approach

o Impact of the agility

o The WAF

Before

Design

Implementation

+ Unit testing

Integration

testing

Business testingExternal security

audit

Fix issues

Go live

Security

validation arrives

only at the end !

SDLC enhancement

DesignDesign

Security

review

Implementation +

Unit testing

Security code

and

configuration

review

Fix issues

Integration

testing

Business

testingInternal

Security audit

Risk analysis

validation

Fix issues

Security audit

Fix issues

(only small

issues here)

Go liveThe audit validates the complete stack,

Can it be automated ?

What about the time for a vulnerability

to be integrated in this cycle ?

Is it possible to follow the cycle for

more than 16000 vulnerabilities per year ?

SDLC enhancement

DesignDesign

Security

review

Implementation +

Unit testing

Security code

and

configuration

review

Fix issues

Integration

testing

Business

testingInternal

Security audit

Risk analysis

validation

Fix issues

Security audit

Fix issues

(only small

issues here)

Go liveBut the release has to be quicker

With more feature

With less bugs

…..

Agility Impact

Release Management as sprint implies quicker….

• Patch management

• Risk analysis

• Security policy update/definition

• Roll back capabilities

Agility Impact

What to fight against ?

Get shell on the server

Retrieve exploit and tools

Get admin crendential and

maintain

Step1

•CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

•CAPEC-88: OS Command Injection

Step2

•CSC 5-1: No antivirus deployed.

•CSC 11-7 Lack of filtering on the network/application firewalls

Step3

•MS14-58 Vulnerabilities in Kernel-Mode Driver Allow Remote Code Execution

•Plaintext password stored in memory

•CSC 16-8: Weak or inexistant password policy

•CWE-262: Not Using Password Aging (krbtgt account)

Agenda

o Intro

o Application security

o The dev team approach

o The infra team approach

o Impact of the agility

o The WAF

Application Security

Secure software requirement

Compliance ISO 27001

Security requirements

Compliance with clients, asking for security proofs

Intrusion tests result and release postponed

Data privacy

Agility Impact

What do we want ?

• Continuous security test

• Quick security policy update

• Quick release

• Less vulnerabilities

• Less false positives

• Detect the vulnerabilities quicker

Agility Impact

What do we want ?

• Continuous security test -> the dev team knows how to automate

• Quick security policy update

• Quick release

• Less vulnerabilities

• Less false positives

• Detect the vulnerabilities quicker

Agility Impact

What do we want ?

• Continuous security test

• Quick security policy update -> the dev team knows how to automate (continuous integration)

• Quick release

• Less vulnerabilities

• Less false positives

• Detect the vulnerabilities quicker

Agility Impact

What do we want ?

• Continuous security test

• Quick security policy update

• Quick release -> (dev team problem !)

• Less vulnerabilities

• Less false positives

• Detect the vulnerabilities quicker

Agility Impact

What do we want ?

• Continuous security test

• Quick security policy update

• Quick release

• Less vulnerabilities -> (the infrastructure team has the DAST tools)

• Less false positives

• Detect the vulnerabilities quicker

Agility Impact

What do we want ?

• Continuous security test

• Quick security policy update

• Quick release

• Less vulnerabilities

• Less false positives -> (the security team knows the attacks)

• Detect the vulnerabilities quicker

Agility Impact

What do we want ?

• Continuous security test

• Quick security policy update

• Quick release

• Less vulnerabilities

• Less false positives

• Detect the vulnerabilities quicker -> (the security team knows the attacks, the infrastructure team has the

SAST tools)

Agility Impact

What do we want ?

• Continuous security test -> the dev team knows how to automate

• Quick security policy update -> the dev team knows how to automate (devops)

• Quick release (dev team)

• Less vulnerabilities (the infrastructure team has the DAST tools)

• Less false positives (the security team knows the attacks)

• Detect the vulnerabilities quicker (the security team knows the attacks, the infrastructure team has the SAST

tools)

Can we automate ?

• Static tests

• Dynamic tests

• Regression tests

• WAF policy tests

• Behavior driven tests

How to reduce the vulnerability window?

Can we see the infrastructure as a software component of the application?

Kind of security tests :

We don’t automated

We don’t have time

Because Because

Can we automate ?

• Static tests

• Dynamic tests

• Regression tests

• WAF policy tests

• Behavior driven tests

How to reduce the vulnerability window?

Can we see the infrastructure as a software component of the application?

Kind of security tests :

We don’t automated

We don’t have time

Because Because

Security dev

Jenkins

SonarQube IIS / TomcatOWASP Dependency

CheckOWASP Zap

Security infrastructure : EyeWAF

Visitor

HTTP(s)

WAF

Tester

Application Server

Testing Server

Agility Impact

Can we imagine ?

• The dev team handling the dev and helping in the automation ?

• The infrastructure handling the infrastructure rules based on the other team input

• The security team controlling what is done and creating the policies

Agility Impact

Agility Impact

Excellium Services S.A.

Thank you!

top related