Fall On Our Sword – ASW #158

Bug bounty programs inevitably come up when we talk about appsec issues. Just this past episode (ASW 157), John had a random thought about using escalating payouts for vuln classes as a means of driving behavioral change within an org's Security Development Lifecycle. In other words, what if the budget impact of payouts was more closely tied to whether common flaws were continually cropping up in a code base. We didn't get into details of how we'd model such a program, nor its pros and cons. But this week we have a chance to think about Facebook's move to essentially pay for patience of bug bounty hunters. Yet it could also be thought of as a "security tax" on both slow triage and slow remediation. It'll be interesting to see how this plays out and what behaviors it ultimately incentivizes. Is it cheaper to just pay for a delay rather than have to continually respond to "is it fixed yet?" queries? Would this be a good way to tie budget consequences to slow code fixes?

Threat modeling and security decisions are essential appsec practices. Yet for as common as they are, the variety of tooling for them varies from docs and spreadsheets to complex web apps. Here's a visualization approach that lands somewhere in between in terms of easy to use (loosely structured text) and informative (flow charts and directed graphs). However, what's even more important in this article is the motivation for building these trees. There's a nod to "Security Chaos Engineering" (which is free, but sadly behind a registration wall) and a prior article on security anti-patterns. Or maybe security way-too-familiar patterns because they represent not really bothering with security at all or following a security practice because everyone else is -- even if your budgets, environments, and threat models are completely different. Be sure to check out the much more detailed and insightful blog post, "On YOLOsec and FOMOsec", at https://swagitda.com/blog/posts/on-yolosec-and-fomosec/.

A heartwarming story of face meets computer, computer likes face, computer lets human in. However, this relationship status gets complicated when face meets USB camera, USB camera meets computer, and the computer ends up with the wrong human. It's a story with unexpected handling of picture frames that reminds us why security plus hardware needs a strong root of trust. The article is a preview of the researchers' upcoming Black Hat presentation, "Bypassing Windows Hello for Business and Pleasure". If you'll be attending the con, check it out.

Why have one machine vision article this episode when we could have two! Here we have an appsec angle of unexpected threat models from old technologies applied in new ways. Many games have cheating and fraud in their threat models, with various mechanisms for detecting suspicious processes or behavior. In this case, machine vision is doing the work of "helper" apps like targeting. While it might still lead to some suspicious behaviors, the technique is novel for the approach it takes in analyzing game events. If you're interested in the domains of machine learning and games, here's an article about using ML to beat Atari games without relying on a human demo or training sequence, https://venturebeat.com/2021/03/05/how-ai-trained-to-beat-atari-games-could-impact-robotics-and-drug-design/

As an update to the article notes, the "imminent" campaign is in fact current and ongoing. Normally the commentary for an article like this would be, "Have an asset inventory, have a patching program". The more interesting angle here is what do to with EOL software -- a situation shared by enterprise and IoT devices (and OT and enterprise IoT and all the combinations therein). So, how does an appsec team handle this from the vendor's perspective? Patch in perpetuity? What perverse incentives arise if backwards compatibility or systems with fundamentally weak designs aren't put out to pasture? What if device lifecycles were accelerated and only new systems got new patches?

The trend of end-to-end encryption in devices is slow, but rising. There's not much appsec depth in this article other than seeing a positive improvement to the confidentiality of user data and, importantly, the keys to encrypt that data.

This is a great article that goes far beyond the security advice cliche of "don't roll your own crypto" to point out *how* custom crypto can go askew. It's a great read that covers good encryption principles for readers who aren't experts.

Here's an article that might be our think-piece of the week. We try to avoid articles with questions as titles (the answer is usually obvious and usually "no"). We also avoid articles that sound like a deep thought, but that usually fall into Shakespearean "sound and fury, signifying nothing." So, onto the premise: The cloud offers many excellent resources for the security CIA triad. In particular, the secrets management and encryption systems, combined with strong IAM policies, make for excellent controls to address confidentiality and integrity. But there's always the letter A -- our poor friend availability, that's often neglected in threat models. This brings up the very first question, how does your appsec team cover availability in their threat models? With a followup sequence of: Who does the security team think is responsible for availability? Do they agree with the security team? The answers to these questions probably influence how you'd measure the risks described in this article.

While code comments may not seem directly related to appsec, they allow code to be easier understood, so people looking to understand and/or modify software have a better chance of not making mistakes. Also, writing good comments is a little like learning something by explaining it to someone else - as you write a comment in English or other non-programming language, you may realize that you missed a use case in the computer language.

Path traversal + code execution vulnerability was found in the javascript CDN in April of this year.