Good People – ASW #186

Yes, another bit of marketing about how much a company has spent on bounties. (We covered Google's VRP and its $8.7M payouts in 2021 two episodes ago.) Overall, having bounty programs that build collaboration with researchers is a positive thing. The quick stat here is that Salesforce's $2.8M payout for 4,700 vulns works out to an average of ~$600 per vuln. It'd be interesting to know what the media payout was. The other side of these programs that we haven't seen reported by organizations is the money and time invested in fixing these vulns. Does Salesforce or Google (or any other program) track the time or costs associated with fixing vulns? Do they conduct postmortems on whether a vuln could or should have been found by internal tools? Was a vuln easily found by a tool that a researcher ran that the org should have been running? For more mature programs like Google's, it's more likely that these vulns stem from clever manual analysis. But in any case, we'd be curious to understand the different trade-offs in investing resources in bounty programs vs. investing in development tools and processes -- after all, this latter part is where the open source ecosystem is currently struggling. Read the announcement from Salesforce at https://www.salesforce.com/news/stories/why-salesforce-paid-hackers-2-8m-in-2021-to-break-into-its-products/

It's cool to see a framework, even one as simple as a git repo, for collaborating to improve CVE write-ups and recommendations. It also might (emphasis on might) be a model for curating cloud vulnerabilities -- vulns in configurations, services, or older versions within cloud service providers' environments. That's something that wiz.io brought up and that John has talked about in an episode or two. Read GitHub's announcement at https://github.blog/2022-02-22-github-advisory-database-now-open-to-community-contributions/ Find the wiz.io discussion about the need for tracking cloud vulns at https://blog.wiz.io/security-industry-call-to-action-we-need-a-cloud-vulnerability-database/

We're still in the timeframe of "year in review" articles about 2021. This is a good summary of security around industrial control systems and operational technology -- the non-consumer side of embedded systems. One thing that stands out is how the quality of advisories leaves plenty of room for improvement. According to the review, 38% of advisories had incorrect data, 24% had not patch available and of those with no patch available 19% didn't even include mitigations. This quality of vuln information and guidance on patches and mitigating controls falls squarely onto an appsec role. It's an interesting metric to consider for the industry as a reflection of how well it is -- or isn't -- serving its customers.

This might only be the second or third mention of WordPress in the past two years. Typically, stories about yet another flaw in a WordPress plugin are generic, far too common, and far too unsurprising. The core WordPress remains relatively secure, but its plugin architecture too easily exposes the system to high-impact vulns. This article stood out because it's about a tool and process to identify classes of vulns that appear in WordPress plugins. For example, rather than launch a bounty to go after these kinds of vulns, having a tool like this helps the approach scale better and to be a self-serve mechanism for plugin developers. That's the kind of evolution we love to see in the appsec space. Check out the repo at https://github.com/kazet/wpgarlic

The initial content on this link is deceptively simple: securing how software is built. Then you dive into the white papers it's based on and you realize how complex and how much effort goes into security a CI/CD pipeline. Even if you're not using many of the CNCF projects noted in the reference project (or even if you don't even recognize some of the names), the principles behind this are universally applicable. A few key items that stand out are deploying MFA for all developers (with FIDO2 keys only), using short-term SSH certs/keys for access to repos and prod systems, and requiring signed commits are just simple starters for securing some of the human element in creating software. Then there's the software integrity and authenticity validation throughout the build and deploy steps. And then there's the third-party security that includes SBOMs and SCA. Read the related white paper at https://docs.google.com/document/d/1FwyOIDramwCnivuvUxrMmHmCr02ARoA3jw76o1mGfGQ/edit

We're always interested in finding more educational resources on basics of appsec, software development, or modern toolchains. Here's a group of lectures and freely available resources that touches on each of those topics.

One of the challenges in high-level security recommendations like the OWASP Top 10 is that cryptographic failures can be subtle. At a glance, Samsung made good cryptographic choices like using AES-GCM, but then made a fatal mistake of reusing IVs. This highlights an area where subject matter expertise and careful analysis is extremely important. It's one of those chances where even appsec practitioners should be comfortable saying, "I don't know" when they approach a topic and search out experts who can apply the scrutiny necessary to review foundational cryptographic components. Read the research paper at https://eprint.iacr.org/2022/208.pdf

Appsec is not even close to the central part of the story in the Ukraine conflict. It's important to keep that perspective in mind when considering what areas of appsec, if any, might be relevant to the conflict and protests. Social media platforms like Twitter and Meta (Facebook) have provided guidance to users for protecting both the security and privacy of their accounts. This is important for individuals fleeing, reporting, or protesting within Ukraine or high-risk areas. This is when personal threat models can suddenly change and individuals need tools to protect themselves, whether it's via secure messaging or protecting their profiles. When companies reach these scale of users and become tools within these situations, it's their responsibility to understand how to best enable users to protect themselves on these sites and make those capabilities simple to understand and implement. In that respect, appsec becomes relevant in terms of threat modeling, establishing security requirements, and having clear communications. Here's another Twitter thread on steps Meta provides for protecting profiles: https://twitter.com/ngleicher/status/1497417241947607043

Interesting to see this getting covered in a non-industry publication (although Slate Future Tense is their emerging tech sub-platform). Part of this is how the numbers are being reported, and partially the malicious actors are getting better at bypassing 2fa