Categories
Artificial Intelligence Security Video

Watched a Black Hat interview on AI supply chain security and it’s NetFoundry’s report’s findings, but from the opposite direction

Here’s a video that isn’t from the place where I work (NetFoundry), but from someone works in a different part of AI security. Yet somehow they ended up at the same question that we at NetFoundry ask: How confident are you that your current tools can defend against the new threats brought about by AI?

The video features an interview that took place at the recently-concluded Black Hat 2026 in Las Vegas, and the interviewee is Daniel Bardenstein, CEO of Manifest Cyber.

While NetFoundry focus on identity-based security, Manifest’s focus is on the AI supply chain:

  • Manifest’s approach to security is knowing what’s actually inside the models and software you build and buy. They’re paying particular attention to provenance: training data you didn’t source, open-weight models pulled from a public hub, what’s “under the hood” of your agents.
  • NetFoundry approaches AI security from the other end: what’s outside the models and software you build and buy, and what’s allowed to reach it. We’re about machine identity, service-to-service access, and attack surface.

Watch the video; it’s got some notable stuff, including:

  • Open-weight adoption is about to accelerate, and the reason is control. Bardenstein argues that with a frontier model you have zero control over the system prompt, the training data, or what some provider (or government) decides to change under you. With an open-weight model, you control the whole chain: prompt, data, deployment, guardrails. If you’re already self-hosting models behind OpenZiti, this is the security-side justification for it, from someone who isn’t us.
  • The Hugging Face incident he describes is darkly funny. A lot of people say that the risk with AI models is that they’re non-deterministic, but the HF situation happened because the sandboxing was weak and guardrails  (which really means “ordinary software security”) were missing. Then, when HF pointed its own AI at the forensics, its guardrails read the request as “too cyber” and refused to help,. HF had to fall back to an open-weight model.I’m going to start saying this regularly: AI fails like software because it is software!
  • “AI has its own supply chain and you inherit it.” Every model off a public hub and every third-party dataset is a dependency you didn’t build and can’t fully vet. Bardenstein notes public datasets have shipped with everything from PII to, in documented cases, outright illegal content nobody caught until after training. As the people on the Antiques Roadshow TV show will tell you, provenance is important.
  • The Log4Shell framing is the one I’d steal (in fact, I’m doing that right now). Bardenstein built Manifest after the Pentagon Log4Shell vulnerability (a.k.a. CVE-2021-44228) scramble. The issue boiled down to a simple, embarrassing question: “Where is this one piece of code running across everything I’ve built and bought?” Even having seen what happened five years ago, if you told a CISO a model or dataset was poisoned, they’d likely not be able to tell you where it’s deployed, who owns it, or which vendors are affected without a lot of phone calls, emails, spreadsheets, and gnashing of teeth.

Bardenstein’s observations are pretty much the mirror image of our recently-published 2026 State of Secure AI Access report, where we observe that:

  • 99% of CTOs/CISOs at orgs with 1,000+ employees admit they lack full visibility into their AI deployments.
  • 54% named new AI-specific services like MCP servers and LLM gateways as fresh attack surface.
  • 8% think their identity systems are sufficient for non-human workloads.

Pair our observations with Bardenstein’s supply-chain point and the full failure mode is bleak. An agent you can’t identify, running a model you didn’t vet, reaching services over credentials nobody rotates. That’s three unknowns stacked on top of each other.

My read (not Bardenstein’s or NetFoundry’s report’s) is that giving an agent its own OpenZiti identity solves the “reach” half of the problem. You know what the system or service can talk to and every log line means something.

What it doesn’t do is handle the composition half, or to put it another way, it doesn’t account for what’s inside the thing you just handed an identity to.

Two separate disciplines that happen to share a root cause: You can’t govern what you can’t see, whether “it” is a network path or a model’s provenance.

Categories
Artificial Intelligence Reading Material Security

Security leaders we surveyed feel pressure to secure their AI, and almost none of them feel ready

Here’s a fun little contradiction to start your week with: NetFoundry asked 200 CISOs and CTOs whether they feel pressure to secure the AI they’re deploying. Unsurprisingly, and to my considerable relief, every single one said “yes”.

We then asked how confident they are that their current tools can actually handle the new risks, and 15% said “very.” 15% is very slightly less that the odds for rolling six on a 1d6. More specifically, among the CISOs, whose entire job is to be the professional pessimist in the room, that figure dropped to 10%.

That’s the current situation: Universal pressure, near-universal doubt.

If you just want to get to the report, it’s here. But if you’d like to know more, read on…

Disclaimer and where the survey comes from

I work at NetFoundry as a developer advocate, and NetFoundry commissioned this report. So yes, this is a vendor survey, and you’re correct to raise an eyebrow. (I’d be worried if you didn’t).

In our defense, we did the thing you’re supposed to do: the survey itself was run by an independent research firm (Global Surveyz), the respondents were 200 US-based security and technology leaders at companies with 1,000+ employees, and it was fielded this past May and June.

I’m going to try and separate what the survey found from what I think it means. The first category is data. The second category is me, a guy on the internet, having opinions, which won’t always be the same as NetFoundry’s Marketign department (it happens). I’ll flag which is which.

The number that reframed the whole thing for me

Of everything in here, this is the one I keep coming back to:

Security leaders are nearly 10x more likely to worry about securing machine-to-machine workloads than human access to applications.

Specifically: 69% said machine workloads (service-to-service, API-to-API, agent-to-whatever) are where they’re least confident today. Just 7% said human user access. The remaining 24% said “both equally,” which I read as “please don’t make me pick.”

That tracks perfectly, and it’s a compliment to the last decade of security work. Think about what we spent the 2020s doing. COVID sent everyone home, remote access became the whole ballgame, and the industry poured an enormous amount of money and brainpower into VPNs,  Zero Trust access, and all sorts of security measures for a world that was suddenly more online that ever. It worked, and hman access to applications is, comparatively, a solved-ish problem. We got good at authenticating people. (I should know; it was during that time that I worked at Auth0!)

The issue of identity

The catch is that all of that machinery is built on one quiet assumption: that the thing connecting to your app is a human being with a unique identity. You authenticate the person, then you grant the access.

My late former coworker, Vittorio Bertocci, has forgotten more about identity than I will ever learn, and he was starting to look very deeply into identity in the age of AI.

Agents and models don’t work like that. They don’t have identities the way humans do. So the tooling we built for the last problem doesn’t cleanly transfer to this one, and the volume is going the wrong direction, fast. Machine traffic is now growing several times faster than human traffic year over year. We got really good at guarding a door that fewer and fewer of the visitors are actually using.

A few more stats worth your attention:

  • 100% agree their attack surface is growing. Not a plurality. Not a strong majority. Everyone. The average projected increase was 14% over the next 12 months, and that figure only counts AI deployments already underway or planned. 14% is probably the minimum.
  • 93% are concerned about the new risks AI introduces, but only 15% are highly confident their current tools can handle them. That’s the gap I opened with. When the level of concern and the level of confidence are that far apart, something structural is going on.
  • 99% admit they don’t have full visibility into their own AI deployments. That remaining 1%, which would have to be one respondent? I would like to buy that person a coffee (or beer! or bourbon!) and ask them a lot of questions.
  • 90% are worried about shadow AI, the unsanctioned tools employees adopt on their own because the approved options don’t cut it. This is not a technology problem, it’s a human-nature problem. I will neither confirm nor deny my own contributions to the shadow AI at previous organizations, but in my defense, I was getting things done! When a tool is genuinely useful, people use it, memo or no memo.
  • Only 8% call their current identity systems “very sufficient” for non-human workloads. 85% are now actively evaluating or exploring new approaches. That second number is the tell. When five out of six organizations are shopping for a new approach at the same time, that’s teh surest indicator that the industry is collectively coming to the realization that the existing tools weren’t built for this.
  • Oh, and it’s slow. 55% cited risk and compliance review as a top contributor to delays in the network changes AI deployments need, and those changes add an average of 8 days from request to implementation. And that’s now, while AI-specific scrutiny is still warming up.

My read (this part is me, not the data)

In this section, I’m switching from reporting to speculating.

I think almost every number above traces back to one root cause: machines don’t have real identities. They have internal names so that developers and devops people can talk about them, but when it comes to having reasonably canonical identities like we humans do (full name, usernames, an email address, a government-issued unique ID number), we haven’t really created these for machines.

In the absence of machine identities, we have workarounds. On the less secure end, we have IP addresses; on the (relatively) more secure end, there are shared secrets, API keys, long-lived service-account credentials. As with most workarounds, they quietly rot. The credentials we give machines tend to carry more permission than they need. They rarely get rotated. After a while nobody’s entirely sure which agent a given key even belongs to, or why it exists.

Once you’re in that world, everything downstream gets harder. Visibility is hard because you can’t tell one agent’s actions from another’s. Access control is hard because a secret isn’t an identity, it’s some piece of data that happens to belong to a robot (and all too easily duplicated). Auditing is hard for both of those reasons at once. The identity gap is the root problem of most of the other security problems in the AI age.

NetFoundry — who are made of some very smart people, a few of whom are literal greybeards! — obviously has opinions about how to close that gap, and the report gets into them. That’s the vendor part, and you can take it or leave it.

In case you saw the em-dashes in the paragraph above and thought “Aha! AI!’, I assure you that I typed them in myself, because this is my relationship with AI:

Entering em-dashes is dirt simple on macOS: option-shift-minus. On Windows it’s a little more work: alt+0151. On Linux: control-shift-U, then release and type 2014, then return/enter.

Let me have just a couple of em-dashes in my article. Please.

But strip the logo off and the underlying observation stands on its own: we spent a decade giving humans strong identities and largely ignored the machines, and now the machines are the fastest-growing thing on the network. That bill was always going to come due. It’s just arriving faster than most people planned for.

The stat I want ask you about

That 14% attack-surface increase feels low to me. If you’re actually running agents in production right now, watching them spawn sub-agents and reach across cloud boundaries and pick up new tool integrations every sprint, does 14% over a year match what you’re seeing, or is it wildly optimistic?

(That’s a genuine question, not a rhetorical one. I’d rather hear it from people living it than trust my own gut.)

Read the full 2026 State of Secure AI Access report!

Download it here. (You have to provide a little info to get it.)

Categories
Security

[Video] OpenZiti 2.0: Securing the Management API With Zero Open Ports

Clint (who among other things, does all sorts of OpenZiti development and co-hosts Ziti TV with me) recently posted a video, OpenZiti 2.0: A Management API With No Open Port.

It’s a quick but deep dive prompted by a great question over on our Discourse forums: “What’s the service configuration for the hosts part when using identity?”

Short answer: there isn’t one. No host.v1, no tunneler hosting it.

The core idea: in 2.0+, the controller is the hosting app. Give it an identity and it binds the service itself. There’s no separate tunneler, no host config. That’s the whole trick behind darkening an API you’d normally have no choice but to expose.

What the demo does: starting from a fresh 2.0.2 quickstart, Clint splits the controller’s APIs across two web listeners. The edge client and OIDC APIs stay on the public listener (0.0.0.0:1280). The management API gets no internet-facing port at all! It’s bound to the controller’s own Ziti identity and reachable only over the overlay by identities authorized to dial it. Then he proves it three ways: over loopback, with the ziti CLI over the overlay, and with a plain curl through ziti-edge-tunnel.

Before you try this in your own lab:

  1. The intercept hostname has to be in the listener’s server cert. Recreate the server cert to include the intercept name (management.z in the demo), or the ziti CLI won’t connect over the overlay.
  2. The edge-oidc snag. The moment you split listeners, edge-oidc’s auto-binding will bite you. It’s tracked in openziti/ziti#4185. If you’d like confirmation you’re not losing your mind, there’s a matching Discourse thread from folks whose ziti edge login broke on 2.0.0 right after a split.

Resources:

[ This article also appears in r/OpenZiti. ]

Categories
Security

The best way to secure a public API might be to make it unreachable

It’s a completely counterintuitive concept, but that’s the thesis of API Gateway Security: A Zero Trust Approach, an article we just refreshed on the NetFoundry blog.

Read the article here: https://netfoundry.io/devops/api-gateway-security/

It’s written by Tod Burtchell, Associate Director Service Planning & Development in Management & Operations Platform (long title, dude!), whom I had the pleasure of meeting at a planning meeting last week.

Most API security spend goes into inspecting inbound traffic (WAFs, rate limiting, an API gateway parked out front), and all of it inspects traffic that has already arrived at your infrastructure. The exploit is already inside the door even before the door can do anything.

The general gist of the article leans on NetFoundry CEO Galeal Zino’s earlier article, Squaring the Circle: How to Make Public APIs Private, where he describes APIs as “snowflakes”. They’re snowflakes in the sense that they’re always changing, and each change quietly opens a new attack vector that signature-based defenses haven’t seen yet.

The tl;dr: Hardening the front door is one thing, but why not remove it instead? Picture and API with outbound-only connections, no listening ports, and identity-and-auth before anything connects. As a result, the API stays usable for the people who should reach it and is simply invisible to everyone else. OpenZiti is the open-source plumbing underneath if you want to see how it actually works.

I thought I’d make another “back of the envelope” diagram showing the difference between the usual way of building APIs, and the OpenZiti-powered outbound-only approach.

Once again, here’s the article: https://netfoundry.io/devops/api-gateway-security/

[ This article also appears in r/NetFoundry. ]

Categories
Artificial Intelligence Security

Two doors an attacker loves, and one they can’t find

I drew the illustration above on the back of an actual envelope (one of my new “things” these days). It’s either the most or the least appropriate medium for a diagram about attack surface. Your call.

It’s here because my colleague Mark Jaffe — NetFoundry’s Chief Strategy and Marketing Officer — just published an article called MCP Is Spreading Through Your Enterprise at Developer Speed. Your Security Architecture Isn’t, and it makes a point that I think is worth more than a link-and-a-shrug. So I illustrated one of its key ideas the old-school engineer way, because you’ve probably seen enough AI-generated images and need to look at something a little more human.

Read the article: https://netfoundry.io/ai/mcp-is-spreading-through-your-enterprise-at-developer-speed-your-security-architecture-isnt/

You’re probably seeing this happening around you: teams are wiring AI agents up to their CRMs, databases, and internal APIs through Model Context Protocol servers, because MCP makes it easy. What almost nobody is asking, and what security teams usually can’t even see, is whether the way they’re connecting those servers is quietly creating a new attack vector. In most of the deployments NetFoundry runs into, it does.

The cartoon is Mark’s “before and after,” in three panels. The first two are how nearly everyone connects an MCP server today. The third is what he argues you should be doing instead.

1: Public MCP (a.k.a. “door open to anyone”)

You publish the MCP server on a public hostname, stick a load balancer in front of it, and rely on an API key or an OAuth token to authenticate the agent.

If that gives you déjà vu, it should. This is the exact pattern we all used for REST APIs back around 2012, and it carries the exact same flaw. The server is reachable by anyone on the internet who can enumerate the endpoint or get their hands on a credential. It has to be reachable, because the agent needs to find it. Which means so does everybody else.

That’s the evil bot in the corner going “poke poke.” He doesn’t need to be clever. He just needs the door to exist.

2: Jump host inside (a.k.a. “one session pivots to all”)

“Fine,” you say. “We’ll keep everything internal. Run the agent on a jump host or a dedicated VM inside the network, nothing exposed to the public internet, problem solved.”

Except now you’ve traded one problem for a subtler one. That agent is the thing that’s calling an external LLM, ingesting user-supplied prompts, and taking actions across a dozen connected tools. It’s also now sitting on a trusted internal segment with network-level reach to systems far beyond what it actually needs. Compromise a single agent session and you’ve got a pivot point. One hop to the CRM, one hop to the database, one hop to the internal APIs.

That’s the middle panel: the agent with arrows fanning out to everything. One session pivots to all of them.

3: Outbound only (a.k.a. “don’t call me, I’ll call you”)

Here’s the fix, and the almost annoying thing about it is that it isn’t new. It’s the same outbound-only, identity-bound, least-privilege model that zero trust has been asking for all along. What’s new is applying it to the one connection (agent to MCP server) where none of your existing controls (firewalls, WAFs, network segmentation) actually operate.

The MCP server lives on a private subnet with no inbound connectivity. Instead of the agent reaching in to find the server, the server dials out to meet the agent through an authenticated, encrypted tunnel. There’s no public address to enumerate, no port to probe, nothing sitting there waiting to be found.

Or, as my little pencil agent puts it: don’t call me, I’ll call you.

That line did more work in one speech bubble than a paragraph of my prose could, which is a humbling thing to learn from a robot you drew yourself.

The part that isn’t about doors at all

The panels are the fun part, but the argument I’d actually push you to sit with is why this isn’t just an API-gateway problem wearing a new hat. Mark lays out three things MCP changes that break the old assumptions:

The client is autonomous. An AI agent doesn’t just call an endpoint. It decides which endpoints to call, in what order, with what parameters, based on reasoning you can’t fully predict or constrain up front. So your attack surface isn’t “the MCP server.” It’s the full action space of every tool that agent can touch, across every session it runs.

The session context carries risk. MCP servers receive the agent’s reasoning context right alongside its tool requests. If an attacker can inject content into that context (prompt injection in a document the agent reads, a poisoned result from an earlier tool call, a malicious server the agent got pointed at) they can influence the next tool call in the same session. The MCP connection is the channel that influence travels down.

The inventory is invisible. Most organizations have no systematic way to know which MCP servers their teams have already stood up, which agents are connected to them, or what those servers can reach. If “shadow API” gave you a twitch a decade ago, meet shadow MCP. It’s the same problem, but building up considerably faster.

That speed is the whole thesis, really. The API security industry got the better part of ten years to retrofit controls around a pattern it shipped before it fully understood. MCP is running the same curve compressed into months. Nobody’s getting ten years this time.

So what do you do with this?

If AI-agent security is landing on your desk right now, the uncomfortable truth in Mark’s piece is that the architecture decisions your developers are making this quarter are the ones that’ll be expensive to unwind later. A dev who wires an MCP server to your production CRM through a public hostname isn’t making a temporary choice. They’re setting the pattern every future agent deployment quietly copies.

The good news is that the fix is boring and well-understood. Outbound-only. Identity bound to the connection. Every session governed and observable. Panel 3, basically.

Go read the whole thing! It’s about an eight-minute read and it’s sharper than my envelope.

Categories
Developer Relations Humor Security

I might have been in cybersecurity and DevRel a little TOO long…

Most people would probably respond to these “Menthole XXtreme” Dude Wipes with these responses:

  1. Ewww! What is wrong with people?!
  2. Cool! Mint, brah!

But my first thoughts were:

  • Networking/cybersecurity: Now that there are menthol wipes to do “for the other end” what breath mints do for the mouth, there’s now end-to-end mintiness.
  • Developer relations/marketing: That’s clever; why compete in someone else’s category when you can create your own?
Categories
Conferences Security Tampa Bay

Notes from BSides Tampa 13: “Dealing with Shadows” or “A day in the life of a threat actor negotiator”

If you’ve been anywhere near a screen this month, you saw the Canvas breach unfold in real time, where the ransomeware group known as ShinyHunters dropped a “rooting your systems since ’19 ;)” page onto the dashboards of nearly 9,000 schools during finals week. Instructure papered it over with a “scheduled maintenance” message that even the most gullible saw through. A few days later, they ended up paying the ransom in exchange for “shred logs” and a pinky-promise that no customers would be extorted further.

So when I sat down in a packed room at BSides Tampa 13 this past Saturday for a talk titled Dealing with Shadows: A Day in the Life of a Threat Actor Negotiator the timing felt less like a conference session and more like a debrief.

The speaker was Matt Barnett, CEO and co-founder of SEVN-X, a Pennsylvania-based cybersecurity firm. Matt spends his working hours talking to criminals on the dark web on behalf of clients whose systems have just been encrypted, whose data has just been exfiltrated, or  frequently both. He was joined onstage (in spirit, anyway) by his colleague Dave Zofran, who Matt repeatedly tried to make wave at the audience and who, in the great tradition of every backstage engineer at every conference ever, was having none of it.

This was easily one of the best talks of the day. Matt is jokey, sweary, self-deprecating, and irreverent, and the audience stayed well past the scheduled end for a Q&A that ended only because it was time for the closing keynote and raffle for Chris Machowski’s amazing BSides posters. Here’s what I took away.

“My career is a series of clerical errors”

Matt opened by describing his career path as “mostly an annoying inability to say no to things.” Somebody asked him if he wanted to do physical penetration testing. Sure. Forensic analysis school? Sure. Want to talk to criminals on the dark web? Hell yeah. Do you know what you’re doing? Not a clue. We’ll figure it out.

He compared himself to Jim Carrey in Yes Man, which he claimed was autobiographical. As somebody whose own career has been driven in no small part by saying yes to the next weird thing (DevRel, accordion-on-stage, organizing meetups, writing this blog for two decades), I felt seen.

Before getting into the meat of it, Matt did a room survey: students, IT folks (“the unpaid group, maybe the underpaid group”), cyber pros with one-to-five years (“the unjaded ones, because you still believe you can make a difference”), and the over-fives (“the unbothered”). Then he asked if there were any vendors in the room, and offered them the mic. Nobody took him up on it. They know a trap when they see one.

Myth-busting: paying ransoms, double-dipping, and “why does this exist?”

Matt opened with a couple of myths he wanted to put to bed.

Myth number one: Paying ransoms is illegal. Nope. Some payments are illegal, specifically payments to entities on the OFAC sanctions list, which is why you don’t want amateurs handling the wire. Ransom payment as a category is not, in itself, against the law.

Myth number two: You don’t always get what you pay for. Mostly false, with caveats. Double and triple extortion happen, but in Matt’s experience, they’re typically different groups exploiting the same unpatched Fortinet firewall (a refrain that came up roughly every six minutes during the talk; more on that in a moment), and not the original group going back on its word. Reputable ransomware crews are, weirdly, reputable, and that’s because their business model depends on it.

There is, however, no certification body for what Matt does. He has a GCFA, meaning that he’s a certified forensic analyst, but there’s no such thing as a certified-ransomware-negotiator credential. He quoted Jon DiMaggio (whom he says everyone calls ”Joe”) on the state of the field: nobody can really tell you whether you’re good at this job. You learn it the way Jason Statham’s character in The Mechanic learned his trade: “Good judgment comes from experience, and a lot of that comes from bad judgment.”

And on the moral question of “Why do negotiators exist at all? Doesn’t paying ransoms just feed the system?”, Matt invoked Tony Stark from the first Iron Man (alas, he’s no fan of the sequels): “It’s an imperfect world, but it’s the only one we got. The minute we don’t need threat actor negotiators anymore, I will build bricks and beams for baby hospitals.”

The ransomware industry is, in fact, an industry

Probably the most important reframe in the talk (and one I’m going to be repeating to people at NetFoundry and at Tampa Bay AI meetups) is that the mental image of “ransomware operator” most non-security people still carry around is wildly out of date.

The kid in his mom’s basement, surrounded by cold pizza, while she yells about meatballs? Not a thing anymore. Or more accurately, never coming back to a screen near you. Modern ransomware groups are full-on enterprises with:

  • Ransomware developers
  • Initial access brokers
  • Software and codebase maintainers
  • AI specialists (yes, really)
  • Web devs building the victim portals
  • Customer service / “help desk”
  • Translators (or rather, prompt engineers driving Google Translate and Claude and ChatGPT)
  • HR. HR.

“I don’t know if they have benefits,” Matt said. “The minute they have benefits, I might consider a career change.”

These aren’t lone actors. They’re businesses, and in many cases they’re tacitly or explicitly protected by their host governments because the money flowing back into their towns and villages props up local economies. As Matt put it: they’re heroes where they live. Which is one of those facts about the modern threat landscape that you have to sit with for a minute before you can keep going.

The shift to enterprise has changed everything about negotiation strategy. The old groups sometimes had a moral compass; for example, there was a group that would hand over decryption keys for free if they realized they’d accidentally hit a hospital, and another that announced they were retiring after they hit a billion dollars and then actually published a master decryption key on their way out. Those days are over. Today’s groups operate on margin and SLA, like any other B2B company. They just happen to be in the extortion vertical.

“Why use a negotiator?” Because you know everyone at your company.

Here’s a part of the talk worth keeping in mind should you find yourself or your company at the mercy of a ransomware organization.

Matt asked how many of us had worked at our current job for more than a year. Then more than five. Then more than ten. Then he asked the ten-plus hands: do you have kids? Because if you do, you have worked with these people longer than your kids have been alive. You know your coworkers better than you know your spouse, your friends, sometimes your own children.

Which means when your company gets ransomed, you’re most likely not going to be a calm, collected, rational actor. You’re a person watching your work-family bleed out, and you will do dumb things because of it. This is exactly why, in hostage negotiations, local PD will bring in officers from another jurisdiction the moment they realize anyone involved knows anyone involved. Emotional distance is the whole point.

A negotiator isn’t there because they’re smarter than you. They’re there because they don’t know your accounts receivable manager who just had her first kid, and that distance is, perversely, a gift.

The other thing negotiators bring is pattern recognition across hundreds of cases. There are really only two companies in the U.S. that actually facilitate ransom payments because it’s a risky line of work. Matt didn’t name them, but they’re not hard to find, and the negotiators who work with them have visibility into asks, settlements, durations, and outcomes that no individual victim can possibly have. Which brings us to the data.

Ransomware company discount curves

Hey, actual numbers!

Matt put up actual data from the last 12 months of facilitated payments. I’m reproducing the highlights here because they’re genuinely useful for anyone thinking about cyber insurance, incident response runbooks, or just calibrating their understanding of the threat landscape.

Akira (traditional / technical, business-oriented group)

  • Average initial ask: ~$1.3 million
  • Average settled payment: ~$429,000
  • Average discount: 60–70%
  • Average duration: ~20 days

Qilin (pronounced “CHEE-lin”; it’s Chinese and denotes a magical creature close in spirit to a unicorn or magical giraffe)

  • Average initial ask: ~$800,000
  • Average discount: ~62.5%, but with a hard floor around 50%
  • Tighter statistical clustering than Akira

ShinyHunters (the new kids; social engineering and help desk scams)

  • Much higher initial asks
  • Average discount: ~71%
  • Much shorter duration. Matt called it “almost like a fire sale.” I like to think of them as the TJ Maxx or Ross of malware.

The shape of the discount curve is the interesting part: time on the x-axis, percent off on the y-axis, and the curve goes up and to the right. Like buying a car, except the dealership is in a sanctions-adjacent country and the test drive is your production environment.

A practical consequence: if you’re paying for recovery (your systems are down, you’re hemorrhaging money), you pay faster and you pay more. If you’re paying for suppression (they didn’t encrypt anything, they just exfiltrated data and are threatening to leak), you can drag it out for a bigger discount. Which is exactly what we just watched happen with Canvas — Instructure ultimately paid for suppression and “shred logs,” not recovery.

The Black Basta “I had COVID” story

The single best war story of the talk involved Black Basta about a year and a half ago. The Black Basta victim portal, Matt said with what sounded like genuine professional admiration, is gorgeous. Looks like iMessage. Read receipts. Tight UX. “I wanted to send a meme. It doesn’t support that. The first ransomware group that allows GIFs [in their chats] is gonna be a work of art.”

But at the top of the portal: a countdown timer. Six days, twenty-three hours, fifty-nine minutes, fifty-eight seconds. Tick.

Matt was working a real case, was actually going to pay, and needed to stall. So he asked for more time. They gave him seven days. He asked again the following week. Seven more days. He was feeling pretty pleased with himself when, on the Friday of week three, they finally said: no more extensions. Pay or else.

Then Matt got on a flight home from Denver to King of Prussia, PA (which, as he pointed out, sounds like a Batman villain, as does his other hometown, Wayne, and look, I lived in Wayne; I can confirm it sounds exactly like the kind of place Bruce Wayne would buy a second house). He proceeded to get deathbed sick. Lost an entire weekend. Woke up Monday morning with roughly forty hours left on the clock and a portal full of increasingly unhinged messages from his criminal counterparts: “Are you there? Hello! I’m serious. Don’t make me do what I’m going to do.”

Matt typed back: “Really sorry, I got super sick. I think I had COVID.”

They gave him seven more days.

Matt’s rules of engagement (lightly paraphrased and worth tattooing somewhere)

He’s a flat-fee operator. Never a percentage of savings — because at that point you’re not a negotiator, you’re a co-conspirator with a conflict of interest. (The two negotiators who got federally indicted for actively colluding with ALPHV BlackCat are the cautionary tale he doesn’t want to become.)

He will lie to criminals with abandon, but he won’t lie to clients.

He won’t negotiate in bad faith. If you tell him “just stall, we’re never paying a dime,” he walks. Because he’s seen what happens when threat actors realize they’ve been strung along. He told a story about a client that changed their mind at the last minute after a long negotiation. The group responded by publishing pediatric patients’ Social Security numbers on Facebook. One. At. A. Time, in a slow, painful, drip campaign.

He does not hack back. He has heard of illicit activities waivers. They take two to three years to get and they are not a Get Out of Jail Free card. They are, at best, a “you probably won’t go to jail” card.

He does not facilitate the actual payment, because (a) money laundering, (b) OFAC compliance is a specialty unto itself, and (c) the two payment-facilitation firms have current data on which Bitcoin addresses and chat fingerprints map to which sanctioned entities. He just does the talking.

The four things he wants from every threat actor

When Matt’s at the table, he is always asking for the same four things:

  1. The decryption key. Of course.
  2. Proof of deletion. Typically a screenshot, ideally a video. He has an eight-hour video of someone DoD-wiping a drive somewhere in his archive.
  3. How they got in. No guarantees on how honest they’ll be; sometimes ransomeware operators will literally copy-paste from a different victim’s report. Matt and another negotiator once compared notes and got the exact same “you had a Fortinet firewall” attribution for clients who, respectively, ran Meraki and Cisco.
  4. A promise to never do it again. Worth roughly what you’d expect, but worth getting in writing.

If he can get those four, he’s done his job.

Q&A

The Q&A ran long. A few highlights:

Where do ransomware group names come from? Matt blames CrowdStrike. Honestly, fair. “Every cool t-shirt you’ve ever gotten from Black Hat came from the CrowdStrike booth.” I jumped in to point out that Qilin (pronounced “CHEE-lin”) is a Chinese mythological creature usually translated as “unicorn” or, more delightfully, “magic giraffe.”

Is ransomware seasonal? Absolutely. American holidays, especially Thanksgiving, are target-rich, because skeleton crews and four-day weekends mean defenders are slow to respond. Attackers also take vacations themselves. Ransomware drops off in the summer months. Because who wants to be at their computer when the weather’s nice? Even criminals deserve a beach day.

Are you ever personally targeted? Matt’s whole career is built around not announcing himself as a negotiator on the live chat. He plays the dumb IT guy. He’s got a story about a colleague suggesting they ask the threat actor what a “botcoin” is (after one of them mistyped “Bitcoin” in a chat), and the threat actors spent two days patiently explaining cryptocurrency to him. “Best time stall ever.”

What about emotional toll? Matt has been a paramedic, a cop, and a firefighter. “I don’t know of a crisis I haven’t run head-first into. It’s a programming defect from up top.” Then: “Better living through pharmacology. Oh God, don’t call my therapist.”

What industries get hit hardest? Manufacturing. Not necessarily the most often, but the hardest, because of legacy systems. He told a story about a Pennsylvania university that literally cemented a Novell NetWare box into a basement wall during construction because it was running directory services and they didn’t want to unplug it. It’s been running since the ’80s. It’s still there.

Why I’m writing this up

Two reasons.

One: BSides Tampa is a regional con and the speaker quality this year was outstanding. Matt’s talk in particular deserves a wider audience than the room it ran in. It could’ve been a keynote.

Two: I spend most of my professional life right now thinking about zero trust and AI-plus-network-security at NetFoundry, and what Matt’s talk drove home (better than any threat report I’ve seen lately) is that the human layer of incident response is where most of the leverage is. You can do everything technically right at the perimeter and still lose a six-figure negotiation because somebody on your team panicked, told the truth at the wrong moment, or said the magic words that flipped a transactional extortion into a personal vendetta. Zero trust as a philosophy (not just a product category) is partly about acknowledging that humans will always be the soft target, and designing accordingly.

Also: I am now permanently delighted by the idea that every ransomware negotiator on the planet should adopt the alias “Matt” so that threat actor groups go forever convinced that U.S. companies are staffed by an army of identically-named slow-witted staff who don’t know what Bitcoin is. Matt, if you read this, I’m in. Sign me up.

Big thanks to Matt Barnett and SEVN-X for an outstanding session, and to the BSides Tampa crew for putting on one of the best regional security cons in the Southeast!