You’ve Got Appsec, But Do You Have ArchSec? – Merritt Baer – ASW #250

(If this looks familiar, it's because we had it in last episode's news queue. We ran out of time to cover it, but there were some still-relevant points I wanted to highlight.)

I've been a long-time fan of Clang and LLVM. Its various analyzers are immensely helpful for discovering and fixing issues that lead to bugs and security flaws.

This article highlights the desire of researchers who want to work more directly through the compiler toolchain, such as reviewing and manipulating the AST in order to find all sorts of security issues. (In fact, the analyzers work on the CFG, not the AST -- which I didn't realize.) It points out how Clang is optimized to optimize code and serve developers, but it doesn't have all the features a security researcher would want.

But if you don't care about compiled code or the few acronyms in this summary have already thrown you off, think instead about the development toolchains you currently use and how well they can be instrumented for security purposes.

There are ideas and structure in here that could apply to a company's approach to security awareness and the digital literacy and resilience of its employees.

Here's our second security strategy from the U.S. government this week. Once again, the guidance feels directionally effective and something that companies can use to inspire their own programs.

More car hacking! This time with a more consumer-focused angle reminiscent of the John Deere agricultural vehicle hacking we covered back in April with episode 237.

Keep an eye on the researcher's BlackHat presentation this week. We'll follow up with any fun updates.

WebSocket pentesting can be a pain. It can tunnel arbitrary protocols, many of which aren't text-based and therefore aren't human-friendly for reading and manipulating data.

There's not too much new in this article that we haven't already covered in the last few months. So I'm just going to use it as a reminder that choosing Rust for new projects is far more likely to be successful than attempting to rewrite existing code that lacks memory safety into Rust.

And I'll also use it to must on headlines and framing. Rust has better default security for memory safety -- that alone is a great benefit -- but it is just as prone to all the Top 10-style vulns that plague web apps. It'll be wonderful to reduce the amount of vulns that stem from memory safety, but there'll be plenty of other vuln classes to deal with. Hopefully we'll discover better ways of addressing them than just relying on security awareness through top 10 lists.

In related news, Rust released a tool "to build a graph database of dependencies and invocations between all crates within the crates.io ecosystem."

Find the code at https://github.com/rustfoundation/painter

This goes into the cool research, but don't worry about revising all your threat models.

It might also be a departure point for us to talk about directions in cybersecurity research and what it looks like in academia vs. industry.

I like how this research generated adversarial attacks not by clever prompt creation by humans (which can be a fun way to explore LLMs), but by creating an adversarial prompt that takes advantage of the LLM's underlying model. To roughly explain the idea, the attack relies on crafting prompts that trigger the paths of probability that string together responses that the LLM owners would otherwise like to suppress -- think offensive words or similar "jailbreaks".

One of the points we try to emphasize in security awareness and secure code training is to be relevant -- both in programming language as well as being topical. Using old examples from 20 years ago might be interesting from a history of appsec (or a slightly cynical show of how little progress appsec has made). On the other hand, pulling examples from headlines and from software that developers are familiar with can increase their curiosity and engagement. With that in mind, here's a chance to talk about Minecraft and deserialization attacks.

Zap has made some noises over the years about not being totally happy at OWASP, and now they're announcing that they are moving to SSP and two of the core developers will be on payroll.

I mention here for zap users to know "hey where'd zap go?!" and also as we've talked about issues at OWASP several times.

(h/t Akira)

This is mostly a cloud-security story, but there's an appsec aspect, I think: When you create a tool, how do you control when it is used for good vs bad?

On the crypto side of things, Lexon is a language designed to read/write like a "normal" human language. I bring it up here for the discussion: Will this improve appsec?

h/t Coin Telegraph

Interesting story coming out of Pacific Northwest National Lab: Some of their staff were looking to improve DOS detection/response. They turned to look at how entropy changes in a network between normal users browsing a website vs a DOS attack. They found a solution much more compute-efficient and easier to understand/manage than training a ML algorithm.

One of the problems orgs can have is tracking the non-code parts of an application - who wrote something, why, who is supporting/"owns" the app, possibly what code is actually being used. On the other hand, perhaps you're looking at a code repo, but are not sure if/when/where it was deployed?

Crash Override's attempting to address this by releasing Chalk, a soon to be open source (grrr don't develop "open source" in closed environments) tool to annotate git repos and releases in a standardized way to make answering these questions easier.