_commit_at,_commit_hash,_id,_item,_version,_commit,description,tags,date,pdf-url,nature,title,url,timestamp,pdf-content,decision,_item_full_hash,_changed_columns 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,31,31,1,952,"Warnings were issued to Toll Logistics (Asia), Toll Global Forwarding, Toll Offshore Petroleum Services, and Toll (TZ) for breaches of the PDPA in relation to the transfer of employees’ personal data to a human resources software vendor in Ireland.","[""Transfer Limitation"", ""Warning"", ""Transport and Storage""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Toll-Logistics-Asia-Limited-and-others--180322.pdf,Transfer Limitation,Breach of the Transfer Limitation Obligation by Toll Logistics (Asia) and others,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-the-transfer-limitation-obligation-by-toll-logistics-and-others,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 4 Case No. DP-2008-B6707 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Toll Logistics (Asia) Limited (2) Toll Global Forwarding (Singapore) Pte. Limited (3) Toll Offshore Petroleum Services Pte. Ltd. (4) Toll (TZ) Pte. Ltd. … Organisations DECISION Toll Logistics (Asia) Limited and others [2022] SGPDPC 4 Yeong Zee Kin, Deputy Commissioner — Case No. DP-2008-B6707 14 March 2022 Introduction 1 Toll Holdings Limited (“Toll Holdings”) is an integrated logistics services provider headquartered in Australia. Toll Logistics (Asia) Limited (“Toll Logistics”), Toll Global Forwarding Singapore Pte. Ltd. (“Toll Forwarding”), Toll Offshore Petroleum Services Pte. Ltd. (“Toll Offshore""), and Toll (TZ) Pte. Ltd. (“Toll TZ”) are Singapore-registered entities (collectively, “the Organisations”) that are part of a multinational group of companies headed by Toll Holdings (“the Group”). 2 On 11 June 2020, Toll Holdings notified the Personal Data Protection Commission (“the Commission”) of a ransomware attack which had affected the Group’s IT systems, including servers in Australia and Singapore containing the personal data of current and former employees of the Organisations (“the Incident”). The Commission subsequently received complaints from 3 former employees of Toll Logistics in relation to the Incident. Investigations were commenced to determine whether the circumstances relating to the Incident disclosed any breaches by the Organisations of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 3 In July 2013, Toll Holdings contracted with a vendor in Ireland (“the HR Vendor”) for the Group’s use of the HR Vendor’s human resources software platform (“the HR Platform”). To facilitate use of the common HR Platform, the respective Group entities (including the Organisations) uploaded the personal data of their employees to the HR Platform. The data uploaded to the HR Platform was hosted by the HR Vendor in data centres in the European Economic Area. 2 4 Subsequently in 2019, a series of Corporate Services Agreements (“CSAs”) and accession agreements were executed with the net effect that Toll Holdings undertook to provide finance, human resources (“HR”), information technology (“IT”), legal, and other corporate services to all the Organisations. Although the CSAs were inked in 2019, they took retrospective effect from 1 April 2018. 5 The services provided by Toll Holdings to the Organisations under the CSAs included: 6 (a) Development and maintenance of HR policies and procedures; (b) Development and maintenance of IT strategy; (c) Development and maintenance of IT policies and procedures; and (d) Provision of IT support services. Under the terms of the CSAs, Toll Holdings was permitted to appoint subcontractors to perform part or all of the services subject of the CSAs but was responsible to the same extent as if it had performed the services itself. 7 The scope of IT services to be provided by Toll Holdings under the CSAs specifically excluded the “development or implementation of IT systems”, which responsibility presumably remained with the Organisations. To this end, the Organisations maintained ten servers in Singapore to support their operations. Three of these servers (“the Singapore Servers”) were used by the Organisations’ corporate teams (i.e. finance, legal, HR) in the ordinary course of their work and contained personal data within the email archives and other working documents. 8 The Group (including the Organisations) had implemented various industry- standard security solutions for its IT systems such as end-point protection software, logging and monitoring software and/ services, firewall and intrusion prevention software, security detection and response software, identity access management and control software and services, vulnerability scanning software and services, and patching software. A Managed Security Service Provider (“MSSP”) was also engaged to provide cyber security detection and incident response services for the Group. With 3 the assistance of the MSSP and other external vendors, the Group carried out regular vulnerability scanning and penetration testing of its IT systems. Transfer of personal data to Australia 9 Sometime prior to the Incident, Toll Holdings’ Chief Human Resources Officer extracted personal data relating to 1,748 of the Organisations’ current and former employees from the HR Platform and transmitted them to a server in Australia (“the Australia Server”). Toll Holdings represented that this personal data was transferred for the purposes of performing services for the Organisations pursuant to the CSAs. 10 11 The personal data downloaded by Toll Holdings comprised each employee’s: (a) Name; (b) Address (c) Age; and (d) Salary. 5 employees of Toll Logistics and 2 employees of Toll Forwarding also had other datasets disclosed including: (a) Driver’s licence number; (b) Emergency contact details; (c) National ID; (d) Fingerprint; (e) Medical details; and (f) Passport details. 4 The Incident 12 On 26 April 2020, a malicious actor gained access to Toll Holdings’ IT environment in Australia using credentials stolen from a third-party vendor. The thirdparty vendor had been granted administrative access to two servers in Toll Holding’s IT environment in order to provide support services for a software solution. 13 Having gained access to the Group’s IT environment, the malicious actor used advanced malware and a range of hacking tools to move through the Group’s network, conduct reconnaissance, and escalate account privileges. The malicious actor also made various efforts to bundle and compress data from the Australia Server and stage it for exfiltration. 14 Threat monitoring software deployed by the Group detected events related to the malicious actor’s account takeover and privilege escalation during the Incident and raised alerts to the MSSP. However, according to Toll Holdings, no alerts were brought to its attention. On 3 May 2020, the malicious actor exfiltrated less than 2% (two percent) of the data stored on the Australia Server using a web-based file sharing service. The malicious actor then ran scripts to disable various endpoint protections across the Group and executed a ransomware attack. The ransomware attack encrypted files on a number of the Group’s servers, including the Australia Server and the Singapore Servers. 15 When subsequently making ransom demands, the malicious actor provided Toll Holdings a summary of the files exfiltrated from the Australia Server and eventually uploaded portions of the exfiltrated files onto the dark web. Based on (i) the summary provided by the malicious actor, (ii) the Group’s review of the available logs and records on the Australia Server, and (iii) a review of the files eventually published by the malicious actor on the dark web, the Organisations concluded that there was no evidence of exfiltration of the personal data of its current or former employees from the Australia Server. 16 The Organisations also concluded that there was no evidence of data exfiltration from the Singapore Servers, or any other servers in the Group’s IT environment in the Incident, other than the Australia Server. The Organisations were 5 able to restore the encrypted data in the Singapore Servers from securely stored backups. Remedial actions 17 Following the Incident, Toll Holdings implemented the following remedial measures on a Group-wide basis: (a) Temporarily disconnected from the Internet, and undertook a rolling shutdown of IT systems in order to mitigate spread of any infection; (b) Isolated all impacted servers and implemented network restrictions to prevent spread of the ransomware within the Group’s network; (c) Engaged third-party experts to assist with incident response, including investigation and remediation; (d) Upgraded its user access system and reset all administrator passwords; (e) Blocked the malware used in the Incident; (f) Removed access privileges obtained by the malicious actor; (g) Implemented additional vulnerability scanning across the Group’s IT systems to harden the Group’s network perimeter; (h) Strengthened the Group’s Active Directory infrastructure; (i) Implemented additional end point protection, forensic tools, and monitoring tools; (j) Introduced a shadow security operations centre and initiated transition to a new MSSP; (k) Initiated plans for an asset lifecycle review to identify legacy critical business applications and treatment required to address cyber risks; (l) Commenced a logging, monitoring and alerting uplift to review existing policies and standards; 6 (m) Completed the rollout of multi-factor authentication for all remote access; (n) Updated organisational measures such as incident response plans, policies, and playbooks; and (o) Rolled out a cyber awareness programme containing training and assignments for its employees Findings and Basis for Determination 18 Based on the circumstances of the Incident, the Commission’s investigation centred on: (a) Whether the Organisations had breached their respective obligations under section 26 of the PDPA to not transfer any personal data to a country or territory outside Singapore except in accordance with requirements prescribed under the PDPA (the “Transfer Limitation Obligation”); and (b) Whether the Organisations had breached their respective obligations under section 24 of the PDPA to protect personal data in their possession or under their control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). Whether the Organisations had contravened the Transfer Limitation Obligation 19 The HR Platform was implemented on a Group-wide basis on or around July 2013. The Organisations began uploading the personal data of their employees to the HR Platform for storage in the HR Vendor’s servers in the European Economic Area around this time, and would have continued to do so as part of the normal course of HR functions (for example, when new employees joined). Any transfers of personal data by the Organisations out of Singapore after 2 July 2014 would have been subject to the Transfer Limitation Obligation and the requirements prescribed in Part III of the Personal Data Protection Regulations 2014 (“PDPR 2014”). For transfers of personal data outside of Singapore which occurred after 1 February 2021, such transfers would 7 have been subject to the requirements in Part 3 of the Personal Data Protection Regulations 2021 (“PDPR 2021”). 20 Regulation 9(1)(b) of the PDPR 2014 and regulation 10(1) of the PDPR 2021 require an organisation that transfers personal data outside of Singapore to take appropriate steps to ensure that the recipient of the personal data is bound by legally enforceable obligations to provide the transferred personal data a standard of protection that is at least comparable to that under the PDPA. Under regulation 10 of the PDPR 2014 and regulation 11(1) of the PDPR 2021, such legally enforceable obligations can be imposed on the recipient organisation under (a) any law; (b) any contract between the parties; (c) binding corporate rules; or (d) any other legally binding instrument. 21 In gist, the Organisations were required to take appropriate steps to ensure that the personal data transferred out of Singapore via the HR Platform for storage in the European Economic Area would be protected to a standard comparable to under the PDPA, before any such transfers were made. 22 There was no evidence of any such steps taken by the Organisations. While the contract between Toll Holdings and the HR Vendor included data protection obligations imposed on the HR Vendor, the Organisations were not party to this agreement. The CSAs also did not contain any provisions relating to the protection of personal data or impose obligations on Toll Holdings to protect the personal data of the other Organisations for the purposes of the centralised corporate functions to be undertaken pursuant to the CSAs. Accordingly, the Organisations were determined to have contravened the Transfer Limitation Obligation in relation to the personal data uploaded on to the HR Platform. 23 In the course of investigations, Toll Holdings represented that it had since reviewed the data transfer arrangements under the CSAs and that the Organisations and Toll Holdings have now executed a “Singapore Data Export Agreement” to govern intra-group transfers of personal data from the Organisations to Toll Holdings (and other members of the Group who may subsequently become party to the agreement) 8 to ensure that a standard of protection comparable to the PDPA is provided to any transferred personal data. Whether the Organisations had contravened the Protection Obligation 24 As held in Everlast Projects Pte Ltd and others [2020] SGPDPC 20, members of a corporate group may satisfy the Protection Obligation by relying on binding grouplevel written policies or intra-group contracts which specify the respective data protection obligations of the members of the group. In the present case, while the Organisations had entered into the CSAs to centralise various corporate functions with Toll Holdings, the CSAs did not deal with data protection obligations. In the circumstances, the Protection Obligation remained with the Organisations, and the Organisations cannot rely on the CSAs to say that certain of its data protection operations had been centralised with Toll Holdings at the Group-level. 25 That being said, under the CSAs, Toll Holdings had undertaken to provide the Organisations with IT support services. It has been held in WTS Automotive Services Pte Ltd [2018] SGPDPC 26 that organisations can rely on the technical expertise of their service providers to satisfy the Protection Obligation (subject to clear instructions or business requirements being specified). In the case where a member of a group of companies provides technical support services to others in the group, it is advisable that their respective roles and responsibilities be clearly spelt out. 26 In the present case, the CSAs were intended to perform this role: Toll Holdings was responsible for IT support services while the Organisations remained responsible for development and implementation of IT systems: see [7] above. As part of the IT support services provided, Toll Holdings introduced and implemented Group-level IT security standards. These were communicated through the Group’s intranet and implemented by Toll Holdings on a Group-wide basis, as part of the IT support services they provided. In accordance with these standards, a number of industry-standard technical solutions and tools were implemented prior to the Incident to protect the personal data in the Singapore Servers: see [8] above. 27 Having considered these security arrangements, we are satisfied that the Organisations had not breached their Protection Obligation as the security 9 arrangements in place prior to and at the time of the Incident to protect the personal data in the Singapore Servers were reasonable and consistent with existing industry standards. In coming to this decision, we are also of the view that the security lapse and privilege escalation that enabled the malicious actor to overcome the Organisations’ endpoint protections in the Incident occurred abroad arising from theft of credentials from Toll Holdings’ vendor and was beyond the control of the Organisations. The Deputy Commissioner’s Decision 28 In determining what directions (if any) should be given to the Organisations pursuant to section 48I of the PDPA, the Deputy Commissioner took into consideration: (a) the Organisations’ cooperation with the Commission’s investigations; (b) that access to the transferred personal data was limited to entities within the same corporate group; (c) that there was no evidence of any loss or damage resulting from the Organisations’ contravention of the Transfer Limitation Obligation; and (d) that the Group had already implemented intra-group contractual arrangements to govern future transfers of personal data by the Organisations to Toll Holdings. 29 Having considered all the mitigating factors listed above, the Organisations are administered a warning in respect of their breach of the Transfer Limitation Obligation. No other directions are necessary in view of the remedial actions already taken by the Organisations. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 10 ",Warning,3366d27f6930503cebbbff6dd8de747f0da55d18,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,32,32,1,952,"A financial penalty of $2,000 was imposed on Southaven Boutique for failing to put in place reasonable security arrangement to prevent the unauthorised access of its customers' personal data in its Point-Of-Sale system server. An application for reconsideration was filed against the Decision Re Southaven Boutique Pte Ltd. Upon review and careful consideration of the application, direction in the Decision was varied and the financial penalty imposed was reduced.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Ransomware""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Southaven-Boutique-Pte-Ltd---280222.pdf,Protection,Breach of Protection Obligation by Southaven Boutique,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-protection-obligation-by-southaven-boutique,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2102-B7854 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Southaven Boutique Pte Ltd 1 Editorial note: An application for reconsideration was filed against the decision in Re Southaven Boutique Ptd Ltd. Pursuant to this application, the Deputy Commissioner has decided to reduce the financial penalty imposed on the Organisation from $5,000 to $2,000. As the application did not give rise to significant legal or factual issues, a separate decision on the application will not be published. SUMMARY OF THE DECISION 1. On 5 February 2021, Southaven Boutique Pte Ltd (the “Organisation”), a brickand-mortar retailer of clothes and accessories, informed the Personal Data Protection Commission (the “Commission”) of a ransomware attack that occurred on or about 4 February 2021 (the “Incident”). A threat actor had gained access to the Organisation’s Point-Of-Sale (the “POS”) system server and encrypted the personal data of 4,709 customers. The personal data affected include names, addresses, email addresses, contact numbers and date of birth. 2. Investigations revealed that the Organisation did not implement adequate administrative and technical security arrangements. First, the Organisation failed to conduct or schedule any software updates, maintenance and/or security review before the Incident. Past decisions by the Commission had stressed the need for such security arrangements. The Organisation’s operating system and anti-virus software, for example, were outdated and updated only after the Incident. 3. Second, the Organisation had failed to set out any data protection requirements or responsibilities with the POS vendor whom the Organisation had engaged to supply and install the POS, and relied on for system service issue. This meant that the Organisation did not in fact engage the POS vendor to provide the necessary maintenance support. As the Organisation continued to seek the POS vendor’s assistance for any system service issue, it was also not entirely clear to the parties concerned whether the POS vendor remained responsible for ensuring that the POS system server was updated or patched. It should be reiterated that while an organisation may engage other third-party service providers to provide the 2 necessary technical assistance and support, an organisation’s responsibility for complying with its statutory obligations under the PDPA may not be delegated.1 Given the Organisation’s omission to engage any maintenance support prior the Incident, the Organisation bore full responsibility for its failure to conduct or schedule the necessary software updates, patches and security reviews. 4. In the circumstances, the Organisation is found to have breached section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 5. After the preliminary decision was issued, the Organisation submitted representations requesting for a waiver of the financial penalty imposed. The Commission considered the representations made, and took into account first, the remediation efforts taken by the Organisation since the Incident, and its commitment to invest in a better and more secure IT system, and second, the adverse impact the COVID-19 pandemic had on the Organisation’s business revenue. Nonetheless, as explained above, the onus remained on the Organisation to put in place adequate security measures such as regular IT system maintenance, patches and periodic security reviews. . 6. Having considered all the circumstances in this case, the Deputy Commissioner directs that the Organisation pays a financial penalty of S$5,000 within 30 days from the date of the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 7. Finally, having considered the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. 1 See Re WTS Automotive Services Pte Ltd [2019] PDP Digest 317 at [14] and [23]. 3 The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. 4 ",Financial Penalty,ba5645fa0a7e61666bb1148c1c65700478353304,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,33,33,1,952,"A financial penalty of $12,500 was imposed on PINC for failing to put in place reasonable security arrangements to protect the personal data in its possession. Directions were also issued to PINC to develop and implement internal data protection policies and practices to comply with the PDPA and to ensure no copies of database were stored on employees' personal computers.","[""Accountability"", ""Protection"", ""Financial Penalty"", ""Directions"", ""Wholesale and Retail Trade"", ""No Policy""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---PINC-Interactive-Pte-Ltd---04022022.pdf,"Accountability, Protection",Breach of the Accountability and Protection Obligations by PINC Interactive,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-the-accountability-and-protection-obligations-by-pinc-interactive,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 1 Case No. DP-2002-B5827 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And PINC Interactive Pte. Ltd. … Organisation DECISION Page 1 of 9 PINC Interactive Pte. Ltd. [2022] SGPDPC 1 Lew Chuen Hong, Commissioner — Case No. DP-2002-B5827 4 February 2022 Introduction 1 On 2 February 2020, the Personal Data Protection Commission (“the Commission”) received feedback about a Twitter post dated 31 January 2020 which revealed that the personal data of users of www.pincstyle.com had been exposed. The tweet included a snapshot of the data (“the Incident”). The Commission commenced investigations into the Incident thereafter. Facts of the Case 2 The website www.pincstyle.com was created and managed by PINC Interactive Pte. Ltd. (“the Organisation”) at the material time. Investigations revealed that sometime in October 2019, a database comprising 252,813 records was accessed and exfiltrated from the Organisation’s staging servers (the “Staging Database”). The Staging Database is a synthetic database containing personal data of 3,916 actual users, while the remaining 248,897 records were fake or “dummy” data modelled after the real data. The synthetic database was used to facilitate development and testing on the staging servers. The personal data from the 3,916 actual users that were exposed in the Incident included the name, username, email address, contact number (for some users) and a password hash. For completeness, the 3,916 user records in the Staging Database is equivalent to 1.6% of the Organisation’s total database of 252,813 user records. Page 2 of 9 3 Investigations revealed two likely causes of the Incident. First, the developers, who are the Organisation’s employees, had retained a copy of the Staging Database on their own personal devices, and the database was exfiltrated when the developers’ computers were compromised. The Organisation stated that while they had instructed the developers to use strong passwords, the developers were left to manage the security settings on their own computers, and only had antivirus software installed. 4 Second, unauthorised access may have occurred from May 2019 to October 2019 when the Organisation did not require authentication for the Application Programming Interface (“API”) under testing (“Staging API”), which pointed to the Staging Database containing the personal data of real users, despite the Staging Database being accessible over the Internet. The Organisation only implemented access key authentication from October 2019 onwards. Remedial actions 5 Following the Incident, the Organisation took the following remedial actions: a. Updated the API with new authentication keys; b. Limited the access of authentication keys to only the senior developers; c. A password reset was initiated for affected users via email; and d. Developers were instructed to delete their local copy of the Staging Database and scan their own computers for malware. Findings and Basis for Determination Whether the Organisation contravened the Protection Obligation 6 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, Page 3 of 9 disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). For the reasons set out below, the Organisation failed to implement reasonable security arrangements to protect the personal data in the Staging Database. 7 Firstly, the Organisation had failed to accord adequate protection to the personal data by allowing their employees, i.e. the developers, to store local copies of the Staging Database in their own personal devices, without implementing any additional security requirements. Allowing their employees to store the Staging Database in their own personal devices constituted a breach of the Protection Obligation, given that the Staging Database did not merely contain purely synthetic data, but also the personal data of real users. 8 Secondly, the Organisation was also in breach of the Protection Obligation as it merely instructed its employees not to use weak passwords on their personal devices, and left it to each individual employee to decide if and what level of security measures ought to be implemented on their own personal devices to protect the personal data. Indeed, even though the developers had purportedly installed antivirus software on their own personal devices, the Organisation was unable to provide the product name, version, or the frequency of the antivirus updates that the developers supposedly implemented on their end when questioned. 9 In Learnaholic Pte. Ltd.1, the Organisation was found in breach of section 24 of the PDPA as the personal data affected had been sent to and stored in the work email account belonging to the Organisation’s representative in an unencrypted form. After completing the task at hand, the representative failed to delete the email containing the personal data that he received. Instead, the representative kept the email containing the personal data, in case he needed it in future. As a result, the hacker had free rein to the personal data affected once he obtained access to the email 1 [2019] SGPDPC 31. Page 4 of 9 account. In a similar vein, the Organisation here has failed to adopt adequate security measures when it simply allowed its employees to retain a copy of the Staging Database on their own personal devices, without putting any thought to the security measures that ought to be implemented to protect the personal data. 10 Finally, while we appreciate that the Organisation wanted the Staging API to mirror the production environment, it was not a reasonable “protection” measure to commingle synthetic data with the personal data belonging to real users, without processing the personal data of the real users before doing so, as this meant that the Staging Database contained the data of real users. Having decided to use personal data belonging to real users in the Staging Database, the Organisation has breached the Protection Obligation by failing to require authentication before the Staging API could be accessed. If the Organisation’s intention was not to require authentication for the Staging API, the Organisation should have chosen to use only synthetic data in the Staging Database. In How to Guard Against Common Types of Data Breaches (the “Handbook”),2 the Commission identified the five most common gaps in ICT system management and processes, and observed at page 11 of the Handbook that: “Out of convenience, many organisations use production data for system testing in their test environments. But as test environments tend to be much less secured, there is a high risk of data breach in a test environment.” 11 In the Handbook, the Commission explained that synthetic data can be generated either from scratch using commercial tools or by anonymising production data, and recommended that organisations can create synthetic data (i.e. fake personal data or data anonymised from real data) for development and testing purposes in non-production environments instead of using real data. 2 https://www.pdpc.gov.sg/news-and-events/announcements/2021/05/handbook-on-how-to-guard- againstcommon-types-of-data-breaches-now-available Page 5 of 9 12 In this case, the Organisation could have chosen to use 100% synthetic data or anonymise the personal data before using them if it did not wish to require authentication for the Staging API. In light of the above, we are also of the view that the Organisation breached the Protection Obligation by using personal data belonging to real users in the Staging Database, but failing to require authentication before the Staging API could be accessed. Whether the Organisation contravened the Accountability Obligation 13 Section 12(a) of the PDPA requires an organisation to develop and implement policies and practices that are necessary for the organisation to meet its obligations under the PDPA (the “Accountability Obligation”). 14 The Organisation admitted that they did not have any data protection policies or practices in place for their “non-technical” employees, who have access to “public user data”. In its reply, the Organisation drew a distinction between its “technical” and “non-technical staff”, and stated that for the “technical” staff, the data protection policies in place extended to the Organisation’s team lead providing a briefing to the “technical” staff of the system, rules for branch creation and the code standard during onboarding. The information provided by the Organisation to its “technical” staff, during their onboarding, serves merely to facilitate the performance of these employees’ core duties, and cannot be equated with or amount to data protection policies or practices. 15 Indeed, the Organisation’s reply reflects a lack of understanding of what data protection policies and processes seek to achieve and implement. We have previously stressed the critical role that data protection policies and practices play in increasing awareness and ensuring accountability of an organisation’s obligations under the PDPA in Re Aviva Ltd3. We also explained in Re Singapore Cricket Association4 that data protection policies and practices ensure that employees will be able to better 3 [2018] PDP Digest 245 at [32]. 4 [2019] PDP Digest 270 at [19]. Page 6 of 9 protect personal data when they are first able to recognise a matter as one involving data protection. 16 Given the Organisation’s reply, it follows that the Organisation did not in fact have any data protection policies or processes in place to guide their employees on how to comply with the PDPA in carrying out their work functions. The Organisation has therefore breached the Accountability Obligation. The Commissioner’s Directions 17 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty, the factors listed at section 48(6) of the PDPA were taken into account, as well as the following aggravating and mitigating factors: Aggravating Factors (a) The Organisation allowed its employees to keep local copies of the Staging Database on their personal devices, without considering and undertaking any security measures needed to protect the personal data of real users; Mitigating Factors (b) The Organisation was cooperative in the course of investigations and had provided prompt responses to PDPC’s requests for information; and (c) The Organisation was implemented remedial actions to address the Incident. 18 In the course of settling this decision, the Organisation made representations on the amount of financial penalty that the Commissioner intended to impose. Page 7 of 9 The Organisation raised the following factors for the Commissioner’s consideration: (a) The Organisation had engaged an external consultancy firm to ensure that its obligations under the PDPA are upheld to the highest standards with periodic audits, training and risk assessments; and (b) The Organisation was incorporated in 2018 and is still a relatively young company. Since its inception, it had been suffering significant losses in its operation. 19 Having considered the Organisation’s representations, as well as all the relevant factors of this case, the Commissioner hereby decided to impose a reduced financial penalty of $12,500 on the Organisation. The quantum of financial penalty has been calibrated and reduced after due consideration of the Organisation’s financial circumstances, bearing in mind that any financial penalty imposed should not be crushing or cause undue hardship on organisations. 20 Taking into account all the relevant facts and circumstances, the Commissioner hereby: (a) Requires the Organisation to pay a financial penalty of $12,500 within 30 days from the date of the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full; (b) Directs the Organisation to: (i) Develop and implement internal data protection policies and practices to comply with the PDPA within 60 days of the relevant direction accompanying this decision; Page 8 of 9 (ii) Ensure that no local copies of the database are stored on the personal computers of any employees (including both developers and senior developers) within 60 days of the relevant direction accompanying this decision; and (iii) To notify the Commission within 1 week of the completion of this direction. 21 Although the Commissioner has imposed a lower financial penalty on the Organisation in this case, the financial penalty was arrived at after considering the dismal state of the Organisation’s finances, and should be confined to the specific facts of this case. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION Page 9 of 9 ","Financial Penalty, Directions",d2cda7ac80cc4638223955ef382304ee06a36b98,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,34,34,1,952,"A financial penalty of $24,000 was imposed on Lovebonito for failing to put in place reasonable security to protect personal data in its possession. The incident resulted in the personal data being accessed and exfiltrated.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Password policy""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Lovebonito-Singapore-Pte-Ltd--21022022.pdf,Protection,Breach of the Protection Obligation by Lovebonito,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-the-protection-obligation-by-lovebonito,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 3 Case No. DP-1912-B5484 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Lovebonito Singapore Pte. Ltd. … Organisation DECISION Lovebonito Singapore Pte. Ltd. [2022] SGPDPC 3 Lew Chuen Hong, Commissioner — Case No. DP-1912-B5484 21 February 2022 Introduction 1 On 12 December 2019, Lovebonito Singapore Pte. Ltd (the “Organisation”) informed the Personal Data Protection Commission (“Commission”) that one of its IT systems had been hacked, and that the personal data of 5,561 of its customers had been accessed and exfiltrated by a malicious actor (the “Incident”). The Commission subsequently received two separate complaints from individuals affected in the Incident. Facts of the Case 2 The Organisation operates an e-commerce platform (the “Website”) retailing clothing and accessories. At the material time, the Organisation employed, amongst others, two third-party solutions to manage the Website. First, the Organisation employed Magento Cloud, a cloud-based service, to host and run the Website. Magento Cloud includes the Magento Content Management System (“Magento CMS”), an open-source e-commerce management software, which the Organisation used to change and update the Website. Second, the Organisation used a payment platform offered by Adyen N.V. (“Adyen”) to facilitate credit card payments on the Website. When a customer indicated that they intended to pay for their purchases via credit card, Adyen’s platform would load directly from their servers as a frame within the “checkout” page of the Website (the “Checkout Page”). 3 Customers would then input the below details into Adyen’s frame, and Adyen would directly collect these details and process the credit card payment: (a) Full credit card number; (b) Expiry date of the credit card; 2 (c) The CVV number of the credit card; and (d) Customer’s billing address (collectively, the “Credit Card Data”) 4 Once Adyen has processed the credit card payment, it would send some (but not all) of the Credit Card Data to the Organisation, namely: (a) The last 4 digits of the credit card number; (b) Expiry date of the credit card; (c) Adyen’s payment reference; and (d) Billing address. (collectively, the “Partial Credit Card Data”) 5 The Organisation would then store the Partial Credit Card Data together with other details collected by the Organisation for the purposes of processing the order (the “Order Data”). The Order Data comprised the following personal data of the Organisation’s customers: (a) First name; (b) Last name; (c) Shipping address; (d) Date of birth (optional); (e) Phone number; (f) Email address; (g) Order details; (h) Payment type: Paypal, credit card (i.e., Visa, Mastercard), bank transfer; and 3 (i) If payment was made via: (i) Credit Card: Partial Credit Card Data; or (ii) Paypal: the email address associated with the Paypal account (if the customer in question completed the transaction using his/her Paypal account). 6 On or around 22 November 2019, the Organisation noted a high drop in credit card authorisations for payments via Adyen’s platform and began investigating the issue with Adyen. It was discovered that the Checkout Page had been configured to load an incorrect form replacing Adyen’s frame on the Checkout Page. This incorrect form had not been submitted via Magento CMS or validated by any of the Organisation’s employees, and the Organisation was unable to determine the source of the form. The next day, the Organisation implemented a fix to replace the incorrect form with the correct one, in order to allow the processing of credit card payments to resume through Adyen’s platform, while root cause analysis was undertaken. 7 Subsequently, on or around 9 December 2019, the same issue resurfaced. As a precaution, the Organisation turned off the credit card payment functionality on the Checkout Page, and continued investigations into the issue with Adyen, Magento, and subsequently a private forensic investigator (“PFI”). 8 Based on these further investigations, it was concluded that: (a) One of the Organisation’s Magento CMS accounts with administrator privileges was likely to have been compromised (the “Compromised Account”); (b) The Compromised Account was likely used to modify the Checkout Page to load and execute an unauthorised JavaScript code each time the Checkout Page was loaded (“the Unauthorised Code”); (c) The Unauthorised Code caused the Credit Card Data intended to be sent to Adyen to be intercepted and exfiltrated to the malicious actor instead (explaining the drop in credit card transactions); and 4 (d) The Compromised Account was also used by the malicious actor to access and exfiltrate Order Data from the Website via unauthorised Application Programming Interface (“API”) calls to Magento CMS. 9 The personal data of a total of 5,561 customers was accessed and exfiltrated in the Incident of which: (a) 4,817 customers had only their Order Data affected; (b) 188 customers had only their Credit Card Data affected: and (c) 556 customers had both their Order Data and Credit Card Data affected. Remedial actions 10 Following the Incident, the Organisation: (a) Removed the Unauthorised Code from the Website; (b) Notified affected customers of the Incident and offered a complimentary credit monitoring service; (c) Reset the passwords for all Magento CMS user accounts; (d) Implemented a new password policy and two-factor authentication for all Magento CMS user accounts; (e) Implemented session management; (f) Reviewed its Magento CMS access permissions, refined the scope of roles, and limited the number of users with Magento CMS accounts; (g) Implemented a remote access virtual private network; (h) Implemented endpoint protection; (i) Implemented a custom script to monitor for JavaScript injections; (j) Set up API “whitelisting” to restrict network access to only approved IP addresses; 5 (k) Implemented a monitoring script to trigger alerts whenever there was a request from a non-trusted domain; (l) Conducted two external penetration tests; (m) Upgraded its version of Magento CMS to fix a security vulnerability found in the version it was using; and (n) Implemented CAPTCHA on its Website to deter brute-force attacks. Findings and Basis for Determination 11 As a preliminary point, both the Order Data and the Credit Card Data constituted personal data as defined by section 2(1) of the Personal Data Protection Act 2012 (“PDPA”) 1 . In respect of the Order Data, distinct individuals could be identified from such data. In respect of the Credit Card Data, although such data could not identify any individual on its own, it could identify individuals together with other data that the Organisation had access to (viz., the Order Data). Whether the Organisation had contravened section 24 of the PDPA 12 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). While the Organisation did not have possession of the Credit Card Data (i.e. because it did not collect or store the Credit Card Data), the Protection Obligation nonetheless applied, as it had control over the Credit Card Data. 13 As highlighted in Re AIG Pacific Insurance Pte. Ltd. [2018] SGPDPC 8 at [18]: “While there is no definition of “control” in the PDPA, the meaning of control in the context of data protection is generally understood to cover the ability, 1 Under section 2(1) of the PDPA, “personal data” is defined as “data, whether true or not, about an individual who can be identified (a) from that data; or (b) from that data and other information to which the organisation has or is likely to have access”. 6 right or authority to determine (i) the purposes for; and/or (ii) the manner in which, personal data is processed, collected, used or disclosed.” 14 In this case, the Organisation made the decision to deploy Adyen’s HTML code within a frame on the Checkout Page, and this decision directed the manner in which the Credit Card Data was collected, processed and disclosed via the Website. Thus, even though the Credit Card Data was sent to Adyen directly without first being collected and stored by the Organisation, the Organisation had control over how the Credit Card Data was collected, and the additional processing into a format which was then transmitted to Adyen. The Organisation exercised such control by implementing (or deploying) Adyen’s HTML code within a frame on its Checkout Page. 15 The application of the Protection Obligation to the Order Data is more straight forward as this dataset was collected and stored by the Organisation. As the Organisation had possession of the Order Data and control over the Credit Card Data, the Protection Obligation applied in respect of both datasets. 16 In assessing the reasonableness of the Organisation’s security arrangements, the fact that the data within its control included personal data of a financial nature (i.e. the Credit Card Data) was considered highly relevant. As highlighted in the Commission’s previous enforcement decisions, stronger security measures are called for when protecting sensitive personal data because of the potential harm that may befall an individual from unauthorised use of such data.2 17 For the reasons set out below, the Organisation failed to put in place such reasonable security arrangements to protect the Order Data and Credit Card Data. Inadequate password policy 18 A robust password policy is a key security measure that an organisation must have in place to ensure that its IT systems are not vulnerable to common hacking attempts such as brute force attacks. As noted in Re (1) The Cellar Door Pte Ltd; (2) Global Interactive Works Pte. Ltd. [2016] SGPDPC 22 (at [30(d)]): 2 Credit Counselling Singapore [2017] SGPDPC 18 at [25]; PeopleSearch Pte. Ltd. [2019] SGPDPC 47 at [10]. 7 “… The need to have a strong password is fundamental to the security of the database system. Weak passwords increase the chances of an intruder cracking the password and gaining full access to the database system, and, more importantly, the personal data stored therein.” 19 Magento CMS had several default security settings and the Organisation confirmed that it had adopted these default settings as its password policy for its Magento CMS accounts (the “Magento Password Policy”). While default settings of the Magento Password Policy on password length, and the implementation of a lockout after a number of failed login attempts were in line with good practices suggested in the Commission’s Guide to Securing Personal Data in Electronic Medium (the “Guide”)3, more robust and stringent measures were required. 20 First, the Magento Password Policy did not mandate periodic changes of passwords as part of the default settings, despite the availability of this functionality in Magento CMS. As stated in paragraph (g) of Table 4 in the Guide: “Users are required to change their passwords regularly. The frequency should be based on the risk of damage to the individual if the data is compromised.” [Emphasis added.] 21 Second, the default settings of the Magento Password Policy did not require the Organisation’s employees to refrain from using easily-guessable passwords. As highlighted in Re Chizzle Pte Ltd [2020] SGPDPCR 1, a password that complies with an organisation’s rules on password complexity in form, could still be regarded as a weak password if it incorporated components such as the organisation’s name. In this respect, the Organisation ought to have complemented the technical Magento Password Policy with a written password policy. Both written and technical policies reinforce each other. Technical policies alone may not ensure that users refrain from incorporating easily-guessable words or phrases such as their user name, real name, 3 Published on 8 May 2015, and revised on 20 January 2017. The Guide has recently been replaced by a new Guide to Data Protection Practices for ICT Systems. All references to the Guide in these grounds are to the 2017 edition. 8 birth date, or the organisation’s name in the password. In this case, the password of the Compromised Account – “ilovebonito88” – incorporated the Organisation’s name, which made it easy to guess and vulnerable to brute force attacks. 22 For these reasons, the out-of-the-box default settings of the Magento Password Policy was not sufficiently robust for the Organisation’s needs and failed to meet the standard of being a reasonable security arrangement under the Protection Obligation. Weaknesses in the Organisation’s host, network, remote access, and webpage security 23 There were other significant weaknesses in the Organisation’s IT systems identified by the PFI that could have also been exploited by malicious actors to gain privileged access to Magento CMS: (a) The Organisation’s system allowed insecure remote access, with no / limited system logging and no / limited system hardening; (b) The Organisation’s system was not patched / maintained; (c) There was a lack of security monitoring for the Organisation’s network; (d) There was a lack of network ingress and egress filtering of the Organisation’s network to examine network traffic; (e) There was a lack of monitoring and logging of remote access connection attempts; and (f) 24 There was improper access control in respect of Magento CMS. The above weaknesses indicated that the IT security measures implemented by the Organisation were inadequate in managing the risks of unauthorised access and exfiltration of the Credit Card Data and Order Data. 25 The above security measures did not meet the standard of reasonableness, and the Commissioner finds the Organisation in breach of the Protection Obligation in this regard. 9 The Preliminary Decision 26 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty, the factors listed at section 48J(6) of the PDPA were taken into account, as well as the following mitigating factors: Mitigating Factors (a) The Organisation took prompt remedial actions following discovery of the Incident, including notifying affected individuals of the breach; and (b) 27 The Organisation was cooperative during the investigations. In the preliminary decision, the Organisation’s failure to implement two-factor authentication (“2FA”) to secure privileged access to Magento CMS was also considered as an instance of breach of the Protection Obligation – this is discussed further below at [33] to [36]. Having considered all the relevant factors of this case, the preliminary financial penalty was set at $29,000. 28 The Organisation was notified of the preliminary decision by way of the Commission’s letter dated 21 June 2021 and was invited to make representations on the same. Representations Made by the Organisation 29 On 12 July 2021, the Organisation made representations that it ought not be found in breach of section 24 of the PDPA because: (a) The Organisation’s measures to safeguard its administrative accounts were reasonable; and (b) It could not be conclusively determined that the weaknesses in the Organisation’s IT systems had directly caused the Incident. 10 Representations on reasonableness of security measures for Magento CMS 30 The Organisation represented that its security measures for Magento CMS were commensurate with the risks associated with a potential data breach, as: (a) Magento CMS was only intended to collect and store the Order Data, which was less sensitive personal data; and (b) The risk of compromise to the more sensitive Credit Card Data via Magento CMS was assessed to be relatively low, where the Credit Card Data was collected directly by Adyen via a frame on the Website’s Checkout Page loaded directly from Adyen’s server, without such data being transmitted to the Organisation. 31 The Organisation’s representations in this regard are not accepted. While it is accepted that the Credit Card Data was not transmitted to the Organisation and was collected directly by Adyen via the Checkout Page of the Website, access and changes to the Website were in turn managed and carried out by the Organisation via Magento CMS. There was therefore a foreseeable risk that unauthorised access to the Website using one of the Organisation’s Magento CMS administrative accounts could lead to unauthorised changes to the Checkout Page, adversely affecting its intended function and performance. Such unauthorised changes could include the insertion of a malicious code to intercept and exfiltrate the Credit Card Data collected via the Checkout Page. 32 The Credit Card Data was collected via the Website, and it was for the Organisation to secure the Website against unauthorised changes in order to protect the Credit Card Data. Put differently, the Organisation’s Protection Obligation extended over the Website in its entirety, including the Checkout Page. The Organisation was therefore incorrect in assessing that there was a low risk of compromise to the Credit Card Data via Magento CMS. The security measures implemented by the Organisation for Magento CMS and in its databases and systems did not constitute reasonable security measures, having regard to the risks in the context of the sensitivity and volume of the personal data in its possession and/or control. 11 Representations on failure to enable 2FA for administrative accounts 33 In the present case, 2FA was available as an “out-of-the-box” feature in Magento CMS. In the preliminary decision, the Organisation’s failure to enable 2FA in Magento CMS was found to be another instance of its breach of the Protection Obligation. 34 The Organisation represented that 2FA was not an out-of-the-box feature in Magento CMS version 2.3.2, which the Organisation was using at the time of the Incident, and that the option to activate 2FA was only available in Magento CMS version 2.4, via a third-party vendor (GitHub) module “MSP_TwoFactorAuth”. However, according to publicly available Magento version 2.3.x user guides – and contrary to the Organisation’s representations – 2FA was already a feature available on Magento CMS version 2.3.2, albeit at that version, 2FA was not enabled by default. 35 The Organisation also represented that even if 2FA had been implemented, it would not have prevented the Incident as the “2FA functionality in Magento CMS version 2.4 would only have restricted unauthorised access via the graphical user interface (“GUI”) of Magento CMS” and that “(…) 2FA would not have prevented API calls to Magento CMS, which was the actual mechanism by which the Organisation’s website was modified during the Incident”. In an investigation summary report prepared by Magento in respect of the Incident, Magento did not find any evidence of changes made to the Organisation’s website made via the GUI, and concluded that it was “more likely” that the administrative account belonging to [redacted] was used “to make modifications and access information via API requests”. 36 After careful consideration of the Organisation’s representation, it is decided that the benefit of doubt ought to be given to the Organisation on the preliminary findings and its representations concerning the implementation of 2FA for two reasons. First, the external actor accessed and modified the Organisation’s Website via API calls to Magento CMS (as opposed to via the GUI of Magento CMS), which made the attack a sophisticated one. Second, the Organisation’s failure to consider enabling the out-of-the-box 2FA functionality within Magento CMS was but one of several instances 12 supporting the finding of its breach of the Protection Obligation. The finding of breach is maintained on the basis of other instances of breach. Representations on other weaknesses in IT systems 37 The Organisation’s representation that it cannot be conclusively determined that the weaknesses in its IT systems had directly caused the Incident (see [29(b)] above) is rejected. The Commission’s role is not limited to investigating the immediate or proximate cause of the data breach although this may have been one of the lines of inquiry. The Commission’s investigations found that other weaknesses in the Organisation’s IT systems posed risks to personal data in the Organisation’s possession and/or control, including Order Data that it collected and processed. The Organisation ought to have implemented reasonable security measures to manage these risks. In failing to do so, the Organisation breached the Protection Obligation. Other representations seeking reduction in financial penalty 38 The Organisation also made representations for a reduction in the financial penalty on the basis that: (a) It was inaccurate to state the number of affected individuals as 5,561, as only 4,474 individuals in Singapore were affected; (b) The Organisation had admitted to the Incident at first instance; (c) The Organisation had promptly alerted customers of the Incident and offered a complimentary credit monitoring service; (d) There were no other data breach incidents reported apart from the Incident; and (e) The Organisation had in place existing security measures to guard against unauthorised access to databases and systems. 39 The Organisation’s attempt to confine the number of affected individuals in the Incident to those in Singapore is misconceived and is rejected. The PDPA requires organisations to protect all personal data in their possession or control, and does not 13 draw distinctions between the personal data of individuals in Singapore and outside of Singapore. 40 As to the factors raised by the Organisation at [38(b)] to [38(e)] above, these had already been taken into account in the assessment of the appropriate financial penalty to be imposed. 41 In the preliminary decision, the preliminary financial penalty was derived considering, inter alia, the gravity of the Organisation’s breach of the Protection Obligation in failing to consider implementing 2FA, which was available out-of-the-box. As the Organisation’s representations that 2FA may not have prevented the Incident are accepted, the gravity of the Organisation’s breach is lessened, and it follows that the quantum of the financial penalty should also be moderated. 42 Having said that, the Organisation’s breach included more fundamental failures, such as failing to implement a robust password policy and to refrain the Organisation’s employees from using easily-guessable passwords. Regardless of whether 2FA would have prevented the specific vector of attack adopted by the threat actor, the harm caused to data subjects in the Incident remains the same. 43 For the above reasons, the Commissioner is of the view that based on the representations made by the Organisation, the preliminary financial penalty of $29,000 should be reduced to $24,000. The Commissioner hereby requires the Organisation to pay a financial penalty of $24,000 within 30 days from the date of the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts would accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 44 In view of the remedial actions already been taken by the Organisation, no further directions need be issued to the Organisation. 14 Two- or multi-factor authentication as mandatory baseline standard for administrative accounts with privileged access to systems that host or process sensitive personal data 45 As 2FA and multi-factor authentication (“MFA”) become more broadly available, the adoption of these tools should become the norm, at least for accounts with administrative privileges. 46 Recently, the Commission released a handbook on common causes of data breaches (How to Guard Against Common Types of Data Breaches4, at page 13) that recommends 2FA / MFA for all administrator access to systems holding large volumes / sensitive personal data: “Have stronger requirements for some administrative accounts (e.g. a complex password or 2-Factor Authentication (2FA) / Multi-Factor Authentication (MFA)). With 2FA/MFA in place, access to administrative accounts would involve additional round (s) of authentication, such as a temporary code sent securely to the administrator’s mobile phone. Hence, the use of a stolen password alone will not be enough to breach an account. This is important for administrative accounts to systems that hold large volumes of personal data, or personal data of a confidential or sensitive nature (e.g. financial or health records), where a breach of such data could result in adverse impact to the affected individuals.” [Emphasis added] 47 The Commission’s recent Guide to Data Protection Practices for ICT Systems5 at page 16 similarly recommends using “a one-time password (“OTP”) or 2FA/MFA for admin access to sensitive personal data records or large volumes of personal data”, as part of the authentication and authorisation processes in ICT systems. 4 https://www.pdpc.gov.sg/-/media/files/pdpc/pdf-files/resource-for-organisation/how-to-guard-againstcommon-types-of-data-breaches-handbook.pdf 5 https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Other-Guides/Tech-Omnibus/How-toGuard-Against-Common-Types-of-Data-Breaches-Handbook.pdf 15 48 This is the baseline standard that the Commission will apply in future cases. This is not a standard that was adopted lightly, but after industry consultation and considering developments domestically and internationally. 49 In recent domestic cases, the Commission has observed that 2FA was implemented by the Organisations involved as part of voluntary remedial measures: (a) In MSIG Insurance (Singapore) Pte Ltd and Globalsign.in Pte Ltd [2019] SGPDPC 43, an administrative account for the organisation’s email marketing system was hacked, resulting in spam emails being sent to over 350,000 individuals. The organisation was found in breach of the Protection Obligation for not implementing a proper password policy or carrying out periodic security scanning. As part of voluntary remedial measures, the organisation implemented 2FA for its administrative accounts. (b) In Ncode Consultant Pte Ltd [2019] SGPDPC 11, students exploited vulnerabilities in a school’s administration system (which had been developed by the investigated organisation), obtained a teacher’s login credentials, and modified examination results. The organisation was found in breach of the Protection Obligation for insecure coding which resulted in the exploited vulnerabilities. As part of voluntary remedial measures, the organisation implemented 2FA for the teachers’ accounts. (c) In Learnaholic Pte Ltd [2019] SGPDPC 31, an employee of the investigated organisation (a school IT vendor) had his email account hacked, resulting in unauthorised access to a large number of students’ personal data including medical information. The organisation was found in breach of the Protection Obligation for negligently leaving one of the school’s servers exposed to the Internet, leaving credentials to the employee’s email account in the exposed server, and storing students’ personal data in the employee’s email account in an unencrypted form. The organisation implemented 2FA for its employees’ email accounts as part of voluntary remedial measures. 16 50 A review of guidance and cases from foreign jurisdictions shows that implementing 2FA (or similar arrangements) to secure privileged access to sensitive data is by now a reasonable and industry-standard practice: (a) United Kingdom. In two separate guidance notes, i.e. “Multi-factor authentication for online services”6 and “10 Steps to Cyber Security – Identity and access management”7, UK’s National Cyber Security Centre advises that MFA be enabled for all accounts with administrative privileges. (b) Canada. The Privacy Commissioner of Canada (“PCC”) has cited the failure to implement MFA to secure all remote administrative access as a significant data protection failing in the Joint Investigation of Ashley Madison by the Privacy Commissioner of Canada and the Australian Privacy Commissioner/Acting Australian Information Commissioner 8 , where the personal data of 36 million customers of the investigated organisation (including sensitive personal and financial data) was published online. In a subsequent note on takeaways from the investigation 9 , the PCC described MFA as a commonly recommended industry practice for controlling remote administrative access, and recommended that MFA be so implemented in all such cases. (c) Australia. The “Australian Government Information Security Manual”, a cybersecurity framework for organisations published by the Australian Cyber Security Centre 10 , recommends that MFA be used to authenticate all (i) privileged users, (ii) positions of trust, (iii) users of remote access solutions, and (iv) users with access to important data repositories. The Office of the Australian Information Commissioner, in its “Guide to securing personal information”11 recommends that MFA be employed in circumstances that may 6 https://www.ncsc.gov.uk/guidance/multi-factor-authentication-online-services 7 https://www.ncsc.gov.uk/collection/10-steps/identity-and-access-management 8 Joint Investigation of Ashley Madison by the Privacy Commissioner of Canada and the Australian Privacy Commissioner/Acting Australian Information Commissioner (PIPEDA Report of Findings #2016-005, 22 August 2016) 9 https://www.priv.gc.ca/en/privacy-topics/business-privacy/safeguards-and-breaches/safeguardingpersonal-information/2016_005_ta/ 10 https://www.cyber.gov.au/acsc/view-all-content/guidance/authentication-hardening 11 https://www.oaic.gov.au/privacy/guidance-and-advice/guide-to-securing-personal-information/ 17 pose a higher security risk, such as remote access to a system or access to sensitive or restricted personal information. 51 Henceforth, the Commission adopts the following tiered approach: (a) First, 2FA / MFA should be implemented as a baseline requirement for administrative accounts to systems that hold personal data of a confidential or sensitive nature, or large volumes of personal data: see [46]-[47] above. Failure to do so can ipso facto amount to a breach, unless the organisation can show that its omission is reasonable or implementation of 2FA is disproportionate. (b) Second, remote access by privileged accounts to information systems that host confidential or sensitive personal data, or large volumes of personal data, should a fortiori be secured by 2FA / MFA. The risks concerning remote access are higher, thus the expectation to implement 2FA / MFA will correspondingly increase. (c) Third, organisations using IT systems to host confidential or sensitive personal data, or large volumes of personal data, are expected to enable and configure 2FA / MFA, if this is a feature that is available out-of-the-box. Omission to do so may be considered an aggravating factor. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 18 ",Financial Penalty,89b55bd8d0fb6740006b25908bf6eba6b220b5c5,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,35,35,1,952,Royal Caribbean Cruises (Asia) was found not in breach of the PDPA in relation to a coding error in a business software which resulted in emails containing personal data being sent to unintended recipients.,"[""Protection"", ""Not in Breach"", ""Arts, Entertainment and Recreation"", ""Software"", ""Unintended recipient""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Royal-Caribbean-Cruises-Asia-Pte-Ltd--130819.pdf,Protection,No Breach of the Protection Obligation by Royal Caribbean Cruises (Asia),https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/no-breach-of-the-protection-obligation-by-royal-caribbean-cruises,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1804-B1931 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Royal Caribbean Cruises (Asia) Pte. Ltd. SUMMARY OF THE DECISION 1. On 5 April 2018, the Personal Data Protection Commission (“Commission”) commenced investigation against Royal Caribbean Cruises (Asia) Pte Ltd (the “Organisation”) after receiving a complaint from a member of the public (the “Complaint”). The complainant stated that she had received the personal data of unrelated individuals in an email payment reminder sent by the Organisation. 2. Investigations revealed that, from 8 February 2018 to 4 April 2018, the personal data of 526 individuals were inadvertently disclosed to other unrelated members of the public via unintended email payment reminders (the “Data Breach Incident”). The personal data disclosed included booking IDs, ship codes, sailing dates, names, net amounts due, amounts paid, balance due and the balance due date (the “Affected Personal Data”). 3. The Organisation is part of the Royal Caribbean Group, and is the wholly owned subsidiary and data intermediary of the USA-based Royal Caribbean Cruises Ltd 1 (Liberia) (“RCL”). It is responsible for the following business functions on behalf of RCL: (a) Conducting sales and marketing activities on behalf of the cruise ship operators of the Royal Caribbean Group, including RCL; (b) Taking cruise bookings from Singapore-based customers of RCL; (c) Administering a loyalty membership programme on behalf of RCL; and (d) Collecting payments from Singapore-based customers of RCL who made their bookings via walk-in, roadshows and online bookings at the Royal Caribbean Group’s Singapore website. 4. RCL’s branch office in the Philippines (“RCL Philippines”) provides IT support to entities within the Royal Caribbean Group, and does not have a separate legal identity from RCL. On 1 January 2017, the Organisation entered into an operative intercompany agreement with RCL Philippines for the provision of IT support and customer services support. Such services included providing technical support for the business software applications and services used by the Organisation. 5. As part of its business functions, the Organisation would send its Singapore customers email payment reminders prior to the commencement of their cruises. On 8 February 2020, the Organisation automated this business function through a business software enterprise operated by RCL Philippines (the “Hyperion System”), which would generate pre-programmed emails to individual customers to remind them of outstanding bill amounts (the “Direct Payment Reminder”). Concurrently, a collated list of the customers (together with other personal data) who received the Direct Payment Reminder would be generated and sent via email 2 to the Organisation (“Collated Payment Reminder”). Both the Direct Payment Reminder and Collated Payment Reminder were automatically generated on a scheduled frequency and sent to the customers and Organisation by the Hyperion System without any manual intervention from the Organisation (the “Automated Payment Reminder System”). 6. The Automated Payment Reminder System had been successfully implemented in other countries, and RCL Philippines put in place the following process to handle requests from Royal Caribbean Group entities related to the Hyperion System: (a) RCL Philippines would receive a request from respective Royal Caribbean entity for a new process to be implemented in the Hyperion System; (b) RCL Philippines would review the scope of the request and configure the Hyperion System; (c) RCL Philippines would then run a test cycle and a test email would be generated to RCL Philippines to test for whether the content was in line with the request by the requesting Royal Caribbean entity; (d) Thereafter, RCL Philippines would send a sample of the output email to the relevant Royal Caribbean entity to review; and (e) The relevant Royal Caribbean entity would sign off on the implementation and RCL Philippines would then implement the new process to go live. 7. Investigations revealed that the Data Breach Incident occurred because RCL Philippines made an error in the coding of the email parameters in the Structured Query Language (“SQL”) script when configuring the Hyperion System as described in paragraph 6(b), leading to the Collated Payment Reminders being 3 sent to the first customers in the mailing lists instead of the Organisation. Consequently, the personal data of the Singapore customers contained in the Collated Payment Reminders were disclosed to certain unrelated customers. 8. Both the Organisation and RCL Philippines were not aware of this error until they were informed of the Complaint to the Commission referenced in paragraph 1. As the Automated Payment Reminder System was new and unfamiliar to the Organisation at the material time, the Organisation and its employees were also not aware that it was supposed to be receiving the Collated Payment Reminders. 9. The Data Breach Incident happened after the Organisation provided lists of Singapore customers with outstanding payments due to RCL Philippines for processing with the Hyperion System. The Commission is of the view that the coding error that occurred during the configuration of the Hyperion System was wholly within RCL Philippines’ operations and that the Data Breach Incident did not arise from any business functions that the Organisation was conducting as a data intermediary on behalf of RCL. 10. In the above circumstances, the Deputy Commissioner for Personal Data Protection finds that the Organisation was not in breach of the Protection Obligation under section 24 of the PDPA. 4 11. We note that the Organisation had taken the following remedial actions: (a) Conducted additional trainings for its employees to be mindful of the importance of data protection in its business processes; (b) Reviewed its supervisory framework for new employees so that similar incidents would not happen again; and (c) Reviewed its communication with RCL Philippines for implementation of any new processes. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. 5 ",Not in Breach,0d00bbb6002dda7ff71a02aa63df23ee41375297,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,36,36,1,952,Singtel was found not in breach of the PDPA in relation to an incident which occurred on or about 20 January 2021 whereby threat actor(s) exfiltrated personal data by exploiting zero-day vulnerabilities of a third party file transfer appliance.,"[""Protection"", ""Not in Breach"", ""Information and Communications""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Telecommunication-Limited---101221.pdf,Protection,No Breach of the Protection Obligation by Singapore Telecommunications (Singtel),https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/no-breach-of-the-protection-obligation-by-singapore-telecommunications,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2102-B7878 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Telecommunication Limited SUMMARY OF THE DECISION 1. On 10 February 2021, Singapore Telecommunication Limited (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a personal data breach that had occurred through the exploitation of zero-day vulnerabilities in a File Transfer Appliance (“FTA”) provided by a third party system (the “Incident”). 2. As a result of the Incident, 9,921 files containing personal data were exfiltrated. The personal data of 163,370 individuals which included their name, NRIC number, FIN, UIN, nationality, date of birth, address, email address, mobile number, photograph, staff, company pass or ID, bank account number, credit Page 1 of 3 card information (with expiry date), billing information, and vehicle number were affected. 3. The Organisation engaged an external cybersecurity company, FireEye Mandiant, to investigate the Incident. Its investigations found that the threat actors had exploited two (2) zero-day vulnerabilities of the FTA to gain unauthorised access to the FTA’s MySQL database and subsequent file downloading. 4. Investigations revealed that the Organisation had a license to use the FTA with the FTA developer, Accellion Pte Ltd (“Accellion”). Accellion was the only party that had access to the proprietary source code to the FTA system. Accordingly, the discovery and rectification of the zero-day vulnerabilities within the FTA system fell within the sole responsibility and control of the developer. We are of the view that the Organisation could not have detected or prevented the incident as it had no control or visibility of the zero-day vulnerability of the FTA. 5. The Organisation had provided and made reasonable security arrangements to protect personal data in its possession and/or control in relation to the Incident. The Organisation maintained the practice of updating and patching the FTA within five (5) days of patch/update receipt. 6. Following the Incident, the Organisation took prompt and extensive remedial both to mitigate the effects of the Incident and enhance the robustness of its security measures. This included shutting down the FTA, conducting thorough Page 2 of 3 review of processes and file sharing protocols to enhance information security posture, and offering identity monitoring service to the affected individuals. 7. In view of the above, the Deputy Commissioner for Personal Data Protection is satisfied that the Organisation had met its Protection Obligation under section 24 of the PDPA and cannot be held liable for zero-day vulnerabilities on a third party system. No enforcement action therefore needs to be taken in relation to the Incident. The following provision(s) of the Personal Data Protection Act 2012 had been cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. Page 3 of 3 ",Not in Breach,572fbbe0157ad79a81e4ed46fce23091a479c4f6,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"