_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,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""]"