In the segment Mike and Caroline will discuss Risk Tolerance and Risk Transfer. They’ll touch on the following: risk ranking, risk transfer in supply chain, how to diversify security controls, time vs risk reduction vs vulnerability exposure all from a DevOps perspective. While also touching upon how security is not (and should not) be a gate.
Caroline Wong – Chief Strategy Officer at Cobalt
Caroline Wong is the Chief Strategy Officer at Cobalt. As CSO, Caroline leads the Security, Community, and People teams at Cobalt. She brings a proven background in communications, cybersecurity, and experience delivering global programs to the role. Caroline’s close and practical information security knowledge stems from her broad experience as a Cigital consultant, a Symantec product manager, and day-to-day leadership roles at eBay and Zynga. Caroline also hosts the Humans of InfoSec podcast, teaches cybersecurity courses on LinkedIn Learning and has authored the popular textbook Security Metrics, A Beginner’s Guide. Caroline holds a bachelor’s degree in electrical engineering and computer sciences from UC Berkeley and a certificate in finance and accounting from Stanford University Graduate School of Business.
Co-founder & CTO at Cysense
Product Security Lead at Square
2. ChaosDB, OpenSSL String Bugs, Revealing Locations, & More Top 15 Vulns – 01:00 PM-01:30 PM
InfoSec World 2021 is proud to announce its keynote lineup for this year’s in-person event! Hear from Robert Herjavec plus heads of security at the NFL, TikTok, U.S. Department of Homeland Security, Stanford University, and more… Plus, Security Weekly listeners save 20% on world pass and main conference registration! Visit https://securityweekly.com/isw2021 to register now!
Security Weekly Unlocked will be held IN PERSON this December 5-7 at the Hilton Lake Buena Vista!
We are excited to announce our speakers: Lesley Carhart, John Strand, Alyssa Miller, Dave Kennedy, O’Shea Bowens, Marina Ciavatta, Patrick Coble, Chris Eng, Eric Escobar, Nick Leghorn, Michael Schladt, Kevin Johnson, Justin Kohler, Jay Beale, Trenton Ivey & Ryan Cobb!
This week in the Application Security News, Mike and John talk: Flaws in Azure’s CosmosDB, OpenSSL vulns in string handling, dating app location security, cloud security orienteering, detailed S3 threat model, & more!
ChaosDB: How we hacked thousands of Azure customers’ databases – Researchers discovered how to abuse a flaw in Azure’s deployment of Jupyter notebooks for their CosmosDB environment that enabled them to access arbitrary databases. It’s a particularly unfortunate vuln because the underlying choice of using Jupyter is a good one — it’s a way to have consistent, well-configured, auditable, and interactive access to datasets. The technical details still haven’t been revealed, but it looks like a topic worth keeping an eye on to learn how to better protect and isolate cloud resources.
Here are some additional links to check out:
Big bad decryption bug in OpenSSL – but no cause for alarm – We’re back (unsurprisingly…sigh) into the land of C and memory safety issues with a pair of bugs in OpenSSL. The silver lining is that they’re apparently difficult to exploit — one is in an algorithm created by the Chinese government that few are likely to use and the other in ASN.1 parsing that fortunately doesn’t have easy attack vectors. There’s still some useful general lessons to take from this situation. One, disable features you don’t need. This is probably an under-appreciated aspect of supply chain security, where recompiling binaries to remove unneeded features reduces your attack surface. The catch is how much engineering time you have to ensure you haven’t removed or disabled features that a rare code path in your app needs.
The other lesson is a callback to last episode when we talked about the programming minefield that is ASN.1 parsing — it’s been a notorious attack surface for decades. And, in this specific case, it’s a lesson in assumptions when crossing implementation boundaries where C-style strings are expected to have a NULL byte terminator and ASN.1 strings have a length field, but no guarantee of NULL terminator. In other words, it’s a mismatch across APIs in terms of “what does a string look like” for APIs that have different rules. This is similar in spirit to the glibc vuln that we also discussed last episode, where the expectation for NULL pointers differed between two APIs.
Check out the OpenSSL advisory and technical details at https://www.openssl.org/news/secadv/20210824.txt
Vulnerability in Bumble dating app reveals any user’s exact location – This is a good example of the impact of appsec on the safety and user experience of an app. It’s easy to focus on technical details of vulns and exploits, or focus on privacy issues, but threat models should also take into account user interactions and how app features might be abused to target users in unwelcome and unexpected ways. Another thing that stood out from this article was the robustness of the fix, not only did Bumble address the location precision and hashing issues, but they improved the app logic to “prevent you from matching with or viewing users who aren’t in your match queue”. It’s nice to see a more concrete example of business logic issues and how they’re addressed.
Check out similar research on the dating app Tinder at https://robertheaton.com/2018/07/09/how-tinder-keeps-your-location-a-bit-private/
If we took a step back and queried this through a lens of appsec architecture, some bigger questions might be: Are these app’s designed in a way that make them harder to secure by default? (Hint: WordPress core seems relatively secure; it’s the plugin model where it falls down.) Or, what makes these apps more difficult to patch?
The more detailed report is at https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/linux-threat-report-2021-1h-linux-threats-in-the-cloud-and-security-recommendations
Cloud Security Orienteering – Here’s an article from the TL;DRsec newsletter that’s rich in its overview of cloud security principles and its links to detailed resources. You’d be well served if all you did was use it as bookmark to other material (and, well, read and implemented the recommendations in that material — so set asides lots of time).
For the more time-pressed readers or those looking for more actionable advice, there’s a companion checklist you can find at https://tldrsec.com/blog/cloud-security-orienteering-checklist/
The last S3 security document that we’ll ever need, and how to use it – Here’s another doc highlighted from the most recent TL;DRsec Newsletter (https://tldrsec.com/blog/tldr-sec-098/). But at 163 pages, it’s possible the S3 security document that you’ll never read as opposed to ever need. The doc’s length and the data flow diagram on page 3 make the “Simple” in Simple Storage Service suspiciously something other than simple. But it’s also likely that the doc could be distilled to simple steps of 1) block public exposure of S3 buckets by default at the account level, audit IAM for least privilege, choose an encryption strategy that matches the sensitivity of the data stored (whether default encryption for the bucket or per-object encryption with a client-managed key).