Web Application security testing: who tests the test?

(1)

Web Application security testing:

who tests the test?

(2)

About myself

Functional

testing

Leading test

group

Reporting to

client

Formal QA

Performance

testing

HTTP level

analysis

Behavior

modelling

Security

testing

Application

security

Threat

analysis

(3)

(4)

Why we test, what we test?

What they

needed

Code

Design

Specification

(5)

Test levels - theory

UAT

System

Integration

Unit

What they needed

Specification

Design

(6)

Different test levels

Dev

.

_Test

(7)

Because bugs escape testing

DEV

Test

User

mistakes

time

changes

skills

(8)

QA approach: test to reduce bugs



_{Functional testing practice: bug metrics}

–

Defect Removal Efficiency (DRE) = bugs before delivery

/ total number of bugs

–

Defect density = defects / number of code lines

… passing security testing

is not an indication that

no flaws exist …

(9)

How much testing is enough?



_{Functional testing experience:}

–

“Coverage problem” part of test strategy

–

IEEE Std 829, Standard for test documentation



Security testing is different:

–

OWASP testing standard (minimal tests)

–

ISO 2700*standard (minimal controls)

(10)

How much testing is enough? - experience



_{Test guides:}

i.e. by OWASP ~100 attack types



B.B. Test tools: thousands of attacks



My own experience

–

Average internal audit : 3-5 person days

–

Singe attack type per field take up to 2 hours

–

I don’t test everything

–

I don’t test app., I validate assumptions

Perhaps automated

testing is the choice?

(11)

Recent movement in Functional Testing



Industry leaders re-defining term “test”

–

Automated Checks VS Sapient Tests

–

Some checks are hard(er) to automate



Automated security test tools

–

checks to see if the application is vulnerable to attacks



Tools that help sapient (manual) testing

check

that’s not hard to automate

known

(12)

Risk assessment: “issue -> threat”



DREAD: prioritize issues based on sum of

–

Damage potential

–

Reproducibility (prerequisites)

–

Exploitability (knowledge/tools required)

–

Affected users

–

Discoverability (e.g. risk of getting caught)



Alternatives exist, such as CVSS



Assumes we know the vulnerability

(13)

Experience: missing threat analysis

Development

Audit

(14)

Different security testing levels



_{Application VS Perimeter*}

–

Code VS network

–

Threat VS vectors



Internal VS External

–

Interfaces VS business

–

Techniques VS risks

(15)

Risk assessment: “threat -> issue”

Step 1

• Decompose the application

Step 2

• Determine (and rank) threats

Step 3

• Set countermeasures & mitigation

OWASP Application Threat Modeling

(16)

Mitigation strategies



Performance monitoring

–

Utilization = % of CPU, memory, network, etc.

–

Response times, Session count, fault ratios, …



Security monitoring

–

Analyze authentication (login) failures

–

Analyze authorization failures (server side)

–

Analyze XSS attack attempts

(17)

Missed bug = reported by user ?

…most of security incidents are discovered

and reported only months after the initial

intrusion or data compromise.

OWASP: The CISO Guide

(18)

Backdoor mitigation



Backdoors

–

Application code (created on purpose)

–

Created by hacker (i.e. stolen admin password)



Mitigation – analyze attacks not vulnerabilities

–

Security Intelligence, SIEM

–

Honeypot



Users could help mitigate

–

Inform user about last login

–

User intelligence (i-bank: transaction history)

–

Change passwords on regular basis

(19)

RECOMMENDATIONS

(20)

Analysis of discovered vulnerabilities (findings)



_{Adopt PCI recommendations per vulnerability :}

–

Define whether/how exploitable

–

Risk ranking



Adopt PCI overall analysis recommendations:

–

Describe restriction imposed

–

Use PCI Test report evaluation checklists



Analyze risk of vulnerabilities missed

(21)

Comprehensive testing



_{Demand “standard” security}

–

Protect from script kiddies

–

Discourage hackers (i.e. do not encourage)



Distinguish comprehensive testing

–

Documenting test coverage, not just bugs

–

Hire two independent auditors to compete

–

Penalties for missed security threats

(22)

Mitigation: intrusion detection



Example:XSS protection options

–

Turtle: do not allow

–

Accepted: do not

allow and notify admin

–

Honeypot: allow,

(23)

Gartner Top 10 Strategic Technology Trends for 2015



Risk-Based Security and Self-Protection

test

educate

While 100% security solutions

aren’t feasible, advanced risk

assessment and mitigation will

come into play in the next few

years.

Security will move away from

perimeter defense to

(24)

24

www.exigenservices.lv

QUESTIONS?

Contact:

Ainārs Galvāns

Aplication PenTester, Exigen Services Latvia

[email protected]

J.Daliņa iela 15| Rīga, LV-1013, Latvia

phone +371 6707 2976 | mobile +371 2943 2698