1. How to Build a Developer-First Application Security Program – 12:30 PM-01:00 PM
Do you have a specific guest or topic that you want us to cover on one of the shows? Submit your suggestions for guests by visiting https://securityweekly.com/guests and completing the form! We review suggestions monthly and will reach out to you once reviewed!
Developers ignore security issues. But can we really blame them? After all, security folks bombard them with an endless stream of issues that need to be addressed with no way for them to separate what’s actually critical from all the noise, all while they are expected to release software more frequently and faster than ever before. It makes sense why developers view security as something that just gets in their way and slows them down. To make application security easy, we must make it developer-first. This is the future of AppSec.
Don’t miss any of your favorite Security Weekly content! Visit https://securityweekly.com/subscribe to subscribe to any of our podcast feeds and have all new episodes downloaded right to your phone! You can also join our mailing list, Discord server, and follow us on social media & our streaming platforms!
Join us April 14th to learn how to monitor your wifi network for attacks with Nzyme, a free and open source wireless intrusion detection system, with Lennart Koopmann, hosted by Larry Pesce and Paul Asadoorian. Then, join Alan Stacilauskas and hosts Tyler Robinson and Paul Asadoorian on April 21st to learn how to gain visibility into your enterprise with SYSMON. Live attendees at both of these webcasts will have the chance to win a $100 Hacker Warehouse gift card! Register at securityweekly.com/webcasts. Don’t forget to check out our library of on-demand webcasts & technical trainings at securityweekly.com/ondemand.
In the AppSec News: Okta breach, fuzzing Rust find ReDos, SQL injection and the age of code, Log4j numbers paint a not-pretty picture
While the breach may have impacted over 300 of Okta’s customers, it also seems to have led to over 300 articles written about it. Here’s a sampling of additional items on the topic:
– https://www.philvenables.com/post/insider-threat-blast-radius-perspective-updated — This is in fact from August 2020 and not specifically about the Okta breach, but it’s a great summary of how to approach mitigating the type of threat demonstrated by the breach.
Rust patches sneaky ReDoS bug – As much as we love advocating for languages that address classes of vulns, specifically memory safety issues, we’re just as empathic about pointing out that there are plenty of other security issues beyond buffer and heap abuse. This flaw in Rust could lead to a local DoS via a user-supplied regex. It’s not necessarily the most exciting flaw, nor is the type of flaw new. What is relatively new is how fuzzing is being used to identify these types of issues. It’s great to see investments in fuzzing produce meaningful improvements to software security.
Be sure to read the Rust advisory as well at https://groups.google.com/g/rustlang-security-announcements/c/NcNNL1Jq7Yw
But there’s another aspect of this article I wanted to call attention to that’s independent of the C code and CPU details. The article uses several graphs to demonstrate data collected during the analysis and a set of simpler graphs to demonstrate the underlying concept of race conditions. Visualizations like these can be really effective at enriching text and help readers understand complex topics. If you’re working on your own write-ups about vulns, flaws, recommendations, or any metrics, strive to include simple, well-designed visualizations to help tell your story.
Which is the angle I wanted to take with this article — lots of infosec articles like to include metrics like CVSS scores (a perfect 10!), the number of times an app is downloaded on a weekly basis, or how many results for an app comes back from a tool like Shodan. These are rough indicators of popularity and impact, but rough and often with too many confounding variables to be of any real uses other than to paint a picture of “this is an important vuln”.
On the other hand, I’d be curious to see metrics for vulns related to age of the code base, such as date of the commit that first introduced the vuln, date of the last commit to the affect file, and date of the last commit to the affected repo. To me, those can build a picture of how well maintained the codebase is and whether security tools — if they’re being run at all — are providing quality results.
NSA, CISA release Kubernetes Hardening Guidance – NSA and CISA first released this hardening guide back in August 2021 and have now released an update based on industry feedback. We covered the first release, with the sentiment of, “This is great work, but wouldn’t it be nice if a hardening guide consisted of a single page that said to use the default configuration?”
That sentiment still stands; it’d be great for hardening guides to shrink as default secure configurations expand. Even so, if you’re not familiar with kubernetes security, reading a hardening guide like this is a great introduction to important concepts. The guide includes a lot of the “why” a hardening step is useful, which helps the reader gain more knowledge about the design assumptions of kubernetes rather than just being a dry checklist of steps to go through.
Infographic: Log4Shell Vulnerability Impact by the Numbers – I’m highlighting this article to talk about the aspect of log4j as an indicator of the state of appsec, patching, and app inventories. The technical aspects of log4j aren’t as important for this discussion. What’s really scary — and something to remember as we talk about the best modern tools and DevOps approaches — are observations like 50% of installations impacted by log4j were flagged as end of support. The cloud isn’t immune, with Qualys detecting 68,000 vulns in cloud workloads. If there’s one metric that feels like a positive trend, it’s that the average remediation time was 17 days. I’d love to know more about this remediation metric, such as what the median time was and if there was a distinction in remediation times between applying a patch vs. having up update a dependency.
Towards Practical Security Optimizations for Binaries – I’ve always been a fan of compiler-driven security improvements, especially the various sanitizers that LLVM makes available for compile-time and run-time analysis. And I’ve always been suspicious of “clever” code that attempts to outsmart a compiler or that’s written for the compiler to understand better than a human reading it. But it’s also important to realize when compilers are working against you, such as the classic “dead code” that just zeroes memory — when zeroing memory is in fact important for scrubbing secrets. This is a great article that lays out specific recommendations for improving the state of compiled binaries.