Customer Cardholder Data Environments – What Could Go Wrong?
A good deal of Friday and yesterday was spent trying to unravel dataflows and network topography to determine the scope of a customer’s cardholder data environment (CDE). Three interesting channels are currently under scrutiny but today’s job is to get to the bottom of an e-commerce website white labelled by our client and provided by an outsourced merchant. After landing on our client’s website, clicking on the “shop” link takes the user off to the e-commerce merchant’s portal. Goods and services are selected and at the point of purchase, the user either has to login to the portal or create an account and log in. Then the user is transferred to an approved secure payment portal along with the value of the transaction. Card details are entered. An interesting twist is that the e-commerce portal has an add-in translation function which translates the information on the page as well as the navigation, footers etc. between English and other languages.
So, what could go wrong?
For a start, we’re wondering how the language plug-in actually works? What if an attacker could amend the text and send the user off to a rogue payment page? Is it some kind of Java functionality or perhaps it draws data from a content management system when the language switch is activated? How secure is this feature? Then we are wondering how much of the client’s website within scope? Is it one page, more than that or all of it? How exactly does our client segment and protect the bought-in e-commerce site and links? How does it work with the translation function? Where are these websites, who develops them and to what standards? What exactly is a portal anyway? It seems to be an over-used descriptor for all sorts of different things.
The brief was received late on Thursday. “We have these new payment channels that people have committed to during lockdown, would you (DPP) review and sign off our risk assessment paperwork?” The trouble is that without seeing how these channels are put together, it is simply not possible to give a considered response to a short risk assessment. The risk assessment highlights that passwords are never required to be changed on the portal! Wow! And that there is no log-in logging. It suggests this is non-compliance with Article 6 of the GDPR as well as a potential PCI DSS non-compliance.
If something so elementary as that is missing, what exactly are we looking at and where is the detail behind the risk assessment? So we have arranged a meeting with the vendor: the e-commerce portal provider to go through the channel in more detail.
The nagging question is why are we doing this retrospectively and what if we find a can of worms?
Philip Brining – Director – Data Protection People