Smart Lock and Simple Vulns, Macros and Secure Defaults, Breaches and Costs – ASW #206

I tend to skip over XSS. It's a flaw that's been around forever and feels like there's little new to say about it. This example doesn't add to any new aspect, but it's worth a reminder that the flaw persists despite modern frameworks, scanning, and decades of awareness campaigns. If there's one new discussion point to tease out of this ancient topic, it'd be a question about how old this flawed code was -- was it relatively new and therefore a new mistake, or old code that's been missed or skipped by increased security attention?

Grabbed this one for its range of mostly software and a few hardware vulns identified by NCC Group. The list of vulns has several classics, like stack overflows from parsing and DoS, that are frustrating to see in modern apps. So, regardless of whether you're building an IoT device or writing C code, revisit your security architecture around parsers. One of the flaws relates to the "invite keys" functionality, which is essentially a way to share access to the lock. The researchers discuss potential threats with exposing secrets to the system's servers vs. preserving them client-side. That also touches on the more universal challenge of balancing user experience with secure designs.

We need more secure defaults. It took decades for Microsoft to disable Office macros by default, followed by an on-again-off-again spectacle in the last few weeks. It's always great to see metrics that can reinforce the security success of switching to a hardened default. I look forward to the day where we deploy software and occasionally have to refer to "unhardening guides" to enable a few, rarely used features. Until then, we'll be stuck with default configurations and PDFs with double-digit pages of hardening instructions.

We've already covered some of the bumps in npm's enforcement and adoption of 2FA for its ecosystem. One item I hadn't noticed before that felt worth highlighting was their effort to maintain backwards compatibility. If I were to use this as a very (very, very) broad strokes example of appsec vs. DevOps, I'd consider a framing like: Appsec says 2FA has to be rolled out; DevOps says here's how to enable 2FA in 10 lines of code. That's a pretty reductive summary, but the idea is to try and highlight the difference between just mandating "more security" and putting in the up-front development work to make adopting "more security" easier. GitHub and npm discuss this at https://github.blog/2022-07-26-introducing-even-more-security-enhancements-to-npm/

We haven't talked about specific breaches in a while and, while we covered the Verizon DBIR a few months ago, we talked about the appsec attack vectors, not the costs. When you craft threat models, how often do you talk about records or the costs, value, or fines associated with records? When is it useful to include? When is it a distraction?

Phil Venables shared a list of his most popular posts along with his personal favorites. His most popular one was about a year ago -- https://www.philvenables.com/post/cybersecurity-and-the-curse-of-binary-thinking One of his favorites was from almost two years ago and got about 1/10th of the views -- https://www.philvenables.com/post/the-uncanny-valley-of-security-or-why-we-might-never-finish-anything I don't have any grand insight to share on this disparity, but I do find it interesting to read through posts like that and think about what makes something stand out more to the reader or the writer. Helpfully, Phil shares his perspective on each one of the posts.

????