THE ECHO

One story. Gone deep.

"I'm sorry to say that the attackers had access to your name, email address, phone number, and address."

That's Justin Petszaft, the founder of Master of Malt, an online whisky shop in the UK, telling customers what happened. Passwords and card details were stored separately. They weren't exposed.

The shop wasn't broken into. Neither was the platform it runs on. BigCommerce put it plainly: "This was not a breach of Commerce systems or the BigCommerce platform."

The company behind one of the shop's add-ons was. Ribon is an app the shop had installed to improve the shopping experience. To do that, it was given a key to the shop's customer information. The key was taken when Fastr, the company behind the app, was broken into. For five days, September 13 to 17, someone used it to pull customer information "page by page," until the key was shut off.

Think about how a store like that gets built. You make one careful decision, early: which platform to run on. You compare a few, and you choose. Then, over the years, somebody clicks install on smaller things. Each one has a job. Each one gets a key. Every one of those keys sits at a company you never evaluated, never met, and couldn't name.

You chose the store. You didn't choose who else would be holding the key to it.

And it isn't only stores. The apps that work inside your email, your sales system, your accounting. Each one holds a key like this one.

Who turned it off? Not the shop. The platform turned the key off, pulled the app out of the affected stores and told the shops. That's the good version of this story, and it depended entirely on somebody else.

Now look at who signed. The key was held by someone else. The break-in happened to someone else. The apology went out under the founder's name.

The shop did nothing unusual. It installed an app to do what the app is for. When it went wrong, it told its customers plainly and reported it to the UK's data protection regulator.

You can outsource the key. You can't outsource the apology.

You don't need to understand how the key works. You need to know who holds it, and who can turn it off.

Start with what's already there. Ask whoever runs your store, your website or your IT: when the company behind one of these gets broken into, who turns its key off, and who tells us?

If the answer is "the platform does, and here's how," good. If the answer is "we'd probably see it in the news," then nobody does, and now you know.

That isn't a question about the person who runs your IT. Asking it makes you a better client, not a suspicious one.

Then the next install, which matters more than the last breach. Two questions, before the button. What does it get to see? Who can turn it off?

Ask those two every time, and you've done the part of this story that was always yours.

The details are from reporting by BleepingComputer, SecurityWeek and The Register, September 21 to 23, including statements from the shop and from BigCommerce.

SIGNAL CHECK

What else matters this week.

The Call That Came From Your Own Number

Astrana Health, a large healthcare company, told the SEC on September 23 what happened. People pretending to be its own staff called its employees, and the caller ID showed the company's main phone number. The company says information was accessed or taken, and that it may include patient, employee and business records.

This doesn't need a big company. At yours, everyone knows the main number, and nobody thinks twice when it shows up on their phone. That's why the trick works.

Caller ID tells you what number to trust. It doesn't tell you who's calling.

Ask your IT company one thing: "Would you ever call my people and ask them to do something on their computer? If so, how do they check it's really you?" The answer you want is specific. "We never will" is a good one. "We'd send a ticket first, and here's what it looks like" is another.

And give your team one rule to keep. Hang up, and call back on the number you already have. If the call is real, it'll still be real in two minutes.

Did Your Website Take the Update?

WordPress is the software behind a large share of small-business websites. Last week it shipped a fix for a flaw that, under certain conditions, lets someone with no login take over a site. Attackers started trying it the same day the fix came out. By the next day, the attempts were more than ten times as frequent.

The conditions depend on how the site and the server it runs on are set up. Your web person will know; you don't need to.

The good news: sites set to take automatic updates install this fix on their own.

Sites built by an agency or a freelancer sometimes have automatic updates turned off, so an update can't break anything. Nobody's wrong for that. It just means someone has to do the update by hand, and it's worth knowing who.

One question for whoever built or hosts your site: "Did our site take last week's WordPress update, and are automatic updates on?"

"We'll check" is a fine answer. Now someone is checking.

THE NOISE

Not every signal needs action.

Fixed or Filtered

Google's threat researchers at Mandiant reported on September 25 that a group called ShinyHunters is breaking into Oracle PeopleSoft systems again, dozens of them worldwide. PeopleSoft is business software that universities and large organizations run.

ShinyHunters is a name built for headlines. It's also the least useful part of the story. You almost certainly don't run PeopleSoft.

The useful part is smaller. The fix has been out since June. This time, the group went after organizations that hadn't applied it and had put a filter in front of the problem instead. Getting past the filter took rewriting one character in the web address.

That part is about you. There are two ways to handle a hole like this. Fixed means it's closed. Filtered means something is standing in front of it. Both are real. A filter can be the right move for a week while a fix is tested. It's a bad place to stay.

When your IT company says something is handled, it's fair to ask: fixed, or filtered?

ONE QUESTION

No answer. Just the question.

Think of the next tool someone at your company will install. The person clicking the button will be busy getting a job done. Before that click, who is supposed to stop and ask who holds the key? And do they know that's their job?

Where to Start

The two questions before the button work on any tool. The better ones are specific to the tool.

Hit reply with the next tool you're about to buy. I'll send back the two questions I'd ask its vendor first.

Prefer audio? Jane reads every Pulse edition on the Signal vs. Noise podcast. Five minutes, same signal, no scrolling. Find it wherever you listen.

Michael Faas is a fractional CTO/CISO who translates technical complexity into business decisions. echocyber.io