Download as PDF, PPTX
Uploaded byDinis Cruz
Using security to drive chaos engineering - April 2018
Dinis Cruz, a CISO, discusses chaos engineering as a method for enhancing security in distributed systems by conducting controlled experiments to ensure system resilience during disruptions. Key principles include defining steady state metrics, performing hypothesis-driven testing, and automating continuous experiments to manage risks effectively. Cruz emphasizes the importance of visibility in security practices and frames chaos engineering as integral to modern change management.
More Related Content
Similar to Using security to drive chaos engineering - April 2018
Using security to drive chaos engineering - April 2018
- 1. Using Security todrive Chaos Engineering Dinis Cruz, CISO, Photobox April 2018
- 2.
- 3. I’m a CISOfocused on securing our client’s Magic moments by creating secure environments that enable and accelerate the business and contribute to the top and bottom line
- 4. Here are mychallenges How to make rational risk based decisions How to create high performance teams How to scale Security knowledge How to drive and enable change How to map data as graphs
- 5. We are alsohiring :) Head of AppSec Head of Cloud Security
- 6.
- 7.
- 9.
- 11.
- 12. Let’s look ata number of Chaos Engineering definitions
- 13. Chaos Engineering Building Confidence inSystem Behaviour through experiments
- 14. Chaos Engineering is abouttrying controlled changes to observe system availability deviation
- 15. Chaos Engineering is carefully injecting harm into our systems to test the system’s ability to respond to it.
- 16. Chaos Engineering isthe discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production
- 17. (most business friendly) ChaosEngineering is limited scope, continuous, disaster recovery
- 18.
- 19. 1. Start bydefining ‘steady state’ as some measurable output of a system that indicates normal behaviour. 2. Hypothesise that this steady state will continue in both the control group and the experimental group. 3. Introduce variables that reflect real world events like servers that crash, hard drives that malfunction, network connections that are severed, etc. 4. Try to disprove the hypothesis by looking for a difference in steady state between the control group and the experimental group. Chaos in practice - 4 experiments http://principlesofchaos.org/
- 20. 1.Build a Hypothesisaround Steady State Behavior 2.Vary Real-world Events 3.Run Experiments in Production 4.Automate Experiments to Run Continuously 5.Minimise Blast Radius Advanced Principles http://principlesofchaos.org/
- 21. the idea that“Chaos engineering is not Testing” Is caused by the failure to make TDD (Test-Driven development) Scale
- 22. TDD Demo 1) Real-time TestExecution 2) Real time code coverage
- 23. Chaos Engineering istesting the different are the test abstractions and the extra random layer
- 24.
- 25. Cyber Security isa ‘change generation factory’
- 26. Developers and Techopsare chaos creators
- 27. Security testing (andusers) are chaos creators
- 28. I have beencalled Director of chaos :)
- 29. The myth ofthe singe point of failure (i.e. attackers only need to run code and find a weak spot)
- 30. Do you understandwhat is going on in your network?
- 31. Biggest threat isnot the issue, but is not having visibility
- 32. When do youknow about security incidents? (or changes)
- 33. You need toknow what the attackers are doing on your system (and users)
- 34. If you don’tknow what is on the pentest report … you have a bigger problem (i.e. your SOC should be able to tell you)
- 35. Best Security modelis one based on the attacker making a mistake (i.e. a change)
- 36. Use risks tounderstand reality and to make the business owners responsible for their decisions
- 37. Use Threat Modelsto understand how your system works and to document it
- 38. Use tests toreplicate known behaviours, attacks and simulate changes (with and without random events)
- 39. Which can alsocalled Security tests (which pass on vulnerable state and on regression test)
- 40.
- 41. If a serveron your cloud is mining bitcoins Would you know about it?
- 42. If a serveror app misbehaves ? When do you know about it?
- 43. If your serversstart running 30% slower? What happens to your apps?
- 44. If your serversfails to reboot after a patch What happens to your system?
- 46. When (not if)you have malicious or api breaking dependencies? How do you know about them?
- 47. If 3rd partiesare using your APIs (official or not) to dump your user’s data (aka Facebook) Would you know about it?
- 48. Properties of resilient andsecure systems
- 49.
- 50. Plan for Failure Abilityto sustain failures
- 51. Validate and Sanitise allrequests
- 52. Authenticate and Authorise allrequests
- 53. Reduce capabilities and featuresgracefully
- 54.
- 55. Have error budgets (from Google SRE)
- 56. Are easy tochange
- 57. Are easy torefactor (make changes with confidence)
- 58. Pushes to production happen minutes (fully tested and 100x a day (if needed))
- 59. The bigger they getthe faster they go (it is smooth and safe to make changes)
- 60. Have 99% changecoverage
- 61.
- 62. It is notabout test code coverage
- 63. What matters is changecoverage
- 64. If you makechanges and they are not detected
- 65. you are justmaking random changes
- 66. Basically you are an agentof chaos
- 67. Every change youmake has to have a respective test change (much better pair programming model)
- 68. Chaos Engineering is modernchange management
- 69. Chaos Engineering is theprogramatic introduction of changes
- 70.
- 71. Following from 2017edition https://owaspsummit.org
- 72. Collaboration @ 16xper day for 5x days
- 73. Open Security Summit2018 - London https://open-security-summit.org/4th - 8th of June
- 80.