Payment infrastructure as a target: what retail teaches us

For several years now, retail has seen a steady stream of incidents involving the compromise of customer payment data. Some became public. Most stayed inside the companies affected. Nearly all of them share one feature: attackers were inside the network significantly longer than anyone suspected before being discovered.

That is the right place to focus. The problem is not just that card data leaked. The problem is that companies with sophisticated operational infrastructure - thousands of terminals, complex supply chains, processor integrations - were unable to detect a foreign presence in their network for weeks or months.

Why retail became an attractive target

Retail payment infrastructure combines several risk factors in one place.

A large number of entry points. Every POS terminal in every store is a device connected to the network. The scale makes it impossible to control each point with the same rigour as central systems.

Mixed networks. In a typical retailer the same network often serves checkout terminals, administrative workstations, and warehouse management systems. Compromising one segment opens access to others.

Long refresh cycles. Replacing a fleet of terminals is expensive. Devices run for years, and software updates on them are a logistics challenge. This means vulnerabilities in older software versions live longer than in corporate environments.

Real-time data. Card data passes through the terminal at the moment of a transaction. If malicious code is running on the terminal at that moment, the data is captured before encryption.

What actually solves the problem

PCI DSS standards exist precisely for this industry and contain sensible requirements. But compliance certification and real protection are different things. Companies that passed audits successfully went on to become victims of serious incidents.

Three things work not as checkboxes but as real protection mechanisms.

Network segmentation - dividing infrastructure into zones with controlled traffic between them. If the payment segment is isolated from the administrative one, compromising a checkout terminal does not automatically give access to the central database. The case that ICS segmentation is no longer optional applies equally here, in a very different industry.

Centralised event logs - collecting logs from devices into a central system that cannot be deleted from the device itself. An attacker who wipes local traces cannot erase what has already been sent to the centre.

Anomaly monitoring - not a post-incident audit, but a real-time response to atypical behaviour. If a terminal starts sending data to an external address at 3am, that signal needs to be visible to someone right now.

Applicability beyond retail

All three mechanisms - segmentation, centralised logging, anomaly monitoring - are universal. Retail provides vivid examples because the scale of incidents and the number of compromised cards makes them public. But the same principles apply anywhere that sensitive data and distributed infrastructure coexist.

Questions for self-assessment

A few questions that help evaluate the real state of protection:

1. Are the network segments that process sensitive data isolated from the rest of the infrastructure?
2. Where do logs from peripheral devices go - stored locally or centrally?
3. Do we have the ability to detect atypical network behaviour within hours rather than weeks?
4. Who in the organisation is responsible for monitoring - and do they do it actively, not only on request?
5. When did we last verify that isolation between segments actually works, rather than just being declared in policy?

Incidents in retail are not only about payment cards. They are about the fact that attackers are patient, and that time-to-detection is the critical metric that most organisations do not measure.