First I must say I did not go to Las Vegas, all I did is hunt the Internet for pieces of information and did not copy completely, but edited to make it easier to understand when reading only (versus giving presentation within the hall):
“Controlled Chaos” the Inevitable Marriage of DevOps & Security (Kelly Shortridge and Nicole Forsgren) is an interesting and thought provoking presentation.
This presentation is listed at this page: https://www.blackhat.com/us-19/briefings/schedule/
Here is the relevant information in the presentation:
What are the principles of chaotic security engineering?
- Expect that security controls will fail & prepare accordingly
- Don’t try to avoid incidents – hone your ability to respond to them
- What are the benefits of the chaos/ resilience approach?
Time to D.I.E. instead of the C.I.A. triad, which is commonly used as a model to balance infosec priorities.
CIA first – Confidentiality – Integrity -Availability
Confidentiality: Withhold info from people unauthorized to view it.
Integrity: Data is a trustworthy representation of the original info.
Availability: Organization’s services are available to end users
But these are security values, not qualities that create security. Thus we need a model promoting qualities that make systems more secure.
D.I.E. model: Distributed, Immutable, Ephemeral
Distributed: Multiple systems supporting the same overarching goal. This model reduces DOS attacks by design.
Immutable: Infrastructure that doesn’t change after it’s deployed and servers are now disposable “cattle” rather than cherished “pets”. The infrastructure is more secure by design – ban shell access entirely and although lack of control is scary, unlimited lives are better than nightmare mode.
Ephemeral: Infrastructure with a very short lifespan(dies after task). Where ephemerality creates uncertainty for attackers (persistence=nightmare). I.e. installing a rootkit on a resource that dies in minutes is a wasted effort.
Optimize for D.I.E. reduce your risk by design and support resilience
So what metrics are important in resilient security engineering?
TTR is equally as important for infosec as it is for DevOps.
Time Between Failure(TBF) will lead your infosec program astray.
Extended downtime is bad (makes users sad) not more frequent but trivial blips.
Prioritizing failure inhibits innovation
Instead, harness failure as a tool to help you prepare for the inevitable
TTR>TTD – who cares if you detect quickly if you don’t fix it?
Determine the attacker’s least-cost path (hint: does not involve 0day)
Architecting Chaos
Begin with ‘dumb’ testing before moving to ‘fancy’ testing
- Controlling Chaos: Availability
- Existing tools should cover availability
- turning security events into availability events appeals to DevOps
- Tools: chaos Monkey, Azure fault analysis, Chaos-Lambda, Kube-monkey, PowerfulSeal, Podreaper, Pumba, Blockade
- Controlling Chaos: Confidentiality
- microservices use multiple layers of auth that preserve confidentiality
- A service mesh is like an on-demand VPN at the application level
- Attackers are forced to escalate privileges to access the iptables layer
- Test by injecting failure into your service mesh to test authentication controls
- Controlling Chaos: Integrity
- Test by swapping out certs in your ZTNs all transactions should fail
- Test modified encrypted data and see if your FIM alerts on it.
- Controlling Chaos: Distributed
- Distributed overlaps with availability in context of infrastructure
- Multi-region services present a fun opportunity to mess with attackers
- Shuffle IP blocks regularly to change attackers’ lateral movement
- Controlling Chaos: Immutable
- Immutable infrastructure is like a phoenix – it disappears and comes back
- Volatile environments with continually moving parts raise the cost of attack
- Create rules like: “If there is a write to disk, crash the node”
- Attackers must stay in-memory, which hopefully makes them cry
- Metasploit Meterpreter and webshell: Touch passwords.txt & gone
- Mark Garbage files as “unreadable” to craft enticing bait for attackers
- Possible goals: Architect immutability turtles all the way down
- Controlling Chaos: Ephemeral
- Infosec bugs are stated-related so get rid of state, get rid of bugs
- Reverse uptime: longer host uptime adds greater security risk
- Test: change API tokens and test if services still accept old tokens
- Test: inject hashes of old pieces of data to ensure no data persistence
- Use “arcade tokens” instead of using direct references to data
- Leverage lessons from toll fraud – cloud billing becomes security signal
- Test: exfil TBs or run a cryptominer to inform billing spike detection
How should infosec and DevOps come together and develop all of these concepts?
Has to be done as a cultural “marriage” cultivate buy-in for resilience and chaos engineering.
This is a marathon not a sprint and changing culture : change what people do , not what they think.
———————————————
There are a lot more suggestions, but the main themes that I took out of this presentation slides is that you can make your defense more resilient and tougher by making it a little bit chaotic. I.e. Immutable and ephemeral are some good concepts to think about and use in your infrastructure. Every environment is different and will require co-ordination and rethinking of how things work, but it is good to work some of the concepts into your environment.
Here is a great piece of thinking: Don’t keep your systems up as long as possible, as it is also a security risk (besides patching and other issues).
Using short lifespan hardware with frequent rebooting (relatively – like every day for example) makes the attacker’s life much more difficult. Of course patching requires some rebooting, but monthly or quarterly reboots are not frequent enough.
Also here are some links from DEFCON
First the Media presentation webpages: https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20presentations/
(I always include the full link instead of Media.defcon.org link so one can see where it will go)
First I look at the Speaker’s bio and quick overview of the presentation given at this link: https://www.defcon.org/html/defcon-27/dc-27-speakers.html
Then I download the information freely available on the Internet. I will have more posts on the presentations at DEFCON and Blackhat.