DevSecCon Tel Aviv 2019 Roundup

DSC Tel Aviv was nice: it was small and personable with a great venue, some single track talks, and then an “unconference” section.

If “unconference” doesn’t mean anything to you, don’t worry, it didn’t to me either until I showed up. Attendees collectively put forth a number of topics or challenges we had, we voted on them, and then self-organized into small groups where we discussed them in detail. Pretty neat.

Here are some key takeaways from the talks.

The Hardest Part of DevSecOps: Working Together

Elissa Shevinsky started the conference off strong with an audience interaction-heavy opening keynote to get people engaged and starting to discuss the most pressing challenges they had.

I hadn’t met Elissa before, but throughout the con I was impressed by how friendly and supportive she was of the people around her. If you run into her at a con, you should say hi!

She’s also the author of the book Lean Out: The Struggle for Gender Equality in Tech and Start-Up Culture and CEO / co-founder of Faster Than Light, an early stage start-up aimed and making static analysis faster by distributing work to many nodes via Kubernetes on AWS. It’ll be interesting to see where this goes.
(home page, try it now)

Lost in (DevSecOps) Space – practical approach for “Lightway” Threat Modeling as a Code

(slides) By Vitaly Davidoff, AVP and Application Security Expert at Citi Innovation Lab.

As a number of other talks have pointed out, traditional threat modeling (TM) approaches, such as STRIDE, PASTA, VAST, and Trike have struggled to keep up in fast-paced, Agile development shops.

Other common TM problems include:

• The results are not propagated to developers.

• TMs are updated rarely (if at all) as applications change.

• TMs are concentrated on diagrams, not countermeasures, and are not integrated within the DevOps development model (CI/CD).

The core idea in this talk is to follow the lead of other DevOps domains, such as infastructure as code and CI/CD processes as code, and implement TM expectations in code as well.

The goal is to build up a series of templates for common threats (specified in JSON or YAML) that can be applied to many applications, for example, risks relevant to any web app, or REST API, GraphQL API, etc.

Not all aspects of threat modelling will be automatable, but you can still get some great value and scalable wins from automating the common cases and low hanging fruit.

Here’s the process Vitaly recommends:

Other tools referenced:

• Open source: Slack goSDL, Threat Playbook, Robot Framework

• Commercial: Threat Modeler, IriusRisk, Orchestron, Security Compass, ZeroNorth

Secrets are hard to manage. How to manage your secrets and keep them safe

Jake Hall, Principal Consultant at Infinity Works, gave a nice overview of the problems caused by a poor (or no) secret management strategy, how to gradually start managing secrets properly, and concluded with a Vault demo.

Without a good secret management solution:

• You don’t know what secrets exist and where they are, as they could be distributed across source code, your wiki, etc.

• You have limited visibility into how they’re used- attribution of actions taken using a shared secret is tough, and without central management, it’s impossible to know which users or services are using a given secret (e.g. DB credentials).

• If a secret is leaked or otherwise needs to be rotated, lack of central management makes rolling the secret hard, time-consuming, and error prone, likely leading to development slowdown or potential service failures.

How to get your secret sprawl under control:

1. Find all of your secrets for a given service (e.g. a microservice, DB, or third-party API).

2. Copy the secrets into your centralized solution.

   • We want developers to continue being able to move fast and ship new code, so we’re copying the same secrets into the secret management tool.

   • Example secrets management tools: Vault, AWS Secrets Manager, Azure Key Vault, GCP berglas.

3. Integrate your centralized secret management tool with your service.

   • Have your applications read the secret at runtime from the new tool instead of how they were obtaining it before (ENV variable, plaintext file, source code, etc.)

4. Validate, then run in production.

   • Start with 1-2 services, validate with engineering and DevOps teams that it works in prod.

   • Remove secrets from their old locations, then start rolling them.

To minimize your pain during this transition:

• When you’re doing the PoC, test each service type you’ll need to support. For example, if you have Java and Python microservices, determine how the secrets management tool will handle both cases.

• Choose the hardest case(s) first.

  • If you have a service that communicates with multiple third parties or otherwise has a complicated use case, make this service work first, which will allow you to demonstrate viability early on and de-risk future work.

Securing Containers by Breaking In

Liran Tal, Developer Advocate at Snyk, described a number of container security best practices and some stats from the Snyk State of Open Source Security - 2019 study. Some parts that stuck out to me:

• 20% of Docker images had known vulns that would be fixed simply by rebuilding it (e.g. Dockerfile includes apt-get update or the like).

• There can be a vast difference in the number of known vulns in system libraries in similar base images, for example:

  • node:10 - 582

  • node:10-slim - 71

  • node:10-alpine - 0

DevSecOps: State of the Union

This was my first keynote, so I spent awhile thinking about how to make it appropriately “keynote-y“™. I decided to make the first half of this talk a summary of modern DevSecOps principles and practices I’ve seen across many companies, and the second half my predictions about the future of DevSecOps and security programs in general.

I’m going to flesh out these predictions in more detail in a blog post, but here they are now as a teaser:

• Many vulnerability classes will be squashed.

  • OWASP-type bugs (e.g. XSS, CSRF, SQLi) will be solved by better libraries, frameworks, secure defaults, and ecosystem changes.

  • Memory safety issues will gradually die to broader adoption of better languages, like Golang and Rust.

  • Business logic bugs will remain.

• ML / AI - current offerings are mostly hype, but ML will likely be incorporated in powerful ways in the future in both offensive and defensive applications.

• Platforms (e.g. cloud providers and code hosting solutions) will invest heavily in security, and security features will become a primary selling point of the platform.

• Security product companies (e.g. SOAR, ASTO) will replace much in-house custom glue code.

• Every security professional (SOC analyst, pen tester, reverse engineer, …) will be heavily tool-augmented.

Feel free to shoot me an email or reach out on Twitter and let me know if you agree, disagree, or believe something totally else entirely.