ASW #212 – Sam Placette

The very week that Uber's former CISO, Joe Sullivan, is in court over Uber's 2016 data breach, an alleged 18-year old hacker created a spectacle of the company's security practices. On a meta-level, it's been nice to see the majority of the industry response as having sympathy for the security teams responding to the incident, the pushback against marketing on top it, and the resistance to blaming any one user for the breach. On the appsec angle, we'll talk about hard-coded credentials, designing for "break glass" situations, the pros (many) and cons (some) of FIDO2 and WebAuthn, and the threat models you should -- and those you shouldn't -- bother with based on this breach example. Additional resources - https://www.darkreading.com/attacks-breaches/attacker-apparently-didnt-breach-single-system-pwn-uber - https://www.uber.com/newsroom/security-update/

This might be one of those articles that makes me unreasonably excited. It's great to see programming languages move towards explicit acknowledgment and ownership of security issues. The article mentions a lot of threat modeling, which hopefully focuses not only on the language's design, but the ways that programmers use, misuse, or misunderstand it. Ideally, this team will create more than just a "Secure Rust Checklist" -- we don't need more checklists. We need safe defaults, aggressive deprecation of functions or features that lead to insecure designs, and improved tooling for analyzing security mistakes.

Kelly Shortridge wrote a detailed, insightful article about the recent NSA supply chain guidance (we covered it last week in episode 211). She sees it as flawed, with contradictory messages and recommendations likely to remain forever aspirational. It's a good reminder that any guidance out there, whether multi-page PDFs or OWASP Top 10 lists, is useful to inform a security program, but that a program has to be well planned and have milestones that show how it delivers value. More specifically, it also means that some guidance either isn't helpful at all (which the article argues is the case for much of the supply chain doc) or that it requires context about the org -- where context, like "it depends", is the magic word that shows just how much of a subjective art appsec remains.

Cool news for folks into C++ nerdery (and users of Chrome, who will benefit from this work). In short, the MiraclePtr is a design solution for an entire class of memory safety issues in the heap. It doesn't reach the safety guarantees of Go or Rust, nor is it a wholesale replacement of every raw pointer within the codebase. But it is a welcome design improvement and the type of solution that can make future code or new projects much safer. Plus, bonus points for a security mechanism that also helps identify bugs.

One of our friends from Enterprise Security Weekly, Adrian Sanabria, shared this article with us. On the surface, it might not seem to have a direct connection to appsec. Yet we've mentioned Netflix many times when talking about paved roads, DevOps, and SRE approaches to application design. Plus, this is an article about developer incentives and careers. Not only should appsec teams be having similar discussions about compensation, career growth, and team compositions, but teams should also build an understanding of organizational dynamics, incentives, and how large changes -- whether engineering levels or engineering security hurdles -- impact an org.

As a parallel to the other Netflix article this week, here's one from a former Netflix infosec leader about building teams.

Another article on this week's theme of careers. In this case, it's highlighting the ongoing failure in orgs to pay fairly, leading to a gender gap in compensation. Katie Moussouris hasn't been alone as a subject to this, having sued Microsoft for their practices. She has turned that into a broader effort to highlight the reality of the problem and demand changes like transparency in compensation and actions that orgs can take to reduce bias in hiring, negotiation, and pay.

Neat idea to diff heap snapshots between two browser states. I wonder where else this can be used in security R&D

So GPT3 now allows us to converse with a bot in English*, but also to manipulate what the bot does/says in English, as well. * I'm sure for things like the huggingface models, this can work with other languages, as well...

...how long until it leads to system compromise?

The kernel peeps have been busy in recent weeks, working on better approaches to retbleed. Call Depth Tracking works by putting traps that break the speculation execution just far enough away that some speculative execution happens, but not enough to make the capability useless.