Embed Size (px)
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?
