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. You can subscribe here and see past issues here.

DevSecCon Seattle 2019 Round Up

Hey there,

I hope you've been doing well!

In this newsletter:

• I ask for feedback for an upcoming talk I'm giving: What's a source code anti-pattern you want to find?

• Talks I liked from DevSecCon Seattle - continuous compliance, secure wrapper libraries, and more.

• Links about ML that reads privacy policies, a new XSS cheat sheet from Portswigger, and some cloud security PoC attacks.

• A salacious pic a tech billionaire doesn't mind if you see.

You can read the newsletter on our website

here

.

🗨️

Feedback Wanted: What's a source code anti-pattern you want to find?

At every company, there are standard ways to call internal frameworks and APIs. When you call them the wrong way, it can lead to a bug.

These code patterns may be hard to

grep

for (too noisy) but don't require the full power of slow, expensive commercial SAST tools.

My friend

and I are giving a

talk at ShellCon

about using open source tools to find these source code anti-patterns. For example:

• Find every time foo() is called where an argument is/isn't a hard-coded string

• What parameters do various controller methods care about?

Feel free to reply directly to this email with examples of patterns you'd like to find, and we'll cite you in the slides

💙

⭐️

DevSecCon Seattle 2019

Recently I was in Seattle for

DevSecCon Seattle

, which was a great con - nice venue, good attendee size (not too big, not too small), and a number of solid talks.

I'm on the DevSecCon program committee, so it was gratifying to see how all the effort we put in reviewing talks created a nice program

🤘

There were many great talks, but here are a few I want to call out.

Keynotes

opened the conference with a fun and engaging keynote about how security is everybody's job. She made everyone raise their hand and

promise that they worked in security regardless of their role (e.g. developer, project manager, etc.).

, author of the book

Securing DevOps

and manager of the Firefox Operations Security team at Mozilla (i.e. all the back-end services and infra), keynoted the second day (

slides + speaker notes

). Tons of good takeaways, including:

• Using data to justify to management to actually invest less in an area when other areas will have higher security impact. This can make sense after you've spent years investing in services and tooling that eliminate classes of problems.

• Check out the Mozilla services web security checklist for a nice baseline of security control expectations, written in Markdown, that Mozilla copies into a GitHub issue for new services.

• The Mozilla Rapid Risk Assessment is a ~30min lightweight threat modeling exercise that can be done with dev teams to determine the risk of a service.

• "Don't just build security tools. Build operational tools that do things securely."

• Clear expectations -> Checklist -> Self Assessment -> Profit.

• Some thoughts on the relative impacts of the organizational structure of dev and security teams:

-------------------------------

Secure Wrapper Libraries FTW

Morgan Roman gave an excellent talk (abstract | slides) on creating secure-by-default libraries and then ensuring their use via lightweight static analysis (aka grep).What's particularly great about this talk is Morgan's emphasis on the process of finding these security engineering opportunities and addressing them. He walks through 4 concrete examples of how this was done at DocuSign for Regex Denial of Service, XXE, open redirects, and SSRF.

Creating secure defaults / building a "paved road" (as Netflix likes to call it), is an emphasis I hear again and again from high performing security teams at various companies.

DevSecOps Panel

I moderated another

DevSecOps panel

with some smart friends from Netflix, Dropbox, Datadog, Apple, and Signal Sciences. I'll share a summary and the full transcript when the video is live.

If you just can't wait,

see here

for a summary of another DevSecOps panel I moderated at AppSec Cali 2019.

Continuous Compliance

Compliance can be a pain. Oftentimes it can be a checkbox-y activity that doesn't actually improve security. Instead, it involves documenting systems and processes in PDFs or Excel spreadsheets that become out-of-date as soon as they're made.

One interesting theme we saw through several talks is that some of the ideas and principles in Agile and DevOps can be applied to compliance (e.g. infrastructure as code) -- enabling compliance to be an easy, continuous state rather than a big effort quarterly or annually.

, a developer advocate at Chef, describes (

abstract

|

slides

) how you can use

InSpec

to specify your compliance, security, and other policy requirements in code.

• Similar to other config management tools like Chef, Puppet, Ansible, etc., you can say "the following files/directories/groups should exist," "the following packages should (not) be installed, "the following services should (not) be running," and roll these policies out easily to all of your servers and ensure that there's no drift over time.

• To be honest, it's not clear to me what value InSpec provides over the baseline features of any config management tool. Conceptually you could apply the same requirements via Puppet/Ansible or even baseline Chef.

• The real value here seems to be in the specific policies, which document useful security domain knowledge. dev-sec.io has some solid examples of hardened defaults for common software (e.g. MySQL, Apache, SSH, Docker, K8S) and OSes (Linux, Windows).

• You can see the source for the various hardening playbooks on GitHub.

of LifeOmic gave a talk (

abstract

|

slides

) on how development can still move fast in environments that must maintain HIPAA/HITRUST compliance. In this type of environment, all changes to production must be auditable/documented and every PR must have received peer reviewed and have been vetted by security scans.

• The change approval process used to be a bit painful and manual, but they automated aggregating the info required by compliance using a change management bot.

• Basically: Jira change management issue created -> webhook -> Bitbucket/Jenkins/Jira info analyzed -> updates the Jira ticket if required policies have been followed.

Erkang Zheng, the CISO of LifeOmic, also presented (abstract | slides) about some technology they've built that they've spun out into a start-up, Jupiter One.

The core idea is to represent all of your company's assets (people, teams, laptops, servers, code repos, PRs, AWS accounts, known vulnerabilities, ...) as nodes in a graph and have edges between them denoting relationships. This allows you to write graph queries that give you useful visibility into your assets as well as potential security issues. For example: 

If this idea sounds familiar, you're right! That's because Sacha Faust of Lyft gave a BSidesSF 2019 talk about essentially the same approach, and they open sourced their tool on GitHub: lyft/cartography.Another interesting idea from Erkang's talk is having security policy and procedure documents written in Markdown and stitched together with a config JSON file. Changes to these policies are then tracked via git and the info can be imported into the same graph DB for querying/relating to other aspects of your org. They've open sourced some templates on GitHub with mappings to HIPAA, NIST CSF, PCI DSS, FedRAMP, and CIS Controls.You can also manage your vendors as code (and thus include in the graph):

They've open sourced a number of their adapters on the Jupiter One GitHub page. You may find the secops-automation-examples and bitbucket-pr-detector repos useful.ReflectionsWhile I liked both presentations, overall I wish the InSpec and Jupiter One talks had been a little more, "here's a tough problem space, here's how we think about it and our mindset/methodology for addressing the challenges" rather than "here's our specific solution in detail." The former is more easily generalizable, allowing the audience to benefit from the talk's insights regardless of if they use the specific tools  described. 

🔗

Links

Guard

uses AI to read various site's privacy policies and gives them a letter grade for how they treat your privacy. They list the site's recent privacy scandals, summarize the main privacy threats discovered in the policy, and display the privacy policy with the sensitive parts highlighted in red.

Portswigger released an

interactive XSS cheat sheet

that lets you filter by tag, event type, and browser. At first glance, seems like the successor to the iconic

OWASP XSS filter evasion cheat sheet

.

• Gareth Heyes describes a number of the especially interesting examples he discovered using some automated fuzzing and manual probing in this blog post.

• See some slides about Gareth's XSS magic here.

Some

PoC

s from

of Rhino Security Labs: GCP cloud shell docker escape, getting AWS-owned AWS keys from AppStream, hitting the AWS Lambda runtime API with SSRF, and getting creds from the "disabled" AWS Glue metadata API.

Semmle, a static analysis company started by a few Oxford academics, was bought by GitHub (aka Microsoft) -

Semmle's announcement

.

• GitHub's announcement is quite interesting, because it hints at GitHub's vision of the future of secure software development and how their features support it - support for disclosure and private forks for fixes within the platform, Dependabot to find out-of-date dependencies, and Semmle to find bugs.

• Finally, a lengthy write-up about Semmle from a Google engineer on HN that was taken down but can be read in Google's cache here.

Apparently you can now

buy disinformation campaigns on the dark web

, it's not limited to nation states trying to influence elections (

cough 2016 cough

). What a time to be alive

😅

✉️

Wrapping Up

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

If you find this newsletter useful and know other people who would too, I'd really appreciate if you'd forward it to them

🙏

Thanks for reading!

Cheers,

Clint

|

P.S. As your reward for making it to the end, here's the salacious pic:

Known colloquially as "Bezos' balls," [0] the Amazon Spheres are two recently built enclosed botanical gardens in Seattle for Amazon employees to relax in, with some public space.[0] True story, I overheard two separate groups of locals refer to them that way.

Hey there,

I hope you've been doing well!

In this newsletter:

• I ask for feedback for an upcoming talk I'm giving: What's a source code anti-pattern you want to find?

• Talks I liked from DevSecCon Seattle - continuous compliance, secure wrapper libraries, and more.

• Links about ML that reads privacy policies, a new XSS cheat sheet from Portswigger, and some cloud security PoC attacks.

• A salacious pic a tech billionaire doesn't mind if you see.

🗨️

Feedback Wanted: What's a source code anti-pattern you want to find?

At every company, there are standard ways to call internal frameworks and APIs. When you call them the wrong way, it can lead to a bug.

These code patterns may be hard to

grep

for (too noisy) but don't require the full power of slow, expensive commercial SAST tools.

My friend

and I are giving a

talk at ShellCon

about using open source tools to find these source code anti-patterns. For example:

• Find every time foo() is called where an argument is/isn't a hard-coded string

• What parameters do various controller methods care about?

Feel free to reply directly to this email with examples of patterns you'd like to find, and we'll cite you in the slides

💙

⭐️

DevSecCon Seattle 2019

Recently I was in Seattle for

DevSecCon Seattle

, which was a great con - nice venue, good attendee size (not too big, not too small), and a number of solid talks.

I'm on the DevSecCon program committee, so it was gratifying to see how all the effort we put in reviewing talks created a nice program

🤘

There were many great talks, but here are a few I want to call out.

Keynotes

opened the conference with a fun and engaging keynote about how security is everybody's job. She made everyone raise their hand and

promise that they worked in security regardless of their role (e.g. developer, project manager, etc.).

, author of the book

Securing DevOps

and manager of the Firefox Operations Security team at Mozilla (i.e. all the back-end services and infra), keynoted the second day (

slides + speaker notes

). Tons of good takeaways, including:

• Using data to justify to management to actually invest less in an area when other areas will have higher security impact. This can make sense after you've spent years investing in services and tooling that eliminate classes of problems.

• Check out the Mozilla services web security checklist for a nice baseline of security control expectations, written in Markdown, that Mozilla copies into a GitHub issue for new services.

• The Mozilla Rapid Risk Assessment is a ~30min lightweight threat modeling exercise that can be done with dev teams to determine the risk of a service.

• "Don't just build security tools. Build operational tools that do things securely."

• Clear expectations -> Checklist -> Self Assessment -> Profit.

• Some thoughts on the relative impacts of the organizational structure of dev and security teams:

-------------------------------

Secure Wrapper Libraries FTW

Morgan Roman gave an excellent talk (abstract | slides) on creating secure-by-default libraries and then ensuring their use via lightweight static analysis (aka grep).What's particularly great about this talk is Morgan's emphasis on the process of finding these security engineering opportunities and addressing them. He walks through 4 concrete examples of how this was done at DocuSign for Regex Denial of Service, XXE, open redirects, and SSRF.

Creating secure defaults / building a "paved road" (as Netflix likes to call it), is an emphasis I hear again and again from high performing security teams at various companies.

DevSecOps Panel

I moderated another

DevSecOps panel

with some smart friends from Netflix, Dropbox, Datadog, Apple, and Signal Sciences. I'll share a summary and the full transcript when the video is live.

If you just can't wait,

see here

for a summary of another DevSecOps panel I moderated at AppSec Cali 2019.

Continuous Compliance

Compliance can be a pain. Oftentimes it can be a checkbox-y activity that doesn't actually improve security. Instead, it involves documenting systems and processes in PDFs or Excel spreadsheets that become out-of-date as soon as they're made.

One interesting theme we saw through several talks is that some of the ideas and principles in Agile and DevOps can be applied to compliance (e.g. infrastructure as code) -- enabling compliance to be an easy, continuous state rather than a big effort quarterly or annually.

, a developer advocate at Chef, describes (

abstract

|

slides

) how you can use

InSpec

to specify your compliance, security, and other policy requirements in code.

• Similar to other config management tools like Chef, Puppet, Ansible, etc., you can say "the following files/directories/groups should exist," "the following packages should (not) be installed, "the following services should (not) be running," and roll these policies out easily to all of your servers and ensure that there's no drift over time.

• To be honest, it's not clear to me what value InSpec provides over the baseline features of any config management tool. Conceptually you could apply the same requirements via Puppet/Ansible or even baseline Chef.

• The real value here seems to be in the specific policies, which document useful security domain knowledge. dev-sec.io has some solid examples of hardened defaults for common software (e.g. MySQL, Apache, SSH, Docker, K8S) and OSes (Linux, Windows).

• You can see the source for the various hardening playbooks on GitHub.

of LifeOmic gave a talk (

abstract

|

slides

) on how development can still move fast in environments that must maintain HIPAA/HITRUST compliance. In this type of environment, all changes to production must be auditable/documented and every PR must have received peer reviewed and have been vetted by security scans.

• The change approval process used to be a bit painful and manual, but they automated aggregating the info required by compliance using a change management bot.

• Basically: Jira change management issue created -> webhook -> Bitbucket/Jenkins/Jira info analyzed -> updates the Jira ticket if required policies have been followed.

Erkang Zheng, the CISO of LifeOmic, also presented (abstract | slides) about some technology they've built that they've spun out into a start-up, Jupiter One.

The core idea is to represent all of your company's assets (people, teams, laptops, servers, code repos, PRs, AWS accounts, known vulnerabilities, ...) as nodes in a graph and have edges between them denoting relationships. This allows you to write graph queries that give you useful visibility into your assets as well as potential security issues. For example: 

If this idea sounds familiar, you're right! That's because Sacha Faust of Lyft gave a BSidesSF 2019 talk about essentially the same approach, and they open sourced their tool on GitHub: lyft/cartography.Another interesting idea from Erkang's talk is having security policy and procedure documents written in Markdown and stitched together with a config JSON file. Changes to these policies are then tracked via git and the info can be imported into the same graph DB for querying/relating to other aspects of your org. They've open sourced some templates on GitHub with mappings to HIPAA, NIST CSF, PCI DSS, FedRAMP, and CIS Controls.You can also manage your vendors as code (and thus include in the graph):

They've open sourced a number of their adapters on the Jupiter One GitHub page. You may find the secops-automation-examples and bitbucket-pr-detector repos useful.ReflectionsWhile I liked both presentations, overall I wish the InSpec and Jupiter One talks had been a little more, "here's a tough problem space, here's how we think about it and our mindset/methodology for addressing the challenges" rather than "here's our specific solution in detail." The former is more easily generalizable, allowing the audience to benefit from the talk's insights regardless of if they use the specific tools  described. 

🔗

Links

Guard

uses AI to read various site's privacy policies and gives them a letter grade for how they treat your privacy. They list the site's recent privacy scandals, summarize the main privacy threats discovered in the policy, and display the privacy policy with the sensitive parts highlighted in red.

Portswigger released an

interactive XSS cheat sheet

that lets you filter by tag, event type, and browser. At first glance, seems like the successor to the iconic

OWASP XSS filter evasion cheat sheet

.

• Gareth Heyes describes a number of the especially interesting examples he discovered using some automated fuzzing and manual probing in this blog post.

• See some slides about Gareth's XSS magic here.

Some

PoC

s from

of Rhino Security Labs: GCP cloud shell docker escape, getting AWS-owned AWS keys from AppStream, hitting the AWS Lambda runtime API with SSRF, and getting creds from the "disabled" AWS Glue metadata API.

Semmle, a static analysis company started by a few Oxford academics, was bought by GitHub (aka Microsoft) -

Semmle's announcement

.

• GitHub's announcement is quite interesting, because it hints at GitHub's vision of the future of secure software development and how their features support it - support for disclosure and private forks for fixes within the platform, Dependabot to find out-of-date dependencies, and Semmle to find bugs.

• Finally, a lengthy write-up about Semmle from a Google engineer on HN that was taken down but can be read in Google's cache here.

Apparently you can now

buy disinformation campaigns on the dark web

, it's not limited to nation states trying to influence elections (

cough 2016 cough

). What a time to be alive

😅

✉️

Wrapping Up

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

If you find this newsletter useful and know other people who would too, I'd really appreciate if you'd forward it to them

🙏

Thanks for reading!

Cheers,

Clint

|

P.S. As your reward for making it to the end, here's the salacious pic:

Known colloquially as "Bezos' balls," [0] the Amazon Spheres are two recently built enclosed botanical gardens in Seattle for Amazon employees to relax in, with some public space.[0] True story, I overheard two separate groups of locals refer to them that way.