Designing and building post compromise recoverable services

Preview:

DESCRIPTION

A look at how to design and build services, systems, networks, hosts and applications that are designed to be able to successfully deal with a security compromise. The deck also touches on the topics of self-healing systems and potential applications of machine learning to the problem space.

Citation preview

Designing and building post compromise recoverable services

Ollie Whitehouse

Why?"We may be at the point of diminishing returns by trying to buy down vulnerability"

"maybe it’s time to place more emphasis on coping with the consequences of a successful attack, and trying to develop networks that can ‘self-heal’ or ‘self-limit’ the damages inflicted upon them”

Gen. Michael Hayden (USAF-Ret.) ex NSA and CIA head February, 2012

Why?

Agenda

• Stages of a compromise• Impact limitation • Healing• Requirements for:

• design• build• operations

• Wrap-up and conclusions

Stages of a compromise

Stages of a compromise

Stages of a compromise

What can we do?

Deny

What can we do?

Frustrate

What can we do?

Misdirect

What can we do?

Contain

Services are unique

Indicator collection

Detection

Impact limitation

Healing – old wisdom / not practical

rebuild & reinstall everythingdown to bare metal

(to avoid whack-a-mole and persistence)

Healing – reality

remediate, re-establish trust & re-integrate

(whilst continuing to provide service, avoiding whack-a-mole & persistence)

Healing

Healing - configuration

Healing a live service

Healing – real world

The requirements

design, developmentand operations

Design• Packaging, testing &

deployment• Boundaries• Authentication• System wide monitoring• Isolation• Operation while isolated

Design• Roll-ability (not a word)• Query-ability (not a word)• Variable protection• Integrity verification• Frequency of checks

Design• Health / normal• Response

• if this then that• Consider

• Machine learning for behaviours• Rate limiting• Something else

Development• Staff & vendor education• 3rd party components• Source integrity• Build environment integrity• Build artefact integrity• Archive releases • Compromise unit test cases• Test compromise scenarios

Operations

• Able to define ‘security healthy’• Worse case scenario planning• Configuration management• Configuration integrity• Protective monitoring• Time-line capability• Fire drill - continually

The requirements of tomorrow

self healing

Self-heal – defining states

Self-heal - steps• Detect• Verify integrity • Understand and remediate• Alert • Segregate• Snapshot • Revert / Rebuild / Restart• Verify• Reintegrate

Self-heal – what is healthy?

• Client’s user behaviour• Client’s software behaviour • Client’s system behaviour • Clients behaviour

Self-heal – what is healthy?

• Service behaviour• Software behaviour• System behaviour• Network behaviour • Operations / staff (and their credentials)

Putting it into practice

two (simplistic) examplesand one point for consideration

Example #1 (semi-passive response)

• Client SQLi• Database dump – sequential record read• Response taken• Alerts raised• Snapshots taken

… facilitates full post indecent analysis

Example #2 (active response)

• Ops client side attack• Credentials stolen • Anomalous credential behaviour• Alerts sent • Credentials automatically disabled

… exposure window minutes

Point for consideration

• Red and Blue teams

• Red team could be a Netflix-esq simian army

• Blue team could be your self-healing systems

Conclusions

• Design and implement compromise readiness

• Self learning / healing the future

• Plan for worse case*

• Test scenarios continually

EuropeManchester - Head Office

Cheltenham

Edinburgh

Leatherhead

London

Milton Keynes

Amsterdam

Copenhagen

Munich

Zurich

North AmericaAtlanta

Austin

Chicago

Mountain View

New York

San Francisco

Seattle

AustraliaSydney

Thanks! Questions?

ollie.whitehouse@nccgroup.com

Recommended