3 minute read

Tom McLaughlin presented on iterative security,  incorporating security into DevOps cycles through early detection and prevention of vulnerabilities. His slide are here. This is a loose transcript of taking points from his talk at DevOps Days Boston 2017.

Breaches in Practice vs. Theory

Tom made the point that breaches often occur in areas that aren't covered by development or security teams because vulnerabilities escape due to a lack of objective and continuous risk assessment.

Code still has passwords and tokens in it. Lots of assumed knowledge going from dev to prod. Account access and password policies, patching, is usually handled by someone else. Leads to "good luck, it's up to you" syndrome.

There's also security paralysis. When we don't think we know how to do something, we just won't. And we're rewarded for accomplishing things. So long as disaster doesn't strike, we get by.

Why Do We Suffer from Security Breaches?

Mostly, we get distracted. 0-day exploits, crypto weaknesses, hash collisions. We get distracted by logos and discussion threads, but not patching the system. We get caught up in all of this stuff instead of actually doing what improves security.

Think about all the publicly exposed mongodb and Elasticsearch instances you've seen...being proactive isn't always hard, but is rarely incentivized well.

We don't do a good job explaining how to get from where you are to where you should be. We also don't always practice critical thinking. What is you goal? What is your posture about security? Proactive, reactive?

We also don't always have a wealth of layered instructional content. There's a lot of information at the extremes (101 and advanced tutorials), but most of us are in the middle.

Solve the Problem Like You're At Work

So then let's develop a threat model together, as an example. Let's start by being realistic. What kind of org and product matters? Align with your company on risk management policies and processes.

Prioritize. Use DREAD (or STRIDE) for rating threats and modeling risk.

Also take care of the easy stuff: USB sticks over man in the ceiling.

"Do you still use a service after it's been breached? I leave that up to you."

Decompose the system. Map out your architecture and understand the systems. Look at the perimeters, how are credentials proliferated? Understand your data pipeline, where is your really valuable data stored?

Take time to consider things like exposed net ports, unpached containers, weak secrets...there are tools for this. These tools can be found in later slide here.

Putting a Response to Security Threats into Action

Two words: impose constraints. To find which constrains work for you and start with a simple discovery process that includes:

  • Time, how long to solve? Timebox solutions, defensible use of existing time.
  • Complexity, how hard is it? Ask deep questions, iterate over which help.
  • Risk, how risky is the problem and solution?

Secrets management is a first start. Tom pretty much pwns this space and I encourage you to seriously check out his extensive work on the topic here.

In terms of tactical actions you can take today, Tom mentioned these few, but of course there are more:

  • At the code, start with at least something like git-crypt.
    Ask yourself, what should be thrown out before it goes anywhere else?
  • In configuration management scripts:
    Developing a master re-key strategy is a great exercise to flesh this out.
  • Storage...a tool like sneaker for S3
    Really makes you ask questions...who/how are buckets managed.

Summary

We need to be better at security, continuous or otherwise. We need to act. There are simple things you can do, but they need to be aligned to your team/organization risk strategy. And make it easy for others to do the right thing, so that it's far more likely to happen without imposing huge effort cost.

Tom's a great speaker, engaging and fun to listen to. He is also a huge community contributor and even runs a distributed DevRel (developer relations) slack group. Tom is currently working on the CloudZero team.

More reading:

[wonderplugin_slider id="1"]

You may also enjoy