Who Has the Keys?

Episode transcript

Transcript provided for accessibility and search. Minor transcription errors may remain.

Opening and introduction

SPEAKER_00 0:02

Each week we break down the biggest cybersecurity stories: emerging threats, new technologies, and the changes that matter to you. What happened, why it matters, and what to do next. This is What Matters in Cyber with your host Steve.

What matters this week

SPEAKER_01 0:19

Hi, I'm Steve, and welcome to the first full episode of What Matters in Cyber. Each week, I want to look at a handful of stories and ask a simple question: what actually matters here? This week, a stolen key for a shopping app became a route into customer information. A medical device company shared more about a cyber attack that disrupted its operations. The US government signaled a change in how it wants organizations to think about patching, and a major security vendor launched a new way of using AI to find weaknesses before attackers do. Those sound like four separate stories. To me, they connect around one idea. Knowing where your risk really is, especially when it sits just outside the systems you directly control. Let's start with the stolen key. Imagine

A stolen app key exposes customer information

SPEAKER_01 1:04

you run an online store. You use a commerce platform, and you add a third-party app to improve the shopping experience. That app needs permission to connect to your store, so it gets an access key. Then someone steals the key. That's the basic shape of the ribbon incident involving stores that use Big Commerce. One affected retailer, Master of Malt, published an unusually clear account of what happened to its customers. According to the retailer, someone used a stolen key belonging to the Ribbon app to download customer information on September 13th. The key was disabled on September 17th, and the retailer learned about the breach on September 18th. For its affected customers, the information included names, email addresses, and where provided phone numbers and addresses. Master of Malt says passwords and payment card numbers were not taken. That's an important distinction. It doesn't make the incident harmless. Names and contact details can make a scam message much more convincing. BigCommerce has said the credentials belonged to a third-party app and that its own platform was not breached. It also said the stolen credentials were used to inject malicious scripts into a small number of storefronts, and that it removed the affected apps and notified merchants. Master of Malt has described customer data being downloaded from its store. Those are different parts of the reported activity, and the app developer's investigation into how the key was stolen is still ongoing. Here's my take. The most useful question isn't which company's logo to put next to the word breach. It's who could see the misuse, who could stop it, and how quickly the people carrying the customer relationship found out. Master of Molt says it could not see that the app's key was being misused while the download was underway. It says the developer or platform had the ability to disable it, and the retailer found out after the key had already been revoked. The retailer has since said it is reviewing other app permissions and adding alerts for unusual access. That sequence is familiar to anyone who has managed a large technology environment. A business team installs an integration because it solves a real problem. The integration gets permissions. Months later, the organization remembers the product, but not necessarily the exact access it has or who is watching that access. The practical question for listeners is straightforward. Could you name the outside apps that can read customer records? Change your storefront or add code to it? Could you tell which keys are active? What each one can do, and who gets alerted if a key starts downloading data in bulk? I'm not suggesting every business needs an elaborate new program this afternoon. I'd start with an inventory of those connections, review their permissions, remove the ones nobody needs, and agree with your providers on how a suspected compromise gets reported and a key gets shut off. Those are manageable questions, even if you never use the phrase supply chain security in a meeting. For the rest of us as customers, the immediate risk is a message that seems to know us. If a store tells you your contact details may have been exposed, be wary of emails or texts that push you to sign in or pay through a link, go to the store directly. The broader lesson is that a trusted connection is still a route into your business. Trust has to include visibility and a way to act when something goes wrong. Now to Boston

Boston Scientific and the cost of disruption

SPEAKER_01 4:15

Scientific. This story began in August, so why bring it up this week? Because on September 22nd, the company published an update that gives us a clearer picture of what investigators found. Boston Scientific says the threat actor entered through an external facing network device and reached a limited part of its on-premises IT environment. Its update says investigators found no evidence of continuing attacker activity after containment measures on August 25th. It also says they found no evidence of compromise in the cloud applications, manufacturing maintenance systems, product development systems, or medical device maintenance systems that the company named. According to the update, investigators found no evidence that customer or patient data was accessed or taken from those systems. That is reassuring. And we should say so. We should also be precise. No evidence in the systems examined is the company's reported finding. It isn't a claim that every question about the incident has disappeared. Even with those findings, this was a serious operational event. The company has described disruption to parts of its business, including order processing and shipping, and has warned that the incident is likely to affect its 2026 financial outlook. For me, that gets at something we sometimes miss when we talk about breaches. We tend to ask, was data stolen? It's an important question. But a company can face real consequences when systems it relies on become unavailable, even if an investigation does not find stolen customer data. Think about the chain of work behind a medical product reaching the people who need it. Orders have to be received. Inventory has to be visible. Products have to move. Staff need working systems. If a disruption affects any of those steps, the response is about more than restoring a server. My take is that recovery plans should be tested around the work the business needs to do. Can you accept an order? Can you ship? Can your people tell customers what's happening? Do you know which processes need to return first? Those answers matter at least as much as the date a dashboard goes green. And one more thing, a clear public update helps customers and partners make decisions. Boston Scientific September 22nd update says they may safely continue normal business activities and system connections. That kind of specific reassurance is useful when it is backed by an investigation and limited to what the investigation actually found. If you work in security,

Which vulnerabilities should we fix first?

SPEAKER_01 6:39

you know the feeling of opening a vulnerability report and seeing more urgent items than your team could possibly fix this week. Here's a small change with a bigger meaning. Kizer says it will discontinue its weekly vulnerability bulletin on September 28th. The agency says the change reflects a move away from sorting work, mainly by severity scores, and toward the risk a vulnerability presents in the real world. It will continue to publish its known exploited vulnerabilities catalogue and security alerts. Sizer also added a flaw affecting Zixel GS 1900 series switches to that catalog on September 21st, citing evidence of active exploitation. That doesn't mean every listener owns one of these switches. It does mean that if your organization does, you should establish where it is, whether it is exposed, and what the vendor says to do. The bigger point is about priority. A severity score can tell you a flaw might be dangerous. It does not tell you that attackers are using it against systems like yours, whether the vulnerable system is reachable, or what an attacker could get to next. My take, the patching conversation should start with three questions. Is it being exploited? Do we have it? Especially where an attacker can reach it? And what happens if it is compromised? That sounds obvious, but it changes how a team spends Tuesday morning. A high scoring issue buried in a test system and an exploited issue on an exposed device should not automatically sit in the same queue just because they both have alarming numbers beside them. This is not an excuse to ignore other vulnerabilities. It's a way to direct limited time towards the ones most likely to hurt you first. CISA's new federal directive applies to federal civilian agencies, but the decision process is useful well beyond government. For non-technical listeners, here's the translation. Security teams have an enormous to-do list. Better information about what criminals are actually using helps them choose the right first job. And finally,

Can AI find the weaknesses that matter?

SPEAKER_01 8:39

a technology story. Palo Alto Networks announced a service this week called Unit 42 Continuous Frontier AI Defense. The idea is to use several AI models along with its security specialists to test applications, identities, cloud environments, and other assets for weaknesses and possible routes an attacker might take. The company says the service can validate whether a weakness is usable and help teams decide what to fix. It reports strong results from its internal testing and customer engagements, including finding exposures that did not have a known vulnerability number. Those are the vendors' claims, and results will depend on the environment and what a team does with the findings. My reaction is strongly positive. Security teams already have scanners and long lists of findings. If these tools can find a realistic path through several individually small mistakes, then help people close that path faster. That's a meaningful improvement. I particularly like the move toward continuous testing. A system isn't secure once and for all, because it passed a test in March. New code goes live, permissions change, a supplier adds an integration, someone makes a reasonable decision under time pressure, and the environment changes again. Of course, there are questions to ask before buying a service like this. What access does it require? How is your data handled? Who confirms the findings? How are fixes assigned to the people who can make them? And after three months, can you show that serious exposures were closed faster? Those aren't objections to AI. They're the questions that turn a promising tool into a useful one. I would rather see a team remove ten credible attack paths than celebrate a thousand new findings in a dashboard. That distinction connects back to our first story. If an AI testing service spots an overly powerful third-party key, but nobody owns the permission or the response plan, the finding alone doesn't protect the customer. Discovery matters because it gives us a chance to act.

Closing: The question to ask your team

SPEAKER_01 10:39

So, what matters in cyber this week? A stolen app key shows why we need to understand the access we give outside providers. Boston Scientifics update reminds us that cyber incidents can disrupt the work people depend on, even when the investigation finds no evidence of stolen customer data in the systems it examined. CISO is pushing teams to focus on exploitation and exposure when deciding what to fix first. NA-driven testing may help defenders find the attack paths that traditional lists miss. If I were asking one question of my own team this week, it would be this which connection or system could cause the most trouble if we lost control of it? And would we know quickly enough to respond? I'm Steve, and this has been What Matters in Cyber. If you have a story I should cover or you disagree with my take, I'd like to hear from you. Subscribe for the next episode, and I'll see you next week.