tl;dr sec is a newsletter about AppSec and scaling security, automated bug finding, conference talk and paper summaries, and useful links from around the web. See past issues here.

(in)Secure Development - Why some product teams are great and others aren’t…

Hey there,

I hope you've been doing well! I've been a bit busy traveling, but things are great. My birthday was last week, and I did a bit of

on Twitter.

This issue includes some key takeaways of Riot Games' InfoSec Development Manager

's AppSec Cali 2019 talk:

"(in)Secure Development - Why some product teams are great and others aren’t...".

You can read a

full summary here

.

Links

Sqreen published a nice high-level

SaaS CTO Security Checklist

broken down by areas of concern (employees, code, app, infra, company, product users) and company stage (seed, series A, series B). I like that the descriptions are concise but useful and have links to supporting resources.

, the guy behind

, manually audited all 500+ of AWS' managed policies looking for security issues and silent fixes. In this blog post he

discusses several issues he found

, including tagging secrets, privilege escalation, resource policy privilege escalation, and more.

As you might guess, I'm a big fan of security summaries, and

wrote some

nice tl;dr's of a number of papers and posters

from this past ICSE, which is a top-tier academic software engineering conference. The papers cover topics including static analysis, SMT solving, fuzzing, concolic testing, and of course #blockchain.

New Summary: "(in)Secure Development - Why some product teams are great and others aren’t..."

Koen describes analyzing the security maturity of Riot product teams, measuring that maturity’s impact quantitatively using bug bounty data, and discusses one lightweight prompt that can be added into the sprint planning process to prime developers about security.

Key Takeaways:

• Based on observing how development teams discuss security and interact (or don’t) with the security team, Koen groups dev teams into 4 security maturity levels.

• Teams at these maturity levels range from largely not thinking about security (Level 1), to having one or two security advocates (Level 2), to security being a consistent part of discussions but it’s not yet easy and natural (Level 3), to security consciousness being pervasive and ever-present (Level 4).

To examine if a dev team’s level had a measurable impact on the security of the code bases they worked on, Koen analyzed Riot’s 2017 bug bounty data group by team maturity level. The differences were

clear and significant

.

• Compared to teams at Level 1, teams at Levels 2-4 had:

  • A 20% / 35% / 45% reduced average bug cost

  • A 35% / 55% / 70% reduced average time to fix

  • The average issue severity found from internal testing was 30% / 35% / 42% lower

• Riot chose to focus on raising Level 1 and 2 teams to Level 3, as that yields the biggest security benefits vs effort required, makes teams’ security processes self-sustaining without constant security team involvement, and makes them more accepting of future security tools and processes provided by the security team.

• They did this by shaping development team behaviour, rather than purely focusing on automation and technical competencies and capabilities.

How to uplevel dev teams? During standard sprint planning, dev teams now ask the following prompt and spend 2-3 minutes discussing it, recording the outcomes as part of the story in Jira/Trello/etc.:

Though the dev team may not think of every possible abuse case, this approach is highly scalable, as it primes devs to think about security continuously during design and development without the security team needing to attend every meeting (which is not feasible).

Some final thoughts:

• The security level of a team influences how the security team should interact with them.

  • If the majority of your teams are Level 1 and 2, rolling out optional toolings and processes isn’t going to help. First, you need to level up how much they care about security.

• Work with Level 3 and 4 teams when building new tooling to get early feedback and iterate to smooth out friction points before rolling the tooling out to the rest of the org.

  You can read the

full summary here

.

How does your company do threat modeling?

One thing I hear from friends at a variety of companies is how tough it is to a) stay on top of architecture reviews and threat modeling with a rapid pace of development and b) keep threat models accurate as features and requirements change over time.

How does your company handle these challenges? If there's any specific tips and tricks your team has found effective, I'd enjoy hearing about them.

Sharing is Caring

If there's anyone you know who would find this newsletter interesting or useful, we'd really appreciate if you'd forward it to them.

Have questions, comments, or feedback? Just reply directly, we'd love to hear from you.

Thanks for reading!

Cheers,

Clint

|