The patch nobody asked the vendor to apply

What happened

Goldheart Jewelry sells jewellery through an online store and its outlets in Singapore. It is majority owned by Aspial Corporation. Its website ran on Magento, an open-source e-commerce platform, and customer data was held in a MariaDB database on its web server. A vendor maintained the website. The service agreement said patches were applied on Goldheart's request, though the vendor sometimes applied some without being asked.

On 24 May 2023, Goldheart learned that its customer database had been published on an online forum. Forensic investigators found that a patch for a known Magento vulnerability had been available since 13 February 2022. It was not applied until January 2023, eleven months later. The threat actor exploited the vulnerability, placed malicious files on the server, copied the database and published it around 19 May 2023.

The data of 41,379 individuals was affected: names, email addresses and dates of birth, plus contact numbers and billing and shipping addresses for roughly 3,500 of them.

What PDPC found

Goldheart admitted the facts and the breach under PDPC's expedited procedure. PDPC found that it had negligently breached the Protection Obligation by failing to implement adequate patch management processes.

PDPC recognised that many organisations rely on vendors for patching, but said this does not absolve them of accountability. Goldheart said it had outsourced patch management. PDPC said that was inconsistent with its service agreement and with the Aspial Group's Patch Management Policy, which made Goldheart responsible for monitoring patch releases and asking its vendor to apply patches. Goldheart said patching was the vendor's job. PDPC said the vendor applying some patches on its own initiative did not help, because the obligation to implement security arrangements remained with Goldheart, including setting out clearly in the contract who was responsible for what. Goldheart had not monitored for the patch or asked for it. Its only check was a vendor scan with the Magento Security Scanner on 8 December 2022, which did not detect the problem.

PDPC did not accept that the vendor was Goldheart's data intermediary. It contrasted this case with the Law Society decision, where the organisation had kept maintenance logs of its vendor's activities and was found reasonable in relying on it. Goldheart had no process to monitor or manage its vendor. The vendor's scope under the agreement was backend programming and database configuration, which did not involve processing Goldheart's personal data. Some incidental processing did not make it responsible for security arrangements.

PDPC noted that Goldheart had appointed a data protection officer, had data protection policies and had endpoint security and anti-virus in place. It also noted there was no regular, extensive security testing or penetration testing of the website server, and gaps in access control and log retention. PDPC's preliminary view had also covered plaintext credentials stored on the server. After Goldheart's representations, PDPC accepted its explanation on that point.

PDPC imposed a financial penalty of S$58,000. It directed Goldheart, within 60 days, to engage a third-party cybersecurity vendor for a targeted security audit to strengthen access control, to fix any gaps found, and to report to PDPC within 7 days of finishing.

Where it goes wrong in practice

"We pay a vendor for the website" slowly becomes "the vendor looks after security". The contract says patches are applied on request. The vendor assumes you will ask. You assume they will tell you. Neither side has a calendar, and the notice about a known vulnerability lands in an inbox nobody checks.

Having a DPO and policies can add to the false comfort. A policy describes what should happen, but it doesn't produce a patch. In this case the policy named who was responsible, and the task still didn't happen for eleven months.

Calling a vendor a specialist, or a data intermediary, can feel like the same thing as handing over responsibility. It isn't. When the vendor does some of the work unprompted, the assumption gets stronger, and nobody checks what the contract actually says.

Lessons learned

• Outsourcing the work doesn't outsource the responsibility. The contract decides who acts, and you still need to know it is happening.
• Evidence of oversight, such as a maintenance log, is what separated this case from the Law Society one.
• A clean scan is not proof that nothing is wrong.
• Known vulnerabilities are the ones attackers look for first, because the fix has already been published.
• A vendor doing something helpful unprompted is not an agreement to keep doing it.
• Calling a vendor a data intermediary doesn't move security responsibility. The contract has to say who does what.

How to avoid it

• Read your vendor agreement and mark who monitors for patches, who requests them and who applies them.
• Give someone in your business the job of watching security updates for the platforms you run, or get your vendor to confirm in writing that they do.
• Set a target time for applying patches to known critical vulnerabilities, and record when each one was applied.
• Ask the vendor for a maintenance report each month or quarter, so there is a record you can review.
• Test any website that holds customer data beyond a standard scan, at least once a year.

If you're unsure what your vendor contracts say about security and who is checking, talk to us. It is the kind of oversight we help organisations keep in place, so it doesn't depend on one person remembering to ask.