Singapore | Personal Data Protection Commission imposes S$74,400 fine on E-Commerce Enablers Pte. Ltd.

1. On 16 August 2023, the Personal Data Protection Commission ("PDPC") published its decision Re E-Commerce Enablers Pte. Ltd. [2023] SGPDPC 6 in which it imposed a financial penalty of S$74,400 on E-Commerce Enablers Pte. Ltd. (the "Organisation"). The Organisation was found to be in breach of its Protection Obligation under section 24 of the Personal Data Protection Act 2012 ("PDPA"). Notably, the PDPC rejected the Organisation’s framing of the Incident as a "one-off case of human error".

2. The PDPC emphasised that organisations cannot place sole reliance on their employees to carry out their duties as a security arrangement to protect personal data. Organisations must ensure that there are processes in place to ensure that the steps their employees are required to perform are indeed taken.

Background Facts

3. This case arose when the Organisation notified the PDPC and its customers of an incident involving unauthorised access to its customer data servers (the “Incident") on 25 September 2020. The PDPC subsequently received 2 complaints from the Organisation’s customers regarding the Incident. Later on 12 November 2020, the Organisation's customer database was offered for sale on an online forum, indicating that there was personal data exfiltration during the Incident.

4. The Organisation, also known as Shopback, runs an online platform offering cashback for purchases made through affiliated merchant programmes. At the time of the Incident, the Organisation hosted its customer database on virtual servers in an Amazon Web Services (“AWS”) cloud environment. The Organisation's Site Reliability Engineering ("SRE") team, was responsible for, among other things, providing and managing the Organisation’s AWS cloud environment and ensuring security of the AWS keys. The SRE team used an AWS access key with full administrative privileges (the “AWS Key”) to carry out its work. Only SRE team members had access to, and were authorised to use, the AWS Key.

5. On 4 June 2019, the AWS Key was inadvertently committed to software code in a private repository in GitHub, by a senior SRE team member. Two days later, this was discovered by another SRE team member and the AWS Key was removed from GitHub on the same day. However, the code remained viewable in GitHub’s "commit history".

6. On 21 June 2019, the AWS Key was to be deleted and replaced by a new key as part of an out-of-cycle key rotation. The SRE team member in charge of the key rotation informed the SRE team that he had created a new key and that he would be deleting the AWS Key. However, after creating the new key, he failed to fully disable and remove the AWS Key. Consequently, the AWS Key continued to be usable to access the Organisation’s AWS environment (and the Customer Storage Servers therein) until shortly after the time of the Incident, which took place approximately 15 months later.

7. On 9 September 2020, a malicious threat actor gained access to the Organisation’s AWS environment using the AWS Key, which was likely to have been found by the threat actor in the "commit history" of the Organisation's GitHub repository. The threat actor had, among other things, managed to exfiltrate data from the Customer Storage Servers. The affected data items included: email addresses, names, mobile numbers, addresses, NRIC numbers, bank account numbers, and partial credit information.

8. On 17 September 2020, during a routine security review, the Organisation discovered that there had been unauthorised access to its AWS environment. Subsequent investigations showed that there had been unauthorised third-party access to the AWS environment using the AWS Key. The Organisation conjectured that it was likely that the threat actor had obtained the AWS Key from GitHub’s "commit history", where the AWS Key was still visible.

9. Following the Incident, the Organisation implemented various remedial actions, including: immediately performing a full deletion of the AWS Key and rotating the other AWS keys, reversing all changes made by the threat actor and triggering a forced logout and password reset of all customers’ accounts, and various measures to prevent recurrence of similar incidents.

10. On 12 November 2020, it was discovered that the Organisation’s database was offered for sale on Raidforums. Raidforums’ domain name and content was independently seized by the United States authorities in April 2022.

PDPC’s Findings

11. In light of the circumstances of the case, the PDPC found the Organisation to be in breach of the Protection Obligation under section 24 of the PDPA in two main respects:

     Lack of sufficiently robust processes for AWS key management

12. The PDPC held that the Organisation failed to ensure that its AWS key management processes that granted access to the Customer Storage Servers were sufficiently robust.

13. Notably, the Organisation had claimed that the compromise of the AWS Key arose from human error and was not due to any systemic issue with its security practices. The Organisation represented to the PDPC that the Incident was a "one-off case of human error", and that there was no reason to doubt the capabilities of the SRE team member in question, because (i) he was a senior member of the SRE team, (ii) his responsibilities included key security and rotation, and (iii) he had dutifully rotated or deleted all other keys assigned to him in the out-of-cycle key rotation. The SRE team member’s inadvertent commit and incomplete rotation or deletion of the AWS Key contravened the Organisation’s security practices.

14. The PDPC however rejected this position. In Re DataPost Pte Ltd, the PDPC had highlighted that organisations cannot place sole reliance on their employees to perform their duties properly as a security arrangement to protect personal data. Instead, organisations must ensure that there are processes in place to ensure that the steps their employees are required to perform are indeed taken, such as independent verification by another checker.

15. For instance, the Organisation could have ensured that the out-of-cycle key rotation was complete by requiring a supervisor or another SRE team member to test either all or a reasonable sample of the old keys to verify that they had been disabled. However, no such verification or testing practice was put in place.

16. When a high-risk task (such as the rotation of an AWS key that gives access to the AWS environment) is concerned, it is especially important for the organisation to ensure that there must be additional verifications and checks.

     Failure to conduct periodic security review

17. The Organisation also failed to conduct regular specific security review on whether the AWS keys had been properly rotated or deleted. Such a review could have covered and detected whether the AWS Key remained active or had been used after the out-of-cycle key rotation and during the period preceding the Incident.

     Observation regarding the Organisation's incident management processes

18. The PDPC noted that following the Organisation's discovery of the inadvertent committal of the AWS Key, it took 15 days to conduct a key rotation. The Organisation should review its incident management processes to determine whether it was reasonable to have taken 15 days to remediate the compromise of a full administrative privilege AWS access key, regardless of whether this had been an out-of-cycle rotation.

PDPC’s Decision

19. In determining whether to impose a financial penalty and the amount thereof, the PDPC took into account, among other things, the following:

     i. Aggravating Factors:

        a. The Organisation lacked sufficiently robust processes to monitor its incident management response to ensure reasonable remediation speed; and

        b. The AWS Key was exposed for a long period of 15 months;

     ii. Mitigating Factors:

         a. The Organisation took prompt remedial actions, including notifying the affected individuals;

         b. The Organisation was cooperative during investigations; and

         c. The Organisation voluntarily acknowledged that its failure to ensure proper rotation and deletion of the AWS Key constituted a breach of the Protection Obligation.

20. In light of the circumstances of the case, the PDPC imposed a financial penalty of S$74,400 on the Organisation, without further directions as it had already taken the necessary remedial measures.

Commentary

21. This decision highlights the standard of robustness that is expected of organisations’ access key management and review practices. Organisations that store personal data in online / cloud databases should ensure that they have in place adequate processes for access key management.

22. Organisations should ensure that key rotations (including out-of-cycle rotations) are indeed complete by testing either all or a reasonable sample of the old keys to verify that they have been disabled. Specific security review on access keys should also be carried out as part of organisations’ periodic security reviews.

23. Lastly, organisations should ensure that their incident management process enables a reasonable response and remediation time.

24. We will continue to monitor developments in this area.