_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-11-12T17:45:22+08:00,e73bd1da8813cb4506688ee114b4ae1198ccbe07,265,241,1,955,"A financial penalty of $10,000 was imposed on Ascentis for failing to put in place reasonable security arrangements to protect individuals' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Admin and Support Services""]",10 Nov 2023,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Ascentis_12092023.pdf,Protection,Breach of the Protection Obligation by Ascentis,https://www.pdpc.gov.sg/all-commissions-decisions/2023/10/breach-of-the-protection-obligation-by-ascentis,2023-11-10,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 10 Case No. DP-2209-C0193 / DP-2209-C0217 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Ascentis Pte. Ltd. … Organisation DECISION 1 Ascentis Pte. Ltd. Wong Huiwen Denise, Deputy Commissioner - Case No. DP-2209-C0193 / DP2209-C0217 12 September 2023 Introduction 1 On 13 September 2022, the Personal Data Protection Commission (the “Commission”) was notified by the Singapore Computer Emergency Response Team that the personal data of 332,774 individuals had been exfiltrated from an eCommerce platform (the “Platform”) owned by Starbucks Coffee Singapore Pte Ltd (“Starbucks SG”) and offered for sale online (the “Incident”). 2 The Commission commenced investigations to determine whether the circumstances of the Incident disclosed any contraventions of the Personal Data Protection Act 2012 (“PDPA”). For the reasons set out below, the Commission determined that the developer of the Platform, Ascentis Pte Ltd (“the Organisation”) had contravened section 24 of the PDPA (“the Protection Obligation”) in the context of the Incident. 3 The Organisation requested and agreed for the investigation to be handled under the Commission’s Expedited Breach Decision Procedure, and voluntarily provided and admitted to the facts set out below. The Organisation also admitted that 2 it had failed to implement reasonable security arrangements to protect the personal data exfiltrated during the Incident, in breach of the Protection Obligation. 4 The Commission also accepted a voluntary undertaking from Starbucks SG pursuant to section 48L(1)(a) of the PDPA for Starbucks SG to implement enhanced security arrangements to improve its compliance with the PDPA1. No further enforcement action was taken against Starbucks SG. Facts of the Case The CRM System and CRM Database 5 The Organisation is in the business of developing, providing and integrating software solutions for Customer Relationship Management and eCommerce. 6 On 19 December 2014, Starbucks SG engaged the Organisation to develop, implement, support, and host a Customer Relationship Management system (the “CRM System”) to support Starbucks SG’s “My Starbucks Rewards” loyalty program (the “Rewards Program”). 7 When an individual signed up as a member of the Rewards Program, their personal data including name, email address, telephone number, and birth date was collected and stored on a cloud database (the “CRM Database”). 1 A copy of Starbucks SG’s voluntary undertaking is available at https://www.pdpc.gov.sg/Undertakings. 3 The Project for development of the Platform 8 On 14 September 2020, Starbucks SG engaged the Organisation to separately develop and provide, as well as render ongoing technical support for, the Platform, an online store for the sale and purchase of products offered by Starbucks SG (“the Project”). 9 In turn, on 1 January 2021, the Organisation engaged one Kyanon Digital Co. Ltd (“Kyanon”), a company based in Vietnam in the business of software development and provision, to provide additional manpower and software development support to the Organisation for its execution of the Project. 10 One of Starbucks SG’s requirements for the Project was for a Rewards Program member’s personal data to be auto-completed in electronic forms on the Platform, such that the member would not have to manually key in his/her personal data to complete a transaction on the Platform. 11 The personal data of Rewards Program members was originally only stored on the CRM Database (and not on the Platform). In order to make it more convenient for members to use the Platform, the Organisation implemented a process to automatically synchronise a member’s personal data from the CRM Database to the Platform whenever an individual logged in as a member on the Starbucks SG website and then visited the Platform. This synchronisation occurred in real-time. Once the 4 synchronisation was complete, the member’s personal data would exist separately in a database within the Platform. Both the CRM Database and the database within the Platform were hosted and operated independently. Kyanon’s involvement in the Project 12 Despite Kyanon’s engagement, the Organisation maintained control and management of, and had direct involvement in, the Project. The leader of the team delivering the Project (the “Project Team”), was an employee of the Organisation, while the remaining personnel comprising the Project Team were employees of Kyanon (the “Kyanon Employees”) 13 The Kyanon Employees were provided with accounts to the Platform with full administrative privileges (the “Admin Accounts”). These enabled the Kyanon Employees to support, check and perform configuration of the Platform, troubleshoot any technical problems, and check if data received on the Platform had been synchronised correctly. The Admin Accounts also granted rights to Kyanon Employees to export data from the Platform (the significance of which is discussed below). Prior to the Incident, the Admin Accounts did not require multi-factor authentication (“MFA”). 14 One of the Kyanon Employees, “Peter”, left the employ of Kyanon in May 2022. He handed over the credentials to his Admin Account (“Peter’s Admin Account”) to the remaining members of the Project Team via a shared Google Sheet. Despite the cessation of Peter’s employment with Kyanon, Peter’s Admin Account was not 5 disabled. Rather, the Kyanon Employees changed the password of Peter’s Admin Account to “Kyanon@123456”, updated the shared Google Sheet with the new password, and continued using Peter’s Admin Account among themselves. The Incident 15 Sometime between 10 and 13 September 2022, a malicious actor used Peter’s Admin Account to gain access to the Platform, where the personal data of those Rewards Program members who had previously logged into the Platform was stored. The Organisation was not able to determine the exact method by which the malicious actor gained access to Peter’s Admin Account; it was possibly through the abovementioned shared Google Sheet. The malicious actor granted other accounts administrative privileges, performed data gathering, and exported the gathered data to an external email address. 16 In total, the personal data of 332,774 individuals stored in the Platform comprising names, email addresses, dates of birth, membership details relating to the Rewards Program, last login dates to the Platform, the physical addresses of 181,875 individuals, and the telephone numbers of 310,560 individuals (“Subject Data”) was exfiltrated in the Incident. 17 The Subject Data was subsequently advertised for sale on an online forum on the dark web. The Commission was notified of the same by the Singapore Computer Emergency Response Team on 13 September 2022. Starbucks SG and the 6 Organisation submitted data breach notifications to the Commission on 15 and 16 September 2022, respectively. Remedial Actions 18 After being notified of the Incident, the Organisation took remedial actions which included: (a) Activating an emergency response team and establishing an investigation team (including an external cybersecurity firm) to investigate the Incident; (b) Disabling access to the Platform by all accounts, validating all Platform accounts, and resetting all administrator accounts; (c) Blocking the malicious actor’s IP address in the Platform firewall; (d) Mandating that all vendors, including Kyanon, perform full anti-virus and malware scans, and provide reports of these scans to the Organisation before resuming work; and (e) Implemented MFA for all its accounts. 7 Findings and Basis for Determination Whether the Organisation had contravened the Protection Obligation 19 Under the Protection Obligation, an organisation must 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 disposal, or similar risks. 20 The Protection Obligation also applies to data intermediaries2. A data intermediary is defined under section 2(1) of the PDPA as “an organisation which processes personal data on behalf of another organisation but does not include an employee of that other organisation”. In turn, the “processing” of personal data is defined as: “in relation to personal data, means the carrying out of any operation or set of operations in relation to the personal data, and includes any of the following: 2 3 (a) recording; (b) holding; (c) organisation, adaptation or alteration; (d) retrieval; (e) combination; (f) transmission; (g) erasure or destruction;”3 Section 4(2) of the PDPA. Section 2(1) of the PDPA. 8 21 As the developer and host of the CRM System and the Platform, the Organisation processed personal data (including the Subject Data) in the CRM Database and the Platform on Starbucks SG’s behalf. Accordingly the Organisation was a data intermediary of Starbucks SG and was subject to the Protection Obligation in respect of the Subject Data. 22 The reasonableness of an organisation’s security arrangements would be assessed having regard to the volume and sensitivity of such personal data and the possible impact of a data breach. As stated in the Commission’s Advisory Guidelines on Key Concepts in the Personal Data Protection Act (revised 16 May 2022) (“Advisory Guidelines”) at paragraphs 17.3(a) and (b), 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; … c) implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of security …” 23 Additionally, as stated in the Commission’s Guide to Data Protection Practices for ICT Systems (“ICT Systems Guide”) at page 8: 9 “For organisations that hold large quantities of different types of personal data or data that might be more sensitive to the individuals or the organisations, they should additionally implement the relevant enhanced practices suggested in each section. 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.” 24 In the present case, having regard to the large volume of personal data hosted in the Platform, reasonable security arrangements to protect the Subject Data were not implemented. The Commission sets out the reasons for this finding in the paragraphs below. In particular, the Organisation failed to disable Peter’s Admin Account after he was no longer working on the Project. 25 In the ICT Systems Guide, the Commission recommends at page 15 that organisations should, as a basic practice, conduct “Regular review of user accounts to ensure that all the accounts are active and the rights assigned are necessary (i.e. remove user accounts when a user has left the organisation or update the user’s rights when he/she has changed his/her role within the organisation).” (emphasis added in bold). 26 In this case however, the Organisation did not disable Peter’s Admin Account after he left the employ of Kyanon but permitted its continued use by Kyanon Employees. While Peter was an ex-employee of Kyanon and not of the Organisation, 10 it was nevertheless (by the Organisation’s own admission) the Organisation itself which retained responsibility for the development and management of the Platform, including the creation and management of administrator accounts. The Organisation admitted that the failure to disable Peter’s Admin Account was a “lapse” on its part, and further admitted that it failed to create new accounts for the Kyanon Employees who took over Peter’s duties. 27 The failure to disable Peter’s Admin Account was exacerbated by the fact that the account was not protected with a sufficiently complex password. Having taken over Peter’s Admin Account, the Kyanon Employees changed the password to “Kyanon@123456” (the “New Password”). The Organisation informed the Commission that the New Password met the Platform’s password complexity requirements, namely that passwords be at least 8 characters in length, have at least 1 upper and 1 lower case letter, at least 1 special character, and not be a repeat of the account’s previous 5 passwords. 28 The Commission has made clear in previous enforcement decisions that mere technical compliance with password complexity requirements is not good enough if the password remains guessable4. Although the New Password complied with the Platform’s password complexity requirements, it incorporated the name “Kyanon” and 4 Re Chizzle Pte Ltd [2020] SGPDPR 1 at [5(d)]. 11 a sequential series of digits (“123456”). This made the New Password easily guessable and insecure. 29 Further, the sharing of credentials for Peter’s Admin Account via a shared Google Sheet meant that anyone who obtained access to the said Google Sheet could gain access to Peter’s Admin Account. As the Commission has stated in the ICT Systems Guide at page 16, an organisation should “[h]ave clear policies that prohibit the sharing of passwords such as admin credentials”. Such sharing posed a heightened risk of unauthorised access especially if a malicious actor was familiar with Peter’s user ID. 30 The Organisation stressed to the Commission that passwords for accounts to the Platform were hashed, and that the Organisation was unaware of the New Password. Further, the Organisation stated that Peter’s Admin Account was used by Kyanon Employees and not the Organisation’s employees, and that the New Password was set by the Kyanon Employees using Peter’s Admin Account. 31 While the immediate cause for the weak New Password and insecure sharing of the credentials for Peter’s Admin Account may have been the Kyanon Employees, the Organisation could have managed this better by specifying clearer data protection requirements to Kyanon as part of its involvement in the Project, including in relation to account management. 12 32 While the Master Services Agreement between the Organisation and Kyanon dated 1 January 2021 did impose broad data protection obligations on Kyanon, it did not mandate any specific measures in relation to account management, beyond stating that “secure authentication and authorisation processes” were to be implemented. 33 In addition, Kyanon had provided the Organisation with a signed Letter of Undertaking in which Kyanon undertook to comply with “the standards in relation to personal data protection, including those required under the Personal Data Protection Act (No. 26 of 2012) of Singapore (the “PDPA Policy”)”, the Organisation’s Security and Services Guide, and the Organisation’s Personal Data Handling and Measures. However, these documents did not specify any specific requirements for the disabling of ex-employee accounts. 34 Taking into consideration the above, the Commission finds the Organisation in breach of the Protection Obligation for failing to disable Peter’s Admin Account after Peter was no longer a Kyanon employee. Observations on other data protection practices 35 Separate to the above finding (which the Organisation admitted to), the Commission sets out observations on two other data protection practices which, if implemented, could have prevented the unauthorised disclosure of personal data in the Incident even if Peter’s Admin Account had not been disabled. For the avoidance 13 of doubt, these observations are made solely to provide guidance, and (i) do not constitute additional findings of breaches of the Protection Obligation by the Organisation in this case, or (ii) factor in any way in the Commission’s final decision in this case. Scoping of rights assigned to Admin Accounts 36 All Admin Accounts assigned to Kyanon Employees were granted rights to export data from the Platform, even though such rights may not have been necessary for their work on the Project. 37 As stated in the ICT Systems Guide (page 15) and paragraph 25 above, the Commission recommends regular review of user accounts to ensure that only the necessary rights are assigned. The Commission has previously found organisations in breach for failing to carry out such review.5 Implementation of MFA for Admin Accounts 38 The level of privileges granted to all Admin Accounts created a heightened risk that large volumes of personal data could be exfiltrated from the Platform if an Admin Account was compromised. This risk was exacerbated by the fact that the Admin Account did not require MFA. In Lovebonito Singapore Pte. Ltd. [2022] SGPDPC 3, the Commission made clear that MFA should be implemented as a baseline 5 RedMart Limited [2022] SGPDPC 8 at [19]. 14 requirement for administrative accounts with access to confidential or sensitive personal data or large volumes of personal data.6 39 In this case, the Organisation explained that while it had plans to implement MFA for the Admin Accounts (as part of unified access controls), these plans were delayed due to manpower shortages caused by the COVID-19 pandemic. 40 While the Commission recognises the business difficulties brought on by the COVID-19 pandemic, implementation of MFA for the Admin Accounts could nevertheless have been given greater priority considering the volume of personal data accessible from the Platform, and the associated heightened data protection risks. 41 It was not necessary for the Commission to make breach findings in relation to the above two data protection practices in this case. However, the Commission will not hesitate to find organisations in future enforcement cases in breach of the Protection Obligation for failing to implement the same – particularly in cases involving unauthorised use of administrative accounts with access to sensitive or large volumes of personal data. 6 Lovebonito Singapore Pte. Ltd. [2022] SGPDPC 3 at [51]. 15 The Commission’s Decision 42 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 Commission took into account the factors listed at section 48J(6) of the PDPA. 43 The Commission notes that the personal data of 332,774 individuals was affected in the Incident and that this largely consisted of basic contact and account membership information. 44 The Commission also recognises that: (a) the Organisation was cooperative with the Commission’s investigations; (b) the Organisation took prompt remedial actions to address the Incident; (c) the Organisation has not previously been found to have breached the PDPA; and (d) the Organisation had voluntarily accepted responsibility for the Incident, thus facilitating the expeditious investigation and resolution of this case through the Commission’s expedited breach procedure. 16 45 Having considered all the relevant factors in this case, the Commission hereby requires the Organisation to pay a financial penalty of $10,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. 46 No further directions are necessary on account of the remedial measures already taken by the Organisation. WONG HUIWEN DENISE DEPUTY COMMISSIONER PERSONAL DATA PROTECTION 17 ",Financial Penalty,441daf2d082c67ef00a31a74d3bbd15b659147a5,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-11-12T17:45:22+08:00,e73bd1da8813cb4506688ee114b4ae1198ccbe07,266,242,1,955,"A financial penalty of $82,000 was imposed on Tokyo Century Leasing for failing to put in place reasonable security arrangements to protect individuals' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Finance and Insurance"", ""Vulnerability""]",10 Nov 2023,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Tokyo_Century_Leasing_040923.pdf,Protection,Breach of the Protection Obligation by Tokyo Century Leasing,https://www.pdpc.gov.sg/all-commissions-decisions/2023/10/breach-of-the-protection-obligation-by-tokyo-century-leasing,2023-11-10,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 9 Case No. DP-2206-B9897 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Tokyo Century Leasing (Singapore) Pte. Ltd. … Organisation DECISION Page 1 of 14 Tokyo Century Leasing (Singapore) Pte. Ltd. Lew Chuen Hong, Commissioner - Case No. DP-2206-B9897 4 September 2023 Introduction 1 On 14 June 2022, the Personal Data Protection Commission (the “Commission”) was notified by Tokyo Century Leasing (Singapore) Pte. Ltd. (the “Organisation”) of a ransomware attack which resulted in the encryption of the personal data of 141,412 individuals (“Incident”). 2 The Organisation requested that the investigation be handled under the Commission’s Expedited Breach Decision Procedure. 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 encrypted during the Incident, in breach of section 24 of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 3 The Organisation is in the leasing and hire-purchase business. It operates a website through which existing or potential customers may submit applications to enter into hire-purchase or leasing agreements. Page 2 of 14 4 On 12 June 2022, the Organisation was notified by a customer that he was unable to submit an online application. The Organisation conducted an internal investigation and discovered that 7 servers and 6 employee computers had been infected with ransomware, resulting in the encryption of the personal data of 141,412 individuals, comprising: a) 111,156 customers whose personal data consisted of name, NRIC number, date of birth, address, contact number, income statement, email address, employer information, bank account, and additionally for foreign customers, their passport numbers and employment pass numbers; b) 30,220 guarantors whose personal data consisted of name, NRIC number, date of birth, address, contact number, income statement, email address, employer information, and bank account; and c) 36 employees whose personal data consisted of name, NRIC number, date of birth, address, contact number, email address, bank account, resume information, and medical check-up information. (collectively the “Subject Data”) 5 The Subject Data was encrypted by a virus with the extension “.myghost”. The Organisation also discovered a ransom note instructing the Organisation to contact “apichai[@]keemail.me” or “teeraanu[@]tuta.io” to obtain the decryption key, failing Page 3 of 14 which the Subject Data would be leaked. The ransom note did not specify a ransom amount. The Organisation did not respond to the ransom note. 6 The Organisation notified the Commission of the Incident on 14 June 2022. On 8 July 2022, the Organisation requested that the investigation be handled under the Commission’s Expedited Breach Decision Procedure, and in a statement by its Managing Director dated 29 July 2022, admitted to a breach of section 24 of the PDPA. 7 Investigations were conducted between 14 June 2022 and October 2022, comprising the efforts of an IT forensic investigation firm engaged by the Organisation’s parent organisation, and the Commission’s own investigations. The investigations revealed that: a) A malicious encryption programme “Stager.exe” had been executed on at least 3 servers by a compromised administrator account through Remote Desktop Connections;1 b) The IP address of each of the Remote Desktop Connections was generated by a FortiGate 100E Virtual Private Network (“VPN”) and firewall device (“Device”) in use by the Organisation since September 2019; c) The software installed on the Device was the outdated version 6.0.4 of FortiOS and had a known vulnerability CVE-2018-13379 (“Vulnerability”).2 1 A Remote Desktop Connection refers to the connection and control by a user to a target device (such as a computer) remotely through the internet or other network. 2 This is the same vulnerability that may have been exploited in the data breach incident which is the subject of the Commission’s decision in The Law Society of Singapore [2023] SGPDPC 4. Page 4 of 14 The effect of the Vulnerability was that a malicious actor could, via the internet, remotely access system files on the Device, specifically “sslvpn_websession”, containing the username and password of a VPN session. With such details, the malicious actor would be able to gain access to the VPN to which the target’s (in this case, the Organisation) devices were connected; d) The most likely cause of the Incident was that malicious actor(s) exploited the Vulnerability, thereby gaining access to the Organisation’s VPN. The malicious actor(s) in turn compromised one of the Organisation’s administrator accounts, gaining access to the Subject Data stored on the Organisations servers and computers. However, no evidence was discovered to indicate that the Subject Data had been exfiltrated; e) The Device’s manufacturer released a patch in May 2019 to address the Vulnerability,3 but the patch had not been installed by the time of the Incident. The Organisation informed the Commission that while its IT vendor had the responsibility of upgrading the Organisation’s firewall, such upgrading / patching was only triggered upon request by the Organisation. However, the Organisation was unaware of the patch, did not have processes in place to manage software patches, and therefore did not request its IT vendor to patch the Vulnerability; and Fortinet, Inc, “FortiOS system file leak through SSL VPN via specially crafted HTTP resource requests” (FortiGuard Labs, 24 May 2019) accessed 23 March 2023. 3 Page 5 of 14 f) The Organisation had not implemented Multi-Factor Authentication (“MFA”) for its administrator accounts at the time of the Incident. Remedial Action 8 After the Incident, the Organisation took the following remedial actions: a) Reported the Incident to the Singapore Police Force and the Commission, within 72 hours of the discovery by the Organisation of the same; b) Published a notice of the Incident on its website, and engaged an external call centre to provide hotline services to affected customers; c) Conducted anti-virus scans on all its computers; d) Engaged an IT forensic investigation firm to scan and monitor the internet for the Subject Data. The IT forensic investigation firm did not detect any disclosure of the same on the internet; e) Patched the Vulnerability and its Windows systems; f) Changed the passwords for its administrator accounts for all its servers and critical network equipment; and g) Implemented MFA for access to its VPN. Page 6 of 14 Findings and Basis for Determination Whether the Organisation had contravened the Protection Obligation 9 Under section 24 of the PDPA an organisation must 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 disposal, or similar risks (the “Protection Obligation”). 10 The reasonableness of an organisation’s security arrangements to protect personal data would be assessed having regard to the volume and sensitivity of such personal data and the possible impact of a data breach. As stated in the Commission’s Advisory Guidelines on Key Concepts in the Personal Data Protection Act (revised 17 May 2022) (“Advisory Guidelines”) at paragraphs 17.3(a) and (b), 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; … c) implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of security …” 11 In the present case, the Subject Data comprised a large volume of sensitive personal data affecting 141,412 individuals. Such data included names, NRIC numbers, bank account information and income statements. Given the nature of such Page 7 of 14 personal data, there was a heightened risk of identity theft and/or financial loss, which called for a higher standard of security arrangements. 12 For the reasons set out below the Commission determines that the Organisation failed to implement reasonable security arrangements to protect the Subject Data, in breach of the Protection Obligation. In particular, the Organisation failed to: a) Conduct regular monitoring for software patches; b) Implement processes to manage software patches and upgrades; and c) Implement MFA for its administrator accounts. Failure to conduct regular monitoring for software patches 13 The importance of conducting regular monitoring for software patches, and more generally testing the vulnerability of info-communications and technology (“ICT”) systems, has been stressed repeatedly by the Commission. 14 In Commeasure Pte Ltd [2021] SGPDPC 11, the Commission highlighted at paragraph 14 that it was necessary for organisations to conduct regular reviews and monitoring of their ICT systems, which would include monitoring for software patches and updates. 15 The Commission has also made clear at page 27 of its Guide to Data Protection Practices for ICT Systems, that as a basic measure, organisations ought to “conduct Page 8 of 14 regular ICT monitoring, alerts, security audits, scan and tests to detect vulnerabilities and non-compliance with organisational standards.” 16 However, the Organisation failed to conduct regular monitoring for software patches for the software on the Device. The Device (with the Vulnerability) had been in use by the Organisation since September 2019, more than 3 months since the Device’s manufacturer had released the patch in May 2019. The Vulnerability remained un-patched for a period of almost 3 years thereafter until the Incident occurred. The Organisation admitted that it was unaware of the patch until after the Incident and that it did not conduct regular monitoring for software patches. Had the Organisation conducted regular monitoring for software patches, it would have learned of the patch for the Vulnerability. 17 Accordingly, the Commission finds the Organisation in breach of the Protection Obligation for its failure to conduct regular monitoring for software patches to the software on the Device. Failure to implement processes to manage software patches and upgrades 18 The Organisation’s failure to conduct regular monitoring for software patches underscores the importance for organisations to implement processes to manage the same. 19 As noted at paragraph 7(e) above, software patching was done on an ad-hoc basis by the Organisation’s IT vendor on the instructions of the Organisation. However, as the Organisation failed to monitor for software patches, it was unaware of the Page 9 of 14 available patch for the Vulnerability, and did not instruct the IT vendor to install the patch. 20 Based on the Organisation’s clarifications to the Commission, it is likely that the Organisation assumed that its IT vendor would monitor for software patches even though the Organisation’s contract with its IT vendor did not contain any requirements for the IT vendor to conduct regular monitoring. The Organisation failed to properly apply its mind to the issue of regular monitoring, as this was not contained in the contract between the Organisation and its IT vendor. 21 In its Checklists to Guard Against Common Types of Data Breaches, the Commission recommends at page 6 that organisations should, as a basic practice, “Develop an ICT policy that covers the critical aspects in IT security such as account and access control, password, email, IT risk management, asset and configuration, backup and recovery, hardening and patching.” 22 While the Commission does not prescribe the specific terms of such ICT policies and/or processes, the Organisation could, for example, have implemented processes by which the Organisation or its IT vendors were automatically notified of available software patches, or reminded on a periodic basis to conduct checks for software patches. Further, the contract between the Organisation and its IT vendor could have specifically included an obligation for the IT vendor to conduct regular monitoring for patches, without the need for the Organisation to request patching on an ad-hoc basis. However, the Organisation failed to implement any such processes to manage software patches and upgrades. Page 10 of 14 23 For completeness, the Organisation provided the Commission with copies of its Internal Data Protection Policy and its Compliance Handbook. However, neither document sets out any processes to manage software patches and upgrades. 24 Accordingly, the Commission finds the Organisation in breach of the Protection Obligation for its failure to implement processes to manage software patches and upgrades. Failure to implement MFA for administrator accounts 25 The Organisation also failed to implement MFA for its administrator accounts. 26 In its decision in Lovebonito Singapore Pte. Ltd. [2022] SGPDPC 3 published on 19 May 2022 (i.e. before the Incident), the Commission made clear that MFA was to be implemented as a baseline requirement for accounts with access to confidential or sensitive personal data or large volumes of personal data: “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. Page 11 of 14 (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.”4 (emphasis added in bold) 27 However, the Organisation failed to implement MFA for its administrator accounts despite these accounts having access to confidential and sensitive personal data.5 The Organisation did not furnish any explanation as to why such failure was reasonable or that the implementation of MFA would have been disproportionate. 28 Accordingly, the Commission finds the Organisation in breach of the Protection Obligation for its failure to implement MFA for its administrator accounts. 29 The Commission notes that the present case and the first tier of the approach in Lovebonito Singapore Pte. Ltd. [2022] SGPDPC 3 (reproduced at paragraph 25 above) deal specifically with administrator accounts. However, where an account is 4 See Lovebonito Singapore Pte. Ltd. [2022] SGPDPC 3 at [51]. “Sensitive” personal data includes, but is not limited to, NRIC/Passport numbers, financial information, and medical information. See the Commission’s previous decisions in Aviva Ltd [2017] SGPDPC 14 at [17] and in Genki Sushi Singapore Pte. Ltd. [2019] SGPDPC 26 at [12] and [13]. 5 Page 12 of 14 not an administrator account, but 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, the Commission encourages 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. The Commission’s Decision 30 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 Commission took into account the factors listed at section 48J(6) of the PDPA. 31 The Commission notes that the data breach affected 141,412 individuals whose personal data, of a highly sensitive nature, was encrypted. Further, the patch for the Vulnerability had been available for a lengthy period of 2 years and 9 months from the time the Organisation first started using the Device until the Incident, but was not installed during that time. The Organisation had also failed to implement MFA for its administrator accounts. 32 The Commission nevertheless recognises the following mitigating factors: a) the Organisation was cooperative with the Commission’s investigations; b) the Organisation took prompt remedial actions to address the Incident; and Page 13 of 14 c) the Organisation had voluntarily accepted responsibility for the Incident, thus facilitating the expeditious investigation and resolution of this case through the expedited breach procedure. 33 Having considered all the relevant factors in this case, the Commission hereby requires the Organisation to pay a financial penalty of $82,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. 34 No further directions are necessary on account of the remedial measures already taken by the Organisation. WONG HUIWEN DENISE DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION Page 14 of 14 ",Financial Penalty,41811af89a1fdebb1b8589e37ec87b3ff0bdc6f9,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"