Thread by @tleam

Afternoon talks starting with @aaronrinehart on “Security Precognition - applying chaos to security” #VelocityConf

First, what’s Resilience and how it applies to Chaos? Resilience is all about the incident that never happened.

#VelocityConf

We are covering a *lot* during this session... Pictures are worth a thousand words here.

#VelocityConf

And it’s time for the mandatory Death Star diagram outlining complexity in our systems slide. It’s used a lot but serves as a constant reminder that: we 👏cannot 👏fully 👏grok 👏how 👏our👏 systems 👏operate.

#VelocityConf

We are still designing stateful security in a stateless world... which is concerning - @aaronrinehart #VelocityConf

There are two different types of complexity:
1) Essential, or intentional, complexity (think business functionality)
2) Accidental complexity - inherent complexity that occurs based on design but not necessitated by business function

#VelocityConf

Personally, I’m not sold on the “Accidental” complexity terminology. I think most complexity is intentional or considered up front. I’d probably lean more on “no longer desirable” complexity.

#VelocityConf

Security tends to have a very blame centric culture and is highly reactive to incidents. We need to get more proactive! Chaos Engineering can help here. - @aaronrinehart #VelocityConf

Putting problems and pain, like security incidents, at the feet of developers is a great method of incentivizing preemptive approaches. This is based on the fact that people operate differently when they expect things to fail.

@aaronrinehart’s meme game is strong

#VelocityConf

Chaos Engineering can be used to initiate objective feedback loops about security effectiveness.

Use Chaos to validate your *assumptions* of how security systems operate with *reality*

#VelocityConf

What’s the difference between security chaos and traditional red, blue, purple testing?

Chaos is geared more towards cascading elements than “whether a breach is possible”

Note: Chaos security testing isn’t a replacement for the other types of tests!

#VelocityConf

We tend to focus a lot of our energy on Malicious attacks (because let’s face it... it’s cool) but the majority of incidents are generated by Human Error (not a thing) and system glitches.

#VelocityConf

Diving in to how to run security chaos via Chaos Slingr.

“What would happen if someone accidentally or maliciously introduced a misconfigured port? Would we automatically detect and reject?”

#VelocityConf

Here’s a huge list of potential experiments. These aren’t “attacks” per sr but things that can occur during application and system development journeys.

#VelocityConf