ASW #224 – Keith Hoodlet

Building security capabilities within an org is an engineering task. It may require specific domain knowledge in areas like authentication and authorization, but it also requires product management skills and metrics to determine whether features are worthwhile or effective.

This doesn't break new ground on attacking image classifiers, but it does provide an interactive example for learning fundamental concepts behind the attacks. It's a cool use of an interactive blog post -- a gist file that sets up a Jupyter notebook to experiment with machine learning.

Additional resources:

• Gist
• https://www.tensorflow.org/tutorials/generative/adversarial_fgsm

A proposed standard for describing and managing tenant isolation from cloud service providers. The high level concepts, such as hardening privileges or encryption or authentication, could serve as a reminder for areas to address within any software project.

Of course, it's also an anagram for CHEAP -- but it's going to be expensive to shift the industry towards naming conventions like this, as much as it's already expensive to go through the engineering necessary to attain strong hardening.

We avoided referencing this flaw for the last few months, but we can't escape 2022 without mentioning it one last time.

There's a quote from the article, "..an independent third party code review likely would have caught the vulnerabilities that led to Log4Shell, and such a review likely would not have cost more than $100k."

Even a secure default, where JNDI would be disabled, would have saved significant time and headache for all the orgs that needed to address this vuln in software that never used the feature. If there's one shift in appsec for 2023, I hope it's a recognition of "hardening guides" as anti-patterns and the introduction of secure defaults plus "de-hardening guides" -- I'm just trying to figure out a better name than de-hardening, unhardening, softening, and weakening. Naming things remains a hard problem in software.

This isn't a new article. It's one to think about going into 2023. The OpenSSF created a mobilization plan with a goal for investing in and securing open source projects by improving many practices.

One step was determining what critical projects are out there. Here's a rough list of a few possible candidates.

Another step was choosing to re-implement fundamental tools in memory safe languages. The Prossimo project has been investing in this area.

This year we'll highlight more resources for your appsec toolbox. They may be familiar tools with more than a decade of code behind them or something new. But they will be something that solves a problem and is good to have ready from the command line.

The Homebrew project is a package manager for adding open source tools to macOS (or Linux).

Use the brew command to list, review, add, and remove tools that either don’t come by default on your system or to get new versions of those that do.

Everything it does is well contained within its own directory structure. It won’t clobber any of your system commands.

As we cover more tools throughout the year, brew will be the best way for macOS (and Linux) listeners to follow along.

SASE (pronounced 'sassy') has become an industry buzzword, with companies claiming to be SASE compliant or have products that supported SASE. This article dives into a recent initiative by the nonprofit MEF to standardize SASE, which will lead to these cloud services being able to work together in a more streamlined fashion. Also of note is the Gartner analysis that SASE will be a trend to have significant impacts on infrastructure and operations in the next 6-12 months and that organizations may not necessarily "wait up" for standardization of SASE terms and procedures.

• Piggybacking off the announcement article of MEF introducing new standards for SASE (https://www.darkreading.com/cloud/sase-definition-still-cloudy-forum-proposes-standard), here is the actual framework proposed by MEF.

As per the document summary:

"This document defines a Secure Access Service Edge (SASE) Service Framework and specifies Service Attributes that need to be agreed between a Service Provider and a Subscriber for SASE Services, including Security Functions, Policies and Connectivity Services."

API Security is a hot topic while often being an organizational afterthought. Since API security is a relatively new discipline, gaps in logic abound, and developers and AppSec professionals are often left without clear guidelines and have to figure things out as they go along. Highlighting this issue is the insecurity of LEGO APIs, which Salt Labs have researched and discovered issues inside of, such as XSS.

As far as this relates to 2023 and beyond, according to research by Future Market Insights, The API security market is expected to grow 26.3% between 2022 and 2032. Gartner also estimates that attacks on APIs will soon become the most-frequent attack vector for Web applications, although it is unclear on how 'soon' soon is.

Exposed secrets are a big problem in public GH repos, with up to 1.7 million secrets available to the public. However, the scan tool available from GH to catch these secrets is a paid feature...until now! You will be notified of leaked secrets automatically as long as you enable this feature in GH's security settings.

Community is a powerful tool. Come join CISOs, red & blue teamers, AppSec pros, cyber enthusiasts, and novices in this online, moderated community. We have plenty of free courses, as well as regular community events. Full disclosure: I'm a moderator!

I thought this was a fun article to read on how two developers approach the same problem, but also as a thought experiment for how I could do similar with a coworker or friend. Always great to see somebody else's point of view on things!

Two of the vulns patched were disclosed by msft in November's Patch Tuesday. Serious question: Is it a good thing when your open source package so mimics a commercial version that it gets the vulns, too?

Technically, this is an interesting article to me - using the CI/CD constructs like GitHub Actions to deliver firmware updates to distributed microcontrollers.

But also - the idea of thinking ahead to realize that you'll have to perform updates on the microcontroller that you installed at grandma's really warms my heart.

While historically I've been a Kali Linux user, after a recent drive crash and re-installing my VMs, I found Parrot Security and decided to give it a try. To me, it feels a little cleaner and easy to use, compared to Kali. Haven't made up my mind to fully adopt it, but it's what I'm experimenting with over the holidays!