Tes Engineering Blog

Musings of the Tes Engineering Team

BlogHow we workMeet the TeamOpen rolesWork with us

November 11, 2020

Secure together: SnykCon 2020

by Rouan Wilsenach

I recently took two of my Tes training days to "attend" the inaugural SnykCon. It actually happened a few weeks ago, but thanks to it being a remote conference and recorded I was able to attend anyway, in my own timezone, without flying anywhere. Which I think is just fantastic. There was a good mix of content. I got exposed to some new ideas. Most talks were ~25 mins.


  • I would recommend the conference
  • You can find all the talks on YouTube
  • Top idea: rapid, smaller threat modelling sessions.
  • The best talk was about the environmental impact of cloud hosting and how not all the providers do a good job (Spoiler: AWS is very behind)

Read further for my key takeaways from my favourite talks. The talk titles below are links to the videos on YouTube.

Day 1

Story time: Secure coding libraries

Tanya Janca (3 mins)

  • When there are opportunities for reuse, create shared components with a focus on security baked in. E.g. a login screen
  • General benefit: sharing code means there's less rework
  • Security benefit: the components can be hardened, tested and improved and all services can reap the rewards

Panel discussion: Beyond the DevOps handbook

Patrick Debois, John Willis, Gene Kim, and Sasha Rousenbaum (20 mins)

  • DevSecOps is a silly name, but it's a good name. It's gained great community traction and it fits right in to people's existing ideas about DevOps so it's clear where to "put" security tools and practices.
  • Patrick Debois reckons the next thing is getting production feedback (from monitoring, incidents etc.) back into the development cycle.

Blow up your security: we are all engineers

DJ Schleen (20 mins)

  • Things to put into your PR test/review pipeline:

    • VERIFY: policy checks (I made a note to look into Open Policy Agent, which lets you define rules in your infrastructure that prevent bad things from happening)
    • ANALYZE: static checks – static analysis, dependency checks etc.
    • SIMPLIFY: discussions (between humans) and code improvements
  • OBSERVE (ways to expose security data for reporting)

    • DJ described the ability to request/raise exception from a PR i.e. I can't deal with security issue X right now, create a ticket on Jira.
    • He mentioned the idea of having a Slackbot that lets executives get a scorecard
    • Things are easier if you have a unified build process across your apps

How did the Department of Defence move to Kubernetes and Istio?

Nicolas Chaillan, Chief Software Officer, U.S. Air Force (20 mins)

  • The U.S. department of Defense's DevSecOps training videos are available publicly: https://software.af.mil/training/
  • They open source a lot of their work
  • They have a curated repository of DoD approved containers called the Iron Bank
  • They put Kubernetes on fighter jets
  • They use Istio sidecar containers
  • It sounded like their engineers get 1hr a day for learning
  • Key idea: Their Kubernetes clusters PULL code from Git, so their CI/CD platform has no access to production services

How to Implement a DevSecOps Culture in a Large Enterprise - People, Processes, Tools

Folks from Pearson (20 mins)

  • Threat modelling is the thing to do if you're not already
  • Provide security "services" for teams to use
  • They have a shared library (i.e. write-ups) of threats across teams to speed up their threat modelling sessions
  • They do some automated checking + Jira ticket creation
  • They include security training in their onboarding process

Security culture

Masha Sedova (27 mins)

  • An interesting talk about how behaviour psychology can be applied to the adoption of secure practices by users
  • B[ehaviour change] =[happens when] M[otivation]A[ability]P[rompt]
  • Motivation and ability are inverse (hard things harder to get motivated to do)
  • Two ways to encourage behaviour change: 1) Make the change really easy; or 2) Provide strong motivation
  • Social proof works really well to provide motivation. E.g. "80% of your colleagues, including Paul and Sarah, have MFA turned on. You're less secure than they are! Click here to turn it on."

User story threat modelling

Alyssa Miller (26 mins)

  • Threat modelling is great, but it's slow and it's hard to do continuously which is key to do it in a DevOps-y way.
  • Ask, per user story:

    • "What's the worst thing that could happen?" Involve business people in asking and answering this.
    • What assets do you have? Options: private data, critical functions, financial assets, people assets, secrets
    • STRIDE is cumbersome. Rather use these simple, less technical, concepts: Theft, Fraud, Exposed Data, Interrupted Service.
    • Instead of drawing an attack tree, create 3 counter-measures for each threat:

      • detection
      • mitigation
      • protection

Hackers don't wear hoodies, they wear capes

Chloé Messdaghi (27 mins)

  • This was a really illuminating talk from the perspective of ethical hackers
  • Outdated legislation, public perception and a lack of disclosure policies puts ethical hackers at risk
  • This means that 1/4 ethical hackers don't disclose what they find, for fear of legal persecution
  • Attackers are like burglars. (Ethical) Hackers are like locksmiths.

Day 2

The impact of DevSecOps quantified

Larry Maccherone (17 mins)

  • Their security team starts with a pledge: We trust that developers... ; We pledge to ...
  • ThWAC model to measure maturity:

    • Unknown (Don't know about it)
    • Thoughts (Thinking about doing it, learning about it)
    • Words (Talking about doing it, planning)
    • Actions (Starting to do it)
    • Culture (Built habits)
  • Practices that correlate strongly with positive security outcomes:

    • High-severity clean - resolve pipeline findings to 0
    • Security peer review as part of PR
    • Secure coding training (Checkmarx Codebashing)
    • Only merge secure code
    • Threat modelling
    • Production-ready security assessment (internal white box penetration testing)

Resilience engineering and security

John Allspaw (20 mins)

  • A great recap on what resilience engineering is all about. If you've never heard John talk about this topic I'd definitely recommend it.
  • John points out how these principles are relevant to cyber security
  • Bottom line: The sustained ability to adapt is key to good security

Host like your planet depends on it

Anne Currie (20 mins)

  • Most eye-opening talk of the conference, although it wasn't related to security
  • Regulators and governments are very likely to introduce legislation forcing companies to take carbon emissions seriously.

    • Your company is locked into: your cloud provider and your planet
    • If your cloud provider isn't looking after the planet it's a real business risk
  • There are three (non-negotiable) steps to improving and countering carbon emissions on the planet:

    • Today: Carbon Neutral (fix what you break)
    • Tomorrow: Carbon Zero (stop breaking the planet)
    • The day after tomorrow: Carbon Negative (remove all legacy emissions)
  • Microsoft (Azure) and Google (GCP) are both on track to do all three by 2030
  • AWS is behind
  • Tell AWS to take their carbon footprint seriously! You don't need to switch providers, but you need to tell them this is important to you so they make changes.

How to prioritize your vulnerabilities

Anna Debenham (23 mins)

  • CVSS is not enough to prioritise vulnerabilities, so snyk works out its own priority score
  • A demo of how Snyk provides better ways to prioritise vulnerabilities for fixing

Secure by Design - coding patterns

Dan Bergh Johnsson (26 mins)

  • Good software design can prevent bugs
  • Fewer bugs means a higher chance of more secure software

Do you accept the risk? Dynamic risk metrics in your environment.

Daniel Maher and Andrew Krug from DataDog (26 mins)

  • R[isk] = f(s[cenario], p[probability], c[onsequence], k[nowledge])
  • Errors are the only security risk currently trending upwards
  • Increase in complexity and scale means more errors, leading to rising security risk
  • You should think about what your risk budget is for each application
  • Use the output of e.g. CI tools that check for vulnerabilities or warnings & weight them by how critical the app is.
  • Andrew has some promising-looking OSS tools e.g. a tool to grab S3 info after a breach.

Rapid risk assessment

For a faster way of doing threat modelling, use the Rapid Risk Assessment approach from Mozilla.

In the RRA write-up there is a link to Binary Risk Assessment:

  • An easy way to give each service a risk score
  • There's a one-page PDF you can use
  • There's a web app too, though it doesn't look right in Firefox. Chrome was fine.

There is a wealth of good, concise information on https://infosec.mozilla.org/. It looks like a great resource.

I was lucky enough to have a chat with Guillaume Destuynder who created the Mozilla RRA "after" the conference:

  • He mentioned it's usually a good idea to think of the "service" in question as a product, rather than a particular microservice
  • The RRA can be represented as JSON, SQL etc.

Disclosing security vulnerabilities: If You’re Good at Something - Never Do it for Free

Anna Manley (6 mins)

  • A great lightning talk by a lawyer on the problems that can arise when you try do the right thing and disclose security vulnerabilities.
  • Be very careful when hacking ethically, the response may be antagonistic.
© Tes Engineering Team2021| All rights reserved
Follow @tes_engineering