Industry Brief: Retail and E-Commerce Cyber Risk Priorities

Why retail is a different risk problem

A retailer holds a very large number of customer identities, most of them dormant, and each one can carry stored payment methods, addresses and loyalty value. Revenue is concentrated in short peaks, so an outage costs far more in some weeks than others. The checkout page is assembled from the retailer’s own code and from scripts supplied by payment, analytics, marketing and personalization vendors. And the workforce is large, changes often, and leans on contracted help desks.

Each of those features creates an exposure that a generic enterprise risk register does not weigh properly. The result is that attacks can start at an ordinary point of contact, such as a phone call to a service desk or a script on a web page, rather than at a hardened perimeter.

The priorities at a glance

1. Customer identity and account takeover

Customer accounts are valuable because they store things that can be spent: saved cards, gift balances, loyalty points, refund rights. An attacker who takes over an account can often extract value without ever touching the payment environment. That makes account takeover a retail problem first and a technology problem second.

A common organizational gap is ownership. Fraud teams see the losses, security teams see the credential attacks, and product teams own the login journey and resist friction. When nobody owns the whole problem, controls get applied unevenly. The practical answer is to attach stronger checks to the actions that move value, such as changing an email address, adding a payment method or redeeming points, rather than adding friction to every login.

Decision: name a single accountable owner for account takeover, and agree which customer actions justify step-up verification.

2. Workforce identity and the help desk

CISA’s advisory on Scattered Spider describes a group that impersonates employees to persuade help desk staff to reset passwords and move MFA enrollment to devices the group controls. It also describes repeated push notifications until a user approves, social engineering to obtain one-time codes, and SIM swapping. The advisory recommends phishing-resistant MFA, which resists push fatigue and SIM swaps, along with tight control of remote access tools.

In the UK, the National Cyber Security Centre issued guidance after attacks on Marks & Spencer, the Co-op and Harrods. As reported, it said attackers had posed as employees to get help desk staff to reset credentials, and urged retailers to review reset processes and how staff identity is checked, especially for privileged accounts. The NCSC said at that stage that it had not established whether the attacks were linked or who was behind them, so this brief draws no link between those incidents and any particular group.

The reported outcomes differed, and the differences are instructive. Marks & Spencer suffered ransomware that disrupted online orders, contactless payments and Click & Collect. The Co-op said significant customer data was stolen but that it stopped the attack before encryptors were deployed. Harrods reported an attempted breach and restricted internet access. Speed of detection and the willingness to cut access decided how far each attack traveled.

Decision: treat password reset and MFA re-enrollment as high-risk transactions with stronger verification for privileged users, and bring outsourced help desks inside the control scope.

3. Payment pages and third-party scripts

PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 address e-skimming on e-commerce payment pages. Broadly, scripts on the payment page must be authorized and checked for integrity, and changes to the page must be detected. They began as best-practice items and are now required in assessments.

The test for a leadership team is simple to state and often hard to pass: can someone produce a list of every script that runs on the checkout page, with a named person who approved each one? Marketing tag managers and personalization tools are where lists tend to break down, because the people who add scripts are not the people who answer to the assessor. How a given payment integration model affects scope is a question for the retailer’s assessor, and the answer should be on file.

Decision: give the checkout page a single accountable owner, and bring the marketing and payment-security teams into the same approval path for scripts.

4. Platform and third-party dependency

Online retail runs on platforms, payment providers, fulfillment partners and marketing services. Some of them are single points of failure in the literal sense: if the provider is down, the site cannot take an order. Security questionnaires do not show that. A dependency map does.

The map should answer one question for each provider: if this stopped for three days, what could we still sell, and how? Some retailers will find they can take orders by an alternative route. Others will find they cannot, and that is the finding that justifies investment.

Decision: identify the third parties whose failure would stop trading, and agree a degraded mode for each.

5. Trading-peak availability and recovery

Consider a retailer a few weeks before its busiest trading period. A late-stage intrusion is detected on a Friday afternoon. The choice is to isolate trading systems now, at a known cost, or to wait for certainty while the attacker may be preparing encryption. This is a hypothetical scenario, not a documented incident. The point is that the decision is much easier if it was made in advance, with the cost per hour of lost trading already understood.

Recovery has the same quality. Restoring the order, payment and inventory path in the right sequence is a rehearsed skill. Restoring head-office systems first, because they are easier, can cost days that trading cannot spare.

Decision: pre-authorize who can isolate trading channels, record the cost of doing so, and agree the restoration order for order management, payment and inventory before the peak, not during it.

Decisions to put in front of the executive team

• Assign one owner for customer account takeover and agree where step-up verification applies.

• Rewrite help desk reset and MFA re-enrollment procedures as high-risk transactions, including for outsourced desks.

• Confirm that every script on the payment page is inventoried, authorized and monitored.

• Map the third parties whose failure stops sales and agree a degraded mode for each.

• Pre-authorize isolation of trading channels and rehearse restoration in the agreed order.

What this brief does not claim

The order of priorities is a judgment drawn from public guidance and reported incidents. It is not a ranking of any retailer’s actual exposure. The attacks on UK retailers are described here only as far as the NCSC and press reporting support, and the cause and attribution of each remain the subject of ongoing investigation. Retailers with different channel mixes, such as stores-led or marketplace-led, will weight the priorities differently.

Sources

• Scattered Spider (advisory AA23-320A) (CISA and FBI)

• UK shares security tips after major retail cyberattacks (BleepingComputer, reporting on NCSC guidance)

• Guidance for PCI DSS e-commerce requirements 6.4.3 and 11.6.1 (PCI Security Standards Council)