_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,1,1,1,952,"A financial penalty of $9,000 was imposed on Century Evergreen for failing to put in place reasonable security arrangements to protect the personal data of jobseekers in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Employment"", ""URL manipulation""]",2023-09-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Century_Evergreen_260723.pdf,Protection,Breach of the Protection Obligation by Century Evergreen,https://www.pdpc.gov.sg/all-commissions-decisions/2023/09/breach-of-the-protection-obligation-by-century-evergreen,2023-09-15,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPCS 5 Case No. DP-2212-C0526 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Century Evergreen Private Limited SUMMARY OF THE DECISION 1. On 11 December 2022, the Personal Data Protection Commission (the “Commission”) received a complaint against Century Evergreen Private Limited (the “Organisation”) that images of identification documents (which includes the National Registration Identity Card) submitted by jobseekers to the Organisation were publicly accessible on the Organisation’s website (“Incident”). The Organisation is a manpower contracting services company and required jobseekers to submit their identification documents to verify the identity of and suitability of the jobseeker in question. 2. Following the complaint received, the Commission commenced investigations to determine the Organisation’s compliance with the Personal Data Protection Act 2012 (“PDPA”). The Organisation requested that the investigation be handled under the Commission’s Expedited Decision Procedure (“EDP”). This means that Page 1 of 5 the Organisation voluntarily provided and admitted to the facts set out in this decision. The Organisation also admitted that it failed to implement reasonable security arrangements to protect the personal data in its possession and control, and was in breach of section 24(a) of the PDPA. 3. The Organisation admitted that the Insecure Direct Object References (“IDOR”) vulnerability on its website, which allowed the complainant to manipulate the URL had existed from the time the website was launched on 9 November 2015. As a result of this vulnerability, 96,889 images of identification documents belonging to 23,940 individuals were downloaded from the Organisation’s website from 10 to 12 December 2022. 4. The Organisation admitted that it was in breach of section 24(a) of the PDPA as it failed to include any security requirements to protect personal data in its contract with the vendor who first developed and subsequently maintained the website. In this regard, even though the Organisation had engaged an IT vendor from the time the website was developed and launched, the Organisation remained solely responsible for protecting the personal data in its possession and control at all material times. 5. What is expected from organisations who engage professional services to build their websites and other online portals is explained in the Commission’s Guide on Building Websites for SMEs (revised 10 July 2018) (the “Guide”). The Commission had consistently advised organisations of the need to emphasise the protection of Page 2 of 5 personal data to their IT vendors, by making it part of their contractual terms.1 The contract should clearly state the responsibilities of the IT vendor with respect to the PDPA. In this regard, the Commission noted that there was a glaring omission of clauses to protect personal data in the Organisation’s contract with its IT vendor. 6. The Organisation also admitted that apart from conducting functionality testing when the website was first launched, the Organisation had no arrangements with its IT vendor to conduct any security tests prior to the launch of the website, or thereafter. The Organisation had also failed to impose any security requirements on the IT vendor to protect personal data, via contract. 7. In view of the above, the Deputy Commissioner found that the Organisation had contravened section 24(a) of the PDPA. 8. In deciding the appropriate outcome in this case, the Commission considered that a financial penalty ought to be imposed as the personal data affected included not just the identification numbers, but the images of the identification documents. Furthermore, there was a long period of non-compliance. The vulnerability was not addressed since 2015. 9. In deciding on the appropriate amount of financial penalty, the circumstances set out above and the factors listed at section 48J(6) of the PDPA were considered, specifically the impact of the personal data breach on the individuals affected and the nature of the Organisation’s non-compliance with the PDPA. In the circumstances, this was not an insignificant breach given the number of individuals 1 See Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1] and Re EU Holidays Pte Ltd [2019] SGPDPC 38. Page 3 of 5 affected (ie 23,940) and the nature of personal data exfiltrated: 96,889 images of identification documents. 10. The Organisation’s non-compliance with the PDPA was also not simply one of mere negligence but that of gross negligence. There was a long period of noncompliance on the facts of this case. As set out above, the Commission had issued the Guide to assist SMEs, and consistently cautioned the need for organisations to ensure compliance with the PDPA even when they engage an IT vendor in our previous decisions.2 11. In deciding on the appropriate amount of the financial penalty, the following factors were considered – the Organisation’s turnover and profitability, its cooperation throughout the investigation, its voluntary admission of breach of the Protection Obligation under the EDP, and the prompt remedial actions taken after the Organisation became aware of the IDOR vulnerability. This included rectifying the IDOR vulnerability, making server configuration changes to improve security, implementing vulnerability scans, migrating its backup server to an encrypted remote server, deploying additional security software and subscription to security services, and securing a new contract with its vendor to manage the security of its website. In addition to its prompt remedial actions, its poor performance in the most recent financial year was also taken into consideration. Finally, the organisation had admitted to its culpability at an early stage and elected to proceed under the EDP. 2 Re EU Holidays Pte Ltd [2019] SGPDPC 38 and Re Vhive Pte Ltd (Case No. DP-2013-B8138). Page 4 of 5 12. For the reasons above, the Deputy Commissioner for Personal Data Protection hereby finds the Organisation in breach and directs the Organisation to pay a financial penalty of S$9,000 within 30 days from the notice accompanying date of this decision, failing which interest at the rate specified in the Rules of Court in respect of judgement debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. The following section 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 5 of 5 ",Financial Penalty,3a409dde7f16bfa6ec2d01d5c2d7e80c9ec98146,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,2,2,1,952,"A financial penalty of $3,000 was imposed on Autobahn Rent A Car for failing to put in place reasonable security arrangements to protect the personal data in its possession or under its control. Directions were also issued to strengthen access control measures to administrator accounts and to conduct reasonable security review of technical and administrative arrangements for the protection of personal data.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Others""]",2023-09-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Autobahn-Rent-A-Car-Pte-Ltd_090623.pdf,Protection,Breach of the Protection Obligation by Autobahn Rent A Car,https://www.pdpc.gov.sg/all-commissions-decisions/2023/09/breach-of-the-protection-obligation-by-autobahn-rent-a-car,2023-09-15,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPCS 4 Case No. DP-2210-C0345 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Autobahn Rent A Car Pte. Ltd. SUMMARY OF THE DECISION 1 On 21 October 2022, Autobahn Rent A Car Pte. Ltd. (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a personal data breach (the “Incident”). 2 The Organisation operates a car-sharing service, Shariot, in Singapore. On 24 September 2022, the Organisation received customer feedback that a photograph on its mobile application had been replaced with a pornographic photograph. The Organisation discovered that the pornographic photograph had been uploaded through an unrevoked administrator account belonging to an ex-employee, who had Page 1 of 6 left the Organisation in May 2022. The ex-employee received an email from an unknown sender on 10 September 2022 stating that his personal laptop had been hacked and demanding Bitcoins as ransom payment. The threat actor was able to log into the Shariot’s mobile application administrator portal through the administrator account belonging to the ex-employee, and used the export CSV function to download a copy of the Shariot’s users personal data. 3 Subsequently, on 21 October 2022, a cybersecurity solutions provider alerted the Organisation of a cybercrime forum post offering the sale of a Shariot database containing personal data. The Commission commenced investigations to determine whether the Incident disclosed any breaches of the Personal Data Protection Act 2012 (“PDPA”) by the Organisation. 4 The Organisation requested, and the Commission agreed, for this matter to proceed under the Expedited Decision Breach Procedure. To this end, the Organisation voluntarily and unequivocally admitted to the facts set out in this decision. It admitted to a breach of the Protection Obligation under Section 24 of the PDPA. 5 The Organisation’s internal investigations discovered that compromise of the dormant administrator account credentials enabled the unauthorised access to Shariot backend admin web portal, leading to the exfiltration of 53,000 personal data sets of Shariot users. The personal data that were affected in the Incident included names, Page 2 of 6 email addresses, mobile phone numbers, NRIC numbers and general location data (e.g. Bishan, Toa Payoh or Orchard). 6 Following the Incident, the Organisation took the following remedial action: (a) Immediately conducted an internal audit of its administrator accounts to ensure that any employee access that was not required was revoked; (b) Enhanced its software code and admin panel user interface to mask displayed or exported NRIC numbers to show only the last 4 characters; and (c) Conducted cyber hygiene and awareness training for all staff handling personal data. 7 The Organisation admitted that it had failed to ensure it had reasonable security arrangements in place to prevent the unauthorized access or disclosure of the personal data in its possession or control, as it failed to implement and ensure reasonable access control to its backend admin web portal. First, the Organisation failed to revoke the login credentials of an administrator account belonging to an exemployee once the employment relationship came to an end in May 2022. As a result, the ex-employee’s administrator login credentials remained active, which – when compromised – enabled the malicious actor access into its network. 8 Second, the Organisation also admitted that the Incident would not have happened if it had implemented multi-factor authentication (“MFA”) as an additional Page 3 of 6 access control for its administrator accounts that had access to its sizeable user database. In Re Lovebonito [2022] SGPDPC 3, the Commission had highlighted the need for organisations to strengthen access control, through the use of a one-time password (“OTP”) or 2FA/MFA, to such accounts. Indeed, regardless of whether an account is an administrative account, once an account is granted access rights to a database containing sensitive personal data records or a significant volume of personal data that would adversely impact the affected individuals in the event of a personal data breach, we would encourage organisations to consider implementing enhanced access controls to the account such as through the use of a OTP or 2FA/MFA to better safeguard the personal data. 9 For the above reasons, the Organisation was determined to have breached the Protection Obligation. The Deputy Commissioner’s Decision 10 In determining whether the Organisation should be required to pay a financial penalty under Section 48J of the PDPA or if directions would suffice, I considered that a financial penalty was appropriate as the personal data breach was not insignificant. In deciding the appropriate financial penalty amount, I first considered all the relevant factors listed at Section 48J(6) of the PDPA, in particular, the impact of the personal data breach on the individuals affected and the nature of Organisation’s noncompliance with the PDPA. In this regard, while the NRIC numbers and general Page 4 of 6 location data was affected, this is less serious than if the NRIC images and specific GPS location had been disclosed. 11 In deciding what would be the appropriate financial penalty amount, I also considered the organisation’s turnover to arrive at a figure that would, in my mind, be a proportionate and effective amount, to ensure compliance and deter non-compliance with the PDPA. On the facts of this particular case, the organisation’s turnover has been taken into consideration to arrive at a proportionate and effective financial penalty. I also considered the following mitigating factors, which led to a further reduction in the financial penalty: (a) The Organisation was cooperative during the course of our investigations; (b) The Organisation voluntarily admitted to breach of the Protection Obligation under the Commission’s Expedited Decision Procedure; and (c) The Organisation took prompt remedial actions following discovery of the Incident. 12 For the reasons above, I hereby require the Organisation to pay a financial penalty of $3,000 within 30 days of the date of the relevant notices 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. Page 5 of 6 13 In addition to the financial penalty imposed, the Organisation is also directed to do the following: (a) Implement processes for systems and applications revocation within a reasonable window of cessation of need for access by an employee; (b) Strengthen access controls measures to administrator accounts with access to databases holding personal data; (c) Conduct reasonable security review of technical and administrative arrangements for the protection of personal data in possession or under control of the Organisation within 60 days of the date of this Direction; (d) Rectify any security gaps identified in the security review directed above; and (e) Inform the Commission within 1 week of the completion on the steps directed above. The following are the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation must 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 or disposal or similar risks and; (b) the loss of any storage medium or device on which personal data is stored. Page 6 of 6 ","Financial Penalty, Directions",458ca2b78344d38cc2dec8a4e89a493c8a7475a2,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,4,4,1,952,"A financial penalty of $74,400 was imposed on Ecommerce Enablers for failing to put in place reasonable security arrangements to protect users' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade""]",2023-08-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Ecommerce-Enablers.pdf,Protection,Breach of the Protection Obligation by Ecommerce Enablers,https://www.pdpc.gov.sg/all-commissions-decisions/2023/08/breach-of-the-protection-obligation-by-ecommerce-enablers,2023-08-16,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 6 Case No. DP-2009-B7056 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And E-Commerce Enablers Pte. Ltd. … Organisation DECISION Page 1 of 11 E-Commerce Enablers Pte. Ltd. Lew Chuen Hong, Commissioner — Case No. DP-2009-B7056 16 May 2023 Introduction 1 On 25 September 2020, E-Commerce Enablers Pte. Ltd. (“Organisation”) notified the Personal Data Protection Commission (“PDPC”) and its customers of an incident involving unauthorised access to its customer data servers (the “Incident”). PDPC subsequently received 2 complaints from the Organisation’s customers in relation to the Incident. On 12 November 2020, the Organisation's customer database was offered for sale on an online forum indicating that personal data was exfiltrated during the Incident. 2 PDPC commenced investigations to determine the Organisation’s compliance with the Personal Data Protection Act 2012 (“PDPA”) in relation to the Incident. Facts of the Case 3 The Organisation runs an online platform offering cashback for purchases made through affiliated merchant programs. The platform also provides coupons, voucher codes, and comparison features with discounts for users. 4 At the time of the Incident, the Organisation hosted its customer database on virtual servers in an Amazon Web Services (“AWS”) cloud environment (“Customer Page 2 of 11 Storage Servers”). The Organisation employed a 12-man Site Reliability Engineering (“SRE”) team whose responsibilities included maintaining the Organisation’s infrastructure, providing, and managing the Organisation’s cloud environment on AWS, and ensuring security of the AWS keys. The SRE team made use of an AWS access key with full administrative privileges (the “AWS Key”) for the purposes of its work, including infrastructure deployment. Only SRE team members had access to, and were authorised to use, the AWS Key. On 4 June 2019, the AWS Key was inadvertently committed to software code in a private repository in GitHub, by a senior member of the SRE team. This was discovered by another SRE team member on 6 June 2019, and the AWS Key was removed from GitHub on the same day. However, it remained viewable in GitHub’s ‘commit history’, which records all changes and previous versions of code uploaded on GitHub. 5 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 member of the SRE team in charge of the key rotation informed the SRE team (via email) that he had created a new key to replace the AWS Key, and that he would be deleting the AWS Key. However, after creating the replacement key, he failed to fully disable and remove the AWS Key. 6 As a result, the AWS Key continued to be usable to access the Organisation’s AWS environment (and consequently the Customer Storage Servers) until shortly after the time of the Incident, about 15 months later. Page 3 of 11 The Incident 7 On 9 September 2020, a malicious threat actor accessed the Organisation’s AWS environment utilizing the AWS Key. The AWS Key was likely found by the threat actor in the commit history of the GitHub private repository. 8 Having gained privileged access to the AWS environment, the threat actor (i) conducted reconnaissance to identify the Organisation’s data repositories, (ii) modified security settings including to allow remote internet access to the Organisation’s database instances (i.e. its virtual servers hosting data), and (iii) generated a fresh database instance to stage its data exfiltration. 9 The threat actor then proceeded to exfiltrate data from the Customer Storage Servers. The data items, and the corresponding number of individuals affected, are set out below: Types of personal data Email Address Number of affected users 1,457,637 Name 840,210 Mobile number 447,076 Address 138,327 Gender 23,278 NRIC numbers 9,961 Date of birth 202,634 Bank Account number 299,381 Partial credit card information, including: 378,531 Page 4 of 11 (i) partial credit card number (first 6 digits and last 4 digits) (ii) issuing bank (iii) country (iv) expiry month and year (v) Visa or Mastercard 10 On 17 September 2020, the Organisation discovered during a routine security review that there had been unauthorised access to its AWS environment. Further investigations revealed that there had been unauthorised third-party access to the Organisation’s AWS environment. 11 The Organisation subsequently engaged a private forensic expert, (“PFE”) to investigate further. The PFE confirmed that the unauthorised access had been carried out 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 despite the removal of the wrongly committed code from the private repository in GitHub. Remedial actions 12 Following the Incident, the Organisation implemented the following remedial measures: Immediate remedial steps to contain the Incident (a) Performed a full deletion of the AWS Key and rotated the other AWS keys; Page 5 of 11 (b) Reversed all changes made by the threat actor and triggered a forced logout and password reset of all customers’ accounts; To prevent recurrence or similar incidents (c) Increased monitoring of logs to ensure heightened detection of any unauthorised access; (d) Separated development and production accounts, resulting in a smaller subset of engineers having access to the production environment; (e) Secured access to systems and data with several measures, including VPN and IP address whitelisting and database encryption; and (f) Created a platform for employee security suggestions / breach reporting. Subsequent sale of personal data on Raidforums 13 On 12 November 2020, the Organisation’s database was offered for sale on Raidforums, an online cybersecurity forum commonly used for trading and selling of stolen databases. Raidforums’ domain name and content was independently seized by authorities from the United States in April 2022. Findings and Basis for Determination 14 Based on the circumstances of the Incident, the Commission’s investigation centred on whether the Organisation had breached its obligations under section 24 of the PDPA to protect personal data in its possession or under its control, by making reasonable security arrangements to prevent unauthorised access, collection, use, Page 6 of 11 disclosure, copying, modification, disposal, or similar risks (the “Protection Obligation”). The Organisation was determined to have breached the Protection Obligation in two respects. Lack of sufficiently robust processes for AWS key management 15 First, the Organisation failed to ensure that processes to manage the AWS keys that granted access to the Customer Storage Servers were sufficiently robust. 16 While the Organisation admitted that it could have done more to ensure that its employees were performing their AWS key rotation duties properly, the Organisation claimed that the compromise of the AWS Key arose from human error, and not because of any systemic issue with the Organisation’s security practices. According to the Organisation, 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 / deleted all other keys assigned to him in the out-of-cycle key rotation. The SRE team member’s inadvertent commit, and an incomplete rotation/deletion were in direct contravention of the Organisation’s security practices. The Organisation accordingly sought to frame the Incident as a one-off case of human error. 17 This position is not accepted. As explained in Re DataPost Pte Ltd, Organisations cannot place sole reliance on their employees to perform their duties properly as a security arrangement to protect personal data. There must be some Page 7 of 11 processes to ensure that the step required from the employee is taken, such as independent verification by another checker1. 18 For example, a precaution the Organisation could have taken to ensure that the out-of-cycle key rotation was complete would have been to have a supervisor or another SRE team member test either all or a reasonable sample of the old keys (depending on the number of keys being rotated) to verify that they had been disabled. There was no such verification or testing practice put in place by the Organisation; the Organisation relied wholly on the SRE team member’s seniority and experience. 19 When a high-risk task (e.g. rotation of an AWS key that gives access to the whole of the AWS environment) is concerned, it is all the more important that there must be additional verifications and checks. Failure to conduct periodic security review 20 Second, specific security review by the Organisation on AWS keys 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 15 months preceding the Incident. The Organisation failed to conduct regular security review on whether the AWS keys had been properly rotated/deleted. In the course of investigations, the Organisation acknowledged that it could have done more to ensure that the SRE team was performing their AWS key rotation duties properly. Following the Incident, the 1 Re DataPost Pte Ltd [2017] SGPDPC 10, at [13] – [16] Page 8 of 11 Organisation implemented a more secure process for temporary, time-limited keys to be issued to SRE team members whenever access to the AWS environment was required. The Organisation also developed a specific IT security policy concerning the secure sharing of keys internally. Observation on the incident management processes 21 Following discovery of the inadvertent committal of the AWS Key to GitHub, the Organisation took 15 days to conduct a key rotation. Regardless of whether this had been an out-of-cycle rotation, the Organisation should review its incident management processes to determine whether it was reasonable to have taken 15 days to remediate compromise of a full administrative privilege AWS access key. The Commissioner’s Decision 22 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty, the matters set out at section 48J(1) and the factors listed at section 48J(6) of the PDPA were taken into account, including the following aggravating and mitigating factors: Aggravating Factors (a) The Organisation lacked sufficiently robust processes to monitor its incident management response to ensure reasonable remediation speed, which led to 15 days passing before the Organisation responded to the exposure of the AWS Key; Page 9 of 11 (b) The AWS Key was exposed for a long period of 15 months; 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. 23 The Organisation was notified of the preliminary decision by way of the Commission’s letter dated 15 February 2023 and was invited to make representations on the same. The Organisation made representations on 22 March 2023, albeit not on its liability for breaches of the Protection Obligation or on the proposed financial penalty. Where accepted by the Commission, these representations have been incorporated into this decision. 24 Having considered all the relevant circumstances of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $74,400 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. Page 10 of 11 25 No further directions are necessary on account of the remedial measures already taken by the Organisation. Page 11 of 11 ",Financial Penalty,76e1a0c6ce1eec405d0c28dbde5757aff32b2192,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,5,5,1,952,"A financial penalty of $58,000 and $10,000 was imposed on Fullerton Healthcare and Agape CP Holdings respectively for failing to put in place reasonable security arrangements to protect personal data belonging to Fullerton Healthcare’s corporate clients and direct patients. Directions were also issued to both organisations to review and enhance processes relating to data handling processes, security audits and access controls to bolster their data protection arrangements.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Healthcare"", ""Public access""]",2023-06-22,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Fullerton-Healthcare-Group-and-Agape-CP-Holdings_230323.pdf,Protection,Breach of the Protection Obligation by Fullerton Healthcare and Agape CP Holdings,https://www.pdpc.gov.sg/all-commissions-decisions/2023/06/breach-of-the-protection-obligation-by-fullerton-healthcare-and-agape-cp-holdings,2023-06-22,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 5 Case Nos. DP-2110-B9054 / DP-2110-B9060 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Fullerton Healthcare Group Pte Limited (UEN No. 201020358N) (2) Agape CP Holdings Pte. Ltd. (UEN No. 201435153E) … Organisations DECISION 1 (1) Fullerton Healthcare Group Pte Limited (2) Agape CP Holdings Pte. Ltd. Lew Chuen Hong, Commissioner — Case Nos. DP-2110-B9054 / DP-2110-B9060 23 March 2023 Introduction 1 On 19 October 2021 and 21 October 2021, Fullerton Healthcare Group Pte Limited (“FHG”) and Agape CP Holdings Pte. Ltd. (“Agape”) respectively notified the Personal Data Protection Commission (the “Commission”) that the personal data of FHG’s customers had been accessed, exfiltrated, and offered for sale on the dark web (the “Incident”). The Commission commenced investigations to determine whether the Incident disclosed any breaches of the Personal Data Protection Act 2012 (“PDPA”) by FHG and Agape. 2 On 11 January 2022 and 12 January 2022 respectively, FHG and Agape requested for the investigations to be handled under the Commission’s Expedited Decision Procedure. In this regard, FHG and Agape voluntarily provided and admitted to the facts set out below and admitted that they had failed to implement reasonable 2 security arrangements to protect the personal data accessed and exfiltrated in the Incident in breach of section 24 of the PDPA (the “Protection Obligation”). Facts of the Case 3 FHG is an enterprise healthcare service provider which provides healthcare services to individuals and employees of its corporate clients. In 2018, FHG engaged Agape, a business process outsourcing provider and social enterprise, to provide call centre and appointment booking services for its customers (the “Services”). As part of its social enterprise initiatives, Agape engaged inmates from Changi Women’s Prison (the “Agents”) to assist in provision of the Services for FHG’s customers. 4 In order to carry out the Services, FHG provided Agape with access to the personal data of its customers via Microsoft SharePoint, a cloud-based document management system. A single Agape personal computer (the “Computer”) was authorised to access FHG’s SharePoint platform via an FHG-assigned SharePoint account. 5 In order to facilitate Agents’ access to FHG’s customer data from within Changi Women’s Prison, Agape downloaded FHG’s customer data onto the Computer, and re-uploaded the customer data onto an internet-facing file server (“the Online Drive”). The Online Drive was then white-listed for access by the Agents from within Changi Women’s Prison. 3 The Incident 6 On 15 October 2021, FHG became aware that its customer data was being offered for sale on a dark web forum. FHG engaged cybersecurity consultants to investigate. On 18 October 2021, FHG’s cybersecurity consultants made contact with the purported seller who claimed that he had exfiltrated FHG’s customer data from Agape’s Online Drive. By 22 October 2021, the post on the dark web forum advertising the sale had been removed. 7 FHG’s cybersecurity consultants confirmed that the Incident solely involved and affected Agape’s Online Drive. FHG’s own systems and servers were not affected in the Incident. 8 The personal data of 156,900 FHG customers (133,866 direct patients and 23,034 employees of FHG’s corporate clients) was accessed without authorisation in the Incident, although the exact volume of exfiltrated personal data was unknown. The affected personal data comprised the following datasets: Direct patients (a) Name; (b) NRIC number / FIN; (c) Date of birth; (d) Gender; (e) Email address; 4 (f) Telephone number; (g) Financial information (Bank account numbers and bank codes); (h) Health information (International Classification of Diseases codes that pertain to an individual’s diagnosis information, and codes for surgical procedures done in hospitals); Employees of FHG’s corporate clients (i) Name; (j) NRIC number / FIN / Passport number; (k) Date of birth; (l) Email address; (m) Financial information; and (n) Health, and other information (Information relating to the utilisation of health benefits by individual members, which include details of clinic names and claim amount (collectively, the “Customer Data”). Remedial actions 9 As part of remedial measures following the Incident, FHG informed affected clients and individuals promptly via SMS, email, and an FAQ page on its website, advising on appropriate steps which could be taken to guard against potential risks. FHG also engaged Credit Bureau (Singapore) Pte Ltd to provide free credit monitoring services to affected individuals for 6 months. 5 10 Agape suspended use of the Online Drive with effect from 19 October 2021, and, with the assistance of a forensic team, conducted internal checks on the Computer and Online Drive for other indicators of compromise. 11 FHG in coordination with Agape also: (a) restricted Agape’s access to its SharePoint to “view-only”; (b) deleted SharePoint files and folders that Agape did not need as part of data minimisation efforts; (c) ceased synchronisation of data between SharePoint and the Computer; (d) changed all passwords for Agape’s access to FHG’s SharePoint; and (e) deleted the Customer Data from the Online Drive upon completion of Agape’s investigations into the Incident. Findings and Basis for Determination Whether Agape had contravened the Protection Obligation 12 As a data intermediary of FHG, Agape is subject to the Protection Obligation pursuant to section 4(2) of the PDPA. For the reasons set out below, Agape was determined to have breached the Protection Obligation in relation to the Customer Data affected in the Incident. 6 Failure to conduct reasonable periodic security reviews 13 In previous enforcement decisions, the Commission has emphasised the need for organisations to conduct periodic security reviews of their IT systems. Such reviews enable organisations to detect vulnerabilities, assess security implications and risks, and ensure that reasonable security arrangements are implemented to eliminate or mitigate such risks. Periodic security reviews should be scoped based on the organisation’s assessment of its data protection needs, for example, taking into account the type of personal data to be protected.1 14 In Quoine Pte Ltd [2022] SGPDPC 2 (“Quoine”), while the organisation had conducted periodic security reviews, these security reviews were improperly scoped and failed to include a particular account. The organisation explained that its current staff were not aware of the reasons for the affected account’s set-up and security arrangements, as the account had been created “at some time in the past (so legacy)”. This explanation did not excuse the organisation’s breach of the Protection Obligation. The Commission found that it was incumbent on the organisation to have implemented the necessary systems and processes to ensure that critical information about its systems, including legacy systems, survived the turnover of its staff (Quoine at [23]). 15 Similarly, while Agape had carried out periodic security reviews, these reviews failed to cover the Internet-facing Online Drive. Agape admitted that this omission was 1 Everlast Projects Pte Ltd and others [2020] SGPDPC 20 (at [21]). 7 because the use of the Online Drive had been a legacy feature unique to Agape’s engagement by FHG, which was not implemented for any of Agape’s other clients. As a result of this omission, Agape failed to review and assess the Online Drive’s security implications and risks. 16 When the Online Drive was installed in December 2017, it was protected by a password which met Agape’s password complexity policy (i.e. 8 to 10 characters with a mix of upper and lower-case characters, numbers and symbols). However, at the time of the Incident, the password for Agape’s Online Drive had been inadvertently disabled for an estimated 20 months (since December 2019), the cause of which could not be established. Agape admitted that this caused the Online Drive to become an open directory listing on the Internet with no password protection, and highly vulnerable to unauthorised access, modification and similar risks over an excessive period of time. 17 If Agape’s periodic reviews had been properly scoped to cover all of the IT components under its Services rendered to FHG (including the Online Drive), this lapse could have been detected and rectified timeously. Inadequate password policy and management 18 In the course of investigations, Agape also admitted that prior to the password being disabled in December 2019, it had been shared by Agents to access the Online 8 Drive. In Terra Systems Pte. Ltd. [2021] SGPDPC 72, the Commission highlighted the data protection risks associated with multiple users sharing a common password, including greater risks of unauthorised access by ex-staff and inadvertent disclosure to threat actors through social engineering, among others. 19 The use of a common password among all Agents was exacerbated by the fact that there was no expiry date set for the password. The failure to implement and enforce reasonable password management policies increased the vulnerability of the Customer Data on the Online Drive to unauthorised access and other similar risks, even before the password had been disabled. 20 For the above reasons, Agape was determined to have breached the Protection Obligation. Whether FHG had contravened Section 24 of the PDPA Failure to exercise reasonable oversight of vendor 21 Under Section 4(3) of the PDPA, an organisation that engages a data intermediary to process personal data on its behalf, bears the same obligations under the PDPA as if the personal data was processed by the organisation itself. This is so, even where the organisation engages the data intermediary to implement the 2 This decision was subsequently subjected to reconsideration by the Commission. In Terra Systems Pte Ltd [2022] SGPCPCR 1, the Commissioner affirmed the finding of the organisation’s breach of Section 24 of the PDPA and the financial penalty imposed. 9 necessary data protection measures in relation to the personal data (Social Metric Pte Ltd [2017] SGPDPC 17 at [15]). 22 The Commission has reiterated in past decisions, such as SCAL Academy Pte. Ltd. [2020] SGPDPC 2, that the Protection Obligation requires organisations to exercise reasonable oversight of their vendors. 23 Specifically in the context of an organisation’s relationship with its data intermediary, the organisation (i.e. the data controller) has a supervisory or general role for the protection of the personal data, while the data intermediary has a more direct and specific role in the protection of personal data arising from its direct possession or control over the personal data. This means that a data controller may be found in breach of the Protection Obligation, even though its data intermediary may not be found in breach, and vice versa (Social Metric Pte Ltd [2017] SGPDPC 17 at [16]). 24 In this case, FHG engaged Agape as its data intermediary to carry out the Services using the personal data provided by FHG. Under the Protection Obligation, FHG was required to exercise reasonable oversight of Agape’s data processing activities. 25 In SCAL Academy Pte. Ltd. [2020] SGPDPC 2 (at [8]), even though the organisation in question had instructed its vendor to prevent certain documents from 10 being ‘leaked’ online, it did not check what security arrangements the vendor had implemented to ensure this. This hindered the organisation and vendor from being able to identify any data protection risks and agree on the measures to be implemented to protect against unauthorised disclosure of the personal data in the documents. 26 In this case, due consideration is given to the fact that FHG had conducted a high-level IT due diligence review of Agape prior to its decision to onboard Agape as a vendor, and that FHG’s written agreement with Agape required the latter to comply with the PDPA including, among others, obligations to take all appropriate and reasonable administrative, physical and technical safeguards, and security arrangements. Nevertheless, FHG’s failed to exercise reasonable oversight through regular monitoring of Agape’s personal data handling processes throughout the engagement, including how Agape stored and granted Agents’ access to the Customer Data. 27 In this regard, there was a point of contention between the parties over whether FHG was aware of and permitted the uploading of the Customer Data from Agape’s Computer to the Internet-facing Online Drive. 28 According to FHG, its understanding with Agape was that the local copy of the Customer Data on the Computer was only to be used for emergency or exceptional situations such as when Agape was unable to connect to FHG’s SharePoint during any system downtime or disruptive event. No other copies of the Customer Data were 11 to be made by Agape, whether from the SharePoint or the local copy on the Computer. FHG stated that it did not provide Agape with permission to upload the Customer Data from Agape’s Computer to the Online Drive. 29 In contrast, Agape asserted that FHG was aware that the Agents were inmates operating from inside Changi Women’s Prison, and that there were IT restrictions preventing them from accessing the Customer Data directly from FHG’s Sharepoint. As such, Agape had downloaded and uploaded the Customer Data onto its Online Drive for the Agents to access and use. Agape asserted that FHG was aware of Agape’s process of sharing Customer Data with the Agents as FHG’s representatives had been present during “dry runs”. 30 While there was insufficient contemporaneous evidence to support either party’s version of events, the fact remains that FHG was aware that Agape was engaging inmates from inside Changi Women’s Prison to carry out the Services, and the Commission’s findings regarding FHG’s breach of the Protection Obligation are not dependent on whether FHG permitted Agape to upload the Customer Data to the Online Drive or not. 31 Given that FHG was aware that access to the Customer Data would have to be granted to a third party that was offsite for the provision of the Services, FHG should have made reasonable enquiries to ascertain how the Customer Data was to be stored and transmitted, and how access to the Customer Data would be controlled. Had FHG 12 made these enquiries and discovered the true state of affairs, they would have no doubt required Agape to implement stricter controls to regulate Agents’ access and use of the Customer Data. By failing to make such enquiries, FHG failed to appreciate the reality of how Agape was storing, transmitting, and retaining the Customer Data, and failed to exercise reasonable oversight over Agape’s data processing activities. Unnecessary disclosure of sensitive personal data 32 Separately, FHG inadvertently disclosed personal data only intended for its employees’ internal use, onto the SharePoint system shared with Agape. This included sensitive financial information such as bank account numbers and bank codes, and health information such as ICD codes and codes for surgical procedures done in hospitals. These datasets were not required by Agape for the performance of the Services, and this inadvertent disclosure ultimately led to a greater loss of personal data during the Incident. 33 When an organisation discloses more personal data than is needed for its purposes, this creates unnecessary data security risks, particularly where such data is more sensitive in nature3. 3 Habitat for Humanity Singapore Ltd [2018] SGPDPC 9 (at [19]-[20]) 13 34 In the Commission’s Guide to Data Protection Practices for ICT Systems4 (at page 11), data minimisation has been encouraged as a good way for organisations to examine what personal data is really needed. It should be a basic data protection practice for organisations to collect, use, or disclose only the least sensitive types of personal data if different types of personal data can be used to achieve the same purpose. 35 FHG should have implemented robust measures to ensure that only personal data necessary for performance of the Services was shared with Agape, and in particular, that sensitive personal data was not inadvertently disclosed. 36 In view of the above, FHG was determined to have breached the Protection Obligation in respect of the Customer Data. Voluntary measures implemented by FHG and Agape 37 Following the Incident, FHG and Agape have voluntarily taken or will be taking the following steps to prevent a recurrence of the Incident or similar events: FHG (a) Agents will now access FHG’s customer data directly from FHG’s SharePoint via individual user accounts with multi-factor authentication; 4 Published on 14 September 2021. The Guide compiles data protection practices from past Advisory Guidelines, Guides and data breach cases that should be adopted by organisations in their ICT policies, systems and processes. 14 (b) FHG’s SharePoint has been reconfigured to grant “view-only” access to only the specific files required by vendors for the services to be provided, with clear segregation between the vendor’s SharePoint files and FHG’s internal SharePoint files; (c) FHG will formally communicate its internal personal data protection policies and processes to vendors in order for them to be applied to the vendors’ processing of personal data on FHG’s behalf; (d) FHG will enhance its contracts with vendors to include additional data protection obligations, such as the requirement for vendors to undergo regular vulnerability assessments and penetration testing, rights for FHG to audit the vendor’s data processing practices, and requirements for vendors to have in place reasonable data breach response management processes; Agape (e) With the assistance of external cybersecurity consultants, Agape has refreshed its data protection and IT policies; and (f) Agape has increased data protection awareness by requiring employees to go through the assessment tools provided on the Commission’s website, enrolling employees in Workforce Skills Qualifications PDPA courses for certification, and regularly conducting internal communications to maintain cybersecurity vigilance. 15 The Commissioner’s Decision 38 In determining whether any directions should be imposed on FHG and Agape under Section 48I of the PDPA, and/or whether they should be required to pay a financial penalty under Section 48J of the PDPA, the factors listed at Section 48J(6) of the PDPA and the following mitigating factors were taken into account: Mitigating Factors (a) FHG and Agape were cooperative during the investigations; (b) FHG and Agape voluntarily admitted to their breaches of the Protection Obligation under the Commission’s Expedited Decision Procedure; and (c) FHG and Agape took prompt remedial actions following discovery of the Incident. 39 While Agape’s breaches of the Protection Obligation were more causally proximate to the unauthorised access and disclosure of personal data in the Incident, FHG’s inadvertent disclosure of financial and health related data resulted in the impact of the Incident being amplified. As the data controller, FHG also bore the ultimate responsibility to exercise due diligence and reasonable supervision over Agape. For the purposes of assessing what amount of financial penalty would be proportionate and effective as a deterrent, it was also taken into consideration that FHG’s annual turnover based on its latest available audited accounts, was almost 50 times higher than that of Agape’s. 16 40 Having carefully considered all the relevant circumstances, the Commissioner hereby requires that: (a) FHG pay a financial penalty of $58,000; and (b) Agape pay a financial penalty of S$10,000; within 30 days of the date of the relevant notices 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. 41 In quantifying the financial penalties imposed, no weight was placed on Agape’s status as a social enterprise. The standard of security arrangements expected under the Protection Obligation will depend on the volume and nature of personal data in the organisation’s possession or control, regardless of whether the organisation is a forprofit business, a charity, or a social enterprise5. 42 In addition to the financial penalties imposed, FHG and Agape are also directed to do the following: 5 See Singapore Red Cross Society [2020] SGPDPC 16 at [10] 17 FHG (a) Within 60 days from the date of this decision: i. Review processes and contractual obligations with Agape and existing vendors processing personal data on behalf of FHG, to ensure that such vendors have sufficiently robust data handling processes to protect personal data in their possession and/or control; ii. Review existing internal processes to ensure that only personal data necessary for fulfilling contractual obligations is disclosed to vendors via secured channels and with reasonable access controls considering the type and volume of personal data being disclosed; and (b) Notify the Commission within 14 days of the completion of the reviews above, with an outline of their scope. Agape (c) Within 60 days from the date of this decision: i. Ensure that the scope of its periodic security reviews and any security audits include the protection of personal data handled in all of Agape’s systems and processes; ii. Resolve and record in writing with FHG the data protection requirements and job specifications for the processing of personal data on behalf of FHG, including arrangements for the exercise of regular oversight by FHG to verify that the requirements and specifications are being met; and 18 (d) Notify the Commission within 14 days of the completion of the reviews above, with an outline of their scope. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 19 ","Financial Penalty, Directions",1b0b43399e4f4f5d75c72d6a95a144b1fdefd199,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,6,6,1,952,"Directions were issued to Kingsforce Management Services to ensure the implementation of regular patching, updates and upgrades for all software and firmware supporting its website(s) and application through which personal data in its possession may be accessed.","[""Protection"", ""Directions"", ""Employment"", ""Protection"", ""Patching""]",2023-05-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_KingsforceManagementServicesPteLtd_100323.pdf,Protection,Breach of the Protection Obligation by Kingsforce Management Services,https://www.pdpc.gov.sg/all-commissions-decisions/2023/05/breach-of-the-protection-obligation-by-kingsforce-management-services,2023-05-11,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPCS1 Case No. DP-2202-B9480 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Kingsforce Management Services Pte Ltd SUMMARY OF THE DECISION 1. On 31 January 2022, the Personal Data Protection Commission (the “Commission”) was notified by Kingsforce Management Services Pte Ltd (the “Organisation”) of the sale on RaidForums, on or about 27 December 2021, of data from its jobseeker database (the “Incident”). 2. The affected database held approximately 54,900 jobseeker datasets, comprising name, address, email address, telephone number, date of birth, job qualifications, last and expected salary, highest qualification and other data related to job searches. 3. External cyber security investigators identified outdated website coding technology, with critical vulnerabilities, as the cause of the Incident. 4. The Commission accepted the Organisation’s request for handling under the Commission’s expedited breach decision procedure. The Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision, and to breach of section 24 of the Personal Data Protection Act (“the PDPA”). 5. The Organisation admitted work had not been completed on the website at launch owing to contractual disputes with the developer. The Organisation subsequently engaged IT maintenance vendors in an effort to ensure the security of the website. However, maintenance had been ad-hoc and limited to troubleshooting functionality issues from bugs, glitches and/or when a page failed to load. 6. In breach of the Protection Obligation, the Organisation failed to provide sufficient clarity and specifications to its vendors on how to protect its database and personal data. In Re Civil Service Club, the Commission had pointed out that organisations that engage IT vendors can provide clarity and emphasize the need for personal data protection to their IT vendors by a) making it part of their contractual terms, and b) reviewing the requirements specifications to ensure that personal data protection is reflected in the design of the end-product.1 Further, post-execution of the contract, an organization is also expected to exercise reasonable oversight over its vendor during the course of the engagement to ensure that the vendor is protecting the personal data by adhering to the stipulated requirements.2 1 Re Civil Service Club [2020] SGPDPC 15. 2 Re WTS Automotive Services Pte Ltd [2019] PDP Digest 317 at [16] and [17]. 7. Another breach of the Protection Obligation by the Organisation was failure to conduct reasonable periodic security reviews, including vulnerability scans, since the launch of its website. The requirement for and scope of reasonable periodic security reviews had long been established in the published decisions of the Commission.3 The PDPC’s Guide to Data Protection Practices for ICT Systems also emphasized the need to periodically conduct web application vulnerability scanning and assessments, post deployment, as a basic practice to ensure compliance with the Protection Obligation under the PDPA.4 8. The Organisation is therefore found to have breached the Protection Obligation under section 24(a) of the PDPA. 9. In deciding the enforcement action in this case, the Commission considered the Organisation’s efforts towards website security, cooperation throughout the investigation, voluntary admission of breach of the Protection Obligation and the prompt remediation taken. The last included immediate suspension of its website, and the engagement of a new developer to develop a new and enhance web application. The Commission also notes that the affected personal data was no longer or accessible following the shutdown of RaidForums. In the circumstances, the Commission directs the Organisation to do the following: a. To submit to the Commission, within twenty-one (21) days from the date of issue of this Direction, a plan to ensure regular patching, updates and upgrades 3 See, eg, Re WTS Automotive Services Pte Ltd [2019] PDP Digest 317; Re Bud Cosmetics Pte Ltd [2019] PDP Digest 351; and Re Watami Food Service Singapore Pte Ltd [2019] PDP Digest 221. 4 Pages 21 and 22 of the Guide to Data Protection Practices for ICT Systems. for all software and firmware supporting its website(s) and applications through which personal data in its possession may be accessed. b. To state whether it intends to implement the plan by engagement of qualified external services or by relying on its own resources, and if by engagement of qualified external services, to state in detail the job specifications for software and firmware patching, updates, and upgrades to be stipulated to the vendor. c. To outline each implementation step with deadlines to ensure that the entire implementation is completed within sixty (60) days from the date of issue of this Direction. 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 is possession or under its control by making reasonable security arrangements to prevent(a) unauthorized access, collection, use, disclosure, copying, modification or disposal, or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. ",Directions,55f101a661c1696120dbd78b07f569b7bba4c9db,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,7,7,1,952,"A financial penalty of $8,000 was imposed on Fortytwo for failing to put in place reasonable security arrangements to protect the personal data in its possession. Fortytwo was also issued directions to complete the upgrading of its website to a supported software version, including vulnerability assessment and penetration testing.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Wholesale and Retail Trade"", ""Patching""]",2023-05-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_FortyTwo070323.pdf,Protection,Breach of the Protection Obligation by Fortytwo,https://www.pdpc.gov.sg/all-commissions-decisions/2023/05/breach-of-the-protection-obligation-by-fortytwo,2023-05-11,"PERSONAL DATA PROTECTION COMMISSION [2023 SGPDPCS 3] Case No. DP-2112-B9354 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Fortytwo Pte. Ltd. SUMMARY OF THE DECISION 1. On 24 December 2021, Fortytwo Pte. Ltd. (the “Organisation”), an online furniture store, notified the Personal Data Protection Commission (the “Commission”) of malicious code injections on its website which led to the capturing of the email address and password of 6,241 individuals when they logged in to its website (the “Incident”). The name, credit card number, expiry date and CVV/CVN number of another 98 individuals’ were also affected. 2. The Organisation requested for the matter to be handled under the Commission’s expedited breach decision procedure. This means that the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision; and admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 1 3. An issue that arose in this case is whether fictitious names or pseudonymous personal particulars form part of the personal data under the possession or control of the Organisation. The importance of this lies in how it may potentially reduce the size of the dataset that was at risk. In their addendum to the Written Statement, the Organisation stated that it does not verify the names provided by the users, and suggested that the impact of the Incident might be more limited as some of the users’ names may be incomplete, fictitious or pseudonymous. 4. Section 2(1) of the PDPA defines “personal data” to be data, whether true or not (emphasis added), about an individual who can be identified from that data; or from that data and other information to which the organisation has or is likely to have access. The PDPA caters for the situation where not every record of personal data that is under the possession or control of an Organisation is verified. It takes a practical approach, as the accuracy of personal data records will change with the passage of time (e.g. information becomes outdated) or individuals may intentionally provide inaccurate information (e.g. users hiding their age or using fictitious residential addresses to bypass restriction of services by age or geolocation). What matters is that the Organisation, having collected the information, takes steps to comply with their obligations under the PDPA, such as to protect them and to ensure that they are used in accordance with the purpose of their collection. 5. The situation is different when the organisation, as a data security or data management measure, applies pseudonymisation or anonymisation techniques on personal data that is in their possession or under their control. In such circumstances, if the risk of reidentification is adequately addressed and managed, the resulting dataset may be treated as anonymised. The key difference is the intention of the 2 organisation and its ability to direct and control the data processing activities required to achieve the resultant anonymised dataset.1 6. In this case, the Organisation was collecting data from its customers. Their customer database contained names, email addresses and additional details such as their shipping address, billing address, and date of birth. It also contained credit card details of 98 customers. Even if some customers had provided incomplete, fictitious or pseudonymous personal particulars or payment details, the Organisation had collected personal data. For the purpose of this investigations, it matters not that some of these customers may have provided inaccurate information. The Organisation’s obligations under the PDPA applies to the entire customer database. 7. The Organisation admitted that the Incident occurred because the threat actor had successfully exploited vulnerabilities present in the Magento open-source version 1.9.x.x which the Organisation had employed for its online store. These vulnerabilities were present because the Organisation failed to apply four Magento security patches released on 28 Nov 2017, 25 June 2019, 8 October 2019 and 28 April 2020 by Adobe. 8. Compounding the above, support for Magento version 1 had ended on 30 June 2020. The Organisation admitted that it should have upgraded to Magento opensource version 2.0 after Adobe ended the support for Magento 1 on 30 June 2020. The Organisation had planned to upgrade to Magento version 2 in early 2020, but its plans were disrupted by the COVID-19 pandemic. Having said that, Adobe had announced in November 2015 that it will end support for Magento 1.x in 36 months, 1 See Personal Data Protection Commission, Advisory Guidelines on the Personal Data Protection Act for Selected Topics, at paras 3.5, 3.8 and 3.13. 3 i.e. by November 2018. In September 2018, Adobe then announced that it would extend the support to 30 June 2020. Given the ample notice given by Adobe to the Organisation of the need to upgrade the version of Magento Open Source which it was using in order to continue receiving support and security patches from Adobe, it is difficult to look past the Organisation’s prolonged failure to do the needful and perform the necessary upgrades. 9. The Commission had consistently advised organisations on the importance of applying software patches. In our Guide to Data Protection Practices for ICT Systems, the Commission had highlighted that organisations should perform system patching promptly to fix security vulnerabilities. If software patches are not updated as recommended by the software provider, they may not contain the latest cybersecurity updates and may compromise the organisation’s defence against cyber-attacks. 10. We note that the Organisation had considered and evaluated the four patches but decided to hold back on installing them. However, these four patches were released by Adobe to address several high severity risk issues and critical bugs, including the injection of malicious codes. The Organisation’s failure to patch had increased the risks of a malicious code injection capable of capturing users’ personal data. 11. In light of the above, the Organisation is found to have breached the Protection Obligation under section 24(a) of the PDPA. 4 12. The Commission notes that after the Incident, the Organisation took prompt remedial actions, including notifying affected individuals and various technical measures to improve its security. The Organisation is also taking steps to upgrade to Magento version 2. 13. In deciding the appropriate outcome in this case, the Commission considered the Organisation’s cooperation throughout the investigation, the voluntary admission of breach of the Protection Obligation, and the prompt remedial actions taken. 14. Following the issuance of the Commission’s preliminary decision, the Organisation represented that it was unfair to state that was a prolonged failure to perform the necessary upgrade. This is because there was a lead time of 6 months before the end of support when it made the decision to upgrade, before the COVID19 pandemic disrupted its plans. The Organisation’s representation is not accepted as, notwithstanding the disruptions caused by the pandemic, the Organisation had been given ample notice of the impending end of support but took no action to perform the necessary upgrade from November 2015 to early 2020. 15. Having considered the circumstances set out above, the factors listed at section 48J(6) of the PDPA and the representations made by the Organisation, the Deputy Commissioner for Personal Data Protection hereby finds the Organisation in breach and directs the Organisation to pay a financial penalty of S$8,000 within 30 days from the notice accompanying date of this decision, failing which interest at the rate specified in the Rules of Court in respect of judgement debts shall accrue and be 5 payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 16. The Organisation is also directed to: a. Complete the upgrading of its website to a supported software version, including vulnerability assessment and penetration testing, within 6 months of the direction. b. Inform the Commission with 14 days of the completion of the above. 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. 6 ","Financial Penalty, Directions",94a50b28e4364bbb6e7cc57412b04d7d6841f870,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,8,8,1,952,"Directions were issued to The Law Society of Singapore to conduct a security audit of its technical and administrative arrangements for accounts with administrative privileges that can access directly and/or create access to personal data, and to rectify any gaps identified. This is pursuant to a data breach incident where The Law Society’s servers were subjected to a ransomware attack.","[""Protection"", ""Directions"", ""Professional"", ""Scientific and Technical"", ""Ransomware"", ""Patching"", ""Security"", ""Password""]",2023-05-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_LawSocietyofSingapore_140323.pdf,Protection,Breach of the Protection Obligation by The Law Society of Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2023/05/breach-of-the-protection-obligation-by-the-law-society-of-singapore,2023-05-11,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 4 Case No. DP-2102-B7850 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And The Law Society of Singapore … Organisation DECISION 1 The Law Society of Singapore Yeong Zee Kin, Deputy Commissioner — Case No. DP-2102-B7850 14 March 2023 Introduction 1 On 4 February 2021, the Law Society of Singapore (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware attack on its servers which had encrypted and denied the Organisation access to the personal data of its members and former members (the “Incident”). The Commission commenced investigations to determine whether the circumstances behind the Incident disclosed any breaches by the Organisation of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 2 The Organisation is a body corporate established under the Legal Profession Act 1966 and represents members of the legal profession in Singapore. Every advocate and solicitor called to the Singapore bar is a statutory member of the Organisation as long as they have a practising certificate in force. At the material time, the Organisation stored the personal data of its current and former members (“Members”) in one of its servers for the purposes of carrying out its statutory functions. 2 3 The Organisation had implemented an off-the-shelf secure VPN solution, FortiOS, to manage remote access to its servers (the “VPN System”). The Organisation also engaged a vendor (the “Vendor”) to provide IT support services, including maintenance of the VPN System. For completeness, the Vendor was not the Organisation’s data intermediary as it did not access or process the personal data of the Members in the course of carrying out its IT support services. 4 The Organisation also implemented antivirus / malware detection software at the servers, and password complexity requirements for its users’ accounts. In particular, account passwords had a maximum lifespan of 3 months before a compulsory change was required. 5 Additionally, the Organisation had in place a written data protection policy and conducted data protection training for its staff highlighting cybersecurity threats such as phishing and ransomware. Periodic emails on data protection awareness and reminders were also sent to staff. The Incident 6 On 27 January 2021, a threat actor gained access to the account of the Organisation’s IT administrator (“compromised admin account”) and used this to create a new account with full administrative privileges. Using this new account, the threat actor moved through the Organisation’s network without detection and located the Organisation’s servers. The threat actor then executed a ransomware attack on the servers, encrypting their contents. 3 7 A total of 16,009 Members’ personal data was affected in the Incident, including each Member’s full name, residential address, date of birth, and NRIC number. Other data items were also affected but they are either in the nature of business contact information or publicly available information. 8 The attack was detected on the same day by antivirus / malware detection software deployed by the Organisation. The Organisation took immediate steps to remove the new administrator account created by the threat actor and restored the servers to their original state from secured back-ups. Remedial actions 9 Following the Incident, the Organisation also took the following remedial actions: (a) Removed unused administrator accounts and initiated password resets for all administrator accounts; (b) Reduced privileged access for the compromised admin account (to create new administrator accounts); (c) Hired an in-house cybersecurity professional to take charge of the Organisation’s IT security matters; (d) Implemented multi-factor authentication (“MFA”) for all VPN access; and (e) Implemented VPN IP location whitelisting to allow only Singapore-based IP addresses. Findings and Basis for Determination 4 10 The Commission’s investigation centred on whether the Organisation had breached its obligation under Section 24 of the PDPA 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”). As the Vendor was not the Organisation’s data intermediary, the Protection Obligation in this case was borne solely by the Organisation. Findings from the investigations 11 Investigations disclosed that there could have been multiple threat actors targeting the Organisation or the same group of threat actors targeting the Organisation through multiple channels – through brute force attacks, phishing email, and exploiting the unpatched VPN vulnerability of the VPN System. 12 Brute-force attacks. Around ten days before the Incident, multiple unsuccessful login attempts using a “guest” account were found since 18 January 2021. There were also further unsuccessful attempts made using random accounts. However, investigations did not surface evidence that the initial entry by the threat actor had been via a successful brute force attack on the compromised admin account. 13 Phishing emails. Investigations also revealed that the Organisation was attacked by the Netwalker ransomware, most commonly introduced via phishing emails. From the Vendor’s explanations, the administrator of the compromised admin account could have received a phishing email with a link and entered his credentials. However, investigations did not surface evidence of any phishing email relevant to this 5 ransomware; neither was there evidence that the compromised admin account’s credentials was obtained by a threat actor through phishing. 14 Vulnerability of the VPN System. At the material time before the Incident, MFA was not implemented for the Organisation’s administrator access to its servers. This meant that once authenticated, an admin user had rights to create new accounts, assign privileged security groups, and access all of the Organisation’s servers without the need for a second factor. 15 Investigations revealed that there was a vulnerability in the VPN System which could be exploited to gain access credentials if left unpatched (the “Vulnerability”). This was assessed to be a possible way in which the threat actor obtained the credentials of the compromised admin account: (a) Around November 2020, a file containing more than 45,000 session links and IP addresses for the VPN System of affected organisations (including the Organisation) was found posted in online forums by someone who had obtained the information by exploiting the Vulnerability. (b) Without patching the VPN System’s firmware, each session link would disclose the credentials of users in plain text, including passwords. (c) The date/time of the online publication (i.e. November 2020) was sufficiently proximate to the threat actor’s successful intrusion in January 2021 using the compromised admin account. 6 16 From the foregoing, it would appear that of the three possible attack vectors, the vulnerability in the VPN System could have given the threat actor entry into the Organisation’s environment. No breach of the Protection Obligation for omission to patch the Vulnerability 17 The developer of the VPN System, Fortinet, had disclosed the Vulnerability as early as 24 May 2019. It released an Operating System (“OS”) upgrade to remedy the issue, which contained the updates to remedy the issue. The VPN System had a user interface (“UI”) through which the OS upgrade availability could be notified. According to the Vendor, the Vendor had regularly checked the UI if OS upgrades were available but there were no prompts of updates available for download prior to the Incident. According to the Organisation, it was only after it communicated the issue to the developer, after the incident, that the UI subsequently prompted availability of some patches that included the OS upgrade remedying the Vulnerability. 18 The Commission recognises that organisations may rely on vendors engaged to provide IT security maintenance to obtain and apply needed software upgrades and patches. If so, the Protection Obligation requires organisations to stipulate such requirements clearly in writing as part of the job specifications of such vendors. In this case, patching of the VPN System had been a specific obligation explicitly outsourced by the Organisation to the Vendor via contract. 19 In addition to clearly stipulating the vendor’s scope of IT maintenance and/or development work, organisations are expected to exercise reasonable oversight over the vendor’s performance of the subcontracted services, including patching – Re 7 Smiling Orchard (S) Pte Ltd and Ors [2016] SGPDPC 191. There should be a clear meeting of minds as to the services the service provider has agreed to undertake and organisations must follow through with procedures to check that the outsourced provider is delivering the services. 20 The Commission appreciates that the technical nature of information on software patching and upgrades limits the degree of oversight that many organisations can exercise on vendor performance in this regard. The Commission notes that the Organisation had put in place a process to ensure that there were maintenance logs in respect of the Vendor’s activities. Thus, the Organisation, to its credit, had put in place a system to monitor its Vendor’s activities. In technical areas where the Organisation depends on its Vendor’s technical expertise, this is reasonably adequate. The situation may be different if there was a very well-publicised issue with a wellknown commercial solution (e.g. vulnerabilities affecting a network router) that the Organisation ought to know that it uses. In such situations, the Organisation might be at least expected to query its Vendor about whether it is exposed and ask for a remediation plan. But this is probably limited to well-known and well-publicised issues in mass media. 21 Carefully weighing the above circumstances, the Commission has decided that: (a) it had been reasonable for the Organisation to rely on the Vendor to perform software security patching, including of the Vulnerability, and (b) that the Organisation 1 See also Singapore Health Services Pte. Ltd and Integrated Health Information Systems Pte Ltd [2019] SGPDPC 3. 8 had in this case discharged its duty of oversight of the Vendor’s patching function. Therefore the Organisation has not breached the Protection Obligation. Breach of the Protection Obligation by the Organisation in other aspects 22 Investigations revealed that the password for the compromised admin account was “Welcome2020lawsoc”. Despite this password complying with the Organisation’s own password complexity rules, the Organisation acknowledged that this was a weak password and vulnerable to dictionary attacks due to the use of a full word and the Organisation’s name. As highlighted in Chizzle Pte Ltd [2020] SGPDPCR 1, a password that meets complexity rules in form could still be regarded as a weak password if it was easily determined and vulnerable to brute force attacks. In that case, the password “Chi!zzle@2018” incorporated the organisation’s name and was determined to be a weak password. Further, the Organisation informed that the compromised admin account’s password had been used for more than 90 days and had not been changed every 3 months, as required by the Organisation’s password policy. In the circumstances, the Organisation failed to enforce its password policy in relation to the compromised admin account. 23 In the Commission’s recent Guide to Data Protection Practices for ICT systems2, it has been observed that unauthorised access is one of the most common types of data breaches. This can happen, for example, through the use of a weak password which is easily guessed by hackers. To remediate this, it may be practical to look into implementing processes in ICT systems to minimise risk of brute force 2 Published on 14 September 2021, replacing the Guide to Data Protection by Design for ICT systems published on 31 May 2019, after the Incident. 9 attacks (e.g. a pre-defined number of failed login attempts) and ensure information is accessed only by the authorised/authenticated persons performing the intended activities. Additionally, as 2FA or MFA becomes more broadly available, the adoption of these tools should become the norm for accounts with administrative privileges, for systems managing sensitive data or large volumes of personal data3. 24 Next, the Organisation also did not conduct a review of its security arrangements within the last 3 years prior to the Incident. Regular assurance checks help organisations ensure that ICT security controls developed and configured for the protection of personal data are properly implemented and practised4. In Re WTS Automotive Services Pte Ltd [2018] SGPDPC 265, the Commission emphasised (at [18]) for the need for regular review of security arrangements and tests to detect vulnerabilities. 25 For the above reasons, the Organisation is found to have negligently breached the Protection Obligation by (i) using an easily guessable password for the compromised admin account, (ii) failing to change the password for the compromised admin account at reasonable intervals, and (iii) failing to conduct any periodic security reviews in the three years leading up to the Incident. 3 See the Commission’s recent release of the handbook on common causes of data breaches in How to Guard against Common Types of Data Breaches published on 24 May 2021 (at page 13), after the Incident; See Love Bonito Singapore Pte Ltd [2022] SGPDPC 3. 4 See the Guide to Data Protection Practices for ICT systems. 5 See also Jigyasa [2020] SGPDPC 9. 10 The Deputy Commissioner’s Decision 26 Notwithstanding that the Organisation’s breaches of the Protection Obligation were not directly related to the Incident, the Commission’s role is not limited to investigating only the immediate or proximate causes of a data breach incident 6. In determining whether directions (if any) should be given to the Organisation pursuant to Section 48I of the PDPA, and/or whether a financial penalty ought to be imposed pursuant to Section 48J of the PDPA, the Deputy Commissioner took into consideration the relevant facts and circumstances of the case, and in particular the following factors: (a) The Organisation’s breaches of the Protection Obligation were not the most proximate cause of the Incident (which was the VPN Vulnerability); (b) The datasets affected in the Incident were not of a higher sensitivity (e.g. personal data of a financial or medical nature); (c) The risk of unauthorised access to the Members’ personal data was limited due to early detection of the unauthorised access, which also allowed prompt containment and restoration of the servers to its original state; (d) There was no evidence of any exfiltration or misuse of the personal data of the Members; and (e) 27 The Organisation took prompt remedial actions in response to the Incident. For the above reasons, it is adequate for directions to be issued in this case. The Deputy Commissioner hereby directs the Organisation to: (a) Engage qualified security service providers to conduct a thorough security audit of its technical and administrative arrangements for the security, 6 See Love Bonito Singapore Pte Ltd [2022] SGPDPC 3. 11 maintenance, creation and removal of accounts with administrative privileges that can access directly and/or create access to personal data in the possession or control of the Organisation; (b) Furnish to the Commission within 14 days a schedule stating the scope of the security audit; (c) Provide the full security audit report to the Commission, by no later than 60 days from the date of the issue of this direction; (d) Rectify any security gaps identified in the security audit report, review and update its personal data protection policies as applicable, and (e) Inform the Commission within 1 week of completion of rectification and implementation in response to the security audit report. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 12 ",Directions,7d6096f9562cfde74f556a2117cc264960050a02,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,9,9,1,952,"A financial penalty of $37,000 was imposed on OrangeTee & Tie for failing to put in place reasonable security arrangements to protect users' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Real Estate""]",2023-04-17,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_OrangeTee_210223.pdf,Protection,Breach of the Protection Obligation by OrangeTee & Tie,https://www.pdpc.gov.sg/all-commissions-decisions/2023/04/breach-of-the-protection-obligation-by-orangetee-and-tie,2023-04-17,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 3 Case No. DP-2108-B8712 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And OrangeTee & Tie Pte Ltd … Organisation DECISION OrangeTee & Tie Pte Ltd Lew Chuen Hong, Commissioner — Case No. DP-2108-B8712 21 February 2023 Introduction 1 On 4 August 2021, the Personal Data Protection Commission (“Commission”) contacted OrangeTee & Tie Pte Ltd (“Organisation”) after receiving information indicating that a threat actor had managed to exfiltrate databases in the Organisation’s possession, which were believed to contain personal data. 2 Subsequently, on 6 August 2021, the Organisation notified the Commission of an incident involving unauthorised access to its IT network (the “Incident”). The Organisation also gave a media statement on the same day informing members of the public about the Incident and inviting any concerned customers to contact the Organisation’s call centre for clarification. 3 The Commission then commenced investigations to determine the Organisation’s compliance with the Personal Data Protection Act 2012 (“PDPA”) in relation to the Incident. Facts of the Case 4 The Organisation is a real estate enterprise based in Singapore and has been in operation since 2000. 5 Four servers maintained by the Organisation were involved in the Incident, namely: the Production Web Server, the Production Database Server, the Development Web Server, and the Development Database Server. The Production Web Server and the Development Web Server (collectively the “Web Servers”) were internet-facing, in that they were directly accessible from the internet. The Production Web Server was linked to the Production Database Server, while the Development Web Server was linked to the Development Database Server. 6 The personal data of employees and customers of the Organisation was stored on the Production Database Server and the Development Database Server (collectively the “Database Servers”). The personal data had not been encrypted. 7 The Databases Servers were running Microsoft SQL Server 2012 Standard version 11.0.6251.0 (Service Pack 3) at the time of the Incident, which Microsoft had ceased support for on 9 October 2018. Additionally, the version of Microsoft SQL Server the Organisation used was also not updated, as the most current Service Pack 4 was not installed. The Incident 8 On 3 August 2021, the Organisation received a ransom demand email from an organisation which identified themselves as ‘ALTDOS’. The email was sent from an email address which is known to be used by the ALTDOS group. The threat actor claimed that they had been hacking the Organisation’s network since June 2021 and had stolen “hundreds of databases”, some of which were claimed to contain sensitive information. The ransom demand also contained video footage of five databases purported to have been stolen, which showed that sensitive data might have been exfiltrated from the Organisation’s servers. 9 In the same email, the threat actor demanded a ransom of 10 Bitcoins for the safety and non-disclosure of the exfiltrated databases and threatened disclosure if the ransom was not paid. The Organisation filed a police report and reported the Incident to the Singapore Computer Emergency Response Team, a division of the Cyber Security Agency of Singapore. 10 On 4 August 2021, having not received the demanded ransom, ALTDOS carried out a Distributed Denial-of-Service attack which brought down the Organisation’s network, and sent an additional ransom demand via email and WhatsApp to some of the Organisation’s employees. 11 The Organisation engaged a private forensic expert (“PFE”) to ascertain the cause and extent of the Incident. PFE’s investigations disclosed that, contrary to their claims, the threat actor exfiltrated personal datasets from eleven databases, containing personal data set out in the table below: Category of Number of Individuals Individuals Employees 305 Types of Personal Data Affected Name, full NRIC/FIN/passport number and bank account number Customers 245,752 Name, full NRIC/FIN/passport number and property transaction amount Agents 10,526 1. Name, full NRIC/FIN/passport number and bank account number (2,301 individuals) 2. Name, full NRIC/FIN number, bank account number and commission amount (4,763 individuals) 3. Name, full NRIC/FIN number, commission amount (286 individuals) 4. Name, full NRIC/FIN number (3,176 individuals) TOTAL 12 256,583 - The PFE’s investigations found that the threat actor had carried out certain web- based attacks and exploited vulnerabilities on the Web Servers to successfully exfiltrate databases from the outdated Database Servers. The following observations were made by the PFE: (a) Production Web Server – the PFE concluded that the threat actor used SQL injection attacks on the Production Web Server. SQL injections are a way of exploiting vulnerable website code and forms to return data from a SQL database that should not be available to a user. The PFE also found that the threat actor had likely used a malicious tool known as ‘SQL Map’ on vulnerable webpages in the Production Web Server, to automate the systematic probing of webpages for SQL injection vulnerabilities. Once the vulnerabilities were discovered, the threat actor then proceeded to exploit the vulnerabilities to access and exfiltrate data from four databases within the Production Database Server at some point(s) between 24 June 2021 and 3 August 2021. (b) Development Web Server – the PFE could not locate forensic artefacts to confirm the mode of attack by the threat actor. However, the PFE identified evidence of cross-site scripting attacks. Cross-site scripting attacks involve the injection of malicious scripts into trusted websites which are then executed on end-users’ browsers. In this case, malicious code had been injected into the Development Web Server. This led the PFE to believe that the Development Web Server was compromised. The threat actor is believed to have exploited the compromised Development Web Server to access and exfiltrate data from seven databases on the Development Database Server, although it was unclear how and when this had occurred. Remedial actions 13 Following the Incident, the Organisation implemented the following remedial measures: Immediate remedial steps to contain the Incident (a) Shut down and isolated the affected servers from the rest of the IT network; (b) Updated its servers with the latest security patches; To prevent recurrence or similar incidents (c) Tested the affected servers for vulnerabilities and deployed enterprisegrade anti-malware software across the IT network; (d) Carried out security hardening activities, including the removal of redundant services, restricting access and services, and ensuring the server is secure to ‘Center for Internet of Security’ (CIS) benchmarking standards; (e) Carried out detailed analysis of intrusion prevention logs; (f) Reviewed and secured the firewall configuration; (g) Separated the public-facing website from the internal agent portal and ensured that the former was securely hosted; (h) Implemented a web application firewall to protect the network; and (i) Liaised with the PFE on the recovery process as well as improving IT security. Findings and Basis for Determination 14 Based on the circumstances of the Incident, the Commission’s investigation centred on whether the Organisation had breached its obligation under section 24 of the PDPA 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”). The Organisation was determined to have breached the Protection Obligation in the following two respects. Use of production data in Development Servers for testing purposes 15 First, the Organisation used ‘live’ production data for development and testing purposes without sufficiently robust processes to protect the personal data through proper safeguards. 16 The ‘live’ production data used included personal data and had been stored in the development environment (i.e. the Development Servers) from which the datasets had been exfiltrated by the threat actor. The Organisation explained the use of ‘live’ production data as being necessary in order for the testing computations to be accurately derived, and for the actual business process flow to be effectively tested. 17 The Commission has advised in its Handbook on How to Guard Against Common Types of Data Breaches (the “Handbook”) at page 11 that use of ‘live’ production personal data for testing creates a security risk. 1 The safer practice would be to use anonymised data for testing purposes. Synthetic data, which is fake data that contains similar characteristics as the real data, is a form of anonymised data. Another way is to use pseudonymised data where direct identifiers have been replaced with pseudonyms. The Commission has explained the rationale for anonymisation of personal data for development and business study in the Advisory Guidelines on the PDPA for Selected Topics: Handbook on How to Guard Against Common Types of Data Breaches (“Handbook”), page 11: “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.” (https://www.pdpc.gov.sg/news-andevents/announcements/2021/05/handbook-on-how-to-guard-against-common-types-of-data-breaches-now-available) 1 “3.14 Anonymisation of personal data enables businesses to tap on data for insights and innovation while at the same time provides protection to individuals. It also reduces the impact of harm to individuals in the event of a data breach. Where possible, Organisations should adopt such practices for external sharing of data. It can even be adopted when sharing data internally, particularly where individuals need not be identified for the purposes of processing. 3.15 In the event of a data breach, the level of data anonymisation, corresponding safeguards implemented and proper assessment by organisations in considering the harms of the anonymised data would be taken into consideration to assess if data has been properly anonymised.”2 (emphasis in bold added) 18 The Commission’s position on this issue had been reiterated in Re PINC Interactive Pte Ltd [2022] SGPDPC 1, in which it was held that the organisation had breached the Protection Obligation by using a synthetic dataset that contained personal data belonging to real users. It should have used 100% synthetic data.3 19 However, where the use of ‘live’ personal data is operationally necessary, sufficiently robust processes should be implemented to safeguard the personal data. Testing or development environments are usually not as secured as production environments. The Organisation in this case had failed to implement sufficiently robust Advisory Guidelines on the PDPA for Selected Topics, page 14, paragraphs 3.14 – 3.15 (https://www.pdpc.gov.sg/guidelinesand-consultation/2020/02/advisory-guidelines-on-the-personal-data-protection-act-for-selected-topics) 3 Re PINC Interactive Pte Ltd [2022] SGPDPC 1, [10] – [12] 2 processes in the form of a security assessment of the risk from using, and storing, ‘live’ personal data in a testing environment. Such a security assessment could consider, for example, whether to restrict access to a smaller group of testers and limit the duration when live data is loaded in the testing environment. If the testing environment is accessible from the Internet, security assessment ought to also be carried out of the risk of unauthorised web entry. 20 Without such an assessment, the Organisation was not positioned to make an informed decision on whether the security arrangements to protect the personal data had been reasonable or had needed to be enhanced. The lack of sufficiently robust processes to protect personal data through proper safeguards, such as the conduct of a reasonable security assessment, amounted to a breach of the Protection Obligation by the Organisation. Failure to conduct reasonable periodic security reviews prior to the Incident 21 Second, the Organisation failed to conduct reasonable periodic security reviews for its servers. 22 The Commission’s previous decisions4 and the Guide5 have established that periodic security reviews should be conducted to a reasonable standard to identify and remedy any vulnerabilities. Such scheduled reviews should be in place as a basic practice as it would likely have resulted in the detection of the vulnerabilities arising from the outdated software and the risk of SQL injection techniques. The Organisation 4 5 WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 and Commeasure Pte Ltd [2021] SGPDPC 11 Guide, page 21, paragraph (g) admitted in its submissions to the Commission that it had not considered the need for such security reviews in its IT security policy. 23 Both Web Servers were internet-facing and were connected to production data stored in both Database Servers, thereby exposing the ‘live’ production data contained therein (containing personal data) to security risks. However, owing to its failure to conduct periodic security reviews for the Web and Database Servers, the Organisation did not recognise the risks engendered by the outdated software and did not take steps to assure itself that all internet-facing servers were adequately protected. Had the Organisation conducted reasonable periodic security reviews prior to the Incident, the vulnerabilities to SQL injection techniques in the Web Servers would have been known and remedied. The Incident could then very likely have been avoided. 24 For the above reasons, the Organisation was determined to have breached the Protection Obligation by (i) using personal data belonging to real users in a development environment (i.e. the Development Servers) without a sufficiently robust process for a reasonable security assessment of the risk, and (ii) failing to conduct reasonable security reviews prior to the Incident. Organisation’s position on the failure to update Microsoft SQL Server 2012 25 The Organisation explained its failure to update the Database Servers’ Microsoft SQL Server 2012 version and install Service Pack 4 as follows: (a) The Organisation’s IT team relied on Microsoft’s own auto-scan function to be alerted to available updating patches as a prompt for installation. This Microsoft tool ran once a month before the Incident. The tool, however, failed to detect that the installed version of Microsoft SQL Server 2012 in the servers required patching, and that the required patch in the form of Service Pack 4 had been available. (b) The tool had not previously failed to detect and alert about required updates. (c) The alternative option of requiring the IT team to conduct a manual review of all updates released by Microsoft every month had not been practical or reasonable as compared to relying on the auto-scan function. (d) The Organisation’s IT team did not use third-party scanning software to monitor and detect available patches because even these might not have identified the need to patch Microsoft SQL Server 2012 with Service Pack 4. 26 The Commission’s investigation revealed no known issues relating to the availability or installation of Microsoft SQL Server 2012 Service Pack 4 updates. The Protection Obligation required the Organisation to have sufficiently robust processes to protect personal data through regular patching / updates / upgrades of important software. The question is whether the Organisation’s reliance on system prompts in the form of alerts from the Microsoft auto-scan function had amounted to a sufficiently robust process for patching in the circumstances of this case. 27 Service Packs are significant collations of updates and patches that have been released. When released, Service Packs effectively provide a new baseline of updates and patches. On the question above, the Commission noted that the Microsoft Knowledge Base site indicated that the Service Pack 4 update had been available through the usual Windows Update auto-scan function since October 2017. This means that it would have been available for almost 4 years at the time of the Incident. Considering that an important software patch in the form of the Service Pack 4 had in this case been available for almost 4 years, the Organisation’s reliance on system prompts such as alerts through the auto-scan function had not been a sufficiently robust process to patch important software for the security of personal data. The Organisation should be aware of significant Service Packs and consciously decide whether to upgrade. The Commissioner’s Decision 28 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty, the matters set out at section 48J(1), and the factors listed at section 48J(6) of the PDPA were taken into account, including the following mitigating factors: 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 admitted that it had breached the Protection Obligation in Section 24(a) of the PDPA in failing to protect personal data in its possession by making reasonable security arrangements to prevent unauthorised access. 29 The Commission further notes that names and property transaction amounts were among the categories of personal data which was exfiltrated. Whilst the Commission took the exfiltration of such personal data into account in its decision, it does not consider these categories to be highly sensitive in nature as this information is, to a certain extent, already in the public domain. For example, a member of the public is able to look up such information through a land titles search on the Singapore Land Authority website (for names), or a search on the Urban Redevelopment Authority website for caveats lodged (for property transaction amounts). Thus, this information is publicly available as defined in s 2(1) of the PDPA. 30 Having considered all the relevant circumstances of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $37,000 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. 31 No further directions are necessary on account of the remedial measures already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION ",Financial Penalty,bc2f44656c288eb64e8e9ad0568ae8dadb65e251,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,11,11,1,952,Sembcorp Marine was found not in breach of the PDPA in relation to an incident whereby threat actor(s) exfiltrated personal data by exploiting a zero-day vulnerability present in an application.,"[""Protection"", ""Not in Breach"", ""Others"", ""Ransomware"", ""No breach""]",2023-03-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Sembcorp-Marine-Ltd_070223.pdf,Protection,No breach of the PDPA by Sembcorp Marine,https://www.pdpc.gov.sg/all-commissions-decisions/2023/03/no-breach-of-the-pdpa-by-sembcorp-marine,2023-03-10,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPCS 2 Case No. DP-2206-B9934 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Sembcorp Marine Ltd SUMMARY OF THE DECISION 1. On 25 July 2022, Sembcorp Marine Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a personal data breach that had occurred through the exploitation of the Log4J zero-day vulnerability (the “Incident”). 2. As a result of the Incident, the personal data of 25,925 individuals was exfiltrated. The personal data affected included their name, address, email address, NRIC number, telephone number, passport number, photograph, date of birth, bank account details, salary, and medical screening results. 1 3. The Organisation engaged an external cybersecurity company, Sygnia, to investigate the Incident. Its investigations found that the threat actor had exploited three Log4J vulnerabilities present in an application (the “Application”) to gain unauthorised access to a server as early as on 4 January 2022. The threat actor also deployed the “Cobalt Strike” beacon, conducted reconnaissance, and made lateral movements across several machines, before exfiltrating data between 10 and 23 June 2022, and deploying a ransomware on 28 June 2022. 4. Threat intelligence research revealed that the ransomware campaign which affected the Organisation began targeting users of the Application in January 2022. Given that reports of the Log4J vulnerability were first made in December 2021, it would have been difficult for the Organisation to detect and prevent the infiltration when it was one of the early targets, having been infiltrated as early as 4 January 2022. 5. After finding out about the Log4J vulnerability, the Organisation took prompt actions to identify instances of Log4J vulnerabilities across all the software application it was using. The Organisation started identifying instances of Log4J vulnerabilities across its systems on 14 December 2021. It applied the security patches immediately when they were made available by the respective software vendors. The Organisation also implemented workarounds recommended by the vendors, for systems which patches were not available or had not been released. Additional measures such as blocking incoming and outgoing Log4J traffic were also taken. 2 6. We are satisfied that the Organisation had made reasonable security arrangements to protect personal data in its possession and/or control in relation to the Incident. The Organisation had in fact adopted good practices in relation to its Information and Communications Technology (ICT) systems. This included a cybersecurity testing programme, regular vulnerability assessment and penetration testing, and cyber security monitoring. 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. 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. 3 ",Not in Breach,fa527b079427e2423cb0a716970088f54b497254,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,12,12,1,952,"A financial penalty of $62,400 was imposed on Eatigo International for failing to put in place reasonable security arrangements to protect users' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B""]",2023-03-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Eatigo-International-Pte-Ltd_211222.pdf,Protection,Breach of the Protection Obligation by Eatigo International,https://www.pdpc.gov.sg/all-commissions-decisions/2023/03/breach-of-the-protection-obligation-by-eatigo-international,2023-03-10,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 9 Case No. DP-2010-B7267 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Eatigo International Pte. Ltd. … Organisation DECISION Page 1 of 22 Eatigo International Pte. Ltd. Lew Chuen Hong, Commissioner — Case No. DP-2010-B7267 21 December 2022 Introduction 1. For an organisation to effectively safeguard the personal data in its possession or control, it must first know what its personal data assets are. The surest way to ensure such visibility is to maintain a comprehensive personal data asset inventory. This case is, amongst other things, a cautionary tale of the consequences of not maintaining a proper personal data asset inventory. 2. On 29 October 2020, the Personal Data Protection Commission (the “Commission”) was notified by a third party about a possible data leak by Eatigo International Pte. Ltd. (the “Organisation”). A cache of personal data that was suspected to be from the Organisation’s database was being offered for sale on an online forum (the “Incident”). Facts of the Case 3. The Organisation provides an online restaurant reservation platform which offers incentives such as discounts to its users. In its daily operations, it regularly collects and processes the personal data of its users in order to facilitate restaurant reservations and the provision of incentives. 4. After the Commission was notified of the Incident, it informed the Organisation on 30 October 2020 of an online forum purportedly selling the personal data from various ecommerce websites, including a database containing personal data that were suspected to have been obtained from the Organisation. Separately, the Organisation was also notified of the Incident Page 2 of 22 on the same day by a user and a Channel News Asia journalist. The Organisation proceeded to carry out investigations. 5. The Organisation’s investigations revealed that the personal data for sale on the online forum did not match any current databases in use by the Organisation at the time of the Incident, but matched the structure of a legacy database which contained user data as of late 2018, when the database was last updated (the “Affected Database”). The Affected Database was hosted on the infrastructure of a Cloud Service Provider located in Singapore, and was previously in use by the Organisation until 2018. Thereafter, the Organisation migrated to its current online platform, which entailed a complete redevelopment of data storage and infrastructure. Whilst the Organisation did not intend to continue to utilise the personal data contained in the Affected Database, it was nevertheless retained to support the migration of data to the new platform. After the migration, the Affected Database was not included in the Organisation’s Virtual Private Network (“VPN”) infrastructure. Unfortunately, as the Organisation transitioned to the current engineering team, knowledge of the Affected Database was lost. 6. The Organisation was unable to ascertain exactly when the threat actor gained unauthorised access to the Affected Database. However, since the Affected Database was last updated in late 2018, the Incident was likely to have occurred some time between 2018 and 2020 (when the Affected Database was put up for sale on an online forum). Investigations revealed the following: (a) At the time of the Incident, the Affected Database was accessible from the internet and accessible by anyone who had the requisite credentials; (b) None of the Organisation’s employees at the material time had knowledge of the Affected Database or possessed the credentials to access the Affected Database; Page 3 of 22 (c) The databases inside the Cloud Service Provider’s Relational Database Services (“RDS”) were intended to have randomly generated alphanumeric passwords of a minimum 13-character length. However, there had been no such password rotation rules implemented for the Affected Database; (d) There was no security review conducted on the protection provided to the personal data contained in the Affected Database; (e) There was no system in place to monitor the exfiltration of large volumes of data from the Affected Database; and (f) No personal data asset inventory or access logs were maintained, and the Organisation was unable to establish how or when the threat actor gained unauthorised access to the Affected Database. 7. The Affected Database held the personal data of approximately 2.76 million of the Organisation’s users. Because the Organisation had effectively lost track of a database of that size, network security and access control measures deployed by the Organisation were not applied to the Affected Database. 8. Consequently, the Affected Database was accessed and likely exfiltrated in the Incident and put up for sale on an online forum. A sample of 154 personal data sets were also posted on the online forum. The types of personal data affected (the “Dataset”) were as follows: (a) Name; (b) Email; (c) Telephone number; (d) Gender; (e) Passwords in MD5 Hash; and Page 4 of 22 (f) Facebook ID number and tokens of around 10 users, which can provide access to the Facebook accounts of users and their accounts with the Organisation’s online platform. 9. The personal data of a total of 154 of the Organisation’s users were displayed in the forum post, and appeared to have been randomly selected from the Affected Database. As of 13 November 2020, the post on the online forum no longer lists the Organisation’s personal data for sale. 10. Upon discovery of the Incident, the Organisation implemented, or has been in the process of implementing, the following remedial actions: (a) The Affected Database was securely backed-up and then deleted; (b) All databases were ensured to be accessible only inside VPN (i.e. no direct internet access); (c) All passwords to access databases were changed as of 30 October 2020; (d) Affected individuals were notified; (e) Security Settings on Systems Infrastructure were upgraded; (f) Different VPN for different categories of staff were created: (g) Access security for data storages and cloud services was improved, including increasing the password rotation and strengthening the password rules. (h) All personal data in all non-production was anonymised; (i) The logging and monitoring systems was reviewed to detect data access anomalies and trace access; (j) Access for external services used with the Organisation’s platform was reviewed; (k) Penetration Testing was conducted; (l) All staff were updated on policies relating to network security, and subject to Data protection and social engineering prevention training; Page 5 of 22 (m) All internal users in the Organisation’s cloud infrastructure and data storage were subject to review; (n) Access and error logging for all databases were added; (o) The entire infrastructure, including which servers are currently inside vs. outside demilitarized zone (DMZ), was subject to review; and (p) Accelerated implementation of recommendations of security audit completed by an external consultant in September 2020. Findings and Basis for Determination The Protection Obligation under section 24 of the PDPA 11. Based on the circumstances of the Incident as set out above, the Commission’s investigations centred on whether the Organisation had breached its obligation under section 24 of the Personal Data Protection Act 2012 (“PDPA”) to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (“the Protection Obligation”). 12. For the reasons set out below, it is determined that the Organisation failed to implement reasonable security arrangements to protect the Affected Database from the risk of unauthorised access. This includes a failure to ensure that the Affected Dataset was properly accounted for in the Organisation’s personal data asset inventory, and a failure to implement reasonable data protection processes. 13. In determining what constitutes reasonable security steps or arrangements, an organisation should have regard to the nature of the personal data in its possession and control, as well as the impact that the disclosure of the data might have on the affected persons. As Page 6 of 22 stated in the Commission’s Advisory on Key Concepts in the PDPA (the “Advisory”)1 at [17.2]: “There is no ‘one size fits all’ solution for organisations to comply with the Protection Obligation. Each organisation should consider adopting security arrangements that are reasonable and appropriate in the circumstances, for example, taking into consideration the nature of the personal data, the form in which the personal data has been collected (e.g. physical or electronic) and the possible impact to the individual concerned if an unauthorised person obtained, modified or disposed of the personal data. For example, in the employment context, it would be reasonable to expect a greater level of security for highly confidential employee appraisals as compared to more general information about the projects an employee has worked on.” 14. The Affected Database contained personal data relating to approximately 2.76 million individuals, encompassing personal data such as passwords, access IDs and Facebook tokens. Given the high volume of personal data contained in the Affected Database, it was incumbent on the Organisation to implement policies and practices to meet such security needs to discharge its obligation under the Protection Obligation. Lapses in managing of personal data asset inventory 15. For organisations with substantial personal data assets, the maintenance of an accurate and up-to-date personal data asset inventory is a pre-requisite for complying with the Protection Obligation. The personal data asset inventory should catalogue all personal data assets in the organisation’s possession or control, so as to ensure that such personal data is covered by the organisation’s security measures. Maintaining such an inventory ensures that the organisation 1 Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021) Page 7 of 22 retains the necessary institutional memory of the personal data assets that is or was previously under its possession or control even if there is turnover of staff. Any significant lapse in an organisation’s inventory management and maintenance would impair the organisation’s ability to know whether the data protection processes it implemented are sufficient to cover all its personal data assets. 16. This requirement to maintain a personal data asset inventory is not novel. As stated in Re Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 at [13]: “In addition, it is important for an organisation to be aware of and track its personal data assets. The creation and maintenance of a personal data asset register (i.e. a record identifying all personal data in the organisation’s possession or control) is a good practice that would assist organisations to comply with the Protection Obligation. An up-to-date personal data asset register provides the organisation with an accurate record of all the personal data in its possession or control, and enables the organisation to ensure its periodic security reviews covers the personal data assets. It also enables the organisation to more effectively review the implementation of its data protection policies, for example, the access control list setting out the employees who have access to the IT systems the personal data asset is stored in, whether the internal business owner of the personal data asset has reviewed it for data quality issues, and initiating the process for disposing personal data that have reached the end of its life cycle within the organisation.” (emphasis added) 17. Similarly, it was stated in Re Civil Service Club [2020] SGPDPC 15 at [15]: Page 8 of 22 “From the Appointed Day, the Organisation’s failure to take any reasonable steps to ensure sufficient obligations are imposed on the Vendor (when developing and troubleshooting the CMS, Membership Portal and Virtual Cards) to protect the Members Data was a breach of its obligations under section 24 of the PDPA. A period of about five years had elapsed since 2 July 2014 to 2 July 2019. The Organisation, as owner of the CMS, should have included it as part of its personal data asset inventory and ensured that its data protection policies covered personal data held in the CMS. Had this been done, the Organisation would have identified these gaps in the business requirements for the CMS, which would have set it down the path to rectifying these gaps through one or both of the options discussed in the preceding paragraph. The Organisation, as owner of the CMS, is responsible for identifying the omission and articulating its business requirements relating to the protection of personal data stored in the CMS. This would have led to action by the Vendor in recommending technical fixes to enhance the CMS. It is the failure to identify the omission and articulate business requirements, and for a not-trivial period of five years, that is the gravamen of the Organisation’s breach of the PDPA.” (emphasis added) 18. In this connection, the Commission’s Guide to Developing a Data Management Programme (the “Guide”) states that an organisation should establish a personal data asset inventory as part of Data Protection Impact Assessment (“DPIA”), and sets out the information that should be recorded by the organisation at pages 13 and 23: “By conducting a DPIA, an organisation would be in a better position to assess if the handling of personal data complies with the PDPA or data protection best practices, and to implement appropriate policy, technical or process measures. For more Page 9 of 22 information on the DPIA, please refer to the Guide to Data Protection Impact Assessments. As part of a DPIA, it is recommended to establish a data inventory (see Data Inventory Maps, Data Flow Diagrams and Other Registers on page 23) and classify the risk level of the data in the context that it is collected, used and disclosed throughout the data life cycle, from creation, distribution, storage, to disposal. This may be mapped onto a risk matrix for assessment and implementation of appropriate control for the identified risk levels. ... Data Inventory Maps, Data Flow Diagrams and Other Registers Known risks should be managed through a good understanding of the life cycle and flow of personal data in your organisation. This can be done through documenting the personal data handled using diagrams and charts such as data inventory maps or data flow diagrams, as illustrated in Annex C. The data inventory map and data flow diagram should also include information on the business purposes for collection, use and disclosure of personal data, the individuals and third parties who handle personal data under the organisation’s possession or control, as well as the classification of the data to manage user access. They should also deal with when and how the organisation should dispose of or anonymise the personal data for long-term archival. As good practice, it is important that employees and third parties access personal data on a need-to-know basis. Different sets of data may be accessed by different parties.” (emphasis added) Page 10 of 22 19. In the present case, the Organisation’s oversight in failing to maintain the Affected Database in its personal data asset inventory resulted in the omission to extend its extant security arrangements to the Affected Database. This resulted in the following: (a) The Organisation did not maintain proper records of the Affected Database and was unable to locate documentation related to user permission for the Affected Database. There was a dearth of records of the details of the data lifecycle of the personal data in the Affected Database from collection to disposal. (b) After the re-development and migration of the Organisation’s online platform, the Organisation did not conduct a proper handover of the Affected Database despite the turnover in staff. This led to the Organisation’s engineering team in 2020 having no knowledge of the existence of the Affected Database or its access credentials. (c) Since the Organisation lacked visibility of the Affected Database, it was omitted from the Organisation’s periodic security review. The Organisation thus did not have the opportunity to assess whether the Affected Database needed to be retained, or whether its security arrangements should be updated. During the Commission’s investigations, the Organisation indicated that the Affected Database should not have been retained following the successful migration of the Organisation’s online platform in 2018. It stands to reason that if the Organisation had covered the Affected Database in its periodic security reviews and assessed that it should be deleted, the Incident could have been prevented. (d) Since the Affected Database was effectively forgotten about, the Organisation also did not put in place any systems to monitor the exfiltration of data from the Affected Database, thus impeding its ability to react swiftly to mitigate the effects of the Incident. Page 11 of 22 20. The Organisation’s negligence in this regard left an internet-accessible database containing the personal data of approximately 2.76 million individuals (i.e. the Affected Database) outside its data protection architecture, creating a clear vulnerability that was exploited by threat actors. 21. The Organisation’s poor knowledge management often led to it providing inconsistent, extraneous and dilatory responses to the Commission’s notices to produce specified information and documents (“NTPs”) relating to the Organisation’s access models, causing the Commission to expend substantial time and resources to seek various rounds of clarifications with the Organisation. This includes, but is not limited to, the following responses to the Commission’s NTPs: (a) On 16 November 2020, the Organisation stated that the Affected Database was only accessible through VPN via certificates. After the Commission sought further clarifications, the Organisation stated on 14 December 2020 that it was in fact not included in the Organisation’s VPN structure; (b) On 16 November 2020, the Organisation stated that only 14 users had VPN access, but subsequently stated on 14 December 2020 that a total of 29 users with access without VPN; and (c) The Organisation also gave conflicting information about its password policies regarding the Affected Database. On 16 November 2020, it purported to have put in place a password policy for the Affected Database prior to the Incident. However, on 10 February 2021, it indicated that no specifically predefined password rules applied to the Affected Database. On 4 March 2021, after further clarifications were sought, the Organisation stated that it no longer had the username and password for the Affected Page 12 of 22 Database, and that nobody from its engineering team had any knowledge of the username and password. Other lapses in the Organisation’s data protection policies and processes 22. Besides failing to adequately maintain its personal data asset inventory, investigations also revealed other lapses and shortcomings in the Organisation’s data protection policies and processes. As referenced in paragraph 18, the Guide states that by establishing a personal data asset inventory as part of an organisation’s DPIA, it would be better positioned to assess if the handling of personal data complies with the PDPA or data protection best practices, and to implement appropriate policy, technical or process measures. In this regard, aside from its lapses in its management of its personal data asset inventory, the Organisation also did not implement some other basic data protection processes. 23. First, organisations that have a high volume of personal data within their possession and / or control should implement sufficiently robust processes to protect personal data through reasonable security monitoring. This ensures that organisations have sufficient situational awareness of its network security, enabling it to react timeously to data breaches. This step is embedded into the responsibilities of a data protection officer, as stated in the Advisory at [21.4]: “An organisation’s DPO plays an essential role in how the organisation meets its obligations under the PDPA. The responsibilities of the DPO often include working with senior management and the organisation’s business units to develop and implement appropriate data protection policies and practices for the organisation. In addition, the DPO would undertake a wide range of activities, which may include producing (or guiding the production of) a personal data inventory, conducting data protection impact assessments, monitoring and reporting data protection risks, Page 13 of 22 providing internal training on data protection compliance, engaging with stakeholders on data protection matters and generally acting as the primary internal expert on data protection.” (emphasis added) 24. Examples of such security monitoring measures are provided in the Commission’s Guide to Securing Personal Data in Electronic Medium at [4.1(j)] and [9.1] applicable at the material time2: “Conduct periodic checks for personal data stored in ICT systems. For personal data that is not required in any form anymore, securely dispose the data (refer to section 8). If there is a need to retain the data but not in identifiable form, e.g. for performing data analytics, consider anonymising the data. …. Computer networks allow communication between computers and devices that are connected to them. Internal corporate computer networks may be connected to external networks, such as the Internet. It is important for an organisation to ensure that its corporate computer networks are secure. Vulnerabilities in the network may allow cyber intrusion, which may lead to theft or unauthorised use of electronic personal data. Defences that may be used to improve the security of networks include: • Intrusion prevention systems (“IPS”) - a device or software application that monitors network or system activities and prevents malicious activities or policy violations; 2 The guide has been replaced by the Guide to Data Protection Practices for ICT Systems (updated 14 September 2021), which recommends similar security monitoring measures at pages 10 and 17. Page 14 of 22 • Intrusion detection systems (“IDS”) – a network security appliance that monitors network and system activities for malicious activities and may raise alerts upon detecting unusual activities; • Security devices that prevent the unauthorised transfer of data out from a computer or network; • Firewalls; and • Web proxies, anti-virus and anti-spyware software.” (emphasis added) 25. In this case, the high volume of personal data in the Affected Database necessitated a higher level of security awareness through robust security monitoring. However, the Organisation’s monitoring system extended only to performance and latency monitoring. The Organisation did not implement security monitoring for exfiltration of sizeable volumes of data based on pre-set limits. Given the considerable volume of personal data in the Organisation’s possession and / or control, including the personal data of the approximately 2.76 million individuals contained in the Affected Database, this is a reasonable security arrangement that the Organisation should have implemented. 26. Second, given the volume of personal data under the Organisation’s possession and / or control, the Organisation also should carry out periodic security audits which should include a reasonable vulnerability assessment of its IT infrastructure. This would entail the discovery and mapping of all parts of the Organisation’s network, including the Affected Database. If this had been carried out, it might have led to the re-discovery of the Affected Database, which would have allowed the Organisation to take the necessary steps to either improve the security of the Affected Database or delete it entirely. However, based on the Commission’s Page 15 of 22 investigations, the Organisation conducted no such security audits in relation to the Affected Database. The Commissioner’s Preliminary Decision 27. In determining whether any directions should be imposed on the Organisation under section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA were considered, with particular emphasis on the following factors: Mitigating Factors (a) The Organisation had implemented the remedial measures set out in paragraph 10 swiftly to address the Incident. Aggravating Factors (b) The Organisation was grossly negligent in its failure to keep proper records or documentation of the Affected Database and to effect a proper handover to new employees vis-à-vis the Affected Database. Most egregiously, there was no institutional memory amongst the Organisation’s employees of the Affected Database by late 2020, or of the access credentials. (c) The Organisation had left the Affected Database exposed to a risk of unauthorised access and exfiltration for a protracted period of time, from October 2018 to late 2020. (d) As stated in paragraph [21], the Organisation’s dilatory responses to the Commission’s NTPs resulted in delays in the investigations. Page 16 of 22 28. Additionally, the Organisation also impeded the Commission’s investigations by responding in an uncooperative and evasive manner to the Commission’s NTPs: (a) The Organisation objected to the Commission’s request for information about the access models implemented for current production databases, giving the excuse that it might create “additional security risks”; and (b) Similarly, objecting to provide information regarding access to the Affected Database, citing the reason that this was against their policy and might create “additional security risks” even though the Affected Database had already been deleted on 3 November 2020. 29. Organisations that are uncooperative and that throw up objections will only prolong investigations. The Commission will not be deterred by such tactics. If, as is possible in this case, the Organisation did not have the information or needed more time to recover the information, honesty is the best policy. Hiding behind vague notions like “additional security risks” without providing details can and will be interpreted as cavalier and obstructive, and will be taken as an aggravating factor when the eventual outcome is determined. 30. Based on the foregoing, the Commission made a preliminary decision to impose a financial penalty on the Organisation for its breach of the Protection Obligation. Representations Made by the Organisation 31. The Organisation was notified of the preliminary decision by way of the Commission’s letter dated 26 November 2021 and was invited to make representations. On 10 December 2021, the Organisation made the following representations to the Commission urging the Commission to impose a warning in lieu of a financial penalty, or to reduce the financial penalty to be imposed: Page 17 of 22 (a) The Organisation had not intended to frustrate the Commission’s investigation. Instead, the Organisation’s internal investigations and responses to the Commission’s NTPs were hampered due to diminished corporate knowledge of the Affected Database at the material time and the impact of the COVID-19 pandemic on its management and operations. In support, the Organisation stated that: i. On July 2018, the Organisation’s former Chief Technology Officer (“CTO”) resigned, with the various back-end engineers that he recruited following suit. Consequently, the new CTO and team of back-end engineers lacked corporate memory and had no knowledge of the Affected Database; ii. The internal investigations on the Incident were hampered by turbulence in the Company's organisation during the Covid-19 pandemic, and despite the steps taken to maintain system documentation, the Affected Database was not uncovered; and iii. The conduct cited in [21] and [28] above stemmed from a misunderstanding of the Commission’s queries and the new CTO, being from a different cultural background, being reluctant to provide sensitive data to the Commission; (b) The contemplated financial penalty in the preliminary decision would be crushing on the Organisation and would likely lead to financial distress and the closure of its business. As the Organisation operates in the food and beverages industry, its business suffered during the COVID-19 pandemic and left it in a risky financial position from which is it has yet to recover from. Any financial penalty imposed would adversely affect the Organisation’s business, and deter any further investors or lenders from providing any further loans or investments to the Organisation; and Page 18 of 22 (c) The impact of the Incident was limited. The Organisation raised the following points in support: i. The Organisation did not collect NRIC numbers, birth dates and sensitive financial data such as credit card information. The login passwords that were collected were encrypted using MD5 Hash ; ii. As of 10 December 2021, the Company received less than 100 requests from users to delete their accounts following the Incident; and iii. The online forum post initially offering personal data from the Affected Database for sale appears to have been taken down as of 13 November 2020. Diminished corporate knowledge and conduct during the Commission’s investigations 32. The Organisation’s representations in [31(a)] do not merit a waiver or reduction in the financial penalty imposed. Staff turnover is no excuse for a lack of corporate knowledge, and it is incumbent on organisations to take reasonable steps to bolster institutional memory to manage any security risks arising thereof. This includes the implementation of practices such as the maintenance of a personal data asset inventory as detailed in [16] to [18], which would have enabled it to conduct proper handovers to new staff. 33. As for the difficulties experienced by the Organisation during its own internal investigations and any misunderstandings it may have had in relation to the Commission’s NTPs, it should have been candid with the Commission about its difficulties and sought clarifications and extensions of time to respond to the NTPs. Instead, its lack of transparency during the investigation stage caused the Commission to expend substantial time and resources in engaging the Organisation. In its representations, the Organisation has also admitted that it Page 19 of 22 should have substantiated its position during the NTP stage to avoid giving the Commission the impression that it was being uncooperative and evasive. Likely impact of a financial penalty on the Organisation 34. One of the considerations in the imposition of a financial penalty is the likely impact of the imposition of such penalty on an organisation, including the ability of the organisation to continue its usual activities: see section 48J(6)(i). When determining the appropriate financial penalty, the Commission has consistently considered the financial circumstances of the organisation or person involved, bearing in mind that financial penalties imposed should avoid imposing a crushing burden or cause undue hardship on the organisation or person3. 35. After careful consideration, the Commission accepts the Organisation’s representation at [31(b)] that the imposition of the financial penalty proposed would likely lead to financial distress and the closure of its business. However, a mere warning is inappropriate in view of the egregiousness of the Organisation’s breach of the PDPA and the impact of the Incident. Hence, the imposition of a reduced financial penalty, to be paid out in instalments, would be more proportionate and appropriate in ensuring the Organisation’s compliance with the PDPA. 36. In arriving at its decision, the Commission had regard for the following factors concerning the Organisation’s financial situation, and the likely impact that the proposed financial penalty in the preliminary decision would have on it: (a) In the Organisation’s audited financial statements for the financial year ending 31 December 2020, its independent auditor stated that there was significant doubt on 3 Re Jigyasa [2021] SGPDPCR 1; Commeasure Pte Ltd [2021] SGPDPC 11; and Neo Yong Xiang (trading as Yoshi Mobile) [2021 SGPDPC 12 Page 20 of 22 the ability of the Organisation to continue as a going concern and to realise its assets and discharge its liabilities in the ordinary course of business; (b) The Organisation’s monthly income statements from 2021 indicated that it was incurring heavy net losses on a month-to-month basis (with the exception of one month); and (c) 37. The Organisation had various substantial short-term loans due in the near future. The above evinces a clear picture of an organisation in a parlous financial situation caused by the COVID-19 pandemic, with various debts and liability (some incurred to keep the business afloat) coming due in the near future. In view of this situation, the Commission shall refrain from imposing a financial penalty that might push the Organisation’s business even closer to the brink. Impact of the Incident 38. The Commission had already taken into account the impact of the Incident when calibrating the financial penalty in the preliminary decision. At the same time, the Commission also took into consideration the fact that the Affected Database contained the personal data of a very high number (2.76 million) of individuals, which necessitated the implementation of more robust security measures by the Organisation. The impact of the Incident should not be minimised, and the financial penalty imposed should reflect this. Acceptance of the Commission’s findings 39. Additionally, the Commission notes that the Organisation voluntarily accepted the Commission’s findings in the preliminary decision that it had failed to comply with the Protection Obligation and explicitly indicated that it would not seek to challenge these findings. Page 21 of 22 The Organisation’s voluntary acceptance of liability (even at this late stage) ought to be reflected in the financial penalty. Had the Organisation accepted responsibility for the Incident at an earlier stage of the investigation, it could have significantly shortened the time for investigations and resolution of this case through the expedited breach procedure and also benefited from greater mitigatory considerations. Nonetheless, an organisation that voluntarily accepts responsibility for its non-compliance with the PDPA should be recognised as an organisation that demonstrates its commitment to the Accountability Obligation and shows that it can be responsible for the personal data in its possession or under its control4: see [46] of Farrer Park Hospital Pte Ltd [2022] SGPDPC 6. 40. Having considered all the relevant factors in this case including the representations made by the Organisation, the Commission hereby requires the Organisation to pay a financial penalty of $62,400 in 12 monthly instalments by the due dates as set out in 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. 41. In view of the remedial actions already been taken by the Organisation, no further directions need be issued to the Organisation YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 4 Refer to section 11(2) of the PDPA. Page 22 of 22 ",Financial Penalty,d2f8ccda43f78a0b1e149fae38950a4570f436dc,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,13,13,1,952,Directions were issued to CPR Vision Management Pte Ltd to conduct a security audit of its technical and administrative arrangements for the protection of personal data in its possession or control and rectify any security gaps identified in the audit report. This is pursuant to a data breach incident where CPR Vision Management Pte Ltd’s server and network storage devices were subjected to a ransomware attack.,"[""Protection"", ""Directions"", ""Others"", ""Ransomware"", ""Data Intermediary"", ""Retention""]",2023-02-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---CPR-Vision-Management-Pte-Ltd---071222.pdf,Protection,Breach of the Protection Obligation by CPR Vision Management Pte Ltd,https://www.pdpc.gov.sg/all-commissions-decisions/2023/02/breach-of-the-protection-obligation-by-cpr-vision-management-pte-ltd,2023-02-10,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPCS 17 Case No. DP-2207-B8974 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And CPR Vision Management Pte Ltd L’Oreal Singapore Pte Ltd L’Occitane Singapore SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (the “Commission”) received data breach notification reports from (i) L’Oreal Singapore Pte Ltd (“L’Oreal”) on 29 October 2021 and (ii) L’Occitane Singapore Pte Ltd (“L’Occitane”) on 1 November 2021 respectively of a ransomware attack on their customer relationship management (“CRM”) system vendor, CPR Vision Management Pte Ltd (the “Organisation”). The Organisation is a data intermediary that helped to process personal data collected by L’Oreal and L’Occitane. 2. The ransomware attack affected a server and three network attached storage (“NAS”) devices in the Organisation’s office (“office network”), and led to the Page 1 of 6 encryption of the personal data belonging to 83,640 L’Occitane’s customers and 35,079 L’Oreal’s customers, which included their name, address, email address, mobile number, NRIC number, date of birth, age, gender, race, nationality, loyalty points and amount spent. 3. The Organisation requested, and the Commission agreed, for this matter to proceed under the Expedited Decision Breach Procedure. To this end, the Organisation voluntarily and unequivocally admitted to the facts set out in this decision. It also admitted to a breach of the Protection Obligation under Section 24 and the Retention Limitation Obligation under Section 25 of the Personal Data Protection Act (the “PDPA”). 4. The Organisation’s internal investigations found the threat actor had first gained access to the office network via a compromised user account VPN connection on 13 October 2021 before executing the ransomware attack on or about 15 October 2021. However, due to the limited data logs available on the Organisation’s FortiGate firewall and VPN appliance, the Organisation was not able to determine how the threat actor gained access to the compromised user account VPN. As part of the immediate remediation efforts, the Organisation reset the credentials of the compromised user account VPN and the password credentials of all VPN accounts across the Organisation. Page 2 of 6 5. The Organisation admitted that its endpoint security solution would have been able to detect and block the unauthorised entry attempts to the office network affected in the Incident. However, the Organisation failed to extend the deployment of this protection solution to the affected office network. This could have been because the domain controller server within the affected office network had been earmarked to be decommissioned after the data was copied to MS365 Sharepoint. Another reason for the omission may have been the fact that the Organisation set up the affected office network for business continuity purposes, when it shifted to its new premises, sometime between 6 – 9 April 2020, on the eve of the nation-wide COVID-19 circuit breaker in Singapore. 6. The Commission finds the Organisation in breach of the Protection Obligation as it failed to have reasonable security arrangements in place to protect the personal data in its possession and control. As a CRM system vendor, the Organisation processes and processed a high volume of web traffic containing personal data on behalf of many e-commerce retailers, including L’Oreal and L’Occitane, and would ordinarily be held to a higher standard. The Organisation’s omission to deploy its endpoint security solution to the affected office network suggests that the Organisation failed to maintain an inventory of its data assets. 7. Even if there were extenuating circumstances in April 2020 which could have partly excused the Organisation’s omission to include the affected office network in its data inventory, it was inexcusable for the Organisation to let this state of affairs Page 3 of 6 persist for more than one and-a-half years, from April 2020 until October 2021. We should add however, that as part of its remediation efforts, the Organisation has since ensured that its endpoint security solution was deployed to all office and enduser devices. 8. The Organisation also admitted to being in breach of the Retention Limitation Obligation. The Organisation admitted that the affected personal data in the Incident had been legacy content, which should have been deleted together with the domain controller server earmarked for decommissioning, and for which no business or legal purpose existed for retention. The Organisation highlighted however, that this lapse was not in accordance with its own data retention policy. Had the Organisation complied with the Retention Limitation Obligation and deleted the personal data in question, the Incident would not have amounted to a breach of the Retention Limitation Obligation under the PDPA. 9. In the course of our investigations, L’Oreal furnished documentary evidence which showed that L’Oreal had specifically instructed the Organisation, pursuant to its data retention policies, to delete the affected personal data on 26 March 2021. This was duly acknowledged by the Organisation, and the Organisation furnished a purported Certificate of Destruction dated 17 May 2021 stating that the personal data had been deleted on 6 May 2021. Page 4 of 6 10. Similarly, L’Occitane also raised its concerns that the Organisation failed to seek its prior written consent before duplicating the personal data to other nonproduction environments. 11. The Commission is satisfied that neither L’Oreal nor L’Occitane had any knowledge of the retention and storage of the legacy personal data by the Organisation on the affected NAS device; and neither had any control over the NAS device used by the Organisation to store the personal data affected by the ransomware attack. Both L’Oreal and L’Occitane had also adequately provided in their contracts with the Organisation to ensure compliance with the Protection and Retention Limitation Obligations under the PDPA. The Commission is therefore of the view that despite the personal data breach incident, L’Oreal and L’Occitane had acted consistently with and complied with the relevant obligations under the PDPA. 12. Having considered the circumstances set out above, including the Organisation’s upfront admission of liability, and the fact that data analysis conducted by the data security team of the Organisation’s parent company did not uncover any evidence to suggest that data exfiltration or modification had occurred, the Commission considered that it would be most appropriate in lieu of imposing a financial penalty, to direct the Organisation to comply with the following action: a. Conduct a thorough security audit (with report) of its technical and administrative arrangements for the protection of personal data in its possession or control; b. Rectify any security gaps identified in the security audit report; Page 5 of 6 c. Conduct a comprehensive review of all of the Organisation’s databases containing personal data to ensure full compliance with the Retention Limitation Obligation under Section 25 PDPA; d. Review and update the personal data policies of the Organisation as applicable, including clarification of the roles of data intermediaries and vendors in complying with the Retention Limitation Obligation under section 25 of the PDPA, within 60 days from the date the security audit report is delivered to the Organisation; and e. Inform the Commission within 1 week of the completion of the steps directed above. The following are the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation must 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 or disposal or similar risks and; (b) the loss of any storage medium or device on which personal data is stored. Retention of personal data 25. An organisation must cease to retain its documents containing persona data, or remove the means by which the personal data can be associated with particular individuals, as soon as it is reasonable to assume that – (a) the purpose for which the personal data was collected is no longer being served by retention of the personal data; and (b) retention is no longer necessary for legal or business purposes. Page 6 of 6 ",Directions,7e9168136ea5e122bc3f4577c70535e0fc6c7689,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,15,15,1,952,"Directions were issued to Thomson Medical to conduct scan of the web to ensure no publication of affected personal data online and to include in the review of its application deployment process, measures such as the arrangements for security testing and the implementation of data retention policy. This is pursuant to a data breach incident from an unsecured Health Declaration Portal which enabled public access to visitors' personal data.","[""Protection"", ""Directions"", ""Healthcare""]",2022-12-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Thomson-Medical-Pte-Ltd---140922.pdf,Protection,Breach of the Protection Obligation by Thomson Medical,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-protection-obligation-by-thomson-medical,2022-12-19,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPCS 15 Case No. DP-2010-B7246 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Thomson Medical Pte. Ltd. SUMMARY OF THE DECISION 1. On 26 October 2020, the Personal Data Protection Commission (the “Commission”) was notified that the Thomson Medical Pte. Ltd. (the “Organisation”) Health Declaration Portal was not secure, enabling public access to the personal data of visitors (the “Incident”) stored in a CSV (comma separated values) file. 2. Visitor data collected on the Organisation’s Health Declaration Portal had been stored concurrently in a publicly-accessible CSV file as well as a secured 1 database from 16 April 2020, when the health declaration portal was first used by the Organisation to 8 September 2020, when the storage of the visitor data was changed to only the secured database instead of the CSV file. The CSV file was hosted on the Organisation’s web server. 3. The Organisation admitted that, contrary to the instructions given to the employee to switch the data storage from the CSV file to secured database exclusively, and the organisation’s protocols, its in-house developer had omitted to remove a software code, causing the visitor data to be stored in the CSV file and the same in-house developer had omitted to change the default web server configuration, thereby allowing public access to the hosted CSV file. The switch to storage in a secured database would have ensured access controls by requiring user login ID and secure password protection, as well as encryption of data transfers using SSL certificates. The access controls would ensure that only authorized users would be able to access the data. 4. The Commission’s investigations revealed that the affected CSV file contained the personal data of 44,679 of the Organisation’s visitors, including the date and time of visit, temperature, type of visitor (purpose of visit), name of visitor, name of newborn, contact number, NRIC/FIN/passport number, doctor/clinic name or room visiting, and answers to a health declaration questionnaire (which included a declaration by the visitor that he/she did not have any symptoms or recent exposure to the Covid-19 virus). 2 5. The Organisation accepted that it was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act (“PDPA”). The Commission finds that the Organisation had breached section 24 of the PDPA for two reasons. 6. First, even though the Organisation’s existing policies required the visitor data collected to be stored in a secured database, the Organisation failed to ensure that there were processes in place to ensure these policies and instructions would be complied with. The Organisation stated that the in-house developer had been the only staff in its IT department familiar with the programming language used for the health declaration form. This, however, should not have prevented the Organisation, as an example, from requiring the in-house developer to demonstrate to another staff member, and for that staff member to verify that the storage instructions had been complied with. As noted in Re Aviva Ltd [2017] SPDPC 14, relying solely on individual employees to perform their tasks diligently, with no oversight or supervision, is not a reasonable security arrangement. 7. Second, the Organisation failed to conduct reasonable pre-launch testing before the Health Declaration Portal went live. While acceptance testing and some technical tests were conducted, there had been no security testing to verify that there were access controls to the visitor data collected. 3 8. Having said that, it is a mitigating fact that the Organisation’s in-house developer sought to comply with the Organisation’s policies and swiftly rectified the software code on 8 September 2020, when he first discovered the coding error whilst updating the health declaration questionnaire. 9. The forensic investigator engaged by the Organisation did not uncover any evidence that the disclosed data had been exported and posted online, including on the Dark Web. The Organisation’s server logs also revealed that the CSV file was only accessed 4 times from 3 different local IP addresses. Given the timing of the access instances, it is probable that these instances were made by the complainant and by the Commission when investigating this matter, which suggests that the impact of this Incident was limited. 10. The Commission noted a parallel between the facts of this case and Re Spear Security Force Pte. Ltd. [2016] SGPDPC 12, in that both cases arose from a single complaint about a potential breach of the PDPA, with no other evidence suggesting that the personal data had actually been exposed to unauthorised third parties due to the lapses by the Organisation. 11. The personal data exposed here included the clinic or room that the individual intended to visit, and the reason for the visit. This could be to seek treatment, accompany a patient, or a business visit made by a sales representative of a pharmaceutical or medical device company. While the personal data exposed 4 included some health-related information, this had essentially been health declaration information for the purpose of containment of the pandemic. The information did not in fact reveal any potentially sensitive information such as whether the visitor was Covid-19 positive.1 12. The personal data disclosed is also not on par with Re Singapore Health Services Pte. Ltd.& Ors. [2019] SGPDPC 3 (“Singhealth”). In the Singhealth case, we recognised the sensitivity involved in the exposure of the affected individuals’ personal data in their “clinical episode information, clinical documentation, patient diagnosis and health issues and Dispensed Medication Records” as the information and personal data affected may allow one to deduce the condition for which a patient had sought treatment, and may lead to the unintended disclosure of serious or socially embarrassing illnesses.2 While there is some personal data in the present case which may reveal the clinic which an affected individual had sought treatment, this is of a much more limited scope as compared to the Singhealth case. 13. The Commission accepted that the Organisation took prompt remedial action to contain the exposure. This include removing the affected CSV file and changing all the passwords to the database, even though it was not affected by the Incident. To prevent a recurrence of a similar incident, the Organisation also 1 Cf Re Terra Systems Pte Ltd [2021] SGPDPC 7. 2 See Re Singapore Health Services Pte. Ltd.& Ors. [2019] SGPDPC 3, at [139]. 5 reviewed its application deployment process to take into consideration data security, and rectified all potential gaps discovered during a vulnerability scan. 14. Given the lack of evidence suggesting that personal data had actually been exposed to unauthorised third parties due to the lapses by the Organisation and the limited impact of the Incident, the Commission considered that it would be most appropriate in lieu of imposing a financial penalty, to impose directions. 15. Another factor which prompted the Commission to impose directions in lieu of a financial penalty was the fact that at the material time, such health declaration information was widely collected across the island. There was also a corresponding acceptance and support from members of the public of the need for the collection of such health declaration information in order for the relevant authorities to effectively respond to and control the potential spread of COVID19. 16. Given the above, the Commission directs the Organisation to carry out the following within 60 days: a. In relation to the Organisation’s remedial action of reviewing its application deployment process to take into consideration data security, i. The Organisation shall ensure that the intended measures include arrangements for reasonable pre-launch security testing 6 to be conducted before the launch of any new website, application, portal or other online feature for the processing of personal data; and ii. The Organisation shall ensure that the intended measures include the development and implementation of a data retention policy to meet the Retention Limitation Obligation under section 25 of the PDPA. b. In relation to the Organisation’s remedial action of scanning the Dark Web for evidence of exfiltration of the personal data, i. The Organisation shall conduct a scan of the Clear/Surface Web, as well as a renewed scan of the Dark Web to confirm that there is no evidence of publication of the affected personal data online. c. By no later than 14 days after the above actions have been carried out, the Organisation shall submit to the Commission a written update providing details of the actions taken. The following provision(s) of the Personal Data Protection Act 2012 had been cited in the above summary: Protection Obligation 24(a) Failure to protect personal data in its possession or under its control by making reasonable security arrangements to prevent – 7 (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks 8 ",Directions,2e2e404473e7fa064a0c51315f167b10b4810806,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,16,16,1,952,"A financial penalty of $72,000 was imposed on RedMart for failing to put in place reasonable security arrangements to protect the personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade""]",2022-12-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---RedMart-Limited---28102022.pdf,Protection,Breach of the Protection Obligation by RedMart,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-protection-obligation-by-redmart,2022-12-19,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2010-B7266 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And RedMart Limited … Organisation DECISION RedMart Limited [2022] SGPDPC 8 Lew Chuen Hong, Commissioner — Case No. DP-2010-B7266 28 October 2022 Introduction 1 Many organisations rely on web-based application programming interfaces (“API”) to enable computers or computer programs to communicate and facilitate the sharing of data between them. API keys are in turn used to authenticate users seeking to access APIs. If an organisation fails to implement reasonable security measures to safeguard the security of their API keys, this may allow threat actors unauthorised access to large troves of data stored within multiple interconnected environments. 2 On 29 October 2020, the Personal Data Protection Commission (“the Commission”) was notified that a database containing personal data of the customers of RedMart Limited (the “Organisation”) was being offered for sale on an online forum (the “Incident”). Subsequently, the Commission commenced investigations 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 The Organisation operated an online platform selling groceries and fresh produce to consumers. In 2016, the Organisation was acquired by Lazada Group (“Lazada”). Thereafter, 2 the Organisation began to integrate its platform with Lazada’s online platform. The customerfacing website and mobile application ceased operations on 15 March 2019. However, on the back end, the migration and integration of the Organisation’s system into Lazada’s system was not completed by that time. It is worth setting out in some detail the Organisation’s information technology architecture to understand the backdrop against which the Incident occurred. 4 From March 2012 until its acquisition by Lazada, the Organisation’s business applications (including its customer facing website, mobile application, warehouse and delivery back-end applications) were stored in RedMart’s Amazon Web Services Virtual Public Cloud (the “AWS Environment”). The personal data of its customers and sellers were in turn, always stored in a MongoDB database within RedMart’s Alibaba Virtual Public Cloud. Whilst the MongoDB database is stored within cloud infrastructure that belongs to the Alibaba Group, the Organisation remained responsible for managing its cloud environment (hereinafter, the “RedMart Cloud”). The Organisation did not encrypt the MongoDB database, or implement any password authentication requirement to access the MongoDB database. 5 After its acquisition, the Organisation’s intention was to re-design and migrate all the relevant databases and applications from the AWS Environment into the RedMart Cloud to facilitate its integration with Lazada’s systems and environment by March 2021. However, given the substantial time and resources required to complete the re-design and migration, the Organisation opted to carry out the migration in stages. Following the acquisition and as a matter of priority, the Organisation migrated its front end, customer-facing systems to the RedMart Cloud to enable a seamless integration into Lazada’s environment and platform for its customers. This was completed on 15 March 2019, after which the Organisation shut down its public-facing consumer application and website. Additionally, the MongoDB database residing in the RedMart Cloud containing the affected customer and seller data was 3 disconnected from the application and website (the “Affected Database”), and thereafter access by the Organisation’s customers was disabled. In contrast, the Organisation’s back-end business applications and systems (such as 6 order fulfilment, inventory, transport and warehousing) and its seller portal continued to be hosted on the AWS Environment and linked to the Affected Database contained in the RedMart Cloud. 7 Concomitantly, the Organisation’s back-end systems and IT infrastructure during the interim period was structured in the following manner: (a) The Organisation’s GitHub Enterprise repositories (the “GitHub Repositories”), were accessible by the Organisation’s employees possessing GitHub user and administrative accounts. The Organisation used the GitHub Repositories to store, amongst other things, sensitive source codes including a Chef1 key that functioned as a high privilege access key to the AWS Environment. The Organisation implemented the following access control measures vis-à-vis the GitHub Repositories: i. For GitHub user accounts, the Organisation followed GitHub’s password policy, which required the use of passwords which were either eight characters long if it included a number and a lowercase letter, or 16 characters long with any combination of characters; and ii. For GitHub administrator accounts, two-factor authentication (“2FA”) was required on top of the password requirements above. “Chef” is an orchestration tool used for automated provisioning and management purposes within an AWS environment. 1 4 (b) The AWS Environment was accessible through the Chef key, and contained various private Simple Storage Service (“S3”) buckets 2 , one of which contained another sensitive API key – the Hubot3 key. (c) Lastly, the AWS Environment was connected to the RedMart Cloud through an OpenVPN4 connection. The Affected Database was stored within the RedMart Cloud. The Incident 8 Sometime in September 2020, an unidentified threat actor (“TA”) gained unauthorised access to the GitHub user account of a member of the Organisation’s DevOps (i.e. software development and IT operations) team. The TA utilised the compromised GitHub user account to search through the GitHub Repositories and found the Chef key. Thereafter the TA used the Chef key to access the AWS Environment, whereupon he scanned through the Organisation’s private S3 buckets and located the Hubot key. 9 Using the Hubot key, the TA created a rogue Amazon Elastic Compute Cloud (“EC2”) instance in the AWS Environment. The TA also created a new firewall rule to enable a connection between the rogue EC2 instance and another part of the Organisation’s network hosted by the RedMart Cloud. The TA then traversed the OpenVPN connection (that linked the AWS Environment to the RedMart Cloud) to access the RedMart Cloud. 10 Once the TA had gained access to the RedMart Cloud, he proceeded to exfiltrate the Affected Database on 6 September 2020. Subsequently, the Affected Database was found on an online forum being offered for sale. 2 S3 buckets are public cloud storage resources in AWS which are similar to file folders. Hubot is a chat software that can be scripted to interact with an IT environment. 4 OpenVPN is a virtual private network system that implements techniques to create secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. 3 5 11 The Affected Database contained the following personal data: Customer accounts Seller business accounts Number of affected 898,791 individuals Types of personal a. Name a. Partial credit card number data b. Email address comprising first 6 and last c. Contact number 4 digits d. Residential address e. Partial credit card details b. Hashed account password comprising: • First 6 and last 4 digits of card number • Card owner’s name • Expiry date • Credit card billing phone number and billing address • Hashed account password • URL links of call recordings between customer service agents and the Organisation’s customers Remedial actions 12 Following the Incident, the Organisation and Lazada implemented the following remedial measures: Actions to mitigate the effects of the Incident (a) Disabled and reset the affected Chef and Hubot keys. (b) Disabled the compromised GitHub user account. 6 (c) Reset all other existing AWS API keys, GitHub user credentials and tokens (d) Deleted the EC2 instance created by the TA. (e) Logged out and reset of all affected customer and seller accounts on 30 October 2020. (f) Reviewed all of the Organisation’s servers with services connected to Internet. All sensitive services were filtered by a firewall. (g) Conducted vulnerability scanning of 31 Internet facing IP addresses. (h) Investigated all other existing MongoDB databases to search for traces of the TA. (i) Monitored the Lazada login page for brute force attacks. (j) Informed all affected individuals of the Incident via emails and broadcast on the Lazada online and application platforms on 30 October 2020. A media statement was also issued at the same time. Actions to prevent recurrence of the Incident or similar incidents (k) Implemented database authentication for all databases containing personal data. Restricted access to sensitive database from only authorised source IP addresses instead of network ranges. (l) Implemented 2FA for all GitHub accounts and removed unnecessary GitHub accounts and developer access keys. (m) Scanned for vulnerabilities in AWS critical Virtual Private Cloud instances. 7 (n) Performed a security architecture review of the Organisation’s multiple cloud network and intra-cloud micro-segmentation. (o) Reviewed all AWS Identity and Access Management user permissions to ensure no “create instance” permission. (p) Set up identity access management rules to restrict geographical locations from which API keys could be used to access the Organisation/Lazada cloud environments. (q) Reviewed all user identities and access privileges for all systems and applications used. Removed access privileges of all inactive accounts. (r) Implemented network traffic logging between the AWS Environment and RedMart Cloud. (s) Implemented network Access Control list and endpoint detection and response for windows instances for RedMart Cloud. (t) Implemented security monitoring to detect creation of any new cloud instance (u) Enabled Virtual Private Cloud (VPC) logs for security monitoring. (v) Required all of the Organisation’s employees to complete an online training course on privacy management and responsibilities in handling personal data. Findings and Basis for Determination The Protection Obligation under section 24 of the PDPA 8 13 Based on the circumstances of the Incident as set out above, the Commission’s investigation focused on whether the Organisation had breached its obligation under section 24 of the PDPA to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access and disclosure (“the Protection Obligation”). 14 In determining what constitutes reasonable security steps or arrangements, an organisation should have regard to the nature of the personal data in its possession and control, as well as the impact that the disclosure of the data might have on the affected persons. As stated in the Commission’s Advisory Guidelines on Key Concepts in the PDPA (the “Advisory Guidelines”)5 at [17.2]: “There is no ‘one size fits all’ solution for organisations to comply with the Protection Obligation. Each organisation should consider adopting security arrangements that are reasonable and appropriate in the circumstances, for example, taking into consideration the nature of the personal data, the form in which the personal data has been collected (e.g. physical or electronic) and the possible impact to the individual concerned if an unauthorised person obtained, modified or disposed of the personal data. For example, in the employment context, it would be reasonable to expect a greater level of security for highly confidential employee appraisals as compared to more general information about the projects an employee has worked on.” (emphasis added) 15 Given the high volume of personal data contained in the Affected Database (approximately 898,791 individuals, encompassing personal data such as names, email 5 https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-thepersonal-data-protection-act 9 addresses, residential addresses, contact numbers and partial credit card details), it was incumbent on the Organisation to implement policies and practices that were commensurate with the Organisation’s higher-level security needs to discharge its obligation under the Protection Obligation. 16 For the reasons set out below, it is determined that the Organisation failed to implement reasonable security arrangements to protect the Affected Database from the risk of unauthorised access. Whether the Organisations had contravened the Protection Obligation 17 Based on the Organisation’s IT architecture as detailed above, the Affected Database was placed behind various levels of security controls within RedMart Cloud. This meant that a threat actor had to get through various access points to access the Affected Database. The implementation of network segmentation as part of layered defence is a reasonable strategy for defence-in-depth. However, a complex IT architecture can be defeated by simple errors, especially when the high-value data embedded within such complex systems are so often the target of sophisticated threat actors. The complexity of the Organisation’s network architecture does not paper over the cracks in its security arrangements – at every level of defence, the Organisation’s systems presented clear vulnerabilities that should have been addressed. 18 First, the Organisation failed to implement reasonable access control on its employers’ user GitHub accounts, which allowed the TA access to the GitHub Repositories. As stated in paragraph [7(a)], the access control measures were more stringent for GitHub administrative accounts than for GitHub user accounts. While this adequately dealt with the differentiation of ability to make configuration and other changes to the Organisation’s GitHub Repositories, it did not make any distinction to the type of data stored within the repositories. This disparity in 10 access controls was not sensitive to the fact that both types of accounts had equal abilities to access important files within the GitHub Repositories including the Chef key, which provided access to the AWS Environment. Data with higher security implications (such as the Chef Key) ought to be secured to a higher degree than other types of data. It is, of course, open to the Organisation to secure all data in its GitHub Repositories at the higher level. Indeed, as stated in paragraph 12(l), the Organisation and Lazada, as part of their remedial measures postIncident, implemented 2FA for all its GitHub accounts. 19 Second, the Organisation did not implement sufficient access controls to protect and limit access to the Chef and Hubot keys, which enabled highly privileged access to various environments within the Organisation’s systems. Not all accounts need access to the Chef and Hubot keys; and even for accounts that had access to them, they ought to be periodically reviewed to determine whether continued access were necessary. At an organisation-wide level, investigations revealed that the Organisation did not conduct periodic management reviews to ensure that the access to Chef and Hubot keys were limited to the GitHub accounts that required such access, or to remove access from accounts that no longer needed it (including removing unnecessary GitHub accounts altogether). This is a fundamental data security practice. As suggested in the Commission’s Guide to Data Protection by Design for ICT Systems6: “12. Regularly review user accounts This ensures that all user accounts are legitimate. There should be processes to update or remove user accounts, for instance, when a user has left the organisation. Test accounts should also be removed after test activities have been completed. 6 https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Other-Guides/Guide-to-Data-Protection-by-Designfor-ICT-Systems-(310519).ashx?la=en 11 Separately, there should also be a process to review user accounts regularly. The review should include ensuring all the rights assigned are indeed necessary.” (emphasis added) 20 In this connection, best practice dictates that the principle of least privilege should apply i.e. each employee be given only the minimum level of access rights or privileges necessary for that employee to complete an assigned operation. This would limit the damage in case a vulnerability is exploited, as in this case where the TA gained unauthorised access to a GitHub user account. This principle was also espoused in GitHub’s own Secure Design Principles7. The Organisation’s failure to limit access to the Chef and Hubot keys at the material time allowed the TA to access the Chef key, and consequently the AWS Environment, through a GitHub user account. 21 On a more granular level, insufficient security measures were implemented to protect the Chef and Hubot keys, as both were stored in plain text files that were not encrypted or even password-protected. Specifically: (a) The Chef key was hardcoded in source code and stored in the GitHub repositories, and was accessible to a large group of developers from the Organisation, Lazada and Alibaba for the purpose of knowledge sharing. By allowing so many accounts to access the Chef key in such a manner, the risk of exposure and exploitation was heightened. (b) The Hubot key was stored in plain text in an AWS private S3 bucket. Therefore, any account that accesses the AWS Environment was able to access the Hubot key as a 7 https://github.com/OWASP/DevGuide/blob/master/02Design/01Principles%20of%20Security%20Engineering.md 12 conduit from which to access the RedMart Cloud and the Affected Database stored therein. 22 The manner in which the Chef and Hubot keys were stored in the GitHub Repositories and AWS Environment were manifestly inadequate in view of the circumstances, and this vulnerability was exploited by the TA to access the keys after he gained access to the GitHub Repositories and AWS Environment respectively. Ideally, such keys ought to be stored in a separate location such as Secrets Manager within the AWS Environment (i.e. a dedicated key vault). The Organisation should not have embedded the Chef and Hubot keys directly in the source code. This is also reflected in AWS Access Keys best practices8, which the Organisation should have been aware of given its usage of the AWS Environment since 2012: “Observe these precautions when using access keys: • Don't embed access keys directly into code. The AWS SDKs and the AWS Command Line Tools enable you to put access keys in known locations so that you do not have to keep them in code.” (emphasis added) 23 Such best practices applies to of all platforms that use APIs, and are not confined to AWS. They are echoed in Google’s best practices for securely using API keys9, which are meant to apply to Google Cloud but are nevertheless apposite here: 8 https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html https://support.google.com/googleapi/answer/6310037?hl=en#:~:text=Delete%20unneeded%20API%20keys% 3A%20To,use%20the%20newly%2Dgenerated%20keys 9 13 “Best practices for securely using API keys When you use API keys in your Google Cloud Platform (GCP) applications, take care to keep them secure. Publicly exposing your credentials can result in your account being compromised, which could lead to unexpected charges on your account. To keep your API keys secure, follow these best practices: • Do not embed API keys directly in code: API keys that are embedded in code can be accidentally exposed to the public, for example, if you forget to remove the keys from code that you share. Instead of embedding your API keys in your applications, store them in environment variables or in files outside of your application's source tree. • Do not store API keys in files inside your application's source tree: If you store API keys in files, keep the files outside your application's source tree to help ensure your keys do not end up in your source code control system. This is particularly important if you use a public source code management system such as GitHub. • Restrict your API keys to be used by only the IP addresses, referrer URLs, and mobile apps that need them: By restricting the IP addresses, referrer URLs, and mobile apps that can use each key, you can reduce the impact of a compromised API key. You can specify the hosts and apps that can use each key from the GCP Console Credentials page and then create a new API key with the settings you want, or edit the settings of an existing API key. • Restrict your API keys to be usable only for certain APIs: If you have multiple APIs enabled in your project and your API key should only be used with some of them, restrict usage of that key to those APIs. You can specify the allowed 14 APIs for each key from the GCP Console Credentials page and then create a new API key with the settings you want, or edit the settings of an existing API key. • Delete unneeded API keys: To minimize your exposure to attack, delete any API keys that you no longer need. • Regenerate your API keys periodically: You can regenerate API keys from the GCP Console Credentials page by clicking Regenerate key for each key. Then, update your applications to use the newly-generated keys. Your old keys will continue to work for 24 hours after you generate replacement keys.” (emphasis added) 24 The Organisation claimed that it was constrained from implementing password protection and encryption for the Chef and Hubot keys by technical issues, and that the implementation of password protection or encryption was not feasible or practical given the keys’ core administrative and automating technical functions. The mere existence of technical issues does not exculpate the Organisation, or justify the Organisation’s decision to embed the Chef and Hubot keys into source code. Technical issues are not insurmountable, and it is open to the Organisation to expend the necessary time, effort and resources to troubleshoot and resolve them. However, investigations revealed that the Organisation did not make sufficient efforts to resolve the technical issues in a timely manner, and were thus responsible for its difficulties in implementing access controls for the Chef and Hubot keys. More broadly, even if the Chef and Hubot keys were not compatible with password protection or encryption, there were a variety of other methods available to safeguard the security of the keys as set out in the best practices set out above, such as removing unnecessary GitHub accounts, restricting access to only certain GitHub administrative accounts or storing the keys separately in a configuration 15 file or a key vault. Nothing prevented RedMart from adhering to such best practices, as is evident by the fact that all these measures were implemented after the Incident occurred. 25 Lastly, the Organisation also did not implement separate authentication requirements, for the Affected Database. Once the TA accessed the RedMart Cloud, this enabled the TA to access and exfiltrate the Affected Database. Instead, the only measures implemented to safeguard the Affected Database were the access requirements for the RedMart Cloud environment in general, which was circumvented by the TA through his possession of the Hubot key. This reflects a failure of the Organisation’s attempt to deploy a reasonable “defence in depth” strategy (despite its multiple layers of access) to safeguard the security of the Affected Database, as it should have implemented separate authentication requirements for the Affected Database to prepare for the contingency of someone gaining unauthorised entry into the RedMart Cloud. 26 At a basic level, this should have included access controls such as password protection. Further, given the high volume of personal data contained in the Affected Database, the Organisation should also have taken steps to implement more stringent access controls, such as limiting access only to certain authorised network connections / interfaces. The Center for Internet Security MongoDB 5 Benchmark10 recommends requiring authentication of, amongst others, users and servers before allowing access to a MongoDB database on the following basis: “2 Authentication This section contains recommendations for requiring authentication before allowing access to the MongoDB database. 10 https://cissecurity.org/benchmark/mongodb 16 … Rationale: Failure to authenticate clients, users, servers can enable unauthorized access to the MongoDB database and can prevent tracing actions back to their sources. It's highly recommended that password length and complexity also be in-place. When performing the traditional user/password authentication against MongoDB there is not in-place intrinsic password complexity check and there is no LOCKING mechanism with multiple failure logins. So, MongoDB is prone to brute force attacks compared to other database systems.” (emphasis added) 27 The Organisation, again, cited technical difficulties for why separate authentication requirements were not implemented for the Affected Database. Again, such technical difficulties could have been overcome if the Organisation had expended the effort and resources to do so. The Commissioner’s Decision 28 In determining whether any directions should be imposed on the Organisation under section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA were considered, with particular emphasis on the following mitigating factors: (a) the Organisation was cooperative with the Commission’s investigations, responding to the Commission’s queries in a prompt and forthcoming manner; 17 (b) the Organisation had put in place some good data de-identification practices for the credit card numbers in its possession by redacting part of the data and storing only partial credit card details. This reduced the sensitivity and harm that might be caused when personal data within its control are disclosed in a data breach; and (c) the Organisation swiftly implemented effective measures to mitigate the effects of the incident and prevent recurrences. 29 The Organisation was notified of the preliminary decision by way of the Commission’s letter dated 2 August 2022 and was invited to make representations. Representations Made by the Organisation 30 On 23 August 2022, the Organisation made the following representations to the Commission seeking a reduction in the financial penalty: (a) The Organisation had voluntarily notified the Commission and affected individuals of the Incident even though it was not legally obliged to do so at the material time, as the Data Breach Notification Obligation under Part 6A of the PDPA only came into effect on 1 February 2022; (b) As of the date of the representations, the Organisation was not aware of any personal data of the affected individuals being misused as a consequence of the Incident. In support, the Organisation stated that the data in the Affected Database relates to data used on its previous application and website which is no longer in use. Moreover, the data was more than 18 months out of date, and was not linked to any current Lazada databases. Although the Organisation’s account passwords had been securely encrypted at the time of the Incident, it had conducted a forced logout and 18 password reset on every affected current Lazada account upon discovery of the Incident to ensure that no third party could misuse the leaked passwords by logging into a current Lazada account; and (c) The Incident was the Organisation’s first breach of the PDPA. To the best of the Organisation’s knowledge and belief, the Incident was its first experience of a data breach. Voluntary notification 31 The Commission had already taken into account the Organisation’s voluntary notification of the Incident into account in determining the quantum of the financial penalty in the preliminary decision. Hence, this factor does not warrant a further reduction in the financial penalty imposed. Lack of misuse of the affected personal data 32 The fact that the Organisation was not aware of any misuse of the affected personal data is neither here or there, and does not merit a further reduction in the financial penalty. Whilst evidence of exploitative use may be a relevant factor of harm that may be relevant for enhancing the financial penalty, the inverse is not necessarily true. 33 In support of its representations, the Organisation cited the case of Learnaholic Pte Ltd [2019] SGPDPC 31 (“Learnaholic”), in which the Commissioner had taken into account the fact that “while there was actual exfiltration of the Personal Data…there was no evidence of further exploitation, use or disclosure of the Personal Data by the attacker”.11 It suffices to 11 Learnaholic at [34]. 19 say that the Commission has explained Learnaholic in Farrer Park Hospital Pte Ltd [2022] SGPDPC 6 at [35 to 36] as follows: “35 In the case of Learnaholic the main factors taken into account when deciding to reduce the preliminary financial penalty imposed were: (a) A reduction in the total number of affected individuals due to a recalculation of figures; and (b) The benefit of doubt given to Learnaholic as to the period of time the vulnerability in its system existed. 36 The lack of evidence of further exploitation, use or disclosure is not, ipso facto, a factor meriting a reduction of the financial penalty. The Organisation’s representations are not accepted as the lack of an aggravating factor (i.e. subsequent exploitation, use or disclosure of personal data) is not in itself a mitigating factor.” 34 The explanation in Farrer Park Hospital that is cited above is equally applicable in the present case. Lack of antecedents 35 In calibrating the financial penalty in the preliminary decision, the Commission had already taken into account the fact that this was the Organisation’s first non-compliance with the PDPA, and no further reduction is merited. In support of its representations, the Organisation also cited Aviva Ltd and Toh-Shi Printing Singapore Pte Ltd [2016] SGPDPC 15 (“Aviva""), where the Commission had taken into account the fact that the breach of the Protection Obligation by the organisation was its second breach in approximately one year, and both data breach incidents involved similar fact patterns and causes. 12 In Aviva, the Commission had considered the organisation’s previous non-compliance as a contributory 12 Aviva at [38(c)]. 20 factor that justifies an increase in the financial penalty meted as the organisation had failed to improve its data protection practices. In contrast, the lack of antecedents in this instance means that the Commission did not increase the financial penalty imposed on the Organisation. To be clear, the absence of an antecedent does not, ipso facto, merit a reduction in the financial penalty imposed. Acceptance of the Commission’s findings 36 Notwithstanding the foregoing, the Commission notes that the Organisation voluntarily accepted the Commission’s findings in the preliminary decision, that it had failed to comply with the Protection Obligation and explicitly indicated that it would not seek to challenge these findings. The Organisation’s voluntary acceptance of liability (even at this late stage) ought to be reflected in the financial penalty. Had the Organisation accepted responsibility for the Incident at an earlier stage of the investigation, it could have significantly shortened the time for investigations and resolution of this case through the expedited breach procedure and also benefited from greater mitigatory considerations. Nonetheless, an organisation that voluntarily accepts responsibility for its non-compliance with the PDPA should be recognised as an organisation that demonstrates its commitment to the Accountability Obligation and shows that it can be responsible for the personal data in its possession or under its control.13 37 Having considered all the relevant factors in this case, the Commission hereby requires the Organisation to pay a financial penalty of $72,000 within 30 days from the date of the directions, 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. 13 Refer to section 11(2) of the PDPA. 21 38 In view of the remedial actions already been taken by the Organisation, no further directions need be issued to the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 22 ",Financial Penalty,1f2e2b94601c32c373eb88020422ba071c772e63,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,18,18,1,952,"A financial penalty of $58,000 was imposed on Farrer Park Hospital for failing to put in place reasonable security arrangements to protect the personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Healthcare""]",2022-11-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Farrer-Park-Hospital-Pte-Ltd_15092022.pdf,Protection,Breach of the Protection Obligation by Farrer Park Hospital,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-protection-obligation-by-farrer-park-hospital,2022-11-18,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 6 Case No. DP-2007-B6646 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Farrer Park Hospital Pte Ltd … Organisation DECISION Farrer Park Hospital Pte Ltd Farrer Park Hospital Pte Ltd Lew Chuen Hong, Commissioner — Case No. DP-2007-B6646 15 September 2022 Introduction 1 On 23 July 2020, the Personal Data Protection Commission (the “Commission”) received a data breach notification from Farrer Park Hospital Pte Ltd (the “Organisation”). The Organisation discovered that between 8 March 2018 and 25 October 2019, 9,271 emails had been automatically forwarded from two employees’ (the “Employees”) Microsoft Office 365 work email accounts (the “Email Accounts”) to a third-party’s email address (the “Third Party”), thereby disclosing the personal data of 3,539 unique individuals (the “Incident”). Background 2 The Organisation is a private tertiary healthcare institute that provides a range of healthcare services. The nature of the Organisation’s operations requires its employees to regularly handle highly sensitive personal data of past, present, and prospective patients. At the material time, the Employees were part of the Organisation’s marketing department which, inter alia, processes requests for the Organisation’s medical services via email. The email requests received by the Organisation’s marketing department contain personal data pertinent to the medical treatment(s) requested by individuals including: (a) Name; (b) Gender; 1 Farrer Park Hospital Pte Ltd (c) Nationality; (d) Date of Birth; (e) NRIC Number (full and partial); (f) Passport details (including Passport numbers); (g) Contact number; (h) Photograph; and (i) Medical information, including the following (the “Medical Information”): (i) Medical Condition(s) – namely, patient’s health condition(s), including doctor’s diagnosis, brief description of the health condition provided by the patient or an appointment with a specialist for a specific condition mentioned; (ii) Medical History – namely, more than one record of a patient’s health condition(s). (iii) Medical Results/Reports – namely, documents containing a medical procedure or analysis (for example, X-Rays). (collectively, the “Affected Data Types”) Security measures prior to discovery of the Incident 3 At the time of the Incident, the Organisation had implemented various IT and data protection policies regulating the collection, use, disclosure, and protection of personal data, including: 2 Farrer Park Hospital Pte Ltd (a) A ‘Data Protection Handbook’ to provide awareness and assistance to its employees in complying with the Personal Data Protection Act 2012 (the “PDPA”); (b) A ‘Personal Data Protection Policy for Patient Records’ to outline the Organisation’s protocol for managing patients’ medical records as well as the relevant retention period of medical records; (c) An ‘IT Security Management Standards’ policy detailing the establishment, implementation, and management of the Organisation’s information security program to ensure the prevention, detection, containment, and correction of security breaches; (d) An ‘Access Control Standards’ policy setting out the Organisation’s standards relating to user accounts and password security settings; and (e) An ‘Acceptable Use Policy’ stipulating the Organisation’s rules governing the acceptable use of its IT resources, including access to emails, websites, the internet, and other types of organisational information, and which mandated that user passwords be at least 8 characters long, and contain characters from at least 3 of the below 4 categories 4 (i) “English upper-case letters (e.g., A, B, C, …Z)”; (ii) “English lower-case letters (e.g., a, b, C, …Z)”; (iii) “Alphanumeric (e.g., 1, 2, 3, …9)”; and (iv) “Special characters) (e.g., ?, !, %, $, #)”. The Organisation had also implemented various IT security measures and vendor-based solutions including: 3 Farrer Park Hospital Pte Ltd (a) Staff training sessions on medical confidentiality, and periodic email updates on developments to the PDPA and guidelines issued by the Commission; (b) Regular phishing exercises on employees to continually inculcate awareness on the techniques that malicious actors might deploy to undermine the organisation’s IT security; (c) A cloud-based filtering service to protect the Organisation against spam, malware, and other email threats; (d) Signature-based and behaviour-based endpoint protections to protect endpoints from known and unknown malicious files; (e) User and entity behaviour analytics utilising deep learning algorithms to identify anomalies based on the Organisation’s usual network traffic; (f) Webpage whitelisting solutions to only allow users to access permitted sites and/or category of sites based on the Organisation’s defined policies; (g) Firewalls to prevent unauthorised access into FPH’s private network; and (h) A network intrusion prevention system to analyse network traffic to prevent known malicious activities from occurring within the Organisation’s network. 5 At the time of the Incident, the work email accounts of the Organisation’s employees were hosted on Microsoft Office 365 (“Office 365”), and the Organisation’s employees were able to access their work email accounts through the internet via a web-browser (i.e. web-mail). In June 2019, the Organisation implemented multi-factor 4 Farrer Park Hospital Pte Ltd authentication (“MFA”) for all of its employees’ work email accounts as part of its planned initiatives. The MFA implemented by the Organisation required its employees to key in a one-time password sent to their registered mobile number when accessing their work email accounts from a new device (the “OTP Process”). Upon successfully accessing their work email account on that device, employees had the option of choosing to “stay signed in” to their work email account on that authenticated device. Where this option was chosen, employees would not be required to undergo the OTP Process when subsequently accessing their work email accounts on that same authenticated device. 6 The Organisation represented that the above security solutions did not detect any anomalies and/or unusual activities in the Organisation’s email traffic before 24 October 2019. The Incident 7 On 24 October 2019, the Organisation’s IT helpdesk received a complaint that one of the Email Accounts was not able to send outgoing emails. In conducting checks to address this complaint, the Organisation’s IT helpdesk discovered that Office 365 had automatically imposed restrictions on the Email Accounts. This is a security feature of Microsoft’s Exchange Online Protection which indicated unauthorised access to the Email Accounts. Further investigations by the Organisation confirmed that the Email Accounts had been configured to automatically forward all incoming emails to the Third Party. This auto-forwarding of emails occurred between 8 March 2018 to 25 October 2019 for one of the Email Accounts, and between 1 April 2018 to 25 October 2019 for the other. 8 In total, 9,271 emails were forwarded from the Email Accounts to the Third Party. This resulted in the unintended disclosure of personal data belonging to 3,539 5 Farrer Park Hospital Pte Ltd unique individuals, of which 1,923 unique individuals also had their Medical Information disclosed. The Affected Data Types were disclosed in different permutations and not all affected individuals had all of the Affected Data Types disclosed through the various forwarded emails. 9 For completeness, the MFA and OTP Process had been not implemented at the time when the Incident first occurred on 8 March 2018. Remedial Measures 10 After discovering the Incident, the Organisation carried out the following remedial measures: (a) Disabled the auto-forwarding feature for end-users; (b) Increased the frequency of internal cybersecurity training and exercises; (c) Implemented additional technical email and network security measures; and (d) Refreshed and upgraded various of its existing network security measures. 11 The Organisation has advised that it will by 2022, upgrade, refresh and/or enhance its existing solutions for its: (a) Network security measures; and (b) Endpoint security measures. 6 Farrer Park Hospital Pte Ltd Findings and Basis for Determination 12 In view of the circumstances of the Incident, the Commission’s investigation focused on whether the Organisation had breached its obligation under section 24 of the PDPA 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”). 13 In deciding what constitutes reasonable security arrangements and/or controls, organisations should take into consideration the nature of the personal data in question, as well as the impact that disclosure of that personal data might have on affected person(s). This is a fact-specific assessment that organisations should undertake when developing and/or implementing its security arrangements, policies, and controls. As stated in the Commission’s Advisory on Key Concepts in the PDPA1: “There is no ‘one size fits all’ solution for organisations to comply with the Protection Obligation. Each organisation should consider adopting security arrangements that are reasonable and appropriate in the circumstances, for example, taking into consideration the nature of the personal data, the form in which the personal data has been collected (e.g. physical or electronic) and the possible impact to the individual concerned if an unauthorised person obtained, modified or disposed of the personal data. For example, in the employment context, it would be reasonable to expect a greater level of security for highly confidential employee appraisals as compared to more general information about the projects an employee has worked on. 1 See sections 17.2 – 17.3 of Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021) 7 Farrer Park Hospital Pte Ltd In practice, an organisation should: a) design and organise its security arrangements to fit the nature of the personal data held by the organisation and the possible harm that might result from a security breach; b) identify reliable and well-trained personnel responsible for ensuring information security; c) implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of sensitivity; and d) be prepared and able to respond to information security breaches promptly and effectively. In addition, it might be useful for organisations to undertake a risk assessment exercise to ascertain whether their information security arrangements are adequate. In so doing, the following factors may be considered: a) the size of the organisation and the amount and type of personal data it holds; b) who within the organisation has access to the personal data; and c) whether the personal data is or will be held or used by a third party on behalf of the organisation.” [emphasis added] 8 Farrer Park Hospital Pte Ltd 14 For the reasons set out below, it is determined that the Organisation failed to implement reasonable security arrangements to protect the personal data in the Email Accounts from the risk of unauthorised access and disclosure. Failure to put in place reasonable security arrangements to meet its needs 15 Where the personal data in question is sensitive and/or may cause damage to affected individuals if compromised, organisations should implement stronger access and security measures. The Commission has issued guidance on this issue in its Guide to Securing Personal Data in Electronic Medium2 (the “Guide”) In particular, paragraphs 7.3 and 7.4 of the Guide state that: “7. 3. The strength of authentication, such as password requirements or other mechanisms for access to personal data, should depend on the potential damage to the individual, such as potential damage to reputation or finances, if such personal data is compromised… 7.4 More secure authentication methods include two-factor or multi-factor authentication. These involve the use of a combination of information that the user knows, such as a password or PIN, and an object that only the user possesses, such as a digital key, token or smart card, or a unique physical trait, such as the use of fingerprints in biometric technology. The use of multi-factor authentication increases confidence in the identity of the user accessing the system.” [emphasis added] 2 Guide to Securing Personal Data in Electronic Medium (revised Jan 2017) 9 Farrer Park Hospital Pte Ltd 16 The Commission’s latest Guide to Data Protection Practices for ICT Systems3 also recommends two tiers of (i) basic and (ii) enhanced data protection practices for organisations to adopt in different circumstances. The guidance remains that larger quantities and more sensitive personal data call for enhanced data protection practices: “…For organisations that hold large quantities of different types of personal data or data that might be more sensitive to the individuals or organisations, they should additionally implement the relevant enhanced practices suggested.... The design and implementation of these protection measures should always take into consideration the extent of the sensitivity of the data based on the nature of business and types of services offered.”4 17 In the present case, the Organisation ought to have implemented stronger security arrangements, policies and/or controls to manage its marketing department’s Office 365 work email accounts, for the following reasons: (a) The Organisation’s marketing department routinely (on a daily basis) received and processed sensitive personal data, namely, the Medical Information of past, present and prospective patients. (b) The volume of sensitive personal data processed by the Organisation’s marketing department was not insignificant (1,923 individuals’ Medical Information processed over 18 months). 3 Guide to Data Protection Practices for ICT Systems (2021) 4 Guide to Data Protection Practices for ICT Systems (2021), page 8 10 Farrer Park Hospital Pte Ltd (c) The marketing department’s Office 365 work email accounts were accessible from the Internet (i.e. web-mail) which taken together with the above factors, exacerbated their vulnerability to unauthorised access. 18 Without prescribing the specific measures that would have been appropriate for the Organisation’s circumstances, stronger security arrangements, policies and/or controls could have included: (a) Implementing enhanced access controls for the marketing department’s web-mail access (e.g. MFA, IP address based white-listing); (b) Implementing policies and/or processes for the marketing department to collect Medical Information via a more secure platform (e.g. a separate webportal); (c) Implementing policies and/or processes for Medical Information to be regularly moved and purged from the marketing department’s Office 365 email accounts, and stored in a more secure system (e.g. a non-Internet facing medical records or customer relationship management system); and/or (d) Implementing policies and/or processes for Medical Information disclosed via the marketing department’s email accounts to be better protected (e.g. password protecting email attachments). 19 For the avoidance of doubt, it is accepted that web-mail may be an appropriate and cost-effective way for organisations to provide their employees with out-of-office email access, and that it may not be necessary for organisations to implement enhanced controls to regulate the use of all types of web-mail accounts. It is incumbent on organisations to assess whether enhanced controls should be implemented to 11 Farrer Park Hospital Pte Ltd regulate the use of web-mail accounts, considering factors such as the volume and sensitivity of the personal data processed using such accounts. 20 In the present case, while MFA was eventually implemented for the marketing department’s Office 365 work email accounts as an enhanced access control measure, this was unfortunately only after the Incident had occurred. Web-mail accounts are exposed to modes of attack that may defeat or circumvent 8-character alphanumeric password protection. Given that the marketing department was routinely processing personal data of a sensitive nature, it was incumbent on the Organisation to implement stronger security arrangements, policies and/or controls in conjunction with its adoption of web-mail. 21 In the premises, the Commission finds that the Organisation breached the Protection Obligation by failing to implement stronger security arrangements, policies and/or controls in respect of the Email Accounts. Risks arising from Email Auto-Forwarding 22 The automatic forwarding of emails to external domains (“Email Auto- Forwarding”) is a known security risk. In March 2018, it was reported that the Office of the Australian Information Commissioner was investigating a data breach incident notified by a member of the Maersk Group involving the auto-forwarding of 50,000 emails sent to 3 employees’ accounts to external parties5. More recently, in a Private Industry Notification dated 25 November 2020, the United States of America’s Federal Bureau of Investigations warned that cyber-criminals have been exploiting autoforwarding rules on web-based email clients to perpetuate business email compromise 5 https://www.zdnet.com/article/oaic-received-31-notifications-in-the-first-three-weeks-of-data-breach-scheme/ 12 Farrer Park Hospital Pte Ltd scams and recommended, amongst other mitigation measures, that Email AutoForwarding be prohibited by default6. 23 Locally, in Singapore Medical Association [2020] SGPDPCS 13, an unauthorised user gained access to an email account and created an email rule to forward emails to an external email address. 137 emails were forwarded without authorisation, resulting in the unauthorised disclosure of the personal data of 68 individuals. The danger of allowing Email Auto Forwarding is clear, but there is an easy fix – organisations can simply disable this function and ensure that it remains disabled. 24 In the present case, the Organisation conducted a ‘Business Impact Assessment’ in 2013 on the use of Office 365 to assess the risks involved from the use of corporate email and instant messaging. The Organisation also subsequently conducted regular reviews and assessments of security risks arising from the use of Office 365 within the Organisation. Unfortunately, these steps did not include an assessment of the risks arising from Office 365’s default setting which allowed Email Auto-Forwarding. 25 The Organisation, on its part, stated that it had not specifically examined disabling the default Email Auto-Forwarding feature in Office 365 because there had been no guidelines, standards, or benchmarks at the material time prior to the Incident recommending disabling of or management of risks from default Email AutoForwarding. Neither had it been a common industry practice to do so prior to the Incident. In this regard, it is noted that Microsoft only released specific guidance on 6 https://www.ic3.gov/Media/News/2020/201204.pdf 13 Farrer Park Hospital Pte Ltd restricting or controlling Email Auto-Forwarding in Office 365 around July / August 20207. 26 It is recognised that Email Auto-Forwarding may be a useful function that serves valuable needs in relation to some email accounts. The Protection Obligation requires organisations, as part of their periodic security review, to assess the frequency and manner of use of Email Auto-Forwarding, and to weigh and counter the attendant risks. In particular, it is incumbent on organisations to apply their minds and make their own assessments of the risks and implications of adopting the default settings of “out-ofthe-box” software solutions (see COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 at [14] and DS Human Resource Pte. Ltd. [2019] SGPDPC 16 at [9]). 27 On balance, and on the facts of this case, the Organisation is given the benefit of the doubt that the lack of guidelines, standards or benchmarks at the material time may have affected its assessment of the risks arising from the Office 365 default Email Auto-Forwarding rule. This omission will therefore not be factored in determining the enforcement action to be taken in this case. However, there must be no doubt that failure to make reasonable assessment of the risks from Email Auto-Forwarding within an organisation is breach of the Protection Obligation that would, in future cases, be met with the appropriate enforcement action. The Commissioner’s Preliminary Decision 28 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, 7 See https://www.vansurksum.com/2020/08/25/microsoft-is-making-changes-related-to-automatic-email- forwarding-for-atp-customers-here-is-what-you-need-to-know/ referencing Microsoft’s MC 218984 published July 2020 and MC220853 published August 2020. See also: https://docs.microsoft.com/en-us/microsoft365/security/office-365-security/external-email-forwarding?view=o365-worldwide 14 Farrer Park Hospital Pte Ltd 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 immediate remedial actions following the Incident; (b) The Organisation cooperated fully with the Commission during the investigations; (c) Prior to the Incident occurring, the Organisation had in place various technical security measures, including current market solutions; and (d) The Organisation had conducted various data protection and cybersecurity training for its employees. 29 The Organisation was notified of the preliminary decision by way of the Commission’s letter dated 20 April 2022 and was invited to make representations on the same. Representations Made by the Organisation 30 On 6 May 2022, the Organisation made the following representations to the Commission seeking a reduction in the amount of the financial penalty to be imposed: (a) The Organisation had voluntarily notified the Commission and affected individuals of the Incident even though it was not legally obliged to do so under the PDPA, at the material time; (b) There was no misuse of the affected personal data; 15 Farrer Park Hospital Pte Ltd (c) The Organisation took prompt remedial actions to contain and mitigate the effects of the Incident, and prevent recurrence; (d) The Incident was the Organisation’s first breach of the PDPA; and (e) The financial penalty which the Commissioner intended to impose was excessive in light of previous Commission decisions for similar or more serious breaches of the PDPA. Representations on voluntary notification and lack of antecedents 31 The Organisation represented that it voluntary notified the Commission of the Incident despite not being legally obliged to do so, as the obligation for organisations to notify the Commission of notifiable data breaches (as defined under s 26B of the PDPA) only came into effect on 1 February 2022. The Organisation’s voluntary notification of the Incident was taken into account when the Commission determined the preliminary financial penalty, and does not merit a further reduction of the same. 32 Likewise, the Organisation’s representations that it had not committed any breaches of the PDPA prior to the Incident are not accepted. The Organisation’s lack of antecedents had already been taken into account in calibrating the preliminary financial penalty. Representations on the lack of misuse of the affected personal data 33 The Organisation represented that its private forensic expert had monitored the Internet and dark web from 25 February 2020 to 24 April 2020 and not found any information or data (including personal data of the affected individuals) relating to the Incident disclosed during that period. The Organisation further stated that it had not received any complaints from any affected individual as of the date of the 16 Farrer Park Hospital Pte Ltd representations in relation to misuse of their personal data. The Organisation therefore represented that no individuals had been harmed or had suffered loss as a result of the Incident. 34 In support of its representations, the Organisation cited the case of Learnaholic Pte Ltd [2019] SGPDPC 31 (“Learnaholic”), in which the Commissioner had taken into account the fact that “while there was actual exfiltration of the Personal Data…there was no evidence of further exploitation, use or disclosure of the Personal Data by the attacker.”8 35 In the case of Learnaholic the main factors taken into account when deciding to reduce the preliminary financial penalty imposed were: (a) A reduction in the total number of affected individuals due to a recalculation of figures; and (b) The benefit of doubt given to Learnaholic as to the period of time the vulnerability in its system existed. 36 The lack of evidence of further exploitation, use or disclosure is not, ipso facto, a factor meriting a reduction of the financial penalty. The Organisation’s representations are not accepted as the lack of an aggravating factor (i.e. subsequent exploitation, use or disclosure of personal data) is not in itself a mitigating factor.9 8 Learnaholic at [34] 9 See Public Prosecutor v AOM [2011] SGHC 29 at [37] and Edwin s/o Suse Nathen v Public Prosecutor [2013] SGHC 194 at [24] for the equivalent positions in the criminal sentencing domain. 17 Farrer Park Hospital Pte Ltd Representations on the prompt remedial actions taken by the Organisation 37 The Organisation represented that the Commission had not taken into consideration the immediate nature of the remedial action taken to contain the Incident, as well as the success of the immediate post-Incident remediation and recovery efforts. The Organisation further stated that it had not suffered any breaches of the same nature since the Incident, which was proof of the effectiveness of its remedial actions. 38 The Organisation’s prompt remedial actions were already taken into account in determining the preliminary financial penalty. However, this is weighed against the lengthy time period during which the Email Auto-Forwarding took place (March 2018 – October 2019) and long delay in detecting the breach in the first place. Representations on previous Commission decisions 39 The Organisation cited two previous Commission decisions in support of its representations that the intended financial penalty was excessive for similar or more serious breaches of the PDPA. These two cases are The National Kidney Foundation [2021] SGPDPC 10 (“NKF”) and Singapore Medical Association [2020] SGPDPCS 13 (“SMA”). NKF 40 The breach in NKF concerned a hacker who had gained access to the work email account of one of NKF’s employees, thereby gaining access to 23,145 emails containing the personal data of approximately 500 individuals, including patients, employees, and third parties. The Organisation submitted that both cases were similar in the following areas: 18 Farrer Park Hospital Pte Ltd (a) Types of personal data involved (i.e. sensitive medical information); (b) Similar root causes and nature of the incidents; (c) Failure by the organisations to implement 2FA/MFA for web-mail access at the time of the incidents; 41 (d) Increased data protection awareness as remedial measures; and (e) Mitigating factors. The Organisation distinguished NKF and submitted that a lower financial penalty was justified in this case for the following reasons: (a) The Incident was less egregious than NKF because NKF involved: (i) an additional category of sensitive personal data (bank account information), apart from just medical information; and (ii) the hacker synchronising and downloading contents of the compromised email account; while no such synchronising or further use of the compromised email accounts was detected in the Incident; (b) The Organisation had carried out far more substantial and comprehensive remedial measures than NKF; and (c) The number of individuals affected by the Incident was not significantly higher than the number of individuals affected by the NKF incident. 42 The Organisation’s representations are not accepted for the following reasons: 19 Farrer Park Hospital Pte Ltd (a) In NKF only 8 patients’ medical information was compromised, as opposed to the disclosure of 1,923 individuals’ medical information due to the Incident. The breach in the Incident was therefore of a much larger magnitude. (b) The length of time that the breach went undetected was much longer in the Incident – the first email account was compromised in early 2018 and went undetected by the Organisation until October 2019, which was more than a year. This is much longer than the time it took for detection of the breach in NKF, where the hacker obtained access around 14 May 2020 and NKF discovered the breach on 17 May 2020. (c) The number of individuals affected by the Incident is more than 7 times higher (500 in NKF as opposed to 3,539 in the Incident). The two incidents thus cannot be considered in the same bracket of egregiousness. SMA 43 The breach in SMA concerned unauthorised access to an email account by brute force attack, and the subsequent forwarding of 137 emails containing the personal data of 68 individuals to an external email address. The Organisation submitted that both cases were similar in the following areas: 44 (a) Types of personal data involved; and (b) Similar root causes and nature of the incidents. The Organisation distinguished SMA and submitted that a lower financial penalty was justified because the Organisation had implemented more comprehensive security measures than SMA. In particular, the Organisation highlighted its own 20 Farrer Park Hospital Pte Ltd periodic changes of email account passwords and limit of the number of failed login attempts, in contrast with SMA which did not implement these measures. 45 The Organisation’s representations are not accepted as the volume and sensitivity of personal data affected in the Incident was much higher than in SMA: (a) The number of affected individuals in the Incident was 3,539; many times higher than the 68 affected individuals in SMA. (b) The following categories of sensitive information were disclosed in the Incident but not in SMA: passport details, photographs, contact numbers, and notably, specific medical information. As a hospital, the Organisation must be held to a higher standard with regard to safeguarding medical information. 46 Notwithstanding the foregoing, the Commission notes that the Organisation voluntarily accepted the Commission’s findings in the preliminary decision, that it had failed to comply with the Protection Obligation and explicitly indicated what it would not seek to challenge these findings. The Organisation’s voluntary acceptance of liability (even at this late stage) is accepted to have some mitigating weight, meriting a small reduction in the financial penalty. Had the Organisation accepted responsibility for the Incident at an earlier stage of the investigation, this may have merited a larger discount. An organisation that voluntarily accepts responsibility for its non-compliance with the PDPA is an organisation that demonstrates its commitment to the Accountability Obligation and shows that it can be responsible for the personal data in its possession or under its control.10 47 Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $58,000 within 30 days 10 S 11(2) of the PDPA 21 Farrer Park Hospital Pte Ltd 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. 48 No further directions are necessary on account of the remedial measures already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 22 ",Financial Penalty,0022595df88e4b744c91519d483b5cc7416a2511,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,19,19,1,952,QCP Capital was found not in breach of the PDPA in relation to an incident whereby threat actor(s) exfiltrated personal data via unauthorised access to an employee's account.,"[""Protection"", ""Not in Breach"", ""Finance and Insurance""]",2022-10-25,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---QCP-Capital-Pte-Ltd---16092022-(002).pdf,Protection,No Breach of the Protection Obligation by QCP Capital,https://www.pdpc.gov.sg/all-commissions-decisions/2022/10/no-breach-of-the-protection-obligation-by-qcp-capital,2022-10-25,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPCS 16 Case No. DP-2108-B8816 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And QCP Capital Pte Ltd SUMMARY OF THE DECISION 1. On 30 August 2021, QCP Capital Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a personal data breach that had occurred through an unauthorised access to employee accounts and exfiltration of customer personal data (the “Incident”). 2. As a result of the Incident, the personal data of 675 individuals was exfiltrated. The personal data affected includes name, NRIC number, date of birth, address, passport scan, passport number, photograph, email address, phone number, Telegram and WeChat ID, whitelisted address and trading records (which included the account balances, buy/sell/settlement activities). Page 1 of 3 3. The Organisation engaged an external cybersecurity company, Blackpanda Pte Ltd, to investigate the Incident. Its investigations found that the threat actor(s) had accessed two accounts, belonging to one employee, to gain unauthorised access to the Organisation systems and subsequently exfiltrated of personal data. 4. Investigations revealed that 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 also had an internal monitoring system in place which allowed the Organisation to detect, escalate the anomalous transaction, flag and suspend the trading account affected. 5. Following the Incident, the Organisation took prompt and extensive remedial action to mitigate the effects of the Incident and enhance the overall robustness of its security measures. This included notifying the affected individuals, layering access controls and introducing mandatory hardware key access authentication. 6. In view of the above, the Deputy Commissioner for Personal Data Protection is satisfied that the Organisation was in compliance with its Protection Obligation under section 24 of the PDPA and cannot be held liable for the unauthorised access by the threat actor(s) involved. No enforcement action therefore needs to be taken in relation to the Incident. Page 2 of 3 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,b38af202b30c4ef6f100bb2255281e89e63fdcc6,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,20,20,1,952,"A financial penalty of $26,000 was imposed on Cognita Asia Holdings for failing to put in place reasonable security arrangements to protect the personal data in its possession from a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Education"", ""Ransomware"", ""Schools""]",2022-10-25,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Cognita-Asia-Holdings-Pte-Ltd---09062022.pdf,Protection,Breach of the Protection Obligation by Cognita Asia Holdings,https://www.pdpc.gov.sg/all-commissions-decisions/2022/10/breach-of-the-protection-obligation-by-cognita-asia-holdings,2022-10-25,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPCS 14 Case No. DP-2106-B8484 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Cognita Asia Holdings Pte Ltd SUMMARY OF THE DECISION 1. On 16 June 2021, Cognita Asia Holdings Pte Ltd (the ""Organisation"") notified the Personal Data Protection Commission (the “Commission”) of a ransomware attack on 13 June 2021. The ransomware incident (the ""Incident"") affected the servers of three schools run by the Organisation. 2. The ransomware encrypted the personal data of 1,260 individuals, of which 1,195 are students. The personal data included copies of identification/passport page, salaries of the affected employees and the bank account details necessary for the crediting of salaries. Page 1 of 5 3. The Organisation’s internal investigations found that the threat actor gained initial entry to one of the school's network in April 2021 through a VPN session. The VPN logs showed no brute-force entry attempts, suggesting the use of compromised administrator account credentials. Investigations disclosed that between 8 and 12 June 2021, the threat actor gained broad network access and deployed the encrypting ransomware. 4. The Organisation requested that this matter proceed via the Expedited Decision Breach Procedure, which the Commission acceded to. To this end, the Organisation voluntarily and unequivocally admitted to the facts set out in this decision. It also admitted to a breach of section 24 of the Personal Data Protection Act (the ""PDPA""), also referred to as the Protection Obligation. 5. At the time of the Incident, even though the Organisation employed VPN, the Organisation’s existing configuration of VPN required merely a username and password for authentication. However, the personal data collected and processed by the Organisation included copies of the photographic identification documents of students as well as salary and bank account information of employees. In view of the nature of personal data that it holds, the Organisation needed a higher level of security and stronger access control for its administrator accounts, such as multifactor authentication for VPN connection to its administrator accounts to protect such personal data. Page 2 of 5 6. The Organisation also failed to have reasonable password policies or ensure compliance with their existing password policies. The Organisation did not enforce their password policies in the following areas: (i) Although the Organisation's password policy specified a minimum requirement of 10 characters, in practice the requirement that was enforced by their IT systems was only 8 characters; and (ii) Its password policy of requiring the default password to be changed after the first usage was not enforced. 7. The Commission's Handbook on ""How to Guard Against Common Types of Data Breaches"", which is complemented by the ""Checklists to Guard Against Common Type of Data Breaches"", has identified poor management of accounts and passwords as one of the five common causes and types of data breaches. Organisations must adopt, implement, and enforce a strong password policy as a necessary measure of data protection. 8. Finally, the Organisation also failed to ensure that personal data protection training was conducted for its staff. In this regard, the Commission wishes to reiterate that staff training in personal data protection is an important and necessary component of the Protection Obligation of an organisation. 9. In light of the above, the Organisation is found to have breached section 24 of the PDPA. Page 3 of 5 10. The Commission acknowledged that, the Organisation informed the relevant stakeholders of the Incident and implemented real time threat monitoring and Deep and Dark Web monitoring for potentially exposed personal data. 11. The Organisation also undertook remedial actions to mitigate the effects of the Incident and improve the robustness of its security measures. This included the engagement of a cybersecurity expert to investigate the cause of the Incident and working together with the said expert to enact a Remediation Plan. 12. The Remediation Plan included measures such as, enforcing multi-factor authentication of all staff accounts, enhancing the password requirements for administrator accounts, and increasing the frequency of security reviews and cyber security trainings for its staff. 13. The Organisation also conducted security awareness webinars and offered a 12 months’ personal identity monitoring services to all the staff and parents (who can sign up on behalf of the affected students) of these three schools. 14. The Commission’s decision to require payment of a financial penalty, and on the quantum of the penalty, took into account sections 48J(1) and 48J(6) of the PDPA, and all the relevant circumstances of the case. This included the Organisation's admission of breach of the Protection Obligation, which the Commission considers Page 4 of 5 is a significant mitigating factor. Having considered all the facts of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of S$26,000. 15. The Organisation must make payment of the financial penalty 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. 16. In view of the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. The following are the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation must 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 or disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. Page 5 of 5 ",Financial Penalty,2bb79bfdd23b06a8855ff98de1a352eac57e3ebd,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,21,21,1,952,"A financial penalty of $60,000 was imposed on MyRepublic for failing to put in place reasonable security arrangements to protect the personal data in its possession.","[""Protection"", ""Financial Penalty"", ""Information and Communications""]",2022-09-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---MyRepublic-Ltd---05082022.pdf,Protection,Breach of the Protection Obligation by MyRepublic,https://www.pdpc.gov.sg/all-commissions-decisions/2022/09/breach-of-the-protection-obligation-by-myrepublic,2022-09-15,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 5 Case No. DP-2108-B8814 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And MyRepublic Limited … Organisation DECISION Page 1 of 11 MyRepublic Limited Lew Chuen Hong, Commissioner — Case No. DP-2108-B8814 5 August 2022 Introduction 1 On 29 August 2021, the Personal Data Protection Commission (“the Commission”) received information that MyRepublic Limited (“the Organisation”) had been the subject of a cyber incident. On 1 September 2021, the Organisation informed the Commission that a threat actor had exfiltrated and deleted customers’ personal data from its IT systems (the “Incident”). 2 The Organisation requested for the investigation to be handled under the Commission’s Expedited Breach Decision procedure. In this regard, the Organisation voluntarily provided and admitted to the facts set out below, and admitted that it had failed to implement reasonable security arrangements to protect the personal data accessed and exfiltrated in the Incident in breach of section 24 of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 3 The Organisation is incorporated in Singapore, and is a telecommunications operator that holds a Facilities-Based Operations licence (“FBO Licence”) under Section 5 of the Telecommunications Act 1999. 4 At the time of the Incident, the Organisation accepted customer orders for mobile services through its Mobile Order Portal (“Portal”). The Organisation’s customers who applied for mobile services would submit their customer identity verification and number portability documents (the “KYC documents”) through the Portal, and the Portal would store the KYC documents in a bucket (the “Bucket”) on cloud-storage procured from Amazon Web Services (“AWS”). Page 2 of 11 5 While the Bucket was publicly accessible, its access was restricted through the use of an access key (the “Access Key”) in the Amazon Identity and Access Management feature. The Access Key could only be used to access the Bucket and no other AWS accounts, systems or bucket used by the Organisation. The Access Key was stored in the source code of the Portal to facilitate the transfer of the KYC documents submitted through the Portal, to the Bucket. 6 On 29 August 2021 (SGT), the Organisation became aware that an external actor had accessed and exfiltrated the KYC documents submitted by customers applying for mobile services. The Organisation received an email from the external actor threatening to publish the downloaded customer data unless a ransom was paid. 7 Following the Incident, the Organisation engaged an IT forensic investigator (among others) to assist in its incident response. Investigations revealed that the external actor had utilised the Access Key to access the Bucket. Fortunately, the compromised Access Key could not be used by the external actor to access the Organisation’s other AWS accounts, systems or buckets. However, an unusually large volume of data had been downloaded from the Bucket before it was deleted. 8 While the Organisation was unable to determine with certainty how the external actor had obtained the Access Key, the Organisation determined that the external actor had likely obtained the Access Key through two vulnerabilities identified within the Portal, namely: (a) The disclosure of the Access Key in the Portal’s functionality which displayed technical information; and (b) The disclosure of the Access Key in the Portal’s source code repository which was available to all the Organisation’s developers, one of whom may have inadvertently disclosed the Access Key. Page 3 of 11 9 The personal data of 79,388 of the Organisation’s customers was accessed and exfiltrated in the Incident, comprising the following: (a) For 75,026 Singapore citizens and permanent residents: Scanned copies of both sides of NRIC and work pass cards, which included the customer’s full name, address, date of birth, gender, race, place of birth, full NRIC number, photograph, thumbprint, date of issuance of card, (for Employment Passes only) employer and nationality, and (for Dependant’s Passes only) nationality; (b) For 4,362 foreigners: Scanned copies of residential address documents such as utility bill, tenancy agreement or insurance policy, which included the customer’s name, address and other information; and (c) For 3,631 customers porting an existing mobile service: porting form which included the customer’s full name and mobile phone number. (collectively, the “Customer Data”). Remedial actions 10 Following the Incident, as part of remedial actions, the Organisation: (a) Revoked the Access Key and issued a replacement key for the Bucket; (b) Removed environment configuration files from the Organisation’s Portal that exposed the Access Key; (c) Reviewed activities across all accounts and buckets to ensure that the compromise was isolated to a single bucket; (d) Restricted access to buckets to specific IP addresses through a block- all-with exception policy; Page 4 of 11 (e) Enabled version control on buckets that were not previously controlled/managed; (f) Reviewed to ensure all buckets are private and in line with AWS’ best practices; (g) Reviewed to ensure all access keys are rotated; (h) Consolidated all AWS accounts with central monitoring enabled; (i) Cleaned up DNS registry across the Organisation’s IT landscape; (j) Issued a notification to the affected customers, recommending actions to minimise the risks of identify fraud and social engineering, and offering the affected customers six months of complimentary credit monitoring services; (k) Conducted dark web monitoring from 3 September 2021 to 3 October 2021 to verify whether the exfiltrated data have been published; and (l) Commissioned the development of a programme of security improvements for the Organisation’s systems in order to reduce the risk of security incidents. Findings and Basis for Determination Whether the Organisation had contravened the Protection Obligation 11 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, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). The Organisation is required under the Protection Obligation to implement reasonable security arrangements to prevent the risk of unauthorised disclosure of the Customer Data, notwithstanding that the data was hosted on a Page 5 of 11 vendor’s cloud service. This is because the Organisation retains control over such data. In Commeasure Pte Ltd [2021] SGPDPC 11 (“Commeasure”) at [11], the Commission found that even though a vendor was responsible for the security of the cloud infrastructure that it provided to the organisation, the organisation bore ultimate responsibility under the Protection Obligation for making reasonable security arrangements to protect all the customers’ data under its control. 12 The reasonableness of the Organisation’s security arrangements to protect the Customer Data would be assessed having regard to the volume and sensitivity of such personal data. As stated in the Commission’s Advisory Guidelines on Key Concepts in the Personal Data Protection Act (revised 1 October 2021) (“Advisory Guidelines”) at [17.3], an organisation should design and organise its security arrangements to fit the nature of the personal data held by the organisation and the possible harm that might result from a security breach, and implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of sensitivity. 13 In the course of its business, the Organisation collected and retained copies of its customers’ KYC documents such as NRICs and work passes, which contained their Customer Data, in compliance with its FBO Licence.1 At the time of the Incident, the Organisation had in its control a high volume of sensitive personal data: (a) High volume of Customer Data: At the time of the Incident, the Organisation had in its control the Customer Data of almost 80,000 individuals. (b) Sensitivity of Customer Data: The Customer Data included the customers’ full NRIC numbers, photographs, thumbprints, and dates of issuance of their NRIC cards. The sensitivity of such information is heightened 1 Under its FBO Licence, the Organisation is required to (i) maintain a register containing records of its customers, including the customers’ identity number such as NRIC number, (ii) make and keep a photocopy of its customers’ NRIC, passport or employment pass as evidence of the customers’ identity, and (iii) keep the register of the customers for at least 12 months from the date of termination of its services to the customers (among others). Page 6 of 11 and there is an increased risk, for example, of identity theft, as the information could enable access to other services provided by the Government. 14 Accordingly, the Organisation should have implemented stronger security measures to protect the Customer Data. 15 For the reasons set out below, the Organisation failed to put in place such reasonable security arrangements to protect the Customer Data and was determined to be in breach of the Protection Obligation (as also admitted by the Organisation). In particular, the Organisation failed to implement sufficiently robust processes to manage the Access Key, and also failed to implement reasonable security controls for its AWS environment. Failure to implement sufficiently robust processes to manage Access Key 16 The Organisation’s Protection Obligation required it to protect the Access Key, which allowed access to the Customer Data in the Bucket. As stated in Commeasure at [12], AWS has, in its “Reference Guide – AWS security credentials” (“AWS Reference Guide”), advised users to protect the access keys as “anyone who has the access keys for your AWS account root user has unrestricted access to all resources in your AWS account”.2 17 However, the Organisation failed to implement sufficiently robust processes to protect the Access Key. 18 The Organisation informed the Commission that the Access Key could be disclosed through the Portal’s functionality to display technical information, at https://mobile.myrepublic.com.sg/php-info. The functionality, known as “PHP Info”, is a standard function of the PHP programming environment and helps programmers to understand the configuration of the environment. The “PHP Info” function is invoked https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html – see “Best practices for managing AWS access keys” (last accessed on 5 August 2022). Page 7 of 11 2 by executing a PHP script file. Thereafter, if the php-info URL is accessed, the browser will display the Portal’s operating system environment variable values. These values included the Access Key, which was used by the Portal to access and transfer documents submitted by customers through the Portal to the Bucket. This was a significant vulnerability as anyone who knew or could guess the php-info URL could obtain the Access Key and use it to access the Customer Data in the Bucket. The Organisation also determined that this was the most likely way in which the external actor had obtained the Access Key. The Organisation should not have left the Access Key publicly accessible through the php-info URL. Instead, the Organisation could have disabled the “PHP Info” function or moved the Access Key from the Portal’s system environment variables to configuration files available only to authorised parties. 19 Further, the Organisation informed the Commission that the Access Key was embedded in the Portal’s source code available to all the Organisation’s developers via the source code repository. This was another way through which the external actor could have obtained the Access Key or one of the developers with access could have inadvertently disclosed it. The Commission has held in Commeasure at [12] that embedding AWS access keys into the source code of applications poses a clear security risk. In the AWS Reference Guide, AWS has likewise cautioned users not to “embed access keys directly into code”. The Organisation could have stored the Access Key in a file that is separate from the source code and secured with separate access controls, or it could have utilised third party solutions for the management of access keys. 20 In addition, the Access Key was captured in the clear in mobile order application log files made available to employees, including external developers and engineers, who did not require such information for their functions. If the Organisation wanted to store credentials such as the Access Key in its log files (e.g. for development purposes), it should have implemented reasonable security measures such as a log file redaction mechanism to prevent disclosure of such credentials. Page 8 of 11 21 In view of the above, the Organisation was found in breach of the Protection Obligation for its failure to implement sufficiently robust processes to manage the Access Key. Failure to implement reasonable security controls for AWS environment 22 Apart from the Organisation’s failures in its management of the Access Key, the Organisation also failed to implement reasonable security controls for its AWS environment. 23 The Commission had stated in the Guide to Data Protection by Design for ICT Systems (2021) (“Guide”) that as a basic practice, organisations should “[e]nsure that files containing personal data are not accidentally made available on a website or through a web application”, and “avoid storing personal data in public folders” (at page 20). In the “Amazon Simple Storage Service – User Guide”, AWS has similarly advised its users that “[u]nless [they] explicitly require anyone on the internet to be able to read or write to [their] S3 bucket, [they] should ensure that [their] S3 bucket is not public”.3 24 However, as stated at [5] above, the Bucket was publicly accessible. This significantly increased the risk profile of the Bucket as external actors could find the Bucket and thereafter access, exfiltrate and delete the Customer Data in the Bucket, which is what occurred in the Incident. Given the high volume and sensitivity of the Customer Data stored in the Bucket, the Bucket should not have been made publicly available. This is especially if the Bucket was meant to interact only with the Portal for customers to upload KYC documents for retrieval by the Organisation’s back-office systems. 25 The Commission had stated in the Guide that organisations should put in place ICT controls to manage data protection risks, including setting appropriate access https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html – see “Amazon S3 Preventative Security Best Practices” (last accessed on 5 August 2022). Page 9 of 11 3 control rules, access rights, and restrictions for specific user roles (at pages 9 and 15). Access to the Bucket should therefore have been restricted to only authorised applications or users. In this case, the Organisation sought to restrict access to the Bucket through the use of the Access Key, but it turned out to be ineffective because of the Organisation's handling and inadvertent disclosure of the Access Key, as stated above. The Organisation could also have considered layering its defences, and could have supplemented the Access Key with a “block-all but” exception policy that allows only specific IP addresses to access the Bucket, as implemented by the Organisation after the Incident. 26 Accordingly, the Organisation was found to be in breach of the Protection Obligation for failing to implement reasonable security controls for its AWS environment. The Commissioner’s Directions 27 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty, the matters set out at section 48J(1) and 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 and effective remedial actions, including notifying the affected individuals; and (b) 28 The Organisation was cooperative during investigations. The Commission also considered the Organisation’s voluntary acceptance of liability for the Incident. Page 10 of 11 29 Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $60,000 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. 30 No further directions are necessary on account of the remedial measures already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION Page 11 of 11 ",Financial Penalty,281b38e59a842f8bbcce33f312e6d5fdca027752,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,22,22,1,952,"Directions were issued to Budgetcars to put in place appropriate contractual provisions, conduct a security audit of its technical and administrative arrangements for the security and maintenance of its website and rectify any security gaps identified in the audit report. This is pursuant to a data breach incident where personal data could be accessed by changing a few digits of the tracking ID.","[""Protection"", ""Directions"", ""Transport and Storage""]",2022-08-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Budgetcars-Pte-Ltd---06072022.pdf,Protection,Breach of the Protection Obligation by Budgetcars,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-budgetcars,2022-08-11,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPCS 13 Case No. DP-2108-B8798 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Budgetcars Pte. Ltd. SUMMARY OF THE DECISION 1. On 25 August 2021, the Personal Data Protection Commission (the “Commission”) received a complaint that the delivery tracking function (the “Tracking Function Page”) on the website of Budgetcars Pte Ltd (the “Organisation”) could be used to gain access to the personal data belonging to another individual. By changing a few digits of a Tracking ID, the complainant could access the personal data of another individual (the “Incident”). 2. The Organisation is a logistics company delivering parcels to customers (“Customers”) on behalf of retailers (“Retailers”). 3. The personal data of 44,357 individuals had been at risk of unauthorised access. The datasets comprised name, address, contact number and photographs of their signatures. 4. The Tracking Function Page was set up in December 2020 to allow Retailers and Customers to (i) keep track of the delivery status of their parcels; and (ii) confirm the identity of individuals to collect parcels on their behalf (where applicable). The Tracking IDs were generated by Retailers and comprised either sequential or nonsequential numbers. Although generated by Retailers, the Organisation adopted the Tracking IDs for use on its own Tracking Function Page that allowed their customers to track their deliveries, which would disclose personal data listed above. The Protection Obligation therefore required the Organisation to ensure that there were reasonable access controls in its use of the Tracking IDs for giving access to an individual’s personal data. 5. The risk of unauthorised access to personal data from altering numerical references, both sequential and non-sequential, have featured in the published decisions of the Commission in Re Fu Kwee Kitchen Catering Services [2016] SGPDPC 14, and more recently, in Re Ninja Logistics Pte. Ltd. [2019] SGPDPC 39. Insecure direct object reference has long been a well-known security risk to personal data. The Organisation failed to have reasonable access control to the affected individuals’ personal data when it simply adopted Tracking IDs generated by the Retailers without factoring in this risk. 6. The Organisation also admitted that it did not have in place a process to protect personal data through proper safeguards by archiving personal data relating to a completed delivery order after a reasonable period of time has lapsed. To reduce the risk of access to personal data through frontend applications, they should be removed and archived within a reasonable time. The Organisation’s failure to do so resulted in more personal data at risk in the Incident than should have been the case. 7. In the circumstances, the Organisation is found to be in breach of section 24 of the PDPA. 8. Upon being notified by the Commission of the Incident, the Organisation took the following remedial measures after the Incident: a. Removed all personal data from the Tracking Function Page; b. Engaged its IT solutions provider to re-examine management of the Tracking Function Page; c. Post-delivery expiry of Tracking ID after 14 days; and d. Implemented checks to prevent sequential Tracking IDs from being uploaded onto the Tracking Function Page. 9. The Commission accepted the Organisation’s request for this matter to be handled under the Commission’s expedited breach decision procedure. This meant that the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. The Organisation also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 10. In Re Ninja Logistics Pte. Ltd. cited above, the organisation had been aware of the risk from manipulation of Tracking IDs. However, a counter-measure which the organisation initially introduced was abandoned due to operational issues and was not replaced. This resulted in a significantly larger dataset (>1.2 million) that was exposed to the risk of unauthorised access over a period of close to 2 years. In comparison, the number of affected individuals in the present case was lower as the Organisation was only handling deliveries for a few Retailers at the time of the Incident. 11. Having considered the circumstances set out above and the factors listed in section 48J(6) of the PDPA, including (i) the Organisation’s upfront voluntary admission of liability; and (ii) the prompt remedial action undertaken by the Organisation, the Commission considered that it would be appropriate not to require the payment of a financial penalty but to direct the Organisation to do the following: a. To put in place the appropriate contractual provisions to set out the obligations and responsibilities of both the data controller and data intermediary to protect the Organisation’s personal data, and the parties’ respective roles in protecting the personal data; b. To engage qualified security service provider to conduct a thorough security audit of its technical and administrative arrangements for the security and maintenance of its website that contains personal data in the Organisation’s possession or control; c. Provide the full security audit report to the Commission, no later than 60 days from the date of the issue of this direction; d. Rectify any security gaps identified in the security audit report, review and update its personal data protection policies as applicable within 60 days from the date the security audit report is provided; and e. Inform the Commission within 1 week of completion of rectification and implementation in response to the security audit report. 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. ",Directions,f58b11a86b70faf2534d0dbe08ee7f22ddbeaeb9,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,23,23,1,952,Directions were issued to Crawfort to conduct a security audit of its technical and administrative arrangements for its AWS S3 environment and rectify any security gaps identified in the audit report. This is pursuant to a data breach incident where Crawfort's customer database were offered for sale in the dark web.,"[""Protection"", ""Directions"", ""Finance and Insurance""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Crawfort-Pte-Ltd---070622.pdf,Protection,Breach of the Protection Obligation by Crawfort,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-crawfort,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2106-B8446 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Crawfort Pte. Ltd. SUMMARY OF THE DECISION 1. On 9 June 2021, Crawfort Pte. Ltd. (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of the sale of the Organisation’s customer data on the dark web (the “Incident”). 2. The personal data of 5,421 customers were affected. The datasets affected comprised NRIC images (front and back), PDF copies of loan contract (containing all the information in the NRIC, age, email address, contact number and loan amount) and PDF copies of income document (payslip, CPF statements or IRAS Notice of Assessment). 1 3. The Organisation engaged external cyber security teams to investigate the Incident. The investigation identified an opened S3 server port in the Organisation’s AWS environment as the cause of the Incident. 4. The Organisation explained that it had opened the S3 server port for one week during a data migration exercise sometime on or about 15 April 2020 for business continuity purposes. On 3 April 2020, the Singapore government had announced that the country will enter into a Circuit Breaker to contain the spread of COVID-19. All non-essential workplaces, including the Organisation, had to be closed from 7 April 2020. In order to continue its business, the Organisation had to pivot its operations so as to allow its staff to work from home and its customers to make loan applications remotely. Within a very short period, the Organisation had to carry out the data migration exercise and as a result, overlooked conducting a risk assessment prior to conducting the data migration exercise. 5. The opened S3 server port connected directly to the S3 server hosting the S3 buckets, which contained the affected personal data. The open remote port enabled attempts to connect to the Organisation’s AWS environment from the internet. Furthermore, the S3 bucket containing the affected personal data was publicly accessible due to a misconfiguration of the S3 bucket. As a result, the threat actor was able to gain access to the publicly accessible S3 bucket during the one-week period. 2 6. The Organisation the following remedial measures after the Incident: a. Reset and reconfigured all whitelisted IPs to AWS server; b. Reset and reconfigured all VPNs; c. Limited the whitelisted IP addresses to its web portal; d. Conducted a penetration test; e. Monitored the dark web to ensure that data was not circulated; f. Engaged independent cyber security consultant to carry out investigation, study the IT infrastructure and propose improvements to their systems; and g. Notified affected individuals. 7. The Commission accepted the Organisation’s request for this matter to be handled under the Commission’s expedited breach decision procedure. This meant that the Organisation had voluntarily provided and unequivocally admitted to the facts set out in this decision. The Organisation also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 8. The Organisation admitted that it failed to conduct a reasonable risk assessment before carrying out the data migration exercise. There was no access control to the S3 bucket containing the affected personal data during the week-long migration exercise. This, coupled with the open port, allowed the threat actor to gain access to the affected personal data. 3 9. In the circumstances, the Organisation is found to be in breach of section 24 of the PDPA. 10. Having considered the circumstances set out above and the factors listed in section 48J(6) of the PDPA, including (i) the Organisation’s upfront voluntary admission of liability which significantly reduced the time and resources required for investigations; and (ii) the prompt remedial actions undertaken by the Organisation, the Commission considered that it would be most appropriate in lieu of imposing a financial penalty, to direct the Organisation to comply with the following: a. To engage qualified security service provider to conduct a thorough security audit of its technical and administrative arrangements for the security and maintenance of its AWS S3 environment that contains personal data in the Organisation’s possession or control; b. Provide the full security audit report to the Commission, no later than 60 days from the date of the issue of this direction; c. Rectify any security gaps identified in the security audit report, review and update its personal data protection policies as applicable within 60 days from the date the security audit report is provided; and d. Inform the Commission within 1 week of completion of rectification and implementation in response to the security audit report. 4 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. 5 ",Directions,e2755a8249f833e1c234b8532991f2dc6896ee30,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,24,24,1,952,"A financial penalty of $10,000 was imposed on Audio House for failing to put in place reasonable security arrangements to protect the personal data in its possession from a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Ransomware""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Audio-House-Marketing-Pte-Ltd---27052022.pdf,Protection,Breach of the Protection Obligation by Audio House,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-audio-house,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2106-B8421 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Audio House Marketing Pte Ltd SUMMARY OF THE DECISION 1. On 1 June 2021, Audio House Marketing Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware affecting its customer database (the “Incident”). Approximately 98,000 individuals’ names, addresses, email addresses and telephone numbers, in the nature of contact information, were affected. 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. This means that the Organisation voluntarily provided and unequivocally admitted to the facts set out in 1 this decision; and admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 3. The Organisation’s internal investigations revealed that PHP files used to develop a web application on the Organisation’s website contained vulnerabilities that allowed the threat actor to carry out a SQL injection attack. The Organisation admitted that it is possible that the vulnerabilities in the PHP files had existed since April 2017, when its website was first launched. Further, even though the Organisation had conducted pre-launch tests prior to the launch of its website, the Organisation admitted that it failed to identify and detect the existing vulnerabilities in the PHP files. 4. SQL injection attacks are well-known vulnerabilities: see “Top Ten” list of the Open Web Application Security Project (OWASP). The Commission has consistently advised organisations to take the necessary precautions to guard against the risk of injection attacks (see para. 15.3 of the Commission’s Guide to Securing Personal Data in Electronic Medium, published on 8 May 2015, and revised on 20 January 2017). We note that apart from conducting functionality testing of features such as the shopping cart and payment on its website, the Organisation did not conduct any vulnerability scanning and assessment that would have provided a reasonable opportunity to discover the vulnerabilities in the PHP files that were eventually exploited in the Incident. 5. Compounding the above, the Organisation also did not conduct reasonable periodic security review. A reasonable periodic security review would include 2 vulnerability scanning and assessments, which would have offered the Organisation the opportunity to detect any vulnerabilities that were not detected during the pre-launch tests, or any vulnerabilities that may have arisen since. 6. Periodic security reviews is also a practice that the Commission has consistently advised organisations to adopt. In our Checklists to Guard against Common Types of Data Breaches, the Commission highlighted that conducting a periodic security review is a basic practice that all organisations ought to embrace. This is also reiterated in para. 6.1(a) of the Commission’s Guide to Securing Personal Data in Electronic Medium where we stated that it was a good practice for organisations to “conduct regular ICT security audits, scans and tests to detect vulnerabilities and non-compliance with organizational standards”, and Table 13(f) of the same Guide where we encouraged organisations to perform web application scanning and source code analysis to help detect common web vulnerabilities, in particular, those identified in the “Top Ten” list of the OWASP, which includes SQL injection attacks. 7. With the use of IT comes the responsibility for data security in IT systems. We urge organisations who may be unable to conduct such security reviews on their own to engage the necessary expertise from the professionals. 8. Having said that, we note that the Organisation’s website was built by a company, which the Organisation’s main IT vendor had engaged on the Organisation’s behalf. The Organisation did not have any contract with the company that developed the website. As a result, the Organisation failed to stipulate clear job 3 specifications or any data protection requirements on the company that developed its website. There was also an absence of any data protection requirements in the Organisation’s contract with its main IT vendor, who it relied upon to manage and maintain its IT systems. The Commission’s published decisions1 have emphasized that organisations engaging IT vendors should – a) stipulate personal data protection requirements on the vendors, b) make clear the job specifications, especially where they include security maintenance and software updates, and, last but not least, c) exercise reasonable oversight over the vendor responsible for the technical capabilities of the organisation so as to offer adequate protection to the types of personal data that may be affected by the engagement of the vendor. In cases where sub-contracting is contemplated, the Organisation should have identified requirements in its main contract that it requires its main IT vendor to impose similar obligations on and exercise adequate oversight over its subcontractor. 9. In light of the above, the Organisation is found to have breached the Protection Obligation under section 24(a) of the PDPA. 10. In deciding the appropriate outcome in this case, the Commission considered the Organisation’s cooperation throughout the investigation, the Organisation’s voluntary admission of breach of the Protection Obligation, and the prompt remediation actions taken. This included disabling the use of its website on the same day of the Incident, reformatting of its webserver, adding security against SQL injections and the implementation of vulnerable assessment and penetration 1 See Jigyasa [2020] SGPDPC 9 and Civil Service Club [2020] SGPDPC 15 4 testing. We note that the Organisation managed to restore all the personal data affected without loss, thereby minimizing any disruptions to its operations. 11. Having considered the circumstances set out above and the factors listed at section 48J(6) of the PDPA, the Deputy Commissioner for Personal Data Protection hereby finds the Organisation in breach and directs the Organisation to pay a financial penalty of S$10,000 within 30 days from the notice accompanying date of this decision, failing which interest at the rate specified in the Rules of Court in respect of judgement debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 12. In view of the remedial actions taken by the Organisation, no directions under section 48I are necessary. 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) unauthorized 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. 5 ",Financial Penalty,2506fbb092f33a10a99d72428ada09a55ade6c6b,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,25,25,1,952,"A financial penalty of $12,000 was imposed on Terra Systems for failing to put in place reasonable security arrangements to protect the personal data of individuals in its customer relationship management portal in Re Terra Systems Pte Ltd [2021] SGPDPC 7. An application for reconsideration was filed against the decision in Re Terra Systems Pte Ltd [2021] SGPCPC 7. Upon review and careful consideration of the application, the Commissioner had decided to affirm the finding of the breach of section 24 of the PDPA as set out in the decision and the financial penalty in the Reconsideration Decision.","[""Protection"", ""Financial Penalty"", ""Information and Communications""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Terra-Systems-Pte-Ltd----06082021.pdf,Protection,Breach of the Protection Obligation by Terra Systems,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-terra-systems,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 7 Case No DP-2007-B6670 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Terra Systems Pte. Ltd. … Organisation DECISION Terra Systems Pte. Ltd. [2021] SGPDPC 7 Lew Chuen Hong, Commissioner — Case No. DP-2007-B6670 6 August 2021 Introduction 1 On 14 July 2020 and 21 July 2020, a customer relationship management portal (“the Portal”) owned and operated by Terra Systems Pte Ltd (the “Organisation”) containing the personal data of persons served with “Stay-Home Notices” 1 (“SHNs”) was accessed and modified without the Organisation’s authorisation (the “Incident”). 2 On 27 July 2020, the Singapore Police Force notified the Personal Data Protection Commission (“Commission”) of the Incident, and the Commission commenced its own investigations thereafter. Background 3 The Organisation is in the business of providing communication solutions and services, including call centre services, to businesses in Singapore and the region. On 17 June 2020, the Organisation was awarded a government contract to provide call centre services to help verify the whereabouts of persons serving SHNs (“the Call Centre”). 4 To facilitate the operations of the Call Centre, the Immigration and Checkpoints Authority (“ICA”) provided the Organisation with a daily spreadsheet containing the personal data of persons serving SHNs, including their: (a) Name (b) Last 4 digits of NRIC; 1 Legal notices issued under the Infectious Diseases Act (Cap 137) requiring a person to remain at their place of residence or at a Stay-Home Notice Dedicated Facility at all times for a stipulated period 1 (c) Gender; (d) Contact Number; (e) Last Day of SHN; (f) Address where SHN was served; and (g) COVID-19 Test Appointment dates (collectively, the “SHN Data”) 5 The Organisation created the Portal for the purposes of its internal administration of the Call Centre. On account of the movement restrictions in force at the time owing to the COVID19 pandemic, the Portal was designed to be accessible by the Organisation’s staff from home via the Internet. 6 Users in the Organisation were granted different levels of access to the Portal: (a) Directors and managers were assigned unique user IDs and passwords and were able to view all cases in the Portal. (b) Team leaders were also assigned unique user IDs and passwords and were able to view all cases assigned to agents in their teams. (c) Agents (i.e. the persons actually contacting the persons serving SHNs) were temporary staff assigned simple user IDs based on their respective teams (e.g. the user ID “D03” referred to agent number 3 in team D). Agents were also given a common daily password which was shared with them during a morning Zoom briefing by the Organisation’s management. 7 Agents logged in to the Portal were only able to view the cases assigned to them, and type in remarks in a specific “remarks” column after a case had been attended to. At the end of each day, the SHN Data would be submitted to ICA with the agents’ remarks, and all data in the Portal would be purged. 8 On 14 July 2020, crude remarks were found to have been inserted in the remarks field of 3 cases in the Portal. The two agents assigned to deal with those cases and their team leader 2 denied inserting the remarks. The Organisation changed the common password for the day and began informing agents of the new daily common password via Whatsapp instead. The Organisation also implemented a web server logging function to track the actions of users logged in to the Portal. This functionality had not enabled previously. 9 On 21 July 2020, another crude remark was inserted in the remarks field of a case assigned to one of the same agents. The Organisation traced the action to an unauthorized user based on the IP address from which the Portal was accessed and reported the Incident to the police. 10 The perpetrator of the Incident is believed to be a disgruntled ex-employee of the Organisation. On 14 July 2020, the perpetrator is believed to have obtained the daily common password by attending the morning Zoom briefing, after obtaining the login details for the morning Zoom briefing from other employees. On 21 July 2020, the perpetrator is believed to have directly obtained the daily common password from another employee who was unaware that his employment had been terminated. 11 After being notified of the Incident, the Organisation took the following remedial actions on ICA’s instructions: (a) The practice of using common passwords was ceased, and agents were required to adopt unique passwords, (b) Agents were assigned unique user IDs which were different from the generic IDs based on their teams; (c) Two-factor authentication was implemented for all access to the Portal; and (d) Security scanning was performed on the Portal. Findings and Basis for Determination 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 taking reasonable security steps or arrangements to prevent 3 unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (“Protection Obligation”). 13 For the reasons set out below, the Organisation is found to have failed to implement reasonable security arrangements to protect the SHN Data from the risk of unauthorised access. Failure to implement reasonable IT access controls 14 Firstly, the Organisation failed to implement reasonable IT access controls to the SHN Data in the Portal. The use of (i) generic user IDs for agents which were known to all or guessable, and (ii) a daily common password for all agents, were poor practices that posed serious security risks. 15 Employing simple user IDs and a common password defeated the purpose of segregating agents’ access to cases in the Portal. Any agent could have accessed another agent’s cases by using that agent’s commonly known or guessable user ID and the common password. While there is only evidence that the perpetrator in this case accessed and modified the SHN Data of 4 persons (based on the distinct cases in the Portal in which crude remarks were inserted), the perpetrator could have accessed the SHN Data of all 125 persons assigned to his former team. 16 The Incident could have been prevented had all agents been assigned unique user IDs and passwords. Failure to implement policies to mitigate risks from using common password 17 Secondly, the Organisation failed to implement adequate policies to mitigate the risks created by the use of a daily common password to access the Portal. Having made the decision to use a common password for access to the Portal, the Organisation attempted to identify the associated risks and adopt suitable policies and practices. Unfortunately, their efforts proved to be inadequate 18 The Organisation clearly recognised some risks associated with use of a common password – this was why they adopted the practice of changing the common password daily. However, it was foreseeable that agents would ask each other for the daily common password, 4 for example, when they had forgotten the password or had missed the morning Zoom briefing. An agent may not have suspected that anything was amiss if someone they believed to be another agent had asked them for the daily password or the login details for the morning Zoom briefing. This risk was exacerbated by the fact that all of the agents were temporary staff and that personnel changes were to be expected. Thus, on both 14 July 2020 and 21 July 2020, the perpetrator is believed to have obtained either the login details for the morning Zoom briefing or the common daily password itself from the Organisation’s employees. 19 If the Organisation had properly appreciated this risk, it could have implemented policies (i) prohibiting agents from disseminating or sharing the daily common password under any circumstances, and (ii) requiring any agents who missed the daily morning Zoom briefings to obtain the daily common passwords directly from their team leaders or managers, who would be better placed to verify the requestor’s employment status. Admittedly, such policies would have been difficult to police. However, they would have at least reduced the risk of disclosure of the common password to unauthorised persons. 20 It is acknowledged that the Organisation was under pressure to operationalise the Call Centre and Portal within a short timeframe to support ICA’s operations in the midst of the COVID-19 pandemic. Even so, its failures to implement reasonable access controls gave rise to the present Incident. The Organisation failed to make reasonable security arrangements to protect the SHN Data from unauthorised access and modification in breach of its obligation under section 24 of the PDPA. The Commissioner’s Decision 21 In determining whether any directions should be imposed on the Organisation under section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA were considered, with particular emphasis on the following aggravating and mitigating factors: Aggravating Factor (a) The SHN Data was sensitive in nature considering the climate of the COVID- 19 pandemic and unauthorised disclosure could have caused the individuals to experience discrimination or social stigma; 5 Mitigating Factors 22 (b) The Organisation had to operationalise the Portal under urgent circumstances; (c) The Organisation took prompt remedial actions following the Incident; and (d) The Organisation was cooperative during the investigations. Having considered the above factors and circumstances, the Commissioner preliminarily determined that a financial penalty of $12,000 would be imposed in respect of the Organisation’s negligent contravention of the Protection Obligation. On 22 April 2021, the Organisation was notified of the Commissioner’s preliminary decision, including the full findings set out above, and given 14 days to make written representations. The Organisation’s representations 23 On 7 May 2021, the Organisation submitted written representations requesting that it be issued a warning in lieu of a financial penalty. While the Organisation did not dispute that it had breached the Protection Obligation, it claimed that the circumstances of its case were similar or less egregious to recent enforcement decisions of the Commission in which warnings had been given to organisations for breaches of the Protection Obligation2. 24 According to the Organisation, unlike in the precedent cases cited: (a) Only 4 individuals’ personal data was affected in the Incident (i.e. a very low number); (b) The personal data affected (i.e. the SHN Data) was not sensitive; (c) There was no exfiltration or public exposure of the SHN Data; (d) Prompt remedial measures were implemented within 48 hours with no loss of personal data; and 2 Chan Brothers Travel Pte Ltd (DP-1905-B3936, Summary of the Decision); Horizon Fast Ferry Pte Ltd (DP1912-B5464, Summary of the Decision); MRI Diagnostics Pte Ltd (DP-1811-B2975, Summary of the Decision); Water+Plants Lab Pte Ltd (DP-2004-B6182, Summary of the Decision); R.I.S.E Aerospace Pte Ltd (DP-2007-B6832, Summary of the Decision); Everlast Projects Pte Ltd [2020] SGPDPC 20; Chapel of Christ the Redeemer (DP-2010-B7132, Summary of the Decision); St Joseph’s Institution International Ltd (DP-2010B7196, Summary of the Decision); and ACCA Singapore Pte Ltd (DP-2011-B7385, Summary of the Decision). 6 (e) Reports were voluntarily made to the authorities (including ICA and the police) and the Organisation was not held to ransom or complained about by any members of the public. 25 The Organisation also claimed that unauthorised disclosure of the SHN Data would not have caused the affected individuals to experience discrimination or social stigma. The Organisation claimed that it was normal for anyone entering Singapore at the time to be subject to an SHN, and that many persons had even publicised this fact. With reference to the precedent cases cited, the Organisation claimed that the disclosure of (i) students’ grades, (ii) church members’ marital statuses, and (iii) employees’ salaries, carried a greater risk of the affected persons experiencing discrimination or social stigma in the relevant circumstances. 26 After careful consideration, the Organisation’s representations were rejected. 27 While there may have been facts in specific domains of the precedent cases which appeared either similar or more egregious than the Incident, this did not mean that the Organisation was deserving of a warning. Every case is decided based on an evaluation of all the relevant facts and circumstances, and in a manner that is fair and appropriate for the particular organisation investigated. 28 There are two main distinguishing factors which justifies the imposition of a financial penalty in the Organisation’s case compared to the precedent cases cited: (a) First, contrary to the Organisation’s representations, the SHN Data is considered to have been sensitive at the material time, during the early days of the COVID-19 pandemic when there was uncertainty about its virulence and high levels of public health concerns. The Organisation was engaged to help administer the SHN regime as part of a national effort to manage the pandemic. While the SHN Data did not include positive diagnoses for COVID-19, the fact of being subject to an SHN nevertheless denoted risk of exposure to the virus. The fact that the Incident occurred in July 2020 just after the end of “circuit breaker” measures and when public concern was high, was important context. (b) Second, within the same context of a national health emergency, the Organisation’s level of culpability was much higher than that of the organisations in 7 the cited precedents. The Organisation employed very poor access control measures which were easily circumvented by an unsophisticated actor. A common password was used by over 50 users and shared over an unsecure platform, with no audit trail. While the Organisation’s representations focused solely on the alleged harm caused by the Incident and the remedial steps taken afterwards, the extent of the Organisation’s negligence in the Incident was also an important factor which justified the imposition of a financial penalty in its case. 29 For completeness, the Organisation’s representations also failed to account that the personal data of 125 individuals was exposed to the risk of unauthorised access in the Incident, notwithstanding that only 4 records had been modified. In any event, the fact that the Incident only affected a limited number of persons has been taken into account in calibrating the quantum of the financial penalty imposed. Other factors raised by the Organisation such as the prompt implementation of remedial measures and voluntary reporting have similarly been accounted for. 30 Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $12,000 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. 31 In view of the remedial actions that have already been taken by the Organisation, no other directions are necessary. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ",Financial Penalty,72732e0dda0822fd38160244a8fdf6eca77d9bca,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,26,26,1,952,"A financial penalty of $67,000 was imposed on Quoine for failing to put in place reasonable security arrangements to protect the personal data in its possession.","[""Protection"", ""Financial Penalty"", ""Finance and Insurance""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Quoine-Pte-Ltd---08022022.pdf,Protection,Breach of the Protection Obligation by Quoine,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-quoine,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 2 Case No. DP-2011-B7409 / DP-2011-B7421 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Quoine Pte Ltd … Organisation DECISION Quoine Pte Ltd [2022] SGPDPC 2 Lew Chuen Hong, Commissioner — Case Nos. DP-2011-B7409 / DP-2011-B7421 8 February 2022 Introduction 1 On 17 November 2020, Quoine Pte Ltd (“the Organisation”) informed the Personal Data Protection Commission (“the Commission”) that its domain manager had transferred control of its domain hosting account to an external actor, who accessed and exfiltrated the personal data of 652,564 of its customers (“the Incident”). The Commission subsequently received a complaint from an individual believed to have been affected in the Incident. 2 The Organisation requested for the investigation to be handled under the Commission’s Expedited Breach Decision procedure. In this regard, the Organisation voluntarily provided and admitted to the facts set out below, and admitted that it had failed to implement reasonable security arrangements to protect the personal data accessed and exfiltrated in the Incident in breach of Section 24 of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 3 The Organisation is a company incorporated and based in Singapore, and a subsidiary of Liquid Group Inc., which is incorporated in Japan. The Organisation operates a global cryptocurrency exchange under the “Liquid” brand, and has customers around the world. 4 At the time of the Incident, the Organisation’s back-end IT infrastructure included the following: (a) Its vendor-procured cloud computing platform (“Cloud Platform”) which it used to run its cryptocurrency exchange platform, and which hosted its cloud computing database; and (b) Its additional cloud computing storage procured from another vendor, which it used to store documents such as Know-Your-Client (“KYC”) documents. 5 The Organisation also engaged a third party domain name registrar (“the Domain Provider”) to register and host the Organisation’s domain (@quoine.com domain). A domain name registrar allows a party to purchase and register domain names, where the domain name translates to a public address of the party’s servers (e.g. webserver, email server) for routing purposes. 6 On 13 November 2020, a staff member of the Organisation received an email from the Domain Provider stating that changes had been made to the settings of the Organisation’s domain hosting account with the Domain Provider (@quoine.com domain) (“Domain Hosting Account”). Staff members also received password reset emails for accounts on the Organisation’s other file-sharing and office productivity services. As the Organisation had not requested for the changes, the Organisation followed up with the Domain Provider, who acknowledged that the Organisation’s email accounts on its domain with the Domain Provider were no longer routed to the Organisation. 7 Investigations revealed that: (a) As a result of social engineering attacks on employees of the Domain Provider, an employee of the Domain Provider incorrectly transferred control of the Organisation’s Domain Hosting Account to an external actor. This allowed the external actor to change the registered email address on the Organisation’s Domain Hosting Account and subsequently effect a password reset on the account to take control of the Domain Hosting Account. (b) Control of the Domain Hosting Account allowed the external actor to know the number of servers using the domain name, and the IP addresses of these servers. (c) With control of the Domain Hosting Account, the external actor changed the servers to which the Organisation’s email traffic was directed (i.e. via changes to the Organisation’s mail exchanger (MX) records), from the email servers used by the Organisation to the external actor’s email servers. This redirected all of the Organisation’s emails to the external actor’s email servers. According to the Organisation, this impacted the Organisation’s security monitoring capability as many alerts and notifications, which were distributed via email, were consequently redirected to the external actor’s email servers. The Organisation’s staff members continued to receive emails notifying of changes to the settings of the Domain Hosting Account (referred to at [6] above) on alternative recovery options that had been set up. (d) Having redirected the Organisation’s emails on the Organisation’s domain (@quoine.com domain) to itself, the external actor then initiated password resets for several of the services tied to the Domain Hosting Account. The external actor successfully carried out a password reset on an account (“DevOps Account”) used by the Organisation for automation tasks and to run codes throughout the day which was not used interactively by humans. (e) The external actor then used the DevOps Account’s newly reset credentials to access the Organisation’s Cloud Platform, which hosted API keys/token to the Organisation’s database hosted within the Cloud Platform as well as a separate cloud computing storage database (collectively, the “Databases”). The external actor thereby gained credentials to the Databases, and accessed and exfiltrated personal data stored in the Databases. 8 The personal data of 652,564 of the Organisation’s customers was accessed and exfiltrated in the Incident, comprising the following: (a) First name and surname; (b) Address; (c) Email address; (d) Telephone number (optional); (e) Photo-image of documents provided by 362,035 customers for KYC purposes before 13 October 2018, namely, NRIC number, passport number or other identification documents, proof of address document, and photograph; (f) Financial information of Japanese customers of Quoine Corporation, a Japanese company related to the Organisation; (g) Transaction information: fiat deposits and crypto withdrawals, and a 2018 record of balances prior to the launch of the current “Liquid Exchange”; and (h) For customers depositing and withdrawing fiat currencies: Bank account and other information, namely, name of the bank, account number and name of the account holder. (collectively, the “Customer Data”). Remedial actions 9 Following the Incident, as part of remedial actions, the Organisation: (a) Notified its customers to alert them of the Incident, advised them of actions to take to secure their accounts, and recommended precautionary measures to monitor any suspicious activities which may have suggested improper use of their personal information; (b) Moved its domains to a more robust service provider that offered Enterprise level support, strong access control (username, password and mandatory two-factor authentication (“2FA”)) and roles-based access controls; (c) Migrated the entire Liquid exchange to a different vendor-provided cloud computing platform, with additional improvements made in the interactions between the Organisation’s service accounts and the system; and (d) Strengthened the use of the DevOps Account, and imposed IP whitelist restrictions where appropriate. 10 The Organisation is also evaluating other services to further harden its infrastructure, including cloud security configuration tools. Findings and Basis for Determination Whether the Organisation had contravened the Protection Obligation 11 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, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). 12 As a preliminary point, while the Organisation had engaged the Domain Provider to host the Organisation’s domain, the Domain Provider did not process any personal data on behalf of the Organisation and was not the Organisation’s data intermediary. Due consideration is given to the fact that the initial breach occurred with the Domain Provider. The basis of the Commission’s decision is that the Protection Obligation in respect of the Customer Data was borne solely by the Organisation and there were failures in respect of how it secured access to its Cloud Platform, leading to the unauthorised disclosure of Customer Data. 13 The Commission has repeatedly highlighted that an organisation should design and organise its security arrangements to fit the nature of the personal data held by the organisation and the possible harm that might result from a security breach, and implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of sensitivity (see the Commission’s Advisory Guidelines on Key Concepts in the Personal Data Protection Act (revised 1 October 2021) (“Advisory Guidelines”) at [17.3]; see also Credit Counselling Singapore [2017] SGPDPC 18 at [25] and PeopleSearch Pte. Ltd. [2019] SGPDPC 47 at [10]). As stated in the Commission’s Advisory Guidelines at [17.5], measures that an organisation can use to protect personal data include adopting appropriate access controls (e.g. considering stronger authentication measures where appropriate) and installing appropriate computer security software and using suitable computer security settings. 14 Considering the Organisation’s business as a global cryptocurrency exchange that regularly deals with a large volume of sensitive personal data of a financial nature, the Organisation’s overall data protection and cybersecurity posture should have been very much heightened. The Organisation was in possession of 822,096 individuals’ Customer Data, including photo-image of documents and other information provided by 362,035 customers for KYC purposes, cryptocurrency transactions and bank account information. Consequently, the Organisation is required under the Protection Obligation to have implemented strong security arrangements to protect the Customer Data held in its Databases. 15 In the present case, the Organisation has admitted that it failed to implement reasonable security arrangements to protect the Customer Data, and that it was in breach of the Protection Obligation. In particular, the Organisation (i) failed to review and assess the DevOps Account’s security implications and risks, and (ii) failed to implement reasonable ICT controls for the DevOps Account. Failure to review and assess the DevOps Account’s security implications and risks 16 The Commission has highlighted in previous decisions the importance of carrying out correctly-scoped periodic security reviews, so as to detect vulnerabilities and assess security implications and risks, and to ensure that reasonable security arrangements have been put in place to protect personal data in an organisation’s database. 17 In WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 (“WTS”), the Commission highlighted the importance of conducting regular reviews to ensure that websites collecting personal data and electronic databases storing personal data have “reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks”, as personal data of individuals may be exposed if a website or database in which it is stored contains vulnerabilities (at [18] of WTS). 18 Likewise, in Commeasure Pte Ltd [2021] SGPDPC 11 (“Commeasure”), the organisation had neglected to include the affected application package and access key (which the threat actor had used to access and exfiltrate personal data in the organisation’s cloud database) in its inventory of IT assets in production, which had resulted in their omission from its periodic security reviews. The organisation was found in breach of the Protection Obligation on this basis, as the vulnerability could otherwise have been discovered and the incident could have been prevented (at [16][17] of Commeasure). While the organisation explained that its failure to implement sufficiently robust processes to manage its inventory of infrastructure access keys was attributable to the high turnover of its employees from the time of its inception to the discovery of the incident, this was unacceptable because the organisation’s responsibility to protect personal data in its control or possession ought not to have been subjected to staff movement or appointment (at [13] of Commeasure). 19 As held in Chan Brothers Travel Pte Ltd [2020] SGPDPCS 11 (“Chan Brothers”), organisations must be aware of security implications of software features of their IT systems, so as to configure the security settings to enable effective protection of personal data stored in the IT systems (at [5] of Chan Brothers). 20 During the investigations, the Organisation admitted that its periodic reviews of access “failed to acknowledge this weakness as they incorrectly focussed on accounts used interactively by humans only, and not the automation bot accounts”. According to the Organisation, until the Incident, it was not aware of the vulnerability and weakness in access control to the DevOps Account, which did not have 2FA enabled. Accordingly, similar to the facts of Commeasure as set out above, although the Organisation had conducted periodic security reviews, these security reviews were improperly scoped, and failed to identify this vulnerability present in the DevOps Account. 21 The Organisation also admitted that the DevOps Account “was created without sufficient due diligence being given to the entire security risk profile of this type of account”, and “[t]his is a vulnerability that had not been adequately assessed by implementing alternative security measures to address the lack of 2FA”. 22 The Organisation had therefore failed to review and assess the security implications and risks arising from the DevOps Account and its lack of 2FA. The Organisation’s failures in this regard were especially egregious, given that the DevOps Account had privileged access to the Organisation’s Cloud Platform containing API keys/tokens to the Databases, and consequently, the Customer Data stored in the Databases. If the Organisation had included the DevOps Account in its security review and detected the vulnerabilities in the lack of 2FA, and/or had assessed and appreciated the security implications and risks arising from the DevOps Account and its lack of 2FA, it could have taken reasonable security measures to mitigate these security risks and to configure the security settings to enable effective protection of the Customer Data in the Databases. 23 The Organisation informed the Commission during the investigations that its current staff were not aware of the reasons for the DevOps Account’s set-up and security arrangements, as the DevOps Account had been created “at some time in the past (so legacy)”. The Organisation explained that there had been internal personnel movement. For instance, its DevOps team had initially been based in and managed out of Tokyo, then Quoine Vietnam. However, by mid-2020, the DevOps Tokyo team was no longer with the Organisation, and the DevOps team that remained was in Quoine Vietnam. While we are sympathetic to the challenges presented as a result of any personnel movements, it was incumbent on the Organisation to implement the necessary systems and processes to ensure that critical information about its IT systems, including legacy systems, survived the turnover of its staff. As the Commission has also held in Commeasure and stated above, an organisation’s responsibility to protect personal data in its control or possession ought not to have been subjected to staff movement or appointment. 24 The Organisation suggested that the DevOps Account’s security risk profile had not been assessed, probably due to its intended use as an automation account. This was not accepted. The Organisation is not exempted from assessing the security implications and risks of the DevOps Account simply on the basis that it was an automation account, especially considering that the DevOps Account could be used to access the Customer Data stored in the Databases. 25 In view of the above, the Organisation was found to be in breach of the Protection Obligation for its failure to review and assess the DevOps Account’s security implications and risks. Failure to implement reasonable ICT controls for DevOps Account 26 As stated in the Commission’s Guide to Data Protection by Design for ICT Systems (2021), organisations should put in place ICT controls to manage data protection risks (at page 9). Examples of ICT controls include setting appropriate access control rules, access rights and restrictions for specific user roles, and strengthening database security (at pages 15 and 18). 27 The Organisation informed the Commission that 2FA had not been implemented for the DevOps Account, which had privileged access to the Cloud Platform containing API keys/tokens to the Databases, and consequently, the Customer Data stored in the Databases. This meant that the DevOps Account is an account with privileged access. Many of the Organisation’s other systems and services had implemented 2FA for accounts with privileged access, and these were not breached in the Incident as the external actor could not carry out a password reset on these systems and services. In the present case, the external actor had been able to access the Cloud Platform and the API keys/tokens to the Databases stored therein, after carrying out password reset on the DevOps Account. 28 The Organisation could have guarded against this risk by strengthening ICT controls for the DevOps Account. The Organisation could have limited access to the password change functions of its DevOps Account. The Organisation could have introduced an additional restriction on the password change function, by requiring 2FA whenever there is a request to change passwords for the DevOps Account. The Organisation had implemented this additional restriction for many of its systems and services, which were not breached in the Incident as the external actor could not carry out a password reset where 2FA was required. The Organisation could likewise have implemented a 2FA requirement for effecting password resets for the DevOps Account. This was an existing policy and practice that the Organisation had for other accounts with privileged access, and it ought to also have been extended to the DevOps Account which also had privileged access. 29 Accordingly, the Organisation was found to be in breach of the Protection Obligation for failing to implement reasonable ICT controls for the DevOps Account. The Commissioner’s Directions 30 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty, the matters set out at section 48J(1) and 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, including notifying the affected individuals; and (b) 31 The Organisation was cooperative during investigations. The Commission also considered the Organisation’s voluntary acceptance of liability for the Incident. 32 Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $67,000 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. 33 No further directions are necessary on account of the remedial measures already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION ",Financial Penalty,050d292466354174c1fddecc90ae2ad45a68f635,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,28,28,1,952,Aman was found not in breach of the PDPA in relation to an incident involving unauthorised access to its servers and exfiltration of personal data. Aman had employed reasonable security arrangement and technical measures to protect its data.,"[""Protection"", ""Not in Breach"", ""Accommodation and F&B""]",2022-06-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Aman-Group-Sarl-and-or-Amanresort-International-Pte-Ltd--28022022.pdf,Protection,No Breach of the Protection Obligation by Aman Group S.a.r.l and Amanresort International,https://www.pdpc.gov.sg/all-commissions-decisions/2022/06/no-breach-of-the-protection-obligation-by-aman-group,2022-06-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2012-B7506 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Aman Group S.a.r.l and/or Amanresort International Pte Ltd SUMMARY OF THE DECISION 1. On 5 December 2020, the Personal Data Protection Commission (the “Commission”) received a notification from SingCERT of a personal data breach involving Aman Group S.a.r.l (“Aman Group”) and/or Amanresort International Pte Ltd (“Aman SG”). 9 systems in London and 2 systems in Singapore were compromised and files containing personal data exfiltrated (the “Incident”). Page 1 of 4 2. As a result of the Incident, personal data of approximately 2,500 individuals which included their name, date of birth, address, email address, phone number and profession were affected. 3. The Aman Group engaged an external cybersecurity company, Ankura Consulting, to investigate the Incident. Its investigations found that the threat actor(s) had gained unauthorised access into 11 systems, which included 9 servers based in London and 2 servers based in Singapore. 4. While the investigations did not uncover any evidence of what the initial method and point of entry were, the most likely scenario is that the threat actor had initially entered via the London based systems. This is because the suspicious activities were first detected in the London systems. Thereafter, the threat actor subsequently gained access to the 2 Singapore based servers by creating administrator account credentials. There was no evidence that the firewalls in the Singapore based servers were breached. 5. Investigations could not conclusively exclude the possibility that data may have been exfiltrated from one of the Singapore based servers. However, analysis conducted by the Aman Group on four extracts obtained from the threat actor(s) failed to establish any conclusive links between the extracts and the current database in the affected Singapore based server. 6. Investigations further revealed that any exfiltrated data would have been encrypted and was in a proprietary format. Aman Group’s assessment was that Page 2 of 4 the encryption and the proprietary format made it unlikely that the threat actor(s) would be able access and recreate the data in plaintext. Their assessment is that even if there had been exfiltration, there was no evidence that the exfiltrated data was in fact compromised. This is because the extracts obtained from the threat actor(s) do not resemble the current database in the affected Singapore based server. 7. Following the Incident, the Aman Group took prompt and extensive remedial actions to mitigate the effects of the Incident and enhance the robustness of its security measures. 8. Further, based on the facts as disclosed, Aman SG is a regional office. It did not hold the data protection role and was not in possession or control of the personal data in the 2 Singapore based servers. As such, Aman SG could not be held accountable for the Incident and cannot be said to be in breach of the Protection obligation under section 24 of the PDPA. 9. In view of the above, the Deputy Commissioner for Personal Data Protection is satisfied of the view that the Aman Group had met its Protection obligation under section 24 of the Personal Data Protection Act (“PDPA”) and that no enforcement action needs to be taken in relation to the Incident. Page 3 of 4 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 4 of 4 ",Not in Breach,5e015c5637baabcfc9d1ffcaae0eb7490cbabe57,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,30,30,1,952,"A financial penalty of $22,000 was imposed on Vhive for failing to put in place reasonable security arrangements to protect the personal data in its possession from a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Ransomware""]",2022-06-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Vhive-Pte-Ltd---08032022.pdf,Protection,Breach of the Protection Obligation by Vhive,https://www.pdpc.gov.sg/all-commissions-decisions/2022/06/breach-of-the-protection-obligation-by-vhive,2022-06-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2013-B8138 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Vhive Pte Ltd SUMMARY OF THE DECISION 1. On 26 March 2021, Vhive Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware attack that affected its customer database (the “Incident”). Approximately 186,281 individuals’ names, addresses, email addresses, telephone numbers, hashed passwords and customer IDs were affected. 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. This means that the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision, and admitted that it was in breach of section 24(a) of the Personal Data Protection Act (the “PDPA”). 3. The Organisation’s forensic investigation results revealed that the Organisation’s IT infrastructure had been outdated, with multiple vulnerabilities at the time of the Incident. The Organisation’s e-commerce server ran on an outdated webserver service. This, together with an unpatched firewall, allowed the threat actor to 1 remotely execute unauthorised code on the e-commerce server, and gained backdoor access to the e-commerce server to carry out the ransomware attack. 4. The Organisation had engaged an IT vendor to host, manage and maintain the e-commerce server and all its other IT systems. However, our investigations revealed that despite the purported “engagement”, there was in fact no written contract between the Organisation and its IT vendor at the time of the Incident. 5. In Re Spize Concepts Pte Ltd [2019] SGPDPC 22 at [22], we had stated that section 4(2) of the PDPA imposes on organisations that engage data intermediaries to do so “pursuant to a contract which is evidenced or made in writing”. In that case, we also highlighted that one specific category of policies and practices under section 12(a) of the PDPA that an organisation should develop and implement is the contractual documentation relating to the scope of the data intermediary relationship, and failure to do so would amount to a breach. The raison d’etre is that the outsourcing of data processing activities must be clearly scoped, and the respective roles and responsibilities between the organization and the data intermediary clearly identified from the outset. In the absence of any written contract and the lack of evidence to show the scope, roles and responsibilities of the data processing outsourcing, the Organisation remained solely responsible for complying with the obligations under the PDPA, including the obligation to make reasonable security arrangements to protect the personal data in its possession or under its control under section 24 of the PDPA. 6. The Organisation’s outdated webserver was used to host the Organisation’s website and its online storefront. In this regard, the Commission had previously 2 issued a Guide on Building Websites for SMEs in 2016, which was subsequently updated and revised in July 2018. In this Guide, the Commission emphasized the importance of ensuring the protection of personal data and the security of the website throughout the life cycle, including ensuring the clear delineation of responsibilities when an organization engages an IT vendor. 7. We wish to reiterate our observations in [4.2.1] of the Guide, where we highlighted the need to consider and properly document an IT vendor’s scope of work, and stated as follows: Organisations should emphasise the need for personal data protection to their IT vendors, by making it part of their contractual terms. The contract should also state clearly the responsibilities of the IT vendor with respect to the PDPA. When discussing the scope of outsourced work, organisations should consider whether the IT vendor’s scope of work will include any of the following: • Requiring that IT vendors consider how the personal data should be handled as part of the design and layout of the website. • Planning and developing the website in a way that ensures that it does not contain any web application vulnerabilities that could expose the personal data of individuals collected, stored or accessed via the website through the Internet. • Requiring that IT vendors who provide hosting for the website should ensure that the servers and networks are securely configured and adequately protected against unauthorised access. • Requiring IT vendors to ensure that all work done is fully documented and that all documentation is handed over to the organisation at the completion of the project. Documents should capture the website’s requirements, design specifications, user test scripts, user test results, as well as server and network configurations. • When engaging IT vendors to provide maintenance and/or administrative support for the website, requiring that any changes they make to the website do not contain vulnerabilities that could expose the personal data. Additionally, discussing whether they have technical and/or non-technical processes in place to prevent the personal data from being exposed accidentally or otherwise. 3 • 8. Requiring that IT vendors providing maintenance and/or administrative support to ensure that all changes to the website are secure and documented, and that the document is kept up to date. The Organisation admitted the weakness in its IT infrastructure and its failure to give due attention to the protection of the personal data of its customers had contributed to the Incident. 9. On the facts, the Organisation’s failure to ensure that there was a written contract with its IT vendor not only meant that there was a lack of clarity on the scope of work expected from the IT vendor, but also that the Organisation had failed to stipulate clear written security maintenance requirements and data protection requirements to its IT vendor to ensure the protection of personal data it was in control or in possession of. This ultimately resulted in a lack of system maintenance, including security maintenance by the Organisation. 10. Investigations further revealed that the Organisation did not have a security maintenance policy, which would have made up for the lack of specification of these requirements to its IT vendor, nor did the Organisation conduct any of its own scheduled security reviews, through which it could have detected any security inadequacy or vulnerabilities within its IT infrastructure. 11. In the above circumstances, the Organisation is found to have breached the Protection Obligation under section 24(a) of the PDPA. 12. Following the Incident, the Organisation decommissioned its e-commerce webserver and overhauled its IT infrastructure. Apart from deciding to conduct online sales solely through third party websites, the Organisation also rebuilt its ERP server in a secure environment with new set of firewalls, updated its 4 operating systems and software, implemented the use of SSL-VPN for remote access, and engaged a new IT vendor with the data security and data protection provisions properly specified in a written contract. The Organisation also reviewed and updated all its internal policies relevant to the protection of personal data. 13. In deciding the appropriate outcome in this case, the Commission acknowledges the cooperation extended by the Organisation to the Commission throughout the course of our investigations. The Organisation had also voluntarily admitted to its breach of the Protection Obligation, and took prompt remediation actions to address its security gaps. The Organisation was able to restore fully the personal data affected without loss, thereby minimizing any disruptions to its operations. 14. Having considered the circumstances set out above and the factors listed at section 48J(6) of the PDPA, the Commissioner for Personal Data Protection hereby finds the Organisation in breach and requires the Organisation to pay a financial penalty of $22,000 within 30 days from the notice accompanying date 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. 15. In view of the remedial action by the Organisation, no directions under section 48I are necessary. 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 – 5 (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. 6 ",Financial Penalty,5c70e87aac9ad5ab303f0f8cb9f8f4094c224e02,"[""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,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""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,38,38,1,952,"A financial penalty of $35,000 was imposed on GeniusU for failing to put in place reasonable security arrangements to prevent the unauthorised access and exfiltration of individuals' personal data stored in its staging database.","[""Protection"", ""Financial Penalty"", ""Education""]",2022-04-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---GeniusU-Pte-Ltd--180122.pdf,Protection,Breach of the Protection Obligation by GeniusU,https://www.pdpc.gov.sg/all-commissions-decisions/2022/03/breach-of-the-protection-obligation-by-geniusu,2022-04-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2101-B7725 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And GeniusU Pte. Ltd. SUMMARY OF THE DECISION 1. On 12 January 2021, GeniusU Pte. Ltd. (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of unauthorized access and exfiltration of a staging application database (the “Database”) holding personal data (the “Incident”). 2. The personal data of approximately 1.26 million users were affected. The datasets affected comprised first and last name, email address, location and last sign-in IP address. 3. The Organisation’s internal investigations revealed that the likely cause of the Incident was compromise of one of its developer’s password, either because the developer used a weak password for his GitHub account or the password for his GitHub account had been compromised. This allowed the threat actor to enter 1 the Organisation’s GitHub environment. As the Organisation had stored the login credentials to the Database in the codebase in its GitHub environment, the threat actor was able to gain access to and exfiltrate personal data stored in the Database. 4. The Organisation took the following remedial measures after the Incident: a. Rotated the credentials of the Database; b. Removed all hard-coded credentials from the codebase; c. Purged all existing website sessions; d. Removed all personal data from non-production environment servers, e. Implemented multi-factor authentication on all work-related accounts; f. Implemented a standardised cyber security policy and related procedures for all staff; and g. 5. Notified users and the GDPR data authority (Ireland) of the Incident. The Commission accepted the Organisation’s request for this matter to be handled under the Commission’s expedited breach decision procedure. This meant that the Organisation had voluntarily provided and unequivocally admitted 2 to the facts set out in this decision. The Organisation also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 6. Based on its admissions, the Organisation had breached the Protection Obligation by: a. Storing credentials for the Database in the codebase in its GitHub environment. This meant that once the threat actor was able to access the GitHub environment, he was able to discover the credentials to access personal data stored in the Database; and b. Storing actual personal data in the Database that was in a nonproduction (testing) environment, which are usually not as secure as production environments. Actual personal data should not be stored in testing environments, which are known to be less secure. 7. In the circumstances, the Organisation is found to be in breach of section 24 of the PDPA. 8. Having considered the circumstances set out above and the factors listed at section 48J(6) of the PDPA and the circumstances of the case, including (i) the Organisation’s upfront voluntary admission of liability which significantly reduced 3 the time and resources required for investigations; and (ii) the prompt remedial actions undertaken by the Organisation, the Organisation is given a notice to pay a financial penalty of $35,000. 9. The Organisation must make payment of the financial penalty within 30 days from the notice accompanying date 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. 10. In view of the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. 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,7a86d2d632c8b7dd6e2f8666a6255cf824652a01,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,39,39,1,952,"A financial penalty of $20,000 was imposed on Trinity Christian Centre for failing to put in place reasonable security arrangements to prevent the unauthorised access of individuals' personal data hosted in its database servers.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""Ransomware"", ""Remote Desktop Protocol""]",2022-04-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Trinity-Christian-Centre-Limited---03022022.pdf,Protection,Breach of the Protection Obligation by Trinity Christian Centre,https://www.pdpc.gov.sg/all-commissions-decisions/2022/03/breach-of-the-protection-obligation-by-trinity-christian-centre,2022-04-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2009-B7057 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Trinity Christian Centre Limited SUMMARY OF THE DECISION 1. On 11 March 2021, Trinity Christian Centre Limited (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that its database servers containing personal data were infected with ransomware on or around 17 February 2021 (the “Incident”). 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. It also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 1 The Incident 3. The Organisation runs Trinity Christian Church in Singapore. 4. At the time of the Incident, the database servers contained 72,285 individuals’ data. The types of data affected for each individual varied, and included at times an individual’s name, full identification number, residential address, contact number, email address, photograph, date of birth, age, marital status, education level, and/or description of medical condition (if applicable). 5. Investigations by the Organisation revealed that the Organisation maintained an open and publicly exposed remote desktop protocol port. This allowed a threat actor with access to compromised administrator account credentials to enter the Organisation’s network and database servers to execute ransomware attack on 17 February 2021, rendering the databases inaccessible. 6. The Organisation managed to restore the affected databases from its back-up copies. Based on the Organisation’s investigations, there was no evidence to suggest that the threat actor exfiltrated the Organisation’s databases. The Organisation’s Admission 7. The Organisation admitted that it had breached the Protection Obligation under section 24 of the PDPA as: 2 a. It could have implemented separate access controls (i.e. separate logins) to protect the databases containing personal data; and b. The initial unauthorised entry to the Organisation’s network was through an administrator account that the Organisation had assigned to an IT vendor it had engaged to develop and test applications. The Organisation conceded that it failed to stipulate data protection requirements on its vendor. Remediation 8. Following the Incident, the Organisation notified its church members on 8 April 2021. The Organisation changed all user and administrator passwords, closed all unused and open ports used for remote access and restricted logon access with domain administrator privileges to servers and workstations. A security review was also conducted and the Organisation implemented real time threat monitoring, detection, and response measures. The Commission’s Decision 9. As noted earlier, the Organisation admitted that it was in breach of section 24 of the PDPA as it could have implemented separate access controls to protect the databases containing personal data. In our view, the number and type of personal data sets in the possession or under the control of the Organisation created a 3 security need for stronger access control beyond reliance on frontend password protection. Indeed, with increasingly sophisticated phishing and social engineering techniques, adding another layer of protection to protect backend database servers, and manage the risks that frontend login credentials may be compromised was a reasonable security measure, which the Organisation also accepted. 10. The Commission had also previously emphasised in our decisions1 and in the Commission’s Guide to Managing Data Intermediaries that organisations that engage IT vendors should ensure that their IT vendors are aware of the need for personal data protection by making it part of their contractual terms. 11. The Organisation admitted that its contract with its IT vendor only contained a general confidentiality clause not to disclose information obtained without the Organisation’s prior written consent. Even though the Organisation was well aware that its IT vendor would process personal data, the Organisation failed to stipulate within the contract any requirements on the vendor to protect the church members’ personal data, thereby breaching section 24 of the PDPA. 12. In determining the directions to be imposed on the Organisation for the breach, the Commissioner took into account the following factors: 1 See examples – Jigyasa [2020] SGPDPC 9, MDIS Corporation Pte Ltd [2020] SGPDPC 11 and Civil Service Club [2020] SGPDPC 15. 4 Aggravating (a) The high number of affected individuals of 72,285 which included approximately 8,300 minors; (b) The nature of the affected data. In particular, the affected databases contained descriptions of medical conditions provided by individuals counselling services and overseas mission applications. Individuals would expect a high level of confidence when they convey such information to the Organisation for handling; Mitigating (c) The Organisation’s upfront admission of breach of the Protection Obligation, and the prompt remedial actions to mitigate the effects and prevent recurrence of the Incident; and (d) There was no evidence of exfiltration of the Organisation’s databases. 13. On account of the above, the Organisation is directed to pay a financial penalty of $20,000 within 30 days from the date of this direction. In view of the remedial action of the Organisation, the Commission will not be issuing any other directions. 5 The following provision 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. 6 ",Financial Penalty,1b58e6ca07c13ad8238e25acd672c8231540a608,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,41,41,1,952,"A financial penalty of $4,000 was imposed on Tanah Merah Country Club for failing to put in place reasonable security to protect personal data in its possession. The incident resulted in personal data being accessed.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""Email"", ""Password policy""]",2022-02-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Tanah-Merah-Country-Club---20122021.pdf,Protection,Breach of the Protection Obligation by Tanah Merah Country Club,https://www.pdpc.gov.sg/all-commissions-decisions/2022/02/breach-of-the-protection-by-tanah-merah-country-club,2022-02-18,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2102-B7951 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Tanah Merah Country Club SUMMARY OF THE DECISION 1. On 24 February 2021, Tanah Merah Country Club (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that an employee’s (the “Employee”) email account had been compromised and 600 phishing emails had been sent to various individuals on 22 February 2021 (the “Incident”). 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. This meant that the Organisation voluntarily and unequivocally admitted to the facts set out within this decision. It also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 3. The Organisation’s investigations revealed that it was likely that the Organisation’s email accounts had been subjected to password spraying attacks. Password spraying is a type of password attack where a threat actor uses a few commonly used or default passwords against many different accounts. In contrast to traditional brute-force attacks, where the targeted account may quickly get lockedout due to account-lockout policies that only allow for a limited number of failed attempts, password spraying attacks allow a threat actor to mount an attack against many accounts with a single commonly used password, while remaining undetected, before attempting the second password. At the time of the Incident, the Employee was using the password “TMCC@1234”, which the Employee had not changed for a period of nearly 5 years, since 2016 to the time of the Incident on 22 February 2021. 4. After gaining access to the Employee’s email account, the threat actor accessed the personal data of 467 individuals, including: a. The email addresses of 155 club members and 284 members of public, which the threat actor had used to send phishing emails to. b. The name, and/or NRIC number, and/or email addresses of a further 28 individuals contained within the emails. 5. Prior to the Incident, the Organisation had informed its employees via an email IT newsletter in August 2018 of the need to change their password once every 3 months, and to use passwords which are at least 8 characters, with a combination of uppercase letter, lowercase letter, special character, and number. In September 2019, the Organisation sent another email IT newsletter to inform its employees of the implementation of a domain password policy. This meant that the abovementioned password requirements became system enforced. 6. Despite disseminating these email IT newsletters where it referred to its password requirements and the implementation of a system-enforced domain password policy, the Organisation failed to further develop its password requirements into a full-fledged password policy in writing and disseminate it in such a manner whereby all its employees, new and old, could easily take reference from the password policy and consult the password policy at any time. It was only on 23 February 2021, after the Incident had occurred, that the Organisation documented its password policy in writing. 7. We had previously emphasized the importance of organisations having a written personal data protection policy so as to guide its employees and staff in Re Furnituremart.sg [2017] SGPDPC 7. In that case, the Commission noted at [14] as follows: “The lack of a written policy is a big drawback to the protection of personal data. Without having a policy in writing, employees and staff would not have a reference for the organisation’s policies and practices which they are to follow in order to protect personal data. Such policies and practices would be ineffective if passed on by word of mouth, and indeed, the Organisation may run the risk of the policies and practices being passed on incorrectly. Having a written policy is conducive to the conduct of internal training, which is a necessary component of an internal data protection programme”. 8. A properly documented password policy is therefore crucial for the protection of personal data. In this regard, the Organisation admitted that it had breached the Protection Obligation under section 24 of the PDPA as it failed to document its password policy in writing. 9. The Commission recently issued a “Guide to Data Protection Practices for ICT Systems” on 14 September 2021. In the Guide, we noted that in order to maintain good governance over its personal data and mitigate data breach risks throughout the data lifecycle, organisations should develop and implement ICT security policies for data protection. Key ICT policies would include a password policy. 10. Prior to the issuance of this Guide, the Commission had also released a Handbook on “How to Guard Against Common Types of Data Breaches”, which is complemented by the Checklists to Guard Against Common Types of Data Breaches. In the Handbook, the Commission identified poor management of accounts and passwords as one of the five common causes and types of data breaches. We noted that the use of default value, weak or easily guessable passwords result in accounts being particularly vulnerable to brute force or dictionary attacks. We therefore recommended that organisations adopt and implement a strong password policy, with the following good practices: (i) Enforcing a password history policy to ensure that employees do not reuse their previous passwords; (ii) Encouraging users to use passphrases such as “Iwant2l@se10kg”, which may be long and complex, yet easy to remember; and (iii) Discouraging users from using the same passwords across different systems. 11. In this regard, we observed that the Organisation’s email IT newsletters to its employees had cited “TMCC_Password_123” as an example of what amounts to a good password. Unfortunately, we are unable to endorse the Organisation’s choice of “TMCC_Password_123” as an example of what amounts to a good password. In Re Chizzle Pte Ltd [2020] SGPDPCR 1, the Commission highlighted that a password that complies with the recommended password complexity rules in form could still be a weak password easily guessable and vulnerable to password attacks if the password incorporates components such as the organisation’s name, which is not difficult to guess and crack. In this regard, we note that in the Organisation’s password policy, which it adopted on 23 February 2021, the Organisation now recommends that its employees refrain from the use of the Organisation’s name or abbreviations such as “TMCC”. 12. In addition, the Organisation also admitted that it had failed to provide structured and organised training for its staff on how to ensure compliance with the obligations under the PDPA and how personal data should be handled in the course of their work. Only ad-hoc and informal training had been provided. As a result, the Employee lacked the awareness of the need to change her password at more regular intervals and of the need to use a strong password. The Employee did not receive system prompts to change her password as the domain password policy was not pushed down to her system due to a domain controller disruption. 13. The Commission wishes to emphasize that staff training is a critical and necessary component to ensure that an organisation is well placed to protect the personal data in its possession and/or control. The Protection Obligation under section 24 of the PDPA extends to and includes the training of all employees who have to handle personal data in the course of their work so that an organisation’s employees can then successfully adopt and implement the policies and best practices necessary to ensure the protection of personal data in an organisation’s possession and/or control. 14. In light of the above, the Deputy Commissioner for Personal Data Protection finds the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 15. Following the incident, the Organisation engaged an IT forensic vendor for investigation. We note that the Organisation has since implemented the measures recommended by the vendor to improve its cybersecurity. The Organisation has also documented its password policy, implemented regular updates, conducted user awareness training, and other trainings on personal data protection. 16. The Organisation cooperated with the Commission’s investigations, admitted to its breach of the Protection Obligation, and took prompt remedial actions. 17. Having considered the circumstances set out above, the factors listed at section 48J(6) of the PDPA, and in particular, the Organisation’s voluntary admission to being in breach of section 24 of the PDPA under the Expedited Breach Decision Procedure, which is a significant mitigation factor, the Deputy Commissioner for Personal Data Protection requires the Organisation to pay a financial penalty of $4,000 within 30 days from the notice accompanying date 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. 18. Finally, in view of the remedial actions taken by the Organisation, no other directions are necessary. 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. ",Financial Penalty,db3f5f6adf8ce0a020293ba554d69dc62a612298,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,42,42,1,952,"A financial penalty of $10,000 was imposed on North London Collegiate School (Singapore) for failing to put in place reasonable security arrangements to prevent the unauthorised access of its student applicants’ personal data residing in a website directory folder.","[""Protection"", ""Financial Penalty"", ""Education""]",2022-02-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---NLCS---01122021.pdf,Protection,Breach of the Protection Obligation by North London Collegiate School (Singapore),https://www.pdpc.gov.sg/all-commissions-decisions/2022/02/breach-of-the-protection-obligation-by-north-london-collegiate-school,2022-02-18,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2107-B8562 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And North London Collegiate School (Singapore) Pte. Ltd. SUMMARY OF THE DECISION 1. On 2 July 2021, North London Collegiate School (Singapore) Pte. Ltd. (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that a parent of a student was able to view and access a student report by the Organisation by performing searches using internet search engines. (the “Incident”). 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. It also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 3. Investigations revealed that, from December 2019 to July 2021, parents of prospective students could submit documents for admission applications via the Organisation’s website (https://nlcssingapore.sg/). All submitted documents were stored in a directory/ folder of the website. However, the website directory/ 1 folder was not adequately secured from automatic indexing by web crawlers. As a result, the submitted documents were indexed by search engines and could show up in online search results. 4. The table below summarises1 the number of affected individuals for each type of document accessible in the directory/ folder (the “Compromised Documents”): S/N 5. Type of Document Number (Scanned or Electronic Copies) Affected 1 Passport 1,742 2 Identity cards (i.e NRICs) 1,714 3 Digital Photographs of applicants 720 4 Birth Certificates 709 5 Academic Reports 676 6 Immunization Records 670 of Individuals The documents above contained the following types of personal data (the “Personal Data Sets”) at risk of unauthorised access in the Incident - Name, Address, NRIC number, Passport Number, Photograph, Date of Birth, immunization details and academic details. 6. The Organisation admitted that it had only relied on a Robots.txt file deployed on its Website to instruct search engines to refrain from indexing the documents in the website directory folder. However, it is well established that the robots exclusion protocol is not mandatory, in the sense that it relies on compliance of 1 This table sets out the documents at risk of unauthorised access in the Incident. Not all of these types of documents were affected for each Affected Individual, and the documents affected for each Affected Individual varies. A unique Affected Individual could have multiple type of documents affected. 2 web crawlers without an enforcement mechanism. Therefore, Organisations storing personal data in website directory/ folders should instead implement proper folder or directory permissions and access controls to prevent unintended access by web crawlers. 7. In addition, the Organisation had stated that it relied on a related group company to setup and manage its website, including to make the necessary security arrangements to protect any personal data collected. However, in this case, there were no clear business requirements (e.g. contractual stipulations) specifying that the Organisation was relying on the sister company to recommend and/or implement security arrangements to protect personal data that resides in the website directory/ folder. 8. Re Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 stated the arrangements to be made when organisations in a group used IT services provided by a group member. An organisation receiving IT services from another organisation of the group should ensure that the latter is bound by either written agreements or group rules to protect personal data in the course of provision of the services. Absent clear written personal data protection requirements of the group member managing the Organisation’s website, the responsibility to make reasonable security arrangements to protect the Affected Personal Data in the directory/ folder of the website remained squarely with the Organisation. 3 9. In the circumstances, the Deputy Commissioner for Personal Data Protection finds the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 10. Following the incident, the Organisation ceased the collection of documents via its website and would now be utilizing a specialized school admission software to manage the application process and the personal data submitted. Additionally, the Organisation would be implementing appropriate binding corporate rules to govern the centralization of corporate functions and the handling of data protection and cybersecurity within its corporate group. 11. The Organisation cooperated with the Commission’s investigations, admitted to its breach of the Protection Obligation and took prompt remedial actions to address its inadequacies in its processes. There were also no indications that that the personal data affected in the Incident had been misused in any form. However, personal data of minors were at risk of unauthorised access. 12. Having considered the circumstances set out above and the factors listed at section 48J(6) of the PDPA, the Deputy Commissioner for Personal Data Protection requires the Organisation to pay a financial penalty of $10,000 within 30 days from the notice accompanying date 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. 4 13. In view of the remedial actions taken by the Organisation, no other directions are necessary. 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. 5 ",Financial Penalty,2b442c9cd53b17e7887a8bb1bdfc113eeb21ae47,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,45,45,1,952,Giordano was found not in breach of the PDPA in relation to an unauthorised network entry and ransomware infection that affected two of its systems storing personal data.,"[""Protection"", ""Not in Breach"", ""Wholesale and Retail Trade"", ""Ransomware"", ""Phishing""]",2021-11-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Giordano-Originals-S-Pte-Ltd--151021.pdf,Protection,No Breach of the Protection Obligation by Giordano,https://www.pdpc.gov.sg/all-commissions-decisions/2021/11/no-breach-of-the-protection-obligation-by-giordano,2021-11-11,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2011-B7387 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Giordano Originals (s) Pte Ltd SUMMARY OF THE DECISION 1. On 3 December 2020, the Personal Data Protection Commission (the “Commission”) was notified by Giordano Originals (S) Pte Ltd (the “Organisation”) of an unauthorized network entry and ransomware infection at the OS and server level that occurred on or about 12 July 2020 (the “Incident”). 2. As a result of the Incident, two of the Organisation’s systems, one which stores the personal data of its employees and second, the personal data of its members were affected. 3. The Organisation’s own and independent investigation conducted found no sign of suspicious activity in the Singapore network, and no impact beyond the Singapore network. The unauthorised entry had most likely occurred through the use of compromised credentials obtained through phishing. 4. Personal data of 790,000 members and 184 employees in encrypted form were affected. The personal data of members comprised names (20% of the members), contact number and partial date of birth (without birth year). The personal data of employees comprised name, NRIC, address, gender, age, contact number, email address, educational and salary information. 5. Investigations revealed that the Organisation had in place reasonable security measures that are consistent with the recommendations that the Personal Data Protection Commission had made in our recent Handbook on “How to Guard Against Common Types of Data Breaches” on how to prevent malware or phishing attacks. The Organisation had installed and deployed various endpoint security solutions, which was complemented with real-time system monitoring for any Internet traffic abnormalities. Even before the Incident, the Organisation also conducted regular periodic system maintenance, reviews and updates (such as vulnerability scanning and patching). 6. More importantly, the Organisation had also ensured that its data was regularly and automatically backed-up, which was a key recommendation that the Commission made in our Handbook. 7. In addition, the Organisation had also taken steps to better protect the personal data affected by encrypting the personal data using current industry-standard RSA algorithm and passphrase. As a result, the personal data affected by the ransomware was not legible without decryption. 8. The Commission endorses the proper use of industry-standard encryption to protect personal data, and will give due weight to Organisations which have implemented the recommendations we made in our Handbook in determining whether an organisation has complied with its Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”), or as a strong mitigation factor in the event of the Commission finds that there has been a breach of section 24 of the PDPA. 9. 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 increased frequency of staff phishing simulation trainings and security reviews as well as additional monitoring measures. There was no evidence of exfiltration of the personal data or decryption of the personal data. The Organisation was also able to fully restore the personal data from its backups. 10. In light of the reasons discussed above, the Deputy Commissioner for Personal Data Protection is satisfied that the Organisation had met its Protection Obligation under section 24 of the PDPA. In light of our findings, we will not be issuing any directions or taking any further enforcement action against the Organisation in relation to the Incident. ",Not in Breach,3967d62cd80927b7c190ce8deba0812d8d97eeb5,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,46,46,1,952,"A financial penalty of $74,000 was imposed on Commeasure for failing to put in place reasonable security arrangements to prevent the unauthorised access and exfiltration of customers’ personal data hosted in a cloud database.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B""]",2021-11-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Commeasure-Pte-Ltd---15092021.pdf,Protection,Breach of the Protection Obligation by Commeasure,https://www.pdpc.gov.sg/all-commissions-decisions/2021/11/breach-of-the-protection-obligation-by-commeasure,2021-11-11,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 11 Case No. DP-2009-B7057 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 201 And Commeasure Pte Ltd … Organisation DECISION Commeasure Pte Ltd. [2021] SGPDPC 11 Lew Chuen Hong, Commissioner — Case No. DP-2009-B7057 15 September 2021 Introduction 1 On 25 September 2020, the Personal Data Protection Commission (“the Commission”) received a data breach notification from Commeasure Pte Ltd (“the Organisation”) that its database containing 5,892,843 customer records had been accessed and exfiltrated (“the Incident”). The Organisation first found out about the data breach on 19 September 2020 when a cybersecurity company based in Atlanta, United States of America, approached the Organisation with an offer to contain the breach and retrieve the data from the hackers. The Commission commenced investigations into the Incident thereafter. Facts of the Case Background 2 The Organisation was incorporated in Singapore in 2014, and operates a hotel booking platform www.reddoorz.com which serves customers in the Southeast Asian region, such as Indonesia, Singapore, Philippines, Vietnam and Thailand. The Singapore office is primarily engaged in sales, finance and administrative activities, while all IT functions (including the management of the affected application package in this case) were managed by the Organisation’s subsidiary company, Commeasure Solutions India Pvt Ltd (“CPL India”). Cause of the Incident 3 Investigations revealed that the unknown threat actor(s) had most likely gained access and exfiltrated the Organisation’s database of customer records hosted in an Amazon RDS cloud database, after they obtained an Amazon Web Services (“AWS”) access key. The AWS 2 access key was embedded within an Android application package (“the affected APK”) publicly available for download from the Google Play Store. 4 This affected APK was created sometime in 2015, when the Organisation was still a start-up, and was last updated in January 2018. Even though the AWS access key had access to a “live” or production database, the AWS access key was embedded in the APK, and erroneously marked as a “test” key by the then-developers. With the exception of one of the Organisation’s co-founders and Chief Technology Officer, all the developers have since left the Organisation. Most unfortunately, even though the Organisation regarded this APK as “defunct”, the APK remained publicly available for download on the Google Play Store until the Organisation became aware of the Incident and removed the affected APK. 5 The fact that the Organisation had treated the affected APK as a “defunct” APK meant that even though the Organisation had engaged a cybersecurity company to conduct a security review and penetration testing sometime from September 2019 to December 2019, it was not within the scope of the security review or penetration tests. Consequently, the vulnerability was left undetected and exposed until the Organisation found out about the Incident. Likewise, even though the Organisation used “Proguard” on its current Android apps to prevent reverse engineering of APKs, which may have prevented the unknown threat actors from retrieving the AWS access key, the Organisation failed to review and deploy “Proguard” on the affected APK which it regarded as “defunct”. 6 As a result of the Incident, the Organisation’s database containing 5,892,843 customer records which included the customer’s name, contact number, email address, date of birth, a hashed password (encrypted with one-way BCrypt hash algorithm) used by the customer to access their “RedDoorz” account and their booking information was accessed and exfiltrated by unknown threat actor(s). Based on the Organisation’s investigations, the unknown threat actor(s) did not gain access or download the customers’ masked credit card numbers. Remedial actions 7 Following the Incident, the Organisation took the following remedial actions: a. CPL India immediately removed the affected APK from the Google Play Store; 3 b. The old access keys were invalidated and new access keys were created. The infrastructure and code repository access credentials were changed; c. IP blocking of suspicious traffic was enabled; and d. Informed all the affected customers via email on 26 September 2020 of the data breach, advising them to change their RedDoorz account password as an added precautionary measure, and to avoid using the same password on other digital platforms. 8 To prevent a recurrence of the Incident or similar incidents, the Organisation also took the following remedial actions: a. The Organisation amended its credential policy to clearly prohibit developers from embedding access codes in any code base; b. The Organisation upgraded their IT infrastructure to a private space for isolation of the customer database from the Internet. Only whitelisted IP addresses were allowed connection to ‘live’ databases; c. The Organisation separated the accounts for production and staging environments for all AWS services. Two-factor authentication was enabled for all tools and accounts used by developers. VPN-based control was implemented to access infrastructure resources; d. The Organisation configured alerts to capture mySQL dump query. Web application firewalls were set up. An audit of all user access to the AWS environment was conducted; and e. The Organisation appointed a cybersecurity company to conduct vulnerability assessment and penetration testing of all its existing applications. Findings and Basis for Determination Whether the Organisation contravened the Protection Obligation 4 9 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, 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 its control. 10 The Organisation collected the personal data of customers when they created a “RedDoorz” account through its hotel booking platform www.reddoorz.com. Even though the Organisation’s customer database was hosted using Amazon RDS on cloud, on servers physically located in North Virginia, United States of America, the database remained under the Organisation’s control throughout as the Organisation could access, use and remove the data. 11 In Re The Cellar Door Pte Ltd,1 we found that even though the organisation was not in direct possession of the personal data that was held in the data intermediary’s servers, it was still obliged to implement reasonable security arrangements to protect the personal data as it had control over such data. Likewise, even though AWS was responsible for the security of the cloud infrastructure that it provided to the Organisation, the Organisation bore ultimate responsibility under section 24 of the PDPA for making reasonable security arrangements to protect all the customers’ data under its control. 12 The data breach occurred because the Organisation embedded the AWS access key, which allowed access to the “live” or production database, in the APK. The root cause was therefore in the application, which was clearly within the Organisation’s responsibility. This presented a clear security risk. The AWS access key comprises of two parts, first, the access key ID, and second, the secret access key, and was effectively the Organisation’s username and password. In a webpage titled “Best practices for managing AWS access keys”, AWS advised users to protect the access keys as “anyone who has the access keys for your AWS account root user has unrestricted access to all resources in your AWS account” 2. AWS also cautioned users not to “embed access keys directly into code”, which was exactly what the Organisation 1 [2017] PDP Digest 160. 2 https://docs.aws.amazon.com (last accessed on 6 August 2021). 5 had done in the present case. We therefore find the Organisation in breach of section 24 of the PDPA for reflecting the AWS access key in the affected APK. 13 In the course of investigations, the Organisation explained that its failure to implement sufficiently robust processes to manage its inventory of infrastructure access keys was attributable to the high turnover of its employees from the time of its inception to the discovery of the Incident. This explanation is unacceptable, however sympathetic one might be to the human resource issues that the Organisation had to manage. The Organisation’s responsibility to protect personal data in its control or possession commences ought not to have been subjected to staff movement or appointment. 14 In Re WTS Automotive Services Pte Ltd,3 we highlighted the importance of conducting a “regular review to ensure that the website collecting personal data and the electronic database storing the personal data has reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks” as the “personal data of individuals may be exposed if the website or database in which it is stored contains vulnerabilities”.4 The Commission reiterates that it is necessary for an organisation to “[c]onduct regular ICT security audits, scans and tests to detect vulnerabilities”.5 15 In this case, the Organisation conducted internal security testing and application architecture reviews every quarter and had engaged a cybersecurity company to conduct a security review and penetration testing sometime from September 2019 to December 2019. The Organisation admitted however, that it “overlooked” including the affected APK in the security review as it was “old”. In addition, the Organisation admitted that the AWS access key had been mistakenly marked as a “test key”. This resulted in its omission from the security review as well as from the Organisation’s periodic review of accounts and login credentials. 16 It is important to highlight that the Organisation remained responsible for the affected APK. The Organisation’s failure to include the affected APK and the AWS access key within the scope of the security review arose because of the Organisation’s negligence to include them 3 [2019] PDP Digest 317. 4 Personal Data Protection Commission, Guide to Data Protection Impact Assessments (1 November 2017) at para. 8.3. 5 Personal Data Protection Commission, Guide to Securing Personal Data in Electronic Medium (revised 20 January 2017) at para. 6.1. 6 in its inventory of IT assets in production after the Organisation had wrongly labelled the affected APK as “defunct” and the AWS access key as a “test” key. 17 Accordingly, we are not satisfied that the IT security reviews that the Organisation conducted were sufficiently rigorous, and met the standard required under section 24 of the PDPA. We are therefore of the view that the Organisation has breached section 24 of the PDPA for failing to include the affected APK and AWS access key in the Organisation’s security reviews. If a security review had examined the affected APK or the AWS access key, the vulnerability exposed by the embedded AWS access key would have been discovered, and the Incident could have been prevented. The Commission’s Directions 18 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, we took into account the factors listed at section 48(6) of the PDPA. The Commission notes that the data breach affected 5,892,843 individuals whose personal data was exfiltrated. This is the largest data breach that has occurred since the PDPA came into effect. Further, prior to the exfiltration of the data in September 2020, the affected APK with the embedded AWS access key had remained publicly available for download on the Google Play Store for a significant duration of time. A lengthy period of 2 years and 9 months passed from the time the Organisation made its last update to the affected APK in January 2018 to 19 September 2020, when the Organisation finally found out about the data breach. 19 Having said that, the Commission also took into account the following mitigating factors: (a) The Organisation was cooperative in the course of investigations and had provided prompt responses to PDPC’s requests for information; (b) The Organisation implemented remedial actions to address the Incident; and (c) The Organisation had conducted periodic security reviews which promised to offer some data protection, albeit their efforts were ultimately futile as these security reviews did not include the affected APK. 7 20 In deciding the amount of financial penalty to be imposed, we also considered that the Organisation, which operates in the hospitality industry, had been severely impacted by the COVID-19 pandemic. Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $74,000 within 30 days from the date of the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court6 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. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 6 Cap 322, R5, 2014 Rev Ed. 8 ",Financial Penalty,07efcafd13b2f83b14c9de466d3a142032ed8020,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,47,47,1,952,"A financial penalty of $10,000 was imposed on ChampionTutor for failing to put in place reasonable security arrangements to protect personal data in its possession. The incident resulted in the personal data being exposed.","[""Protection"", ""Financial Penalty"", ""Education""]",2021-10-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--ChampionTutor-Inc-Private-Limited--10082021.pdf,Protection,Breach of the Protection Obligation by ChampionTutor,https://www.pdpc.gov.sg/all-commissions-decisions/2021/10/breach-of-the-protection-obligation-by-championtutor,2021-10-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2103-B7984 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And ChampionTutor Inc. (Private Limited) SUMMARY OF THE DECISION 1. On 24 February 2021, the Personal Data Protection Commission (the “Commission”) received information that ChampionTutor Inc. (Private Limited)’s (the “Organisation”) database, containing personal data of individuals, was being sold on dark web (the “Incident”). 2. The Organisation was not aware of the Incident until it was notified by the Commission. The cause of the Incident was suspected to be SQL injection of the Organisation’s website. The Organisation knew about this SQL injection vulnerability when it conducted a penetration test in December 2020. The Organisation had instructed its developer, based in India, to fix the vulnerability. However, the developer did not act on the request and this vulnerability was left unfixed until the Incident happened. 3. As a result, the personal data of 4,625 students were affected. The personal data included name, email address, contact number and address. 4. The Organisation took the following remedial measures after the Incident: a. Engaged a new team of developers to fix all the SQL injection vulnerabilities; b. Parameterised SQL statements by disallowing data-directed context changes to prevent SQL injection attacks from resurfacing; and c. Is in the process of revamping the entire website source codes to reduce possible vulnerabilities. 5. The Organisation admitted to having breached the Protection Obligation under section 24 of the Personal Data Protection Act (the “PDPA”), and requested for the matter to be dealt with in accordance with the Commission’s Expedited Decision Procedure. 6. The Organisation admitted it was aware of the SQL injection vulnerability in December 2020. Yet, the Organisation failed to take active steps to fix the vulnerability even when its developer was not responsive, purportedly due to the COVID-19 pandemic, and the Organisation left the vulnerability unresolved until the Incident happened. 7. In the circumstances, the Organisation is found to have breached section 24 of the PDPA. 8. On 14 July 2021, the Organisation was notified of the Commission’s intention to impose a financial penalty based on the Commission’s consideration of the factors listed under section 48J(6) of the PDPA, and the circumstances of this case, in particular (i) the Organisation’s upfront voluntary admission of liability which significantly reduced the time and resources required for investigations; and (ii) the prompt remedial actions undertaken by the Organisation. The Organisation was invited to make representations. 9. Having considered the Organisation’s representations dated 28 July 2021, the Deputy Commissioner hereby directs the Organisation to pay a financial penalty of $10,000 in 12 instalments by the due dates as set out in the accompanying notice, failing which the full outstanding amount shall become due and payable immediately and 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. 10. In view of the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. ",Financial Penalty,001064522a1c6277a0c24b9cf1a09495440cf2e8,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,48,48,1,952,A warning was issued to The National Kidney Foundation for failing to put in place reasonable security to protect the personal data in its possession. The incident resulted in personal data being downloaded.,"[""Protection"", ""Warning"", ""Healthcare"", ""Phishing"", ""Email""]",2021-10-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---The-National-Kidney-Foundation---15092021.pdf,Protection,Breach of the Protection Obligation by The National Kidney Foundation,https://www.pdpc.gov.sg/all-commissions-decisions/2021/10/breach-of-the-protection-obligation-by-the-national-kidney-foundation,2021-10-14,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 10 Case No DP-2005-B6353 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And The National Kidney Foundation … Organisation DECISION The National Kidney Foundation [2021] SGPDPC 10 Yeong Zee Kin, Deputy Commissioner — Case No. DP-2005-B6353 15 September 2021 Introduction 1 On 22 May 2020, the Personal Data Protection Commission (the “Commission”) received a data breach notification from the National Kidney Foundation (the “Organisation”). The Organisation had discovered that on 17 May 2020, a hacker had gained access to the work email account of one of its employees (“Employee A”) and had likely exfiltrated the personal data contained in the email account (the “Incident”). Background 2 The Organisation is a prominent non-profit health organisation in Singapore that provides health services, including subsidised kidney dialysis. Employee A is an executive in the Organisation’s Clinical Operations department. which deals with implementation of operations policies, budget planning and working with medical and nursing management team to uphold healthcare standards. The Incident 3 Investigations revealed that, on 14 May 2020, Employee A received a phishing email containing a hyperlink to a website with a further link to another website seeking his account credentials. The hacker is believed to have obtained Employee A’s account credentials in this way. Thereafter, the hacker accessed Employee A’s email account (the “Email Account”) and synchronised the mailbox on 17 May 2020. In doing so, the hacker is believed to have downloaded all the data stored in the Email Account in its entirety. The hacker also used Employee A’s email account to send phishing emails to 1,039 external business contacts of the Organisation, and 9 email accounts belonging to persons within the Organisation. Whilst these 1 phishing emails contained a link to a phishing webpage, they did not disclose any personal data collected from the Email Account. 4 The Email Account comprised of 23,145 emails containing the personal data of approximately 500 individuals (i.e. patients, employees and third parties): (a) Age (b) Arrear sum owed (22 patients affected) (c) Bank account number (d) Curriculum vitae (e) Date of birth (f) Data subject access request form (for 1 Singapore Police Force officer) (g) Information on the patient's family status and any psycho-social issues faced by the patient (h) Dialysis readings (i) Email address (j) Emergency contact numbers of nurses (k) Education certificate(s) (l) Foreign Identification Number (m) Headshot photo (n) Health screening virology report of the Organisation’s nurses (25 nurses affected) (o) Household income band (p) Marriage certificate; and (q) Medical condition (8 patients affected) (collectively, the “Affected Data”) Security Measures prior to the Incident 2 5 At the time of the Incident, the work email accounts of the Organisation’s employees were hosted on Microsoft Office 365, and the employees were able to access their email accounts through the internet via a browser, ie web-accessible email or webmail. The following security arrangements were in place to protect the email accounts from unauthorised access: (a) The password policy requires a minimum of 8 alphanumeric characters, including upper and lower cases, and a special symbol. (b) A maximum of 3 unsuccessful login attempts before email accounts were locked out. (c) Deployed Microsoft’s Advanced Threat Protection (“ATP”) email filtering service, with the ATP anti-phishing feature turned on. (d) Deployed Sender Policy Framework (“SPF”) and Domain Keys Identified Mail (“DKIM”) email authentication protocols. 6 In addition, the Organisation also had various storage protection and network protection measures. This included a web isolation tool from Menlo Security, and an appointed Managed Security Service Provider (“MSSP”) that performs security monitoring round the clock. 7 In relation to its employees, the Organisation implemented a range of measures to increase data protection awareness, including: (a) Issuing a policy manual which defined the standards for proper usage of all computing and network resources by employees, and how employees should handle suspicious emails; (b) Conducted training workshops in 2017 and 2018 in relation to the Personal Data Protection Act 2012 (“PDPA”) for its internal stakeholders, which included a segment on cybersecurity covering the topic of suspicious emails; (c) Conducting a phishing simulation exercise in 2019, which Employee A participated in; (d) E-learning modules on cyber-security and the PDPA, which Employee A completed in March 2020; 3 (e) Sending regular emails and alerts targeted at increasing cybersecurity awareness to its employees; and (f) Deploying cybersecurity awareness screensavers on all of the Organisation’s computers. Remedial Measures 8 After the Incident, the Organisation carried out the following remedial and rectification measures: (a) Implemented additional email account security requirements for webmail access in the form of two-factor authentication (“2FA”) on 22 May 2020; (b) Appointed a third-party service provider to conduct daily scans for communication relating to the Incident on platforms across all media; and (c) Notified affected individuals of the Incident on 24 July 2020 and offered the affected individuals subscription to an identity theft service to identify trading or selling of their personal data on the dark web. Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 9 Based on the circumstances of the Incident as set out above, the Commission’s investigation centred on whether the Organisation had breached its obligation under section 24 of the PDPA to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (“Protection Obligation”). 10 For the reasons set out below, it is determined that the Organisation failed to implement reasonable security arrangements to protect the Affected Data from the risk of unauthorised access by failing to implement reasonable access controls to its employees’ webmail accounts. 11 In determining what constitutes reasonable security steps or arrangements, an organisation should have regard to the nature of the personal data in its possession and control, 4 as well as the impact that the disclosure of the data might have on the affected persons. As stated in the Commission’s Advisory on Key Concepts in the PDPA1: “There is no ‘one size fits all’ solution for organisations to comply with the Protection Obligation. Each organisation should consider adopting security arrangements that are reasonable and appropriate in the circumstances, for example, taking into consideration the nature of the personal data, the form in which the personal data has been collected (e.g. physical or electronic) and the possible impact to the individual concerned if an unauthorised person obtained, modified or disposed of the personal data. For example, in the employment context, it would be reasonable to expect a greater level of security for highly confidential employee appraisals as compared to more general information about the projects an employee has worked on. In practice, an organisation should: a) design and organise its security arrangements to fit the nature of the personal data held by the organisation and the possible harm that might result from a security breach; b) identify reliable and well-trained personnel responsible for ensuring information security; c) implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of sensitivity; and d) be prepared and able to respond to information security breaches promptly and effectively. In addition, it might be useful for organisations to undertake a risk assessment exercise to ascertain whether their information security arrangements are adequate. In so doing, the following factors may be considered: a) 1 the size of the organisation and the amount and type of personal data it holds; See sections 17.2 – 17.3 of Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021) 5 b) who within the organisation has access to the personal data; and c) whether the personal data is or will be held or used by a third party on behalf of the organisation.” (emphasis added) 12 Where the personal data held by the organisation or particular employees are sensitive and may cause damage to affected individuals if compromised, strong access control measures, including robust authentication measures, are important safeguards. On top of basic authentication measures such as implementing a proper password policy and password expiration mechanism, strengthened measures such as two-factor authentication (“2FA”) should be considered for webmail accounts with sensitive personal data, such as personal data relating to health and finances. As stated at paragraphs [7.3] and [7.4] of the Commission’s Guide to Securing Personal Data in Electronic Medium2: “7. 3. The strength of authentication, such as password requirements or other mechanisms for access to personal data, should depend on the potential damage to the individual, such as potential damage to reputation or finances, if such personal data is compromised… 7.4 More secure authentication methods include two-factor or multi-factor authentication. These involve the use of a combination of information that the user knows, such as a password or PIN, and an object that only the user possesses, such as a digital key, token or smart card, or a unique physical trait, such as the use of fingerprints in biometric technology. The use of multi-factor authentication increases confidence in the identity of the user accessing the system.” [emphasis added] 13 Having regard to the nature of personal data handled by the Organisation in its daily operations, it had higher-level security needs that had to be met when discharging its Protection Obligation. The Organisation is one of Singapore’s most prominent non-profit health organisations and a key provider of subsidised dialysis treatment, with a significant number of 2 Guide to Securing Personal Data in Electronic Medium (revised Jan 2017) 6 patients under its care. Given the nature of its operations, the Organisation’s employees routinely handle the medical data of its patients and financial data relating to the processing of patient subsidies. The vulnerability of its employees’ email accounts (including the Email Account) is made more acute by the fact that they are web-accessible. In this regard, the Organisation should have conducted a risk assessment to identify the employee email accounts that warranted a more robust authentication process by virtue of the sensitivity of the personal data expected to be received in or sent from their email accounts. 14 As stated at 4 above, the Email Account contained the personal data of approximately 500 individuals. A subset of the Affected Data included sensitive personal data such as the medical conditions of patients, arrears owed and health screening virology reports of some of the Organisation’s nurses. In this regard, even though the Organisation did put in place a host of technical measures and processes to address phishing risks prior to the Incident, we are of the view that these security steps and arrangements did not satisfy the standard required under section 24 of the PDPA, , for the reasons set out below, especially when the nature of the personal data routinely handled by the Organisation is considered. 15 First, the Organisation did not adopt a risk-based approach to identify employees whose roles and functions required them to handle sensitive personal data and strengthen the access control measures to their email accounts. 16 Second, in relation to the email accounts of the employees who handle sensitive personal data (in particular, Employee A) in their daily work, the Organisation also did not implement more secure authentication processes access control measures to their email accounts prior to the Incident. As stated in paragraph 5, the Organisation’s access control requirements were confined to a password policy and the locking out of email accounts after 3 unsuccessful login attempts. These measures are too basic and inadequate to safeguard webmail accounts from the threat of hackers seeking to access them from the internet, and left the personal data contained therein vulnerable to unauthorised access and exfiltration. Examples of more secure authentication methods include 2FA, which the Organisation eventually implemented only after the Incident had occurred. If 2FA had been implemented earlier, this would have ensured that the use of stolen credentials such as passwords would not, per se, be sufficient to access the account. 7 17 In the premises, the Organisation has breached the Protection Obligation. The Deputy Commissioner’s Decision 18 In determining whether any directions should be imposed on the Organisation under section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial penalty under section 48J of the PDPA, the Commission considered the factors listed at section 48J(6) of the PDPA, and gave particular weight to the following mitigating factors: Mitigating Factors (a) The Organisation had cooperated fully with the Commission during its investigations; (b) The Organisation had put in place extensive measures to prevent phishing and educate its employees about data protection; (c) The Organisation took prompt remedial actions following the Incident, including notification of the affected individuals; and (d) The Organisation had conducted various data protection and cybersecurity training for its employees. 19 Having considered all the mitigating factors listed above, the Organisation is administered a warning in respect of its breach of the Protection Obligation. No other directions are necessary in view of the remedial actions already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ",Warning,4095cd546dacd60ce1e477d8e6d816e126775088,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,52,52,1,952,"A financial penalty of $9,000 was imposed on Sendtech for failing to put in place reasonable security arrangements to protect personal data. This resulted in an unauthorised access of the personal data stored in their Amazon Web Services account.","[""Protection"", ""Financial Penalty"", ""Admin and Support Services"", ""Password""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Sendtech-Pte-Ltd---220721.pdf,Protection,Breach of the Protection Obligation by Sendtech,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-sendtech,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2102-B7884 In the matter of an investigation under Section 50(1) of the Personal Data Protection Act 2012 And Sendtech Pte. Ltd. … Organisation SUMMARY OF THE DECISION 1. On 13 February 2021, Sendtech Pte. Ltd. (the “Organisation”) informed the Personal Data Protection Commission (the “Commission”) of a data breach incident. There was an unauthorized access to the Organisation’s Amazon Web Services (“AWS”) account via an access key (the “Incident”). 2. The Organisation became aware of the Incident on 10 February 2021 when its AWS account was shut down due to unusual account activity. The cause of Incident was a compromised AWS access key. This access key was created in 2015 when the Organisation was developing the backend of its server in its incipient stages. This AWS access key had not been rotated or changed since 2015. The Organisation suspected that the AWS could have been compromised through its former or current employees. First, all former developers had access to this key and some could still have the source code on their computers. Second, as most of the employees are working from home, it is possible that the AWS access key was compromised if the employees had accessed internet through a public WiFi connection. 3. With this compromised AWS access key, the attacker gained admin privileges, created another admin account and queried the buckets storing personal data. As a result, the personal data of 64,196 customers and 3,401 contractors and the contractors’ employees were accessed. There was no evidence of data exfiltration. For the customers, the personal data included the email address, contact number, home address and last four digits of the debit or credit card. For the contractors and their employees, the personal data included profile photo and copies of the NRIC or work permit (front and back). 4. The Organisation took the following remedial measures after the Incident: a. Rotated all access keys; b. Changed passwords for all servers; c. Enhanced its audit trail on AWS buckets to log all read and write operation at the object level; d. Checked and verified that its Github repositories was set to “Private”; e. Engaged cybersecurity consultants to carry out assessment of its security setup and advise on improvements to the security measures; and f. Developed new cybersecurity policies and processes which specifically include measures for credentials management. 5. In its representations to the Commission, the Organisation admitted to having breached the Protection Obligation under section 24 of the Personal Data Protection Act (the “PDPA”), and requested for the matter to be dealt with in accordance with the Commission’s Expedited Decision Procedure. 6. The Organisation admitted it did not have specific AWS policies for the assignment of roles to rotate credentials. There was also a lack of detailed steps to manage credentials access of outgoing staff. Hence, the credentials were not rotated or changed whenever there are staff movement. 7. In the circumstances, the Organisation is found to have breached section 24 of the PDPA. 8. On 23 June 2021, the Organisation was notified of the Commission’s intention to impose a financial penalty of $10,000 based on the Commission’s consideration of the factors listed under section 48J(6) of the PDPA, and the circumstances of this case, in particular (i) the Organisation’s upfront voluntary admission of liability which significantly reduced the time and resources required for investigations; and (ii) the prompt remedial actions undertaken by the Organisation. The Organisation was invited to make representations. Having considered the Organisation’s representations dated 25 June 2021 to reduce the financial penalty payable and to allow the Organisation to pay the financial penalty by way of an instalment plan the Deputy Commissioner hereby directs the Organisation to: a. Pay a financial penalty of $9,000 in 12 instalments by the due dates as set out below, failing which the full outstanding amount shall become due and payable immediately and 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: i. 1st instalment of $750 on 1 September 2021; ii. 2nd instalment of $750 on 1 October 2021; iii. 3rd instalment of $750 on 1 November 2021; iv. 4th instalment of $750 on 1 December 2021; v. 5th instalment of $750 on 1 January 2022; vi. 6th instalment of $750 on 1 February 2022; vii. 7th instalment of $750 on 1 March 2022; viii. 8th instalment of $750 on 1 April 2022; 9. ix. 9th instalment of $750 on 1 May 2022; x. 10th instalment of $750 on 1 June 2022; xi. 11th instalment of $750 on 1 July 2022; and xii. 12th instalment of $750 on 1 August 2022. In view of the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. ",Financial Penalty,cd74c714c427c34a4021513b29355c8019982bf8,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,53,53,1,952,"A financial penalty of $13,500 was imposed on SAP Asia for failing to put in place reasonable security arrangements to protect personal data of its former employees. This resulted in an unauthorised disclosure of the personal data to unintended recipients.","[""Protection"", ""Financial Penalty"", ""Admin and Support Services"", ""Vendor""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---SAP-Asia-Pte-Ltd---310721.pdf,Protection,Breach of the Protection Obligation by SAP Asia,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-sap-asia,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 6 Case No. DP-2004-B6180 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And SAP Asia Pte. Ltd. … Organisation DECISION SAP Asia Pte. Ltd. [2021] SGPDPC 6 Lew Chuen Hong, Commissioner — Case No. DP-2004-B6180 30 July 2021 Introduction 1 On 1 April 2020, the Personal Data Protection Commission (“the Commission”) received a complaint that SAP Asia Pte. Ltd. (“the Organisation”) had disclosed the payroll information of some of its former employees to the wrong email recipients (“the Incident”). The Commission commenced investigations into the Incident thereafter. Facts of the Case 2 At the material time prior to the Incident, the Organisation had engaged an external vendor (“the Vendor”) to provide IT solutions for its human resources and payroll system (“the HR System”). The Organisation’s process of issuing payslips to its employees had been automated as part of the HR System. However, when payslips needed to be issued to individuals who had already left the employment of the Organisation (e.g. final payslips, reimbursements of expenses etc), this could not be done via the HR System. Such payslips needed to be separately generated by the Organisation’s human resources department and emailed to the former employees at their personal email addresses. The Organisation was keen to automate the process of issuing payslips to former employees as part of the HR System, and sometime around April 2019, requested the Vendor to develop a new programme within the HR System for this purpose (“the Programme”). 3 The Organisation had intended to use the Programme to generate and email multiple payslips to multiple former employees simultaneously in one execution of the Programme SAP Asia Pte. Ltd. [2021] SGPDPC 6 (“Multiple Payslip Issuance”). However, as will be discussed below, this intention was not properly communicated to the Vendor, and the Programme was designed on the incorrect understanding that only a single payslip would need to be issued to a single employee at a time (“Single Payslip Issuance”). 4 The Organisation executed the Programme for the first (and only) time on 31 March 2020 to generate and deliver payslips to 43 former employees at their personal email addresses. Believing the Programme to be capable of Multiple Payslip Issuance, the Organisation’s representative selected all 43 former employees to be issued payslips in one selection screen of the Programme and executed the process. As the Programme had not been designed to be able to properly execute Multiple Payslip Issuance, this execution of the Programme resulted in 29 out of the 43 former employees receiving their own payslip as well as the payslips of other employees. By way of illustration: (a) The 1st former employee in the selection received only their own payslip. (b) The 2nd former employee in the selection received their own payslip as well as the payslip of the 1st former employee. (c) The 3rd former employee in the selection received their own payslip as well as the payslips of the 1st and 2nd former employees. 5 13 of the 43 former employees had not provided the Organisation with valid email addresses and did not receive any emails with payslips. However, the payslips of these 13 former employees were still generated and disclosed to the 29 other former employees when the Programme was executed on 31 March 2020. 6 In all, the personal data of 43 former employees of the Organisation was improperly disclosed in the Incident. The disclosed personal data comprised each of the former employees’: 1 SAP Asia Pte. Ltd. [2021] SGPDPC 6 (a) Name; (b) NRIC or FIN number; (c) Employment number; (d) Bank account number; (e) Monthly basic salary; (f) Detailed breakdown of current payment; and (g) Year-To-Date earnings and deductions. Remedial actions 7 Following the Incident, as part of remedial actions, the Organisation: (a) Emailed all 43 former employees on 1 April 2020 informing them about the error and requesting each of them to delete the payslips which were not intended to be emailed to them; (b) Followed up with the former employees over phone to confirm deletion of the other payslips and received confirmation from 39 of the 43 former employees affected; (c) Disabled the Programme and reverted to manually generating and emailing payslips to former employees; and (d) Agreed on continuous process improvements with the Vendor with clear communicated requirements. 2 SAP Asia Pte. Ltd. [2021] SGPDPC 6 Findings and Basis for Determination Whether the Organisation contravened the Protection Obligation 8 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, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). 9 In this case, the Organisation, a data controller, engaged the Vendor to develop a new feature for its IT systems which processed personal data in its possession (i.e. the Programme). The development of the Programme had obvious implications for the way in which the former employees’ personal data would be processed. However, in developing the Programme, the Vendor did not process personal data on behalf of the Organisation and was not the Organisation’s data intermediary in this regard. Accordingly, the Protection Obligation in respect of the former employees’ personal data was borne solely by the Organisation. 10 In the context of the Programme’s development, the Organisation’s responsibilities under the Protection Obligation included ensuring that: (a) The specifications provided to the Vendor accurately reflected the intended use of the IT feature being developed; and (b) Pre-launch testing of the new feature was accurately scoped to simulate the full range of intended use of the new feature. 11 For the reasons set out below, the Organisation failed both of these responsibilities. 3 SAP Asia Pte. Ltd. [2021] SGPDPC 6 Failure to adequately specify requirements for the Programme 12 It is a data controller’s responsibility to ensure that external vendors who are engaged to modify its IT systems know the scope of their work. As stated in (1) Smiling Orchid (S) Pte Ltd; (2) T2 Web Pte Ltd; (3) Cybersite Services Pte Ltd; (4) East Wind Solutions Pte Ltd [2016] SGPDPC 19 at [51]: “ Data controllers that (engage) outsourced service providers have to be clear about the nature and extent of services that the service provider is to provide. There must be a clear meeting of minds as to the services that the service provider has agreed to undertake, and this should be properly documented.” 13 This does not mean that all organisations will be expected to be able to give detailed technical instructions to their IT vendors. As clarified in MDIS Corporation Pte Ltd [2020] SGPDPC 11 at [14]: “While an organisation may not have — or need to have — the requisite level of technical expertise, a responsible organisation would have engaged competent service providers and made genuine attempts to give proper instructions. The Organisation is only expected to articulate its business requirements as owner of the system, which the service provider can translate into technical requirements. In addition, as the data controller, the Organisation is required to exercise reasonable oversight to ensure that its instructions are carried out.” [emphasis added] 14 In previous enforcement decisions, the Commissioner has held organisations in breach of the Protection Obligation for failing to properly communicate business requirements for design changes to IT features: 4 SAP Asia Pte. Ltd. (a) [2021] SGPDPC 6 In Singapore Cricket Association and another [2018] SGPDPC 19, the organisation engaged a vendor to redesign its website, including certain pages featuring profiles of its registered players. The organisation’s requirements were conveyed to the vendor piecemeal - in meetings, through phone calls, and over text messages. As a result, the vendor misunderstood the intended contents for the player profile pages and incorrectly disclosed around 100 players’ personal data including NRIC numbers and contact information as part of the redesigned website. (b) In The Central Depository (Pte) Limited & another [2019] SGPDPC 24, the organisation engaged a vendor to develop software to generate and issue notification letters to its customers. However, the organisation failed to provide the vendor with clear specifications and representative test data that covered the full range of data to be processed and the various processing scenarios. As such, the vendor incorrectly assumed that a particular dataset would always have 4 lines of data to extract for each letter, when in fact, that dataset could have also had 1, 2, or 3 lines of data. This resulted in a design error that caused the inadvertent disclosure of 1,358 customers’ personal data to the wrong recipients when the software was deployed. (c) In Horizon Fast Ferry Pte Ltd [2019] SGPDPC 27, a ferry operator engaged a vendor to redesign its booking website. There was no written contract between the parties, and all instructions and requirements for the redesign were conveyed verbally or over text messages. As a result, the vendor misunderstood the scope of the redesign and incorrectly imported an auto-population feature from one of the organisation’s internal systems to the redesigned website. This caused the booking form on the redesigned website to automatically populate all fields in the form whenever a passport number that matched an entry in the organisation’s passenger database was entered. As a result, the personal data of close to 300,000 of the organisation’s passengers was exposed to the risk of unauthorised access. 5 SAP Asia Pte. Ltd. 15 [2021] SGPDPC 6 In the present case, the Organisation failed to make clear to the Vendor that the Programme was intended to be used for Multiple Payslip Issuance. This resulted in the Vendor designing the Programme under the wrong impression that all that was required by the Organisation was Single Payslip Issuance. 16 The misunderstanding between the Organisation and Vendor was attributable to the Organisation’s instructions in relation to development of the Programme being brief and ambiguous. The Organisation’s instructions to the Vendor were contained in a short service request which read as follows: “HI Team, Can you please enhance the program (…) where by when i key in the employee id, (…) then A template of the email with the payslip is send to the selected employee? Thanks!” [emphasis added] 17 The request only referred to a payslip to be sent to a “selected employee” (i.e. in the singular) and not multiple employees (i.e. plural). 18 This reference to using the Programme for a single employee (as opposed to multiple employees) was repeated by the Organisation when later responding to clarifications sought by the Vendor as to why payslips needed to be sent to external email addresses: “HI (…), The sending of email to private address is necessary as we are require to provide payslip to ex employee when ever there is a payment. This is for employee who have left the organization. Thanks!” 6 SAP Asia Pte. Ltd. 19 [2021] SGPDPC 6 Apart from these communications, there was no other documentation of the Multiple Payslip Issuance requirement. If the Organisation intended to use the Programme to send payslips in a single instance to multiple former employees (i.e. Multiple Payslip Issuance) this should have been clearly communicated as a required specification for the Programme. The Organisation’s failure to properly communicate its business requirements to the Vendor resulted in the Programme being inadvertently designed in an insecure way. Failure to carry out adequate user acceptance testing 20 The Organisation’s failure to specify Multiple Payslip Issuance as a required functionality of the Programme was compounded by its failure to include any Multiple Payslip Issuance scenarios in its user-acceptance testing (“UAT”) for the Programme (i.e. testing carried out prior to deploying the Programme for use as part of the HR System). 21 Pre-launch testing is an important means of identifying data protection risks before new IT features are deployed in a live environment, and this has also been emphasised in the Commission’s recently published handbook, How to Guard Against Common Types of Data Breaches1: “Most organisations fail to recognise that proper testing can help them to identify defects in programming before a system is launched. Sufficient resources should be allocated for testing, and a comprehensive UAT should ensure good test coverage of scenarios including possible user journeys and exception handling. Organisations should also ensure that the planned UAT scenarios match real-world usage. This can be done through a comprehensive gathering of business requirements and identification of relevant usage scenarios by potential users. These should be driven by the business owner.” 1 https://www.pdpc.gov.sg/news-and-events/announcements/2021/05/handbook-on-how-to-guard-againstcommon-types-of-data-breaches-now-available 7 SAP Asia Pte. Ltd. [2021] SGPDPC 6 [emphasis added] 22 In previous enforcement decisions, organisations have been held in breach of the Protection Obligation for failing to properly scope pre-launch testing to simulate real-world use of new IT features: (a) In Option Gift Pte Ltd [2019] SGPDPC 10, the organisation developed a programme to send email confirmations to persons who had made gift redemption requests. The programme was intended to send a single email confirmation to each recipient. However, a coding error meant that while the first email was sent to the first recipient (as intended), the second email was sent to both the first and second recipient and so on (i.e. a similar type of error as in the Incident as described at [4] above). The organisation’s UAT was found to be inadequate as the programme had only been tested by sending confirmation emails to the same internal email address. There was no testing that simulated the intended use of the programme to send emails to multiple recipients. (b) In AIA Singapore Private Limited [2019] SGPDPC 20, the organisation employed an automated system to generate and send different types of letters to its customers. A fix had been deployed to correct an earlier programming error but ended up introducing a further error. When different types of letters were processed in one batch, the further error caused letters to be sent to the wrong recipients. The organisation’s testing prior to deploying the fix had only simulated scenarios in which one letter was generated at a time. However, this did not replicate the real-world use of the system as letters were ordinarily generated and dispatched in batches. (c) In Grabcar Pte Ltd [2020] SGPDPC 14, an update deployed for the organisation’s mobile application inadvertently exposed the personal data of some users to the risk of unauthorised access by other users. The error arose because the effect of the update on a particular caching mechanism had not been detected in testing. This 8 SAP Asia Pte. Ltd. [2021] SGPDPC 6 was partly because the organisation failed to test the update in scenarios where multiple users were accessing the application concurrently (which was a foreseeable real-world scenario). 23 Similar to the above precedents, in the present case, the Organisation’s representative only conducted 2 test scenarios as part of UAT, and both only involved Single Payslip Issuance. The failure to test Multiple Payslip Issuance as part of UAT meant that the testing was inadequate to simulate the Organisation’s intended use of the Programme, and the Programme’s incapability of handling Multiple Payslip Issuance was not picked up at the testing stage as it should have. 24 For the above reasons, the Organisation was determined to have breached the Protection Obligation in respect of the former employees’ personal data disclosed in the Incident. The Commissioner’s Directions 25 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 after being notified of the Incident; and (b) 26 The Organisation was cooperative during the investigations. Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $13,500 within 30 days from the date of 9 SAP Asia Pte. Ltd. [2021] SGPDPC 6 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. 27 No further directions are necessary on account of the remedial measures already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 10 ",Financial Penalty,b1202a44badfb2a4eadf02786aeafab69a9a4136,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,54,54,1,952,"A financial penalty of $8,000 was imposed on Seriously Keto for failing to put in place reasonable security arrangements to protect the personal data stored in its server. This resulted in the data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B"", ""Ransomware"", ""Vendor""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Seriously-Keto-Pte-Ltd---14072021.pdf,Protection,Breach of the Protection Obligation by Seriously Keto,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-seriously-keto,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2006-B6449 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Seriously Keto Pte. Ltd. SUMMARY OF THE DECISION 1. On 16 June 2020, Seriously Keto Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware infection that occurred on or about 15 June 2020 (the “Incident”). The affected personal data comprised approximately 3,073 individuals’ names, addresses, email addresses and telephone numbers (“the Affected Personal Data”). 2. The Organisation requested that the Commission investigate the Incident under its Expedited Decision Procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. It also admitted that it was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act (the “PDPA”). 3. Investigations revealed the presence of an unprotected file in the Organisation’s network infrastructure which contained unencrypted login credentials to access the server containing the Affected Personal Data. The unprotected file could be located by infrastructure scanning, and this provided a channel for unauthorised access to the server. Server logs retrieved by the Organisation after the Incident indicated that there had been unauthorised access to the file. 4. The Organisation admitted that it had failed to conduct any periodic security reviews prior to the Incident which could have revealed the existence of the unprotected file within its network infrastructure. 5. The Organisation had engaged a vendor to develop its e-commerce and membership website and claimed to have relied on the vendor to make the necessary security arrangements to protect the Affected Personal Data. However, in this case, there were no clear business requirements (e.g. contractual stipulations) specifying that the Organisation was relying on the vendor to recommend and/or implement security arrangements to protect personal data hosted in the e-commerce and membership website that the vendor was engaged to develop. Protection of personal data in the possession or under the control lies primarily with the Organisation, although it may contract the operations to a vendor who is more knowledgeable and with expertise. To do so, the Organisation has to be clear about the scope of outsourcing and the vendor has to also agree to do so. In the absence of clear outsourcing, the responsibility to implement reasonable security arrangements to protect the Affected Personal Data remained squarely with the Organisation. 6. Overall, the Organisation admitted that it had failed to give due attention to personal data protection prior to the Incident and had neglected to implement reasonable security arrangements to protect the Affected Personal Data. 7. In the above circumstances, the Deputy Commissioner for Personal Data Protection finds that the Organisation negligently contravened the Protection Obligation under section 24 of the PDPA. 8. Following the Incident, the Organisation underwent a full security audit and remedied vulnerabilities identified. The Organisation also set up a new website with a more robust internal security infrastructure, implemented a mandatory password change for all users of its new website, and activated a firewall to safeguard access to the new website. It also engaged a cybersecurity vendor to develop further measures and policies to strengthen its internal IT infrastructure. Additionally, the Organisation committed to engaging consultants to improve its data protection policies and outsource data protection functions. 9. The Organisation cooperated with the Commission’s investigation, admitted to its breach of the Protection Obligation, and took prompt remedial action. There was no evidence of exfiltration of the Affected Personal Data, and the Organisation was able to restore the Affected Personal Data from a backup and did not lose any data as a result of the Incident. The practice of having regular and separately located data backup(s) is to be encouraged to prevent organisations from losing data to ransomware. 10. Having considered the above circumstances and the factors listed at section 48J(6) of the PDPA, the Deputy Commissioner for Personal Data Protection requires the Organisation to pay a financial penalty of $8,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. 11. In view of the remedial actions taken by the Organisation, no other directions are necessary. ",Financial Penalty,f96a9b453e14796f77b805ed107e916524839f6e,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,55,55,1,952,"A warning was issued to Specialized Asia Pacific for failing to put in place reasonable security arrangements to protect the personal data of 2,445 application users.","[""Protection"", ""Warning"", ""Others"", ""Mobile application""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Specialized-Asia-Pacific-Pte-Ltd---300721.pdf,Protection,Breach of the Protection Obligation by Specialized Asia Pacific,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-specialized-asia-pacific,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2101-B7826 In the matter of an investigation under Section 50(1) of the Personal Data Protection Act 2012 And Specialized Asia Pacific Pte Ltd … Organisation SUMMARY OF THE DECISION 1. On 29 January 2021, Specialized Asia Pacific Pte Ltd. (the “Organisation”) informed the Personal Data Protection Commission of a data security incident involving the Specialized Cadence application (the “Application”) that it developed, operated and maintained. 2. The Organisation’s developing staff did not realize that the online development tool, which was used to develop the Application, had a default privacy setting that made all data created by users or developers “visible”, even though this had been stated in the tool’s privacy rules. This default setting allowed the Application’s network traffic to be intercepted and accessed using third-party security testing software that can be acquired online. A member of the public had therefore been able to intercept and access the personal data of the Application’s users by using a free version of such software (the “Incident”). However, the risk of unauthorised access had been limited to parties who knew how to use such security testing software to obtain access. This factored in the enforcement outcome below (see paragraph 6 below). 3. The undetected default privacy setting of “visible” put the personal data of 2,445 individuals at risk of unauthorised access. The data affected included names, addresses, dates of birth, telephone numbers, email addresses and gender. 4. Remediation by the Organisation encompassed turning off all access and use of the Application by all external parties, including users, and changing the privacy setting from “visible” to “hidden”. The Organisation also engaged a third-party IT security firm to test and address any security and privacy issues relating to the Application, commenced discussions with its IT application designers and employees involved to adopt ‘privacyby-design’ in future applications development. 5. The Protection Obligation in section 24 of the Personal Data Protection Act 2012 requires that organisations understand the privacy policies and security features of all online tools or software they choose to employ. This was established in published cases such as Re GMM Technoworld Pte. Ltd. [2016] SGDPDPC 18. Organisations employing online tools or other online software must set or reconfigure privacy policies and security features to protect the personal data of application or website users. It would not be a discharge of the Protection Obligation for an organisation to simply adopt, vis-à-vis users, the same default privacy policies of online tools or software that do not protect the personal data of users. 6. The Deputy Commissioner for Personal Data Protection therefore found the Organisation in breach of the Protection Obligation under Section 24 of the Personal Data Protection Act 2012. Upon consideration of the facts, including the limited exposure of the affected data to those who knew how to use the above-mentioned third party software to access such information via the default privacy setting, and the Organisation’s commitment to improve its processes, a Warning was issued to the Organisation. ",Warning,bb6b30899dc237cbbb5ca65a53c42a6e8fc69444,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,60,60,1,952,"A financial penalty of $35,000 was imposed on HMI Institute for failing to put in place reasonable security arrangements to protect personal data stored in its server. This resulted in the data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Education"", ""Ransomware"", ""Third Party Vendor"", ""Scope of Duties"", ""Open RDP Port"", ""Remote Desktop Protocol""]",2021-06-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---HMI-Institute-of-Health-Sciences---20052021.pdf,Protection,Breach of the Protection Obligation by HMI Institute of Health Sciences,https://www.pdpc.gov.sg/all-commissions-decisions/2021/06/breach-of-the-protection-obligation-by-hmi-institute-of-health-sciences,2021-06-10,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 4 Cases No DP-1912-B5434 / DP-1912-B5564 / DP-1912-B5558 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And HMI Institute of Health Sciences Pte. Ltd. … Organisation DECISION HMI Institute of Health Sciences Pte. Ltd. [2021] SGPDPC 4 Lew Chuen Hong, Commissioner — Cases No. DP-1912-B5434 / DP-1912-B5564 / DP-1912-B5558 20 May 2021 Introduction 1 On 4 December 2019, a file server (the “Server”) belonging to HMI Institute of Health Sciences Pte. Ltd. (the “Organisation”) was affected by a ransomware attack. The ransomware encrypted and denied access to various files on the Server, including files containing personal data of the Organisation’s staff and trainees (the “Incident”). 2 On 7 December 2019, the Organisation informed the Personal Data Protection Commission (“Commission”) of the Incident. The Commission subsequently received two separate complaints about the Incident. Background 3 The Organisation is a dedicated private provider of healthcare training to individuals (“Participants”) in Singapore. In the course of carrying out its business activities, the Organisation collects personal data from, among others, (i) its employees, including temporary and contract staff such as associate trainers, (“Employees”) for the purposes of managing or terminating such employment relationships, and (ii) the Participants, for the purposes of registration and the administration of their enrolment in the Organisation’s training courses. 4 The Server affected by ransomware was set up in 2014 and was located in Singapore. It was owned by the Organisation but maintained by the Organisation’s appointed IT solution service provider (the “Vendor”). The Server stored personal data in Microsoft Word or Excel files, most but not all of which were password-protected. 5 The Server was protected by a firewall that blocked all connections to the Server, except for those through port 3389, a standard port which was used for the Remote Desktop Protocol (“RDP Port”). The RDP Port was used by the Vendor for 1 remote management and/or troubleshooting purposes. According to the Organisation, the RDP Port was kept open from sometime in 2014 up to the date of the Incident on 4 December 2019 (i.e. for more than four (4) years) to allow the Vendor quick and easy access. The significance of the RDP Port being kept open will be elaborated on below. 6 The Server only had one administrator account which was shared by the Organisation’s IT administrator and at least three other employees of the Vendor. By use of this administrator account, the Vendor could access the Server remotely through the RDP Port and view, change, or delete all the data in the Server. 7 On 4 December 2019, an employee of the Organisation was unable to access files on the Server containing the personal data of some Participants. An initial diagnostic conducted by the Vendor revealed that the Server had been affected by ransomware. File extensions of the files on the Server had been changed and a ransom note was found on the Server. 8 On 5 December 2019, the Organisation engaged a cybersecurity expert company (“CSE”) to conduct a thorough assessment of the Incident. The CSE found that: (a) the attacker had likely discovered the open RDP Port following a random, opportunistic search for vulnerabilities; and; (b) having discovered the open RDP Port, it was likely that the attacker used brute force attacks to obtain the administrator account password for the Server in order to gain access to the Server and execute the ransomware. 9 In total, the personal data of approximately 110,080 Participants, and 253 Employees were affected by the Incident (the “Affected Personal Data”). 10 For the affected Participants, the following categories of personal data were affected: (a) Name; 2 11 (b) NRIC number; (c) Address; (d) Race; (e) Gender; (f) Date of Birth; (g) Age; (h) Email address; (i) Contact number; (j) Course details; (k) Nationality; and (l) Employer details and past employment history. For the affected Employees, the following categories of personal data were affected: (a) Name; (b) NRIC number; (c) Date of Birth; (d) Nationality; (e) Citizenship; (f) Age; (g) Contact number; (h) Vehicle licence plate; and 3 (i) Financial Information (including salary/payment information, Central Provident Fund (“CPF”) information, and bank account numbers. 12 Not all of the above categories of personal data were affected in every individual’s case. For instance, the bulk of the affected Participants (approximately 98,000) only had their names and NRIC numbers stored on the Server. 13 The CSE’s investigation found no evidence of any exfiltration of the Affected Personal Data from the Server. The Organisation also managed to retrieve all the Affected Personal Data as most of the affected files were back-up files. 14 Upon being made aware of the Incident, the Organisation took prompt remedial actions. The Organisation: (a) Decommissioned the Server (without paying the ransom), and isolated the Server from its network and the Internet; (b) Notified the Commission, SingCERT, and all the affected Employees and Participants that it was able to (approximately 95%) of the Incident; and (c) 15 Issued a media advisory on the Incident. The Organisation also carried out actions to prevent a recurrence of the Incident. It: (a) Adopted its own internal password management policy; (b) Permanently disconnected and blocked remote access for IT support procedures; (c) Implemented Internet separation measures for all devices containing personal data; (d) Introduced various endpoint enhancements and gateway security measures including a monitoring system for all Internet-facing traffic, a suite of antivirus and malware protection for all computers and enhancing email hosting security protection and hard disk encryption; 4 (e) Engaged external IT security consultants to establish an Information Security Management Framework based on the ISO 27001 certification; (f) Conducted cybersecurity training sessions and cybersecurity awareness workshops for its staff; (g) Conducted ad-hoc email phishing tests to augment the cybersecurity training sessions and to engender greater awareness and vigilance towards suspicious emails; and (h) Put in place a monthly IT bulletin post to all employees to keep all staff up to date on IT and cybersecurity issues. Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 16 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (“Protection Obligation”). 17 As a preliminary point, even though the Organisation had engaged the Vendor to maintain the Server and the Organisation’s other IT infrastructure, the scope of the Vendor’s engagement did not involve the processing or handling of any personal data on behalf of the Organisation. The Organisation owned the Server and was in possession and control of the Affected Personal Data at all material times. The Vendor was therefore not a data intermediary and the responsibility to protect the Affected Personal Data fell squarely on the Organisation. 18 For the reasons set out below, the Organisation failed to implement reasonable security arrangements to protect the Affected Personal Data from the risk of authorised access, modification and disposal. 5 Failure to adequately regulate remote access to the Server 19 First, the Organisation did not have sufficiently robust processes to ensure safe remote access to the Server via the RDP Port. The Remote Desktop Protocol (i.e., RDP) is a proprietary protocol developed by Microsoft Corporation for use in its Remote Desktop Connection application, which allows for remote connections to be established from one computer (i.e., a server) to another computer (i.e., the client) allowing the client to remotely control the server. By default, the server uses port number 3389 (i.e., the RDP Port) for incoming connections and requires authentication in the form of a username and password, before access to the server is granted. While the RDP Port is intended to be used for legitimate RDP client-server connections, its existence is well known and thus susceptible to be exploited by malicious actors to gain unauthorised access to a server if there are weak protective measures in place (e.g. weak user authentication). 20 While there is no strict requirement that the RDP Port must always be closed, organisations should regularly review and assess the potential risks of keeping such public facing ports open. Where it is necessary to keep the RDP Port on a server open, organisations should ensure that there are sufficient measures in place to protect the personal data stored on the server. 21 That said, where an organisation holds a high volume of personal data and/or highly sensitive personal data, the Commission is of the view that the default approach should be to close all ports, including RDP Ports. Where it is necessary to open the RDP Port, organisations must ensure that there are sufficient measures in place to ensure the security and legitimacy of any incoming RDP connection, and to promptly close the RDP Port upon completion of the required use. Additional measures to secure the files, for example, access control to folders and file encryption, may also be deployed. These are different layers of defences that can be used cumulatively or in different combination, depending on the volume and sensitivity of personal data and the requirements of business operations. 22 In this case, the Organisation kept the RDP Port open from the time the Server was set up in 2014 until the occurrence of the Incident on 4 December 2019. According 6 to the Organisation, the RDP Port was kept open to allow the Vendor quick remote access to the Server for recovery and maintenance works. The Organisation claimed that keeping the RDP Port permanently closed was not practicable, as half a day of down time would be required whenever the RDP Port needed to be opened or closed. 23 Given the fact that a minority of records (i.e. 253 Employees) contained more sensitive financial information and bank account numbers, as well as the volume of personal data stored on the Server, it is questionable whether the RDP Port should have been kept open permanently for recovery or maintenance work. Even if this meant incurring some down time in activating and deactivating the firewall for the RDP Port, the inconvenience associated with this down time should have been measured against the risk to the type and volume of personal data that was stored on the Server. Nonetheless, the benefit of doubt is given to the Organisation as the majority of records were personal particulars and contact information. 24 Even if it was necessary for the RDP Port to be kept open, the Organisation should at least have put in place other types of technical measures to secure the RDP access, such as: (a) Using a different port (other than the default port 3389) for RDP connections; (b) Restricting access to specific IP addresses or IP addresses within specified ranges, i.e. “whitelisting”; (c) using a RDP gateway; and/or (d) Conducting log reviews for unusual activity, whether upon automated alerts or scheduled monitoring. 25 The risks arising from poor management of RDP Ports have also been highlighted in the Cyber Security Agency of Singapore’s (“CSA”) recent advisory dated 28 December 2020, titled “Protect Your Systems and Data From Ransomware Attacks” 1 . The CSA similarly cautioned that some ransomware variants take 1 https://www.csa.gov.sg/singcert/advisories/ad-2020-006 7 advantage of exposed services and open ports such as the RDP Port to spread across a network. As such, in order to minimise the chance of a ransomware attack, the CSA emphasised that organisations should review their port settings, particularly, to assess whether there was a need to leave the RDP Port exposed, and if so, to restrict RDP connections to only trusted hosts. 26 The Organisation represented to the Commission that it would have been impractical to whitelist specific IP addresses as connections to the Server were generally made through dynamic, instead of static, IP addresses. Even so, the onus remained on the Organisation to put in place alternative security measures that were commensurate with the standard of protection required to protect sensitive data stored on the Server. However, the Organisation failed to implement any such alternative security measures. 27 The Organisation’s inaction on this front placed the Server at risk for more than four years - from the time the Server was set up in 2014 until it was disconnected from the Internet after the Incident. Failure to implement proper password management 28 Second, the Organisation failed to implement proper password management policies. The Organisation had adopted and generally directed its staff to follow the password policy of one of its affiliates (the “Password Policy”). The guidelines and standards in the Password Policy are consistent with the Commission’s recommendations in its Guide to Securing Personal Data in Electronic Medium2, which recommends that passwords used for authentication have a length of at least 8 characters, containing at least one alphabetical character and one numeric character. 29 However, the Organisation failed to take steps to ensure that the Password Policy was compiled with in practice. None of the passwords used by the Organisation for the administrator account of the Server or the files containing the Affected Personal Data (including those containing financial information) met the Password Policy’s recommended complexity rules. The passwords used by the Organisation also 2 https://www.pdpc.gov.sg/help-and-resources/2017/10/guide-to-securing-personal-data-in-electronic-medium 8 incorporated an acronym of the organisation’s name, which made them easy to guess and vulnerable to brute force attacks. 30 As noted in Re Chizzle Pte Ltd [2020] SGPDPCR 1 at [5(d)]: “In this regard, various articles/guides have stated that the use of an organisation’s name as a component of the password is not recommended because it is not difficult to guess and cracked by hackers. The digits “2018” as a component of the password was also guessable, for example, through brute force or dictionary attacks. As such, the password used by the Organisation failed to prevent unauthorised copying and deletion of the Chizzle Database.” [Emphasis added] 31 The login credentials for the administrator account on the Server were also shared between one administrator in the Organisation and at least three other individuals in the Vendor. Other than the login credentials, there were no other access controls to the administrator account (e.g. 2FA or anti-hammering features). As previously stated in Re Orchard Turn Developments Pte Ltd [2017] SGPDPC 12 (at [31]) user accounts should generally not be shared between different individuals, and all the more so for administrator accounts: “Additionally, there should not be a sharing of credentials amongst users. When credentials are shared among multiple users, it is difficult to ensure accountability as it is difficult to track the activity of each individual using the common set of credentials.” [Emphasis added] 32 Although the sharing of the administrator account credentials was not a direct contributing factor to the Incident, the sharing of account credentials – in particular, administrator accounts with high privileges – created an additional risk factor which could have diminished the robustness of other security measures put in place by the Organisation. 9 33 Similarly, while strong passwords may only slow but not entirely deter threat actors, the absence of strong passwords could greatly facilitate unauthorised access to IT systems, including IT systems holding personal data. Failure to take reasonable steps to ensure that the Vendor would protect personal data 34 Thirdly, while the Organisation claims to have relied on the Vendor’s technical expertise with regard to the security of the Server, the Organisation did not take reasonable or sufficient steps to stipulate clear requirements of its Vendor to ensure that the Vendor understood its role in the protection of the personal data in the Server. 35 As mentioned in the Commission’s Guide to Managing Data Intermediaries3: “The primary means by which a DC (i.e. a Data Controller) may ensure appropriate protection and retention of the personal data processed by its DI (i.e. a Data Intermediary) is through a contract. As the range of data processing activities that can potentially be outsourced is very broad, it is necessary for the scope of outsourced data processing activities to be clearly defined and agreed upon. There should be clear communication between the DC and the DI on the scope of outsourced data processing activities and the personal data requirements. For the DC, this is crucial in ensuring that its business requirements and management decisions in relation to the outsourcing are made clear to the DI.” 36 The Vendor in this case was not a Data Intermediary. However, the Vendor was nevertheless expected to handle personal data in the course of its work or make decisions which affected the security of personal data stored in the Server 4. As such, in order for the Organisation to say that it had discharged its Protection Obligation by relying on the Vendor’s technical expertise, clear business requirements on the protection of the data in the Server should have been specified. Alternatively, the Vendor could have made recommendations on the data protection requirements based on its understanding of the engagement (including for protection of the data in the Server), which the Organisation could have approved and adopted. In either case, 3 4 https://www.pdpc.gov.sg/Help-and-Resources/2020/09/Guide-to-Managing-Data-Intermediaries See Civil Service Club [2020] SGPDPC 15 at [13] and [14] 10 reasonable efforts should have been taken by the Organisation to verify that the Vendor was meeting its data protection requirements. 37 The exact requirements for a given case would depend on the services that a vendor is engaged to provide. If a vendor is engaged to put in place protection features for a Data Controller’s IT systems, the business requirements should describe the risks that the vendor is to address. In this case, the Organisation’s contract with the Vendor did not specify any business requirements for the protection of personal data in the Server. Neither could the Organisation provide any evidence to suggest that the Vendor made any recommendations about how to protect the data in the Server. As such, the Organisation could not say that it had discharged its Protection Obligation by relying on the expertise of the Vendor. 38 In the circumstances, the Commissioner finds that the Organisation failed to make reasonable security arrangements to protect the personal data in the Server from the risk of unauthorised access, modification and disposal. Accordingly, the Commissioner finds the Organisation in breach of its obligation under section 24 of the PDPA. The Commissioner’s Directions 39 In determining whether any directions should be imposed on the Organisation under section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA and the following aggravating and mitigating factors were taken into account: Aggravating Factor (a) the Organisation’s failure to put in place reasonable security measures put the personal data in the Organisation’s possession and/or control at risk of exposure for more than four years. The failure to protect led to the unauthorised access and modification of the personal data in the Incident; 11 Mitigating Factors (b) the Organisation took prompt remedial actions following the Incident; and (c) 40 the Organisation was cooperative during the investigations. Having considered all the relevant factors of this case, including representations made by the Organisation on 1 April 2021 after being notified of the Commissioner’s Preliminary Decision, the Commissioner hereby directs the Organisation to pay a financial penalty of $35,000 within 30 days from the date of the relevant notice, 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. 41 In view of the remedial actions that have already been taken by the Organisation, no other directions are necessary. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 12 ",Financial Penalty,65d2d1e1ed47bb4f1dba6c7af5b321b1ae19c7c3,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,61,61,1,952,"A financial penalty of $8,000 was imposed on ST Logistics for failing to put in place reasonable security arrangements to prevent the unauthorised access of 2,400 MINDEF and SAF personnel's personal data.","[""Protection"", ""Financial Penalty"", ""Transport and Storage"", ""Phishing"", ""Malware""]",2021-06-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---ST-Logistics-Pte-Ltd---26102020.pdf,Protection,Breach of the Protection Obligation by ST Logistics,https://www.pdpc.gov.sg/all-commissions-decisions/2021/06/breach-of-the-protection-obligation-by-st-logistics,2021-06-10,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 19 Case Nos. DP-1912-B5514 and DP-1912-B5559 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And ST Logistics Pte Ltd … Organisation DECISION ST Logistics Pte Ltd [2020] SGPDPC 19 Lew Chuen Hong, Commissioner — Case Nos. DP-1912-B5514 and DP1912-B5559 26 October 2020 Introduction 1 Phishing attacks are increasingly prevalent and are one of the top cybersecurity threats faced by organisations1. In its latest report, the Cyber Security Agency of Singapore reported 47,500 cases of phishing in Singapore last year, almost triple the number of cases in 20182. This case is yet another example of an organisation falling victim to phishing. 2 On 16 December 2019, ST Logistics Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that the Organisation had detected an Emoted malware (“Emotet”) in their network which had infected 6 of its users’ laptops (including 4 laptops containing personal data), potentially affecting up to 4,000 individuals in the Ministry of 1 Phishing is a method employed by cyber criminals, often disguising themselves as legitimate individuals or reputable organisations, to fraudulently obtain personal data and other sensitive or confidential information. Once cyber criminals obtain an individual’s personal data, they may gain access to the individual’s online accounts and may impersonate the individual to scam persons known to the individual. See Cyber Security Agency of Singapore, Cyber Tip – Spot Signs of Phishing (25 February 2020) https://www.csa.gov.sg/gosafeonline/go-safe-forme/homeinternetusers/spot-signs-of-phishing. 2 See “Phishing attacks last year tripled from 2018”, The Straits Times, 27 June 2020. ST Logistics Pte Ltd [2020] SGPDPC 19 Defence (“MINDEF”) and Singapore Armed Forces (“SAF”) (the “Incident”). Subsequently, on 23 December 2019, the Commission received a complaint from an individual affected by the Incident. Facts of the Case 3 The Organisation provides logistical services to Singapore’s government and defence sectors, as well as commercial sectors. It has more than 800 employees worldwide and an annual revenue of approximately S$350 million3. 4 On 2 October 2019, the Organisation’s users received phishing emails from email addresses with the text “Stlogs” in the sender name field (e.g. “Account Executive (Stlogs)” and “Assistant General Manager (Stlogs)”). Each email contained an attachment with the file extension “doc”. A total of 13 users from the Organisation opened the malicious attachment (the “Affected Users”). 7 Affected Users had the Palo Alto Traps software (“Traps Software”), an advanced endpoint protection solution, installed in their laptops and were therefore protected from Emotet. The remaining 6 Affected Users (“Infected Users”) did not have Traps Software installed in their laptops. This resulted in the Incident with Emotet being installed and executed on the laptops of the Infected Users. Emotet subsequently harvested the emails in the Infected Users’ accounts, created approximately 100 new phishing emails, and sent these new phishing emails on 3 October 2019. Those new phishing emails quoted the bodies of real emails in the email accounts of the Infected Users. 5 Unencrypted files containing personal data were stored in 4 of the Infected Users’ laptops. The files were offline working copy files used in relation to the logistics services provided by the Organisation to the MINDEF 3 . 2 ST Logistics Pte Ltd [2020] SGPDPC 19 and SAF. The working files contained personal data relating to a total of 2,400 MINDEF and SAF personnel (“Affected Individuals”). The types of personal data of the Affected Individuals at risk of unauthorised access (collectively, the “Disclosed Data”) were: (a) Names; (b) Mailing addresses; (c) Email addresses; (d) Telephone numbers; and (e) NRIC numbers (1,320 full NRIC numbers and 1,080 masked (last 3 digits and checksum) NRIC numbers). 6 Based on the Organisation’s investigations (including anti-virus scans performed following the Incident), the infection by Emotet was limited to the laptops of the Infected Users. At the time of the Incident, the Organisation’s proxy logs captured information which showed that some exfiltration had taken place. However, there was insufficient information in the proxy logs to confirm that the exfiltration included files containing the Disclosed Data. 7 Upon discovery of the Incident, the following remedial actions were taken to mitigate the effects of the Incident: (a) The Organisation immediately disconnected the Infected Users laptops from the Organisation’s corporate network; (b) Security advisories (including guidelines on how to identify phishing emails) were sent to all the Organisation’s users to inform them of the Incident and to be vigilant; and 3 ST Logistics Pte Ltd (c) [2020] SGPDPC 19 All Affected Individuals were notified by MINDEF through text messages by 27 December 2019. 8 In addition, the following remedial actions have been taken, or are committed to be taken, by the Organisation to prevent recurrence of the Incident or similar incidents. (a) The Organisation conducted a “PDPA awareness” programme in February 2020 for its staff. “PDPA awareness” training materials were made available to all staff on the Organisation’s intranet. Selected users also attended the PDPA training offered by NTUC Learning Hub in February 2020; (b) Malicious email domains were identified. Enhanced firewall protection was implemented to inspect traffic to the Organisation’s email gateway. Email rules were created to block similar phishing emails from reaching the Organisation’s users; (c) The Organisation performed a company-wide validation exercise to ensure that Traps Software was installed on the laptops of all its users; (d) The Organisation conducted a Sender Policy Framework verification to reduce the number of spam and phishing emails reaching its users; (e) The Organisation implemented the display of warning banners for emails that do not originate from the Organisation’s email server; (f) The Organisation will increase the frequency of sending “Cybersecurity Advisory & Personal Data Protection Awareness” notices to all users; 4 ST Logistics Pte Ltd (g) [2020] SGPDPC 19 The Organisation implemented internet separation via URL filtering and has been exploring a sandbox feature and URL checking for all emails; (h) Periodic phishing exercises will be conducted as part of the Organisation’s Cybersecurity Awareness Program; and (i) Independent security experts will be engaged to perform compromise assessment to validate the security status of the Organisation’s systems environment in the third quarter of 2020. The Commissioner’s Findings and Basis for Determination 9 Most phishing attacks are sent by email,4 and the most common form is the general, mass-mailed type, where the cyber attacker sends an email pretending to be someone else and tries to trick the email recipient to log into a website or download malware.5 Based on the Commission’s past investigations, there are generally 2 scenarios when a data breach involves phishing attacks on e-mail accounts: (a) First, where malware harvests email addresses from the victim’s email address book to send further phishing emails to contacts of the victim. In this scenario, the only personal data that are accessed and used by the malicious actor are email addresses; and 4 https://www.cisco.com/c/en_sg/products/security/email-security/what-is-phishing.html; See also National Cyber Security Centre (United Kingdom), Phishing attacks: defending your organisation (version 1.1, 8 August 2019) https://www.ncsc.gov.uk/guidance/phishing: Phishing can be conducted via a text message, social media, or by phone, but the term 'phishing' is mainly used to describe attacks that arrive by email. 5 https://www.csoonline.com/article/3234716/types-of-phishing-attacks-and-how-to-identify- them.html 5 ST Logistics Pte Ltd (b) [2020] SGPDPC 19 Second, where the content of the victim’s email account is compromised, and emails are downloaded and/or forwarded by malicious actors. In this scenario, there may be personal data within the body of the email message (e.g. customer information, employee human resource data, payroll information etc.) as part of its communication content. Some of these may be confidential or commercially sensitive information. 10 The first type of email phishing attack at [9(a)] is more common, and the risk of harm is relatively low as the unauthorised access and use is limited to email addresses. Conversely, while the second type of email phishing attack at [9(b)] is less common, the risk of harm is significantly greater. This is because in addition to email addresses, communication content exposed to unauthorised access and use may contain other type(s) of personal data (including those of a sensitive nature, e.g. medical and financial data). Consequentially, a breach of data protection obligations resulting in the organisation falling victim to the second type of email phishing attack generally results in more serious consequences. 11 The present case falls into the first type of email phishing attack, and the issue for determination is whether the Organisation had complied with its obligations under Section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 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 or similar risks (the “Protection Obligation”). 12 As a preliminary point, it is not disputed that the Organisation was in possession and control of the Disclosed Data at all material times, and was obliged to put in place reasonable security arrangements to protect the Disclosed Data. 6 ST Logistics Pte Ltd 13 [2020] SGPDPC 19 The Commission’s investigations revealed that the Organisation failed to conduct periodic security reviews to detect vulnerabilities in its IT systems. (a) As stated in the Commission’s previous decisions, organisations are expected to conduct periodic security reviews of its IT systems.6 Conducting regular information and communication technology (“ICT”) security audits, scans and tests to detect vulnerabilities help organisations to ensure that ICT security controls developed and configured for the protection of personal data are properly implemented7. The comprehensiveness of such security reviews should be scoped based on the organisation’s assessment of its data protection needs, and be conducted to a reasonable standard; (b) In the present case, a reasonably conducted security review should have included (i) verifying complete installation and proper configuration of the security software on all of the Organisation’s users’ laptops; and (ii) checking that the security software is updated; (c) The Organisation’s failure to conduct a security review to a reasonable standard resulted in the following undetected security gaps that led to the Incident8: (i) The anti-virus software installed on users’ laptops was not updated because they had not been properly configured to receive updates. This security gap affected all of the Infected Users, whose laptops were not so configured. The investigations 6 See Re WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 at [18], Re Bud Cosmetics [2019] SGPDPC 1 at [24] and Re Chizzle Pte. Ltd. [2019] SGPDPC 44 at [6] to [8]. 7 Commission’s Guide to Securing Personal Data in Electronic Medium (revised 20 January 2017) at [6.1]. 8 As an updated anti-virus software and Traps Software both offered protection against Emotet, the Organisation could have chosen to take a phased approach to its security review. 7 ST Logistics Pte Ltd [2020] SGPDPC 19 into the Incident revealed that if anti-virus software had been updated, it would have been able to block and remove Emotet at the material time; and (ii) Due to a rollout gap, the Traps Software was not installed on the laptops of some Organisation’s users. In contrast with signature-based anti-virus software (which is used to identify “known” malware), Traps Software detects malware based on their behaviour. This enables Traps Software to detect newly released forms of malware (which signature-based anti-virus software may potentially fail to detect) based on behavioural analysis. As mentioned at [4], this security gap affected all of the Infected Users, on whose laptops the Traps Software had not been installed. Conversely, the laptops of the remaining 7 Affected Users (who had also opened the malicious attachment) had Traps Software installed, and were accordingly protected from Emotet. 14 Based on the Commission’s preliminary findings, it appeared that the Organisation also did not conduct proper data protection training for its staff. In particular, the Organisation had conceded during investigations that not all the Affected Users had completed the relevant data protection training at the time the Incident occurred. The failure to conduct proper data protection training would have been an additional ground (other than the omission to conduct periodic security reviews to detect vulnerabilities in the IT system) in support of finding the Organisation in breach of the Protection Obligation. 15 However, the Organisation subsequently clarified in its representations to the Commission’s preliminary findings that its data protection training for its staff prior to the Incident included PDPA awareness programmes conducted in March and April 2019 and bi-monthly staff induction programmes covering 8 ST Logistics Pte Ltd [2020] SGPDPC 19 cybersecurity and PDPA compliance. In addition, the training material for the PDPA awareness programme, as well as relevant reference materials and the URL link to the Commission’s website were provided in the Organisation’s intranet to allow staff ready access to data protection related resources. 16 The Commission recognises that staff movement will always have to be factored into staff training programmes, and at any one point in time, there will always be members of staff at different stages of training. Having a training programme in place and a system to track staff training is therefore important. Thus, while not all the Affected Users had completed the relevant data protection training at the time of the Incident, the arrangements the Organisation had implemented towards trainings its staff on data protection was reasonable in the circumstances. 17 For the reasons set out at [13] above, the Commissioner finds the Organisation in breach of section 24 of the PDPA. 18 In addition to the representations made on data protection training, the Organisation also raised the following factors for consideration in support of a reduction in the quantum of financial penalty which the Commissioner intended to impose: (a) The Organisation had put in place reasonable security arrangements to protect the Disclosed Data prior to the Incident. These included advanced end point solution (Palo Alto Traps) on corporate servers and workstations; privileged access management; monitoring of security events through security information and events management systems; and web penetration test performed for corporate applications by CREST accredited vendor. Notwithstanding these arrangements, the Organisation was a victim of a phishing attack; and 9 ST Logistics Pte Ltd (b) [2020] SGPDPC 19 There was a low risk of harm arising from the Incident as the unauthorised access and use of the Disclosed Data by the cyber attacker were limited to email addresses. There was also no evidence that any Disclosed Data had been exfiltrated. 19 The Organisation’s representations that it had put in place reasonable security arrangements to protect the Disclosed Data prior to the Incident is not accepted. As explained at [13], the Organisation failed to conduct periodic security reviews to detect vulnerabilities in its IT systems. The requirement for organisations to conduct periodic security reviews to comply has been emphasised in the Commission’s previous decisions.9 Separately, the Organisation’s representation that there was a low risk of harm arising from the Incident is accepted and has been taken into account in determining the financial penalty. 20 Having carefully considered the representations, the Commissioner has decided to reduce the financial penalty to the amount set out at [22]. The quantum of financial penalty has been determined after due consideration of the low risk of harm arising from the Incident and the mitigating factors set out at [21]. The Commissioner’s Directions 21 In determining the directions, if any, to be imposed on the Organisation under Section 29 of the PDPA, the Commissioner took into account the Organisation’s cooperation with the investigations and its prompt and forthcoming responses to the Commission’s queries. 9 See cases listed at Footnote 6. 10 ST Logistics Pte Ltd 22 [2020] SGPDPC 19 Having considered all the relevant factors of this case, the Commissioner directs the Organisation to pay a financial penalty of S$8,000 within 30 days from the date of this direction, 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 the financial penalty until it is paid in full. The Commissioner has not set out any further directions given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 11 ",Financial Penalty,50724d913acafbfd43b21653cd18c545ba471871,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,64,64,1,952,"A warning was issued to Flying Cape, a data intermediary, for failing to put in place reasonable security arrangements to protect the personal data of 191 users of a website. Flying Cape was managing the website on behalf of its client.","[""Protection"", ""Warning"", ""Information and Communications"", ""Ransomware"", ""Data Intermediary"", ""Online Storage Bucket""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Flying-Cape-Pte-Ltd---17032021.pdf,Protection,Breach of the Protection Obligation by Flying Cape,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-obligation-by-flying-cape,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2011-B7385 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Flying Cape Pte Ltd (2) ACCA Singapore Pte Ltd SUMMARY OF THE DECISION 1. Sometime between 25 September 2020 to 5 October 2020, the personal data of 191 users (the “Affected Individuals”) of www.accapdhub.com (the “Website”) was exfiltrated by an unauthorised party (the “Incident”).The exfiltrated personal data comprised of the names, email addresses and contact numbers of the Affected Individuals (“the Exfiltrated Data”). 2. The Website was owned by ACCA Singapore Pte Ltd (“ACCA”), but hosted, managed, and operated by Flying Cape Pte Ltd (“FCPL”) as ACCA’s data intermediary. FCPL notified the Personal Data Protection Commission (the “Commission”) of the Incident on 12 November 2020, after having received a ransom demand in respect of the Exfiltrated Data. 3. Sometime in early September 2020, as part of its management of the Website, FCPL extracted the personal data of the Affected Individuals from the database of the Website into an excel file. An FCPL employee who was assigned to work with the excel file failed to protect the file with a password or encrypt it as required by FCPL’s IT policy. Moreover, the employee incorrectly stored the excel file in a publicly accessible online storage bucket, as opposed to the correct, secured storage bucket. These lapses were believed to have led to the Incident. 4. Pursuant to section 53(1) of the PDPA, FCPL is liable for acts done by employees. The question therefore becomes whether FCPL had taken reasonable steps to prevent or detect mistakes such as the one made by the employee. The investigations did not surface any arrangements to supervise or verify its employees’ compliance with its internal policies or detect non-compliance. The Deputy Commissioner for Personal Data Protection therefore found that FCPL had breached the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”) in respect of the Exfiltrated Data. 5. As the data controller and owner of the Website, ACCA owed the Protection Obligation in respect of the Exfiltrated Data as well. The Deputy Commissioner is satisfied that ACCA discharged this obligation by (i) carrying out a due diligence assessment of FCPL’s data protection policies and practices before their engagement, and (ii) by stipulating data protection requirements in its contract when engaging with FCPL. 6. Taking into account the circumstances of the case, and in particular the factors below, the Deputy Commissioner for Personal Data Protection found ACCA not in breach of the PDPA and decided to issue a Warning to FCPL: a. The number of the Affected Individuals was low; b. The Exfiltrated Data was of a low sensitivity; c. FCPL took immediate remedial actions to prevent the occurrence of a similar incident; and d. FCPL voluntary notified the Commission of the Incident. 7. In view of the remedial actions taken by FCPL, no directions were issued. ",Warning,816c141c71713a45a7d40c205c4815198b33af42,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,65,65,1,952,A warning was issued to St. Joseph's Institution International for failing to put in place reasonable security arrangements to protect the personal data in its possession. The incident resulted in the personal data being at risk of unauthorised access.,"[""Protection"", ""Warning"", ""Education"", ""Google Chrome Extension"", ""Virus""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--St-Josephs-Institution-International-Ltd--12032021.pdf,Protection,Breach of the Protection Obligation by St. Joseph's Institution International,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-obligation-by-st-josephs-institution-international,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2010-B7196 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And St. Joseph’s Institution International Ltd. SUMMARY OF THE DECISION 1. On 16 October 2020, St Joseph’s Institution International Ltd. (the “Organisation”) informed the Personal Data Protection Commission that a file listing the personal data of 3155 parents and students (“the File”) was found on a website called VirusTotal (the “Incident”). 2. The Incident occurred on or around 13 October 2020 when a staff of the Organisation downloaded and deployed a Google Chrome browser extension developed by VirusTotal for additional security scanning. Unknown to the staff, apart from security scanning, the extension also forwarded scanned samples to premium members of VirusTotal (the “3rd Parties”) for security analysis and research. This use of samples was made known in VirusTotal’s privacy policy covering the use of the extension. 3. As a result of the Incident, the personal data of 3155 individuals including both parents and students were put at risk of unauthorised access. The personal data affected included the names of parents and students, parents’ email addresses, students’ date of birth, students’ classes, students’ year and grades. 4. Users of the VirusTotal Chrome extension would have to agree to VirusTotal’s Privacy Policy, which provides that once files are uploaded to the VirusTotal website for scanning, copies of these files will be kept by VirusTotal and shared with their subscribers for research purposes. The risk of such file sharing and in turn disclosure of personal data to 3rd Parties ought to have been known to the said staff of the Organisation, but was overlooked due to oversight. Such oversight could have been prevented if the Organisation had sufficiently robust processes for assessing such risks prior to deploying downloaded software, including Chrome Extensions. However, the Organisation lacked such processes. 5. Nevertheless, the Organisation took prompt action to mitigate the effects of the breach by contacting VirusTotal immediately to remove the File and notified all affected individuals. While personal data was disclosed, it was limited to premium members of VirusTotal for research purposes only. 6. On the facts, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. However, in consideration of the limited risk of personal data being disclosed, and the Organisation’s commitment to improve its processes, a Warning was issued to the Organisation. 7. The Commission reminds all organisations that they must have sufficiently robust processes to obtain a functional understanding of software to be deployed, in order to assess the security risks to personal data in their possession or control. Failure to do so would be breach of the Protection Obligation. ",Warning,8c090a898191be97b97f6c86d047026a0a44edff,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,67,67,1,952,"A financial penalty of $29,000 was imposed on Tripartite Alliance for failing to put in place reasonable security arrangements to prevent the unauthorised access of approximately 20,000 individuals’ and companies’ data stored in its customer relationship system database.","[""Protection"", ""Financial Penalty"", ""Social Service"", ""Ransomware"", ""Scope of Duties"", ""Third Party Vendor""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Tripartite-Alliance-Limited---16032021.pdf,Protection,Breach of the Protection Obligation by Tripartite Alliance,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-obligation-by-tripartite-alliance,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2003-B6000 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Tripartite Alliance Limited SUMMARY OF THE DECISION 1. On 3 March 2020, Tripartite Alliance Limited (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that a server hosting its customer relationship management (“CRM”) system was infected with ransomware on or around 17 February 2020. 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. It also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). The Incident 3. The Organisation is in the business of promoting fair and progressive employment practices, as well as providing mediation and advice in employment–related disputes. 1 4. The CRM system is a Software-as-a-Service (“SaaS”) solution provided by a software service provider engaged by the Organisation (the “Vendor”). The Organisation uses the CRM system to handle employment-related enquiries, feedback and complaints. 5. At the time of the incident, the CRM system contained approximately 12,000 individuals’ and 8,000 companies’ data (including information of the companies’ representatives). The types of data affected for each individual varied, but may include an individual’s name, identification number, contact number, email address, age, race, marital status, salary and compensation amount (if applicable). 6. On 17 February 2020, the CRM system was unavailable to users. The Vendor managed to restore the CRM system from a back-up copy within the next three hours. 7. Upon investigations, the Organisation determined that the CRM system suffered a ransomware attack. In particular, security logs obtained from the Vendor showed that hacking attempts were made on the database server between 7 and 14 February 2020. 8. The Organisation claimed that it had, since June 2019, expanded the scope of the IT services procured from the Vendor to include security monitoring services for the CRM system, such as the blocking of cyber-attacks based on alerts. However, there was inadequate process put in place to ensure that the Vendor proactively monitor the alerts and take actions to block malicious activities in a timely manner. Nevertheless, the 2 Organisation accepts that it had the responsibility to ensure that the Vendor had the same understanding on its duty of care under the monitoring services contract and to oversee and supervise the work of the Vendor through clear instructions on regular reporting and updates by the Vendor. 9. Following the incident, the Organisation started close monitoring of the Vendor’s IT services support on a weekly basis to ensure timely update of patches and follow-ups on security alerts received. The Organisation also undertook an organisation-wide review to strengthen its management of all its third-party IT service providers, such as requesting these service providers to conduct cybersecurity audits, vulnerability assessment and penetration testing for the Organisation’s existing IT systems. The Organisation also informed the Commission that it will be migrating to a new CRM system and is currently working to terminate the existing CRM system. 10. The Organisation informed the Commission that the database in the CRM system was not protected by encryption at the time of the incident, which made the database vulnerable for exposure. However, there was no evidence that the hacker had exfiltrated the database. The Organisation’s Admission and the Commission’s Decision 11. The Organisation admitted that it had breached the Protection Obligation under section 24 of the PDPA in failing to ensure that the Vendor had duly discharged its contractual data protection obligations. In particular, the Organisation admitted that it had not 3 monitored the Vendor’s performance to ensure that the Vendor met the required information security standards. 12. As stated in previous decisions by the Commission1, organisations have to give proper instructions and exercise reasonable oversight over their vendors to ensure that their outsourced providers are indeed delivering the services contracted. Without reasonable oversight, the risk from any failure will fall on the organisation. In the circumstances, the Commissioner found that the Organisation was in breach of the Protection Obligation under section 24 of the PDPA. 13. As for the Vendor, it was a SaaS provider who provided the CRM system, including maintenance support, and security monitoring services. These services did not entail the processing of personal data. As such, the Vendor was not a “data intermediary” of the Organisation. Accordingly, the Vendor was not responsible for the protection of the individuals’ personal data under the PDPA in respect of the incident. 14. In determining the directions to be imposed on the Organisation for the breach, the Commissioner took into account the following factors: 1 See for example, Re Smiling Orchid (S) Pte Ltd and Ors [2016] SGPDPC 19, Re Royal Caribbean Cruises (Asia) Pte Ltd [2020] SGPDPC 5, and Re SCAL Academy Pte. Ltd. [2020] SGPDPC 2. 4 Aggravating (a) The high number of affected individuals, which is approximately 20,000; (b) The nature of the affected data. In particular, the database contained details of employment-related complaints and disputes. Individuals would expect a high level of confidence when they convey such matters to the Organisation for handling; Mitigating (c) The Organisation’s upfront admission of breach of the Protection Obligation, and the prompt remedial actions to mitigate the effects and prevent recurrence of the incident; and (d) There was no evidence of exfiltration of the database in the CRM system. 15. On account of the above, the Organisation is directed to pay a financial penalty of $29,000 within 30 days from the date of this direction. In view of the remedial action of the Organisation, the Commission will not be issuing any other directions. 5 ",Financial Penalty,0cdce22d84405d3787ba0a1ff0507d00cb8cec7f,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,69,69,1,952,"A financial penalty of $9,000 was imposed on Iapps for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of some users of the ActiveSG mobile application.","[""Protection"", ""Financial Penalty"", ""Information and Communications"", ""Code deployment"", ""Wrong Environment""]",2021-03-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Iapps-Pte-Ltd---10022021.pdf,Protection,Breach of the Protection Obligation by Iapps,https://www.pdpc.gov.sg/all-commissions-decisions/2021/03/breach-of-the-protection-obligation-by-iapps,2021-03-11,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 1 Case No DP-1903-B3441 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Iapps Pte Ltd. … Organisation DECISION Iapps Pte Ltd [2021] SGPDPC 1 Lew Chuen Hong, Commissioner — Case No DP-1903-B3441 10 February 2021 Introduction 1 On 1 March 2019, the Personal Data Protection Commission (the “Commission”) received a complaint from an individual (the “Complainant”) in relation to potential unauthorised disclosure of his personal data through the ActiveSG mobile application (the “ActiveSG App”). The Complainant’s concerns arose because he was able to view another individual’s personal data when he logged into his child’s supplementary account on the ActiveSG App (the “Incident”) Facts of the Case 2 ActiveSG is a national movement for sports coordinated by Sport Singapore,1 a statutory board of the Ministry of Culture, Community and Youth. Iapps Pte Ltd (the “Organisation”) is a financial technology company specialising in mobile application development and marketing. Sport Singapore engaged the Organisation to develop, deploy and operate the Super Sports Club Membership Management System (“SSCMMS”). The functions of SSCMMS included membership registration, and the ActiveSG App was a component of 1 Sport Singapore was formerly known as Singapore Sports Council. Iapps Pte Ltd [2020] SGPDPC 1 the SSCMMS. Members of ActiveSG could use the ActiveSG App to book sport facilities, register for fitness classes and purchase entry passes to ActiveSG sport centres. 3 Sport Singapore is the owner of the SSCMMS and ActiveSG App. Pursuant to the written contract between the Organisation and Sport Singapore, the Organisation’s scope of work included providing and operating the production server for the ActiveSG app. The Organisation also developed, deployed and operated the SSCMMS (including the ActiveSG App). 4 On 1 March 2019, the Organisation’s engineer developed a security code fix for the ActiveSG App. The security code fix was meant to be deployed into the enterprise environment (which was a test environment) for further testing. However, due to human error, the security code fix was deployed into the production environment, resulting in the Incident. 5 According to the Organisation, the personal data of 153 individuals (the “At Risk Individuals”) had been at risk of unauthorised access by 84 individuals during the Incident. Out of the At Risk Individuals, there was actual unauthorised access of 108 individuals’ (including 9 minors below the age of 18) (the “Affected Individuals”) names and NRIC numbers (“Disclosed Data”) by 84 individuals who were able to view this information when logging into their own accounts on the ActiveSG App. For 6 of the Affected Individuals, in addition to the Disclosed Data, there was also actual unauthorised access of additional personal data, including (collectively, the “Additional Disclosed Data”): (a) Email address; (b) Mobile telephone number; 2 Iapps Pte Ltd 6 [2020] SGPDPC 1 (c) Home telephone number; (d) Address; (e) Gender; (f) Date of birth; (g) Race; (h) Employment status; and (i) Sports Interests. Upon being notified of the Incident on the same day, the Organisation immediately took the following remedial actions: (a) Rectified the issue within 2 hours of the Incident; (b) Reminded its staff to be careful and vigilant in the course of their work; and (c) Together with Sport Singapore, implemented the following measures: (i) Separated the enterprise environment and production environment that were previously on the same server; (ii) Put in place 2-factor authentication for the Organisation’s engineers to access the production environment. This means that the engineers are required to obtain the 2-factor one-time password from Sport Singapore to access the production environment; 3 Iapps Pte Ltd [2020] SGPDPC 1 (iii) Monitoring of affected users for suspicious activities; and (iv) 7 Implemented dynamic QR codes for member IDs. Sport Singapore also notified the Affected Individuals about the Incident. The Commissioner’s Findings and Basis for Determination 8 There is the preliminary issue of whether the Organisation was a data intermediary for Sport Singapore, and whether it could avail itself of the exception under the previous section 4(1)(c) of the of the Personal Data Protection Act 2012 (“PDPA”).2 9 Effective 1 February 2021, the exclusion in section 4(1)(c) of the PDPA has been amended to be limited to “public agencies” only. Organisations acting on behalf of public agencies in relation to the collection, use or disclosure of public data (even when in an agency relationship of the type described below), are now subject to obligations under the PDPA, and cannot claim to be excluded from the same. 10 As the Incident in this case occurred prior to 1 February 2021, the applicability of the exclusion under the previous section 4(1)(c) of the PDPA remains to be considered. However, the Commission makes clear that this exclusion will not be applicable or considered in future cases. Prior to 1 February 2021, section 4(1)(c) of the PDPA provided that “any public agency or an organisation in the course of acting on behalf of a public agency in relation to the collection, use or disclosure of personal data is not subject to the obligations under Parts III to VI of the PDPA” 2 4 Iapps Pte Ltd 11 [2020] SGPDPC 1 The exclusion in the previous section 4(1)(c) of the PDPA for organisations acting on behalf of public agencies was based on the legal concept of agency i.e. where the organisation was authorised by a public agency to act in its place, as its agent, and the agent manifested assent or otherwise consented to so act.3 Whether an agency relationship was created in any particular case is essentially a question of fact. Relevant factors to take into consideration when determining whether an agency relationship arose included the communications between the parties and their conduct, as well as the terms of any relevant contract. 12 The underlying question in each case was whether the organisation was authorised to act on behalf of the principal. The authorisation by the principal in an agency relationship is usually made expressly, although it could in some cases be by implication from the conduct or situation of the parties. Where there is such authority, the acts of the agent that are within the scope of the authority are the acts of the principal, which would be legally liable for the acts of its agent.4 13 In the present case, the Commission’s investigations revealed that the Organisation was at all material times an independent third party vendor. There was nothing in the contract between the parties which expressly authorised the Organisation to act on behalf of Sport Singapore. The clauses in the contract pointed to the Organisation being a service provider to Sport Singapore, and not its agent. Further, there was an indemnity clause in the contract which obliged the Organisation to among others, indemnify and keep Sport Singapore fully 3 See Alwie Handoyo v Tjong Very Sumitomo and anor [2013] 4 SLR 308 at [147] 4 See Ong Han Ling and anor v American International Assurance Co Ltd and ors [2018] 5 SLR 549 at [208] 5 Iapps Pte Ltd [2020] SGPDPC 1 indemnified against all actions, claims, demands, losses, expenses arising out of or in connection with the performance of the contract by the Organisation. As explained at [11] – [12], if the Organisation and Sport Singapore were in an agency relationship, acts of the agent (i.e. the Organisation) within the scope of authority would be acts of the principal (i.e. Sport Singapore) who would be legally liable for acts of its agent. An indemnity would therefore not be necessary. The presence of the indemnity clause is evidence that the relationship was not a principal-agent relationship. In addition, Sport Singapore confirmed that it had never appointed the Organisation to act in its place. In the circumstances, the exclusion in the previous section 4(1)(c) of the PDPA did not apply to the Organisation. 14 With respect to whether the Organisation was acting as a data intermediary, the Commission’s investigations found that the Organisation was engaged to carry out activities of “processing” personal data on behalf of Sport Singapore as defined in section 2(1) of the PDPA. As mentioned at [3], the Organisation’s scope of work included developing, deploying and operating the SSCMMS (including the ActiveSG App). In the course of operating the SSCMMS and the ActiveSG App, the Organisation organised and retrieved the Disclosed Data and the Additional Disclosed Data on the behalf of Sport Singapore. In addition, the Organisation also processed service requests (which included enquiries and extraction of information including the Disclosed Data and Additional Disclosed Data) on behalf of Sport Singapore. The Organisation was therefore acting as a data intermediary of Sport Singapore Whether the Organisation had contravened section 24 of the PDPA 15 Section 24 of the PDPA provides that an organisation shall protect personal data in its possession or under its control by making reasonable 6 Iapps Pte Ltd [2020] SGPDPC 1 security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or similar risks. 16 The obligation to make reasonable security arrangements does not attach unless an organisation was in possession or control of personal data. In the present case, the Organisation provided the production environment and operated the SSCMMS (including the ActiveSG App). The Organisation therefore had actual possession of the Disclosed Data and Additional Disclosed Data and control of the processing activities that they had contracted to provide. Therefore, prior to the Incident, they were obliged to put in place reasonable security arrangements to protect the Disclosed Data and Additional Disclosed Data. 17 The Commission’s investigations revealed that the Organisation’s processes for the deployment of code into production and test environments were not sufficiently robust to safeguard against risks of deployment of codes into the wrong environment. (a) According to the Organisation, its usual code deployment process went through 3 stages (i) User Acceptance Testing (“UAT”); (ii) “enterprise environment” (i.e. test environment); and (iii) production environment. (b) Due to human error on the part of its engineer, the Organisation’s processes and procedures for the deployment of the security code fix into the ActiveSG App were not followed. After the UAT was completed, the code that was meant to be deployed to the testing environment was instead deployed directly into the production environment. This is a grave and serious error with, as is evident in this case, potentially severe consequences. In this regard, the Commission’s 7 Iapps Pte Ltd [2020] SGPDPC 1 investigations revealed that the Organisation did not have second-level approvals or supervisory checks in its processes for the deployment of codes into the test environment. This meant there was no oversight of the code deployment process nor any supervision of the actions of the Organisation’s engineers after UAT was completed. (c) As stated in the Commission’s previous decisions, relying solely on employees to perform their duties diligently is not a sufficient reasonable security arrangement – organisations should take practical steps to implement its policies and procedures to protect personal data, including identifying areas of high risk that require higher level of approval and adequate supervision.5 In the present case, the deployment of the security code fix into the ActiveSG App could potentially expose the Disclosed Data and the Additional Disclosed Data to security risks. The Organisation should have identified this risk, and implemented a second-level check to ensure that its engineers deployed the codes into the correct environment. Alternatively, the Organisation could have automated its processes by using development operations software that would automate the correct deployment of code. (d) The absence of any second-level checks in the Organisation’s processes for the deployment of codes and lack of any other form of security arrangement to safeguard against risks of deployment of codes into the wrong environment amounted to weak internal work process controls. 5 See Re Aviva Ltd [2017] SGPDPC 14 and Re Marshall Cavendish Education Pte Ltd [2019] SGPDPC 34 8 Iapps Pte Ltd 18 [2020] SGPDPC 1 For the reasons above, the Commissioner found the Organisation in breach of section 24 of the PDPA. 19 After being notified of the Commission’s proposed decision including the proposed financial penalty amount, the Organisation made representations to the Commission suggesting that (i) the Organisation had done the necessary to comply with section 24 of the PDPA, or (ii) that a warning ought to be administered in lieu of the Commission’s proposed financial penalty. The Organisation’s representations were rejected for the following reasons: (a) The Organisation contended that it did have second-level checks for the deployment of code, and referred the Commission to its Standard Operating Procedure (“SOP”) for the SSCMMS. While the SOP did describe multi-level checks at the UAT stage (i.e. the first stage of testing), it not dictate any second-level checks relating to the deployment of code into the enterprise environment, and thereafter production environment (i.e. the second and third stages). In fact, the SOP contained no references to deployment of code in the enterprise environment at all. The Organisation failed to provide any evidence of any second-level checks after UAT and before deployment of the code in production. (b) The Organisation claimed that the Incident was the result of human error which happened “in the rush of the moment” and would not have been prevented by a second level check. The Commission disagrees. For the reasons stated at 17(c) and 17(d) above, the appropriate processes such as a second-level check or automated code deployment via software should have been implemented, and would have prevented the Incident. Such processes are all the more necessary 9 Iapps Pte Ltd [2020] SGPDPC 1 considering the time pressure that engineers often operate under, as appears to have happened in this case. (c) The Organisation highlighted that it had taken prompt remedial actions after discovery of the Incident (listed at [6] above). The Commission accepts that the remedial action taken by the Organisation was timely and sufficient. This has been taken this into consideration in quantifying the financial penalty imposed in this case (as set out below), and in deciding that no further directions need be issued to the Organisation. Financial Penalty 20 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 Commissioner took into account the factors listed at section 48(6) of the PDPA, including that: (a) that the Disclosed Data included the NRIC numbers of 9 minors; (b) The Organisation cooperated with the Commission’s investigations; and (c) The Organisation implemented prompt remedial actions (i.e. the issue was fixed within 2 hours of the Incident). 21 On 23 July 2020, the Organisation was given notice of the Commission’s intention to impose a financial penalty of S$11,000 and was invited to make representations. Having considered the Organisation’s representations dated 21 August 2020, 21 October 2020, and 29 October 2020, 10 Iapps Pte Ltd [2020] SGPDPC 1 as well as all the relevant factors of this case, the Commissioner hereby requires the Organisation to: (a) pay a financial penalty of S$9,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 the financial penalty until it is paid in full. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 11 ",Financial Penalty,254f6fd787bbfaed69d1c08e1395d0e7cc753f16,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,70,70,1,952,"A financial penalty of $5,000 was imposed on BLS International Services Singapore for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of the personal data of individuals who had submitted a booking for an appointment on its website.","[""Protection"", ""Financial Penalty"", ""Information and Communications"", ""Inadequate scoping of testing"", ""URL manipulation""]",2021-01-14,"https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---BLS-International-Services-Singapore-Pte,-d-,-Ltd,-d-,-30112020-(003).pdf",Protection,Breach of the Protection Obligation by BLS International Services Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2021/01/breach-of-the-protection-obligation-by-bls-international-services-singapore,2021-01-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2007-B6563 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And BLS International Services Singapore Pte. Ltd. SUMMARY OF THE DECISION 1. BLS International Services Singapore Pte. Ltd. (the “Organisation”) provides government-to-citizen services for the High Commission of India in Singapore, such as visa and consular services. 2. On 7 July 2020, the Personal Data Protection Commission (the “Commission”) received information that the URLs of the printable version of appointment booking confirmation webpages could be manipulated to access other individuals’ personal data (the “Incident”). The personal data comprised the individual’s name, passport number, contact number, email address, type of service request, booking date/time, appointment date/time, and number of booking applications. 3. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. It also admitted that it was in breach of section 24 of the Personal Dara Protection Act (the “PDPA”). 4. Investigations revealed that on 8 June 2020, which was about a month prior to the Incident, the Organisation had implemented a new booking system for the High Commission of India. Under this new booking system, users who submitted a booking for an appointment at the High Commission of India would be provided with an URL, which led to a printable version of the booking confirmation. In designing the booking system, the Organisation had intended for the URLs to be encrypted. This would have made it more difficult for people to manipulate the URL. However, the encryption was not done properly due to a coding error. Although the Organisation had conducted some testing on the new booking system, the testing was not extensive enough to detect the error. 5. Upon realising the occurrence of the Incident from the Commission on 16 July 2020, the Organisation took immediate action to investigate and subsequently identified the coding error. On the same day, the Organisation made changes to the booking system. It stopped providing users with an URL to a printable version of their booking confirmation. Instead, the booking confirmation would be sent to the user’s email account. 6. The Organisation’s records showed that a total of 3,357 individuals used the new booking system from 8 June 2020 to 16 July 2020. This meant that the personal data of 3,357 individuals was at risk of exposure by URL manipulation. 7. The Deputy Commissioner for Personal Data Protection found that the Organisation was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 for failing to conduct adequate testing of the booking system before it went “live”. Depending on how the URL encryption was implemented, URL encryption could had been a reasonable security measure for the personal data type the Organisation was collecting. However, because the Organisation had not conducted adequate testing of the booking system before it went “live”, the Organisation did not detect the coding error, thereby resulting in the Incident. 8. After considering the circumstances of the case, including: (i) the Organisation’s upfront voluntary admission of liability which significantly reduced the time and resources required for investigations; and (ii) the Organisation’s prompt remedial actions, the Deputy Commissioner for Personal Data Protection directs that the Organisation pays a financial penalty of $5,000 for the breach. 9. The Organisation must make payment of the financial penalty within 30 days from the date of this direction, 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 the financial penalty until it is paid in full. 10. No further directions are required as the Organisation had taken actions to address the gaps in its security arrangements. ",Financial Penalty,258d44ffd944015c9b8f9f9ffd545a6b10bb6fee,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,71,71,1,952,"A financial penalty of $9,000 was imposed on The Future of Cooking for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of its customers’ personal data on its website.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Data Intermediary"", ""Protection"", ""Security""]",2021-01-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---The-Future-of-Cooking-Pte-Ltd-20112020-(003).pdf,Protection,Breach of the Protection Obligation by The Future of Cooking,https://www.pdpc.gov.sg/all-commissions-decisions/2021/01/breach-of-the-protection-obligation-by-the-future-of-cooking,2021-01-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2001-B5620 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And The Future of Cooking Pte. Ltd. SUMMARY OF THE DECISION 1. The Future of Cooking Pte. Ltd. (the “TFC”) operates an e-commerce website at https://www.thermomix.com.sg (the “Website”), retailing kitchen appliances and accessories. 2. On 3 January 2020, the Personal Data Protection Commission (the “Commission”) received a complaint that a text file (the “File”) containing personal data was accessible via the URL: https://thermomix.com.sg/wp-content/uploads/2019/10/woocommerce-orderexport-1.csv-1.txt. (the “Incident”). 3. The File contained the personal data of 178 unique individuals who had purchased items from the Website. The File was accessible via the URL from 1 October 2019 until 6 January 2020. It contained the following types of personal data (the “Personal Data”): a. Name; b. Email Address; c. Billing Address; d. Shipping Address; e. Customer Notes (e.g. delivery instructions); f. Order information (such as payment status, mode of payment, and transaction ID); g. Product ID of items; h. Quantity of items ordered; and i. Telephone number. The Commission’s Findings No breach by Hachi as a Data Intermediary 4. TFC had engaged Hachi Web Solutions Pte. Ltd. (“Hachi”) to re-design the Website and also perform data backup and migration. Insofar as the data backup and migration activities are concerned, Hachi was TFC’s data intermediary. The cause of the breach, however, did not relate to the data processing activities but to the Website re-design. Therefore, Hachi was not in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”) by virtue of its role as a data intermediary. TFC in breach of the Protection Obligation 5. The cause of the data breach may be traced to a WordPress plugin (the “Plugin”) which was installed on the Website. The Plugin contained a bug which caused the File to be generated and uploaded on the Website’s directory folder. Although this was a temporary file, it was accessible to the public via the URL. 6. TFC had used the Website to collect the personal data of individuals. At the time of the Incident, TFC’s database contained personal data of approximately 3,500 individuals. To discharge its Protection Obligation under section 24 of the PDPA, TFC needed to have put in place reasonable security arrangements to protect the personal data collected. 7. In this case, investigations revealed that TFC had failed to discharge its obligations as data controller when engaging Hachi to undertake data processing activities. First, TFC did not specify any requirements for Hachi to implement any data protection measures to be implemented in the Website, whether in its contract with Hachi or other project documentation. Second, TFC did not conduct any pre-launch security testing (such as vulnerability assessments) on the Website. Had security testing been conducted, TFC would have been able to detect the presence of the publicly accessible temporary file, even if it was unaware of the bug in the Plugin that caused it. 8. Once it knew about the Incident, TFC and Hachi removed the Plugin and disabled the public’s access to the relevant directory folder. Hachi also contacted the developers of the Plugin, who acknowledged the existence of the bug and fixed the bug in an updated version. TFC subsequently engaged a vendor to perform penetration testing and other measures to enhance the security of the Website. 9. The Deputy Commissioner found TFC in breach of the Protection Obligation under section 24 of the PDPA. After considering the circumstances of the Incident, including according mitigatory weight to TFC’s cooperation with the Commission during investigations and the remedial action taken by TFC after the Incident, the Deputy Commissioner directs TFC to pay a financial penalty of $9,000 for its breach. 10. TFC must make payment of the financial penalty within 30 days from the date of this direction, 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 the financial penalty until it is paid in full. 11. No further directions are required as TFC had taken actions to address the gaps in its security arrangements. ",Financial Penalty,7255b9fe4b2433c5774bed593dd6215b52226a70,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,73,73,1,952,A warning was issued to Water + Plants Lab for failing to put in place reasonable security arrangements to protect the personal data of its employees. The incident resulted in the personal data being subjected to a ransomware attack.,"[""Protection"", ""Warning"", ""Scientific and Technical"", ""Ransomware"", ""No Security Arrangements"", ""No Patching""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Water--Plants-Lab-Pte-Ltd--181120.pdf,Protection,Breach of the Protection Obligation by Water + Plants Lab,https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-the-protection-obligation-by-water--plants-lab,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2004-B6182 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Water + Plants Lab Pte. Ltd. SUMMARY OF THE DECISION 1. On 9 April 2020, Water + Plants Lab Pte. Ltd. (the “Organisation”) informed the Personal Data Protection Commission of a ransomware infection that rendered the Organisation’s server (the “Server”) inaccessible to the Organisation (the “Incident”). 2. The Incident occurred on or around 30 March 2020. Personal data of 28 employees were encrypted by the ransomware. The personal data affected included the employees’ name, NRIC/FIN/Work Permit number, address, date of birth, mobile number and photograph. 3. Investigations revealed that an employee from the Organisation had downloaded and opened an email attachment that contained ransomware. At the time of the Incident, the Organisation had some security measures in place, for example, it had anti-virus protection, and access rights and password control for the Server. It also had a good practice of performing regular backup of its Server, and most of the data was successfully restored from an external backup. The Organisation therefore suffered minimal data loss as a result of the Incident. 4. However, as admitted by the Organisation, it had not carried out any patching and security scanning of the Server in the 12 months preceding the Incident. Patching and regular security scanning are important security measures to prevent vulnerabilities in an organisation’s ICT systems which a hacker may exploit in compromising personal data. For this reason, the Deputy Commissioner for Personal Data Protection found that the Organisation had failed to protect the personal data in its possession or under its control, in breach of section 24 of the Personal Data Protection Act 2012. 5. Following the Incident, the Organisation installed a firewall with greater capabilities to protect the Organisation against external threats, for example, possessing deeper content inspection capabilities to identify malware. The Organisation had also conducted staff training on personal data protection and on how to identify security threats. 6. Upon consideration of the facts, including the impact from the breach, the remediation action taken by the Organisation and that there was no evidence of exfiltration of the data in the Server, the Deputy Commissioner issued a warning to the Organisation. ",Warning,eee08e16b63cd4fae6c7d3775b36bf12d04f634d,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,74,74,1,952,A warning was issued to R.I.S.E Aerospace for failing to put in place reasonable security arrangements to protect the personal data of its employees from unauthorised disclosure. The incident resulted in the personal data being subjected to a ransomware attack.,"[""Protection"", ""Warning"", ""Manufacturing"", ""Ransomware"", ""No Security Arrangements"", ""IT security policies""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---RISE-Aerospace-Pte-Ltd---131120.pdf,Protection,Breach of the Protection Obligation by R.I.S.E Aerospace,https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-the-protection-obligation-by-rise-aerospace,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2007-B6832 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And R.I.S.E Aerospace Pte. Ltd. SUMMARY OF THE DECISION 1. On 25 August 2020, R.I.S.E Aerospace Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware infection that had rendered its network storage server inaccessible to the Organisation (the “Incident”). 2. The Incident occurred on or about 23 August 2020. Personal data of 21 employees were encrypted by the ransomware. The personal data encrypted included the name, address, contact number, NRIC number, Work Permit details, passport details. redacted bank account numbers, and child’s date of birth. 3. Investigations revealed that the Organisation had not implemented adequate technical security arrangements to protect the personal data in its possession or control, in particular, the Organisation did not carry out any security scans or perform updates to the server firmware despite being prompted to do so by the device manufacturer. In addition, the Organisation did not put in place any documented form of IT Security policies such as its password policy, policies for patching and updating of the company server etc. These failings had resulted in a system that had vulnerabilities which a hacker could exploit by injecting ransomware into the server. 4. Following the Incident, the Organisation had since discontinued the use of its network storage server and to opt for cloud storage instead. Additionally, the Organisation also decided to encrypt all its sensitive data and only store them on offline devices. 5. In the circumstances, the Deputy Commissioner for Personal Data Protection finds the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”) and took into account the following factors in deciding to issue a Warning to the Organisation. a. The low number of affected individuals; b. There was no evidence that the personal data affected in the Incident had been misused in any form; c. The Organisation had a backup copy of the encrypted personal data and did not lose any personal data as a result of the Incident; and d. The Organisation voluntary notified the Commission of the Incident. 6. In view of the remedial actions taken by the Organisation, the Commission will not be issuing any other directions. ",Warning,1400daa426845ef3c61fb74391afd631da480958,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,75,75,1,952,"A financial penalty of $8,000 was imposed on Hello Travel for failing to put in place reasonable security arrangements to protect the personal data of its members from unauthorised disclosure.","[""Protection"", ""Financial Penalty"", ""Information and Communications"", ""Expedited"", ""Exploitation"", ""Vulnerability""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Hello-Travel-Pte-Ltd---301020.pdf,Protection,Breach of Protection Obligation by Hello Travel,https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-protection-obligation-by-hello-travel,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2004-B6189 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Hello Travel Pte. Ltd. SUMMARY OF THE DECISION 1. On 8 April 2020, the Personal Data Protection Commission (the “Commission”) received information that a database belonging to Hello Travel Pte Ltd (the “Organisation”) was posted on an internet forum and was thus made publicly available (the “Incident”). 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. It also admitted that it was in breach of section 24 of the Personal Dara Protection Act (the “PDPA”). 3. The compromised database contained the personal data of approximately 71,002 users who had created accounts at the Organisation’s website (www.havehalalwilltravel.com) from February 2015 to July 2018. The disclosed personal data included their name, email address, date of birth, nationality and phone number. The table below summarises the number of affected individuals for each corresponding type of personal data disclosed: S/N Type of Personal Data Number of Individuals Affected 4. 1 Name 71,002 2 Email Address 57,693 3 Phone Number 453 4 Date of Birth 946 5 Nationality 20,754 The Organisation’s internal investigations pointed to a possible hack as the cause of the Incident. Sometime in year 2018, the server instance which hosted the Organisation’s website and the database became corrupted and unusable after the installation of a free open source wordpress plugin. The Organisation believed that unknown parties could have exploited vulnerabilities of the installed plugin at that time and exfiltrated the database. 5. The Organisation admitted that it did not give due attention to personal data protection and had neglected to put in place basic procedural and technical security arrangements to protect the personal data in its possession and control. As examples, it did not have the relevant policies and/or protocols in place to perform regular system patching or to conduct security assessment and/or testing when making changes to its ICT systems. 6. In the circumstances, the Deputy Commissioner for Personal Data Protection finds the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 7. Following the incident, the Organisation implemented technical measures to secure its systems from potential vulnerabilities. The personal data of its members were also encrypted immediately. Additionally, the Organisation had engaged relevant parties to take down the compromised database and informed the affected individuals of the Incident. 8. In determining the directions, if any, to be imposed on the Organisation. The Deputy Commissioner took into account the following factors: Aggravating factors (a) The high number of individuals affected; (b) The fact that personal data was exfiltrated and posted online; and (c) The Organisation did not put in place basic procedural and technical security arrangements. Mitigating factors (a) The Organisation had cooperated with the investigation; (b) The Organisation’s upfront voluntary admission of liability to a breach of the Protection Obligation under the PDPA; (c) The Organisation’s prompt remedial actions at [7] to address the inadequacies in its procedures and processes; and (d) There was no evidence that the personal data affected in the Incident had been misused in any form. 9. In the course of settling this decision, the Organisation made representation on the amount of financial penalty which the Commission intends to impose and requested that the financial penalty to be paid in instalments. The Organisation raised the following factors for the Commission’s consideration: (a) The Organisation had been suffering substantial loss due to the impact to the travel industry by the Covid-19 pandemic; and (b) The Organisation had already spent quite a substantial amount of money to fix the security breach. 10. Having carefully considered the representations, the Deputy Commissioner has decided to reduce the financial penalty to the amount set out in [11a] and is agreeable for the financial penalty to be payable in instalments. The quantum of financial penalty has been calibrated after due consideration of the Organisation’s financial circumstances due to the unprecedented challenges faced by businesses amid the current Covid-19 pandemic, bearing in mind that financial penalties imposed should not be crushing or cause undue hardship on organisations. Although a lower financial penalty has been imposed in this case, the quantum of financial penalty should be treated as exceptional and should not be taken as setting any precedent for future cases. 11. Taking into account all relevant facts and circumstances, the Deputy Commissioner hereby directs the Organisation to: (a) Pay a financial penalty of $8,000 in 10 instalments by the due dates as set out below, failing which, the full outstanding amount shall become due and payable immediately and 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: i. 1st instalment of $800 on 1 January 2021; ii. 2nd instalment of $800 on 1 February 2021; iii. 3rd instalment of $800 on 1 March 2021; iv. 4th instalment of $800 on 1 April 2021; v. 5th instalment of $800 on 1 May 2021; vi. 6th instalment of $800 on 1 June 2021; vii. 7th instalment of $800 on 1 July 2021; viii. 8th instalment of $800 on 1 August 2021; ix. 9th instalment of $800 on 1 September 2021; and x. 10th instalment of $800 on 1 October 2021 12. In view of the remedial actions taken by the Organisation, the Deputy Commissioner will not be issuing any other directions. ",Financial Penalty,4d881a08a671b9937b7e44b95f8f13e43eadd144,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,77,77,1,952,"A financial penalty of $4,000 was imposed on Novelship for failing to put in place reasonable security arrangements to protect the personal data collected from its sellers from unauthorised access on its website.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Public access"", ""URL manipulation"", ""No Security Arrangements""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Novelship-Pte-Ltd---22072020.pdf,Protection,Breach of the Protection Obligation by Novelship,https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-protection-obligation-by-novelship,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1905-B3820 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Novelship Pte. Ltd. SUMMARY OF THE DECISION 1. Novelship Pte. Ltd. (the “Organisation”) operates an e-commerce website for individuals to sell or buy luxury brands of streetwear (the “Website”). To create a buyer or seller account on the Website, individuals would have to provide their personal data to the Organisation. The Organisation does not, in usual course, reveal the personal data it had collected to any buyer or seller transacting on the Website. Instead, the Organisation, together with an external payment processor, facilitates transaction payments on behalf of the parties. 2. On 1 May 2019, the Personal Data Protection Commission (the “Commission”) received information that a registered seller (“User”) was able to gain unauthorised access to the personal data of other sellers by employing software tools and manipulating the public URLs of active listings (“the “Incident”). 3. The User had accessed the personal data of six unique sellers who had active listings at the time of the Incident. The personal data concerned included: (i) first and last names; (ii) email addresses; (iii) shipping addresses; (iv) hashed account passwords; and (v) the name of bank and bank account numbers (“Personal Data Sets”). No buyer data was accessed in the Incident. 4. Investigations revealed that the Organisation had not conducted adequate security testing before the launch of the Website. The testing it had conducted was limited to design and functionality issues, such as verifying the password hashing and password requirement functions. Critically, the Organisation should have—but had not—conducted vulnerability scanning. Vulnerability scanning that is reasonably and competently conducted should include scanning for OWASP Top Ten, i.e. the top 10 security vulnerabilities listed by the Open Web Application Security Project (“OWASP”). The vulnerability of URLs to manipulation is within the OWASP Top 10, and would have been detected if the Organisation had conducted adequate vulnerability testing. 5. The Commission understands that not every organisation is equipped with adequate knowledge of cyber security risks or the ability to conduct security testing. However, the obligation of organisations to protect the personal data they collect and process online cannot depend on their subjective familiarity with the security risks or ability to prevent them. Organisations are expected to engage qualified competent parties, where reasonably needed, to assist them to discharge their obligation to protect personal data. When doing so, organisations can refer on the technical advice and expertise of their service provider, but remain ultimately responsible for articulating the business risks they wish to avoid and business outcomes that they seek to achieve. 6. Similarly, the Commission recognises that organisations may face financial, manpower and technical limitations. These limitations are relevant in establishing the reasonableness of decisions they have taken, but cannot allow an organisation to justify providing a level of protection that is below what is reasonable for the type of personal data it collects and processes. 7. Accordingly, the Deputy Commissioner for Personal Data Protection finds the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. 8. Having considered the representations made by the Organisation and the material factors, in particular: (a) the sellers’ personal data would have been at risk of unauthorised access for a period of eight months (from the time the sellers were first allowed to sell on the Website, to the date remedial actions were taken); (b) there was actual unauthorised access of the Personal Data Sets of six individuals by the User; (c) the remedial measures taken by the Organisation upon being made aware of the Incident; which included fixing the vulnerability to ensure that the sellers’ personal data would no longer be accessible to unauthorised persons, redacting all user information relating to bank information, and the Organisation committing to developing a new website; and (d) the adverse impact the COVID-19 pandemic had on the Organisation’s business; the Deputy Commissioner for Personal Data Protection directs that the Organisation pays a financial penalty of S$4,000 for the contravention. The Organisation must make payment of the financial penalty within 30 days from the date of this direction, 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 the financial penalty until it is paid in full. No other directions are required as the Organisation had implemented the necessary remedial measures. ",Financial Penalty,e78daf1170808149ba7ab6af446c1836acb0e555,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,80,80,1,952,"A financial penalty of $120,000 was imposed on Secur Solutions Group for failing to put in place reasonable security arrangements to protect a database containing the personal data of blood donors from being publicly accessible online.","[""Protection"", ""Financial Penalty"", ""Professional"", ""Scientific and Technical"", ""Database"", ""Gaps"", ""Public access""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Secur-Solutions-Group-Pte-Ltd---30032020.pdf,Protection,Breach of the Protection Obligation by Secur Solutions Group,https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-protection-obligation-by-secur-solutions-group,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 8 Case No DP-1903-B3501 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Secur Solutions Group Pte Ltd … Organisation DECISION Secur Solutions Group Pte Ltd [2020] SGPDPC 8 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 Tan Kiat How, Commissioner — Case No DP-1903-B3501 30 March 2020 Introduction 1 This case relates to an incident where one of Secur Solutions Group Pte Ltd’s (the “Organisation”) servers, which stored a database (the “Database”) containing personal data of blood donors, was discovered to be accessible from the internet (the “Incident”). 2 The Personal Data Protection Commission (the “Commission”) received a formal request from the Organisation requesting for this matter to be handled under the Commission’s Expedited Breach Decision procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts as set out in this Decision and that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 2 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 Facts of the Case 3 The Organisation has been engaged by the Health Sciences Authority (“HSA”) since 2013 to develop and maintain various IT systems. One of the projects for which the Organisation was engaged was the development, maintenance and enhancement of its queue management system (“ QMS”) for blood donors (the “QMS Engagement”). Pursuant to the QMS Engagement, HSA provided the Organisation with files containing copies (in part or otherwise) of the Database (“Files”) for the purposes of testing and developing the QMS. HSA would also provide the Organisation with copies or updates of the Database (“Updates”) from time to time during the period of the QMS Engagement (hereinafter, the use of the phrase “Files” will include “Updates”, unless the context specifies otherwise). 4 The Organisation stored the Files in a storage server that was designated for the purposes of testing and development (the “Testing and Development Server”). The Testing and Development Server was accessible through the Internet and unsecured as it was not intended to be used to store personal data or other confidential information. The Server’s system was not actively patched or updated, the router to which the Server was connected did not have a perimeter firewall setup, and there were no firewalls or any other security protocols to restrict access to the Server. 5 At the material time, the Files contained registration-related information (the “Personal Data”) of about 800,000 individual blood donors (the “Affected Individuals”), specifically: (a) Name; (b) NRIC; 3 Secur Solutions Group Pte Ltd 6 [2020] SGPDPC 8 (c) Gender; (d) Handphone number1; (e) Number of blood donations; (f) Dates of the last 3 blood donations; and (g) (In some cases) blood type, height and weight. A cybersecurity expert discovered that he could access the Personal Data in the Database through one of the Organisation’s servers. Based on the forensic investigations conducted by the Organisation, the number of records from the Database that had been exfiltrated amounted to anywhere between 236,023 to 328,546. 7 Upon being notified of the Incident on 13 March 2019, the Organisation took the following remedial actions: (a) Disconnected the Testing and Development Server from the Internet and removed all physical devices connected to the compromised ports to the server; (b) Disabled all remote access to the Organisation’s servers to ensure that all development zones were protected by firewalls; (c) Organised an employee townhall session addressing the Incident; 1This was based on the information provided by the Organisation. 4 Secur Solutions Group Pte Ltd (d) [2020] SGPDPC 8 Appointed external vendors to undertake forensic analysis of the affected servers; (e) Issued press releases to keep the public informed of the Incident and the status of ongoing investigations; (f) Informed its employees not to receive personal data from clients if it was not necessary and to escalate the receipt of personal data (inadvertently or otherwise) to senior management; (g) Conducted further investigation on the security of its Internet lines and Internet-facing services; (h) Began reviewing and improving its internal processes and taking steps to enhance its cybersecurity posture, including appointing a second Data Protection Officer, requiring employees to complete an e-learning program and identifying and remediating any gaps in protection; and (i) Began reviewing its security infrastructure with the assistance of an external vendor, and implementing certain measures, including (i) ensuring all devices used by employees are secured and the anti-virus software installed on these devices are up-to-date, (ii) implementation of a Network Access Control measure, (iii) adoption of a “defence-indepth” approach (including segregation of servers containing sensitive information) and (iv) enhancement of endpoint security measures. Findings and Basis for Determination 5 Secur Solutions Group Pte Ltd 8 [2020] SGPDPC 8 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. As a preliminary point, the Organisation has accepted that it is a data intermediary of HSA and is required to comply with section 24 of the PDPA with respect to the Personal Data in its possession. Whether the Organisation Complied with Section 24 9 The Organisation has admitted that it has breached section 24 of the PDPA by failing to put in place reasonable security arrangements to protect the Personal Data. 10 The Organisation informed the Commission that it had stored the Files containing the Database in its Testing and Development Server as it did not anticipate that it would be receiving actual copies of production databases from HSA and, as such, did not take any steps to designate any specific security infrastructure set up to receive or store such data on premise. 11 The Organisation admitted that it ought to have been aware that the Files contained personal data even though they had not been specifically informed of this by HSA. In past projects between them, the Organisation had directly retrieved personal data from a production environment on the servers on HSA’s premises for the purposes of testing and development. On this occasion, even though the Files were provided by HSA to the Organisation for the QMS Engagement, from July to August 2018, the Organisation was given access to HSA’s server rooms to retrieve Updates directly from HSA’s servers, an arrangement that made sense if the Files also contained actual personal data (as 6 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 opposed to dummy data). Accordingly, the Organisation ought to have been aware that personal data was contained in the Files, but most definitely in the Updates. 12 In this regard, the Organisation admitted that the Files should not have been stored on the Testing and Development Server, and this was a breach of the Organisation’s own data protection policies and practices, which required that personal data be protected and secured regardless of the purposes for which it was provided. 13 The Organisation has accepted that there were gaps in its data governance and processes with respect to the receipt of test data from its clients. 14 In view of the above, the Commissioner found the Organisation in breach of section 24 of the PDPA. Representations by the Organisation 15 In the course of settling this decision, the Organisation made representations to request that the financial penalty as set out in [19] be paid in the following manner: 16 (a) $60,000 within 30 days from the date of the directions; and (b) $60,000 within 7 months from the date of the directions. The Organisation raised the following factors for the Commissioner’s consideration: (a) The Organisation is a small medium enterprise in a highly competitive IT services industry. It has to contend with rising 7 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 wage costs and increased rentals while battling depressed prices that customers are willing to pay for their services; (b) Arising out of the Incident, the Organisation has: (i) Expended significant resources when it appointed reputable advisors to undertake forensic activities, and sought the advice and assistance of professionals to respond to the police and the Commission’s investigations; (ii) Invested heavily to shore up its data protection and cybersecurity measures, including conducting research and exploring various technologies and methods which may be deployed in protecting data (at rest and in transit) without compromising ease of use of the data; and (c) Payment of the entire financial penalty of $120,000 in one lump sum would negatively affect the Organisation’s cash flow. 17 Having carefully considered the representations, the Commissioner has decided to reject the Organisation’s request at [15]. For the purposes of supporting a request that a financial penalty be paid in instalments, organisations are required to furnish supporting documents on their financial status to the Commission. However, despite the Commission’s repeated requests, the Organisation did not furnish its financial statements and was unable to provide any explanation why it could not to do so. There was therefore no evidence to support the Organisation’s representations on its financial status at [16]. If the Organisation is able to secure documentary evidence of its financial position before the due date for payment as set out at [19], it may submit another request that the financial penalty be paid in instalments. 8 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 The Commissioner’s Directions 18 In determining the directions to be imposed on the Organisation under section 29 of the PDPA, the Commissioner took into account the following factors: Mitigating factors (a) The Organisation was cooperative during the Commission’s investigations; (b) As set out above, the Organisation voluntarily and unequivocally admitted to its contravention of the PDPA; and (c) The Organisation implemented remedial actions swiftly to address the Incident; and Aggravating Factor (d) A subset of the Personal Data was subject to unauthorised access and exfiltration. 19 Having carefully considered all the relevant factors of this case, the Commissioner hereby directs the Organisation to pay a financial penalty of $120,000 within 30 days from the date of the directions, 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. 20 The Commissioner took the view that the remedial actions set out at paragraph [7] had sufficiently addressed the risks to the Personal Data arising 9 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 from the Incident. The Commissioner has therefore not set out any further directions for the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 10 ",Financial Penalty,aa05055fb8dd4b8379487aa1343e9e005c42257d,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,82,82,1,952,Directions were issued to Security Masters for failing to put in place reasonable security arrangements to prevent the unauthorised access of building visitors’ mobile numbers. A security personnel contacted the visitors to request return of visitor passes and send them Chinese New Year greetings.,"[""Protection"", ""Directions"", ""Others"", ""Text messages"", ""Mobile numbers"", ""Protection""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Security-Masters-Pte-Ltd---21072020.pdf,Protection,Breach of the Protection Obligation by Security Masters,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-security-masters,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2002- B5875 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Security Masters Pte Ltd SUMMARY OF THE DECISION 1. On 17 February 2020, Security Masters Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that a security employee had used the mobile phone numbers of eight building visitors to contact them to request their return of visitor passes and send them Chinese New Year greetings. 2. Investigation found that the Organisation did not put in place any standard operating procedure or guidelines for the retrieval and use of visitors’ personal data prior to the incident. This gap in security arrangements allowed the incident to occur. 3. The Deputy Commissioner for Personal Data Protection therefore found that the Organisation did not adopt reasonable steps to protect personal data in its possession or under its control against risk of unauthorised access. The Organisation was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. 4. Following the incident, the Organisation restricted access to personal data to senior personnel and required all security personnel to sign an undertaking not to contact visitors in their personal capacity. However, structured training is needed to help its security personnel understand the importance of protecting the personal data they handled daily in their duties, such as National Registration Identification Card numbers, photographs and closed-circuit television footage. 5. On the above consideration, the Deputy Commissioner for Personal Data Protection hereby directs the Organisation to: a) Within 60 days from the date of the direction, revise its training curriculum to ensure that its security personnel understand i. the rationale for personal data protection; ii. the importance of consent and authorisation in the handling of personal data; and iii. the circumstances in which it would be appropriate to use and disclose personal data on social media platforms for work-related purposes; and b) Inform the Commission within 1 week of implementation of the above. ",Directions,e24e6989567857bec320cd7ad6365fd535330a52,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,84,84,1,952,"A warning was issued to Chan Brothers Travel for failing to put in place reasonable security arrangements to protect the personal data of individuals on its website. The result was that the personal data of over 5,500 individuals were accessible through online web search engines.","[""Protection"", ""Warning"", ""Arts, Entertainment and Recreation"", ""Access control"", ""SEO indexing""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Chan-Brothers-Travel-Pte-Ltd---21072020.pdf,Protection,Breach of the Protection Obligation by Chan Brothers Travel,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-chan-brothers-travel,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1905-B3936 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Chan Brothers Travel Pte Ltd SUMMARY OF THE DECISION 1. On 23 May 2019, the Personal Data Protection Commission (the “Commission”) received a data breach notification from Chan Brothers Travel Pte Ltd (the “Organisation”) and a complaint from a member of the public. Both were in relation to personal data being at risk of unauthorised access through the Organisation’s website at http://chanbrotherstravelclub.force.com (the “Website”) (the “Incident”). 2. In March 2017, the Organisation purchased Community Cloud, a product of Salesforce.com Singapore Pte Ltd (“Salesforce”), to host the Website. The Organisation managed the Website internally. In August 2018, the Organisation engaged Aodigy Asia Pacific Pte Ltd (“Aodigy”) as an outsource vendor to maintain and improve the Website. 3. The Website provided three online forms for enquiries and feedback. These were the “Enquiry Form”, Feedback Form” and “Post-Tour Feedback Form” (collectively the “Forms”). The Forms collected the users’ names, email addresses and mobile phone numbers. 4. In March 2018, there was a software update released by Salesforce for Community Cloud. This software update included an automated search engine optimisation feature (the “SEO”). As the Website’s access configuration was set to “Public”, the Forms automatically inherited the same setting for the purpose of the SEO feature. The result was that the personal data of an estimated 5,593 individuals collected by the Forms were indexed and cached, and made searchable, through online web search engines. 5. Organisations that employ IT systems or features are responsible for data security. Organisations must acquire knowledge of the security settings and be aware of security implications of software features of their IT system, and they must configure the security settings to enable effective protection of personal data stored in the IT system. This responsibility extends to new features introduced by subsequent software releases. Organisations that lack the IT knowledge to discharge this responsibility should engage qualified assistance. 6. The Organisation failed to consider the implication of the “Public” setting of the Website on the security of the data collected by the Forms. It also failed to understand the function and operation of the SEO feature. The combination of these acts of omission resulted in the security issues arising leaving the SEO feature enabled. 7. The Organisation claimed not to have received any notification from Salesforce of the SEO release. However, this is contradicted by the following. First, the notes of the software release was published on the website of Salesforce. Second, Aodigy had (in its role as vendor for another project) received information of the release. On balance, it is therefore unlikely that Salesforce would have omitted to notify the Organisation about the software release. In any event, the software release was in March 2018 when the Organisation was still maintaining the Website internally. The responsibility to assess the security implications of the software release laid squarely on its shoulders during that 5-month period before Aodigy was engaged. 8. Further, there is some uncertainty over whether Aodigy was instructed to review the security configuration of the Website (including the new software features) as part of its maintenance services when it was engaged. The Organisation did not give clear instructions to Aodigy to assess the security configuration of the IT system as part of the maintenance services. 9. In the circumstances, the Deputy Commissioner for Personal Data Protection therefore found the Organisation in breach of section 24 of the Personal Data Protection Act 2012 and took into account the following factors in deciding to issue a Warning to the Organisation: a. The personal data at risk of disclosure was limited to names, email address and contact numbers, apart from an estimated 50 NRIC numbers. b. The Organisation voluntary notified the Commission of the Incident. c. Prompt co-operation in the course of the Commission’s investigations. 10. No directions are required as the Organisation took immediate steps to prevent the recurrence of the Incident. ",Warning,1371e96aee9b5458d29ef161ea0de43abb7b1200,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,85,85,1,952,"A financial penalty of $4,000 was imposed on Tanah Merah Country Club for failing to put in place reasonable security arrangements to protect the personal data of individuals stored on its electronic direct mail (“EDM”) system. The common password for login to the EDM system was weak and had not been changed since 2010. There were also no arrangements in place to ensure and enforce password strength, expiry and protection. An application for reconsideration was filed against the decision Re Tanah Merah Country Club. Upon review and careful consideration of the application, directions in the decision were varied.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""EDM"", ""Password"", ""Weak password""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Tanah-Merah-Country-Club---21072020.pdf,Protection,Breach of the Protection Obligation by Tanah Merah Country Club,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-tanah-merah-country-club,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1906-B4115 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Tanah Merah Country Club Editorial note: An application for reconsideration was filed against the decision in Re Tanah Merah Country Club. Pursuant to this application, the Commissioner has decided to reduce the financial penalty imposed on the Organisation from $8,000 to $4,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 19 June 2019, Tanah Merah Country Club (the “Organisation”) informed the Personal Data Protection Commission (the “Commission”) of unauthorised access to its electronic direct mail (“EDM”) system (the “Incident”). During the Incident, which occurred on 9 June 2019, the EDM system was used to send unauthorised spam emails. 2. The Organisation was unable to determine how unauthorised access was gained to the EDM system. During investigations, it was discovered that the common password for login to the EDM system was weak, as it comprised the initials of the Organisation and the year 2010 (which was the year that the EDM system was set up). The password was shared by at least 3 persons: 2 of the Organisation’s marketing staff and its technical support vendor. Further, it had not been changed since 2010. Investigations disclosed that there were no arrangements in place to ensure and enforce password strength, expiry and protection. 3. In the circumstances, although the means of unauthorised access to the EDM system was not determined, the evidence pointed to weak password control as the cause. The Deputy Commissioner for Personal Data Protection therefore found the Organisation in breach of section 24 of the Personal Data Protection Act 2012. 4. The Organisation is directed to pay a financial penalty of $8,000 within 30 days from the date of this direction, 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 the financial penalty until the financial penalty is paid in full. In view of the remedial measures taken by the Organisation, the Commission will not issue any other directions. 5. The Organisation’s prompt co-operation in the course of the Commission’s investigation and its prompt actions taken to remediate the breach were taken into consideration in determining the quantum of the financial penalty. ",Financial Penalty,e641872fa69f2e946b7cb68cb7e884c4c88db9c2,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,86,86,1,952,"A financial penalty of $5,000 was imposed on Vimalakirti Buddhist Centre for failing to put in place reasonable security arrangements to protect the personal data of its members and non-members from unauthorised disclosure. The incident resulted in the personal data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Others"", ""Ransomware"", ""No measures""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Vimalakirti-Buddhist-Centre---04092020.pdf,Protection,Breach of the Protection Obligation by Vimalakirti Buddhist Centre,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-vimalakirti-buddhist-centre,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2004-B6193 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Vimalakirti Buddhist Centre SUMMARY OF THE DECISION 1. On 14 April 2020, Vimalakirti Buddhist Centre (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware infection that had rendered its data management system inaccessible by the Organisation (the “Incident”). 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. It also admitted that it was in breach of section 24 of the Personal Dara Protection Act (the “PDPA”). 3. The Incident occurred on or about 31 March 2020. Personal data of approximately 4,500 members and 4,000 non-members (total 8,500 individuals) were encrypted by the ransomware. The personal data encrypted included the name, address, contact number, NRIC number, date of birth and donation details of the individuals. 4. The Organisation admitted it did not give due attention to personal data protection, and had neglected to implement both procedural and technical security arrangements to protect the personal data in its possession and control. Consequently, it did not have the relevant security software and/or protocols in place to prevent the ransomware from entering its data management system. 5. In the circumstances, the Deputy Commissioner for Personal Data Protection finds the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 6. Following the incident, the Organisation set up a new server with backup from 21 October 2019. For the data collected by the Organisation from 22 October 2019 to the Incident, the Organisation had retrieved the data from physical file records and restored them in the new server. It also installed a firewall to filter network traffic to and from the new server, and cleaned, restored and reinstalled all computers connected to its data management system. Additionally, the Organisation committed to engage consultants to help produce a data protection manual and train its staff in cyber hygiene and incident response. 7. The Deputy Commissioner for Personal Data Protection notes that the Organisation had admitted to a breach of Protection Obligation under the PDPA, cooperated with the Commission’s investigation and taken prompt remedial action. There was no evidence that the personal data affected in the Incident had been misused in any form. In addition, the Organisation had a backup copy of the encrypted data and did not lose any data as a result of the Incident. Accordingly, the practice of having data backup(s) should be encouraged to prevent organisations from losing data in the event of ransomware. 8. On account of the above, the Deputy Commissioner for Personal Data Protection directs the Organisation to pay a financial penalty of $5,000 within 30 days from the date of this direction (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). 9. In view of the remedial actions taken by the Organisation, the Commission will not be issuing any other directions. ",Financial Penalty,e0f3f4b9ea5a6f7fe98f703d2b0a529a93f64315,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,87,87,1,952,A warning was issued to Horizon Fast Ferry for failing to put in place reasonable security arrangements to protect the personal data in the Organisation’s email account.,"[""Protection"", ""Warning"", ""Others"", ""Password policy"", ""Email account"", ""Phishing""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision----Horizon-Fast-Ferry-Pte-Ltd---27082020.pdf,Protection,Breach of the Protection Obligation by Horizon Fast Ferry,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-horizon-fast-ferry,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1912-B5465 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Horizon Fast Ferry Pte. Ltd. SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (“Commission”) investigated a complaint against Horizon Fast Ferry Pte. Ltd. (the “Organisation”) where the Organisation’s email account, singapore@horizonfastferry.com (the “Email Account”) had sent out phishing emails to its customers (the “Incident”). 2. Investigations revealed that the computer used to access the Email Account was infected with malware. This caused the Email Account to send phishng emails to three customers. Each email contained only the personal data that the customer himself had sent to the Email Account to book ferry tickets. Hence there was no disclosure of other customers’ personal data in the phishing email. 3. The Organisation informed the Commission that it had implemented various security measures prior to the Incident such as updating their anti-virus software regularly. However, investigations revealed that the password to access the Email Account was shared by 11 employees of the Organisation and had not been changed for almost 3 years. This poor management of passwords fell short of what is reasonably required to protect the personal data in the Email Account. 4. The Deputy Commissioner for Personal Data Protection therefore found that the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 for failing to implement reasonable security arrangements to protect the personal data in its possession or under its control. Upon consideration of the facts, a warning was issued to the Organisation. ",Warning,a9f0d524ae6cbf14f4db5cdf1e0ccba42e45b1e0,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,88,88,1,952,"A warning was issued to MRI Diagnostics for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of approximately 4,099 individuals which were publicly available via the internet. Directions were imposed on Clarity Radiology for failing to appoint a data protection officer and not having policies and practices necessary to comply with the PDPA.","[""Protection"", ""Warning"", ""Healthcare"", ""Excel spreadsheet"", ""Access restriction"", ""Patching"", ""Policies""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---MRI-Diagnostics-Pte-Ltd-and-Other---22072020.pdf,Protection,Breach of the Protection Obligation by MRI Diagnostics and Breach of the Accountability Obligation by Clarity Radiology,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-mri-diagnostics-and-breach-of-the-accountability-obligation-by-clarity-radiology,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1811-B2975 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) MRI Diagnostics Pte Ltd (2) Clarity Radiology Pte Ltd SUMMARY OF THE DECISION 1. MRI Diagnostics Pte Ltd (“NovenaMRI”) operates a medical centre that provides magnetic resonance imaging and X-Ray services to patients. In the course of their business, NovenaMRI subscribed to an internet based teleradiology system (“System”) provided by Clarity Radiology Pte Ltd (“Clarity”). In-turn, Clarity engaged an overseas IT vendor (the “IT Vendor”) to maintain the System. 2. On 7 November 2018, a patient of NovenaMRI (“Complainant”) notified the Personal Data Protection Commission (the “Commission”) about an Excel Spreadsheet containing approximately 600 individual’s personal data (including the Complainant’s) that was accessible via the internet (the “Incident”). 3. During the course of investigations, the Commission found two additional Excel Spreadsheets containing similar information as the Excel Spreadsheet reported by the Complainant. A total of approximately 4,099 individuals were affected by the Incident (“Affected Individuals”). The Affected Individuals’ personal data that was exposed to unauthorised access included their names, NRIC numbers and the type of radiology scans performed (collectively, the “Personal Data Sets”). 4. The Commission’s investigations revealed that the Incident was caused by a lapse in the IT Vendor’s processes while carrying out maintenance work on the System. In particular, the IT Vendor had removed access restrictions to a network folder containing the Excel Spreadsheets for the purposes of patching the System, and omitted to reinstate the access restrictions after the patching was completed. Without access restrictions, the Excel Spreadsheets (containing the Personal Data Sets) were indexed by Google’s search engines and exposed to unauthorised access. 5. NovenaMRI was an organisation who had collected the Personal Data Sets from its patients, and had control of the Personal Data Sets at all material times. 6. Section 24 of the Personal Data Protection Act (“PDPA”) requires organisations like NovenaMRI 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 or similar risks (the “Protection Obligation”). In this regard, the Deputy Commissioner for Personal Data Protection (“Deputy Commissioner”) finds NovenaMRI in breach of the Protection Obligation because: (a) When an organisation engages a vendor to supply, modify and/or maintain its IT system, it is required to provide the vendor with sufficient clarity and specifications on the requirements to protect personal data. This is because even if the vendor was not engaged to process personal data on the organisation’s behalf, it may nevertheless handle the personal data incidentally or make decisions that affect the security of the personal data in the course of providing its services. Depending on the circumstances of each case, the organisation should articulate its business requirements concerning the protection of personal data that the IT system will store. This will enable the vendor to assess and recommend the most appropriate and effective method to protect personal data. The organization will then be able to make a decision with access to the right information. Examples of measures include having clauses in written agreements setting out clearly the vendor’s obligations to protect personal data, providing operational guidance and verifying the data protection arrangements implemented by the vendor and/or exercising some form of supervision and oversight over the vendor’s activities; (b) Given the nature of NovenaMRI’s business, which entailed being in possession and/or control of personal data of a sensitive nature (e.g. radiology scans and X-Rays), NovenaMRI should also have conducted a proper assessment of its vendor to satisfy itself that the vendor is wellplaced to protect the personal data it hosts. For example, NovenaMRI could have obtained documentary evidence that the vendor had complied with industry standards with respect to information security (eg the ISO 27001 standard). However, in this case, there was no evidence that NovenaMRI had conducted proper due diligence of the security standards put in place by Clarity, prior to subscribing to the System that provided cloud-based services, including hosting the Personal Data Sets; (c) Although NovenaMRI claimed that it had a written agreement with Clarity, it was unable to produce supporting evidence of this. NovenaMRI’s claim was also disputed by Clarity, who had admitted that there was no written agreement between the parties. In addition, even after NovenaMRI had engaged Clarity, NovenaMRI did not take any steps to verify if Clarity had implemented any data protection arrangements with respect to the System which hosted the Personal Data Sets. 7. As for Clarity, the contracted services from Clarity to NovenaMRI were to provide an archive for Dicom Images and a Web-based radiology information system with scheduling, registration, billing and client access modules. Essentially, Clarity was a “Software as a Service” provider (or what is commonly known as “SaaS-provider”) who had provided its cloud-based services to NovenaMRI. The provision of such technical solutions or deployment of software integrated into the clinical devices of NovenaMRI did not entail the processing of personal data. As such, Clarity was a vendor of NovenaMRI, and not a “data intermediary” of NovenaMRI. As a vendor, Clarity was not responsible for the protection of the Personal Data Sets under the PDPA in respect of the Incident. 8. However, during the course of investigations, Clarity admitted that it had failed to appoint a data protection officer and had not developed or put in place any data protection policies, as required under Sections 11(3) and 12 of the PDPA. Accordingly, Clarity is in breach of Sections 11(3) and 12 of the PDPA. 9. After considering the circumstances of the case, the Deputy Commissioner’s decisions are as follows: (a) to issue a warning to NovenaMRI for its breach of the Protection Obligation. No further directions are necessary as NovenaMRI has ceased its business relationship with Clarity; and (b) to direct that Clarity shall, within 30 days from the date of this decision: i. Appoint a data protection officer; ii. Develop and implement a data protection policy to comply with its obligations under the PDPA; and iii. Inform the Commission within 7 days of the completion of each of the above directions. ",Warning,8906873bf2bf8d94f7c7b01b729303a770c83162,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,89,89,1,952,"A financial penalty of $9,000 was imposed on COURTS for failing to put in place reasonable security arrangements to protect the personal data of its members from unauthorised disclosure on its website. Some members were able to gain access to personal data of another member via a link in an email sent by COURTS.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Inadequate scoping of testing"", ""EDM"", ""Incorrect Setting""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---COURTS-Singapore---140820.pdf,Protection,Breach of the Protection Obligation by COURTS,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-courts,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 17 Case No DP-1909-B4731 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And COURTS (Singapore) Pte Ltd. … Organisation DECISION COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 Lew Chuen Hong, Commissioner — Case No DP-1909-B4731 14 August 2020 Introduction 1 On 6 September 2019, COURTS (Singapore) Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that an individual in its membership programme who had received an Electronic Direct Mail (“eDM”) from the Organisation, was able to access, without authentication, data in another individual’s account after clicking on a link (the “New eDM Link”) in the eDM (the “Incident”). Facts of the Case 2 The Organisation is a well-known consumer electronics and furniture retailer, with a number of stores in Singapore. Its membership programme, known as “homeclub by COURTS” (“Homeclub”) gives its members (“Members”) exclusive access to, among other things, events and discounts. The Organisation regularly sends eDMs to Members with links to specific products on the Organisation’s website (the “Website”). COURTS (Singapore) Pte Ltd 3 [2020] SGPDPC 17 The Organisation used a platform called Salesforce to create and send eDMs (the “Platform”) and the Website ran on the Magento system1 (the “System”), an e-commerce platform. The System generated a dynamic session identifier (“SID”) for each login to Homeclub on the Website. This SID would be used for all subsequent activities within the session. 4 On 31 August 2019, the Organisation sent an eDM to 76,844 Members (the “Affected Members”). This eDM, included for the first time, the New eDM Link, which was meant to direct Members to the Homeclub login page. The purpose of the New eDM Link was for Members to log in to their respective Homeclub accounts to update their membership identifier – Members were required to provide their mobile numbers to replace NRIC numbers that were previously used as the membership identifier. 5 The New eDM Link did not operate as intended, resulting in the Incident. The Commission’s investigations revealed the following: (a) Notwithstanding that the eDM sent on 31 August 2019 included for the first time the New eDM Link, the Organisation continued to use the System in its default setting. The default setting comprised (i) the SID embedded in the URL of the New eDM Link;2 and (ii) cookie settings to be refreshed after 60 minutes. (b) The default setting had not caused any issues when it was used by the Organisation to send marketing eDMs with eDM links directing Members to specific products on the Website. As Members were not 1 The Organisation acquired a license to operate the System from 6 March 2017. 2 This was due to the default setting “Use SID on Storefront” being set to “Yes” 2 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 required to log in to their accounts in order to view the specific products, the SID embedded in the URL and cookie settings did not affect the functioning of the Website. (c) However, the default setting should not have been used for the New eDM Link – it led to the System assuming that every use of the New eDM Link within 60 minutes of a Member’s login was part of the same session. This meant that: (i) If Member X clicks on the New eDM Link and logs into his Homeclub account without logging out within 60 minutes, all other Members who subsequently clicked on the New eDM Link within 60 minutes of Member X’s login would automatically be directed to Member X’s account, without having to authenticate their credentials; and (ii) If Member X logged out while other Members were still logged into Member X’s account, the other Members would only be logged out of Member X’s account if they refreshed a page or navigated to other pages within Member X’s account. 6 According to the Organisation, 128 of the Affected Members clicked on the New eDM Link between approximately 8am on 31 August 2019 and 12.25am on 1 September 2019.3 The Incident led to the risk of unauthorised access and modification of personal data in the Affected Members’ respective Homeclub accounts. In this regard, each Member’s Homeclub account 3 The eDM containing the New eDM Link was sent to Members at approximately 8am on 31 August 2019. The Organisation rectified the error causing the Incident at approximately 12.25am on 1 September 2019. 3 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 comprised (i) account information; and (ii) address book, which collectively contained the following data (“Personal Data Set”): (a) Name; (b) Email address: (c) Mobile Number; (d) Date of Birth (“DOB”); (e) Address; (f) Password; and (g) Transactional information i.e. products previously purchased by a Member. 7 In addition to unauthorised access, the following types of personal data in the Affected Members’ Personal Data Sets were at risk of unauthorised modification as a result of the Incident: (a) The Affected Member’s name, DOB, mobile number and residential address from his/her account information; and (b) The Affected Member’s name, mobile number and residential address from his/her address book. 8 The risk of unauthorised modification in [7(a)] and [7(b)] was possible because password verification was not required to make these changes. Conversely, an Affected Members’ username (which was his/her email address) and password could not be modified without password verification. An Affected Member’s Personal Data Sets also could not be downloaded by another Member 4 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 who had accessed his/her account because there was no download function on the Website. 9 There was no risk of financial loss to Affected Members through the Incident. While it was possible for another Member (who was given access to Member X’s account) to make a purchase through Member X’s account, he/she would have to provide credit card details to complete the purchase. This was because financial information (i.e. credit card details) was not stored in the System, and there was no reward system in Homeclub for the redemption of products or benefits. 10 Based on the Organisation’s investigations into the Incident, there was no evidence of any unauthorised modification to the Affected Members’ Personal Data Sets. Other than the Affected Member who had notified the Organisation of the Incident, the Organisation did not receive any further complaints or feedback. 11 Upon being notified of the Incident on the same day, the Organisation promptly took the following remedial actions: (a) Fixed the error that caused the Incident at approximately 12:25am on 1 September 2019 by changing the setting for “Use SID on Storefront” to “No”; (b) Implemented password verification for any changes to Members’ account information and address book;4 4 This came into effect on 6 January 2020. 5 COURTS (Singapore) Pte Ltd (c) [2020] SGPDPC 17 Put in place a standard operating procedure (“SOP”) to ensure correct link insertion into eDMs to protect personal data. For eDM links that are supposed to lead to a login page, checks will be conducted to ensure that there will be multiple concurrent user testing; (d) Took steps to engage an external vendor to work on security matters (including data protection security), and disseminate this information to its employees; and (e) Emailed the 128 Affected Members who had clicked on the New eDM Link to inform them of the Incident. The Commissioner’s Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 12 Section 24 of the PDPA provides that 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 or similar risks (the “Protection Obligation”). It is not disputed that the Organisation had possession and control of the Personal Data Sets at the material time. The Commission’s investigations revealed that the Organisation failed to put in place reasonable security arrangements to protect the Personal Data Sets for the reasons explained below. 13 First, the Organisation failed to conduct adequate testing before implementation. As mentioned at [4], this was the first time the Organisation included in its eDM, the New eDM Link to direct Members to the Homeclub login page. There was only 1 employee in the Organisation’s digital marketing team that was in charge of creating the New eDM Link and testing it prior to its 6 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 launch. The employee conducted a limited test of sending the eDM containing the New eDM Link to himself – the New eDM Link operated as intended, directing the employee to the Homeclub login page. This limited test was clearly inadequate. As emphasized in the Commission’s previous decisions, an organisation should ensure that testing scenarios are properly scoped. In particular, pre-launch testing of processes or systems needs to mimic expected real world usage, including foreseeable scenarios in a normal operating environment when the changes are introduced.5 In the present case, the Organisation intended to send the eDM to a very large number of Members. It is therefore foreseeable that testing scenarios should include multiple sequential logins or even concurrent logins to the Homeclub login page at peak usage. If the Organisation had tested the New eDM Link to approximate this real world scenario, the Incident would have likely come to light at that stage. 14 Second, the Organisation failed to assess the appropriateness of the default settings in the System for the New eDM Link. (a) The Organisation used the default setting in the System for the New eDM Link without any assessment on its implications. As mentioned in the Commission’s Guide to Securing Personal Data in Electronic Medium at [17.5] and previous decisions,6 when using readymade software, organisations are required to obtain a clear understanding of the intended purpose of the software, how the software 5 See Re Option Gift Pte Ltd [2019] SGPCPC 10 at [15]; Re AIA Singapore Pte Limited [2019] SGPDPC 20 at [15] and L’Oreal Singapore Pte. Ltd. Case No. DP 1812-B3091, Summary of the Decision at [3] 6 See for example Re DS Human Resource Pte Ltd [2019] SGPDPC 16 at [9] 7 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 functions and how to configure the software correctly. The Organisation failed to do so in the present case; (b) There was an option in the Platform to automatically generate eDM links without any SID in the URL. The Organisation did not fully appreciate the differences in using this option to create links that are embedded within an eDM, as compared with the effects of embedding SIDs as part of the URL for the New eDM Link. Due to the lack of understanding the differences between these out-of-the-box features of the commercial off-the-shelf product that he was using, the employee in charge of creating the New eDM Link was not aware that the appropriate method was to use the option in the Platform that generated eDM links without SID in the URL. Instead, the employee manually copied the New eDM Link (which contained the SID) from the internet browser for insertion into the eDM; and (c) While the Organisation had in place a process for a second-level check on the content and layout of the eDM, the nature of this type of checks would not have been effective in picking up the more technical issues relating to embedded SID in the New eDM Link. Understanding fully the features of the commercial off-the-shelf product in use and properly scoping the testing scenarios during user acceptance testing would have been the more appropriate and effective way to avoid and catch such errors. 15 For the reasons above, the Commissioner found the Organisation in breach of section 24 of the PDPA. 8 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 Representations by the Organisation 16 In the course of settling this decision, the Organisation made representations on the amount of financial penalty that the Commissioner intended to impose. The Organisation raised the following factors for the Commissioner’s consideration: (a) The Organisation takes a serious view of its obligations under the PDPA, and has taken the necessary remedial actions to prevent future data protection incidents from occurring. Personal data protection remains a priority for the Organisation even during these uncertain and turbulent times amidst the COVID-19 pandemic; and (b) The COVID-19 pandemic has had an adverse impact on the business of the Organisation, resulting in a significant loss of revenue. Specifically, due to “circuit breaker” measures imposed by the government, the Organisation closed all 14 of its retail outlets in Singapore from 7 April 2020 to 19 June 2020. Further, its operating overheads remained largely unchanged as labour accounted for significant portion of its costs, and the Organisation has maintained a commitment to retaining employees so as to protect their livelihoods. Even with the recent reopening of its physical stores, the Organisation continues to have a negative outlook of its business due to the impact of COVID-19 on the economy and a challenging retail landscape. 17 Having carefully considered the representations, the Commissioner has decided to reduce the financial penalty to the amount set out at [19]. The quantum of financial penalty has been calibrated after due consideration of the Organisation’s financial circumstances due to the unprecedented challenges faced by businesses amid the current Covid-19 pandemic, bearing in mind that 9 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 financial penalties imposed should not be crushing or cause undue hardship on organisations. Although a lower financial penalty has been imposed in this case, the quantum of financial penalty should be treated as exceptional and should not be taken as setting any precedent for future cases. The Commissioner’s Directions 18 In determining the directions, if any, to be imposed on the Organisation under Section 29 of the PDPA, the Commissioner took into account as an aggravating factor that this is the second time the Organisation has been found in breach of the Protection Obligation.7 The Commissioner also took into account the following mitigating factors: (a) The Organisation cooperated with the investigations and provided prompt responses to the Commission’s requests for information; (b) The Organisation implemented remedial actions swiftly to address the Incident; and (c) The Members’ Personal Data Sets was exposed to the risk of unauthorised access and/or modification for a limited period of less than one day. 19 Having considered all the relevant factors of this case, the Commissioner hereby directs the Organisation to pay a financial penalty of S$9,000 within 30 days from the date of this direction, failing which interest, at the rate specified in the Rules of Court in respect of judgment debts, shall accrue and be payable 7 See Re Courts (Singapore) Pte Ltd [2019] SGPDPC 4 10 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 on the outstanding amount of the financial penalty until it is paid in full. The Commissioner has not set out any further directions given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 11 ",Financial Penalty,7b84d1c0b092675d5ee94570a80a3de93072541d,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,90,90,1,952,A warning was issued to the Singapore Medical Association for failing to put in place reasonable security arrangements to prevent the unauthorised access of 68 individuals’ personal data which were forwarded to an external email address without authorisation.,"[""Protection"", ""Warning"", ""General (eg. Chamber of Commerce)"", ""Email forwarding"", ""Password policy""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Medical-Association---21072020.pdf,Protection,Breach of the Protection Obligation by Singapore Medical Association,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-obligation-by-singapore-medical-association,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2001- B5770 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Medical Association SUMMARY OF THE DECISION 1. On 31 January 2020, Singapore Medical Association (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that the personal data of 68 individuals in 137 emails had been forwarded to an external email address without authorisation between 28 and 30 January 2020. The personal data comprised National Registration Identification Card numbers, dates of birth, indemnity coverage, period of coverage, educational information and financial transaction information. 2. The Organisation believed an unauthorised user (“UU”) gained entry into the affected Microsoft Office 365 email account by a brute force attack but did not have the system logs to confirm this. Regardless, the unauthorised entry enabled the UU to create an email rule to forward received emails to the external email address. 3. It was found that the Organisation failed to conduct periodic security reviews of its IT system. Consequently, it missed the opportunity to detect the following security issues that could have prevented the incident: a. There was no periodic change to the passwords of email accounts. As an example, the password to the affected account had not been changed since first use in November 2013. b. The Organisation collected financial information such as bank account details and swift codes and should have considered, as part of a security review, whether it needed to enhance security measures. For example, encryption of emails and/or attachments containing such sensitive personal data. c. A reasonable security review would also have noted the absence of security arrangements against brute force attacks. Common examples of anti-brute force measures include limiting the number of failed login attempts and account lockouts. Without anti-brute force measures, a password-protected account could be subjected to unlimited and uninterrupted automated login attempts from the Internet. Given sufficient time, the attacker will succeed in arriving at the correct password. 4. The Deputy Commissioner for Personal Data Protection therefore found that the Organisation did not adopt reasonable steps to protect personal data in its possession or under its control against risk of unauthorised access. The Organisation was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. Upon consideration of the facts, a warning was issued to the Organisation. No directions are required as the Organisation had taken actions to address the gaps in its security arrangements. ",Warning,6c2d54a99a7623a26140ad101ee1ad4d4c2a792d,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,91,91,1,952,"A financial penalty of $20,000 was imposed on Civil Service Club for failing to put in place reasonable security arrangements to protect its members’ personal data. A web directory containing members’ profile photographs and their respective NRIC/FIN numbers was found to be publicly accessible.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""Access control"", ""Public access""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Civil-Service-Club-01042020.pdf,Protection,Breach of the Protection Obligation by Civil Service Club,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-obligation-by-civil-service-club,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 15 Case No DP-1907-B4180 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Civil Service Club … Organisation DECISION Civil Service Club [2020] SGPDPC 15 Tan Kiat How, Commissioner — Case No DP-1907-B4180 1 April 2020 Introduction 1 On 2 July 2019, the Personal Data Protection Commission (the “Commission”) received a complaint from a member (the “Complainant”) of the Civil Service Club (the “Organisation”). According to the Complainant, when he accessed his virtual membership card (the “Virtual Card”) through the Organisation’s membership web portal on the same day – “https://gateway.csc.sg” (the “Membership Portal”), he discovered that he was able to access a web directory – “https://gateway.csc.sg/webclub/facilities/tmp” (the “Directory”). The Directory contained profile photographs of other members (and their respective NRIC/FIN numbers which were used as file names for their profile photographs), including the Complainant’s (the “Incident”). Facts of the Case 2 The Organisation is a social club for all Public Service officers in Singapore, and also welcomes staff of Social Service Organisations and the general public to join as associate members. Membership benefits include booking of sports facilities, functions rooms and chalets, as well as members’ rates for club events and recreational activities. Civil Service Club 3 [2020] SGPDPC 15 In October 2009, the Organisation engaged the services of an IT vendor (the “Vendor”) to develop its Club Management System (“CMS”). The Vendor’s scope of work was set out in a contract entered into between the parties in November 2009 (the “Contract”). The Organisation launched the CMS, including the Membership Portal, in stages. On 1 March 2019, the Organisation launched the Virtual Card on the Membership Portal, and members’ NRIC/FIN numbers were used as file names for members’ profile photographs. 4 The Organisation has 2 separate servers hosted in its premises – the “enterprise” server (the “Enterprise Server”) and the “gateway” server (the “Gateway Server”). The Organisation stored its business and personal data on the Enterprise Server. The Gateway Server was specifically deployed to isolate the rest of the Organisation’s network (which may contain personal data or business data) from the public. 5 When a member accessed his/her Virtual Card, the software on the Membership Portal retrieved a copy of the member’s profile photograph from the Enterprise Server and stored it temporarily in the Directory. The Directory resided in the Gateway Server. The files in the Directory (including members’ profile photographs) were designed such that they could not be accessed by the public. If the member logged out from the Membership Portal, his/her profile photograph would be deleted from the Directory at that point in time. However, if the member closed the web browser directly without logging out of the Membership Portal, his/her profile photograph in the Directory would only be deleted during the monthly “housekeeping” process. Other than members’ profile photographs stored temporarily in the Directory (and their respective NRIC/FIN numbers which were used as file names for their profile photographs), the Gateway Server did not contain any other personal data. 2 Civil Service Club 6 [2020] SGPDPC 15 Prior to the Incident, there was an issue arising from members submitting their profile photographs in different file formats and sizes for the Virtual Card. The Vendor planned to monitor the situation for three months until 9 July 2019 and troubleshoot the issue during this period. 7 At first, the Vendor attempted to perform troubleshooting in a test environment using dummy photographs. However, the test environment could not replicate the issue with the Virtual Cards. In order to observe members’ behaviour patterns when they accessed their Virtual Cards and to collect statistics on photograph file sizes and time of creation, the Vendor enabled public access to the Directory on 3 occasions so that it could perform troubleshooting remotely. The Vendor also postponed the monthly “housekeeping"" process for the Directory by pushing it back from June 2019 to July 2019. 8 The Vendor only required a few minutes of remote access to perform remote troubleshooting, and had, as part of its testing procedures, a requirement that engineers restore all changes made during testing. On the first 2 occasions, public access to the Directory was disabled within 15 minutes. However, on 24 June 2019 (i.e. the 3rd occasion of remote troubleshooting), the Vendor’s engineer omitted to disable public access to the Directory but erroneously reported that he had done so. As a result, approximately 1,770 members’ profile photographs (and their respective NRIC/FIN numbers which were used as file names for their profile photographs) (the “Members Data”) could be accessed by anyone who obtained the URL to the Directory, including the Complainant on the date of the Incident. 9 Upon being notified of the Incident, the following remedial actions were taken: 3 Civil Service Club (a) [2020] SGPDPC 15 The Organisation and the Vendor took immediate action to disable access to the Directory; (b) The Vendor enhanced the “housekeeping” processes for the Directory such that the members’ profile photographs are deleted immediately after displaying them on the respective members’ Virtual Cards (i.e. there are no files containing members’ profile photographs stored in the Directory at any time); and (c) The Organisation discontinued the use of NRIC/FIN numbers as membership numbers, and the members’ profile photographs are no longer named using NRIC/FIN numbers. The Commissioner’s Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 10 As a preliminary point, the Organisation owned the Enterprise Server and Gateway Server, and was in possession and control of the Members Data at all material times. While the Organisation had engaged the Vendor to develop the CMS, which included the Membership Portal, the scope of the Vendor’s work did not involve processing of any personal data on behalf of the Organisation. The Vendor was therefore not a data intermediary, and the responsibility to protect the Members Data fell squarely on the Organisation. 11 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) provides that 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 or similar risks (the “Protection Obligation”). The Organisation failed to put in place reasonable 4 Civil Service Club [2020] SGPDPC 15 security arrangements to protect the Members Data for the reasons explained below. 12 As mentioned at [3], the Organisation started engaging the Vendor’s services in October 2009. The Contract between the parties was entered into before the PDPA came into full force on 2 July 2014 (the “Appointed Day”). Before the Appointed Day, the Data Protection Provisions of the PDPA (i.e. Parts III to VI of the PDPA) were not in force, and the Organisation was not subject to these provisions in relation to personal data in its possession or control. However, after the Appointed Day, it became incumbent on the Organisation to take proactive steps to comply with the Data Protection Provisions of the PDPA in respect of the existing personal data held in its possession or control, as well as any new personal data that may come into its possession or control. It was not enough for the Organisation to leave matters status quo, if this would not enable it to meet the requirements and standards of the Protection Obligation.1 13 In the present case, the Commission’s investigations revealed that after the Appointed Day, the Organisation’s engagement of the Vendor’s services included work in relation to the developing and troubleshooting of the Virtual Cards on the Membership Portal. According to the Organisation, it was not aware that (i) Members Data had been stored temporarily in the Directory; and (ii) the Vendor’s troubleshooting involved enabling public access to the Directory. Notwithstanding this, given that the Organisation’s engagement of the Vendor’s services included work in relation to the Virtual Cards that contained Members Data, the Vendor (although not engaged to process the 1 See Re Social Metric Pte Ltd [2017] SGPDPC 17 at [10] – [11] 5 Civil Service Club [2020] SGPDPC 15 Members Data) may nevertheless handle the Members Data incidentally or make software system design decisions that affect the security of the Members Data in the course of providing its services. 14 In the circumstances, and in order for the Organisation to comply with the Protection Obligation, the Organisation should have ensured that it provided sufficient clarity and specifications on requirements to the Vendor (when developing and troubleshooting the CMS, Membership Portal and Virtual Cards) to protect the Members Data. There are various ways that the Organisation could have done so: (a) The Contract was entered into by the parties before the Appointed Day and did not contain any provisions on the protection of personal data.2 In view of the scope of services provided by the Vendor after the Appointed Day as set out at [13], the Organisation could have reviewed the Contract to include clauses setting out requirements for the Vendor to protect the Members Data. As highlighted in the Commission’s Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1], organisations should emphasize the need for personal data protection to their IT vendors by making it part of their contractual terms. In this regard, the Organisation could have adapted relevant clauses from the Commission’s Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data (published 20 July 2016) to suit the Organisation’s particular circumstances and needs. 2 The Contract contained only a confidentiality clause requiring each party to protect information identified by the other party as confidential. 6 Civil Service Club (b) [2020] SGPDPC 15 Further and/or in the alternative, the Organisation could have reviewed and revised the requirements specifications and software systems design documentation to include (i) requirements relating to how personal data (including the Members Data) should be handled as part of the design and layout the CMS and the Membership Portal;3 and (ii) technical and other measures that protect the personal data (including the Members Data). 15 From the Appointed Day, the Organisation’s failure to take any reasonable steps to ensure sufficient obligations are imposed on the Vendor (when developing and troubleshooting the CMS, Membership Portal and Virtual Cards) to protect the Members Data was a breach of its obligations under section 24 of the PDPA. A period of about five years had elapsed since 2 July 2014 to 2 July 2019. The Organisation, as owner of the CMS, should have included it as part of its personal data asset inventory and ensured that its data protection policies covered personal data held in the CMS. Had this been done, the Organisation would have identified these gaps in the business requirements for the CMS, which would have set it down the path to rectifying these gaps through one or both of the options discussed in the preceding paragraph. The Organisation, as owner of the CMS, is responsible for identifying the omission and articulating its business requirements relating to the protection of personal data stored in the CMS. This would have led to action by the Vendor in recommending technical fixes to enhance the CMS. It is the failure to identify the omission and articulate business requirements, and for a not-trivial period of five years, that is the gravamen of the Organisation’s breach of the PDPA. 3 See Commission’s Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1] 7 Civil Service Club [2020] SGPDPC 15 The Commissioner’s Directions 16 In determining the directions, if any, to be imposed on the Organisation under Section 29 of the PDPA, the Commissioner took into account the following mitigating factors: (a) The Organisation cooperated with investigations; (b) There was limited risk to the Members Data arising from the Incident because (i) there was only one complaint received; and (ii) even if the Incident had not occurred, the Directory’s exposure to public access would have been discovered and rectified by 9 July 2019 because the Organisation and Vendor had planned to carry out a security audit on that date; and (c) The Organisation took prompt remedial action to rectify the Incident. 17 Having considered all the relevant factors of this case, the Commissioner directs the Organisation to pay a financial penalty of S$20,000 within 30 days from the date of this direction, 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 the financial penalty until it is paid in full. The Commissioner has not set out any further directions given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ",Financial Penalty,f0321512ea7fdd1c3b0f5d62f673deb9411f9019,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,92,92,1,952,"A financial penalty of $10,000 was imposed and a direction was issued to Grabcar for failing to put in place reasonable security arrangements to prevent the unauthorised access of GrabHitch drivers’ and passengers’ personal data via its mobile application.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Transport and Storage"", ""Mobile application"", ""Code review""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Grabcar-Pte-Ltd---24072020.pdf,Protection,Breach of the Protection Obligation by Grabcar,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-obligation-by-grabcar,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 14 Case No. DP-1909-B4675 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Grabcar Pte Ltd … Organisation DECISION Grabcar Pte Ltd [2020] SGPDPC 14 Yeong Zee Kin, Deputy Commissioner — Case No. DP-1909-B4675 21 July 2020 Introduction 1 Grabcar Pte Ltd (the “Organisation”) is a Singapore-based company offering ride-hailing transport services, food delivery and digital payment solutions through its mobile application (the “Grab App”). The Grab App also provides a carpooling option referred to as “GrabHitch”. GrabHitch matches a passenger with a driver willing to give a lift to the passenger (on the way to the driver’s destination) in return for a fee. On 30 August 2019, the Organisation notified the Personal Data Protection Commission (the “Commission”) that, for a short period of time on the same day, profile data of 5,651 GrabHitch drivers was exposed to the risk of unauthorised access by other GrabHitch drivers through the Grab App (the “Incident”). Facts of the Case 2 The Organisation’s investigations traced the cause of the Incident to the deployment of an update to the Grab App on 30 August 2019 (the “ Update”). The purpose of the Update was to address a potential vulnerability discovered within the Grab App, namely, the application programming interface (“API”) endpoint (/users/{userID}/profile) (the “URL”) that had allowed GrabHitch Grabcar Pte Ltd [2020] SGPDPC 14 drivers to access their data, contained a ‘userID’ that could potentially be manipulated to allow access to other GrabHitch driver’s data.1 3 In order to fix the vulnerability, the Update removed the variable ‘userID’ from the URL which shortened it to a hard-coded ‘/users/profile’. However, the Update failed to take into account the URL-based caching mechanism in the Grab App. This caching mechanism (which was configured to refresh every 10 seconds) served cached content in response to data requests to reduce the load of direct access to the Organisation’s database. 4 With the deployment of the Update, all URLs in the Grab App ended with “/users/profile”. Without the variable ‘userID’ in the URL (which directed data requests to the correct GrabHitch driver’s accounts), the caching mechanism could no longer differentiate between GrabHitch drivers. Consequentially, the caching mechanism provided the same data to all GrabHitch drivers for 10 seconds before new data was retrieved from the Organisation’s database and cached for the next 10 seconds. 5 As a result of the Incident, a total of 21,541 GrabHitch drivers’ and passengers data was exposed to the risk of unauthorised access (collectively “Personal Data Sets”): (a) Profile pictures; (b) Passenger names; (c) Vehicle plate number; and 1 According to the Organisation, there was no evidence that this vulnerability had been exploited. 2 Grabcar Pte Ltd (d) 6 [2020] SGPDPC 14 Wallet balance comprising journal history of ride payments. In addition to the Personal Data Sets, other data that was exposed to the risk of unauthorised access during the Incident included GrabHitch booking details such as addresses and pickup and drop-off times; and driver details such as total rides, vehicle model and make. 7 Upon being notified of the Incident, the Organisation took the following remedial actions: (a) Rolled back the Grab App to the version prior to the Update within approximately 40 minutes; (b) Notified 5,651 GrabHitch drivers of the Incident on the same day; 2 (c) Increased the minimum “cash out” amount for wallets in GrabHitch to S$200,000 to prevent unauthorised transfers; (d) Deployed a new update for the Grab App on 10 September 2019; (e) Reviewed its testing procedures including implementing mandatory automated tests for all API endpoints dealing with personal data; (f) Updated governance procedures concerning deployment and security verification on changes to IT systems and applications; and 2 The Organisation’s initial investigations indicated that 5,651 GrabHitch drivers’ data was exposed to the risk of unauthorised access due to the Incident. Following further investigations, the Organisation determined that up to 21,541 GrabHitch drivers’ and passengers data was exposed to the risk of unauthorised access. 3 Grabcar Pte Ltd (g) [2020] SGPDPC 14 Embarked on an architecture review of its legacy applications, and relevant codes which had not been reviewed for an extended period of time. The Commissioner’s Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 8 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) provides that 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 or similar risks. It is not disputed that the Organisation had possession and control of the Personal Data Sets at the material time. 9 In the context of the present case, given that the Organisation made changes to its IT system that processed the Personal Data Sets, it is obliged to put in place reasonable security arrangements to prevent any compromise to the Personal Data Sets.3 The Organisation failed to do so for the reasons explained below. 10 First, the Organisation did not put in place sufficiently robust processes to manage changes to its IT system that may put the personal data it was processing at risk. This was a particularly grave error given that this is the 3 Re Flight Raja Travels Singapore Pte Ltd [2018] SGPDPC 16 at [8]. 4 Grabcar Pte Ltd [2020] SGPDPC 14 second time the Organisation is making a similar mistake, albeit with respect to a different system.4 (a) The Organisation introduced changes to the Grab App (through the Update) without understanding how the changes would operate with existing features of the Grab App and its broader IT system, including the caching mechanism. (b) In particular, the Update involved changes to the URL (i.e. removing the variable ‘userID’). The variable ‘userID’ in the URL had the function of ensuring that data requests (including the Personal Data Sets) were directed to the correct GrabHitch drivers’ accounts. However, the Organisation implemented the Update without making an assessment whether the Grab App would continue to direct data requests to the correct GrabHitch drivers’ accounts without the variable ‘userID’ in the URL. 11 Second, the Organisation did not conduct properly scoped testing before the Update to the Grab App was deployed. (a) As found in the Commission’s previous decisions, organisations are obliged to conduct properly scoped testing before new IT features or changes to IT systems are deployed. These tests need to mimic real world usage, including foreseeable scenarios in a normal operating 4 See Re Grabcar Pte Ltd [2019] SGPDPC 15 at [17] where it was found that the Organisation did not have adequate measures in place to detect whether the changes it made to a system that held personal data introduced errors that put the personal data it was processing at risk. 5 Grabcar Pte Ltd [2020] SGPDPC 14 environment when the changes are introduced.5 Such tests prior to deployment are critical to enable organisations to detect and rectify errors in the new IT features and/or be alerted to any unintended effects from changes that may put personal data at risk.6 (b) In the present case, the Organisation admitted that it did not conduct tests to simulate multiple users accessing the Grab App, whether concurrently or consecutively. The Organisation also admitted that it did not conduct any specific test to verify how the caching mechanism would work in tandem with the Update. (c) In view of the large number of GrabHitch drivers, multiple users logging in concurrently or consecutively are foreseeable scenarios that the Organisation should have simulated during its testing of the Update prior to deployment. Properly scoped pre-launch tests would have included an assessment of how the caching mechanism may affect the intended operation of the Update because the caching mechanism can affect data requests returned to the GrabHitch drivers. 12 For the reasons above, I find the Organisation in breach of section 24 of the PDPA. 5 Re AIA Singapore Pte Limited [2019] SGPDPC 20 at [15] and L’Oreal Singapore Pte. Ltd. Case No. DP 1812-B3091, Summary of the Decision at [3]. 6 See for example Re Flight Raja Travels Singapore Pte Ltd [2018] SGPDPC 16 and Re Singapore Telecommunications Limited [2019] SGPDPC 36. 6 Grabcar Pte Ltd [2020] SGPDPC 14 The Deputy Commissioner’s Directions 13 In determining the directions, if any, to be imposed on the Organisation under Section 29 of the PDPA, I took into account as a mitigating factor that the Organisation cooperated with the investigation, and was prompt and forthcoming in its response to queries during the Commission’s investigations. I have also taken into consideration that this is the fourth time the Organisation has been found in breach of Section 24 of the PDPA. 7 Given that the Organisation’s business involves processing large volumes of personal data on a daily basis, this is a significant cause for concern. 14 Having considered all the relevant factors of this case, I direct the Organisation to pay a financial penalty of S$10,000 within 30 days from the date of this direction, 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 the financial penalty until it is paid in full. In order to reduce the risk of another data breach, I also direct the Organisation to put in place a data protection by design policy for its mobile applications within 120 days of the date of this direction. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 7 The previous decisions being Re Grabcar Pte Ltd [2018] SGPDPC 23; Re Grabcar Pte Ltd [2019] SGPDPC 14; and Re Grabcar Pte Ltd [2019] SGPDPC 15. 7 ","Financial Penalty, Directions",eb17aef1e75850888d8ec821aa37aebe142109b2,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,94,94,1,952,"A financial penalty of $5,000 was imposed on Singapore Red Cross for breaches of the PDPA. First, the Organisation failed to put in place reasonable security arrangements to protect the personal data of its blood donors. Second, it was also found to be retaining personal data which was no longer necessary for legal or business purposes.","[""Protection"", ""Financial Penalty"", ""Social Service"", ""Security"", ""Retention""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Red-Cross---05052020.pdf,Protection,Breach of the Protection and Retention Limitation Obligations by Singapore Red Cross,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-and-retention-limitation-obligations-by-singapore-red-cross,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 16 Case No DP-1905-B3865 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Red Cross Society … Organisation DECISION Singapore Red Cross Society [2020] SGPDPC 16 Singapore Red Cross Society [2020] SGPDPC 16 Tan Kiat How, Commissioner — Case No DP-1905-B3865 5 May 2020 Facts of the Case 1 Singapore Red Cross Society (the “Organisation”) operates a website at http://www.redcross.sg (the “Website”) which allows the public to make appointments for blood donations. For this purpose, the Organisation collects personal data of individuals such as their names, contact numbers, email addresses and blood types (the “Personal Data”). The Personal Data was stored in the Organisation’s blood donor appointment database (the “Database”) accessible via the Website. 2 On 9 May 2019, the Organisation notified the Personal Data Protection Commission (the “Commission”) that unauthorised individual(s) accessed and ex-filtrated the Personal Data of approximately 4,297 individuals (“Affected Individuals”) from the Database (the “Incident”). 3 Upon being notified of the Incident, the Organisation took the following remedial actions: (a) Removed the appointment booking system on its Website in order to temporarily cease its collection of Personal Data through that channel; and (b) Revised and strengthened its internal procedures to comply with the PDPA. 1 Singapore Red Cross Society [2020] SGPDPC 16 The Commissioner’s Findings and Basis for Determination The Organisation admitted that it had contravened Section 24 of the PDPA 4 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) provides that 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 or similar risks (the “Protection Obligation”). 5 The Organisation admitted that it failed to implement adequate security measures to protect the Personal Data stored in the Database, and had breached the Protection Obligation. In particular, the Organisation admitted to the following specific mistakes: (a) The Organisation employed a vendor to develop the Website. However, there was a lack of supervision over the vendor’s work which led to a failure to detect the presence of a phpMyAdmin database administration tool (the “Tool”) which was used to manage the Database. There was also no password management policy requiring strong passwords of sufficient length and complexity during the development phase. This resulted in a weak password (i.e. “12345”) being set for the Tool;1 and (b) The Organisation did not conduct any regular security reviews, e.g. vulnerability assessment, on its systems that would identify applications that it did not need. 2 Consequentially, the Organisation did not realise that the Tool remained connected to the Website even after development of the Website had been completed. This allowed unauthorised individual(s) to gain access to the Database through the Tool which had a weak password. 1 For examples of the Commission’s previous decisions on the need for proper password management policies, see Re Orchard Turn Developments Pte Ltd [2017] SGPDPC 12 at [35] – [36] and Re Spize Concepts Pte Ltd [2019] SGPDPC 22 at [15]. 2 For examples of the Commission’s previous decisions on the requirement for periodic security reviews, see Re Watami Food Services Singapore Pte Ltd [2018] SGPDPC 12 at [6]; Re WTS Automotive Services [2018] SGPDPC 26 at [18]; Re Bud Cosmetics [2019] SGPDPC 1 at [24]; Re Chizzle Pte Ltd [2019] SGPDPC 44 at [6]. 2 Singapore Red Cross Society [2020] SGPDPC 16 The Organisation admitted that it had contravened Section 25 of the PDPA 6 Under Section 25 of the PDPA, an organisation is obliged to cease to retain its documents containing personal data, or remove the means by which the personal data can be associated with particular individuals, as soon as it is reasonable to assume that: (a) the purpose for which the personal data was collected is no longer served by retaining the data; and (b) the retention is no longer necessary for legal or business purposes (the “Retention Limitation Obligation”). 7 The Organisation admitted that there had been unnecessary retention of Personal Data of approximately 900 Affected Individuals, and this was a breach of the Retention Limitation Obligation. (a) Prior to the Incident, the Organisation intended to purge Personal Data of these 900 Affected Individuals from the Database. However, the Organisation provided wrong instructions to its vendor for the purging exercise. The Organisation had instructed its vendor to only remove some data elements instead of entire records of the 900 Affected Individuals’ Personal Data; and (b) The Organisation also did not conduct any verification checks to ensure the purging exercise was properly carried out. As a result, the Organisation failed to detect that the Database still retained records of the 900 Affected Individual’s Personal Data. 8 In view of the above, the Commissioner found the Organisation in breach of sections 24 and 25 of the PDPA. The Organisation’s Representations 9 In the course of settling this decision, the Organisation made representations on the amount of financial penalty that the Commissioner intended to impose. The Organisation raised the following factors for the Commissioner’s consideration: 3 Singapore Red Cross Society (a) [2020] SGPDPC 16 The Organisation is a charity that depends on public donations to run its operations and programmes, all which are for the benefit of the community. Such a high financial penalty would set the Organisation back significantly, and would mean less help for the disadvantaged and the vulnerable; (b) The Organisation takes its obligations under the PDPA seriously and already had in place various IT security measures and had embarked on a consultancy to ensure its compliance with the PDPA even before the Incident; (c) The attackers were skilled hackers who utilised sophisticated hacking tools to exploit a weak administrator password for the Tool which left the Database vulnerable to unauthorised access. The Tool was never used by the Organisation’s staff and was likely created during the development stage of Database; (d) Upon being informed of the Incident, the Organisation immediately made a police report and promptly informed various public authorities including the Health Sciences Authority and the Commission. The Organisation has also extended full cooperation and provided prompt responses during the Commission’s investigations; (e) The Organisation promptly informed all affected individuals and there were no registered complaints on the case; (f) Since the Incident, the Organisation had taken immediate steps to remove the Database from the Website and put in place more security measures. This included layered and restricted access, isolation of sensitive systems at the network level, password training for staff, review and strengthening of standard operating procedures, practising more stringent oversight of vendor actions, implementation of vulnerability assessment and penetration testing regime for critical systems before deployment and on a regular basis annually; and (g) The financial penalty that the Commissioner intended to impose seemed excessive in light of previous decisions for similar or even more serious breaches. 4 Singapore Red Cross Society 10 [2020] SGPDPC 16 With respect to the representations on the nature and purpose of the Organisation, the fact that the Organisation is a charity cannot be a mitigating factor, and its charitable status cannot lower the standard expected of it in complying with its obligations under the PDPA. The admitted failures on the Organisation’s part at [5] clearly fell short of the standard of protection required for the Personal Data stored in the Database. 11 As for the Organisation’s representations comparing the present case to previous decisions, it needs only to be said that each decision is based on the unique facts of each case. The decision in each case takes into consideration the specific facts of the case so as to ensure that the decision and direction(s) are fair and appropriate for that particular organisation. The Commissioner’s Directions 12 Having carefully considered the representations, the Commissioner has decided to reduce the financial penalty to the amount set out at [13]. The quantum of financial penalty has been determined after due consideration of the appropriate weight to be given to: (a) the Organisation’s upfront voluntary admission of liability which significantly reduced the time and resources required for investigations under the Expedited Breach Decision procedure;3 and (b) the Organisation’s comprehensive remedial actions at [9(f)] to address the inadequacies in its procedures and processes that contributed to the Incident. 13. Taking into account all the relevant facts and circumstances, the Commissioner directs the Organisation to pay a financial penalty of $5,000 within 30 days from the date of the direction, 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 the financial penalty until the financial penalty is paid in full. Although a lower financial 3 See the Commission’s Guide on Active Enforcement at page 21 5 Singapore Red Cross Society [2020] SGPDPC 16 penalty has been imposed in this case, this is exceptional and should not be taken as setting any precedent for future cases. 14. In view of the remedial measures taken by the Organisation, the Commissioner has not imposed any other directions. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 6 ",Financial Penalty,7bdf02b93a7a9d9facf04ceb3c80a66892a08642,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,95,95,1,952,"A financial penalty of $5,000 was imposed on Singapore Accountancy Commission for failing to put in place reasonable security arrangements to prevent the unauthorised access of 6,541 Singapore Chartered Accountant Qualification programme personnel and candidates’ personal data.","[""Protection"", ""Financial Penalty"", ""Professional"", ""Scientific and Technical"", ""Unintended recipient"", ""Email attachments""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Accountancy-Commission---22062020.pdf,Protection,Breach of the Protection Obligation by Singapore Accountancy Commission,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-singapore-accountancy-commission,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1911-B5296 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Accountancy Commission SUMMARY OF THE DECISION 1. On 18 November 2019, Singapore Accountancy Commission (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that a folder containing personal data of 6,541 Singapore Chartered Accountant Qualification programme personnel and candidates was mistakenly enclosed in emails sent to 41 unintended recipients between 12 June 2019 and 22 October 2019. The folder comprised information such as names, National Registration Identification Card numbers, dates of birth, contact details, education and employment information and Singapore Chartered Accountant Qualification examination results. Following the incident, 41 unintended recipients confirmed deletion of the email and folder they each received. 2. The Organisation admitted to a lack of robust processes to protect personal data when sending emails. The staff involved in the sending of the emails were not informed of the Organisation’s personal data policies as part of their induction training. The Organisation’s data protection policies and procedures were not translated into security arrangements for protection of personal data. There were, for example, no second-tier or supervisory checks or technical measures to reduce the risk of sending content with personal data to unintended parties at the time of the incident. 3. Following the incident, the Organisation undertook remediation. This included training sessions on cybersecurity and personal data protection for all employees and revision of policies and procedures on handling of personal data. 4. In the circumstances, the Deputy Commissioner for Personal Data Protection found that the Organisation did not adopt reasonable steps to protect personal data in its possession or under its control against unauthorised access. The Organisation was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 5. The Organisation had made an admission of breach of the Protection Obligation under the PDPA, cooperated with the Commission’s investigation and taken prompt remedial actions. 6. On account of the above, the Organisation is directed to pay a financial penalty of $5,000 within 30 days from the date of this direction, 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. In view of the remedial actions taken by the Organisation, the Commission will not issue any other directions. ",Financial Penalty,3a8e7894f9d69623906f336fc824af00e156f58e,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,96,96,1,952,A warning was issued to Zero1 and IP Tribe respectively for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of 118 individuals’ personal data contained in invoices which were sent to incorrect recipients.,"[""Protection"", ""Warning"", ""Information and Communications"", ""Unintended recipient"", ""Duplication of batch ID"", ""Inadequate scoping of testing""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Zero1-and-IP-Tribe---07042020.pdf,Protection,Breach of the Protection Obligation by Zero1 and IP Tribe,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-zero1-and-ip-tribe,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION Case Nos. DP-1903-B3630, DP-1908-B4431 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And 1. Zero1 Pte. Ltd. 2. IP Tribe Pte Ltd SUMMARY OF THE DECISION 1. On 22 March 2019, Zero1 Pte Ltd (the “Organisation”) voluntarily informed the Personal Data Protection Commission (the “Commission”) that invoices containing the personal data of their subscribers had been emailed to unintended recipients (the “Incident”). Each invoice contained the name, address, subscriber ID, mobile number, mobile charges, and the call details of any international calls made by a subscriber (the “Personal Data”). Each email contained a subscriber’s invoice which was unintendedly sent to another subscriber instead. 2. The Organisation was a licensed Mobile Virtual Network Operation that provided mobile services. It partnered Singtel Mobile Singapore Pte. Ltd. (“Singtel”), which appointed IP Tribe Pte Ltd (“IPT”) to develop and deploy a Mobile Virtual Network Enabler (the “1st Platform”) to manage subscriber accounts. 3. IPT ran the 1st Platform for the Organisation, including generating and sending monthly emails to subscribers. IPT then subcontracted the provision of the billing system within the 1st Platform to Openet Telecom Sales Limited (“Openet”). The 1st Platform was deployed in August 2018. 4. A replacement platform (the “New Platform”) was deployed in 2019. Openet subcontracted 6D Technologies (“6D”) to migrate subscriber data from the 1st Platform to the New Platform. In February 2019, 6D migrated the data of 12,000 to 15,000 subscribers. 5. The Incident was caused by Batch ID duplication. The Batch ID was a unique number that tagged each subscriber to his name and email address. The migration was staggered and some errors made it necessary to delete data migrated earlier. However, due to a coding error, not all previously migrated data had been deleted. The New Platform failed to recognise the Batch IDs that were not deleted and re-issued the same Batch IDs. As a result, 118 invoices belonging to subscribers with duplicated Batch IDs were affected. Since each Batch ID determined the email address to which an invoice was sent, Batch ID duplication resulted in the New Platform emailing the 118 invoices to the wrong addresses. 6. Before a new IT system or a change to an IT system goes live, pre-launch testing is important to determine that the system would run as expected. The Organisation, IPT and 6D jointly conducted pre-launch testing. The Organisation as the end user, and IPT as the Organisation’s data intermediary, should have scoped the pre-launch testing to include a simulation of expected scenarios. In particular, the scenario in which migration to the New Platform is staggered and a high volume of email addresses would have been assigned Batch IDs for the sending of emails to the right subscriber (“Migration Scenario”). 7. However, in the pre-launch testing, the Migration Scenario was not catered for. Only two test accounts were used to check that the New Platform could generate and email invoices to the right parties. This was insufficient to simulate expected usage. Consequently, the tests failed to surface this issue. 8. The proper scoping of pre-launching testing is important for the detection of functionality issues that may put personal data at risk. In failing to simulate the expected scenarios, in particular the Migration Scenario, the Organisation and IPT failed to meet the reasonable standard required to discharge the Protection Obligation. 9. Furthermore, the processes to ensure that the New Platform would issue unique Batch IDs were inadequate. A date/time stamp could have been included as part of each Batch ID to avoid duplication, which was implemented only after the Incident. 10. In deciding to find the Organisation and IPT respectively in breach of the Protection Obligation under the Personal Data Protection Act 2012 (the “PDPA”) and to issue a Warning to each party, the Deputy Commissioner for Personal Data Protection took into account the following: a. Although the Organisation neither owned nor operated the New Platform, it remained a data controller in control of its subscribers’ Personal Data. b. IPT was the Organisation’s data intermediary in developing the New Platform, which included migration of the personal data of subscribers. IPT relied on Openet as its subcontractor, and the Batch ID duplication occurred as a result of errors during the migration that was performed by 6D. Notwithstanding the representations made by IPT, it retained a key role, together with the Organisation, in scoping the pre-launch testing of the New Platform. c. The tests proved to be inadequate and a reasonable opportunity to prevent the Incident was missed. For this, both the Organisation and IPT bore responsibility. 11. No directions are required as the Organisation and IPT had taken remedial actions to address the gaps in security arrangements respectively. ",Warning,9289b77ccf9c91c7e895f86b99071f8723ce5faf,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,97,97,1,952,A warning was issued to Actstitude for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of individuals' personal data. Over 160 individuals uploaded their resumes to Actstitude's website and their personal data were accessible over the Internet.,"[""Protection"", ""Warning"", ""Information and Communications"", ""URL manipulation"", ""Vulnerability"", ""Access control"", ""Security""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Actstitude-Pte-Ltd---20032020.pdf,Protection,Breach of the Protection Obligation by Actstitude,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-actstitude,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1910-B5129 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Actstitude Pte Ltd SUMMARY OF THE DECISION 1. Actstitude Pte Ltd (the “Organisation”) is a social media platform marketing agency. It has a webpage allowing individuals interested in joining the Organisation to upload their resumes. For each resume uploaded, a file was created with a Uniform Resource Locator (“URL”) and stored in a database. Between August 2018 to October 2019, over 160 individuals uploaded their resumes. 2. The Organisation, however, admitted that it did not put in place controls to restrict access to the resume files. The URLs generated by the Organisation could also be manipulated to access resume files uploaded by different individuals. 3. When the webpage was created on 5 July 2018, the Organisation did not conduct vulnerability scanning as part of pre-launch testing; neither did the Organisation conduct periodic security reviews. Such scans offer a reasonable chance of detecting both the lack of access controls and the vulnerability of the URLs to manipulation. 4. The result of this failure to put in place access controls or to conduct security testing was that Google indexed and disclosed the URLs when a search was made of the names in the uploaded resumes. The URLs could then be manipulated to access the resumes of other individuals. This led to a complaint to the Personal Data Protection Commission on 25 October 2019. 5. The Deputy Commissioner for Personal Data Protection therefore found that the Organisation did not adopt reasonable steps to protect personal data in its possession or under its control against risk of unauthorised disclosure. The Organisation was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. Upon consideration of the facts, a warning was issued to the Organisation. No directions are required as the Organisation had taken action to address the gaps in its security arrangements. ",Warning,f67b98aac5af051e0230fe4d74d422bae5c57230,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,98,98,1,952,"A warning was issued to Jean Yip Salon for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of its employees. As a result, the personal data of 28 individuals were accessible over the Internet.","[""Protection"", ""Warning"", ""Wholesale and Retail Trade"", ""Password"", ""Public access""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Jean-Yip-Salon-Pte-Ltd--13032020.pdf,Protection,Breach of the Protection Obligation by Jean Yip Salon,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by--jean-yip-salon,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1907-B4281 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Jean Yip Salon Pte Ltd SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (the “Commission”) received a complaint on 16 July 2019 about an employee system (the “System”) maintained by Jean Yip Salon Pte Ltd (the “Organisation”) that was publicly accessible via the internet. The personal data of 28 individuals disclosed via the System included their name, NRIC number, residence status, date of birth, nationality, gender, mobile number and job designation. 2. The Commission found that the Organisation did not adopt reasonable measures to protect personal data in its possession against risk of unauthorised access. First, the Organisation opened public access to a server without ascertaining what it hosted. As a result, while enabling public access to the Customer Online Appointment Booking System, it inadvertently also allowed access to the System (meant only for internal use), which was also hosted on the same server. Second, there were no processes in place to remove or deactivate unnecessary user accounts of the System. Finally, the Organisation did not enforce a password policy for the user accounts of the System. As such, the complainant was able to gain access to the System by simply using a wellknown and weak default username and password pair. 3. In the circumstances, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of section 24 of the Personal Data Protection Act 2012 and issued a warning to the Organisation. No directions were required as the Organisation had implemented corrective measures that addressed the gaps in its security arrangements. ",Warning,ebdd2c957a9673f4bcab7ed28d18a885209a8e04,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,99,99,1,952,A warning was issued to FWD Singapore for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of 71 individuals’ personal data contained in payment advice letters which were sent to incorrect recipients.,"[""Protection"", ""Warning"", ""Finance and Insurance"", ""Letters"", ""Logic error"", ""Code review""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/FWD-Singapore-Pte-Ltd---Summary-of-Decision---13032020.pdf,Protection,Breach of the Protection Obligation by FWD Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-fwd-singapore,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1907-B4352 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And FWD Singapore Pte Ltd SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (the “Commission”) was notified on 26 July 2019 by FWD Singapore Pte Ltd (the “Organisation”) of the unintended disclosure of 71 individuals’ (the “Affected Individuals”) personal data contained in 42 payment advice letters sent to incorrect recipients between 20 June 2019 and 17 July 2019 (the “Incident”). 2. The Incident arose from the Organisation’s attempt to fix a logic error in the system that it used to generate payment advice letters. The error was introduced when a fix for an earlier logic error was deployed. The Commission found that the second logic error could have been detected if manual code review and unit testing had been conducted to a reasonable standard. 3. The second logic error caused the extraction of incorrect mailing addresses for payment advice letters in some circumstances. This resulted in the Affected Individuals’ names and identification numbers in payment advice letters being sent to incorrect addresses. The Organisation should have taken care in conducting its manual code review and unit testing to avoid another logic error. In the circumstances, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of its Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 4. The Deputy Commissioner took into account the following factors in deciding to issue a warning to the Organisation: a. The Organisation had managed to retrieve letters containing the personal data of 67 out of the 71 Affected Individuals. b. The Organisation voluntarily notified the Commission of the Incident. c. The second logic error resulted in the extraction of incorrect mailing addresses only in limited circumstances. 5. No directions are required as the Organisation took steps to improve its development processes to prevent the recurrence of the Incident. ",Warning,bb248e5764c08e64f81212ce9f5a5c65012fd88c,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,100,100,1,952,"A financial penalty of $32,000 was imposed on CDP for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of individuals’ personal data. Mail sent by CDP were addressed to incorrect recipients.","[""Protection"", ""Financial Penalty"", ""Finance and Insurance"", ""Mail"", ""Unintended recipient""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---The-Central-Depository-(Pte)-Limited-30032020.pdf,Protection,Breach of the Protection Obligation by CDP,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-cdp,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 12 Case No DP-1905-B3847 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And The Central Depository (Pte) Limited … Organisation DECISION 1 The Central Depository (Pte) Limited [2020] SGPDPC 12 Tan Kiat How, Commissioner — Case No DP-1905-B3847 30 March 2020 Introduction 1 The Central Depository (Pte) Limited (the “Organisation”) provides integrated clearing, settlement and depository facilities for its account holders (“CDP Account Holders”) in the Singapore securities market. On 3 May 2019, the Organisation notified the Personal Data Protection Commission (the “Commission”) that dividend cheques of some CDP Account Holders had been mailed to outdated addresses, resulting in the disclosure of their personal data to other individuals. Facts of the Case 2 Prior to 10 December 2018, the Organisation used a software known as the Post Trade System (“PTS”) for the purposes of post trade processing. The Organisation developed and customised additional modules that interfaced with PTS, including a module for the printing of dividend cheques (“Dividend Cheque Module”). The Dividend Cheque Module was used to automate the generation of dividend cheque mailers (i.e. mailers enclosing dividend cheques to be posted to CDP Account Holders). 3 Subsequently, the Organisation purchased another software, the New Post Trade System (“NPTS”) to replace the PTS. In comparison to the PTS, the NPTS facilitated record keeping that was more comprehensive. The PTS only recorded a CDP Account Holder’s latest address, while the NPTS kept records of the CDP Account Holder’s updated address as well as historical addresses.1 Arising from the new feature of the NPTS that kept records of CDP Account Holders’ updated addresses and historical addresses, the Organisation updated the programming logic of the Dividend Cheque Module (and all other modules that required retrieving of addresses) to extract the CDP Account Holders’ updated addresses. 1 As there was only one address for each CDP Account Holder stored in the PTS, a query for the address would always extract that address of the CDP Account Holder. 2 4 Prior to migration from PTS to NPTS, the Organisation conducted several tests, which included the following: (a) A test for the change of address for the module that generated notification letters acknowledging a change of address. This included checking that the notification letters extracted the updated address (the “Notification Letters Test”); (b) A test for the extraction of CDP Account Holders’ personal data for the Dividend Cheque Module. The scope of this test did not include the scenario of change of address (i.e. whether the Dividend Cheque Module would extract the updated address in the event a CDP Account Holder changed its address) (the “Dividend Cheque Module Test”); and (c) Manual code review of the additional modules (including the Dividend Cheque Module). 5 On 10 December 2018, the Organisation migrated from PTS to NPTS. As the tests mentioned at [4] did not detect any errors, the Organisation was unaware that the Dividend Cheque Module may not consistently extract a CDP Account Holder’s updated address. 6 On 20 March 2019, a CDP Account Holder complained that the Organisation had mailed a cheque for dividends to an outdated address (“First Incident”). The Organisation commenced investigations immediately. However, the Organisation’s technical team was unable to replicate the error and identify the issue that caused the First Incident. The results for the Dividend Cheque Module Test returned the correct addresses, including the complainant’s correct address. 7 Subsequently, on 12 April 2019, the Organisation’s customer service team received an email from the Monetary Authority of Singapore (“MAS”) in relation to a complaint (“Second Incident”). Meanwhile, notwithstanding that the Organisation’s technical team was unable to identify the issue that caused the First Incident, to further reinforce the programming logic, they introduced a defensive measure with a clause to consistently extract the updated addresses (the “Fix”). On 20 April 2019, the Organisation deployed the Fix into the production environment. 3 8 After several rounds of correspondence and additional information provided by MAS on 30 April 2019 in relation to the Second Incident, the Organisation realised that the issue pertaining to the First Incident and Second Incident may have a wider impact than originally anticipated. The Organisation conducted further investigations which revealed that all of the modules involving the retrieval of addresses were correctly coded except the Dividend Cheque Module. The error in the code in the Dividend Cheque Module (which resulted in the programme logic not consistently extracting a CDP Account Holder’s updated address) had caused the First Incident and Second Incident. Due to the implementation of the Fix as mentioned at [7], the error had been permanently resolved by this time. 9 According to the Organisation, 542 CDP Account Holders were due to receive dividend cheque mailers, and had previously updated their addresses. Out of the 542 CDP Account Holders whose personal data was at risk of unauthorised disclosure, the Organisation confirmed that 331 CDP Account Holders had presented their dividend cheques, indicating that their dividend cheque mailers had been sent to the correct addresses. By deduction, there were accordingly 211 CDP Account Holders (“Affected Individuals”) whose dividend cheque mailers were sent to outdated addresses. 10 The information disclosed in the dividend cheque mailers (collectively, “Disclosed Data”) were: 11 (a) Name of client; (b) NRIC number; (c) Central Depository (Pte) Limited (“CDP”) account number; (d) Name of security; (e) Quantity of security held; and (f) Dividend amount. During the course of its investigations into the First Incident and Second Incident, the Organisation took the following remedial actions: 4 (a) On 20 April 2019, introduced an additional measure to ensure that the updated address of CDP Account Holders would be extracted in the Dividend Cheque Printing Module; (b) Reviewed all modules which interfaced with NPTS and which involved the extraction of addresses to confirm that the error was specific only to the Dividend Cheque Module; and (c) Re-issued replacement cheques and explanation letters to the Affected Individuals. 12 In addition, the Organisation will also be conducting refresher training to ensure that its teams report issues under their respective purview as soon as practicable (even when similar type of issues had previously been raised), so that necessary follow up action may be taken. Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 13 It is undisputed that the Disclosed Data constitutes “personal data” as defined in section 2(1) of the Personal Data Protection Act 2012 (“PDPA”), and the Organisation had possession and/or control over the Disclosed Data at all material times. 14 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. The fact that the Disclosed Data included NRIC numbers and personal data of a financial nature (i.e. CDP account number, name and quantity of security held, and dividend amount) is relevant in assessing the standard of reasonable security arrangements required. As emphasized in previous decisions, when it comes to the protection of personal data of a sensitive nature, stronger security measures must be put in place due to the actual or potential harm, and the severity of such harm, that may befall an individual from an unauthorised use of such data. 2 Having in mind the sensitivity of the Disclosed Data, the Organisation failed to put in place 2 See for example, Re Credit Counselling Singapore [2017] SGPDPC 18 at [25]; Re Aviva Ltd [2018] SGPDPC 4 at [17]; DS Human Resource Pte. Ltd. [2019] SGPDPC 16 at [9(c)]; and AIA Singapore Private Limited [2019] SGPDPC 20 at [12]. 5 reasonable security arrangements to protect the Disclosed Data for the reasons explained below. 15 When the Organisation migrated from PTS to NPTS, it had an obligation to conduct proper and adequate testing of the NPTS and its implementation that simulated real world usage of the system. This was critical in order to prevent errors from compromising the security of the Disclosed Data. In particular, and as mentioned at [3], the NPTS had a new feature which kept records of both the updated addresses of CDP Account Holders as well as their historical addresses, and the Organisation was relying on the NPTS and its customised additional modules to extract the correct address when generating the dividend cheque mailers. 16 The Commission’s investigations revealed that the Organisation failed to conduct sufficient testing before migrating from PTS to NPTS for the following reasons: (a) First, the scope of the testing for the Dividend Cheque Module was too narrow and did not include the scenario of change of address. This omission was unacceptable given that (i) change of address was a known scenario (which was tested in the module with respect to generation of notification letters that acknowledged change of address); and (ii) the Organisation relied on the Dividend Cheque Module to extract the updated address and automate the generation of dividend cheque mailers; (b) Secondly, the Organisation should have tested the Dividend Cheque Module in an environment that simulated real world usage of the system. This required the Organisation to not only scope the tests to include the change of address scenario, but also to have a sufficient number of test cases to properly test these scenarios; and (c) Thirdly, the Organisation had conceded that there was a “reasonable chance” that the error in the Dividend Cheque Module may have been detected if the scope of the tests had included the change of address scenario with a sufficient number of tests cases. 17 For the reasons above, the Commissioner found the Organisation in breach of section 24 of the PDPA. 6 Representations by the Organisation 18 In the course of settling this decision, the Organisation made representations on the amount of financial penalty that was to be imposed. The Organisation raised the following factors for consideration: (a) The Organisation had expended its best efforts in testing: (i) Prior to migration from PTS to NPTS, the Organisation carried out the Notification Letter Test and the Dividend Cheque Module Test. Both tests did not return any errors. In view of this, the Organisation did not contemplate further targeted testing at the material time. (ii) Even if the Organisation had expanded the scope of the Dividend Cheque Module Test to cover the change of address scenario and increased the relevant test cases, such testing may have still failed to reveal the defect. In this regard, after being informed of the First Incident, the Organisation was unable to replicate the error through repeated testing with real world cases. (b) There was no risk of actual financial loss. (i) The dividend cheques were made out to the names of the Affected Individuals and could only be encashed into accounts bearing such names. (ii) The Disclosed Data of each Affected Individual was disclosed only to a single recipient, as opposed to the world at large. The Disclosed Data was also insufficient, in and of itself, to be used by a recipient to impersonate or execute any transaction in the name of an Affected Individual. (iii) The Organisation used a specific envelope for the mailing of dividend cheques to minimise unauthorised access to the Disclosed Data, save in wilful circumstances. Each envelope was marked “Private & Confidential” and “To be opened by addressee only”. A return address was printed on the face of the envelope, to cater for the event that the letter was not properly delivered to the addressee. 7 (c) Upon establishing the number of dividend cheques affected on 3 May 2019, the Organisation promptly notified the Affected Individuals and the Commission. The Organisation also took proactive and prompt remedial steps at [11]. (d) The financial penalty imposed should be consistent with the Commission’s previous decisions and commensurate with the scale of the Incident. Taking into consideration the number of Affected Individuals in the present case and financial penalties imposed in the Commission’s previous decisions involving similar number of affected individuals, a warning would suffice. In the alternative, the Organisation submitted that any financial penalty imposed should not exceed $5,000. 19 Having carefully considered the representations, the Commissioner has decided to maintain the financial penalty set out at [21] for the following reasons: (a) As explained in [15] to [16], the Organisation failed to conduct sufficient testing before migrating from PTS to NPTS. The module that generated notification letters acknowledging a change of address was coded independently from the Dividend Cheque Module. The Organisation should not have relied on test results from the Notification Letters Test as assurance that there were no errors in the Dividend Cheque Module, and it would consistently extract a CDP Account Holder’s updated address. (b) The Organisation’s representations that there was no risk of financial loss cannot be accepted. Although the risk of financial loss was reduced because the dividend cheques were made out to the names of the Affected Individuals, there was still a risk of fraud i.e. the unauthorised individuals who received the dividend cheque mailers could have fraudulently altered the names on the dividend cheques and presented them for encashment. In addition, for the period between the Incident and the Organisation issuing the replacement cheques, the Affected Individuals would have been deprived of the use of funds they would have otherwise access to. As for the Organisation’s representations on the specific envelopes used for the mailing of dividend cheques, the fact that the dividend cheques mailers were sent to unauthorised individuals meant that there was a risk of further unauthorised access, use and disclosure of the Disclosed Data. 8 (c) The Organisation’s voluntary notification of the Incident to Affected Individuals and the Commission, as well as the Organisation’s proactive and prompt remedial steps had already been taken into consideration in determining the financial penalty at [21]. (d) With respect to the Organisation’s representations comparing the present case to earlier decisions, it needs only to be said that each decision is based on the unique facts of each case. The decision in each case takes into consideration the specific facts of the case so as to ensure that the decision and direction(s) are fair and appropriate for that particular organisation. The Commissioner’s Directions 20 In the assessment of the breach and determination of the directions, if any, to be imposed on the Organisation under section 29 of the PDPA, the fact that the Affected Individuals were put at risk of actual financial loss was an aggravating factor. The dividend cheques mailers were sent to outdated addresses and there was a risk that they may have been banked in by unauthorised persons. The Affected Individuals would also have been deprived of the use of the funds they would have otherwise access to, had they received and banked in the dividend cheques. On the other hand, the following mitigating factors were also considered: (a) the Organisation took prompt remedial actions to rectify the error and mitigate the effects of the breach; and (b) 21 the Organisation was cooperative with the Commission’s investigations. In consideration of the relevant facts and circumstances, the Commissioner hereby directs the Organisation to pay a financial penalty of $32,000 within 30 days from the date of the directions, 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. The Commissioner has not set out any further directions given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 9 ",Financial Penalty,c533793aa9a8e3bfcebfd59e65b4ee2051754090,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,101,101,1,952,"A financial penalty of $10,000 was imposed on MDIS Corporation for failing to put in place reasonable security arrangements to protect the personal data of individuals on its website. These individuals had provided their personal data to MDIS Corporation for registration purposes to attend its courses.","[""Protection"", ""Financial Penalty"", ""Education"", ""Public access"", ""Database""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---MDIS-Corporation-Pte-Ltd---17032020.pdf,Protection,Breach of the Protection Obligation by MDIS Corporation,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-mdis-corporation,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 11 Case No DP-1905-B3832 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And MDIS Corporation Pte Ltd. … Organisation DECISION MDIS Corporation Pte Ltd [2020] SGPDPC 11 Tan Kiat How, Commissioner — Case No DP-1905-B3832 17 March 2020 Introduction 1 On 2 May and 17 June 2019, the Personal Data Protection Commission (the “Commission”) received two complaints from an individual (the “Complainant”) in relation to a Microsoft Excel spreadsheet (the “Spreadsheet”) containing personal data of individuals who had signed up for courses with MDIS Corporation Pte Ltd (the “Organisation”). The Complainant was able to access the Spreadsheet through a Google search of her NRIC number on 2 May and 17 June 2019 (the “First Incident” and “Second Incident” respectively). Facts of the Case 2 The Organisation is a not-for-profit, professional institute for lifelong learning. The Organisation’s server and webpage were maintained by a web development vendor (the “Vendor”). In October 2017, the Organisation engaged the Vendor to develop its website (the “Website”) to include a content management system (“CMS”) for the Organisation to manage training and courses provided, and an online registration form (the “Form”) for course participants to provide their personal data. The purpose of the Form was for the Organisation to use the personal data collected to identify course attendees, create certificates for individuals who had completed their courses and verify their details for the purposes of claiming SkillsFuture credits. The Vendor subsequently engaged a freelance developer based in India (the “Developer”) to assist in developing the Website. 3 There were no written contracts between (i) the Organisation and the Vendor; and (ii) the Vendor and the Developer setting out the parties’ respective scope of work and responsibilities with respect to the development of the Website. During development of the Website, the Organisation conveyed its instructions for the Website via telephone to the Vendor, and the Vendor acted as the middleman between the Organisation and the Developer. From time to time, the Organisation would also contact the Developer directly. 4 In December 2017, the Organisation and the Vendor carried out pre- launch testing on the Website (including the Form). In September 2018, the Organisation approved the Website for launch and the Website went “live” shortly after. Between September 2018 and February 2019, the Vendor assisted to rectify various features on the Website that were not developed to the Organisation’s expectations. The Organisation terminated the Vendor’s engagement in or around February 2019 as it was not satisfied with the Vendor’s service. 5 The First Incident occurred on 2 May 2019 when the Complainant entered her NRIC number into a Google search. The search result was a URL link displaying partial information about the Complainant, including NRIC number, email address and mobile phone number (the “Spreadsheet Link”). The Complainant clicked on the Spreadsheet Link which led to the Spreadsheet containing the following information of 304 individuals including the Complainant’s (the “Disclosed Data”): (a) Name; 2 6 (b) Designation; (c) Citizenship; (d) NRIC number / identification number (for foreigners); (e) Email address; (f) Name of Company name that the individual worked for; (g) Registration type; (h) Contact number; (i) Billing address; (j) Country; (k) Contact person; and (l) Course title, course code and date. On the same day, the Complainant notified the Commission and the Organisation about the First Incident. The Organisation promptly took the following remedial actions: (a) Blocked the CMS administrative backend; (b) Inserted a “robot.txt” file to prevent search engines from crawling the Website; and (c) Submitted a removal request to Google to ensure cached versions of Spreadsheet Link would be removed from search results. 3 7 In addition, as part of the Organisation’s investigations, it periodically removed the blockage on the CMS administrative backend to test and replicate the First Incident. 8 The Second Incident occurred on 17 June 2019 when the Complainant entered her NRIC number into a Google search and was again able to access the Spreadsheet Link and Spreadsheet. According to the Organisation, the Second Incident occurred because the Complainant carried out the Google search of her NRIC number at the same time that the Organisation had removed the blockage on the CMS administrative backend to conduct tests on the First Incident. 9 As of 19 June 2019, the Organisation’s newly appointed vendor deployed security patches on the Website and removed the codes that caused the First Incident and Second Incident. As part of the Organisation’s remedial actions, a new backend system for the Website will also be deployed. The Commissioner’s Findings and Basis for Determination 10 As a preliminary point, the Organisation owned the Website and was in possession and control of the Disclosed Data (collected through the Form) at all material times. While the Vendor and the Developer were engaged to develop the Website, the Organisation confirmed that neither of them processed the Disclosed Data on the Organisation’s behalf. Both the Vendor and Developer were accordingly not data intermediaries, and the responsibility to protect the Disclosed Data fell squarely and solely on the Organisation. 11 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by taking reasonable steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, 4 modification, disposal or similar risks. The Organisation failed to put in place reasonable security arrangements to protect the Disclosed Data for the reasons explained below. 12 First, the Organisation failed to communicate any data protection requirements to the Vendor or the Developer. (a) The Organisation conceded that it did not have a written contract with the Vendor in relation to the development of the Website. There was also no written contract between the Vendor and Developer. As emphasized in previous decisions and the Commission’s Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1], organisations that engage IT vendors to develop and/or maintain their websites should ensure that their IT vendors are aware of the need for personal data protection by making it part of their contractual terms.1 (b) According to the Organisation, it had verbally communicated data protection requirements to the Vendor and Developer. In contrast, the Vendor asserted that there was no such communication. As the data controller and customer, the Organisation ought to be clear about the scope of services that it is procuring from its service providers, and document the scope properly in contract and other project documentation.2 In this case, the Organisation was not able to produce anything in writing to corroborate its assertions. In the circumstances, the Commissioner finds that the Organisation failed to communicate data protection requirements to the Vendor and Developer. 1 See for example Re EU Holidays Pte Ltd [2019] SGPDPC 38 at [11]. 2 Re Royal Carribean Cruises (Asia) Pte Ltd [2020] SGPDPC 5 at [12] 5 (c) Given that one of the purposes of developing the Website was to collect Disclosed Data through the Form, the Organisation’s failure to specify clear requirements with respect to the protection of personal data is particularly glaring. 13 Second, prior to the launch of the Website, the Organisation failed to take reasonable steps to scope the pre-launch testing to discover risks to the Disclosed Data that was collected through the Form. As a result, the vulnerability in the CMS administrative backend of the Website (which allowed Google to crawl and index the Spreadsheet Link) remained undetected prior to the First Incident. (a) Websites connected to the Internet are subject to a multitude of cyber threats that may compromise the website and expose any personal data collected. The Commissioner takes this opportunity to reiterate that organisations should ensure protection of personal data and the security of the website is a key design consideration at each stage of the website’s life cycle, including requirements gathering, design and development, UAT, deployment and operations support.3 (b) The Commission’s investigations revealed that the pre-launch testing conducted prior to launch of the Website focused on its functionality. According to the Organisation, it believed that the password protection to the administrative panel was “secure enough”. In this regard, the Organisation admitted that it did not inform the 3 See Commission’s Guide on Building Websites for SMEs (revised 10 July 2018) at [3.2 – 3.3] and Re Horizon Horizon Fast Ferry Pte. Ltd. [2019] SGPDPC 27 at [26] 6 Vendor of the requirement to secure personal data collected through the Form. (c) The omission to include security testing prior to the launch of the Website is particularly concerning given that: (i) The purpose of the Form was to collect Disclosed Data from individuals participating in the Organisation’s courses; and (ii) The Organisation knew that the administrative panel had an export function which collated the Disclosed Data (entered by course participants in the Form) into the Spreadsheet. The export function could be triggered either by clicking on the export button in the administrative panel or by clicking on the Spreadsheet Link. The Spreadsheet link was not intended to be publicly available and should have only been accessible with valid login credentials. (d) In the circumstances, the Organisation should have scoped the pre-launch testing to verify that password protection measures on the administrative panel and the login credentials on the Spreadsheet Link operated as intended. 14 During the course of the Commission’s investigations, the Organisation asserted that it was not an IT services provider, and therefore had relied on its Vendor to identify the risks and implement the appropriate security measures for the Website. This is not an acceptable explanation. It should be reiterated that while organisations may delegate work to vendors to comply with the PDPA, the organisation’s responsibility for complying with statutory 7 obligations under the PDPA may not be delegated.4 While an organisation may not have — or need to have — the requisite level of technical expertise, a responsible organisation would have engaged competent service providers and made genuine attempts to give proper instructions.5 The Organisation is only expected to articulate its business requirements as owner of the system, which the service provider can translate into technical requirements. In addition, as the data controller, the Organisation is required to exercise reasonable oversight to ensure that its instructions are carried out.6 In this case, and as mentioned at [12], the Organisation failed to provide any data protection instructions to either the Vendor or the Developer. The Commission’s investigations also revealed that the Organisation did not exercise reasonable oversight in respect of the security arrangements for the Website. 15 For the reasons above, the Commissioner finds the Organisation in breach of section 24 of the PDPA. The Commissioner’s Directions 16 In determining the directions, if any, to be imposed on the Organisation under Section 29 of the PDPA, the Commissioner took into account the following mitigating factors: 4 Re WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 at 23; Re National Healthcare Group [2019] SGPDPC 46 at [17] 5 Re WTS Automotive Services Pte Ltd [2018] SGPDPC 26 at [24]; Re DS Human Resource Pte. Ltd. [2019] SGPDPC 16 at [15]. 6 Re Smiling Orchid (S) Pte Ltd and others [2016] SGPDPC 19 at [51] 8 (a) The Organisation was cooperative in the course of the Commission’s investigations and provided prompt responses to the Commission’s requests for information; (b) The Organisation implemented prompt remedial actions; and (c) The unauthorised disclosure of the Disclosed Data was only to the Complainant. 17 The Commissioner also took into account, as an aggravating factor, that the Disclosed Data was exposed to the risk of unauthorised disclosure for a period of approximately 6 months.7 18 Having considered all the relevant factors of this case, the Commissioner hereby directs the Organisation to pay a financial penalty of S$10,000 within 30 days from the date of this direction, 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 the financial penalty until it is paid in full. 19 The Commissioner has not set out any further directions given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 7 The approximate period of 6 months was between November 2018 (when individuals started signing up for courses on the Website using the Form) and June 2019 (when security patches were deployed to fix the vulnerabilities on the Website). 9 ",Financial Penalty,25ed2dfd0034231d7bc91c9c8c2ca09ccadc268f,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,102,102,1,952,A warning was issued to MCST 3400 for failing to put in place reasonable security arrangements to prevent the unauthorised access of 562 individuals’ personal data stored in an internal directory.,"[""Protection"", ""Warning"", ""Real Estate"", ""MCST"", ""Directory"", ""Security"", ""Public access""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---MCST-3400-17032020.pdf,Protection,Breach of the Protection Obligation by MCST 3400,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-mcst-3400,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 10 Case No. DP-1909-B4797 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Management Corporation Strata Title Plan No. 3400 … Organisation DECISION Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 Yeong Zee Kin, Deputy Commissioner — Case No. DP-1909-B4797 17 March 2020 Introduction 1 On 2 September 2019, the Personal Data Protection Commission (the “Commission”) was notified that a directory containing personal data belonging to Management Corporation Strata Title Plan No. 3400 (the “Directory”) was accessible on the Internet by any member of the public (the “Incident”). Facts of the Case 2 In April 2012, Management Corporation Strata Title Plan No. 3400 (the “Organisation”) purchased a Network Attached Storage Device (the “NAS”) for the purposes of internal file sharing among its administrative staff over a local network. The Directory was one of the files stored on the NAS. The 2 Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 Organisation did not intend for the NAS to be connected to the Internet. Prior to the Incident, the Organisation was unaware that the Directory could be accessed via an Internet Protocol address without the need for any login credentials. 3 The Directory contained personal data of 562 individuals collected for the purposes of complying with the Building Maintenance and Strata Management Act, the Building Maintenance (Strata Management) Regulations 2005, as well as to contact subsidiary proprietors of the Organisation. 4 The following types of personal data of the Affected Individuals were exposed to the risk of unauthorised disclosure (collectively, the “Disclosed Data”): (a) 12 council members of the Organisation: Name; NRIC / Passport Number; Contact number; Email address; and (b) 550 subsidiary proprietors of the Organisation: Name; Email address; Contact number; Block and Unit number; Change of property 3 Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 ownership details; Identity of resident; Statement of accounts; Car plate numbers; Figures in relation to share values/arrears.1 5 Upon being informed of the Incident by the Commission on 2 September 2019, the Organisation promptly disconnected the NAS from the Internet on the same day. Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 6 In today’s digital age, many organisations are moving towards paperless offices. Through digitisation, an increasing amount of information (including personal data) is stored electronically and online. This has resulted in a higher risk of data breaches involving IT security vulnerabilities. In the past few years, the Commission has investigated data breaches involving Insecure Direct Object References2, SQL injection vulnerability3, and absence of directory 1 The types of personal data collected from the 550 subsidiary proprietors varied. This was because apart from the mandatory requirement to provide their names, the other types of personal data were optional fields. 2 See Re InfoCorp Technologies Pte. Ltd. [2019] SGPDPC 17 and Re Singapore Telecommunications Limited [2019] SGPDPC 36. 3 See Re Metro Pte Ltd [2016] SGPDPC 7; Re Ncode Consultant Pte Ltd [2019] SGPDPC 11; and Re Creative Technology Ltd [2020] SGPDPC 1. 4 Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 access controls4. Given the increasing number of cases involving IT security vulnerabilities, including the present one, I would like to take this opportunity to highlight some of the measures that organisations could implement in order to comply with their obligations under Section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 7 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). In my view, the Organisation failed to put in place reasonable security arrangements to protect the Disclosed Data and was in breach of the Protection Obligation for the reasons explained below. 8 In an IT security context, timely detection of risks to personal data is key to an organisation’s compliance with the Protection Obligation. As explained and discussed below, there are two key measures that organisations should implement to detect IT security vulnerabilities. 4 See Re Fu Kwee Kitchen Catering Services & anor [2016] SGPDPC 14; Re Tutor City [2019] SGPDPC 5; Re Advance Home Tutors [2019] SGPDPC 35; Re SearchAsia Consulting Pte. Ltd. [2019] SGPDPC 40; and Re Society of Tourist Guides (Singapore) [2019] SGPDC 48. 5 Management Corporation Strata Title Plan No. 3400 9 [2020] SGPDPC 10 First, organisations should conduct code reviews5 and pre-launch testing6 before new IT features or changes to IT systems are deployed. These processes allow organisations to pick up and rectify errors and/or flaws in the new IT features and/or systems prior to deployment. There have been a number of cases where errors in the application code resulted in the unintended disclosure of personal data or unintended access to personal data: see, for example, Re Singapore Telecommunications Limited [2019] SGPDPC 367, and Re Flight Raja Travels Singapore Pte Ltd [2018] SGPDPC 168. This is particularly important if the new IT feature is accessible from the Internet, and therefore exposed to a “multitude of cyber threats that may compromise the website and expose any personal data [the organisation] collects” 9. 5 Depending on the complexity and scope of the new code/system, organisations may conduct the code reviews manually, or with the appropriate automated code review software and tools. 6 This may include load testing, stress testing and/or integration testing. There was unauthorised disclosure of personal data of the organisation’s customers due to a direct object reference vulnerability (which was a design issue in the organisation’s mobile app’s application programming interface). 7 8 The organisation introduced a new mobile application that allowed access to the online booking system through mobile devices without login. This resulted in some of the organisation’s customers having unauthorised access to booking records (containing personal data) of other customers. 9 See Re Horizon Fast Ferry Pte. Ltd. [2019] SGPDPC 27 at [26]. 6 Management Corporation Strata Title Plan No. 3400 10 [2020] SGPDPC 10 Second, organisations should conduct periodic security reviews of its IT systems10. The comprehensiveness of such security reviews should be scoped based on the organisation’s assessment of its data protection needs. For example, periodic security reviews would not typically include penetration tests for most systems that are within the internal corporate network. However, organisations with Internet-facing IT systems that contain personal data that is sensitive in nature should consider conducting penetration testing as part of their periodic security reviews. 11 Generally, as part of the periodic security review of its IT systems, organisations should avail themselves of up-to-date online vulnerability scanning tools, and are expected to acquire reasonable proficiency in their use or seek assistance by engaging vendors with the appropriate expertise11. The use of such tools provides organisations a reasonable chance of detecting common security vulnerabilities in their IT systems12. 10 As set out by the Commissioner in a number of previous decisions, including Re WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 at [18], Re Bud Cosmetics [2019] SGPDPC 1 at [24] and Re Chizzle Pte. Ltd. [2019] SGPDPC 44 at [6] to [8]. 11 See Re WTS Automotive Services Pte Ltd [2018] SGPDPC 26 at [24], and Re DS Human Resources Pte Ltd [2019] SGPDPC 16 at [15(a)]. 12 For example, see the OWASP Top Ten at: https://owasp.org/www-project-top-ten/. 7 Management Corporation Strata Title Plan No. 3400 12 [2020] SGPDPC 10 As a complement to the use of up-to-date online vulnerability scanning tools, the periodic security review of an organisation’s IT systems should also include a manual component. This would include review of password management policies13, archival of personal data that no longer needs to be stored online to near-line or off-line storage14, and purging of personal data that no longer serves any legal or business purpose for the organisation. 13 In addition, it is important for an organisation to be aware of and track its personal data assets. The creation and maintenance of a personal data asset register (i.e. a record identifying all personal data in the organisation’s possession or control) is a good practice that would assist organisations to comply with the Protection Obligation. An up-to-date personal data asset register provides the organisation with an accurate record of all the personal data in its possession or control, and enables the organisation to ensure its periodic security reviews covers the personal data assets. It also enables the organisation to more effectively review the implementation of its data protection policies, for example, the access control list setting out the employees who have access to the IT systems the personal data asset is stored in, whether 13 See Re GlogbalSign.in Pte Ltd [2019] SGPDPC 43. 14 See Re Orchard Turn Developments Pte. Ltd. [2017] SGPDPC 12. 8 Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 the internal business owner of the personal data asset has reviewed it for data quality issues15, and initiating the process for disposing personal data that have reached the end of its life cycle within the organisation. 14 In the present case, the Organisation admitted that it had not conducted any security reviews of its IT systems, including the NAS and the Directory. Consequently, it was unaware of their configuration which allowed access from the Internet without any form of access control. The Organisation ought to have formulated a policy for the NAS and the Directory, implemented the IT security practices that gives effect to the policy and conducted periodic security reviews to ensure that the practices are adequate. For example, if the intention was to permit access to the NAS and the Directory from the Internet, then the policy should establish who should have access and the level of sensitivity of the personal data; the IT security practices would then implement the right level of security measures to control access to the personal data and protect the personal data during its transmission. On the contrary, if the intention was to restrict the NAS and the Directory to the internal corporate network, then the practices to implement this policy would include considerations like whether the NAS and 15 This includes aspects like whether the personal data is accurate and how recently it was updated: see The Commission’s Model ArtificiaI Intelligence Governance Framework (Second Edition) at page 38. 9 Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 the Directory was connected to the right segment of the corporate network and whether their configuration was effective in limiting access to users from within the corporate network. In view of the Organisation’s admission, and the lack of any security measures to protect the Disclosed Data stored in the Directory, I find the Organisation in breach of section 24 of the PDPA. Conclusion 15 In determining the directions, if any, to be imposed on the Organisation under section 29 of the PDPA, I took into account the following mitigating factors: (a) The majority of the Affected Individual’s Disclosed Data exposed to risk of unauthorised access, use and/or disclosure related only to contact information; (b) The Organisation’s took prompt remedial action to disconnect the NAS from the Internet; and (c) There was no evidence of actual misuse or exfiltration of the Disclosed Data. 16 Having considered all the relevant factors of this case, I have decided to issue a warning to the Organisation for the breach of its obligations under 10 Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 section 24 of the PDPA. No directions are required in view of the prompt remedial action implemented by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 11 ",Warning,315029b0a5e1ce7489dea7f836f1f9a64435e6bc,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,103,103,1,952,A warning was issued to SSA Group International for failing to put in place reasonable security arrangements to prevent the unauthorised access of 53 individuals’ course registration information which were publicly available via its webpage.,"[""Protection"", ""Warning""]",2020-03-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/SSA-Group-International-Pte-Ltd---Summary-of-Decision---02032020.pdf,Protection,Breach of the Protection Obligation by SSA Group International,https://www.pdpc.gov.sg/all-commissions-decisions/2020/03/breach-of-the-protection-obligation-by-ssa-group-international,2020-03-19,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1909-B4729 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And SSA Group International Pte Ltd SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (the “Commission”) received a complaint on 6 September 2019 that individuals’ course registration information were publicly accessible via a webpage (the “Webpage”) maintained by SSA Group International Pte Ltd (the “Organisation”). The Webpage contained 53 individuals’ names. Other information disclosed via the Webpage included course titles, sponsorship type, information on how the registrant knew about the Organisation and date of transaction. 2. The Commission found that the Organisation did not adopt reasonable steps to protect personal data in its possession or control against risk of unauthorised access. First, there were no authentication mechanisms in place to limit access to the Webpage. As such, the Webpage was indexed by search engines and made publicly searchable online. Second, there were no formal instructions provided to the developer of the Webpage to protect the contents during its creation in April 2018. Finally, there were no security reviews, including vulnerability scanning, conducted for the Webpage by the Organisation since its creation. As such, the fact that the Webpage was freely accessible from the Internet went undetected for more than a year. 3. On the facts above, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of section 24 of the Personal Data Protection Act 2012. 4. In deciding to issue a warning to the Organisation, the Deputy Commissioner also took into account the following considerations: a) The Organisation’s representation that the Webpage had not been easy to locate was incorrect. An online search of the names of the 53 affected individuals produced the Webpage’s URL. b) The remedial measures taken by the Organisation, the type of personal data at risk, the inadvertent nature of the breach and the absence of a previous breach, all mentioned by the Organisation in its representations, had also been duly considered. c) The Commission’s previous decisions, including as Re Watami Food Service Pte Ltd [2018] SGPDPC [12] and Re Jade E-Services Singapore Pte Ltd [2018] SGPDPC 21 which had similar case facts. 5. No directions are required as the Organisation has implemented corrective measures that addressed the gaps in its security arrangements. ",Warning,4704e4fd9c80a645d09bbc78969a691237116a56,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,107,107,1,952,A warning was issued to AXA Insurance for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of its policyholders. The personal data of 87 individuals was sent in an email to an unintended recipient.,"[""Protection"", ""Warning""]",2020-02-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---AXA-SG.pdf,Protection,Breach of the Protection Obligation by AXA Insurance,https://www.pdpc.gov.sg/all-commissions-decisions/2020/02/breach-of-the-protection-obligation-by-axa-insurance,2020-02-11,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1907-B4201 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And AXA Insurance Pte. Ltd. SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (the “Commission”) received a complaint on 4 July 2019 against AXA Insurance Pte. Ltd. (the “Organisation”). The complaint was about an email (the “Email”) sent with a scanned document (the “Attachment”) containing personal data of 87 other policyholders (the “Affected Individuals”) to the Complainant on 28 June 2019. (the “Incident”). 2. The Attachment was an internal email correspondence of the Organisation that contained the names, NRIC numbers, insurance policy numbers and the details of the servicing agents of the Affected Individuals (the “Personal Data”). The Attachment was not meant for the Complainant. 3. The Organisation admitted that during scanning of documents by its employees, it did not have a process to segregate documents intended for internal record purposes from documents for customers. 4. The Organisation’s customer care specialist who retrieved the scanned document which formed the Attachment also failed to check the Attachment before sending out the Email. 5. The Commission found that these lapses in processes resulted in the Incident. The lapses pointed to a failure by the Organisation to make reasonable security arrangements to protect the personal data of its policyholders from inadvertent disclosure by its employees. The Organisation was therefore found in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. The Commission has decided to issue a warning to the Organisation after considering the admission of liability by the Organisation, the impact of the breach and the corrective measures taken. ",Warning,71d45bf5b66f5336bd2c59fa788260822e8e796d,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,108,108,1,952,A warning was issued to NTUC Income for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data to users making enquiries through its website. 123 users received automated acknowledgement emails attached with files containing personal data belonging to 17 individuals.,"[""Protection"", ""Warning""]",2020-02-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---NTUC-Income-Insurance-Co-Operative-Limited--24012020.pdf,Protection,Breach of the Protection Obligation by NTUC Income,https://www.pdpc.gov.sg/all-commissions-decisions/2020/02/breach-of-the-protection-obligation-by-ntuc-income,2020-02-11,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1907-B4288 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And NTUC Income Insurance Co-Operative Limited SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (the “Commission”) was notified on 17 July 2019 by NTUC Income Insurance Co-Operative Limited’s (the “Organisation”) of the unintended disclosure of personal data to users making enquiries through its website. The users received automated acknowledgement emails attached with files containing personal data of other individuals (the “Incident”). 2. On 10 July 2019, the Organisation enhanced the website’s online enquiry application to allow users to upload supporting documents together with their enquiry submissions. When a user A uploaded files, the application assigned a variable that served to identify the files for future retrieval by the same user or by the Organisation. However, due to a coding error, if the next user B did not upload files, the variable generated for the preceding user was applied to the B’s submission. As a result, the supporting documents uploaded by A were associated with B’s submission. 3. This coding error manifested in the sending of acknowledgement emails, which were intended to include supporting documents submitted by the user. When acknowledgement emails were generated for a user who did not upload files, the coding error caused the files uploaded by a preceding user to be attached. There were 17 users whose uploaded files were sent to 123 other users in this way. The files contained their personal data, such as names, policy numbers, premium amounts, sum assured and period of coverage, email and mailing addresses. 4. The Organisation admitted that the Incident was caused by poor quality codes. The Commission found that such errors should have been detected during the manual code review process that the Organisation had conducted. Further, before the enhancement went “live”, the Organisation’s tests did not simulate the various scenarios expected whereby some users would upload files while others did not. 5. The Organisation has since sought to improve checks on coding quality by replacing its manual code review process with tools such as Crucible and SonarQube. It also moved to ensure that test scenarios were adequate and that test plans and reviews were in place before changes in its IT applications and systems were allowed to be deployed. 6. In the circumstances, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 and decided to give a warning to the Organisation. No directions are required as the Organisation has implemented corrective measures that addressed the gap in its security arrangements. ",Warning,50f8e6a44f01ed62a2f3b441bf9c89a658c16419,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,109,109,1,952,"A financial penalty of $16,000 was imposed on Royal Caribbean Cruises (Asia) for failing to put in place reasonable security arrangements to protect the personal data of its customers. The personal data was subjected to a ransomware attack.","[""Protection"", ""Financial Penalty""]",2020-02-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Royal-Caribbean-04022020.pdf,Protection,Breach of the Protection Obligation by Royal Caribbean Cruises (Asia),https://www.pdpc.gov.sg/all-commissions-decisions/2020/02/breach-of-the-protection-obligation-by-royal-caribbean-cruises-(asia),2020-02-11,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 5 Case Nos.: DP-1904-B3721 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Royal Caribbean Cruises (Asia) Pte. Ltd. … Organisation DECISION 1 Royal Caribbean Cruises (Asia) Pte. Ltd. [2020] SGPDPC 5 Tan Kiat How, Commissioner — Case No. DP-1904-B3721 4 February 2020 Introduction 1 On 14 April 2019, Royal Caribbean Cruises (Asia) Pte. Ltd. (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that the systems of one of the Organisation’s vendors (the “IT Vendor”) had been subject to a cyber-attack, resulting in the personal data of some of the Organisation’s customers being exposed to unauthorised access (the “Incident”). Facts of the Case 2 In early 2017, the Organisation engaged the IT Vendor to develop and supply the Organisation with an electronic receipt system to generate and store electronic receipts with respect to payments made by the Organisation’s customers for cruise and holiday bookings (the “Receipt System”). The initial plan was for the Receipt System to be hosted on the Organisation’s internal server. However, after taking into consideration that the Receipt System would need to be accessed from external Internet Protocol (“IP”) addresses during events and roadshows, the Organisation asked the IT Vendor to host the Receipt System on an Amazon Web Services (“AWS”) server. The Receipt System was installed on an AWS Server in December 2017 and the Organisation started using the Receipt System at the end of January 2018. 3 On 11 April 2019, the Organisation encountered difficulties operating the Receipt System and reported the issue to the IT Vendor. On 12 April 2019, the IT Vendor informed the Organisation that the Receipt System had been subject to a cyber-attack. The cyber-attacker had deleted the database in the Receipt System, and replaced it with a ransom message demanding payment of 0.08 Bitcoins in order to recover the deleted data. 2 4 The following types of personal data belonging to 6,004 of the Organisation’s customers (“Affected Customers”) were affected by the Incident (collectively, “Customer Data”): (a) Receipt Date and Number; (b) Sailing Date; (c) Name of Guest / Card Holder; (d) Ship Name; (e) Booking ID; (f) Amount Paid; (g) Payment Type; (h) The first four and last four digits of credit / debit card number for payments made using credit / debit cards; (i) Issuing bank and the 6 digit cheque numbers for payments made using cheques; and (j) 5 Voucher redemption numbers for payment made using vouchers. In addition, 440 of the 6,004 Affected Customers had completed an online check-in process that required them to provide additional personal data. These 440 Affected Customers had the following types of additional personal data placed at risk of unauthorised access (collectively, “Additional Customer Data”): (a) Name; (b) Nationality; (c) Marital status; (d) Date of birth; (e) Residential address; 3 (f) Mobile number; (g) Email address; (h) Emergency contact information; (i) Last 4 characters of the passport numbers; (j) Passport expiry date; and (k) Customer credit card details including the cardholder's name, credit card issuer, last 4 digits, and expiry date. 6 There were 25 employees of the Organisation whose personal data was also affected by the Incident (collectively, “Employee Data”): 7 (a) Name; (b) Receipt System Username; (c) Receipt System User role; (d) Receipt System Password; (e) Email Address; (f) Mobile number; and (g) Location (i.e., office or roadshow). Upon discovery of the Incident, the Organisation took the following remedial actions: (a) On 12 April 2019, the Receipt System’s phpMyAdmin1 web application name was changed to obscure access. IP address restrictions were also added for access to the Receipt System; 1 phpMyAdmin is an open source administration tool for MySQL and MariaDB data over the world wide web. 4 (b) On 16 April 2019, the Organisation engaged a cybersecurity consultant to conduct technical forensic investigations and identify vulnerabilities in the Receipt System; (c) On 17 April 2019, the Organisation took the Receipt System offline permanently. The Organisation also blocked its online check-in portal to prevent information from the Receipt System from being used to access Additional Customer Data of the 440 Affected Customers; and (d) On 1 May 2019, the Organisation notified the 440 Affected Customers of the Incident, on the basis that the Additional Customer Data that may have been accessed through the online check-in portal was likely to be sensitive and/or could materially impact them. Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 8 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 taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. 9 As a preliminary point, the Organisation owned the Receipt System and had possession and control over the Customer Data, Additional Customer Data and Employee Data at all material times. While the IT Vendor was engaged to develop the Receipt System, the Commission’s investigations revealed that the IT Vendor had not processed, nor were they engaged to process, the Customer Data, Additional Customer Data and Employee Data on the Organisation’s behalf. The IT Vendor was accordingly not a data intermediary and the Organisation was solely responsible for the protection of the Customer Data, Additional Customer Data and Employee Data. 10 The Receipt System had vulnerabilities and gaps that the cyber-attacker could easily have exploited, resulting in the Incident: 5 (a) The administrative credentials (i.e., administrator username and password) to log into the Receipt System were stored in files within the same server with no access controls and were therefore publicly accessible; and (b) The version of the phpMyAdmin tool in use with the Receipt System at the material time was not patched and contained known security vulnerabilities.2 11 In relation to (a), given that the administrative credentials would allow and enable access to Customer Data, Additional Customer Data and Employee Data of a significant number of individuals stored in the Receipt System, it clearly should not have been stored in files without access controls, especially so when the files were in the same server. In relation to (b), and as mentioned in previous decisions,3 regular security testing and patching as security measures is absolutely crucial. Patching is one of the common tasks that all system owners are required to perform in order to keep their security measures current against external threats. The Organisation clearly did not have any process in place to ensure regular patching in the present case. 12 According to the Organisation, it was the IT Vendor’s responsibility to put in place the appropriate security measures for the Receipt System. In contrast, the IT Vendor asserted that it was the Organisation’s network security team that was in charge of security. The Commission’s investigations revealed that the Organisation had not in fact engaged the IT Vendor to provide services in relation to security maintenance or patching of the Receipt System. As the data controller and customer, the Organisation ought to be clear about the scope of services that it is procuring from the IT Vendor, and document the scope properly in contract or other project documentation. In this case, the Organisation was not able to produce anything in writing to corroborate its assertions. The absence of documentation, on the contrary, buttresses the IT Vendor’s assertion that it was not engaged to provide services in relation to security measures for the Receipt System. Without clarity, the risks of any omissions will fall on the Organisation, which as data controller is ultimately responsible. In the circumstances, the Commissioner finds that it was the Organisation and not the IT Vendor that had the obligation to ensure that the Receipt System had up-to-date security maintenance and patching. 2 The security vulnerabilities were listed in Common Vulnerabilities and Exposures, which is a list of publicly disclosed information security vulnerabilities and exposures. 3 See for example Re The Cellar Door Pte Ltd and Global Interactive Works Pte Ltd [2016] SGPDPC 22 at [26]; Re Singapore Health Services Pte. Ltd. & others [2019] SGPDPC 3 at [124]; Re Tutor City [2019] SGPDPC 5 at [23]; Re Genki Sushi [2019] SGPDPC 26 at [20]-[21]. 6 13 The Organisation’s failure to implement security measures, including software patches to ensure that vulnerabilities the Receipt System were properly patched, resulted in a standard of protection that fell far short of what was required for the Receipt System. As such, the Organisation failed to put in place reasonable security arrangements to protect the Customer Data, Additional Customer Data and Employee Data. Accordingly, the Commissioner finds the Organisation in breach of section 24 of the PDPA. The Commissioner’s Directions 14 In determining the directions, if any, to be imposed on the Organisation under section 29 of the PDPA, the Commissioner took into account the following mitigating factors: 15 (a) The Organisation cooperated with the Commission in its investigations; and (b) The Organisation took prompt remedial actions in respect of the Incident. Having considered all the relevant factors of this case, the Commissioner hereby directs the Organisation to pay a financial penalty of $16,000 within 30 days from the date of this direction, 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 it is paid in full. The Commissioner has not set out any further directions given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 7 ",Financial Penalty,9e050b9f6c3568f6a2dff1cb150947fe99ed4f03,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,110,110,1,952,"A financial penalty of $26,000 was imposed on SPH Magazines for failing to put in place reasonable security arrangements to prevent the unauthorised access of personal data of members of HardwareZone forum site.","[""Protection"", ""Financial Penalty""]",2020-02-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---SPH-Magazines-Pte-Ltd.pdf,Protection,Breach of the Protection Obligation by SPH Magazines,https://www.pdpc.gov.sg/all-commissions-decisions/2020/02/breach-of-the-protection-obligation-by-sph-magazines,2020-02-11,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 3 Case No DP-1802-B1731 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And SPH Magazines Pte Ltd … Organisation DECISION 1 SPH Magazines Pte Ltd [2020] SGPDPC 3 Tan Kiat How, Commissioner — Case No DP-1802-B1731 31 January 2020 Facts of the Case 1 On 20 February 2018, SPH Magazines Pte Ltd (the “Organisation”) voluntarily notified the Personal Data Protection Commission (the “Commission”) that the account of a senior moderator of its HardwareZone forum site (the “Forum”) had been accessed by an unknown hacker who used the senior moderator’s credentials to retrieve personal data of members of the Forum. The Organisation subsequently discovered through its consultants who were engaged to assist in its investigations into the incident that the senior moderator’s email address and password had been published on a credential leak database on 5 December 2017. The Organisation believed that the hacker had obtained the senior moderator’s credentials from this source or other similar databases as its investigations showed that its systems and applications had not been compromised during the incident. 2 The Organisation operates, hosts and maintains the Forum, an online Internet portal for members to engage in discussions on technology and other matters. Members are required to provide their usernames, email addresses, full names and passwords during registration and this personal data would form part of a member’s user profile. Members also have the option of including the following personal data in their user profile: (a) Year of Birth (b) Gender (c) Country (d) Education (e) Job Scope (f) Role in IT Procurement 2 3 (g) Occupation (h) Industry (i) Company Size (j) Monthly Income (range) (k) Area of interest (l) Home Page URL (m) Use of MSN, Yahoo, ICQ, AIM, Skype Senior moderators of the Forum are volunteers selected by the Organisation from amongst the members of the Forum and appointed to review and moderate the discussion threads in the Forum and to ensure that any postings comply with applicable laws and the Forum’s Terms of Service. Senior moderators are also responsible for issuing warnings and other sanctions (such as suspensions or bans) to members who do not comply with the Forum’s Terms of Service. Access to members’ user profiles was given to senior moderators (through their respective senior moderator accounts) to allow them to carry out their duties. The senior moderators would be able to view the Forum members’ usernames, email addresses and any optional information included by the members in their user profiles. While the full names and passwords of the members were salted and hashed using the MD5 algorithm, and ordinarily senior moderators would not be able to view these fields, it is well-known that the MD5 algorithm is outdated and could be circumvented: see Fei Fah Medical Manufacturing Pte Ltd [2016] SGPDPC 3 at [19] and [20]. 4 The Organisation first realised that something was amiss when it was notified of an unauthorised post published using the account of a website administrator. The website administrator is employed by the Organisation. Using the administrator’s credentials, the hacker published the unauthorised post and changed the avatar of the administrator account. However, as the Forum administrators could only access the user profiles of members by way of a two-factor authorisation (“2FA”) process, the hacker was unable to access the user profiles using the administrator account. 3 5 The Organisation also subsequently discovered the website administrator’s credentials in the same credential leak database which published the senior moderator’s credentials. 6 It thus appears that the hacker used the compromised senior moderator account to access the user profiles of members. At the material time, there were a total of 685,393 user profiles in the Organisation’s system. The Organisation’s investigations further showed that the senior moderator’s account was used to perform 704,764 attempted views of Members’ user profiles using networks that did not reveal the actual source IP address, between 22 September 2017 to 30 September 2017. The frequent number of attempted views and the use of networks which are difficult to trace suggest that the senior moderator’s account was used to access personal data of Members without authorisation. The investigations also showed that the senior moderator’s account experienced unusual activity from at least December 2015. 7 Upon being notified of the Incident, the Organisation took the following remedial actions: (a) The access rights of senior moderator accounts to user profiles was temporarily suspended on 19 February 2018; (b) The Organisation sent emails to members informing them of the breach and advising members to change their passwords. The Organisation also posted a notification of the breach on the Forum website. (c) The Organisation revised its Password policy on 23 February 2018 requiring passwords to have a minimum of 8 characters and include both alphanumeric and upper/lower case characters. Passwords will also expire within 3 months; (d) 2FA was implemented for senior moderator accounts in April 2018; (e) Captcha for the Site’s login page was implemented; (f) Entries in the filed for full names was removed from the application level and purged from the database; and (g) Additional information in optional fields were also removed from the application level and purged from the database. 4 Findings and Basis for Determination 8 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. 9 The key finding in this case was that the Organisation had omitted to implement reasonable password security requirements for its senior moderators. While the Organisation did have in place a Password Policy which, amongst other things, required passwords to be of a certain length and complexity and provided for the expiration of passwords, the Policy and the security measures therein were applicable to the Organisation’s employees and did not apply to senior moderators. In fact, there was no requirement for senior moderators to change their passwords regularly or to have passwords of an acceptable length and complexity. 10 During the investigations it was discovered that the password used by the relevant senior moderator was not changed in 10 years and did not meet the length and complexity standard the Organisation implemented for its employees. In this regard, the permissions and privileges granted to senior moderators allowed senior moderators to set password expiry rules and to set prohibitions for the re-use of passwords within a selected period (i.e. password history setting) but did not compel them to do so. 11 Finally, the Organisation did not perform any security testing of the Forum website. It therefore did not have an overall picture of its security needs in relation to the website. 12 The failure to implement and enforce reasonable password security requirements on the senior moderator accounts and to conduct security testing to acquire knowledge of the Forum website’s security amounted to a breach of section 24 of the PDPA by the Organisation. The Commissioner’s Directions 13 In determining the directions to be imposed on the Organisation under section 29 of the PDPA, the following factors were taken into account: 5 Mitigating factors (a) the Organisation voluntarily notified the Commission of the Incident and members of the Forum promptly; (b) the Organisation took prompt action to implement measures to prevent a recurrence of such an incident; (c) the Organisation cooperated with the Commission’s investigations; Aggravating factors (d) The password which was compromised had not been changed for a very long period of 10 years; and (e) The Organisation was unable to detect the unauthorised access of personal data for about 2 years. 14 Having carefully considered all the relevant factors of this case, the Commissioner directs the Organisation to pay a financial penalty of $26,000 within 30 days of the date of this direction, 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. No additional directions are required in light of the remedial measures taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 6 ",Financial Penalty,0ccae1ff28f90d66c28dd2491e593155803069f2,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,111,111,1,952,"A financial penalty of $15,000 was imposed on SCAL Academy for failing to put in place reasonable security arrangements to protect the personal data of individuals on its website. These individuals had provided their personal data to SCAL Academy for registration purposes to attend its courses, seminars or workshops.","[""Protection"", ""Financial Penalty""]",2020-02-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---SCAL-Academy---080120.pdf,Protection,Breach of the Protection Obligation by SCAL Academy,https://www.pdpc.gov.sg/all-commissions-decisions/2020/02/breach-of-the-protection-obligation-by-scal-academy,2020-02-11,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 2 Case No. DP-1811-B3061 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And SCAL Academy Pte. Ltd. … Organisation DECISION SCAL Academy Pte. Ltd. [2020] SGPDPC 2 Tan Kiat How, Commissioner — Case No. DP-1811-B3061 8 January 2020 Introduction 1 SCAL Academy Pte. Ltd. (the “Organisation”) provides courses, seminars and workshops for individuals (the “Participants”) and collects personal data of Participants through its website, http://www.scal-academy.com.sg (the “Website”), for registration purposes. The Website was developed and maintained by a freelance vendor (the “Vendor”). 2 On 29 November 2018, the Personal Data Protection Commission (the “Commission”) received a complaint that the results of an online search of the names of Participants displayed links to scanned copies of registration documents (the “Documents”) on the Website (the “Incident”). The Documents were accessible by clicking on the listed links. 3 The Documents contained various personal data of 3,628 Participants including their name, race, nationality, date of birth, gender, country of birth, NRIC or work permit number, address, occupation and the name of the company the Participants were employed by (the “Compromised Personal Data”). 4 The cause of the Incident was traced to an enhancement to the Website (the “Enhancement”) which allowed Participants to upload the Documents directly onto a folder (the “Folder”) on the Website. The Vendor had been tasked with developing the Enhancement on 7 February 2018 and, in the course of doing so, the Vendor omitted to programme the Enhancement to verify that only authorised employees can access the Folder. The Documents were thus accessible without the need for login credentials. Additionally, the Vendor had also, through an oversight, omitted to implement another requirement, which is to implement Google’s recommendations to prevent bot crawlers from searching and indexing website content. 5 Following the Incident, the Organisation took the following remedial actions: (a) Implemented measures to prevent Google trawling and indexing, such as deploying ‘noindex’ tags and scripts to ignore search bots; (b) Requested Google to remove search engine records of the production environment and the links to the Documents; (c) Removed the Documents from the Website; (d) Disabled the upload function for Documents for online registration on the Website; and (e) Assessed the harm and impact of the Incident on the affected individuals and notified approximately 27 of them who the Organisation believed would likely suffer significant harm or impact. Findings and Basis for Determination Whether the Organisation had contravened section 24 of the Personal Data Protection Act 2012 (“PDPA”) 6 As a preliminary point, the Organisation owned and managed the Website, and had possession and control over the Compromised Personal Data at all material times. While the Vendor had been engaged to develop and maintain the Website and subsequently assisted in the development of the Enhancement, the Vendor had not processed any personal data collected via the Website on the Organisation’s behalf. The Vendor was therefore not a data intermediary of the Organisation, and the obligations under the PDPA did not apply to the Vendor in respect of its engagement by the Organisation. 7 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. 8 In this regard, while the Organisation had instructed the Vendor to prevent the Documents from being ‘leaked’ online, it did not check with the Vendor what security arrangements had been put in place to ensure this. It is essential that, having identified a data protection risk, the Organisation and the Vendor agree on the measures to be implemented. These can then be followed through to the testing stage and scenarios can also be devised for user acceptance testing. Since this was not done, it therefore follows that the Organisation did not conduct any tests, or verify whether the Vendor had conducted any tests, to ensure that the security arrangements were effective in protecting the Documents from unauthorised disclosure. 9 As observed in WTS Automotive Services Pte Ltd [2018] SGPDPC 26 at [24], the responsibilities of an organisation over the personal data in its control and/or possession does not require technical expertise. The examples of actions that the Organisation ought to have undertaken as set out at paragraph 8 above do not require deep technical expertise. Instead, it requires that organisations articulate their business requirements, work with their vendors on a set of agreed technical measures, and to follow through with proper testing based on risk scenarios derived from the business requirements. 10 In view of the above, the Commissioner found that the Organisation had not put in place reasonable security arrangements to protect the personal data in the Documents and, accordingly, was in breach of section 24 of the PDPA. The Organisation’s Representations 11 In the course of settling this Decision, the Organisation submitted its representations to the Commission on various aspects of the preliminary Decision. The representations, in part, covered matters which have already been addressed in this Decision or which were not relevant to this Decision. The relevant matters raised in the representations which are not addressed elsewhere in this Decision were: (a) The Organisation warned the Vendor that the Incident was a breach of the PDPA; (b) While not justifying the data breach, the Organisation took the position that the Incident neither impacted nor caused significant harm to the affected individuals; (c) The Organisation has since taken steps to prevent a recurrence of a similar incident such as strengthening and improving communication with suppliers and vendors especially where personal data is concerned and educating members on compliance with the PDPA; and (d) The Organisation counselled the Vendor and obtained an undertaking requiring the Vendor to implement additional safeguards, such as, disabling all UAT websites from being searchable by search engines, educating staff members on the PDPA and communicating and collaborating with the Organisation to ensure that work done complies with the PDPA. 12 With respect to the matter raised at [11(a)], as stated at [6], the Vendor was not a data intermediary for the purpose of its engagement by the Organisation. Nevertheless, informing the Vendor of the Incident and that the PDPA had been breached is a legitimate remedial action. This has already been taken into consideration in determining the directions to be issued to the Organisation, as set out below at [15(b)]. 13 With respect to [11(b)], this should be seen in light of the Organisation having, as part of its remedial efforts, notified affected individuals who it believed would likely suffer significant harm or impact. Looking at the Organisation’s assertions, it is the Organisation’s own view that 27 individuals were likely to have suffered significant harm or impact and mitigated this harm or impact by notifying these individuals. Again, this remedial action had already been taken into consideration when determining the appropriate directions to be issued. 14 With respect to the additional matters raised and as set out at [11(c) and (d)], the Commissioner accepts these points and the financial penalty imposed has been reduced to the amount stated below. The Commissioner’s Directions 15 In determining the directions to be imposed on the Organisation under section 29 of the PDPA, the Commissioner took into account the following mitigating factors: (a) The Organisation was cooperative in the investigations and provided information promptly; and (b) Upon being notified of the Incident, the Organisation swiftly took remedial actions. 16 Having considered all the relevant factors of this case, the Commissioner hereby directs the Organisation to pay a financial penalty of $15,000 within 30 days from the date of the directions, 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. 17 In light of the remedial actions taken by the Organisation, the Commissioner has decided not to issue any further directions. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION ",Financial Penalty,8f0ad290a860ac8ce3ca4cbe3b5a690b72561ff9,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,112,112,1,952,"A financial penalty of $9,000 was imposed on Singtel for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of some of its customers via its My Singtel mobile application.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B""]",2020-02-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Telecommunications-Limited-311219.pdf,Protection,Breach of the Protection Obligation by Singtel,https://www.pdpc.gov.sg/all-commissions-decisions/2020/02/breach-of-the-protection-obligation-by-singtel,2020-02-11,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 49 Case No. DP-1802-B1732 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Telecommunications Limited … Organisation DECISION 1 Singapore Telecommunications Limited Yeong Zee Kin, Deputy Commissioner — Case No DP-1802-B1732 31 December 2019 Introduction 1 On 21 February 2018, the Personal Data Protection Commission (the “Commission”) received a complaint from an individual mobile subscriber of Singapore Telecommunications Limited (the “Organisation”) asserting that when the subscriber accessed account details using the Organistion’s “MySingTel” mobile application (the “App”), the subscriber was able to view the personal information of another subscriber. Facts of the Case 2 The Commission’s investigations revealed that due to a technical issue that occurred during a limited period, certain mobile subscribers of the Organisation were able to view the personal data of other subscribers when they used the App (the “Incident”). The Incident took place over a period of approximately 11 hours on 20 February 2018 and the personal data of 750 subscribers (the “Affected Subscribers”) were exposed to the risk of access by other subscribers. Of these, the personal data of 39 subscribers were, in fact, accessed by other subscribers. The specific cause of this incident is described below. 3 The Incident arose during the Organisation’s migration of its database of mobile customer accounts from its existing billing system (the “Existing System”) to a new billing system (the “New System”). [Redacted]. 4 However, an issue arose when there was a mobile number previously assigned to a subscriber (“historical numbers”) that was subsequently reassigned to another subscriber. One situation in which this happened was when a subscriber ported over an existing mobile number from another mobile telephone operator to the Organisation. In order to effect the porting over, the Organisation would first issue the subscriber with a temporary mobile phone number (this is referred to as a “dummy number”) as part of the overall porting mechanism. After the subscriber’s existing mobile telephone number had been successfully ported over to the Organisation, the dummy number will cease to be linked to the subscriber [redacted]. 2 5 [Redacted]. 6 During the migration period, when a subscriber logged in to the App, the App would query the Organisation’s Master Routing Database (“MRD”) to check if the subscriber’s data had been migrated and then route the query to the relevant billing system. On 20 February 2018, due to slow response times, queries by MRD to the Existing System encountered timeouts. When these timeouts occurred, even if the subscriber had been migrated to the New System, the query would by default be routed to the Existing System. If the subscriber had a historical number, such as a dummy number [redacted], [in certain circumstances] the service information associated with both the current mobile number and the historical number would be retrieved and made available to the subscriber. The service information of the historical number could be viewed by clicking on the mobile number and information bar. If the historical number had been reassigned to an Affected Subscriber, the service information of the Affected Subscriber would have been retrieved and made available to, and therefore at risk of access by, the subscriber. In this way, the associated information of the 39 subscribers were accessed during the timeouts. 7 The types of personal information of the Affected Subscribers (the “Personal Data”) which were accessible through the App included: (a) mobile numbers; (b) mobile plans subscribed to; (c) usage details; (d) account numbers; and (e) add-on services subscribed to. The relevant subscribers1 could also modify the add-on services tied to the Affected Subscribers’ mobile number; 6 such subscribers had tried to make such modifications. 8 Upon being notified by the Commission, the Organisation ensured that migrated Subscribers who encountered timeouts when using the App were shown an error message, and performed testing to verify that this was the case. 3 Findings and Basis for Determination 9 Section 24 of the Personal Data Protection Act 2012 (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. Whether the Organisation Complied with Section 24 10 With respect to the design of the MRD, the Organisation asserted that it did not intend for the MRD to route queries to the Existing System in the event of a timeout, and that the Organisation’s intentions was for an error message to be displayed instead. I give the Organisation the benefit of doubt and accept its assertion. Since the intention was to display an error message, this ought to have been included as a scenario for user testing. Consequently, this Incident was caused by the following lapses on the Organisation’s part: (a) The Organisation had not carried out more thoroughly scoped tests to firstly ensure that dummy numbers in these circumstances did not produce any unintended effects; and (b) the test plan should have anticipated likely scenarios, such as session time- out. 12 If these had been done, the Organisation could have discovered the potential erroneous retrieval and unauthorised disclosure of the Affected Subscribers’ Personal Data for such accounts, and consequently, implemented measures to prevent the Incident from occurring. In view of the above, I found the Organisation in breach of section 24 of the PDPA. 13 The Organisation in its representations made the point that, in their view, the data breach “happened only where there was an obscure combination of factors”. While, it is accepted that a combination of events had to occur before personal data would have been disclosed, I do not think that the combination of factors was obscure. First, session timeout for MRD queries was foreseen, with the intention for an error message to be displayed. 4 Second, the Organisation had full knowledge of how dummy numbers are assigned as a temporary bridge for number porting, and that these dummy numbers are eventually reassigned. The combination of factors giving rise to the Incident was foreseeable and I do not think that the combination is obscure. The impact of the Incident was contained because of its prompt action in implementing a temporary fix. The Deputy Commissioner’s Directions 14 In determining the directions to be imposed on the Organisation under section 29 of the PDPA, I took into account the following mitigating factors: (a) the Organisation was cooperative during the investigations; (b) the Organisation took prompt action to mitigate the impact of the Incident by implementing a temporary fix within 11 hours; and (c) although the Personal Data of 750 individuals were at risk, only 39 of such individuals’ Personal Data were subject to unauthorised disclosure. 15 Having carefully considered all the relevant factors of this case, I hereby direct the Organisation to pay a financial penalty of $9,000 within 30 days from the date of the directions, 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. 16 As the Organisation had completed its migration on 19 August 2018 and there are no further risks to the Personal Data arising from the retrieval of Subscriber information from the Organisation’s Existing System, I have assessed that the remedial actions set out at [8] had sufficiently addressed the risks to the Personal Data arising from the Incident. I have therefore not made further directions for the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 5 ",Financial Penalty,e2d462d64ec0e10bc672b4850fabd12bb0f0d993,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,113,113,1,952,A warning was issued to L’Oreal Singapore for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of individuals on its website. The personal data of 7 individuals were compromised from a data breach incident involving its website.,"[""Protection"", ""Warning""]",2020-01-09,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---Loreal-Singapore-Pte-Ltd---261219.pdf,Protection,Breach of the Protection Obligation by L'Oreal Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2020/01/breach-of-the-protection-obligation-by-l-oreal-singapore,2020-01-09,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1812-B3091 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And L’Oreal Singapore Pte. Ltd. SUMMARY OF THE DECISION 1. L’Oreal Singapore Pte Ltd (the “Organisation”) operated a website which had a login portal that enabled its customers to view their profile information, redeem vouchers and make enquiries about customer points (“Customer Login Page”). The customers’ profile information included their name, email address, postal address, mobile number and date of birth (the “Personal Data”). The development and maintenance of the website was carried out by a vendor engaged by the Organisation. 2. To improve the loading speed of the website, the Organisation instructed its vendor to make some changes to the website in November 2018. However, the Organisation failed to scope the User Acceptance Tests (“UATs”) to include the normal functioning of the website, in particular the login and caching functions of the Customer Login Page, after the code changes were introduced. As a result, when a customer (“Customer A”) logged into the Customer Login Page, his or her Personal Data would be cached. Customer A’s Personal Data would then be disclosed to customers who subsequently logged in to the Customer Login Page until the cache was refreshed. Similarly, the Personal Data of the second customer (“Customer B”), who logged in after the cache refresh, would be cached, leading to disclosure of Customer B’s Personal Data to the third customer who logs in next, and all subsequent customers until the next cache refresh. When the Organisation came to know of this, the Organisation disabled the Customer Login Page. The Organisation also engaged a consultant to assist in its investigations into the matter and to provide recommendations to prevent similar incidents in the future. 3. The Personal Data Protection Commission (“Commission”) found that Personal Data of 7 individuals had been exposed to the risk of unauthorised disclosure as a result of the Organisation’s failure to ensure appropriate testing of its website or make other security arrangements to protect the Personal Data. The Commission notes the Organisation’s representations that it had completed all necessary and appropriate UATs based upon the reasonably foreseeable impact of the requested changes to its website. However, as mentioned at [2] above, the scope of the UATs was inadequate because it did not simulate the normal operating environment of the website. In particular, the UATs only provided for a limited test case of a single user logging into the website, and failed to include the foreseeable scenario of multiple users logging in sequentially. 4. Having considered the representations and taking into account all the relevant circumstances, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of section 24 of the Personal Data Protection Act 2012 and decided to give a warning to the Organisation. ",Warning,4102189a17de6b15ab601751db63326670e4ef82,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,114,114,1,952,"A financial penalty of $15,000 was imposed on Creative for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of users of its online support forum.","[""Protection"", ""Financial Penalty""]",2020-01-09,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Creative-Technology-Ltd--020120.pdf,Protection,Breach of the Protection Obligation by Creative,https://www.pdpc.gov.sg/all-commissions-decisions/2020/01/breach-of-the-protection-obligation-by-creative,2020-01-09,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 1 Case No DP-1811-B3058 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Creative Technology Ltd … Organisation DECISION 1 Creative Technology Ltd Tan Kiat How, Commissioner — Case No DP-1811-B3058 2 January 2020 Facts of this Case 1 This case concerns an online support forum (the “Forum”) operated and hosted by Creative Technology Ltd (the “Organisation”). In November 2018, the Personal Data Protection Commission (the “Commission”) was informed that the Forum had been hacked sometime in mid-2018 resulting in the unauthorised disclosure of personal data of users of the Forum (the “Incident”). 2 The Organisation first set up the Forum some time in 2004 to help users share ideas and information relating to the Organisation’s products. In 2011, the Organisation adopted a thirdparty forum software known as “vBulletin” to operate and host the forum internally. Unknown to the Organisation, the vBulletin software had a SQL vulnerability which could allow hackers to extract information hosted on the platform using SQL injection techniques. The developers of the vBulletin software released patches to address this SQL vulnerability in 2016. However, the Organisation had not installed these patches at the time of the Incident. 3 On 25 May 2018, an unknown hacker used SQL injection techniques to obtain personal data of Forum users from the Forum’s database. In particular, the hacker exploited the vulnerability in the vBulletin software to launch SQL injection attacks by using the “Forumrunner” add-on1. 4 The Organisation first came to know of the Incident on 4 June 2018, when it was notified by a security researcher that he had received a set of user data extracted from the Forum. The Organisation subsequently found that 484,512 users’ account information had been accessed and extracted in the Incident.2 Of these, only 173,763 appeared to be legitimate email addresses with the remainder, in the Organisation’s view, being “disposable” or otherwise not 1 The Forumrunner add-on allows users to use forums hosted using vBulletin on their mobile devices. 2 The Commission has not verified the number of user accounts affected for reasons explained at [14]. 2 Creative Technology Ltd legitimate 3 email addresses. Further, of the accounts with legitimate email addresses, the Organisation found that there were 8,258 active users4 (“Active Users”) who had accessed or posted on the forum between 2014 and 2018 and, amongst these Active Users, approximately 2,600 had email addresses which contained either the names or partial names of individuals. 5 According to the Organisation, the following data of Forum users (the “Personal Data”) were accessed and extracted by the hacker: (a) username; (b) password, salted and hashed by the vBulletin software (each password was hashed using the MD5 algorithm, and the resulting password was hashed for a second time by MD5 and salted with random characters)5; 6 (c) email address; and (d) Internet Protocol address (IP address). In addition, optional personal data which the Forum user may choose to enter (the “Optional Data”), including age, date of birth, other contact details (e.g. ICQ number, AIM screen name, Skype name, and MSN and Yahoo! Messenger handles), location, occupation, could be accessed when the password was used to log in to a user’s account. These data were viewable by other Forum members, with the exception of date of birth, which the individual could choose to hide from, or disclose to, other Forum users. Remedial actions 7 Upon discovering the Incident, the Organisation undertook the following remedial measures: 3 Such as email addresses from the Mailinator Service and addresses which contained gibberish or profanities. 4 According to the Organisation, users whose (i) accounts were activated (by clicking on a verification link in an email sent to them during the Forum registration process); and (ii) had logged into the Forum with their user account, or had uploaded at least one post in the Forum. 5 See paragraph 11. 3 Creative Technology Ltd (a) it conducted a review of all its systems, servers, and software used by its IT and Internet Marketing teams and determined that the incident was an isolated occurrence, and the other systems had been subject to regular security reviews and security patches; (b) it notified the 8,258 Active Users of the Incident; and (c) it shut down the Forum temporarily on 4 June 2018 to prevent further incursions, and shut it down permanently shortly thereafter (by 20 June 2018). Findings and Basis for Determination Whether the Organisation complied with the Protection Obligation 8 Section 24 of the Personal Data Protection Act 2012 (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”). It is not in dispute that the Personal Data and the Optional Data were in the Organisation’s possession and under its control at the time of the Incident. 9 The Organisation had failed to put in place reasonable security arrangements to protect the Personal Data for the following reasons. 10 First, the Organisation had not patched or updated its version of vBulletin since 2 May 2015, three years prior to the Incident. This was a significant factor leading to the Incident. As stated in the Commission’s Guide to Securing Personal Data in Electronic Medium (revised 20 January 2017, at [16]), regular security patching is important for organisations to keep their systems and databases current and minimise their vulnerabilities. 11 Secondly, the use of the MD5 algorithm is no longer sufficiently secure for password hashing, as compared with other available algorithms. Passwords hashed with MD5 are susceptible to some forms of attacks and, if they are compromised, this could lead to the disclosure of other personal data. Individuals may face additional risks if they had used the same email address and passwords for other online accounts. In this regard, the developers of vBulletin no longer used MD5 hashed password by default, opting for the more secure bcrypt, 4 Creative Technology Ltd since the March 2014 version of vBulletin. This reinforces the point that if the Organisation had implemented the updates, the users’ hashed passwords would be more secure. 12 In the circumstances, the Commissioner found the Organisation in breach of section 24 of the PDPA. The Commissioner’s Directions 13 In determining the directions to be imposed on the Organisation under section 29 of the PDPA, the Commissioner took into account the following mitigating factors: (a) the Organisation was cooperative in the investigations and had provided prompt and detailed responses to the Commission’s requests for information; (b) the Organisation implemented reasonable remedial and corrective actions to address the Incident, which includes notifying the affected Active Users; (c) even though the Organisation had deleted the database, it made the effort to go through its email logs to determine the number of affected user emails which contained either names or partial names. 14 In the course of settling this decision, the Organisation made representations highlighting the low sensitivity of the personal data that was disclosed and the fact that the disclosure was unlikely to have caused serious or substantial harm or injury. The type of personal data involved in the Incident (as set out at [5] above) has already been taken into consideration when deciding on the quantum of the financial penalty to be imposed and, as such, no further reduction in the quantum is warranted. 15 The Organisation’s deletion of the user database is an aggravating factor that affected the Commission’s investigations. The number of affected individuals estimated by the Organisation could not be verified given their deletion of the user database. The Organisation was notified about the Incident by a security researcher on 4 June, verified that user account information had been exfiltrated, and by 20 June it had shut down the forum and deleted the user database: see [8]. These decisions were made within a short period of 2 weeks but cast a shadow stretching far into the future. By the time the Organisation was formally notified that 5 Creative Technology Ltd the Commission was commencing investigations in November 2018, the user database had been expunged for 5 months. 16 In Re NTUC Income Insurance Co-operative Ltd [2018] SGPDPC 10, the Commission stated that all organisations have the duty to preserve evidence and that it does not look favourably on the destruction or deletion of potentially relevant documents and records. The decision sets out some of the factors that the Commission would take into account in determining whether or not an organisation would be sanctioned for such deletion or destruction. These factors include whether or not the deletion prejudiced a fair investigation and whether or not legal proceedings were anticipated or contemplated. In this case, investigations were prejudiced given that the number of affected individuals could not be verified. 17 The Organisation made representations stating that it had deleted the user database to comply with section 25 of the PDPA, which imposed an obligation on organisations to cease retention of personal data once the purpose for its collection is met, and retention is no longer necessary for legal or business purposes. The Organisation submitted that section 25 applied to a situation where there was an ongoing legal course of action or a risk of potential litigation, neither of which existed at the time. The Organisation’s interpretation of section 25 is unnecessarily narrow. As the Commission held in NTUC Income Insurance Co-operative Ltd, section 25 allows for the retention of personal data where it is required for legal purposes such as investigations by the Commission. 18 The question is whether, in June 2018 when the user database was deleted, the Organisation could have anticipated an investigation by the Commission. There are a number of facts that the Organisation should have considered before deciding to delete the user database. First, the source of information about the exfiltration was an external security researcher; second, the nature of notification was that the security researcher had received personal data extracted from the Forum from a third party source; third, the Organisation verified that personal data from 484,512 user accounts had been exfiltrated: see paragraph 4. Collectively, these facts point to a not insignificant data breach that affected a significant number of users, anyone of whom might initiate a complaint. 6 Creative Technology Ltd 19 The Organisation ought to have retained the user database offline for a period, but could have limited access to it. It is not necessary at this point to venture an opinion about how long the Organisation ought to have preserved the user database. The necessity of preservation and the period of preservation is determined on the facts of each case. What can be said is that the decision to delete the user database within 2 weeks of discovering the Incident was taken too hastily. 20 The Organisation made representations stating that it had not deleted the user database in bad faith. Whilst it has been said that the decision was taken too hastily, there is no evidence to suggest that the decision was taken in bad faith or in order to put evidence beyond the reach of investigations. These are not considerations that factored in the determination of the directions. 21 The Commissioner hereby directs the Organisation to pay a financial penalty of $15,000 within 30 days, 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. 22 The Commissioner decided not to impose any other direction as the Organisation has ceased to operate the Forum and no longer retains the database of Forum users. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 7 ",Financial Penalty,1d4e08be82b95f65085e2a8f991ad5845f795f48,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,116,116,1,952,"A financial penalty of S$5,000 was imposed on PeopleSearch for failing to put in place reasonable security arrangements to protect personal data of its clients. The incident resulted in the data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty""]",2020-01-09,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---PeopleSearch-Pte-Ltd---261219.pdf,Protection,Breach of the Protection Obligation by PeopleSearch,https://www.pdpc.gov.sg/all-commissions-decisions/2020/01/breach-of-the-protection-obligation-by-peoplesearch,2020-01-09,"PeopleSearch Pte. Ltd. [2019] SGPDPC 47 PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 47 Case No DP-1903-B3521 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And PeopleSearch Pte. Ltd. … Organisations DECISION 1 PeopleSearch Pte. Ltd. [2019] SGPDPC 47 PeopleSearch Pte. Ltd. [2019] SGPDPC 47 Yeong Zee Kin, Deputy Commissioner — Case No DP-1903-B3521 26 December 2019 Introduction 1 PeopleSearch Pte. Ltd. (the “Organisation”) is a subsidiary of a listed Singapore company (“Listed Company”) that provides professional recruitment and flexible staffing services in Asia. On 15 March 2019, the Listed Company notified the Personal Data Protection Commission (the “Commission”) of a ransomware attack suffered by the Organisation on 1 to 2 March 2019, which resulted in the Organisation not being able to access its clients’ personal data (the “Incident”). Facts of the Case 2 At the material time, the Organisation had a business division that managed outsourced payroll for the Organisation’s clients. In order to do so, the Organisation used a payroll software installed in a server in a virtual machine environment (the “VM Server”). The Organisation’s clients would connect to the VM Server through remote desktop protocol to use the payroll software. All the information (including personal data) in the payroll software was stored in a database that was hosted in the VM Server. 3 At the time of the Incident, the database included the following personal data of 472 individuals employed by 2 of the Organisation’s clients1 (collectively, “Employee Data”): (a) Name; (b) NRIC number; (c) Residential address; The payroll information of the Organisation’s other clients had been migrated from the VM Server to another server. This was in preparation for the Organisation’s business division managing outsource payroll being incorporated into a separate legal entity. 1 2 PeopleSearch Pte. Ltd. 4 (d) Contact number; (e) Email address; (f) Bank account number; and (g) Salary details. [2019] SGPDPC 47 The database also included the following personal data of the employees’ next of kin (“Next of Kin Data”)2: 5 (a) Name; (b) Age; (c) Contact number; and (d) Relationship to the respective individual. Taking into consideration the individuals whose information were stored as Next of Kin Data, it is estimated that a total of 944 individuals (comprising the 472 individuals with Employee Data and 472 individuals with Next of Kin Data) were affected by the Incident (the “Affected Individuals”).3 6 The Organisation discovered the Incident on 4 March 2019 when a ransom note appeared when it attempted to access the VM Server. The ransom note informed the Organisation that its files had been encrypted, and required payment in Bitcoins in exchange for the decryption key. The Organisation refused to pay the ransom to the cyber-attacker and restored its business operations by using a backup of the VM Server as at 1 March 2019. 7 Upon discovery of the Incident, the Organisation promptly carried out the following remedial actions: 2 Some or all of the Next of Kin Data may also constitute Employee Data in that it may be data about the employee (namely, who is their next of kin) which may enable the employee to be identified. However, as the total number of Affected Individuals includes both the employees and their next of kin, the two sets of data are identified separately for the purposes of this Decision. 3 The Organisation was unable to provide the Commission with the number of individuals who were listed as “next of kin” in the payroll information of the 472 individuals as it was no longer in possession of the relevant customer data file. It is estimated that each of the 472 individuals would have provided Next of Kin Data of at least 1 individual. 3 PeopleSearch Pte. Ltd. (a) [2019] SGPDPC 47 Disabled remote desktop accounts and/or changed passwords to mitigate any risks relating to credentials; and (b) 8 Installed the latest windows server updates on the restored VM Server. Based on the Organisation’s internal investigations, there was no spike in the outgoing traffic logs from the VM Server at the time of the Incident. This suggested that the risk that Employee Data (including the Next of Kin Data) was exfiltrated by the cyber-attacker was immaterial. On 1 April 2019, the Organisation’s business division managing outsource payroll was incorporated into a separate legal entity and the VM Server was decommissioned. Findings and Basis for Determination Whether the Organisations had breached section 24 of the PDPA 9 It is undisputed that Employee Data and Next of Kin Data constitutes “personal data” as defined in section 2(1) of the Personal Data Protection Act 2012 (the “PDPA”). The Organisation had possession and/or control over the Employee Data and Next of Kin Data at all material times, and accepted its responsibility for protecting such data under the PDPA. While there may have been no exfiltration of the Employee Data, as mentioned at [8], there was unauthorised modification of the Employee Data as the ransomware rendered it inaccessible to the Organisation. 10 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. In assessing the standard of reasonable security arrangements required, I considered the fact that Employee Data included NRIC numbers and personal data of a financial nature (i.e. bank account numbers and salary details).4 When it comes to the protection of such personal data, there is a need to put in place stronger security measures because of the actual or potential harm, and the severity of such harm, that may befall an individual from an unauthorised use of such data.5 In my view, the Organisation failed to put in place reasonable security arrangements to protect the Employee Data and Next of Kin Data for the reasons explained below. 4 5 Re Aviva Ltd [2018] SGPDPC 4 at [17] Re Credit Counselling Singapore [2017] SGPDPC 18 at [25] 4 PeopleSearch Pte. Ltd. 11 [2019] SGPDPC 47 The Organisation admitted that it had not carried out any security scans, penetration testing or patching of the VM Server for at least 12 months preceding the Incident. According to the Organisation, its omission was due to a departure of an employee who was responsible for oversight of the VM Server. This explanation is not accepted. 12 As emphasized in previous decisions and the Commission’s Guide to Securing Personal Data in Electronic Medium (revised 20 January 2017) at [16.3] and [16.4], regular security testing and patching of IT systems are important security measures that organisations should implement to guard against a possible intrusion or attack.6 The Organisation’s failure to have any process in place to ensure regular security testing and patching of the VM Server resulted in a system that had vulnerabilities and gaps that were exploited by the attacker in planting the ransomware to encrypt the Employee Data. In view of the fact that the VM Server stored personal data of a sensitive nature, this fell far short of the standard of protection required. In the circumstances, I find the Organisation in breach of Section 24 of the PDPA. 13 Nevertheless, I note that the Organisation had a good practice of having regular backups of the VM Server. This significantly mitigated the impact of the Incident on the Organisation’s business operations. The Organisation was able to restore the VM Server from a backup as at 1 March 2019, and only lost access to the Employee Data for approximately 2 days from 2 March 2019 to 4 March 2019. 14 In today’s digital age where organisations store information (including personal data) online and move towards a paperless future, it is critically important that they have processes in place to backup their data at frequent and regular intervals. The failure to do so may result in crippling consequences to an organisation’s business operations in the event of a cyberattack. In this case, the Organisation’s good practice of having regular backups is a strong mitigating factor that I have taken into account in determining the quantum of financial penalty to impose. 6 See for example Re Genki Sushi Singapore Pte Ltd [2019] SGPDPC 26 at [20] and [21] 5 PeopleSearch Pte. Ltd. [2019] SGPDPC 47 The Deputy Commissioner’s Directions 15 Having found the Organisation in breach of section 24 of the PDPA, I took into account the following mitigating factors in determining the directions to be imposed on the Organisation: (a) the Organisation’s regular backup process of the VM Server which significantly mitigated the impact of Incident as discussed at [13] and [14]; (b) The Organisation’s prompt actions to mitigate the effects of the Incident and prevent recurrence of a similar breach; (c) The Organisation’s full cooperation with the Commission’s investigations; (d) There did not appear to be any exfiltration of Employee Data from the VM Server; and (e) The Commission did not receive any complaints about the Incident and there was no indication that the Incident caused harm to the Affected Individuals. 16 Having considered all the relevant facts and circumstances of this case, I hereby direct the Organisation to pay a financial penalty of $5,000 within 30 days from the date of this direction, 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. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 6 ",Financial Penalty,c4a52d4f14229d8cac99db0327d1480633fb17ae,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,117,117,1,952,"A financial penalty of $6,000 was imposed on National Healthcare Group for failing to put in place reasonable security arrangements to protect a list containing the personal data of partner doctors and members of the public from being publicly accessible online.","[""Protection"", ""Financial Penalty"", ""Healthcare""]",2020-01-09,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---National-Healthcare-Group-Pte-Ltd---261219.pdf,Protection,Breach of the Protection Obligation by National Healthcare Group,https://www.pdpc.gov.sg/all-commissions-decisions/2020/01/breach-of-the-protection-obligation-by-national-healthcare-group,2020-01-09,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 46 Case No DP-1802-B1703 and DP-1802-B1765 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And National Healthcare Group Pte Ltd … Organisation DECISION National Healthcare Group Pte Ltd [2019] SGPDPC 46 National Healthcare Group Pte Ltd [2019] SGPDPC 46 Yeong Zee Kin, Deputy Commissioner — Case No DP-1802-B1703 and DP1802-B1765 26 December 2019 Introduction 1 On 10 February 2018, the National Healthcare Group Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) about a complaint it had received in relation to a list containing personal information of partner doctors of the Organisation (the “List”) which was accessible on the Internet (the “Incident”). Subsequently, on 28 February 2018, the Commission received a separate complaint over the Incident. Facts of the Case 2 On 17 March 2015, the Organisation awarded a developer (“Website Developer”) a contract to develop its website (the “Website”). The Organisation specified the Website’s functional requirements and contents. A company specialising in IT services (“IT Services Provider”) provided the Organisation with IT support. In this regard, the IT Services Provider ensured that the IT specifications of the Organisation were complied with by the Web Developer, which included coordinating and verifying bug fixes and remedies 2 National Healthcare Group Pte Ltd [2019] SGPDPC 46 of security vulnerabilities implemented by the Web Developer. During the process of developing the Website, a section for restricting access to the Website (including the List) was not included in a web configuration file. 1 The Organisation, Website Developer and IT Services Provider signed off on the Website’s functional requirements specification, user acceptance test cases, and website commissioning. The relevant web configuration file was not examined before the Website went “live” in December 2015. 3 Around June or July 2016, a vendor (the “Vendor”) was engaged to conduct a penetration test of the Website. The penetration test report (the “Penetration Test Report”) highlighted the unrestricted access to the List through the Internet as a vulnerability. The Penetration Test Report also recommended the remedy, which was to ensure that the authorisation rules be configured to restrict Internet access to authorised users only. 4 On 7 February 2018, a general practitioner (“GP”), who had signed up to be a partner doctor of the Organisation, found the List through a Google search of her name and notified the Organisation. The List contained personal information of 129 GPs who had registered to be partner doctors of the Organisation via an online form on the Website (“NHG Partners”), and personal information of 5 members of public which were generated when they submitted feedback on the Website. 1 Web configuration files determine the way a website or directory on a website behaves. Web configuration files placed in the root directory of a website will affect the behavior of the entire site. 3 National Healthcare Group Pte Ltd 5 [2019] SGPDPC 46 The types of information contained in the List (collectively, the “Disclosed Data”) include: (a) With respect to the 129 GPs: (i) their full names (128 GPs), mobile numbers (111 GPs), mailing address (14 GPs), email address (117 GPs) and clinic address (115 GPs) (collectively, “GP’s Contact Information”); (ii) Singapore Medical Council (“SMC”) registration numbers of 129 GPs (“GP’s Registration Numbers”); and (iii) NRIC numbers (111 GPs), dates of birth (112 GPs) and photographs (41 GPs) (collectively, “GP’s Other Data”). (b) With respect to the 5 non-GPs, full names and email addresses, as well as mobile numbers of 3 of them (“Other Individual’s Data”). 6 Upon being notified of the Incident on 7 February 2018, the Organisation promptly carried out the following remedial actions: (a) On 8 February 2018, the Organisation took the Website offline, as well as found and fixed the cause of the Incident; (b) The Organisation sent several requests to Google to remove cached copies of the List indexed from 9 to 13 February 2018. From 21 February 2018, the Organisation performed daily Google searches on the 129 affected records until the cached links could no longer be found on 5 March 2018. Thereafter, the Organisation conducted periodic Google searches until 8 May 2018; and 4 National Healthcare Group Pte Ltd (c) [2019] SGPDPC 46 From 19 February 2018 to 6 March 2018, the Organisation contacted all affected GPs to inform them of the Incident. 7 In addition, to prevent a recurrence of a similar Incident, the Organisation has also adopted the following practices: (a) Two additional checks at front-end publishing site for SharePoint websites will be carried out during user acceptance test and prior to going “live”: (i) The project manager would check for configuration which controls publishing of “visible” pages (lists) after the vendor submits the web configuration prior to the deployment; and (ii) The test script would include testing of authorised access to the relevant web pages. The web pages would also generally be tested to ensure non-public web pages cannot be accessed by non-authorised users. (b) Performing penetration tests prior to websites going “live”. Findings and Basis for Determination Whether the Protection Obligation under Section 24 of the PDPA applies to the Disclosed Data 8 While the Disclosed Data is personal data as defined in section 2(1) of the Personal Data Protection Act 2012 (“PDPA”), the Protection Obligation under section 24 did not apply to the following 2 categories of Disclosed Data – GP’s Contact Information and GP’s Registration Numbers. 5 National Healthcare Group Pte Ltd 9 [2019] SGPDPC 46 In relation to GP’s Contact Information, pursuant to section 4(5) of the PDPA, Parts III to VI of the PDPA do not apply to business contact information. GP’s Contact Information falls within the definition of “business contact information” as defined in section 2(1) of the PDPA because it was provided by the GPs to the Organisation for the purposes of registration as NHG Partners, and as a means of contacting them in their professional capacity. 10 In relation to GP’s Registration Numbers, the same information is generally available to the public on the SMC website and hence it is “publicly available” as defined in section 2(1) of the PDPA. The raison d’etre for making such information available is to assist in the identification of licensed medical practitioners and the nature of their qualification and practice. The register of medical practitioners is maintained by the Singapore Medical Council under section 19 of the Medical Registration Act. It is maintained as multiple lists, i.e., locally-trained doctors, international medical graduates, provisional, conditional, temporary or full registrations, as well as specialist registration and family physician registration. This information enables an inquisitive patient to verify the nature of medical practice that a physician is permitted to practice. To my mind, this is information that falls under the “other similar information about the individual” limb of the definition of business contact information as it assists in the identification of the medical practitioner to whom the business contact information relates. 11 In the circumstances, the Protection Obligation only applied to GP’s Other Data and Other Individual’s Data (collectively, the “Disclosed Personal Data”). Whether the Organisation had breached the Protection Obligation under section 24 of the PDPA 6 National Healthcare Group Pte Ltd 12 [2019] SGPDPC 46 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. 13 As a preliminary point, the Organisation owned the Website and had possession and control over the Disclosed Personal Data at all material times. While the Website Developer was engaged to develop the Website and the IT Services Provider provided IT support to the Organisation (including maintenance and technical support for the Website), the investigations revealed that neither of these parties processed the Disclosed Personal Data on the Organisation’s behalf with respect to the Website. The IT Service Provider and Website Developer were accordingly not data intermediaries with respect to the operation of the Website, and the Organisation was solely responsible for the protection of the Disclosed Personal Data. 14 Based on the investigations, the Organisation had failed to put in place reasonable security arrangements to protect the Disclosed Personal Data as explained below. 15 The Penetration Test Report expressly pointed out that web services could be used to access SharePoint data (which included the List containing the Disclosed Personal Data) via the Internet and recommended that this vulnerability be remediated by reconfiguring the web configuration to restrict access to authorised users only. The Penetration Test Report was issued more than a year prior to the Incident. This was more than sufficient time for the Organisation to remedy the vulnerability which caused the Incident. 7 National Healthcare Group Pte Ltd 16 [2019] SGPDPC 46 According to the Organisation, the vulnerability was inadvertently left unfixed as it was not sufficiently highlighted by the Vendor in the Penetration Test Report. This was an unsatisfactory excuse. First, the relevant findings and recommendations were the first item in the Penetration Test Report. Second, they were expressed in terms that no technical expertise was required for their significance to be understood. If the Organisation did not understand the findings and/or recommendations, it should have consulted the Vendor for clarifications. 17 The Organisation also asserted that it had relied on IT Services Provider and Website Developer to act on any issues identified in the Penetration Test Report. It should be reiterated that while an organisation may delegate work to vendors to comply with the PDPA, the organisation’s responsibility for complying with its statutory obligations under the PDPA may not be delegated.2 In this case, the Organisation failed to exercise reasonable oversight with respect to the review of the Penetration Test Report and rectification of the vulnerabilities of its Website. Representations by the Organisation 18 In the course of settling this decision, the Organisation made representations and asked that a warning to be imposed in lieu of a financial penalty. The Organisation raised the following factors in its representations: (a) As the appointed public healthcare shared services provider, the IT Services Provider was responsible for the overall management, 2 See WTS Automobile Services Pte Ltd [2018] SGPDPC 26 at [14] and [23]. 8 National Healthcare Group Pte Ltd [2019] SGPDPC 46 deployment and maintenance of the Organisation’s IT systems, including the Website. Similar to the facts of Re Singapore Health Services Pte Ltd & Ors [2019] PDPC 3, the IT Services Provider’s staff was deployed to the Organisation to support day-to-day operations and provide technical support. As there was no IT staff employed by the Organisation, it had to rely on the technical expertise provided by the IT Services Provider. In particular, the Chief Information Officer (“CIO”) and Cluster Information Security Officer (“CISO”) for the Organisation was employed by the IT Services Provider and seconded to the Organisation; (b) The IT Services Provider was a data intermediary. The Website’s database was hosted on the Healthcare Data Centre (H-Cloud) network which was (and is still) operated, maintained and managed by the IT Services Provider; (c) The IT Services Provider was in charge of the penetration test, as well as coordinating and deploying the fixes. The vulnerability on the Website that caused the Incident was not highlighted to the Organisation; and (d) The Disclosed Personal Data was not medical data, and therefore not personal data of a particularly sensitive nature which should be accorded a higher standard of protection. 19 Having considered the representations, I have decided to maintain the financial penalty set out in [21] for the following reasons: (a) While the IT Services Provider’s staff deployed to fill the CIO and CISO role may have been employed by the IT Services Provider, to 9 National Healthcare Group Pte Ltd [2019] SGPDPC 46 the extent that they were carrying out the functions of the Organisation’s CIO and CISO in accordance to the terms of their secondment, they were acting on behalf of the Organisation. As such, I find that their actions should be attributed to the Organisation and not the IT Services Provider; (b) The Incident did not arise from a compromise of the Healthcare Data Centre (H-Cloud) network that hosted the Website’s database. Instead, and as mentioned at [2], the cause of the Incident was that a section for restricting access to the Website (including the List) was not included in a web configuration file. While the IT Services Provider provided technical support for the Website, it did not process the Disclosed Personal Data through the Website. The IT Services Provider was accordingly not a data intermediary with respect to operation of the Website; (c) As explained at [15] to [17], the Organisation failed to exercise reasonable oversight with respect to review of the Penetration Test Report and rectification of vulnerabilities of the Website. In this regard, the Penetration Test Report had expressly pointed out that web services could be used to access SharePoint data (which included the List containing the Disclosed Personal Data) and recommended that this vulnerability be remediated by reconfiguring the web configuration to restrict access to authorised users only; and (d) The fact that the Disclosed Personal Data was not medical data had already been taken into account in the quantum of financial penalty set out in [21], which would have been higher if the Disclosed Personal Data had been of a more sensitive nature, such as medical data. 10 National Healthcare Group Pte Ltd [2019] SGPDPC 46 Directions 20 In determining the directions, if any, to be imposed on the Organisation under section 29 of the PDPA, I took into account the following mitigating factors: (a) the Organisation took prompt remedial actions following the Incident as set out in [6] and [7]; (b) the Organisation was fully cooperative during the investigations; (c) the Organisation took immediate steps to notify the affected individuals of the Incident; and (d) there was unauthorised disclosure to one individual and no modification or exfiltration of the Disclosed Personal Data. 21 Having considered all the relevant factors of this case, I hereby direct the Organisation to pay a financial penalty of $6,000 within 30 days from the date of the directions, 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. I have not set out any further directions for the Organisation given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 11 ",Financial Penalty,29d3c0d5771aa5ddfea72dcff51a0ef0c5dde45a,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,118,118,1,952,"Directions, including a financial penalty of $10,000, were imposed on SAFRA for failing to put in place reasonable security arrangements to protect the personal data of the members of its Shooting Club. SAFRA was also directed to review its internal processes to put in place process safeguards and written internal standard operating procedures to protect the personal data of its members.","[""Protection"", ""Directions"", ""Financial Penalty""]",2020-01-09,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---SAFRA---161219.pdf,Protection,Breach of the Protection Obligation by SAFRA National Service Association,https://www.pdpc.gov.sg/all-commissions-decisions/2020/01/breach-of-the-protection-obligation-by-safra-national-service-association,2020-01-09,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 45 Case No DP-1809-B2711 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And SAFRA National Service Association … Organisation DECISION 1 SAFRA National Service Association [2019] SGPDPC 45 Yeong Zee Kin, Deputy Commissioner — Case No DP-1809-B2711 16 December 2019 Facts of the Case 1 On 13 September 2018, the Personal Data Protection Commission (the “Commission”) received a voluntary breach notification from SAFRA National Service Association (the “Organisation”). An employee of the Organisation (the “Employee”) who had sent out two separate batches of e-mails attaching an Excel spreadsheet (the “Spreadsheet”) containing the personal data of certain members of the Organisation’s shooting club (the “SSC”) to other members (the “Incident”). 2 According to the Employee, his job scope included sending mass e-mails to SSC members. He has been sending such e-mails since September 2016 at least once a month. According to him, he was not aware of any SOPs for sending of such mass emails. The Employee claims that his supervisor had instructed him verbally on the process. First, prepare proposed e-mail, and attach a spreadsheet containing intended recipients’ e-mail addresses extracted from another internal system. Next, send this draft email from his individual work email account to the official SSC e-mail account. Thereafter, copy the intended recipients’ emails addresses into the draft email, and delete the attached spreadsheet, before sending out the mass email. This is the process that the Employee has been following whenever he sends mass e-mails to SSC members, as was the case during the Incident. 3 The Organisation claims that it was not aware of this process for mass e-mails. However, its staff were briefed on the practice of using the bcc function when sending mass emails and were verbally instructed to “check and ensure that no unnecessary information or document (including those which contain personal data) has been enclosed before sending an email to members”. 4 The Incident occurred on 9 September 2018. The Employee followed this procedure to publicise an upcoming event. After copying the e-mail addresses from the Spreadsheet and pasting it in the bcc field of the e-mail, the Employee tried to delete the Spreadsheet. He was 2 prompted by the webmail that “the attachment could not be removed and to try again”. This was the first time he encountered such an error message. The Employee claims that upon trying to delete the Spreadsheet again, “the Spreadsheet disappeared from the email draft” and he proceeded to send the first batch of mass e-mails. The same thing happened for the second batch of mass e-mails sent by the Employee. According to the Employee, he was notified by an SSC member right after sending the second batch of mass e-mails that the Spreadsheet had been attached to the mass e-mails. Upon checking the “Sent Items” folder on the SSC e-mail account, he realised that the Spreadsheet was attached in the sent e-mails. 5 The Incident resulted in the Spreadsheet containing the personal data of 780 SSC members being sent to 491 SSC members. The types of personal data in the Spreadsheet (the “Personal Data”) included the following: 6 (a) Name; (b) NRIC number; (c) Date of birth; (d) Address; (e) Telephone number; and (f) E-mail address. Upon being notified of the Incident, the Organisation took the following remedial actions: (a) Completed the masking of members’ NRIC number in its internal systems and reports, which it was in the process of undertaking; (b) Circulated the Commission’s guidelines on Personal Data Protection Act 2012 (the “PDPA”) with reminders to be mindful when handling personal data; (c) Notified all affected SSC members about the Incident via e-mail and SMS, and provided an e-mail address and phone number for members to contact for any queries on the Incident; 3 (d) Put up an announcement on the Organisation’s website regarding the Incident; (e) Set up an incident response team and incident management hotline and prepared an FAQ for its frontline staff; and (f) Followed up with phone calls to the SSC members who received the Spreadsheet to delete the attachment. Findings and Basis for Determination 7 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 (“Protection Obligation”). 8 As a preliminary point, the Organisation alleges that it had replicated the steps taken by the Employee to confirm whether or not the Employee’s version of events was accurate. The Organisation claimed that, in replicating these steps, it had similarly encountered the issue as set out in paragraph 4 above. When the Commission requested for evidence of the tests conducted, the Organisation provided some screenshots of emails with attachments, and stated that the test results were not saved, although “[the investigation team] had witnessed [the test] but no screen shot or video recording was made”. However, these screenshots were inconclusive in demonstrating that the Organisation managed to replicate the issues. As part of its investigations, the Commission contacted the Organisation’s webmail software service provider who informed that it had not encountered such an issue nor had it encountered or received any enquiry on such an issue from users of its webmail software at the material time. On a balance of probabilities, based on a review of the evidence before me, I am unconvinced that there was a software glitch. It is more likely that the Employee had simply failed to delete the attached Spreadsheet prior to sending the emails out. 9 The key issue in this case revolves around the practice adopted by the Organisation for sending mass e-mails. The Organisation’s method of drafting the mass e-mail using the individual work e-mail address of the relevant employee and then sending it to the official SSC e-mail address with the Spreadsheet attached gave rise to the risk of accidental disclosure of the Personal Data in the Spreadsheet. Manual processes such as this give rise to risks of human 4 error. Having in mind that this is a task that the Employee had to perform at least once a month, and the fact that the Organisation had already digitized its membership records, the task could have been partially automated. There are readily available technical solutions like mail-merge functions or the creation of frequently used mailing lists. The Commission’s Guide to Preventing Accidental Disclosure When Processing and Sending Personal Data (published 20 January 2017) states (at [2.1]) that organisations may implement automated processing of documents or communications containing personal data (e.g. merging content or populating fields from various sources) to ensure destination information is correct. Organisations are also reminded to ensure the accuracy and reliability of the automated processing implemented by checking these systems and processes regularly. 10 Further, the Guide on Printing Processes for Organisations (published 3 May 2018) also provides guidance (at page 11) on how organisations may use Mail Merge when emailing to ensure the accuracy of the list of intended recipients and the corresponding merged fields in the email. 11 Additionally, the Organisation was unaware of this manual process that its Employee had been using since September 2016 (and potentially earlier, by other employees or by his supervisor) to send out mass e-mails. As stated in [3], the Organisation claimed that it had given certain verbal instructions to its staff on data protection handling practices pertaining to e-mail correspondence. In general, verbal instructions are insufficient as employees would be unable to refer to them in the course of their duties and may very well be unable to recall such instructions after some time. For a regular and perhaps even frequent task like the present monthly mass e-mail to members to publicise upcoming events, the Organisation should have a properly documented process and consider the use of process automation tools. 12 In light of the foregoing, I am satisfied that the Organisation had contravened section 24 of the PDPA. 13 The Organisation informed the Commission after the preliminary Decision in this matter was issued to the Organisation that the following measures have since been put in place: (a) Mass emails will no longer be sent using the Organisation’s generic email account and will only be sent out by a designated Executive or authorised personnel approved by the Club Manager using his or her individual work email account; 5 (b) The downloading of the list of members from the Organisation’s system will be carried out by the Executive personally; (c) The categories of personal data in the list of members that may be downloaded from the system has been reduced; (d) The frequency of mass emails to update members on programmes and events will be reduced from monthly to bi-monthly or quarterly; (e) All new staff will undergo an orientation programme on the operations of the shooting club within the 1st week of joining and only selected staff will be allowed to handle email updates and will also be trained within the 1st week of joining the club; (f) More stringent access controls to the Organisation’s databases have been implemented; (g) The 1st 5 characters of members’ NRIC numbers are masked in the Organisation’s internal systems; (h) The IT Policy has been updated to include guidelines for the protection, encryption and sharing of the Organisation’s database. As part of this update, databases are to be encrypted or password protected before they are shared and may only be shared with the written consent of a Head of Department or custodian; and (i) 14 Training has been provided to staff on data handling. The Organisation also informed that it was in the midst of enhancing its existing system to automate the sending of mass emails. The Organisation asked for an extension of the timeframe for implementation of the second direction set out in the next section. The Deputy Commission has decided to accede to the Organisation’s request and has lengthened the timeframe to the period set out below. The Deputy Commissioner’s Directions 15 In determining the directions to be imposed on the Organisation under section 29 of the PDPA, I took into account the following mitigating factors: (a) the Organisation voluntarily notified the Commission of the Incident; 6 (b) the Organisation was cooperative and had provided prompt responses to the Commission’s requests for information; (c) the Organisation implemented remedial actions swiftly to address the Incident; and (d) there was no evidence of any further unauthorised use of the Personal Data in the Spreadsheet. 16 Having carefully considered all the relevant factors of this case, I hereby direct the Organisation: (a) to pay a financial penalty of $10,000 within 30 days of the date of this direction, 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; and (b) to conduct a review of its email system and processes to put in place process safeguards and written internal standard operating procedures to protect the personal data of its members within 120 days of the date of this direction. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 7 ","Directions, Financial Penalty",010708766ce21b512c280cfe9da288cff633f350,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,121,121,1,952,"A financial penalty of $8,000 was imposed on Honestbee for failing to put in place reasonable security arrangements to protect the personal data of individuals. The data of about 8,000 individuals was stored in the cloud without access restrictions.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade""]",2019-12-05,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---Honestbee.pdf,Protection,Breach of the Protection Obligation by Honestbee,https://www.pdpc.gov.sg/all-commissions-decisions/2019/12/breach-of-the-protection-obligation-by-honestbee,2019-12-05,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1905-B3827 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Honestbee Pte Ltd SUMMARY OF THE DECISION 1. Honestbee Pte Ltd (the “Organisation”) is an online food and grocery delivery service. Third party merchants, which either engaged or were planning to engage the Organisation for delivery services, provided it with personal data of their customers in order to test its logistics service delivery platform. The Organisation stored this personal data in its Amazon Web Services (“AWS”) file repository. The personal data (the “Personal Data”) included names, email addresses, residential addresses and mobile numbers. 2. The Personal Data Protection Commission (the “Commission”) was informed on 2 May 2019 that the Personal Data was accessible to the public. The number of individuals whose personal data was accessible was about 8,000. The Organisation admitted that it had mistakenly placed the Personal Data in a ‘bucket’ (which is similar to a file folder) without access restrictions. This allowed anyone with knowledge of AWS’s command line to gain access to the Personal Data. 3. The Commission found that the Organisation omitted to put in place the most rudimentary security measures necessary to protect the Personal Data. For example, the Organisation could have implemented a requirement to conduct checks to confirm that any personal data used in testing was stored in a ‘bucket’ with the appropriate access restrictions. In the circumstances, the Organisation had not implemented reasonable security arrangements to protect the Personal Data and is therefore in breach of section 24 of the Personal Data Protection Act 2012. 4. The Organisation has since blocked public access to the Personal Data by modifying the relevant access settings and circulated a report to its engineering team to ensure that similar mistakes would not be repeated in code reviews. The Organisation is also in discussions with cybersecurity companies to perform regular security audits on its systems. 5. The Organisation is directed to pay a financial penalty of $8,000 within 30 days from the date of this direction, 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 the financial penalty until the financial penalty is paid in full. In view of the remedial measures taken by the Organisation, the Commission has not imposed any other directions. 6. The Organisation’s prompt co-operation in the course of the Commission’s investigation, its prompt actions taken to remediate the breach and the limited unauthorized disclosure of the Personal Data were mitigating factors taken into consideration in determining the quantum of the financial penalty. ",Financial Penalty,e5c308da0f082ff90e6a4873039b1d55f4c3f94f,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,123,123,1,952,"Directions, including a financial penalty of $8,000, were imposed on Chizzle for failing to put in place reasonable security arrangements to protect the personal data of users of its mobile application in Re Chizzle Pte Ltd [2019] SGPDPC 44. The organisation was also directed to develop an IT security policy, review and revise its developmental processes in order to adopt a data protection by design approach for future enhancements to its mobile application. An application for reconsideration was filed against the decision in Re Chizzle Pte Ltd [2019] SGPDPC 44. Upon review and careful consideration of the application, the Commissioner has decided to affirm the finding of breach of section 24 of the PDPA as set out in the decision and the direction, in the Reconsideration Decision.","[""Protection"", ""Directions"", ""Financial Penalty""]",2019-12-05,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Chizzle-Pte-Ltd.pdf,Protection,Breach of the Protection Obligation by Chizzle,https://www.pdpc.gov.sg/all-commissions-decisions/2019/12/breach-of-the-protection-obligation-by-chizzle,2019-12-05,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 44 Case No. DP-1807-B2495 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Chizzle Pte. Ltd. … Organisation DECISION Chizzle Pte. Ltd. [2019] SGPDPC 44 Tan Kiat How, Commissioner — Case No. DP-1807-B2495 26 November 2019 Introduction 1 Chizzle Pte. Ltd. (the “Organisation”) provides a mobile application (the “Mobile App”) designed to connect learners and teachers in Singapore, Australia and India. On 31 July 2018, the Organisation notified the Personal Data Protection Commission (the “Commission”) of a cyberattack (the “Incident”) which had compromised the personal data of about 2,213 users of the Mobile App, including some users in Singapore (the “Affected Individuals”). Material Facts 2 On 30 July 2018, the Organisation noticed that the Mobile App had stopped responding. It was found that an unauthorised party had deleted its database containing the personal data of the Affected Individuals (the “Chizzle Database”) and left a ransom demand in text. The personal data in question included the names, dates of birth, genders, email addresses and some mobile numbers and residential addresses of the Affected Individuals (the “Compromised 2 Chizzle Pte Ltd [2019] SGPDPC 44 Personal Data”). Before this, on 9 July 2018, the Organisation had changed the Chizzle Database from Amazon’s Relational Database Service to the MySQL relational database. 3 Since 2016, the Organisation had a “L.A.M.P.” stack (i.e. Linux operating system, Apache HTTP server, MySQL server and PHP) (collectively with the Mobile App, the “System”) as part of its IT infrastructure. “phpMyAdmin”, a MySQL database administration tool, was installed with the L.AM.P stack. The tool was configured to allow remote access to it from the Internet. The Organisation believed that the unauthorised party gained entry into the Chizzle Database through the phpMyAdmin tool by a brute force attack. However, it did not have the logs to prove that a brute force attack had taken place. Regardless, the unauthorised party gained entry to the Chizzle Database through the phpMyAdmin tool. This gave the unauthorised party full control, including reading, writing and deleting data. Remedial actions by the Organisation 4 Following the Incident, the Organisation has taken measures to prevent unauthorised access to the Chizzle Database in the future, including the following: (a) IP address access via phpMyAdmin (i.e. use of IP address to find and reach the Chizzle Database) was turned off and the phpMyAdmin tool was uninstalled; (b) The IP address of the Organisation’s servers, including the Chizzle Database server, were changed; and 3 Chizzle Pte Ltd (c) [2019] SGPDPC 44 The Mobile App and Chizzle Database were moved to new hardware in case any residual malware or Trojans remained in the old hardware. Findings and Basis for Determination Whether the Organisation had breached its obligation to protect personal data under section 24 of the Personal Data Protection Act 2012 (“PDPA”) 5 Section 24 of the PDPA requires organisations 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. 6 The Organisation had failed to conduct any security review of its System although past decisions by the Commission had made clear the need for such reviews (see e.g. WTS Automotive Services Pte Ltd. [2018] SGPDPC 26, Bud Cosmetics [2019] SGPDPC 1 and Watami Food Service Singapore Pte Ltd [2018] SGPDPC 12). 7 The Organisation claimed that it was not even aware that the phpMyAdmin tool was part of its System. It also claimed it had no need of the tool. A reasonable security review would have included a review of all web-connected features of the System. Through such a review, the Organisation would have found the phpMyAdmin tool and could have decided whether to remove or keep it. If the Organisation had decided to retain the tool, the review would have given opportunity for the Organisation to review its security against web-based threats. 4 Chizzle Pte Ltd 8 [2019] SGPDPC 44 However, as found above, the Organisation failed to conduct a security review. It therefore missed the opportunity to determine its need for the phpMyAdmin tool and to address the security requirements of the tool, if retained. A security review would have been the arrangement through which the Organisation could reasonably have prevented the unauthorised entry into the Chizzle Database through the tool. 9 On the facts above, the Commissioner found that the Organisation had not made reasonable security arrangements to protect the Compromised Personal Data and was accordingly in breach of section 24 of the PDPA. The Organisation’s Representations 10 After the preliminary decision was issued, the Organisation submitted representations requesting for a reduction to the quantum of financial penalty. In support of its assertion that the proposed penalty was “more than likely to push [it] to a brink of closing the business”, the Organisation submitted copies of its financial statements and bank account statements. The Organisation did not disagree with, or make any representations relating to, the Commissioner’s findings that it had breached section 24 of the PDPA. 11 In general, financial penalties imposed under the PDPA reflect the seriousness of the breach and do not take into account the financial position of the organisation in question. However, a financial penalty is not meant to impose a crushing burden on the organisation and cause undue hardship: Re Sharon Assya Qadriyah Tang [2018] SGPDPC 1 at [34]. In the present case, the financial standing that was gleaned from the submitted financial statements 5 Chizzle Pte Ltd [2019] SGPDPC 44 and bank account statements was dire. In order to avoid imposing a crushing burden on the Organisation, the Commissioner has decided to reduce the financial penalty. For this reason, the financial penalty imposed in this case should not be taken as establishing a precedent for future cases. 12 In order to ensure that the Mobile App is robust and secure, the Organisation should adopt a data protection by design approach. While the optimal approach is to do so from the commencement of every developmental project, it is nevertheless still possible to do so during the maintenance phase, whenever there are enhancements: Data Protection by Design Guide, at p 35. The Organisation is directed to review its developmental processes in order to adopt a data protection by design approach for future enhancements to the Mobile App. Making changes to its practices will help the Organisation scale its Mobile App for future growth, and will pay longer term dividends than a hefty financial penalty. The Commissioner’s Directions 13 In view of the above findings, the Commissioner decided to direct the Organisation to pay a financial penalty of $8,000 within 30 days from the date of this direction, 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. 14 In addition, the Commissioner decided to issue the following directions to the Organisation to ensure its compliance with the PDPA: 6 Chizzle Pte Ltd (a) [2019] SGPDPC 44 Engage duly qualified personnel to conduct a security audit of its mobile application and accompanying IT system; (b) Furnish a schedule stating the scope of risks to be assessed and the time within which a full report of the audit can be provided to the Commission within 30 days of this direction; (c) Rectify security gaps identified in the security audit; (d) Develop an IT security policy to guide its employees on the security of personal data on its mobile applications and accompanying IT systems within 60 days from the date of completion of the above-mentioned security audit; (e) Within 120 days of this decision, review and revise its developmental processes in order to adopt a data protection by design approach for future enhancements to its mobile application; and (f) Inform the Commission in writing of the completion of each of the above directions within 1 week of completion. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSSIONER FOR PERSONAL DATA PROTECTION 7 ","Directions, Financial Penalty",d2f01a3d69daa429f27a8ad071d760e7006d4489,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,125,125,1,952,"A financial penalty of $6,000 was imposed on i-vic International (i-vic) for failing to put in place reasonable security arrangements to protect the personal data of individuals which it had processed on another organisation’s behalf. i-vic as the data intermediary did not put in place diligent and properly scoped testing of software which led to the disclosure of personal data of individuals via email.","[""Protection"", ""Financial Penalty"", ""Employment""]",2019-12-05,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---i-vic-International.pdf,Protection,Breach of the Protection Obligation by i-vic International,https://www.pdpc.gov.sg/all-commissions-decisions/2019/12/breach-of-the-protection-obligation-by-i-vic-international,2019-12-05,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 41 Case No. DP-1804-B1991 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And i-vic International Pte. Ltd. … Organisation DECISION i-vic International Pte. Ltd. [2019] SGPDPC 41 Yeong Zee Kin, Deputy Commissioner — Case No. DP-1804-B1991 12 November 2019. Introduction 1 The Employment and Employability Institute Ltd (“e2i”) administers a work trial programme on behalf of a public agency, Workforce Singapore (“WSG”). e2i engaged i-vic International Pte Ltd (the “Organisation”) to process claims and queries from members of the public relating to the work trial programme (the “Engagement”). 2 On 16 April 2018, e2i reported to the Personal Data Protection Commission (the “Commission”) that documents containing personal data of three individuals (the “Affected Individuals”) involved in the work trial programme were inadvertently attached to emails sent out by the Organisation to 9 individuals (the “Incident”). Material Facts 3 As part of the Engagement, the Organisation was required to manage e2i’s mailbox which received emails from members of the public with their claims and queries. It was also required to develop and/or maintain the IT infrastructure and customer relationship management (“CRM”) software (collectively, the “System”) used to operate and manage e2i’s mailbox. As part of this, the Organisation was required to either reply to the emails from members of the public (providing the appropriate responses) or escalate the queries in the emails to the relevant e2i representatives. Where an email query needed to be escalated, an employee of the Organisation would submit an escalation request in the System. The System would then automatically generate two emails for the Organisation’s employee to send (the “Automated Email Generation Process”). The first was a holding reply email to the person who had sent the email query to e2i’s mailbox and the second was an email to escalate the query to the relevant e2i representative. For the second email, the System would automatically retrieve the relevant documents that were stored in the Organisation’s servers and attach them to the email. 4 On the 1st of every month, the Organisation ran a batch process on the System, after normal working hours, to generate reward programme emails for an another client (the “Reward Programme Process”). While this was being done, the Automated Email Generation Process was unable to run any instructions to generate and send emails. During this time, any instructions by the Organisation’s employees to generate emails with respect to the Engagement would be queued and the Automated Email Generation Process would process these instructions as a batch once the Reward Programme Process had been completed. 5 On 1 April 2019, while the Reward Programme Process was being run, one of the Organisation’s employees attempted to generate some new emails using the Automated Email Generation Process. These instructions to generate the relevant emails were queued, to be acted upon only after the Reward Program Process was completed. However, due to an error in the Automated Email Generation Process code for processing emails as a batch, the System attached the wrong documents containing personal data of the Affected Individuals to the emails in the queue and sent these out to 9 different individuals. 6 The documents that were sent to the 9 individuals contained the names, NRIC numbers, signatures, residential addresses, mobile numbers, email addressed, age and race of all three Affected Individuals, the bank account number of two of the Affected Individuals and the highest academic qualifications, work trial company details and work experience details of one of the Affected Individuals (collectively referred to as the “Disclosed Personal Data”). Remedial actions by the Organisation 7 After becoming aware of the Incident, the Organisation took the following remedial action to prevent it from reoccurring: (a) Fixed the error in the code of the Backlog Clearing Process which caused the Incident; and (b) Rewrote the relevant code to enable automated encryption of attachments (so that unauthorised recipients would not be able to view the contents of the attachments) and to ensure that the wrong files would not be attached to emails. Findings and Basis for Determination 8 Section 24 of the PDPA provides that 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 (the “Protection Obligation”). 9 As a preliminary point, it is noted that e2i was acting on behalf of WSG in relation to the collection, use and disclosure of personal data for administration of the work trial programme. As such, pursuant to section 4(1)(c) of the PDPA, e2i was not subject to Part III to VI of the PDPA, including section 24, in relation to such collection, use and disclosure of personal data. 10 The Organisation was a data intermediary of e2i as it processed personal data on behalf of e2i for the purpose of the Engagement. The Organisation was thus required to protect personal data in its possession or under its control in accordance with section 24. 11 In relation to the cause of the Incident, the Organisation asserted that it had tested the code of the Automated Email Generation Process. However, the Organisation also admitted that it had not tested how the code acted when the Automated Email Generation Process processed instructions to generate and send emails which were queued while the Reward Programme Process was running. In this regard, the Organisation explained that they expected such emails to be processed and sent out individually and not queued while the Reward Programme Process was running. Nevertheless, as the Organisation ought to have known that the Automated Email Generation Process was unable to run while the Reward Programme Process was running on the 1st of every month, the Organisation ought to have tested whether this had an effect on the Automated Email Generation Process. Diligent and properly scoped testing would have simulated the circumstances leading to the Incident and would therefore likely have detected that documents containing personal data were being incorrectly attached to the emails in queue. 12 In the circumstances, the Organisation’s failure to put in place diligent and properly scoped testing amounted to a failure to put in place reasonable security arrangements to protect the personal data which was in its possession and/or under its control. I therefore find that the Organisation had contravened section 24 of the PDPA. The Deputy Commissioner’s Directions 13 In view of the above findings, I hereby direct the Organisation to pay a financial penalty of $6,000 within 30 days from the date of this direction, 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. 14 I have decided not to issue any further directions as the Organisation has taken the actions set out at paragraph 7 above to remedy the cause of the Incident. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION ",Financial Penalty,e47bddcc5f36c79ec219edf1cb404ced43a0874d,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,126,126,1,952,"A financial penalty of $60,000 was imposed on Learnaholic for failing to put in place reasonable measures to protect the personal data of students, students’ parents and staff of various schools.","[""Protection"", ""Financial Penalty"", ""Education""]",2019-12-05,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Learnaholic.pdf,Protection,Breach of the Protection Obligation by Learnaholic,https://www.pdpc.gov.sg/all-commissions-decisions/2019/12/breach-of-the-protection-obligation-by-learnaholic,2019-12-05,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 31 Case No DP-1703-B0567 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Learnaholic Pte. Ltd. … Organisation DECISION [This is a redacted version of the Decision which omits certain confidential details] Learnaholic Pte. Ltd. [2019] SGPDPC 31 Tan Kiat How, Commissioner — Case No DP-1703-B0567 26 August 2019. Background 1 The Organisation is an IT vendor that was providing attendance-taking and e-learning systems to schools pursuant to a contract with the Ministry of Education (“MOE”). The central issue to this case, in so far as it is related to the Personal Data Protection Act 2012 (“PDPA”), is whether the Organisation had made reasonable security arrangements to protect the personal data of approximately 47,802 students, students’ parents and staff of various schools that it had in its possession and control at the material time. Material Facts 2 The Organisation was responsible for the maintenance and installation of the attendance-taking system installed in [redacted] (“the School”). The School’s attendance-taking system was designed such that the attendance records would be updated each time a student “taps in” with his or her student pass at any one of the card readers located around the School. This attendancetaking system consisted of an attendance server (the “Attendance Server”) Learnaholic Pte. Ltd. [2019] SGPDPC 31 connected to clusters of attendance controllers linked to card readers. One such cluster was located at the guard post of the School (the “Guard Post Cluster”). 3 In or around March 2016, the School informed the Organisation of an intermittent problem with the Guard Post Cluster: students’ names were not being displayed despite them tapping in at the Guard Post Cluster. In order to investigate into the issues reported by the School, the Organisation decided to troubleshoot the problem remotely as this was more convenient than sending someone down to the School. In order to do so, it installed VNC Server, a remote desktop software, at the Guard Post Cluster. Using VNC Viewer to remotely connect to the VNC Server so that the Organisation would be able to troubleshoot the Guard Post Cluster without having to be physically present at the School (the “Remote Troubleshooting” method). 4 In addition to installing the VNC Server, the Organisation also took the following steps to facilitate its Remote Troubleshooting: (a) Modifying the configuration of the School’s Intranet firewall by opening a specific port (“Port”) to allow external access to the Guard Post Cluster from the internet via the VNC Viewer software. (b) Disabling the password for the VNC Server software installed at the Guard Post Cluster (i.e. no password was required to gain access to the Guard Post Cluster via the VNC Server software). While the Organisation claimed to have disabled the input feature at the client side when using the VNC Viewer program, this would have only affected the Organisation’s ability to make changes and would not have affected a hacker’s ability to do the same. If the Organisation had disabled the input feature at the server side, it would have been very unlikely that a hacker could have exploited the vulnerability in the Organisation’s system as 2 Learnaholic Pte. Ltd. [2019] SGPDPC 31 explained immediately below. The only other potential manner in which the hacker could have exploited the said vulnerability would have been where the Organisation opened all the ports to the system instead of just the VNC specific port. 5 The Organisation’s actions would come to have significant consequences. Prior to the opening of the Port, the Guard Post Cluster was only accessible internally from the School network. The opening of the Port was meant to be temporary for the purposes of the Remote Troubleshooting, but the Organisation’s Representative (the “Representative”) conducting the troubleshooting forgot to close the Port and restore the School’s original firewall configuration after the troubleshooting was completed. The disabling of the password for the VNC Server software meant that access to the Guard Post Cluster could be easily gained simply with knowledge of the Port number and the IP address of the Attendance Server. This combination of actions led to the creation of a vulnerability in the School’s Guard Post Cluster (the “Vulnerability”) – a vulnerability that would later be exploited by a hacker. 6 The Organisation took the view that the hacker exploited the Vulnerability to retrieve a configuration file stored on the Guard Post Cluster. The Commissioner believes that this is a logical explanation of how the hack occurred. This configuration file was supposed to be stored only on the School’s Attendance Server, but had inadvertently been copied to the Guard Post Cluster. This had occurred as the Organisation had stored the configuration file in a folder on the Attendance Server that also held firmware update files for the Guard Post Cluster (the “Update Folder”); the Update Folder would be periodically synced with the relevant components of the Guard Post Cluster in the School in order to “push down” firmware updates from the Attendance Server to these components at the Guard Post Cluster. A copy of the 3 Learnaholic Pte. Ltd. [2019] SGPDPC 31 configuration file was therefore copied to the Guard Post Cluster during one of the periodic firmware updates. 7 The purpose of the configuration file was to enable the School’s Attendance Server (using the Representative’s work email as a relay) to send attendance reports to the School’s staff. To facilitate this function, the configuration file contained the login credentials of the Representative’s work email. The hacker was thus able to obtain the login credentials from the copy of the configuration file retrieved from the Guard Post Cluster, and thereby gain access to the Representative’s work email account. The Representative’s work email account contained the unencrypted personal data of approximately 47,802 staff, students, and students’ parents of various schools (the “Personal Data”). The Personal Data exfiltrated by the hacker included information such as: (a) Names; (b) NRIC numbers; (c) Contact numbers; (d) Email addresses; (e) Addresses; and (f) Medical information, which relate to approximately 372 students. 8 The Personal Data was in the Representative’s email as the Organisation had assisted the schools to upload the data onto the respective schools’ attendance taking and/or e-learning systems. The Representative had received the Personal Data via email for the purposes of uploading, but had not deleted these emails after performing the upload as it was thought that it might be useful to retain the Personal Data for future reference. 4 Learnaholic Pte. Ltd. 9 [2019] SGPDPC 31 The breach of the School’s attendance taking system and the Representative’s work email, together with the resulting exfiltration of the Personal Data, were only discovered in February 2017 by the Singapore Police Force (“SPF”) in the course of investigating a separate hacking incident 1. The Personal Data Protection Commission (“PDPC”) was informed of the matter and thereafter commenced its own investigations. The Commissioner’s Findings and Basis for Determination The Relevant PDPA Provisions 10 In respect of this matter, the relevant provision is Section 24 of the PDPA. Section 24 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”). Preliminary Issues 11 It is not disputed that the Personal Data is “personal data” as defined in section 2(1) of the PDPA. There is no question or dispute that the Organisation falls within PDPA’s definition of an “organisation”. There is also no dispute that Personal Data was, at all material times, in the Organisation’s possession and that the Organisation was responsible for the Personal Data. 12 In the course of investigations, it was determined that the Organisation was at all material times an independent third party service provider to, and 1 This hacking incident, and the Singapore Police Force’s investigations, are not the subject of these Grounds of Decision. 5 Learnaholic Pte. Ltd. [2019] SGPDPC 31 therefore was not acting on behalf of, MOE or any of the various schools it provided IT services to. The Organisation also did not raise the applicability of section 4(1)(c) of the PDPA at any time. In the circumstances, section 4(1)(c) of the PDPA does not apply. 13 The key issue is therefore whether the Organisation had protected the Personal Data in its possession by making reasonable security arrangements to prevent unauthorised access and similar risks. The Organisation failed to make reasonable security arrangements 14 After a review of all the evidence obtained by PDPC during its investigation and for the reasons set out below, the Commissioner is of the view that the Organisation had failed to make reasonable security arrangements to protect the personal data in its possession, and has thereby breached the Protection Obligation under section 24 of the PDPA. This data breach incident occurred due to a series of lapses on the part of the Organisation, all of which could have been reasonably averted. 15 First, the Organisation opened a Port and reconfigured the School’s Intranet Firewall to allow remote access to the School’s Guard Post Cluster, while simultaneously disabling the password for remote access to the Guard Post Cluster, thereby creating the Vulnerability. In addition, the Representative conducting the Remote Troubleshooting forgot to close the Port, leaving the Vulnerability exposed from March 2016 until end-April 2016, when the Vulnerability was discovered because the Organisation was subsequently requested to troubleshoot the Guard Post Cluster again in or around April 2016. 6 Learnaholic Pte. Ltd. 16 [2019] SGPDPC 31 It bears noting that the Organisation did not inform the School that it had made changes to the configuration of the School’s Intranet firewall during the Remote Troubleshooting. The changes made to the configuration of the Intranet firewall in this matter was a clear security lapse borne from convenience; in attempting to get around the need to be physically present in the School, the Organisation undermined the security arrangements in place and allowed the hacker to obtain the configuration file. This was exacerbated by the Organisation’s failure to inform the School of these configuration changes. 17 Second, the configuration file (containing the login credentials of the Representative’s work email account) was supposed to be stored only in the School’s Attendance Server. As described at [6] above, this configuration file had been inadvertently copied to the Guard Post Cluster, where the Vulnerability existed as a point of entry for the hacker, which allowed the hacker to consequently gain access to the configuration file. 18 The hacker was thus able to obtain the login credentials of the work email account where the unencrypted Personal Data was stored. The Organisation has represented to PDPC that the email accounts and passwords contained in the configuration file were listed in a jumbled up or random manner, such that it would not have been apparent which email account corresponded with which password. Such an approach falls far below the level of sophistication which one would expect login credentials to be secured with. A relatively low degree brute-force attack (i.e. trial and error) would be all that was required to match an email account with its corresponding password. The Organisation failed to appreciate the consequences of placing the configuration file with the login credentials – a file that effectively contained the proverbial keys to the kingdom – in the Update Folder of the Attendance Server. Allowing a file that contained sensitive information such as login credentials to be copied 7 Learnaholic Pte. Ltd. [2019] SGPDPC 31 to each of the clusters represents a clear lapse in the Organisation’s security arrangements. The less-than secure manner in which the login credentials were stored and dealt with within their own system was an issue that the Organisation should and could have been reasonably alive to. 19 Third, the Personal Data was sent to and stored in the Representative’s work email account in an unencrypted form. The PDPC encourages the encryption of personal data that is sensitive or when sent in bulk. As this case demonstrated, personal data sent in bulk were stored in the clear in the Representative’s email account effectively giving the hacker free rein to access the information once access to the email account was obtained. The originator of the Personal Data shared some of the blame in failing to encrypt the file. But the risks would not have materialised had the Representative deleted the email containing the Personal Data once his task was completed (e.g. uploading of data). This he failed to do. He kept the email containing the Personal Data, just in case he needed it in the future. If there was a valid legal or business purpose for retaining a copy of the Personal Data for an extended period of time, it should not have been retained in the Representative’s work email account in an unencrypted format. The Organisation could have downloaded a copy of such data into a computer and encrypted the same if it needed to retain it (and thereafter deleting the originating email and attachment). This is a basic security arrangement that could have been reasonably expected of the Organisation. 20 The Organisation’s inadequate security measures were therefore directly responsible for the breach and exfiltration of the Personal Data. Any of the individual lapses on their own would have been a cause for concern; combined together, the lapses created the perfect opportunity for any opportunistic hacker armed with basic hacking tools to strike. 8 Learnaholic Pte. Ltd. 21 [2019] SGPDPC 31 Based on the foregoing, the Commissioner finds that the Organisation has breached the Protection Obligation under section 24 of the PDPA. The Commissioner’s Directions 22 Having found the Organisation to be in breach of section 24 of the PDPA, the Commissioner is empowered under Section 29 of the PDPA to give the Organisation such directions as he deems fit to ensure compliance with the PDPA. 23 In determining the appropriate directions to be imposed on the Organisation, the Commissioner has taken into account the following aggravating factors: (a) In the course of its work with the schools and MOE, the Organisation was handling large volumes of personal data relating to minors, including sensitive personal data such as their medical information, family structure and NRIC numbers. The unauthorised disclosure of such data could potentially have caused significant harm. (b) The Vulnerability was left unattended for a period of more than a month during which other hackers could have easily obtained access to the Personal Data2. (c) 24 Actual data exfiltration had taken place. To its credit, the Organisation acted fairly swiftly to address the causes of the breach once they were made aware of the same, a response which carries 2 During the investigations, there had been some uncertainty as to the duration for which the Vulnerability was left uncorrected. This is further discussed at [27] below. 9 Learnaholic Pte. Ltd. [2019] SGPDPC 31 some mitigating value. The following remedial actions taken by the Organisation have therefore been taken into account: (a) Changed the passwords for all the Organisation’s work email accounts; (b) Activated Two Factor Authentication for all of the Organisation’s work email accounts after being informed of the data breach by SPF; (c) Deleted all emails with the Personal Data from the Organisation Representative’s work email account; (d) Deleted the configuration file from the Guard Post Cluster; (e) Implemented a new practice of having the Organisation’s representatives delete emails from their work email account once action has been taken in respect of the same; and (f) Put in place a script to ensure that the Update Folder of the Attendance Server only contains essential php files such as system codes, and that any non-essential files are automatically deleted prior to the syncing of the Update Folder with the other attendance clusters in the School. The Organisation’s Representations 25 The Organisation made representations to the PDPC, in particular to reduce the quantum of the financial penalty imposed, after the preliminary decision was issued to the Organisation. The Organisation’s representations are addressed as follows. 10 Learnaholic Pte. Ltd. 26 [2019] SGPDPC 31 First, the Organisation represented that the total number of individuals affected was 35,000 (and not 60,000 according to initial calculations), and that the total number of students whose medical data was accessed and exfiltrated was 372. PDPC has reviewed the evidence and determined that the number of unique individuals affected by the incident was 47,802. The Commissioner accepts that 372 individuals’ medical data was accessed. The financial penalty has, therefore, been adjusted to take into account the number of individuals whose medical data was accessed and exfiltrated and the reduction in the number of affected individuals. 27 Second, the Organisation represented that the Vulnerability had been discovered and fixed sometime at the end of April 2016 when the Organisation was requested to troubleshoot the Guard Post Cluster again (as described in [15]). The Organisation had previously indicated that they were unaware of the duration during which the Vulnerability was left uncorrected. In the circumstances, the financial penalty quantum was initially based on the Vulnerability having only been corrected on or about February 2017 when the Organisation was notified of the incident by SPF in the course of investigating a separate hacking incident. The Commissioner has given the Organisation the benefit of the doubt as to the period of time the Vulnerability existed and has adjusted the quantum of the financial penalty accordingly. 28 Third, the Organisation also represented that the medical information subject to unauthorised access relates to types of medical conditions3 which it 3 For instance, colour vision; whether the student was on regular medication; respiratory disorders; allergies; asthma; epilepsy; heart condition; ear disorder; hearing loss; periodic loss of consciousness; and modified exercise. 11 Learnaholic Pte. Ltd. [2019] SGPDPC 31 asserts are non-sensitive in nature. However, the medical data that was accessed was those of minors, ie less than 21 years of age. Medical data and personal data of minors is treated as being sensitive in nature4. For such sensitive personal data, organisations are required to take extra precautions and ensure higher standards of protection under the PDPA. 29 Fourth, the Organisation represented that it had requested the schools to upload personal data on their own, to limit any personal data sent to the Organisation to what is absolutely necessary, and if the schools were to send data via email, to password protect the data file attachments. However, the preferred practice of many of the schools was to send unencrypted personal data to the Organisation for it to be uploaded. To give the Organisation the benefit of doubt, even if it is accepted that the Organisation had informed the schools to password protect data file attachments sent by email, the evidence shows that this policy was not observed in practice. Merely having a policy is not a sufficient security arrangement particularly when this policy is observed only in its breach. 30 As a corollary to the above point, the Organisation also represented that “as a vendor and a small enterprise serving the educational institutions, [the Organisation was] understandably subservient to the decisions of their customers”. If the Organisation chooses to accede and upload the personal data that was sent to its email account, then it ought to have reviewed its policies and implemented different security arrangements to protect such personal data, e.g. by deleting file attachments containing personal data promptly. 4 See Advisory Guidelines on the Personal Data Protection Act for Selected Topics at [8.12] and Singapore Taekwondo Federation [2018] SGPDPC 17 at [22] to [27]. 12 Learnaholic Pte. Ltd. 31 [2019] SGPDPC 31 Fifth, the Organisation represented that its practices were to delete emails containing personal data when no longer required (e.g. after uploading onto the appropriate databases), and that the reason that the attacker was able to gain access to so many email attachments containing Personal Data is because he had access to the email account for 3 months. While this may be true, the Organisation previously admitted that emails containing Personal Data would still be required to address enquiries from schools, and thus, were retained in the Representative’s email account for months (and not immediately deleted after uploading). As stated in [19], the fact that the Personal Data was retained in such a manner facilitated the hacker’s access to the Personal Data; if the Organisation needed to keep the Personal Data for operational purposes, it should have properly secured it. 32 Sixth, the Organisation represented that the following should be taken into account as mitigating factors: (a) it was a victim of a cyberattack that had maliciously exploited the lapses on the part of the Organisation; (b) the Organisation tried their even best to secure personal data, but its lone efforts were insufficient without reciprocation from the schools; and (c) based on SPF’s investigations there was no evidence of further exploitation, use or disclosure of the Personal Data by the attacker. 33 With respect to [32(a)], it should be reiterated that being a cyberattack victim is not in itself a mitigating factor, especially in this case where the lapses of the Organisation, including the existence of the Vulnerability, were such that 13 Learnaholic Pte. Ltd. [2019] SGPDPC 31 the attacker would not require sophisticated means to obtain unauthorised access to the Personal Data. 34 Paragraph [32(b)] has been addressed above5. With respect to [32(c)], while there was actual exfiltration of the Personal Data in this case6, there was no evidence of further exploitation, use or disclosure of the Personal Data by the attacker. This has been taken into account in the revised financial penalty. 35 Finally, the Organisation also sought to compare the penalty imposed against it with that of previous cases7. However, the cases cited dealt with identification data while this case involved medical data of minors. The Commissioner is satisfied that the financial penalty imposed in this case is justified, in particular given the aggravating factors set out above at [23]. 36 Having considered all the relevant factors of the case, the Commissioner hereby directs the Organisation to pay a financial penalty of S$60,000.00 within 30 days from the date of the Commissioner’s direction, 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 the financial penalty until the financial penalty is paid in full. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 5 See [29] and [30]. 6 This has been taken into account as an aggravating factor, see [23(c)]. 7 Specifically, Re K Box Entertainment Group Pte Ltd [2016] SGPDPC 1, Re JP Pepperdine Group Pte Ltd [2017] SGPDPC 2, and Re Orchard Turn Developments Pte Ltd [2017] SGPDPC 12. 14 ",Financial Penalty,4688b3584b68394e1105d7f6245cbffdd9d23107,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,127,127,1,952,"A warning was issued to CampVision for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of individuals. As a result, the personal data of 106 individuals were compromised through a data breach from an online survey platform. Click here to learn more.","[""Protection"", ""Warning"", ""Education""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---CampVision.pdf,Protection,Breach of the Protection Obligation by CampVision,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-campvision,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1808-B2508 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And CampVision Ltd. SUMMARY OF THE DECISION 1. CampVision Ltd (the “Organisation”) engaged SHINE Children and Youth Services (“SHINE”) to collect evaluation feedback from youths participating in its programmes. For this purpose, SHINE collected information from the youths on the Organisation’s behalf, including their names, NRIC numbers, email addresses and schools (the “Personal Data”). SHINE did this using a platform provided by Typeform S.L. (“Typeform”), a company based in Spain, which provides online survey services. In June 2018, Typeform discovered that an unknown third party had gained access to its server and downloaded information provided by many Typeform users, including Personal Data collected by SHINE on behalf of the Organisation (the “Incident”). 2. The Personal Data Protection Commission (the “Commission”) found that Personal Data of 106 individuals collected by SHINE on behalf of the Organisation had been exposed to the risk of unauthorised access and disclosure in the Incident. The Commission’s investigations revealed that there was no written contract between the Organisation and SHINE setting out SHINE’s obligations with respect to the processing and protection of Personal Data, which it collected on the Organisation’s behalf. The Organisation also admitted that it had not conveyed any instructions to SHINE with respect to protection of the Personal Data. In the circumstances, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of section 24 of the Personal Data Protection Act 2012 and decided to give a warning to the Organisation. ",Warning,54437433b71aa75c2e22ffde6236759e61fc677f,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,128,128,1,952,A warning was issued to Tan Tock Seng Hospital for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of its patients. 85 Notification letters to patients to reschedule appointments were sent to wrong addresses.,"[""Protection"", ""Warning"", ""Healthcare""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---TTSH.pdf,Protection,Breach of the Protection Obligation by Tan Tock Seng Hospital,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-tan-tock-seng-hospital,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1902-B3372 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Tan Tock Seng Hospital Pte. Ltd. SUMMARY OF THE DECISION 1. Tan Tock Seng Hospital Pte Ltd (the “Organisation”) voluntarily informed the Personal Data Protection Commission (the “Commission”) on 14 February 2019 that it had discovered on 12 February 2019 that letters sent to 85 patients (the “Affected Individuals”) to reschedule their appointments with the Organisation (the “Letters”) had been sent to the wrong addresses (the “Incident”). These Letters contained the names, NRIC numbers and appointment of the Affected Individuals (the “Personal Data”). Such letters were usually generated automatically. However, on 12 February the Letters were generated manually using the mail merge function in Microsoft Word to extract the Personal Data from a spreadsheet (the “Spreadsheet”) and insert the data in the letters. However, the staff that had been tasked to generate these letters only selected and sorted the address field in the Spreadsheet. As a result, the addresses in the Spreadsheet no longer corresponded to the correct patient information and when the staff ran the mail merge function, the incorrect addresses were inserted in the letters. 2. The Commission found that the Organisation did not conduct any checks on the generation and printing of the letters. A simple random sampling of the letters would have likely averted the Incident or greatly reduced the number of individuals affected. In the circumstances, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of section 24 of the Personal Data Protection Act 2012 and decided to give a warning to the Organisation. No directions are required as the Organisation has implemented corrective measures that addressed the gap in its security arrangements. ",Warning,9ac644185c04bc82207d036718c6b813da4a98e0,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,129,129,1,952,"A financial penalty of $7,000 was imposed on SearchAsia Consulting for failing to put in place reasonable security arrangements to protect jobseekers’ resumes from unauthorised disclosure via its online website.","[""Protection"", ""Financial Penalty""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---SearchAsia-Consulting-Pte-Ltd.pdf,Protection,Breach of the Protection Obligation by SearchAsia Consulting,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-searchasia-consulting,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 40 Case No DP-1809-B2790 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And SearchAsia Consulting Pte. Ltd. … Organisation DECISION SearchAsia Consulting Pte. Ltd. [2019] SGPDPC 40 SearchAsia Consulting Pte. Ltd. [2019] SGPDPC 40 Yeong Zee Kin, Deputy Commissioner — Case No DP-1809-B2790 24 October 2019 Introduction and Material Facts 1. SearchAsia Consulting Pte. Ltd. (the “Organisation”) is a recruitment company established in Singapore which matches job seekers with organisations that are looking to recruit employees for a specific role. On 26 September 2018, the Organisation notified the Personal Data Protection Commission (the “Commission”) of a data breach incident involving the inadvertent disclosure of résumés (the “Incident”) which were uploaded by individual job seekers to the Organisation’s website, www.searchasia.com.sg (the “Website”). Specifically, when a search was conducted on the names or email addresses of affected individuals using an Internet search engine, the search results would include links to the affected individuals’ résumés which had been uploaded to the Website. These résumés were accessible by clicking on the listed links. 2. The Organisation provided job seekers with the ability to upload their résumés on the Website so that the Organisation could assess their suitability for roles which the Organisation has been engaged to fill. The résumés would generally include personal data such as the name, phone numbers, employment history, educational qualifications, achievements and skillset of the job seekers. In one instance, it was discovered that a job seeker included additional information such as nationality, date of birth, marital status and current salary. (The personal data on the affected individuals’ résumés is collectively referred to as the “Personal Data”.) 1 SearchAsia Consulting Pte. Ltd. 3. [2019] SGPDPC 40 The résumés uploaded to the Website were intended to only be accessible by recruitment agents employed by the Organisation. However, in practice résumés which were uploaded to the Website were stored in a folder (“the Folder”) on the Website’s server which was not secured by access controls. As a result, these résumés were indexed by bot crawlers and could be found and accessed by the general public when a search was done via an Internet search engine. 4. The Organisation asserted to the Commission that it had instructed its third party web developer (the “Developer”) to restrict access to the Folder to only 1 of the Organisation’s employees. However, the Organisation did not provide the Commission with any documentary evidence supporting its assertion and the Developer, in its statement to the Commission, denied receiving any specifications on security from the Organisation. Further, the Organisation had not conducted any checks or tests to ensure that access to the Folder was restricted or that the data in the Folder was encrypted. The Organisation admitted that the Developer had not processed any personal data on its behalf. 5. In its representations to the Commission, the Organisation stated that it had asked the Developer whether the résumés uploaded to the Website would be encrypted and the Developer responded saying that “it was safe”. This does not detract from the fact that the Organisation did not set out its instructions to the developer in writing. As stated in Re WTS Automotive Services Pte Ltd [2018] SGPDPC 26 (at [17]), when engaging a service provider, it is important for the organisation to clarify their obligations and thereafter documenting them in writing prior to the provision of services. As set out in Re Smiling Orchid (S) Pte Ltd and others [2016] SGPDPC 19 at [51]: “[t]here must be a clear meeting of minds as to the services that the service provider has agreed to undertake, and this should be properly documented. Data controllers should follow through with the procedures to check that the outsourced provider is indeed delivering the services.” 2 SearchAsia Consulting Pte. Ltd. 6. [2019] SGPDPC 40 Further, the Organisation’s failure to conduct any checks on whether or not access controls were put in place was in itself a breach of its protection obligations: see Re Tutor City [2019] SGPDPC 5 at [16]. 7. The Organisation also asserted that it had relied on its web hosting and technical support services provider (“Web Host”), to ensure that the Website had adequate security features. However, the Organisation had not informed the Web Host that the contents of the Folder were meant to be protected. Hence, while the Web Host had performed some security reviews on the Website, they had not been engaged to advise on or implement measures to protect the personal data stored in the Folder. 8. After being informed of the Incident, the Organisation undertook the following remedial actions: a. The Organisation requested the Web Host to assist in disabling the directory listing function of the Website; b. The Organisation also engaged an external web developer to add a mechanism to the Website to help prevent future indexing by search engine crawlers; c. Public access permissions were removed from sensitive file directories to avoid similar incidents from reoccurring; and d. The Organisation requested Google to remove the existing cached copies of the affected individuals’ résumés from its search engine results. Findings and Basis for Determination 9. Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires organisations to make reasonable security arrangements to protect personal data in its possession or under its control from unauthorised access, disclosure and similar risks. While the Organisation had outsourced the hosting of the Website to the Web Host, it remained in control of the Personal Data. Accordingly, the Organisation was 3 SearchAsia Consulting Pte. Ltd. [2019] SGPDPC 40 responsible for making reasonable security arrangements to protect the Personal Data. 10. The facts of this case, as set out above, clearly show the Organisation’s failure to make reasonable security arrangements to protect the Personal Data The cause of the Incident was that the Folder was set to allow access to documents within the folder to the public without restrictions and the Organisation had not given the appropriate instructions to its contractors, including the Developer and the Web Host, to protect the Personal Data in the Folder. 11. As has been set out in numerous previous decisions issued by the PDPC (see for example Re Tutor City), one of the fundamental actions an organisation is required to undertake towards fulfilling its obligation to make reasonable security arrangements to protect personal data in its possession or under its control is to conduct relevant tests of their IT environment, including websites, to ensure that personal data has been adequately protected. 12. In the circumstances, I find the Organisation in breach of section 24 of the PDPA. Outcome 13. Having found the Organisation in breach of section 24, I have decided to direct the Organisation to pay a financial penalty of $7,000 within 30 days from the date of this direction, 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. 4 SearchAsia Consulting Pte. Ltd. 14. [2019] SGPDPC 40 Given the Organisation’s remediation actions as set out above at paragraph 8, I have decided not to issue any other directions. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 5 ",Financial Penalty,b892605e222afd2a3621ecbe08ca82ac7ebccbac,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,130,130,1,952,"Directions, including a financial penalty of $90,000, were imposed on Ninja Logistics for failing to put in place reasonable security arrangements to protect customers’ data in relation to the Tracking Function Page on the Ninja Logistics website. This resulted in customers’ data on the website to be accessible by the public. Click here to learn more.","[""Protection"", ""Directions"", ""Financial Penalty"", ""Wholesale and Retail Trade""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Ninja-Logistics-Pte-Ltd.pdf,Protection,Breach of the Protection Obligation by Ninja Logistics,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-ninja-logistics,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 39 Case No DP-1804-B2020 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Ninja Logistics Pte Ltd … Organisation DECISION 1 Ninja Logistics Pte Ltd [2019] SGPDPC 39 Tan Kiat How, Commissioner — Case No DP-1804-B2020 14 October 2019 Introduction 1 Ninja Logistics Pte Ltd (the “Organisation”) is a logistics company providing packaging, delivery and tracking services on behalf of retailers (“Retailers”) to the Retailers’ customers (“Customers”). This case concerns the disclosure of personal data via a delivery order tracking function on the Organisation’s website (the “Tracking Function Page”). 2 On 23 April 2018, the Personal Data Protection Commission (the “Commission”) received a complaint that the Tracking Function Page could potentially be used to harvest personal data of the Customers. By changing a few digits of a Tracking ID, the complainant could access personal data of another Customer (the “Incident”). Facts of the Case 3 The Organisation first set up the Tracking Function Page in December 2014 to allow Customers to (i) enquire on the delivery status of their parcels; and (ii) confirm the identity of individuals who collect parcels on their behalf (where applicable). Generally, for a delivery, only a Retailer and the relevant Customers of the Retailer would be provided with a Tracking ID for parcels sent by the Retailer that were to be delivered by the Organisation to the Customer. 4 There were 2 types of Tracking IDs used by the Organisation, namely sequential and non-sequential Tracking IDs. According to the Organisation, the reason for having sequential numbers in some of the Tracking IDs was for recording and business analytics purposes. Since the launch of the Tracking Function Page, the Organisation was aware that Tracking IDs could potentially be manipulated by changing the last few digits of the Tracking ID. While Tracking IDs with non-sequential numbers may have a lower risk of manipulation, a random generation 2 of any 9 digits that happened to match a valid Tracking ID could still result in unauthorised access and disclosure of personal data. 5 For a period of approximately 3 months from launch of the Tracking Function Page, the Organisation unsuccessfully experimented with 2 methods as a second layer of authentication to the Tracking IDs. These methods involved using either the last 4 digits of a Customer’s mobile number or the Customer’s last name to verify the identity of the person using a Tracking ID. According to the Organisation, these methods were not workable due to difficulties such as the Retailers not having, or not wishing to disclose, the mobile number of their Customers or the Customers not being able to recall the name they had provided at the time of purchase. Hence, the Organisation ceased using a second layer of authentication in 2015. 6 At the material time, the Tracking IDs were thus the sole means of using the Tracking Function Page. Upon the entry of a valid Tracking ID, the following types of information (the “Disclosed Data”) could be accessed from the Tracking Function Page, depending on the delivery status of the parcel in question (as indicated below): (a) For parcels with a “Pending Pickup” status: (i) (b) (c) only the Tracking ID; For parcels with a “On Vehicle for Delivery” status: (i) the Tracking ID; and (ii) the Customer’s Address; and For parcels with a “Completed” status: (i) the Tracking ID; (ii) the Customer’s address; and (iii) the name and signature of the Customer or other individual who had collected the parcel on behalf of the Customer (this was upon clicking on “Retrieve Proof of Delivery” hyperlink). 3 7 Save for the one-time archival of 2.6 million Tracking IDs on 31 August 2016, the Organisation did not have any procedures to remove records of completed deliveries from the Tracking Function Page (i.e. those with the “Completed” status). The Organisation estimated that, at the time of the Incident, there were 1,262,861 unique individuals with valid Tracking IDs at the “Completed” status (the “Affected Individuals”). 8 Upon being notified by the Commission of the Incident, the Organisation took the following remedial actions: (a) Removed the Customer’s address for the “Pending Pickup” and “On Vehicle for Delivery” delivery statuses; (b) As of 23 August 2018, the Organisation implemented a system such that Tracking IDs would expire 14 days after the completion of the delivery1; (c) In August 2018, the Organisation engaged a Crest-certified security organisation for a one-year period to assist with establishing an overarching security framework with a data protection focus, which includes working out a data protection training program for the Organisation’s employees who will all receive formal training on the Organisation’s obligations with respect to the Personal Data Protection Act 2012 (“PDPA”); and (d) Engaged a law firm to improve and document the Organisation’s personal data protection policies. Findings and Basis for Determination 9 As a preliminary point, the Disclosed Data for parcels with “Pending Pickup” and “On Vehicle for Delivery” delivery statuses did not include any data that could identify a Customer. However, the Disclosed Data for parcels with the “Completed” delivery status included the Customers’ names, address and signature. Hence, such data constituted personal data where it related to an identified Customer. In particular, the Incident resulted in the exposure of the following personal data to unauthorised access (the “Exposed Personal Data”): 1 The Organisation has since received feedback from some Retailers requesting to lengthen the validity period of the Tracking IDs, and is considering lengthening the validity period from 14 days to 45 days, but this has yet to be implemented. 4 (a) the names and signatures of Affected Individuals who had signed for parcels when collecting them; and (b) potentially, the addresses of Affected Individuals who were Customers. Whether the Organisation had contravened Section 24 of the PDPA 10 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 Commissioner found that the Organisation had failed to put in place reasonable security arrangements to protect the Exposed Personal Data for the following reasons: (a) First, and as mentioned at [4], the Organisation was aware from the outset that Tracking IDs may be manipulated and had tried unsuccessfully to introduce a second layer of authentication. Notwithstanding its knowledge of the risk of unauthorised access and disclosure of the Exposed Personal Data through manipulation of the Tracking IDs, there was a glaring failure by the Organisation to operationalise an effective method of second layer authentication. Given the foreseeable risk of using Tracking IDs as the sole means of accessing and using the Tracking Function Page, it is inexcusable for the Organisation to neglect its obligations to implement a workable security arrangement to protect the Exposed Personal Data. This resulted in the Exposed Personal Data of a significantly large number of individuals being exposed to the risk of unauthorised access and disclosure for a period of close to 2 years; and (b) Secondly, the Organisation did not have a procedure to remove the Exposed Personal Data from the Tracking Function Page after the completion of a delivery. The Organisation could have easily done so by setting a fixed period upon completion of a delivery after which the Tracking ID would no longer be valid (as they have done after being informed of the Incident). This would have significantly reduced the risk of unauthorised access and disclosure to the Exposed Personal Data. 11 Accordingly, the Commissioner found that the Organisation had contravened section 24 of the PDPA. 5 Representations by the Organisation 12 In the course of settling this decision, the Organisation made representations for the Commissioner to issue a warning in lieu of a financial penalty, or in the alternative, to reduce the quantum of financial penalty imposed for the reasons set out below. 13 First, on 31 August 2016, the Organisation archived a significant number (2.3 million) of Tracking IDs. As such, only Tracking IDs issued after 31 August 2016 were accessible at the date of the Incident (i.e. the Exposed Personal Data was subject to risk of unauthorised access and disclosure for less than 2 years)2. 14 Secondly, keeping the Exposed Personal Data accessible from the Tracking Function Page was “well-meaning and intended to be an additional feature of its platform to differentiate itself from its competitors”, and this allowed the Retailers and their Customers to access such information as and when required without having to contact the Organisation. Furthermore, some Retailers may not receive feedback from its customers promptly and would require the Tracking IDs to be accessible for a longer period in order to respond to feedback or conduct investigations. 15 Thirdly, the Organisation raised the following factors for the Commissioner’s consideration: (a) The names in the Exposed Personal Data may not be the full names of Affected Individuals and is “considerably less sensitive and complete than other published cases”; (b) There was only a single finding of breach of one obligation under the PDPA (i.e. Section 24); and (c) There was no evidence to suggest any actual unauthorised access and/or exfiltration of data leading to loss or damage. 2 Prior to the Organisation providing information in relation to the archiving of Tracking IDs on 31 August 2016, the Commissioner preliminarily found that the Exposed Personal Data was subjected to the risk of unauthorised access and disclosure for more than 2 years. 6 16 Finally, the Organisation also compared the present case with Re K Box Entertainment Group Pte Ltd [2016] SGPDPC 1 (“K Box”) and Re Horizon Fast Ferry Pte Ltd [2019] SGPDPC 27 (“Horizon Fast Ferry”). The Organisation represented that the circumstances of these 2 cases were far more aggravated in comparison and the financial penalties imposed was $50,000 in K Box and $54,000 in Horizon Fast Ferry. The Organisation also represented that Re Challenger Technologies Limited and others [2016] SGPDPC 6 (“Challenger”) is more similar to the present case, and a financial penalty was not imposed in Challenger. 17 Having carefully considered the representations, the Commissioner has decided to maintain the quantum of financial penalty set out at [20(a)] for the following reasons: (a) While the Organisation did archive 2.6 million Tracking IDs on 31 August 2016, this was a one-off exercise. The Organisation did not have any procedures to remove records of completed deliveries from the Tracking Function Page (i.e. those with the “Completed” status). Notwithstanding the archival of the 2.6 million Tracking IDs, Exposed Personal Data of 1,262,861 unique individuals with Tracking IDs had been accumulated over a period of close to 2 years. This was not reasonable considering that the delivery information which Retailers and Customers may want to access would be for a limited post-delivery period (which was likely to be in the order of weeks rather than years); (b) As for the factors in [15] raised by the Organisation, these had already been taken into consideration in the Commissioner’s determination of the quantum of financial penalty; and (c) With respect to the Organisation’s representations comparing the present case to K Box, Horizon Fast Ferry and Challenger, the key distinguishing factor is the volume of personal data involved. The present case involves over 1 million Affected Individuals, which far exceeds the number of affected individuals in K Box, Horizon Fast Ferry and Challenger.3 These cases therefore do not support the Organisation’s representations for a warning to be issued in lieu of a financial penalty or a reduction in financial penalty. 3 As compared to 1,262,861 unique individuals in this case, the number of affected individuals was found to be approximately 317,000 in Re K Box Entertainment Group, 295,151 in Re Horizon Fast Ferry and 165,306 in Re Challenger Technologies Limited 7 The Commissioner’s Directions 18 In determining the directions to be imposed on the Organisation under section 29 of the PDPA, the Commissioner took into account the following aggravating factors: (a) The Organisation was cognisant of the risks of unauthorised access and disclosure to the Exposed Personal Data through the Tracking Function Page but failed to resolve the issue for more than 2 years; (b) The Exposed Personal Data of a significantly large number of individuals were exposed to the risk of unauthorised access and disclosure for close to 2 years; and (c) The Organisation failed to remove Exposed Personal Data of a significantly large number of individuals from the Tracking Function Page when it was no longer necessary to keep them accessible online. 19 The Commissioner also took into account the following mitigating factors: (a) the Organisation was cooperative in the investigations; (b) the Organisation had, in effect, adopted an approach consistent with data protection by design by controlling the amount of information disclosed at different stages of the delivery process, thereby decreasing the risk of unauthorised access and disclosure; and (c) 20 there was no evidence of exfiltration of the Exposed Personal Data. Having considered all the relevant factors of this case, the Commissioner hereby directs the Organisation to: (a) Pay a financial penalty of $90,000 within 30 days from the date of the directions, 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; and 8 (b) Within 30 days from the date of this direction, implement a reasonable validity period for the Tracking IDs after completion of each delivery, which should be as reasonably short as possible while meeting business needs. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 9 ","Directions, Financial Penalty",15f399417f152a9a341caa9715008baacdbf0985,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,133,133,1,952,"A financial penalty of $25,000 was imposed on Singtel for failing to put in place reasonable security arrangements to protect the personal data of users on its My Singtel mobile application.","[""Protection"", ""Financial Penalty""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Singapore-Telecommunications-Limited.pdf,Protection,Breach of the Protection Obligation by Singtel,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-singtel,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 36 Case No DP-1705-B0781 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Telecommunications Limited … Organisation DECISION 1 Singapore Telecommunications Limited [2019] SGPDPC 36 Tan Kiat How, Commissioner — Case No DP-1705-B0781 12 September 2019 Background 1 This case concerns a design issue in a previous version of Singapore Telecommunications Limited’s (the “Organisation”) “My Singtel” mobile app (the “Mobile App”), which resulted in the unauthorised disclosure of the personal data of the Organisation’s customers. The current version of the Organisation’s Mobile App does not have this design issue as it has been fixed. 2 On 17 May 2017, the Personal Data Protection Commission (the “Commission”) received information from an anonymous informant alleging that there was a vulnerability in the Organisation’s Mobile App, which allowed the informant to access the account details of other customers (the “Data Breach”). Following an investigation into the matter, the Commissioner found the Organisation to be in breach of section 24 of the Personal Data Protection Act 2012 (“PDPA”). The Commissioner sets out below his findings and grounds of decision. 1 Singapore Telecommunications Limited [2019] SGPDPC 36 Material Facts and Documents 3 The Organisation is a telecommunications company in Singapore. The Mobile App was developed by the Organisation’s IT team to enable its customers to track their account information and manage add-on services. Communications between the Mobile App and the Organisation’s servers are conducted via Application Programming Interfaces (“API”). 4 The Organisation’s customers can login to the Mobile App via the following methods: (a) Mobile Station International Subscriber Directory Number (“MSISDN”) login: where a customer’s mobile phone is connected to the Organisation’s mobile data network (3G/4G), the Organisation’s servers will verify that the MSISDN and IP address of the mobile phones are correct before granting the customer access to the Mobile App;1 (b) One Time Password (“OTP”): through validation of the OTP sent to customers via SMS and entering it in the Mobile App (“OTP Login Method”); and (c) 5 OnePass: by using their OnePass login and password. Customers that login to the Mobile App via the MSISDN or OTP login method have access to the following data relating to their own account: 1 Each MSISDN is assigned a unique IP address. When a user logs in to the Mobile App via the MSISDN login method, the backend server will verify the MSISDN assigned to that IP address. Once verified, the login attempt will be deemed to be authenticated and the user will be granted access to the Mobile App. 2 Singapore Telecommunications Limited [2019] SGPDPC 36 (a) the mobile number used to access the Mobile App; (b) related service plan information (i.e. data, talktime and SMS usage); 6 (c) outstanding bill amount; (d) bill payment due date; and (e) billing account number. In addition to the data mentioned at paragraph 5 above, customers that login to the Mobile App via the OnePass method also have access to all the service information for all Singtel services registered under that Singtel OnePass ID. In addition, if such customers had opted for electronic billing, they would have access to the following data relating to their own account: (a) the customer’s name; (b) the customer’s billing address; and (c) all Singtel services and corresponding usage (where applicable) under the same billing account number. 7 The anonymous informant claimed that the API on the server could be manipulated by using specialised tools to gain unauthorised access to the account details of other customers through the following methods: (a) The MSISDN is a string of numbers that incorporates within it the customer’s mobile phone number. By logging in using a legitimate Singtel account via the MSISDN login method and changing the value in the 3 Singapore Telecommunications Limited [2019] SGPDPC 36 MSISDN field (i.e. to another customer’s mobile phone number)2 that was sent from the Mobile App’s API to the Organisation’s servers, the informant was able to retrieve the account details (such as the billing account number and billing cycle) of the other customer. (b) Thereafter, by logging in using a legitimate Singtel account via the OnePass method and changing the value in the billing account number and billing cycle fields, the informant was able to obtain the customer’s bill, which contains further personal data such as the customer’s name, billing address and all Singtel services and corresponding usage (where applicable) under the same billing account number3. 8 The informant accessed four billing accounts and extracted the customer’s name, billing address, billing account number, mobile phone number as well as customer service plans (including data, talk time and SMS usage). While there was no further evidence of unauthorised access, the personal data of approximately 330,000 of the Organisation’s customers who were using the Mobile App at the material time were put at risk of disclosure. 9 Although the Organisation had engaged a third party security vendor to conduct regular security penetration tests on the Mobile App and backend systems (including the API), the tests had not detected the design issue in the API that led to the Data Breach and the Organisation was unaware of it. The subscriber’s mobile phone number was used by the Organisation’s servers to retrieve the subscriber’s account and billing details. 2 3 As mentioned at paragraph 6 above. 4 Singapore Telecommunications Limited 10 [2019] SGPDPC 36 During the investigation, the Organisation admitted that the Data Breach was caused by a design issue in the API – the application input4 was not validated against the login credential used to access the Mobile App before performing the requested operation (the “Direct Object Reference Vulnerability”). Because all request parameters sent by the Mobile App to the Organisation’s server during a valid login session were assumed to be valid, once a user was legitimately authenticated to initiate a valid login session on the device (via the MSISDN, OTP or OnePass login methods), the user would be able to intercept and change the field parameters in the API requests between the Mobile App and the server. Notwithstanding, the Organisation asserted that such an action was “not something that a normal user of the App would attempt” and the attacker must be “technically competent” as the changing of the parameters could only be performed on a workstation. 11 Soon after it was notified of the Data Breach, the Organisation took remedial actions to resolve the Direct Object Reference Vulnerability. The Organisation enhanced the API in order to tightly couple the Mobile App user’s identifiers to the authenticated session. In this manner, should the parameters be modified during the same authenticated session such that they do not match the Mobile App user’s identifiers (e.g. the MSISDN field is changed to another number and service information such as data usage of that other number is requested), the user will see an error message and be logged out. 4 Such as the MSISDN for the MSISDN or OTP login method, and the MSISDN, billing account number, billing payment due date for the OnePass login method. 5 Singapore Telecommunications Limited [2019] SGPDPC 36 The Commissioner’s Findings and Basis for Determination 12 It is not disputed that the subscriber’s name, billing address, billing account number, mobile phone number as well as customer service plans (including data, talk time and SMS usage) are “personal data” as defined in section 2(1) of the PDPA (“Personal Data”). There is also no dispute that the PDPA applies to the Organisation as it falls within the PDPA’s definition of “organisation”. The key issue to be determined in this case is therefore whether the Organisation had complied with its obligations under section 24 of the PDPA. Whether the Organisation complied with its obligations under section 24 of the PDPA 13 Section 24 of the PDPA provides that 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. It is not disputed that the Personal Data was in the Organisation’s possession and/or control. 14 Having considered the material facts, the Commissioner finds that even though the Organisation had engaged a third party security vendor to conduct regular penetration tests on the Mobile App and backend systems (including the API), the Organisation failed to put in place reasonable security arrangements with respect to the said API to protect the Personal Data. 15 First, by the Organisation’s own admission, the Data Breach was caused by the Direct Object Reference Vulnerability, which was a design issue in the API. The Organisation failed to take into account the risk of manipulation to the parameters sent from the Mobile App’s API to the Organisation’s servers when 6 Singapore Telecommunications Limited [2019] SGPDPC 36 designing the Mobile App. The validation of parameters (whether input or noninput fields), which could have prevented unauthorised access to the Personal Data, were not implemented as part of the API’s initial design. 16 The Direct Object Reference Vulnerability is a relatively basic design issue and well-known security risk that a reasonable person would have considered necessary to detect and prevent. It was one of Open Web Application Security Project (“OWASP”) 2013’s top 10 most critical web application security risks and OWASP recommended, among other things, the usage of Indirect Object Reference as a prevention method. 17 Furthermore, as highlighted in the Commission’s Guide to Building Websites for SMEs (at [6.5]), programmers should be aware of the common website vulnerabilities and adopt the appropriate programming techniques and practices to ensure that personal data cannot be exposed through such vulnerabilities. Although the Guide to Building Websites for SMEs sets out key considerations for the process of setting up a website, the same principles are similarly applicable when programming a mobile application. This is because the same issues arise when a server responds to requests from a mobile app as when it responds to requests from a web browser. “6.5 Website Programming 6.5.1 When programming the website, programmers should be aware of the common website vulnerabilities, and adopt the proper programming techniques and practices to avoid them. Programmers can use the OWASP Top 10 vulnerabilities list as guide and some common vulnerabilities include: 7 Singapore Telecommunications Limited [2019] SGPDPC 36  Injection (e.g. SQL Injection)  Cross-site scripting  Buffer overflows  Poor authentication & session management 6.5.2 Organisations and any engaged IT vendors should ensure that personal data cannot be exposed, either accidently or by design, through any such vulnerabilities. The website functions should be thoroughly tested or scanned for vulnerabilities, before the website is launched.” [Emphasis added.] 18 By failing to take into account the risk of manipulation to parameters sent from the Mobile App’s API to the Organisation’s servers, the Commissioner finds that Organisation subjected its customers to the risk of actual and potential unauthorised access of their personal data. 19 At this juncture, the Commissioner would like to deal with the Organisation’s claim that exploiting the Direct Object Reference Vulnerability was “not something that a normal user of the App would attempt” and that the attacker must be “technically competent” as the changing of the parameters could only be performed on a workstation. 20 While the changing of parameters would require a person to have some knowledge of the tools and methods for doing so, anyone with working knowledge of how a mobile app communicates with the servers through an API could have exploited the Direct Object Reference Vulnerability. The tools and software required to manipulate the parameters are available online. 8 Singapore Telecommunications Limited 21 [2019] SGPDPC 36 The Organisation was aware that direct object reference vulnerabilities had been discovered in its Mobile App. Despite having received professional advice to take precautions against such vulnerabilities, the Organisation omitted to conduct a full code review on the input and non-input fields and hence failed to discover the Direct Object Reference Vulnerability that was exploited in this case. 22 As mentioned at paragraph 9 above, the Organisation had engaged a third party security vendor to conduct regular security penetration tests on the Mobile App and backend systems.5 The Direct Object Reference Vulnerability was not detected prior to the Data Breach but a variation of it was found in the October 2015 penetration test (“2015 Penetration Test Report”) and rectified in November 2015. In the 2015 Penetration Test Report, the security vendor cited three examples of Direct Object References vulnerabilities in the API (collectively, the “2015 DOR Vulnerabilities”). 23 During the investigation, the Organisation represented that the 2015 DOR Vulnerabilities were specific to the API accepting input fields (i.e. parameters keyed in by users at the user interface level), whereas the Direct Object Reference Vulnerability did not validate non-input fields (i.e. parameters not keyed in by users such as automatically generated URL at the backend). As the Organisation had only conducted a code review for the 2015 DOR Vulnerabilities on APIs accepting input fields, the Direct Object Reference Vulnerability that caused the Data Breach was not discovered at the time. However, contrary to the Organisation’s representation, a review of the 2015 Penetration Test Report showed that both input and non-input fields were affected by the 2015 DOR 5 At the time of the Data Breach, the most recent penetration tests on the Mobile App and backend systems were conducted in October 2015 and January 2017. 9 Singapore Telecommunications Limited [2019] SGPDPC 36 Vulnerabilities, and even non-input fields could be manipulated by the Mobile App’s call to the API and that this should be remedied. 24 Based on the findings and recommendations in the 2015 Penetration Test Report, the Organisation ought to have been more diligent in performing a thorough assessment of the security posture of the API and the server. The Organisation should have examined all other functions to determine whether they could be exploited by changing the input parameters and implement the relevant fixes, but it had failed to do so. 25 For the reasons above, the Commissioner finds that the Organisation is in breach of section 24 of the PDPA as it failed to make reasonable security arrangements with respect to the said API to protect the personal data in its possession and within its control. 26 The Organisation submitted representations after a preliminary grounds of decision was issued and raised four points. First, the Organisation asserted that it was reasonable that any request parameters sent by the Mobile App during a login session was treated as valid without having to re-validate the request parameters during the session, given that the user was required to be legitimately authenticated via one of the three login methods. This does not address the Direct Object Reference Vulnerabilities which could be exploited by a third party. Paragraphs 15 to 25 above, deal with this point. 27 Secondly, the Organisation asserted that not all of its 330,000 customers’ data was put at risk of disclosure as the informant would have had to use the correct combination of the mobile number of the customer, the customer’s billing account number, billing account ID and billing cycle date in order to generate a bill specific to that customer or a correct mobile phone number to generate the 10 Singapore Telecommunications Limited [2019] SGPDPC 36 relevant subscription information. The Organisation thus asserts that the decision should be narrowed to only the 4 accounts that were successfully accessed. The manner in which the informant was able to access the records of the said 4 accounts is set out above at paragraphs 7(a) and 7(b). While the informant only accessed 4 accounts, the informant or someone with similar skillset and access to the same resources could potentially have access to the personal data of all 330,000 subscribers who were using the Mobile App during the material time of the Incident. In the circumstances, it is correct that the full size of the database was one of the factors taken into consideration in assessing the financial penalty quantum. 28 Thirdly, in reference to paragraph 19 above, the Organisation asserted that the technical expertise required by someone to exploit the Direct Object Reference Vulnerability was underestimated in this Decision. For the avoidance of doubt, it is agreed that some level of technical expertise would have been required for someone to exploit the Direct Object Reference Vulnerability. While this level of technical expertise is not uncommon, what cannot be ignored is that the vulnerability is well known and the requisite knowledge, tools and software to exploit the Direct Object Reference Vulnerability can be acquired online. This increases the likelihood that someone with the wrong motivation could have exploited the vulnerability. 29 Finally, the Organisation also restates that the Direct Object Reference Vulnerability was not detected in the security penetration tests. This is dealt with at paragraph 21 above. 30 In the circumstances, the Commissioner decided to maintain his finding that the Organisation was in contravention of section 24 of the PDPA. Nevertheless, the Commissioner has decided to impose a reduced financial 11 Singapore Telecommunications Limited [2019] SGPDPC 36 penalty quantum as set out at paragraph 32 below, given that the exploitation of the vulnerability requires some level of technical expertise. The Commissioner’s Directions 31 Given the Commissioner’s findings that the Organisation is in breach of section 24 of the PDPA, the Commissioner is empowered under section 29 of the PDPA to issue such directions as it deems fit to ensure compliance with the PDPA. This may include directing the Organisation to pay a financial penalty of such amount not exceeding S$1 million. 32 Having considered all the relevant factors in this case, the Commissioner hereby directs the Organisation to pay a financial penalty of $25,000 within 30 days from the date of the Commissioner’s direction, failing which, interest at the rate specified in the Rules of Court6 in respect of judgment debts, shall accrue and be payable on the outstanding amount of the financial penalty until the financial penalty is paid in full. The Commissioner has not set out any further directions given the remediation measures that the Organisation has already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 6 Cap 322, R5, 2014 Rev Ed. 12 ",Financial Penalty,1cfca0515da19cdcbdfd450d34bfa1d3c2583b97,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,134,134,1,952,"A financial penalty of $40,000 was imposed on Marshall Cavendish Education for failing to put in place reasonable measures to protect the personal data of users of its learning management system.","[""Protection"", ""Financial Penalty""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Marshall-Cavendish-Education-Pte-Ltd.pdf,Protection,Breach of the Protection Obligation by Marshall Cavendish Education,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-marshall-cavendish-education,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC [34] Case No DP-1704-B0699 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Marshall Cavendish Education Pte. Ltd. …Organisation(s) DECISION Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC [34] Tan Kiat How, Commissioner – Case No DP-1704-B0699 30 August 2019 1. With the increasing prevalence of ransomware attacks online, this case gives occasion to restate the importance of making adequate security arrangements to protect personal data and to limit unnecessary exposure of an organisation’s computer systems to such potential threats on the internet. Background 2. Marshall Cavendish Education Pte Ltd (“MCE”) provided a learning management system (“LMS”) at www.mconline.com.sg (“Website”) to the Ministry of Education (“MOE”) schools. This was pursuant to a contract between MCE and MOE. 3. On 1 February 2017, ransomware affected a substantial portion of MCE’s network (“Incident”). On 3 February 2017, MCE informed MOE of the Incident. The relevant government agencies were notified of the Incident accordingly, including the Personal Data Protection Commission (“PDPC”). The ransomware had encrypted the files found on MCE’s servers, including files containing personal data of individuals stored in the LMS, and made them inaccessible until a payment was paid to decrypt them. 4. Investigations revealed that the ransomware was an executable file on 1 server. However, it affected data on 11 servers and network storage devices in MCE’s network. These 11 affected servers and network storage devices mostly held teaching material. However, the server in question and a network storage device Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 each held copies of the database of 206,240 active and 44,688 inactive users. The database held the following personal data of its users, which were mandatory fields that every user who signed up for accounts on the Website had to provide: a. Login ID comprising an individual’s full or partial birth certificate or NRIC no.; b. Name; c. School name; d. Schooling level; and e. Class. 5. Users could also opt to supply additional personal data using optional fields. According to MCE, however, users rarely provided such additional information, which comprised: a. Email address; b. Address; c. NRIC; d. Mobile Number; e. Father/Mother/Guardian’s Name; f. Father/Mother/Guardian’s NRIC/Passport Number; 3 Re Marshall Cavendish Education Pte. Ltd. 6. [2019] SGPDPC 34 g. Father/Mother/Guardian’s Occupation; h. Father/Mother/Guardian’s Mobile Number; i. Father/Mother/Guardian’s Residential Number; and j. Father/Mother/Guardian’s Office Number. MCE found no evidence that the personal data in its servers had been ex- filtrated. MCE’s internet service provider’s network logs would have captured the downloading of a database of that size. 7. However, as access had been gained to MCE’s servers to upload and execute the ransomware, it meant that the personal data in MCE’s servers were exposed to unauthorised access. Further, the encryption of the personal data by the ransomware was an unauthorised modification of the personal data in MCE’s servers. Causes of the Incident 8. The primary cause of the Incident was due to a change made to a firewall rule to allow internet access to the server. This allowed the external perpetrator to gain entry into the system to upload and execute the ransomware. 9. MCE had employed a senior system engineer (“SE”) to, amongst other things, maintain MCE’s servers. The SE was part of the Organisation’s IT team that also comprised of another system engineer and a manager (“IT Manager”) who had supervisory duties over the said system engineers. According to the Organisation, the IT Manager together with the SE and a program manager was also responsible for managing the services in the Organisation’s datacentre. 4 Re Marshall Cavendish Education Pte. Ltd. 10. [2019] SGPDPC 34 The SE had found that the backup server’s anti-virus definition was not updating automatically. The SE thought that the anti-virus’ auto-update function was not working properly due to the limited or restricted access to the Internet, and thus the SE changed a firewall rule to allow direct access from the Internet to the server in question (the “Firewall Rule Change”). The Firewall Rule Change had lifted the restrictions that were in place to prevent external access to the MCE backup server and the data it held. 11. Critically, although the Firewall Rule Change was intended to be temporary, the SE had failed to reinstate the firewall rule after completing his investigation, thereby allowing the server to be continuously exposed to internet access. This increased the risk of an external perpetrator being able to gain entry into the server, as had transpired in this case. 12. PDPC’s investigations revealed that the perpetrator had gained entry to the server through brute force attacks on the server. As a result of these brute force attacks, the perpetrator had uploaded and executed the ransomware on the server on 1 February 2017. Remedial actions by the Organisation 13. The Organisation subsequently took the following remedial measures: a. Put in place security arrangements to protect the personal data held in its servers after assessment of their need for remote internet access; b. Conducted a review of the existing firewall rules in conjunction with an assessment of the remote internet needs of the IT system; 5 Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 c. Engaged an external auditor to conduct a thorough review and audit of MCE’s IT system; d. Strengthened controls over deployment of any program to the Website; e. Strengthened controls over obtaining of source code and database scripts; f. Improved handling of any reported defects/issues with the LMS portal; g. Implemented monthly review of user access rights, including a listing of product environment users and their accompanying access rights; h. Strengthened control user access requests to the RDP server and mechanisms to deal with the deletion of any remote user access requests by non-active accounts; i. Improved management of the various types of user accounts; j. Better defined scope of duty for each system engineering team; k. Hired an IT security officer to focus solely on cybersecurity; and l. Strengthened its network security by clarifying various steps or approvals that need to be performed or obtained before a system engineer can make any system changes and procedures for follow up actions and management reporting for all IT security incidents. 6 Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 Findings and Basis for Determination Issue for determination 14. The issue to be determined is whether MCE had complied with its Protection Obligation under section 24 of the PDPA in this case. 15. There is the preliminary issue of whether MCE was a data intermediary for MOE and whether it could avail itself of the exception under section 4(1)(c) of the PDPA, which states that Parts III to VI of the PDPA, including section 24 of the PDPA, shall not impose any obligation on any public agency or organisation in the course of acting on behalf of a public agency (in this case, MOE). Investigations disclosed that MCE was a vendor providing IT tools and hosting services for MOE’s teaching and administrative programmes. MCE was not acting on behalf of a public agency for the purposes of section 4(1)(c) of the PDPA and is subject to the full gamut of obligations under the PDPA qua its capacity as a data intermediary. 16. Section 24 of the PDPA provides that 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 or similar risks (the “Protection Obligation”). Whether MCE breached section 24 of the PDPA 17. The personal data in question was stored on MCE’s backup server. It was in MCE’s possession or under its control. MCE therefore had a duty to protect that data by making reasonable security arrangements against unauthorised access or modification. 7 Re Marshall Cavendish Education Pte. Ltd. 18. [2019] SGPDPC 34 MCE did not fulfil its obligation under section 24 of the PDPA when the circumstances are viewed in totality. The SE had intended the Firewall Rule Change to be temporary. However, the SE had failed to reverse the Firewall Rule Change as he was interrupted by other work matters in the middle of attempting to establish the reason for the failure of the antivirus software to update automatically. This was a critical mis-step. 19. This was exacerbated by the fact that the SE had, at some time prior to this, already installed remote access software on the backup server. Only the Remote Desktop Protocol (RDP) server was meant to be configured to be accessible remotely. However, it appears that the SE had configured the backup server as a secondary RDP server. 20. While the Firewall Rule Change in and of itself was a security risk as it opened the MCE’s backup server to a wide range of possible attacks, the installation of remote access software on the server and its configuration as a secondary RDP server would have allowed an attacker a greater chance of success in infiltrating it, especially where no safeguards were implemented to mitigate this risk. These threats are real – as has been exemplified in this case where the perpetrator had managed to use brute-force attacks to gain access to the backup server in order to upload and execute the ransomware. 21. As an organisation, MCE bore responsibility for putting in place the requisite measures to prevent data breaches from taking place. As mentioned in Re Aviva Ltd [2018] SGPDPC 4, relying solely on employees to perform their tasks diligently is not a sufficiently reasonable security arrangement, and the organisation would need to take proactive steps to protect personal data. In this case, the SE was part of the Organisation’s IT team supervised by an IT Manager. However, it appears that the IT Manager did not exercise competent supervision over the IT team. In this regard, the Organisation admitted, through a written statement made 8 Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 by the Organisation’s General Manager of Product Development (“GM of Prd. Devpt.”), that: a. User accounts in the data centre for former staff, including that of a staff who had left in 2014, had not at the material time been removed; b. The SE was not familiar with the new firewall and that this may have contributed to the Incident. If the Organisation was aware of the SE’s unfamiliarity with the new firewall, the IT manager ought to have supervised the SE more closely; and c. That there were no standard operating procedures in place to document changes to the firewall configurations and there were no measures in place to monitor for the installation of unauthorised software. We have addressed this issue in paragraphs 35 to 37 below in addressing the representations made by the Organisation. 22. In these circumstances, the IT Manager may not have been able to effectively supervise the daily operational actions of the SE. 23. What is required on the part of the Organisation are practicable steps, and these can take the form of identifying areas of risks that require higher level approval and adequate supervision of such risky areas. One such area that ought to have been identified was the installation of remote access software as every installation of remote access software is a channel for web-based threats that have to be guarded against. In this regard, the Organisation did not implement a process which provided adequate supervisory oversight over the installation of the remote access software, apart from identifying the installation of remote access software as an act that required higher level approval. Records of any installation of the remote access software could also be, but were not, maintained. This would have been a practicable step that MCE could have put in place. Of course, this cannot prevent 9 Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 the situation where the SE wilfully disregarded such a policy and proceeded to install remote access software on the backup server without authority, but the analysis of the facts and conclusion on MCE’s liability might well be different had such supervisory measures been implemented. 24. Similarly, MCE could also have implemented some form of approval process for changes to firewall configuration. In this case, a manual record of firewall changes in a log book or other form of supervisory monitoring, for example, could have been practicable steps put in place by MCE. This would have heightened the awareness of the SE that changes to firewall rules cannot be made in a cavalier manner, and that his actions were subject to scrutiny. Again, this will not prevent wilful disregard of such control measures but the lack of such practicable steps deprived MCE room to raise a credible claim that it had put in place reasonable security measures to protect the personal data. 25. In addition to the failure of supervision, 15 accounts with remote access to MCE’s system through the primary RDP server were found during MCE’s postIncident review. MCE reduced this number of accounts to 5. The unnecessary number of permitted users with remote access to the system pointed to a less than adequate appreciation of the risk that comes with remote access. This buttresses the Commissioner’s findings that MCE has not adequately met its section 24 obligation to protect personal data. The personal data stored on the server was not only subject to unauthorised access, it was modified without authorisation through the encryption process of the ransomware. 26. In the premises, the Commissioner is satisfied that MCE failed to make reasonable security arrangements to protect the personal data in its servers from risk of unauthorised access, modification and disposal. The Commissioner therefore finds MCE in breach of its obligation under section 24 of the PDPA. 10 Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 Directions 27. The Commissioner is empowered under section 29 of the PDPA to give the Organisations such directions as it deems fit to ensure the Organisations’ compliance with the PDPA. This may include directing the organisations to pay a financial penalty of such amount not exceeding S$1 million as the Commissioner thinks fit. 28. Pursuant to section 29(2) of the PDPA, and the investigation and assessment of this matter having been completed, the Commissioner is satisfied that MCE did not make reasonable security arrangements and is in breach of section 24 of the PDPA. 29. Having carefully considered all the relevant factors of this case, the Commissioner hereby directs that MCE pays a financial penalty of S$40,000 within 30 days from the date of the directions, failing which interest shall be payable on the outstanding amount of such financial penalty. 30. In assessing the breach as determining the directions to be imposed on MCE in this case, the Commissioner took into account the following mitigating factors: a. MCE was cooperative in the investigations; b. There was no misuse of the affected personal data that was reported or indicated; and c. MCE had put in place several remedial measures as indicated at paragraph 13 above. 11 Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 However, the Commissioner had to balance these mitigating factors against the fact that MCE’s failure to protect in this case led to loss of personal data in the possession of the organisation to the control of the ransomware attacker. 31. Representations were made by MCE after being informed of the proposed decision in this case, submitting that they had complied with the Protection Obligation under section 24 of the PDPA. In the alternative, MCE requested for a warning in lieu of a financial penalty or to otherwise reduce the quantity of the financial penalty imposed. Compliance with the Protection Obligation under section 24 of the PDPA 32. In support of the assertion that MCE had complied with section 24 of the PDPA, MCE made the following representations: a. By installing remote access software on the backup server and changing the firewall configuration without higher level approval from MCE’s IT manager, the SE wilfully disregarded MCE’s IT security policy; b. As acknowledged by the Commission at paragraph 23, no practicable steps can be taken to prevent a situation of wilful disregard; and c. MCE had adequate supervisory measures, as seen by the fact that the Incident was discovered after MCE carried out its routine monitoring of the system, and MCE subsequently took prompt action to investigate the Incident. 12 Re Marshall Cavendish Education Pte. Ltd. 33. [2019] SGPDPC 34 The Commissioner has considered the representations and maintains his finding that MCE is liable under section 24 of the PDPA for the actions of the SE. 34. At the outset, it is crucial to note that the breach was not one-off, as the SE’s installation and usage of the unauthorised remote access software on the backup sever took place on more than one occasion, but went undetected. In fact, the SE had fully configured the backup server to function as an RDP server, should the primary server fail, without the knowledge of his supervisor. This shows the inadequacy of MCE’s supervisory mechanisms. 35. It should be noted that the Organisation, through a written statement made by its GM of Prd. Devpt. on 2 June 2017, had admitted that: a. “At the time of the incident, there were no measures in place to prevent system engineers to install unauthorised software, such as Teamviewer [a remote access software]”; and b. “They [the IT team] were not required to notify anyone else if changes were made to the firewall configurations. There are no standard operating procedures to document such changes.” The Organisation also admitted that this was a lapse on their part and have tightened their process following a security audit by their vendor. 36. The Organisation in its representations has stated that it had a policy in place which required the SE to seek higher level approval from the IT Manager for the installation of remote access software and the Firewall Rule Change. Assuming that the statement made by the GM of Prd. Devpt. on 2 June 2017 and the statements made in the representations are true and are consistent with each other, the reasonable conclusion is that, while there was a policy requiring such higher level approvals, this policy was not adequately implemented and there was a lack of 13 Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 supervision and monitoring over both the installation of remote access software and the Firewall Rule Change. In practice, the SE was allowed to take whatever action he deemed fit without any supervisory oversight from the IT Manager or any other supervisor even if this resulted in compromising the Organisation’s IT security. 37. In this regard, the fact that the SE was able to wilfully disregard MCE’s procedures on more than one occasion over a period of time, without this activity being detected, highlighted MCE’s failure to translate the policy into a process which sufficiently complies with section 24 of the PDPA. Merely putting in place policies is insufficient to fulfil MCE’s obligation under section 24 of the PDPA – MCE must also have taken practicable steps to implement these policies, for example, as set out above at paragraph 21 through adequate supervision and/or monitoring. Imposition of financial penalty 38. In support of their request that the Commission should issue a warning instead of a financial penalty or otherwise reduce the quantity of the financial penalty imposed, MCE made the following representations: a. The Commission failed to consider all relevant mitigating factors in arriving at the preliminary decision; b. The proposed financial penalty is manifestly excessive in light of previous decisions issued by the Commission for similar or even more serious breaches; and c. It would be extremely prejudicial for MCE if the Commission were to issue a decision and impose penalties on MCE almost two years after the Incident, as the public may have the misconception that the Incident took place recently and MCE currently does not have 14 Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 reasonable security arrangements to protect personal data that is in its possession. 39. MCE raised the following mitigating factors in its representations: a. There was clearly no loss of personal data; b. No personal data was accessed by the perpetrator or any third party and no individual can or will be affected by the Incident; c. MCE took immediate steps to reduce the damage caused by the Incident; d. There were no prior breaches of the PDPA on the part of MCE; and e. MCE had not acted deliberately or wilfully. 40. As the personal data had been rendered inaccessible by encryption, MCE had in fact lost access and control of the personal data. Also, because of the unauthorised encryption of files containing the personal data, MCE was forced to delete these encrypted files in accordance with its data protection policy. The main database was modified because it was encrypted, and there would have been a loss of new incremental data created during the interval between the last backed up copy and ransomware attack. Furthermore, personal data was put at risk as the perpetrator of the ransomware attack could access the personal data if they chose to do so. 41. Nevertheless, as noted at paragraph 30 above, the Commission took into account the fact that there was no misuse of the affected personal data that was reported or indicated, and the fact that MCE had put in place remedial measures following the Incident. The fact that there were no prior breaches of the PDPA is not a mitigating factor in itself. On the contrary, if MCE had breached the PDPA 15 Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 repeatedly, this would have been an aggravating factor, and it is trite that the absence of an aggravating factor is not a mitigating factor. In addition, the deliberateness or wilfulness of MCE in breaching the PDPA is not a relevant consideration in this case. 42. Furthermore, the three cases cited by MCE – Challenger Technologies Ltd and Xirlynx Innovations [2016] SGPDPC 6 (“Challenger”), Institute of Singapore Chartered Accounts [2018] SGPDPC 28 (“ISCA”) and Bud Cosmetics [2019] SGPDPC 1 (“Bud Cosmetics”) are not analogous to the present facts. 43. Firstly, MCE submitted that only a warning was imposed in Challenger although the personal data of more than 165,000 individuals was compromised. However, the personal data leaked in Challenger was limited – it comprised only individuals’ names, membership expiry dates and accumulated points. However, the personal data in the present case includes personal data of minors and NRIC numbers, and is thus of a more sensitive nature. 44. Secondly, MCE submitted that the personal data compromised in ISCA was even more sensitive as it included employment records and exam results, however a financial penalty of only $6,000 was imposed. Employment and exam results are not treated as sensitive data. Furthermore, the number of affected individuals in ISCA was substantially lesser – 1,906 individuals as opposed to more than 250,000 individuals in the present case, and the unauthorised disclosure was limited to a single unintended recipient for a short period of 10 minutes. This consequentially affects the quantity of the financial penalty imposed. 45. Thirdly, MCE submitted that in Bud Cosmetics, the Commission imposed a financial penalty of only $11,000 despite the fact that the Commission found breaches under sections 12, 24 and 26 of the PDPA. As with Challenger, the personal data compromised in Bud Cosmetics was not sensitive. Furthermore, the 16 Re Marshall Cavendish Education Pte. Ltd. [2019] SGPDPC 34 number of affected individuals in Bud Cosmetics was substantially lesser – 2,457 individuals as opposed to more than 250,000 individuals in the present case. 46. Lastly, the time taken to complete investigations into PDPA breaches and issue decisions may vary from case to case due to a myriad of factors. The present case involved substantial technical complexities requiring a longer a period of time to complete investigations, consider representations and issue the decision. The present Grounds of Decision clearly state the date of the Incident and the remedial measures taken by MCE. This would address MCE’s concerns that the public would be of the view that the incident took place recently or that it has not remediated the breach. 47. In view of the remedial measures taken by MCE, no further directions are necessary. 48. The Commissioner urges organisations to take the necessary action to ensure that they comply with their obligations under the PDPA. Appropriate enforcement action against non-compliant organisations will be taken. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 17 ",Financial Penalty,08a8fe2b2bb4c3daaa4126990a15b41870870f01,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,135,135,1,952,"A warning was issued to Barnacles Pte. Ltd. for failing to put in place reasonable measures to protect the personal data of individuals who had made dining reservations via its website; and retaining such personal data when it no longer had any legal or business purpose to retain it. As a result, the personal data of 149 individuals were accessible over the Internet.","[""Protection"", ""Warning"", ""Accommodation and F&B"", ""Dining reservations"", ""F&B""]",2019-10-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---Barnacles.pdf,Protection,Breach of the Protection Obligation by Barnacles,https://www.pdpc.gov.sg/all-commissions-decisions/2019/10/breach-of-the-protection-obligation-by-barnacles,2019-10-10,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1904-B3652 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Barnacles Pte. Ltd. SUMMARY OF THE DECISION 1. Barnacles Pte Ltd (the “Organisation”) operates a website which enables its customers to make reservations to dine at its restaurant. For this purpose, it collected certain personal data from its customers such as their name, contact number, email address and date and time of their reservation, amongst other information (the “Personal Data”). However, when the Organisation developed its website, the Organisation did not instruct the vendor it appointed to develop the website to implement security arrangements to protect the Personal Data. The Organisation also made no effort to verify whether any security arrangements had been put in place by its appointed vendor. As a result, the Personal Data was accessible over the Internet, for example, if a search was made on a customer’s name using an Internet search engine. The Organisation ceased operations in January 2019 but continued to retain the Personal Data until May 2019, even though it did not have any legal or business purpose to retain the Personal Data other than to fulfil or decline its customers’ reservations. 2. Following a complaint against the Organisation in April 2019, the Personal Data Protection Commission found that the Personal Data of 149 individuals had been exposed to the risk of unauthorised disclosure as a result of the Organisation’s failure to make security arrangements to protect the Personal Data and/or to cease to retain the Personal Data once it no longer had any legal or business purpose to retain it. In the circumstances, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of sections 24 and 25 of the Personal Data Protection Act 2012 and decided to give a warning to the Organisation. ",Warning,ca4aa8642a9f0116f05bea853cfe7f4261e535a5,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,136,136,1,952,A warning was issued to ERGO Insurance Pte. Ltd. for failing to protect the personal data of its policyholders from unauthorised disclosure via its internet portal. The personal data of 57 policyholders were mistakenly disclosed to other insurance intermediaries.,"[""Protection"", ""Warning"", ""Finance and Insurance""]",2019-10-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---Ergo-Insurance.pdf,Protection,Breach of the Protection Obligation by ERGO Insurance,https://www.pdpc.gov.sg/all-commissions-decisions/2019/10/breach-of-the-protection-obligation-by-ergo-insurance,2019-10-10,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1810-B2869 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And ERGO Insurance Pte. Ltd. SUMMARY OF THE DECISION 1. ERGO Insurance Pte Ltd (the “Organisation”) is a general insurer and operates an internet portal (the “Portal”) which enables its insurance intermediaries, who are not the Organisation’s employees, to request for documents of policyholders represented by the intermediaries. These documents contain the policyholders’ personal data such as their names, addresses, car registration numbers, genders, nationalities, NRIC numbers, dates of birth and contact numbers (the “Personal Data”). 2. The Organisation voluntarily informed the Personal Data Protection Commission on 15 October 2018 that it had earlier discovered, on 11 September 2018, that some of its insurance intermediaries had been incorrectly sent documents of policyholders who were represented by other insurance intermediaries (the “Incident”). The Incident arose when some insurance intermediaries (the “Intermediaries”) requested for documents of policyholders which they represent through the Portal. However, the Organisation’s application and printer servers had been shut down for a scheduled system downtime and when they were restarted, the Organisation’s employees had failed to follow the correct restart process. They were supposed to start both servers at the same time but this was not done as the starting of the printer server initially failed. This resulted in documents with duplicate document IDs being generated and hence the wrong documents being sent to the Intermediaries. As a result of the Incident, the Personal Data of 57 individuals were mistakenly disclosed to the Intermediaries. 3. The Personal Data Protection Commission found that the Organisation did not have in place a clearly defined process to restart its application and printer servers and a sufficiently robust document ID generation process (such as including a timestamp as part of the document ID) to prevent the duplication of document IDs. In the circumstances the Deputy Commissioner for Personal Data Protection found the Organisation in breach of section 24 of the Personal Data Protection Act 2012 and decided to give a warning to the Organisation. No directions are required as the Organisation implemented corrective measures that addressed the gap in its security arrangements. ",Warning,2eda8279b0e8c55d340038ea44d528dc61b77f48,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,142,142,1,952,A warning was issued to Friends Provident International for failing to protect the personal data of its policyholders from unauthorised disclosure via its online portal.,"[""Protection"", ""Warning"", ""Finance and Insurance""]",2019-09-06,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Ground-of-Decision---Friends-Provident---300719.pdf,Protection,Breach of the Protection Obligation by Friends Provident International,https://www.pdpc.gov.sg/all-commissions-decisions/2019/09/breach-of-the-protection-obligation-by-friends-provident-international,2019-09-06,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 29 Case No DP-1805-B2112 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Friends Provident International Limited … Organisation DECISION Friends Provident International Limited Yeong Zee Kin, Deputy Commissioner – Case No. DP-1805-B2112 30 July 2019 Facts of this Case 1 Friends Provident International Limited is a company established in the Isle of Man which provides life assurance services in Singapore through a registered branch office (the “Organisation”). In the course of providing these services, it operates and maintains an online portal (the “Portal”) through which its policyholders can request for changes to their particulars, for example, contact details. On 10 May 2018, the Organisation notified the Personal Data Protection Commission (the “Commission”) of a data breach incident involving the disclosure of certain personal data of policyholders obtained from the Portal. The circumstances leading to the incident were as follows. 2 The Organisation’s policyholders and certain other authorised personnel could access the Portal via a “Secured Mailbox” webpage on the Organisation’s website (the “Secured Mailbox Webpage”). Policyholders could, as noted above, submit certain requests via the Portal and the Organisation’s authorised personnel accessed the Portal in order to process these requests. For this purpose, the Organisation’s authorised personnel could generate reports containing the data of policyholders who had made a request (“Reports”). These Reports were stored in the Portal and could be obtained thereafter by the Organisation’s authorised personnel. 1 3 The ability to generate and obtain Reports from the Portal was intended to be restricted to the Organisation’s authorised personnel. To achieve this, when a user logged in to the Secured Mailbox Webpage, the system would determine whether the user was one of the Organisation’s authorised personnel or a policyholder. If the user was one of the authorised personnel, a ‘Report’ tab would be displayed in the Secured Mailbox Webpage which enabled the authorised personnel to generate and obtain Reports. The ‘Report’ tab was hidden from the view of policyholders when they accessed the Secured Mailbox Webpage. Apart from hiding the ‘Report’ tab, no additional or separate authorisation was necessary in order to generate and obtain Reports from the Portal and there was no subsequent verification (after the user logged in) as to whether the user was, in fact, authorised to generate and obtain the Reports via the ‘Report’ tab. 4 As a result of a faulty JavaScript within the Secured Mailbox Webpage, the ‘Report’ tab was visible to policyholders when they re-sized their desktop internet browser to a smaller size or if they accessed the Secured Mailbox Webpage via a mobile device. As no verification or separate authorisation was required to access the ‘Report’ tab and generate and obtain Reports, such policyholders were able to generate and obtain Reports from the Portal once the ‘Report’ tab was visible (collectively referred to as the “Vulnerability”). 5 The exploitability of the Vulnerability, which had likely existed since 30 September 2017 when the Secured Mailbox Webpage was introduced, was fortuitously resolved on 6 February 2018 when the Secured Mailbox Webpage was enhanced and backend verification was included. Unfortunately, on 12 December 2017, one of the Organisation’s policyholders discovered that he could generate and obtain Reports from the Portal that contained the names, policy numbers and regions of residence of other policyholders. He subsequently reported this to the Monetary Authority of Singapore which, in turn, notified the Organisation of the incident 2 (the “Reported Breach”). The Organisation had been unaware of the Vulnerability until they were notified of the Reported Breach. 6 The Organisation subsequently determined that before the Vulnerability was fixed, 42 Reports had been produced and downloaded by 21 policyholders or their advisors. The total number of individuals affected by this was estimated to be 240, 11 of whom had their policy numbers disclosed. After the Reported Breach, the Organisation undertook the following as part of its remedial actions: (a) reviewed the Portal to ensure that the Reports were no longer accessible by unauthorised personnel; (b) conducted an initial risk assessment and commenced an immediate investigation into the Reported Breach; (c) imposed a requirement that regression testing must be conducted for mobile devices and different screen resolutions; (d) ensured that backend access validation was in place on top of front-end validation; (e) ensured that all employees received training on data protection upon commencement of employment, which would be refreshed annually; and (f) contacted the policyholder who had generated and downloaded Reports on 12 December 2017 to ensure that he no longer held the Reports that he downloaded. 3 Findings and Basis for Determination 7 Section 24 of the Personal Data Protection Act 2012 (the “PDPA”) requires organisations to protect personal data in their possession or under their control by making reasonable security arrangements to prevent unauthorised access, disclosure and similar risks. I find that the Organisation had not done so, and is in breach of section 24, for two main reasons: first, the manner in which the Organisation restricted access to the Reports was insufficient to prevent unauthorised access to the Reports and the personal data they contained and, secondly, the testing of the Secured Mailbox Webpage was inadequate. 8 On the first point, what is most striking in this case is the lack of an authorisation mechanism for access to the ability to generate and obtain Reports. Once a user gained access to the Secured Mailbox Webpage and could view the ‘Report’ tab (in the circumstances noted above), no further authorisation or verification was required to generate and obtain Reports from the Portal via the ‘Report’ tab. The only means the Organisation employed to limit access to the Reports was to hide the ‘Report’ tab from the view of unauthorised persons. This was insufficient as there could be various ways in which the hidden tab could be revealed, even without the faulty JavaScript, such as by manipulating the scripts or widgets running on the Secured Mailbox Webpage. 9 On the second point, given that the Secured Mailbox Webpage was intended for use across a variety of devices and screens, testing should have been conducted across multiple browsers and devices. While organisations are not expected to test across all possible browsers and devices, testing should have been done on representative devices (in the present case, with different screen or browser sizes) based on the design and intended functionality of the Secured Mailbox Webpage. The Organisation’s failure to do so meant that its testing was ultimately inadequate to address the risk of unauthorised access to the personal data in the Reports. In 4 fact, simply accessing the Secured Mailbox Webpage on a mobile device as part of its tests would have revealed the Vulnerability to the Organisation. Additionally, organisations and developers should note that the testing of other browser conditions such as script blocking, while not mandatory, is highly recommended. In the Organisation’s case, script blocking would also have caused the ‘Report’ tab to become visible. Outcome 10 Taking the totality of the circumstances into account, I have decided to issue a warning to the Organisation for its contravention of section 24 of the PDPA. In reaching this conclusion, I note that: (a) the potential for misuse of the personal data disclosed was relatively low because the data was not of a nature where identity theft could be committed; and (b) the Organisation had promptly notified the Commission and implemented remedial actions upon learning of the Reported Breach. YEONG ZEE KIN DEPUTY COMMISSIONER PERSONAL DATA PROTECTION 5 ",Warning,6578b3c9e72080e89fbcce5011a711485b15a443,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,143,143,1,952,Directions were issued to Avant Logistic Service for failing to make reasonable security arrangements to prevent the unauthorised disclosure of customers' personal data. The lapses resulted in personal data of customers being disclosed by an employee.,"[""Protection"", ""Directions"", ""Wholesale and Retail Trade""]",2019-08-02,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Avant-Logistic-Service-Pte-Ltd---300719.pdf,Protection,Breach of the Protection Obligation by Avant Logistic Service,https://www.pdpc.gov.sg/all-commissions-decisions/2019/08/breach-of-the-protection-obligation-by-avant-logistic-service,2019-08-02,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 28 Case No DP-1802-B1709 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Avant Logistic Service Pte. Ltd. … Organisation DECISION Avant Logistic Service Pte. Ltd. [2019] SGPDPC 28 Yeong Zee Kin, Deputy Commissioner — Case No DP-1802-B1709 30 July 2019 Background 1 On 25 November 2017, a customer of Ezbuy Holdings Ltd. (“Ezbuy”) made a complaint to the Personal Data Protection Commission (the “Commission”) alleging that her personal data had been disclosed to another customer of Ezbuy without her consent by an employee of Avant Logistic Service Pte. Ltd. (the “Organisation”). The facts of this case are as follows. 2 Ezbuy provides an online e-commerce platform that allows its customers to shop for items from various online retailers and platforms around the world. It engaged the Organisation to provide delivery services in Singapore. The Organisation is an affiliate of Ezbuy and its delivery personnel are required to adhere to Ezbuy’s Privacy Policy and the terms and conditions in Ezbuy’s Employee Handbook and Ezbuy’s Delivery and Collection Standard Operation Procedure (“SOP”). 3 When a customer ordered an item through Ezbuy’s platform, they would be offered two modes of delivery, (i) delivery to a designated collection point 1 Avant Logistic Service Pte. Ltd. [2019] SGPDPC 28 (referred to by Ezbuy as “self-collection”), or (ii) delivery to the customer’s address. If the customer opted for self-collection, the customer would proceed to the designated collection point at a specified time. The delivery personnel there would verify their identity using their Ezbuy user ID or their mobile number registered with Ezbuy and then hand over the package with their item. 4 On 9 November 2017, the complainant scheduled to self-collect a package that she ordered from Ezbuy at a collection point in Bishan at around 6.30 p.m. One of the Organisation’s employees (referred to in this Decision as “OA”), was assigned to distribute packages there that evening. When the complainant met OA at the collection point, he gave the complainant two packages (the “Packages”) after verifying her identity. The complainant noticed that the Packages were not hers because they bore the user ID and mobile number of another person (referred to in this Decision as “CA”). According to the complainant, she informed OA of this but was told to take the Packages as they were tagged to her mobile number in the Ezbuy system. The complainant also alleged that OA asked her to inform Ezbuy’s customer service that the wrong packages had been sent to her. The complainant then left the collection point with the Packages. 5 CA arrived to collect the Packages shortly after the complainant left. OA informed her that someone else had already collected the Packages and told her 2 Avant Logistic Service Pte. Ltd. [2019] SGPDPC 28 that he would try to locate them and arrange for their subsequent delivery. At this time, OA did not realise that it was the complainant who had collected the Packages. 6 Later that night, OA sent CA screenshots of two delivery lists containing Ezbuy user IDs and mobile telephone numbers of some Ezbuy customers (the “Disclosed Data”). The first list that was sent contained the Ezbuy user IDs and mobile telephone numbers of eight Ezbuy customers who had been scheduled to collect their packages at Bukit Panjang. (This was apparently sent by mistake.) The second list contained the user IDs of four Ezbuy customers, including that of the complainant, who had been scheduled to collect their packages at Bishan. The telephone numbers in the second list were redacted by OA. However, OA also sent the complainant’s mobile telephone number to CA. OA explained to CA that he suspected that the complainant had collected the Packages because his records showed that the complainant had not collected her own packages. 7 CA eventually managed to find the complainant’s Facebook and Instagram pages using the complainant’s Ezbuy user ID as the complainant had used the same name (which was not her real name) for her Facebook, Instagram and Ezbuy user IDs. CA then sent a series of messages to the complainant via 3 Avant Logistic Service Pte. Ltd. [2019] SGPDPC 28 Facebook Messenger in order to recover the Packages. The complainant subsequently returned the Packages to Ezbuy. Remedial actions by Ezbuy and the Organisation 8 After being informed of the incident by the Commission, Ezbuy and the Organisation jointly undertook the following measures to prevent the unauthorised disclosure of customers’ personal data in the future: (a) All delivery personnel are required to request for both a customer’s user ID and mobile telephone number for verification during the self-collection process; (b) Ezbuy’s Delivery and Collection SOP was updated to comply with the provisions of the PDPA and to highlight the importance of the PDPA. In particular, a clause was added by Ezbuy stating that no customer information can be disclosed to any party under all circumstances, and that any unauthorised disclosure will lead to disciplinary action as listed in Ezbuy’s Employee Handbook; (c) A briefing was conducted to all delivery personnel to reinforce the instruction and policy that no customer’s personal data should be provided to any third party under all circumstances, and this briefing is repeated to all delivery personnel every morning; and 4 Avant Logistic Service Pte. Ltd. (d) [2019] SGPDPC 28 Ezbuy revised its Employee Handbook to include detailed enforcement and disciplinary actions to be taken for breach of confidentiality and employee misconduct, including any leak or sale of customer data. Findings and Basis for Determination Was the Disclosed Data personal data? 9 As a preliminary issue, I find that most of the Disclosed Data was personal data within the meaning of the PDPA. The term “personal data” is defined in section 2(1) of the PDPA as follows: “personal data” means data, whether true or not, about an individual who can be identified – (a) from that data [“Direct Identification”]; or (b) from that data and other information to which the organisation has or is likely to have access [“Indirect Identification”].” 10 The mobile telephone numbers disclosed by OA constitute personal data since they enable Direct Identification of the respective individuals. As explained in the Commission’s Advisory Guidelines on Key Concepts in the Personal Data Protection Act [at 5.9 to 5.10], an individual’s personal mobile 5 Avant Logistic Service Pte. Ltd. [2019] SGPDPC 28 telephone number is a ‘unique identifier’ and capable, on its own, of identifying the individual. 11 On the other hand, since Ezbuy user IDs do not enable Direct Identification, whether they qualify as “personal data” depends on whether they enable Indirect Identification. In this case, CA was able to find the complainant’s Facebook and Instagram pages and identify her using the complainant’s Ezbuy user ID. The complainant’s Ezbuy user ID therefore constitutes personal data under the PDPA, even though the user ID did not contain complainant’s real name, as it enabled Indirect Identification of the complainant. 12 Although organisations cannot be expected to know in advance if the user IDs of their customers enable Indirect Identification, they should not assume that user IDs per se do not constitute personal data as such an assumption may not, in fact, be true (as seen from this case). Organisations should therefore exercise prudence in handling user IDs. As there is no evidence that the other Ezbuy user IDs in the Disclosed Data allowed for Indirect Identification, I grant the Organisation the benefit of the doubt and accept that they do not constitute personal data. Nevertheless, it remains that the personal data of nine individuals (corresponding to the nine mobile telephone numbers 6 Avant Logistic Service Pte. Ltd. [2019] SGPDPC 28 disclosed) was disclosed without their consent or the authorisation of the Organisation. Whether the Organisation had made reasonable security arrangements 13 Section 24 of the PDPA requires organisations to protection personal data in their possession or under their control by making reasonable security arrangements to prevent unauthorised use, disclosure and similar risks. Although the Organisation’s delivery personnel were required to comply with Ezbuy’s Privacy Policy and Employee Handbook, this was, at the time of the incident, inadequate as they did not inform employees of exactly what they were required to do in order to protect customers’ personal data: (a) Ezbuy’s Privacy Policy only stated its commitment to ensuring security of customer information and that “suitable physical, electronic and managerial procedures” had been put in place to safeguard customer information; and (b) Ezbuy’s Employee Handbook only included a provision highlighting that customer information (among others) was confidential. 14 At the time of the incident, the Organisation had not made any effort to impress upon its delivery personnel the need to protect personal data in their possession. The Organisation did not have measures in place, such as policies 7 Avant Logistic Service Pte. Ltd. [2019] SGPDPC 28 or standard operating procedures, to prohibit the unauthorised use or disclosure of personal data by its delivery personnel. The Organisation also had not provided any instruction or training to its delivery personnel on the proper handling of personal data and on compliance with the PDPA. 15 In the course of the Commission’s investigation, the Organisation sought to rely on a clause in OA’s employment contract which prohibited him from disclosing confidential information, including customer information, without the Organisation’s prior consent (the “Confidentiality Clause”). While such clauses are relevant to an organisation’s security arrangements to protect personal data, they are insufficient on their own because they typically do not elaborate on what constitutes personal data, nor how employees should handle and protect it. Organisations are expected to provide their staff with specific, practical instruction on how to handle personal data and comply with the PDPA (Re Hazel Florist & Gifts Pte Ltd [2017] SGPDPC 9 at [18]). This is particularly important for the Organisation’s delivery personnel who frequently handle personal data and are on the frontline of the Organisation’s customer-facing operations where the potential for improper use and disclosure of personal data cannot be ignored. 16 In the circumstances, I find that the Organisation had not made reasonable security arrangements to protect the personal data comprised in the 8 Avant Logistic Service Pte. Ltd. [2019] SGPDPC 28 Disclosed Data. The Organisation is accordingly in breach of section 24 of the PDPA. 17 One additional point I wish to address is that when OA was asked about the incident, he claimed that he had given the complainant the Packages as the complainant had provided him with CA’s Ezbuy user ID and mobile telephone number for verification. As there is no evidence that the complainant and CA were known to each other, I do not find OA’s recollection of the events to be credible or acceptable. In any case, this does not detract from the above conclusion that the Organisation had failed to make reasonable security arrangements as required under section 24 of the PDPA. Outcome 18 Taking the totality of the circumstances into account, I have decided not to impose a financial penalty in this case. In particular, I note that: (a) The breach was a one-off incident, with few affected individuals and relatively little personal data disclosed (comprising the nine mobile telephone numbers and user IDs); (b) The Organisation took prompt remedial actions to prevent a recurrence of such an incident; and 9 Avant Logistic Service Pte. Ltd. (c) 19 [2019] SGPDPC 28 The Organisation was cooperative during investigations. Instead, I have decided to issue the following directions to the Organisation to ensure its compliance with the PDPA: (a) To put in place the appropriate written policies and process safeguards which are necessary for it to protect personal data in its possession or under its control within 30 days from date of this direction; (b) To arrange for personal data protection training for its staff within 60 days from date of this direction; and (c) To inform the Commission in writing of the completion of each of the above within 1 week of completion. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 10 ",Directions,080f1f19619de2e97b442d076d6b4f4a81f71d57,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,144,144,1,952,"A financial penalty of $54,000 was imposed on Horizon Fast Ferry for failing to appoint a data protection officer, develop and implement data protection policies and practices, and put in place reasonable security arrangements to protect the personal data collected from its customers.","[""Protection"", ""Financial Penalty"", ""Transport and Storage""]",2019-08-02,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Horizon-Fast-Ferry---250719.pdf,Protection,Breach of the Protection Obligation by Horizon Fast Ferry,https://www.pdpc.gov.sg/all-commissions-decisions/2019/08/breach-of-the-protection-obligation-by-horizon-fast-ferry,2019-08-02,"COMMISSIONER FOR PERSONAL DATA PROTECTION [2019] SGPDPC 27 Case No DP-1710-B1202 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Horizon Fast Ferry Pte. Ltd. (UEN No. 201221074R) … Organisation DECISION Horizon Fast Ferry Pte. Ltd. [2019] SGPDPC 27 Tan Kiat How, Commissioner — Case No DP-1710-B1202 25 July 2019 1 On 9 October 2017, the Complainant informed the Personal Data Protection Commission (the “Commission”) that by entering her passport number in the booking form on the Organisation’s website, her name, gender, nationality, date of birth and passport expiry date were automatically populated in the corresponding fields on the form on the Booking Site without any requirement for further authentication (the “Incident”). Material Facts 2 The Organisation is a Singapore-based ferry operator with ferry services running between Singapore and Batam. 3 As part of its service offerings, the Organisation operates a website that allows passengers to purchase ferry tickets directly from the Organisation online (“Booking Site”). At the material time, passengers who wanted to purchase ferry tickets through the Booking Site were required to provide the following personal data (the “Personal Data Set”) as set out in the form on the Booking Site (“Booking Form”): (a) the passenger’s full name; (b) gender; (c) nationality; (d) date of birth; (e) passport number; and (f) passport expiry date. 4 The same Personal Data Set was collected from passengers and entered into the Organisation’s Counter Check-In System (“CCIS”) when they checked in at the check-in counter. The CCIS is an internal system used by the Organisation’s counter staff to manage the passenger check-in process and is only accessible by authorised counter staff. 5 As a matter of practice, all Personal Data Sets collected from the Booking Site and the CCIS were stored and retained on the Organisation’s internal database (the “Database”) even after the last travelling date of the passenger’s itinerary to facilitate and speed up subsequent check-ins for passengers who have previously travelled with the Organisation (“Returning Passengers”).1 6 In this regard, one of the features of the CCIS was the auto-retrieval of the personal data of Returning Passengers. By entering a Returning Passenger’s passport number, the CCIS would automatically retrieve the Personal Data Set associated with a Returning Passenger’s passport number from the Database and populate the remaining fields in the Booking Form. Counter staff would no longer need to manually enter the Returning Passenger’s personal data. The personal data retrieved from the Database was only meant to be accessible by authorised counter staff on the CCIS. Booking Site revamp 7 In or around May 2017, the Organisation engaged an independent contractor (the “Contractor”) on an informal basis to revamp the Booking Site, specifically to improve the user interface and user experience, such as when purchasing ferry tickets online. The parties did not enter into any written contract for the revamping of the Booking Site and all instructions and requirements for the revamp of the Booking Site were conveyed either verbally or through WhatsApp text messages. The Organisation did not inform or instruct the Contractor of its data protection obligations in relation to the personal data in the Database. 8 Unbeknownst to the Organisation and contrary to its intention, the Contractor replicated the auto-retrieval and auto-population feature (which was only meant to be used in the internal CCIS) in the Booking Site as part of the website revamp. Consequently, whenever a user entered a passport number which matched a Returning Passenger’s passport number in the 1 The Organisation also represented that the Personal Data Sets were retained on the Database for audit and accounting and internal reporting purposes. Database, the system would automatically retrieve and populate the remaining fields in the Booking Form with the Personal Data Set associated with the Returning Passenger’s passport number. As the Organisation failed to conduct proper user acceptance tests before launching the revamped Booking Site, the Organisation was not aware of this function until it was notified of the Incident. 9 At the time of the investigation, there were a total of 444,000 Personal Data Sets stored in the Database.2 However, the Organisation represented that out of the 444,000 Personal Data Sets, there were only a total of 295,151 unique passengers whose Personal Data Sets were stored in the Database as a number of passengers had made bookings under different passport numbers (valid and expired).3 10 The Organisation took the following remedial actions shortly after it was notified of the Incident: (a) the Organisation commenced investigations and removed the auto-retrieval and auto-population feature from the Booking Site a little more than a week after the Organisation was first notified of the Incident; (b) the Organisation conducted checks to ensure that the auto-retrieval and auto- population feature was disabled from the Booking Site; and (c) the Organisation implemented administrative measures to protect the personal data in their possession, such as ensuring that documents containing booking data and passenger manifests were properly shredded at the end of the day, that monthly reports with passenger data were kept in a locked room and sent for mass disposal at the end of the financial year and the Organisation appointed a data protection officer to be responsible for ensuring the Organisation’s compliance with the PDPA. Findings and Basis for Determination 11 2 The two main issues for determination are: Approximately three months after the date of the Complaint, on 12 December 2017. Other than the Personal Data Sets, some users also supplied their mobile phone numbers. There were 5,218 unique mobile numbers collected and stored in the Database as at 12 December 2017. 3 (a) whether the Organisation complied with its obligations under sections 11(3) and 12(a) of the PDPA; and (b) 12 whether the Organisation breached section 24 of the PDPA. The Personal Data Sets stored in the Database are “personal data” as defined in section 2(1) of the PDPA. In particular, given that the unauthorised disclosure of the Personal Data Set as a whole could have led to an increased risk of such personal data being used for illegal activities such as identity theft or fraud, they are personal data of a more sensitive nature.4 Whether the Organisation complied with its obligations under sections 11(3) and 12(a) of the PDPA 13 Section 11(3) of the PDPA requires an organisation to designate one or more individuals to be responsible for ensuring compliance with the PDPA. In a similar vein, section 12(a) of the PDPA requires an organisation to develop and implement policies and practices that are necessary to meet its obligations under the PDPA (collectively, the “Openness Obligation”). 14 As mentioned above, all passengers who purchased ferry tickets from the Organisation were required to provide the personal data in the Personal Data Set to the Organisation either at the time of booking through the Booking Site or at the Organisation’s check-in counter. 15 However, even though the Organisation routinely collected and processed large volumes of personal data in the course of its business, the Organisation demonstrated a blatant disregard for its data protection obligations. 16 By its own admission, at the time of the Incident, the Organisation did not designate any individual to be responsible for ensuring that the Organisation complies with the PDPA, i.e. a data protection officer (“DPO”). The Organisation’s current DPO was only appointed after 6 November 2017, when the Organisation was first informed of the Incident. 17 Similarly, the Organisation’s privacy policy was only implemented and uploaded on its Booking Site after it was informed of the Incident. While the Organisation represented that it 4 See Re: Singapore Management University Alumni Association [2018] SGPDPC 6 at [20] had an internal guideline titled “Workplace policies: confidentiality” in place at the time of the Incident, apart from a reference to its commitment to “[e]stablish data protection practices (e.g. secure locks, data encryption, frequent backups, access authorization)”, the internal guidelines do not set out any actual practices or processes to protect the personal data in the Organisation’s possession. 18 The development and implementation of data protection policies is a fundamental and crucial starting point for organisations to comply with their obligations under the PDPA. This was highlighted in Re M Star Movers & Logistics Specialist Pte Ltd [2017] SGPDPC 15 (at [25]) (“M Star Movers”): At the very basic level, an appropriate data protection policy should be drafted to ensure that it gives a clear understanding within the organisation of its obligations under the PDPA and sets general standards on the handling of personal data which staff are expected to adhere to. To meet these aims, the framers, in developing such policies, have to address their minds to the types of data the organisation handles which may constitute personal data; the manner in, and the purposes for, which it collects, uses and discloses personal data; the parties to, and the circumstances in, which it discloses personal data; and the data protection standards the organisation needs to adopt to meet its obligations under the PDPA. An overarching data protection policy will ensure a consistent minimum data protection standard across an organisation’s business practices, procedures and activities (e.g. communications through social media). 19 Likewise, the DPO plays a vital role in building a robust data protection framework to ensure the organisation’s compliance with its obligations under the PDPA regardless of the size of the organisation.5 20 As highlighted in M Stars Movers (at [34]), the responsibilities of a DPO include, but are not limited to: (a) ensuring compliance with the PDPA when developing and implementing policies and processes for handling personal data, including processes and formal procedures to handle queries and/or complaints from the public; (b) fostering a data protection culture and accountability among employees and communicating personal data protection policies to stakeholders; 5 M Stars Movers at [37]. (c) handling and managing personal data protection related queries and complaints from the public, including making information about the organisation’s data protection policies and practices available on request to the public; (d) alerting management to any risks that might arise with regard to personal data; and (e) liaising with the Commissioner on data protection matters, if necessary. 21 In the circumstances, it is clear that the Organisation failed to meet its obligations under sections 11(3) and 12(a) of the PDPA. Had the Organisation met its Openness Obligation under the PDPA, the Organisation would have had a clearer understanding of its data protection obligations under the PDPA and appropriate measures may have been put in place earlier which could have prevented the Incident from occurring. Whether the Organisation breached the Protection Obligation under the PDPA 22 As a preliminary point, although the Contractor appears to have been responsible for carrying out the Booking Site revamp, seeing as the parties did not enter into any written agreement and there was no evidence to suggest that the Contractor stored, held or managed the personal data in the Database on behalf of the Organisation, the Contractor is not a data intermediary of the Organisation. The Organisation is solely responsible for complying with all the data protection obligations under the PDPA, including the obligation to make reasonable security arrangements to protect the personal data in its possession or under its control under section 24 of the PDPA. 23 At the time of the Incident, the Database was shared by the Booking Site and the CCIS. However, the Organisation conceded that it omitted to inform the Contractor of its data protection obligations and did not instruct the Contractor to put in place proper safeguards to protect the personal data in the Organisation’s possession or control. 24 In this regard, one of the key considerations for organisations as highlighted in the Guide on Building Websites for SMEs (at [4.2.1]) is the importance of emphasising the need for personal data protection to their IT vendors: Organisations should emphasise the need for personal data protection to their IT vendors, by making it part of their contractual terms. The contract should also state clearly the responsibilities of the IT vendor with respect to the PDPA. When discussing the scope of outsourced work, organisations should consider whether the IT vendor’s scope of work will include any of the following: 25  Requiring that IT vendors consider how the personal data should be handled as part of the design and layout of the website.  Planning and developing the website in a way that ensures that it does not contain any web application vulnerabilities that could expose the personal data of individuals collected, stored or accessed via the website through the Internet.  Requiring that IT vendors who provide hosting for the website should ensure that the servers and networks are securely configured and adequately protected against unauthorised access.  When engaging IT vendors to provide maintenance and/or administrative support for the website, requiring that any changes they make to the website do not contain vulnerabilities that could expose the personal data. Additionally, discussing whether they have technical and/or non-technical processes in place to prevent the personal data from being exposed accidentally or otherwise. Even more concerning was the fact that the Organisation did not put in place reasonable arrangements to discover risks to its personal data when changes were made to the Booking Site that was linked to the Database which held the personal data of close to 300,000 individuals. The Organisation did not conduct any proper user acceptance testing prior to the launch of the revamped Booking Site. The only test that the Organisation carried out was to key in a simulated passport number to test the new user interface. However, as the simulated passport number did not match any record in the Database, the Organisation failed to detect the auto-retrieval and population feature in the revamped Booking Site. 26 Websites connected to the Internet are subject to a multitude of cyber threats that may compromise the website and expose any personal data it collects. Organisations should therefore ensure that the protection of the personal data and the security of the website is a key design consideration at each stage of the website’s life cycle – be it during the requirements gathering, design and development stage or when conducting user acceptance testing or deployment and operations and support.6 27 As a result of the Organisation’s failure to conduct proper user acceptance tests, the gap in the revamped Booking Site which allowed for the unauthorised access to personal data stored 6 See PDPC’s Guide on Building Websites for SMEs at [3.2] to [3.3]. in the Database went undetected. This was not rectified for approximately one month, thereby causing the personal data of close to 300,000 of the Organisation’s passengers to be exposed to the risks of unauthorised disclosure. 28 As a matter of good practice, organisations should consider whether there is a need to conduct a data protection impact assessment whenever a new system or process is being introduced, developed or implemented that involves the handling of personal data or an existing system or process is being reviewed or substantially redesigned.7 29 In this regard, the Guide to Data Protection Impact Assessments (published on 1 November 2017) (at [1.2]) states that: A [Data Protection Impact Assessment] involves identifying, assessing and addressing personal data protection risks based on the organisation’s functions, needs and processes. In doing so, an organisation would be better positioned to assess if their handling of personal data complies with the PDPA or data protection best practices, and implement appropriate technical or organisational measures to safeguard against data protection risks to individuals. 30 In adopting this view, the Commissioner agrees with the observations in the Joint Guidance Note issued by the Office of the Privacy Commissioner of Canada, the Office of the Information and Privacy Commissioner of Alberta and the Office of the Information and Privacy Commissioner for British Columbia on the proper use of risk assessment tools for all new projects involving personal information:8 Privacy risks evolve over time. Conducting risk assessments, at least on an annual basis, is an important part of any privacy management program to ensure that organizations are in compliance with applicable legislation. We have seen instances of organizations offering new services that collect, use or disclose personal information that have not been thoroughly vetted from a privacy perspective. Proper use of risk assessment tools can help prevent problems. Fixing a privacy problem after the fact can be costly so careful consideration of the purposes for a particular initiative, product or service, and an assessment that minimizes any privacy impacts beforehand is vital. See PDPC’s Guide to Data Protection Impact Assessments. Office of the Privacy Commissioner of Canada, Office of the Information and Privacy Commissioner of Alberta and the Office of the Information and Privacy Commissioner for British Columbia, Getting Accountability Right with a Privacy Management Program 7 8 As a result, such assessments should be required throughout the organization for all new projects involving personal information and on any new collection, use or disclosure of personal information. Organizations should develop a process for identifying and mitigating privacy and security risks, including the use of privacy impact assessments and security threat risk assessments. [Emphasis added.] 31 In view of the above and the Organisation’s failure to put in place adequate security arrangements to protect the personal data in the Database, the Commissioner finds that the Organisation was in breach of the Protection Obligation under section 24 of the PDPA. 32 Finally, although the Organisation did not intend to offer the auto-retrieval and auto- population function in its Booking Site, organisations that do offer such functions should take note of the following comments made by the UK Information Commissioner’s Office (“ICO”) in the Personal Information Online Code of Practice on the use of auto-completion facilities for forms and passwords: If your site offers auto-completion facilities for forms and passwords, it is good practice to notify users if this could leave them vulnerable, for example if their mobile device or laptop is stolen. However, ultimately users have a role to play in protecting themselves online, for example by adjusting the auto-complete settings on their browser or on a website they visit. Autocompletion can present a particular risk where an individual’s payment card details have been retained for ‘auto-fill’ purposes. This may mean not offering auto-completion in certain contexts – e.g. on password fields for authorising payments. [Emphasis added.]] Directions 33 Having found that the Organisation is in breach of sections 11(3), 12(a) and 24 of the PDPA, the Commissioner is empowered under section 29 of the PDPA to give the Organisation such directions as he deems fit to ensure compliance with the PDPA. This may include directing the Organisation to pay a financial penalty of such amount not exceeding S$1 million. 34 In deciding whether to direct an organisation to pay a financial penalty, one of the Commissioner’s key objectives is to promote compliance with the PDPA. As such, while the Commissioner will seek to ensure that the financial penalty imposed is reasonable and proportionate on the facts, the financial penalty should also be sufficiently meaningful to act both as a sanction and as a deterrent to prevent similar contraventions of the PDPA. 35 In this regard, as highlighted in the Advisory Guidelines on Enforcement of the Data Protection Provisions (at [24.1]) the Commissioner will take into account factors such as the seriousness and impact of the organisation’s breach and will consider if the organisation had acted deliberately, wilfully or if the organisation had known or ought to have known of the risk of a serious contravention and failed to take reasonable steps to prevent it. 36 In adopting this view, the Commissioner agrees with the ICO’s Guidance About the Issue of Monetary Penalties Prepared and Issued Under section 55C(1) of the Data Protection Act 1998 (“ICO Guidance on Monetary Penalties”) (at [34] to [37]): The Commissioner’s aim in imposing a monetary penalty The Commissioner’s underlying objective in imposing a monetary penalty notice is to promote compliance with the DPA or with PECR. The penalty must be sufficiently meaningful to act both as a sanction and also as a deterrent to prevent non-compliance of similar seriousness in the future by the contravening person and by others. This applies both in relation to the specific type of contravention and other contraventions more generally. Here, the Commissioner will have regard to the general approach set out in paragraphs 42 to 46 below. The Commissioner will seek to ensure that the imposition of a monetary penalty is appropriate and the amount of that penalty is reasonable and proportionate, given the particular facts of the case and the underlying objective in imposing the penalty. 37 With the foregoing principles in mind, the Commissioner took into account the following aggravating and mitigating factors in assessing the breach and determining the directions to be imposed: Aggravating factors (a) the Organisation routinely collects and processes the personal data of a large number of individuals in the course of its business but did not have adequate data protection policies or practices in place; (b) the Personal Data Sets in collected and stored in the Database, such as the individual’s nationality, passport number and passport expiry date, are of a sensitive nature particularly when disclosed as a whole. In this regard, attention is drawn to the decision in Re: Singapore Management University Alumni Association [2018] SGPDPC 6 (“SMU AA”) at [20] where it was stated that “the use of an NRIC Number generation tool would make it relatively easy for a motivated hacker to systematically query the webpage and, if successful, he would have been able to definitively link the NRIC Number to the full name, address and other personal data of the member, potentially resulting in significant harm to the individual, such as through identity theft or an unauthorised person impersonating the affected member”; (c) the Organisation demonstrated a blatant lack of regard for its data protection obligations prior to the Incident. Despite the fact that the PDPA came into full force on 2 July 2014 and advisory guidelines and/or guides which are relevant to the contravention were available, the Organisation only appointed a DPO more than three years after the PDPA came into full force and appears to have ignored or not given these guidelines and/or guides the appropriate weight; (d) as a result of the Organisation’s lack of regard for its data protection obligations, the personal data of at least 295,151 of the Organisation’s passengers were exposed to the risks of unauthorised disclosure; Mitigating factors (e) the Organisation had cooperated fully in the investigation and was forthcoming and transparent in admitting its mistakes in contributing to the unauthorised disclosure; (f) remedial actions were taken and the Organisation took increased efforts to heighten employees’ awareness of the Organisation’s data protection obligations under the PDPA; (g) there was no evidence to suggest any actual unauthorised access and/or exfiltration of data leading to loss or damage; and (h) there was limited disclosure to possibly one individual who would have had to enter a Returning Passenger’s passport number that matched the passport number in the Database. 38 The Organisation submitted representations, after being informed of the proposed decision in this case, requesting a warning in lieu of a financial penalty or otherwise to reduce the quantum of the financial penalty imposed. In support of this, the Organisation made the following representations: (a) The Organisation asserted that the revamped Booking Site was only operational in or around October 2017, and the auto-retrieval and auto-population feature was only accessible to users (other than the authorised counter staff) from October 2017 to 14 November 2017. Thus, the Personal Data Sets were only at risk of unauthorised disclosure for this period of time; (b) The Organisation did not deliberately nor wilfully breach the PDPA and upon notification of the Incident, the Organisation took remedial actions 9 and was cooperative during the investigations, and (c) The risk of unauthorised disclosure is low as an individual would need to possess the exact passport number to trigger the auto-complete feature which would disclose the corresponding Personal Data Set. 39 With respect to the issue raised in paragraph 38(a), the Commissioner accepted the clarifications as to the period of time for which the Personal Data Sets were at risk of unauthorised disclosure, and the quantum of the financial penalty has been adjusted accordingly. 40 With regards to paragraph 38(b), the remedial actions taken by the Organisation and the fact that the Organisation was cooperative during the investigations, have already been taken into account as mitigating factors at paragraphs 37(e) and 37(f) above in determining the appropriate quantum of the financial penalty. Also, the deliberateness or wilfulness of the Organisation in breaching the PDPA is not a relevant consideration in this case where it was 9 Including those set out in paragraph 10. found that the Organisation failed to put in place the necessary security arrangements to protect the Personal Data Set. 41 With regards to paragraph 38(c) above, these are matters that had already been taken into consideration in assessing the financial penalty and as set out at paragraphs 37(g) and 37(h) above . 42 Having considered all the relevant factors of this case, the Commissioner hereby direct the Organisation to pay a financial penalty of S$54,000 within [30] days from the date of this direction, failing which, interest, at the rate specified in the Rules of Court in respect of judgment debts, shall be payable on the outstanding amount of such financial penalty. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION ",Financial Penalty,22d8a5e1622926675d2f3bece9bfea120e5cb7a8,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,145,145,1,952,"A financial penalty of $16,000 was imposed on Genki Sushi for failing to put in place reasonable security arrangements to protect personal data of its employees. The incident resulted in the data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B"", ""Food"", ""F&B""]",2019-08-02,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Genki-Sushi---220719.pdf,Protection,Breach of the Protection Obligation by Genki Sushi,https://www.pdpc.gov.sg/all-commissions-decisions/2019/08/breach-of-the-protection-obligation-by-genki-sushi,2019-08-02,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 26 Case No DP-1809-B2684 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Genki Sushi Singapore Pte. Ltd. … Organisation DECISION Genki Sushi Singapore Pte. Ltd. [2019] SGPDPC 26 Genki Sushi Singapore Pte. Ltd. [2019] SGPDPC 26 Tan Kiat How, Commissioner — Case No DP-1809-B2684 22 July 2019 Background 1 On 7 September 2018, Genki Sushi Singapore Pte. Ltd. (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that a server on the Organisation’s network which stored the personal data of its employees, among other information, had been the target of a ransomware attack. This attack resulted in the unauthorised encryption of the employee personal data hosted on that server and the Organisation being subjected to a ransom demand (the “Incident”). The Commission commenced an investigation in order to determine whether the Organisation had failed to comply with its obligations under the Personal Data Protection Act 2012 (the “PDPA”). Material Facts 2 The Organisation is a sushi chain restaurant. As part of its internal operations, it used an off-the-shelf payroll software application, “TimeSoft”, which was developed and licensed to it by Times Software Pte Ltd (“Times”). The TimeSoft application included a web portal and a database. The web portal was used by (a) employees to view their electronic payslips and (b) supervisors at the various restaurants to confirm the attendance of their employees during 1 Genki Sushi Singapore Pte. Ltd. [2019] SGPDPC 26 the designated hours. The database contained the personal data of the Organisation’s former and current employees (“Employee Data Files”). The TimeSoft application was hosted on a local server belonging to the Organisation (the “Server”). The Server also contained financial data files (e.g. financial statements and details on the Organisation’s dealings with its vendors). 3 On 30 August 2018, the Organisation’s IT personnel discovered that the Server was unresponsive. Following internal investigations, the Organisation confirmed that the Server had been subjected to a ransomware attack, resulting in most of its hosted files (including the Employee Data Files) being encrypted with a “.bip” extension and their contents being inaccessible to the Organisation. A ransom payment was demanded from the Organisation in exchange for the decryption key. Based on its investigations, the Organisation suspected that the Server was infected by the “Dharma” variant of ransomware that had been installed on the Server through its internet link. 4 The Incident resulted in the unauthorised modification of the Organisation’s data (including the Employee Data Files) as the encryption by the ransomware replaced the original plaintext with ciphertext (which was unreadable without the proper cipher to decrypt it). The following types of personal data belonging to approximately 360 current and former employees of the Organisation were affected by the unauthorised modification: (a) name; (b) NRIC number, if the employee was a Singaporean; (c) Foreign Identity Number (“FIN”) and application date, if the employee was a foreigner; 2 Genki Sushi Singapore Pte. Ltd. 5 [2019] SGPDPC 26 (d) bank account information, i.e., bank and branch information; (e) gender; (f) marital status; (g) date of hire; (h) date of birth; and (i) salary details. The Incident also affected the following types of personal data for some of the Organisation’s current or former employees (who had these types of data stored in the Server): (a) passport number; (b) address; (c) telephone number; (d) mobile phone number; (e) names of relatives; (f) emergency contact person’s name and relationship with the employee; and 3 Genki Sushi Singapore Pte. Ltd. (g) 6 [2019] SGPDPC 26 country of birth. There was no evidence of the encrypted personal data files being subjected to exfiltration or unauthorised disclosure. 7 Upon discovery of the Incident, the Organisation immediately took the following steps to contain and mitigate the effects of the Incident: (a) isolated the Server from its larger IT network; (b) performed anti-virus scans on each computer in the Organisation’s office and restaurants; (c) attempted, albeit unsuccessfully, to remove the ransomware and decrypt the infected data files using third party security tools; and (d) to the best of its ability, notified its affected employees of the Incident. In this regard, all full-time employees and most parttime employees were notified by 7 September 2018. The Organisation was unable to notify its affected former employees due to their contact details being encrypted by the ransomware. 8 The Organisation subsequently also took the following steps to prevent the recurrence of the Incident: (a) replaced the Server with a new server that was isolated in a “demilitarised zone” within the Organisation’s IT network; 4 Genki Sushi Singapore Pte. Ltd. (b) [2019] SGPDPC 26 introduced the following safeguards to protect the personal data in the new server: (i) encrypting the TimeSoft application’s database; (ii) setting the server’s firewall security policy to allow traffic only via Hyper Text Transfer Protocol Secure or through required service ports; (iii) enabling an intrusion prevention system on the firewall; (iv) installing TrendMicro OfficeScan XS anti-virus software on the new server, with the intent of subsequently upgrading this software to TrendMicro Deep Security after improvements to the Organisation’s overall enterprise IT structure are completed; (v) (c) enabling audit logging on the new server; engaged an external vendor to provide security operation centre services, whereby the vendor would monitor the network and server logs and look out for any potential malicious activities on the new server; and (d) engaged an IT security vendor to assist with updating the Server’s operating system, managing patches for the Server, and conducting regular IT vulnerability assessments. Findings and Basis for Determination 9 The main issue for determination is whether the Organisation breached section 24 of the PDPA. Section 24 of the PDPA requires an organisation to 5 Genki Sushi Singapore Pte. Ltd. [2019] SGPDPC 26 protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. 10 As a preliminary point, it is noted that, during the material time, the Organisation was responsible for the maintenance of the Server, while Times was in charge of providing technical support for the TimeSoft application, such as maintaining its web portal and database, as well as troubleshooting the application. Times provided its technical support on an ad hoc basis via remote access granted by the Organisation. During this process, the Organisation’s IT personnel would supervise the activities of Times to ensure that there was no unauthorised access to, or collection of, the personal data hosted on the Server. Accordingly, Times did not have any control or possession of the personal data hosted on the Server. In any event, the Incident did not relate to the scope of Times’ services rendered to the Organisation. As such, the Commissioner found that only the Organisation was in possession and control of the personal data, including the Employee Data Files, hosted on the Server during the material time. 11 To determine whether the Organisation was in breach of section 24, the relevant question is whether it had put in place reasonable security arrangements to safeguard the personal data hosted on the Server. The Commission’s Advisory Guidelines on Key Concepts in the PDPA (revised 27 July 2017) (at [17.2]) provide the following examples of factors that are taken into consideration in assessing the reasonableness of an organisation’s security arrangements: (a) the nature of the personal data; 6 Genki Sushi Singapore Pte. Ltd. (b) [2019] SGPDPC 26 the form in which the personal data has been collected (e.g. physical or electronic); and (c) the possible impact to the individual concerned if an unauthorised person obtained, modified or disposed of the personal data. 12 In assessing the security arrangements adopted by the Organisation, the Commissioner considered that the Employee Data Files included sensitive personal data in the form of NRIC numbers, FINs, passport numbers, bank account details and salary details. In this regard, it bears repeating what was stated in Re Aviva Ltd [2018] SGPDPC 4 at [17]: “All forms or categories of personal data are not equal; organisations need to take into account the sensitivity of the personal data that they handle. In this regard, the Commissioner repeats the explanation in Re Aviva Ltd [2017] (at [18]) on the higher standards of protection that should be implemented for sensitive personal data: The Advisory Guidelines on Key Concepts in the PDPA states that an organisation should “implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of sensitivity”. This means that a higher standard of protection is required for more sensitive personal data. More sensitive personal data, such as insurance, medical and financial data, should be accorded a commensurate level of protection. In addition, the Guide to Preventing Accidental Disclosure When Processing and Sending Personal Data expressly states that documents that contain sensitive personal data 7 Genki Sushi Singapore Pte. Ltd. [2019] SGPDPC 26 should be “processed and sent with particular care”.” [Emphasis added.] 13 It should also be borne in mind that NRIC numbers are of special concern as they are “a permanent and irreplaceable identifier which can be used to unlock large amounts of information relating to the individual” (Re Habitat for Humanity Singapore Ltd [2018] SGPDPC 9 at [19]) 14 The standard of security arrangements expected in relation to IT systems was elaborated upon in Re The Cellar Door Pte Ltd and Global Interactive Works Pte Ltd [2016] SGPDPC 22 (“Re The Cellar Door”) at [29]; “reasonable security arrangements” for IT systems must be sufficiently robust and comprehensive to guard against a possible intrusion or attack: “Another important aspect of a “reasonable security arrangement” for IT systems is that it must be sufficiently robust and comprehensive to guard against a possible intrusion or attack. For example, it is not enough for an IT system to have strong firewalls if there is a weak administrative password which an intruder can “guess” to enter the system. The nature of such systems require there to be sufficient coverage and an adequate level of protection of the security measures that are put in place, since a single point of entry is all an intruder needs to gain access to the personal data held on a system. In other words, an organisation needs to have an “all-round” security of its system. This is not to say that the security measures or the coverage need to be “perfect”, but only requires that such arrangements be “reasonable” in the circumstances.” [Emphasis added.] 8 Genki Sushi Singapore Pte. Ltd. 15 [2019] SGPDPC 26 In this case, the Organisation had failed to put in such “all-round” security of its system which is accessible via the Internet by all of its branches, and which contained sensitive personal data of its employees, e.g. NRIC/FIN and passport numbers, bank account details. The Commission’s investigations revealed the following significant gaps in the security measures implemented in relation to the Server during the Incident: (a) first, the Organisation initially did not have a firewall for the Server and, even after a firewall had been installed following its recent IT migration pursuant to its business re-organisation, it failed to configure the Server’s firewall to filter out unauthorised traffic and close unused ports; (b) second, the Organisation did not conduct periodic penetration tests to assess the overall security of its IT infrastructure and bolster the effectiveness of its defensive mechanisms and determine what measures (including patches) may be required to fix vulnerabilities; and (c) Third, the Organisation failed to ensure that the Server and the TimeSoft application were regularly patched. 16 As regards the failure in paragraph 15(a), although the Server was kept in a secure physical location with physical access only granted to authorised personnel, the same level of precaution had not been implemented for virtual or remote access. There was no firewall for a while, and even when installed, the Server’s firewall was not configured to block any unused ports or unauthorised traffic at all material times. In other words, the Server’s firewall was ineffective at filtering out any external threats. 9 Genki Sushi Singapore Pte. Ltd. 17 [2019] SGPDPC 26 In its response to the Commission’s queries, the Organisation had explained that the lack of configuration for the firewall was because the Organisation had recently undergone a full IT migration and its IT team was waiting for the IT infrastructure to be refreshed before configuring the appropriate firewall settings. Pending this refresh, it had not configured any firewall setting as the Organisation did not have any server firewall before the IT migration and therefore no pre-existing configuration it could use for the firewall in the interim period. Thus, there was effectively no firewall in place during the relevant period. 18 The Commissioner reiterates what was said in Re The Cellar Door (at [30(a)] and [30(b)]) that “a firewall is fundamental to the security of the server to protect against an array of external cyber threats” and “leaving unused ports on a server open increases the risk of an external hacker exploiting the services running on these ports”. In this case, the firewall was not configured to close any ports. 19 As regards the failures in paragraphs 15(b) and 15(c), the Organisation admitted that it did not conduct any penetration tests on the Server within the last 12 months prior to the Incident. The Organisation was also unable to provide evidence that it had done any patching on the Server during the same period. This suggests that the Organisation did not have any processes in place to ensure regular security testing and patching of its IT systems. 20 The Commissioner emphasises that regular security testing and patching are important security measures. Patching is one of the common tasks that all system owners are required to perform in order to keep their security measures current against external threats. Moreover, as stated in the Commission’s Guide 10 Genki Sushi Singapore Pte. Ltd. [2019] SGPDPC 26 to Securing Personal Data in Electronic Medium (revised 20 January 2017) at [16.3] and [16.4]: “Vulnerabilities discovered [in software] are often published, hence cyber attackers are well aware of vulnerabilities available for exploiting. It is therefore important for organisations to keep their software updated or patched regularly to minimise their vulnerabilities.” 21 Generally, organisations should, to the extent possible, test and apply updates and security patches as soon as they are available to the relevant components (e.g. network devices, servers, database products, operating systems, applications, software libraries, programming frameworks and firmware) of the Organisation’s IT system. There should also be processes and people responsible to monitor new patches and updates that become available with respect to such components. In this regard, the arrangement with Times for maintenance and technical support of the TimeSoft application was inadequate. 22 The failures highlighted above contributed to a system that had a number of vulnerabilities and gaps that a hacker could easily exploit. In this case, the ransomware may have successfully exploited these gaps to reach the Employee Data Files and the other files on the Server. For a server that held sensitive personal data, the security measures implemented by the Organisation were inadequate. In fact, the standard of protection provided was not even sufficient for non-sensitive personal data. 23 For the reasons above, the Commissioner finds the Organisation in breach of section 24 of the PDPA. 11 Genki Sushi Singapore Pte. Ltd. [2019] SGPDPC 26 Representations by the Organisation 24 In the course of settling this decision, the Organisation made representations on the amount of financial penalty which the Commissioner intended to impose. The Organisation raised the following factors for the Commissioner’s consideration: (a) There was no evidence that the personal data had been subjected to exfiltration, unauthorised disclosure or modification; (b) The Organisation did not pay the ransom amount to positively discourage and disincentivise unauthorised and criminal behaviour by the ransomware attacker; and (c) The Incident occurred during the period where the Organisation’s new management was in the midst of the IT migration and the strengthening of the IT infrastructure. 25 The Commissioner has decided to maintain the financial penalty set out at [29] for the following reasons: (a) As explained at [4], there had been unauthorised modification to personal data belonging to approximately 360 current and former employees of the Organisation. In determining the quantum of financial penalty, the Commissioner had already taken into consideration that there was no evidence of the encrypted Employee Data Files being subjected to exfiltration or unauthorised disclosure. 12 Genki Sushi Singapore Pte. Ltd. [2019] SGPDPC 26 (b) Notwithstanding that there was criminal activity on the part of the ransomware attacker, the finding of section 24 breach relates to the Organisation’s own failings to put in place reasonable security measures. As such, whether the ransom amount is paid is not a mitigating factor. (c) A transition to a new management team does not lower the standard expected of an organisation to protect personal data in its possession and/or control. Notwithstanding that the Organisation was in the midst of IT migration and strengthening of IT infrastructure, it was obliged to put in place reasonable security measures to protect the Employee Data Files at all times. These are therefore not mitigating factors. In any event, as stated at [15], the Commission’s investigations revealed that the Organisation did not have adequate security measures in place for the Server even before the IT migration. The Commissioner’s Directions 26 Given the Commissioner’s findings that the Organisation is in breach of section 24 of the PDPA, the Commissioner is empowered under section 29 of the PDPA to issue the Organisation such directions as he deems fit to ensure its compliance with the PDPA. This may include directing the Organisation to pay a financial penalty of such amount not exceeding $1 million. 27 In determining the directions, if any, to be imposed on the Organisation in this case, the Commissioner took into account the following mitigating factors: 13 Genki Sushi Singapore Pte. Ltd. (a) [2019] SGPDPC 26 the Organisation voluntarily notified the Commission of the breach; (b) the Organisation fully cooperated with the Commission’s investigations; and (c) the Organisation took prompt action to mitigate the effects of the breach. 28 The Commissioner also took into account, as an aggravating factor, that the failure to make reasonable security arrangements to protect the personal data led to a loss of control over the Employee Data Files, which contained sensitive personal data. 29 Taking into account the above mitigating and aggravating factors, the Commissioner hereby directs the Organisation to pay a financial penalty of $16,000 within 30 days from the date of this direction, 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 it is paid in full. 30 The Commissioner has not set out any further directions for the Organisation given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 14 ",Financial Penalty,2ce401cead0de35fee05185836541ed0903e6dff,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"