postimage

    11:57 PM Joshua Kow (CIPP/A, LL.B. (Hons), National University of Singapore)?Kenji Lee (CIPP/A, Law Undergraduate, National University of Singapore)

    Technical Measures for Reasonable Security Arrangements under the PDPA – A Roadmap

        

    Introduction

    In this age of rapid technological advancement and digitisation, privacy and data protection issues have become increasingly visible and relevant to the average consumer. Legal penalties aside, the destructive power of high-profile data breaches or hacks on public confidence is also well-documented. Hefty fines may be paid, and CEOs may publicly apologise, but battered corporate reputations take months—if not years—to heal.

    In a Straits Times article titled “Privacy watchdog fines 22 in past two years over security breaches” published on 3 January 2018, Senior Tech Correspondent Irene Tham observed that “nearly every fine issued by the Personal Data Protection Commission (“PDPC”) centred around the same type of offence - inadequate security measures for personal data.” Further, a review of the PDPC’s recent enforcement decisions, such as Re Social Metric Pte Ltd [2017] SGPDPC 17 (“Social Metric”), Re ComGateway (S) Pte Ltd [2017] SGPDPC 19 (“ComGateway”), and Re Orchard Turn Developments Pte Ltd [2017] SGPDPC 12 (“Orchard Turn”) reveals that such breaches are, more often than not, technical in nature.

    In light of the above, this article aims to demystify the process of achieving technical compliance with the Personal Data Protection Act (Act No. 26 of 2012) (“PDPA”) through the use of a roadmap. This will be achieved in three parts. First, we review the current regulatory framework under the PDPA and the various security measures available for compliance. Second, we discuss technical measures in detail, in the form of a roadmap referencing the aforementioned decisions. Finally, we conclude with a summary of our views.

    The Regulatory Framework

    The PDPA contains nine main obligations which organisations are required to comply with if they undertake activities relating to the collection, use or disclosure of personal data. These are the (i) Consent; (ii) Purpose Limitation; (iii) Notification; (iv) Access and Correction; (v) Accuracy; (vi) Protection; (vii) Retention Limitation; (viii) Transfer Limitation; and (ix) Openness Obligations respectively. This article focuses solely on the Protection Obligation as enshrined in s. 24 PDPA.

     

    s. 24 PDPA states 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.” Two points are relevant to understanding the legal obligation imposed by this provision:

    First, reading the phrases “reasonable security arrangements” and “in its possession or under its control” together, it becomes clear that organisations need not implement excessive, unnecessary arrangements to the detriment of their business. Rather, the PDPC’s Advisory Guidelines on Key Concepts in the PDPA (revised on 27 July 2017) (“Advisory Guidelines”) states (at [17.3(a)]) that security arrangements should, in practice, “fit the nature of the personal data held by the organisation and the possible harm that might result from a security breach” Similarly, the PDPC’s Guide to Securing Personal Data in Electronic Medium (revised 20 January 2017) (“Electronic Medium Guide”) advises (at [2.4]) the adoption of security measures which are “reasonable and appropriate for their circumstances” in relation to the type, form, and risk and breach impact of the personal data in possession or control. Therefore, while Singapore does not adopt a legally-defined class of “sensitive” personal data (as in India or the Philippines) entitled to greater protection, it would nevertheless be prudent to arrange for greater security measures in respect of certain sensitive datasets, whose breach could result in greater impact to the individual (e.g. highly confidential employee appraisals).

    Second, recent enforcement decisions on s. 24 PDPA reveal that not every data breach immediately results in a finding of non-compliance. Indeed, the fact that “personal data had been rendered accessible to an unauthorised party by an error or flaw in an organisation’s systems and processes does not automatically mean that the organisation is liable [...] for failing to take reasonable security arrangements to protect personal data.” (ComGateway at [19]) Notably, while the organisation in ComGateway had committed two separate data breaches, it was only found liable for the latter, as reasonable security arrangements were made for the former. A finding of non-compliance, therefore, is a fact-specific exercise which takes into account the reasonableness of the arrangement in relation to the breach. The reasonableness of the arrangement would be construed with reference to, inter alia, the specific measures that comprise it—the Advisory Guidelines state (at [17.5]) that security arrangements may “take various forms such as administrative measures, physical measures, technical measures or a combination of these” (emphasis added). The Advisory Guidelines also provide non-exhaustive lists of each form of measure which may be implemented by organisations.

    Technical Measures - A Roadmap to Compliance

    Despite being referred to in the Advisory Guidelines, “technical measures” are not defined in both the PDPA and the PDPC’s Guidelines. However, the Advisory Guidelines provide examples including, inter alia, computer network and application security, encryption of personal data, implementation of appropriate access controls, and ensuring that outsourced IT service providers can provide the requisite standards of IT security. Technical measures may therefore be contrasted with administrative or physical measures, in that they deal directly with the system or network directly securing the personal data.

    In light of the many options and combinations of technical measures available, we provide a sequential, three-stage roadmap to technical compliance comprising: (a) security by design; (b) properly-scoped technical measures; and (c) maintenance and upkeep. This roadmap will be discussed with reference to the aforementioned decisions.

    Social Metric - Security by Design

    Social Metric epitomises the importance of security by design. In that decision, the organisation was a digital marketing agency which created webpages containing the personal data of its clients’ customers for marketing campaigns.  A number of such webpages containing the personal information of approximately 558 individuals were left exposed to the Internet, without any security or access controls such as basic password protection. The Commissioner found that s. 24 PDPA had been breached, as any member of the public could have accessed these webpages directly.

    The facts of Social Metric are not extraordinary—many businesses conducting online lead generation or promotion increasingly rely on public-facing websites to reach their target audience. Yet, if these are built without basic technical measures from the onset, then personal data hosted on them become immediately vulnerable to compromise. Indeed, the PDPC’s Guide on Building Websites for SMEs (revised on 20 January 2017) (“Website Guide”) states at [3.3] that website security is a “key design consideration at each stage of the website’s life cycle” and, where outsourced to an external vendor, the organisation should “emphasise the need for personal data protection [...] by making it part of their contractual terms.” On the facts of Social Metric, the organisation claimed that it had outsourced the building and maintenance of its website to “freelance developers located in the Philippines” [at 37(d)], but failed to provide any evidence of the claim. Presumably, the organisation did not provide any evidence that it had conveyed the necessary obligations in a written agreement, or that it had instructed its developers on access control implementation.

    Organisations whose websites or web applications have been outsourced would also do well to conduct pre-launch vulnerability assessments and code reviews, to identify and remediate potential vulnerabilities before publication. These could be done with reference to, for example, the Open Web Application Security Project (“OWASP”) Application Security Verification Standard (“ASVS”), a standardised basis for testing application technical security controls, or the OWASP Top Ten, an annual compilation of the most critical security risks to web applications each year. The results of such tests could also provide guidance on further technical measures to implement.

    ComGateway - Properly-scoped Technical Measures

    Of course, not all breaches involve a complete lack of technical security—non-compliance may also arise where the implemented measures do not address the underlying vulnerability, as was the case in ComGateway. In that case, the organisation was a company which provided logistics, shopping, and shipping services to its customers via an electronic system and web application which processed, tracked and managed shipping and transaction orders. On 29 November 2016, two breaches were reported to the PDPC. First, that one customer had accessed the personal data of another, in the form of shipping details, when she accessed a shipping details page on the website; and second, that the shipping details website could be manipulated to reveal other customers’ details by changing the last character in the Uniform Resource Locator (“URL”) query string.

    In finding the organisation liable for the second but not the first breach, the Commissioner noted (at [34]) that while certain measures went towards the prevention of the first breach (e.g. regular “Trustwave” vulnerability scans, annual penetration tests, managed firewall applications, risks assessments and automated code reviews), “none of [them] address the URL manipulation vulnerability” in the second breach. Essentially, notwithstanding the wide range of measures implemented, the website was still found to possess a glaringly-obvious vulnerability. Specifically, he found that the query string values were not actually encrypted, but merely functions of shipment date encoded in Base64, which could be “easily decoded through publicly available decoding tools”, or even manipulated by ordinary users by replacing the last character of the URL.

    In addition to reaffirming the importance of security by design (at [32]), ComGateway emphasises that implemented measures must address the vulnerabilities of the system. The facts of ComGateway are unusual, as query string manipulations are common and should have been picked up by the organisation’s automated OWASP Top Ten code checks (at [7]), which expressly flag broken access controls as key security risks. Furthermore, OWASP ASVS requirements 4.4 and 4.16 require developers or security testers to “verify that access to sensitive records is protected, such that only authorized objects or data is accessible to each user (for example, protect against users tampering with a parameter to see or alter another user's account)”, and to “verify that the application correctly enforces context-sensitive authorisation so as to not allow unauthorised manipulation by means of parameter tampering.” This raises questions about whether the organisation actually understood the measures it implemented, and whether they were properly-scoped by the organisation and its external consultants jointly.

    In addition to understanding their own system architecture, organisations should understand how specific measures function in order to appropriately select and scope them for implementation. For example, OWASP project leader Daniel Miessler provides a succinct introduction to the methodological differences between vulnerability assessments and penetration tests—the former seeks to identify and prioritise a list of vulnerabilities through a “white box” approach, whereas the latter is goal-oriented and performed primarily in respect of a “target” identified by the client. Returning to ComGateway, it is conceivable that the details on the shipping details page were not designated as targets for annual penetration testing, or that the vulnerability scans simply did not include access control vulnerabilities as part of their scope.

    Orchard Turn - Maintenance and Upkeep

    Even if a system is securely-designed, and properly-scoped technical measures are implemented, the constant discovery of new vulnerabilities over time could render them vulnerable to compromise. Therefore, the importance of regular maintenance and upkeep to an organisation’s overall security strategy cannot be overstated, as malicious attackers can easily take advantage of unpatched vulnerabilities to access operating systems, servers and web applications to gain unauthorised access to personal data.

    In Orchard Turn, the organisation was a retail mall manager which also ran a loyalty programme for mall purchases. This programme was run using a system created by an outsourced IT vendor, and personal data of the programme’s subscribers was stored on it for the purpose of sending email updates through a web application. On 26 December 2015, an unknown perpetrator gained access to the web application, accessed the subscriber list, and sent phishing emails to the programme’s 24,913 subscribers. Although the PDPC could not establish the root cause of the breach (at [23]), it nevertheless found several issues with system’s security posture which could have enabled the attack. One crucial issue, inter alia, was that the organisation failed to follow a regular operating system patching cycle, and was only patched ad-hoc every two to four months. Unsurprisingly, a post-breach check revealed 24 known vulnerabilities inherent in the system.

    The Commissioner’s findings are unsurprising, as patching is a “common [task] that all system owners have to perform in order to keep its security measures current against external threats” (at [38]). In fact, the Advisory Guidelines identify (at [17.5]) the “updating [of] computer security and IT equipment regularly” as a technical measure in and of itself. A fortiori, an organisation’s omission to patch a known vulnerability puts it at greater risk of exploitation, as malicious actors would similarly have knowledge of it. Therefore, system administrators should “[t]est and apply updates and security patches as soon as they are available to relevant components of the organisation’s [IT] systems” (Electronic Medium Guide at [16]) in accordance with a recognised patch management methodology, and consistently monitor alerts and advisories on critical flaws from trusted sources, such as the United States Computer Emergency Readiness Team (“US-CERT”) and the Singapore Computer Emergency Response Team (“SingCert”).

    Conclusion

    In summary, technical compliance with the Protection Obligation must begin with an understanding of the type and sensitivity of personal data stored and a security-focused approach to system architecture design. Next, the organisation must recognise the specific security risks associated with their chosen system through a vulnerability assessment, and subsequently implement appropriately-scoped technical measures which address the underlying vulnerabilities prior to launch. Finally, the organisation must consistently maintain and upkeep its system through periodic testing and regular patching, to ensure that it does not succumb to newly-discovered vulnerabilities.

    By virtue of the wide range of systems and myriad combinations among them, a “one size fits all” technical arrangement would be impossible (Advisory Guidelines at [17.2]), and would necessarily differ from system to system. Organisations without in-house expertise in information security would be well-advised to implement system components with independently-verified security standards (e.g. MTCS SS584-certified cloud service providers), and to consult qualified professionals (e.g. OSCP or CREST-accredited cybersecurity experts) to advise on an overall security strategy for PDPA compliance. They should also be aware of regulatory developments, such as the licensing of penetration testing services under the proposed Cybersecurity Bill, slated for adoption later this year.

    * This blog entry may be cited as Joshua Kow and Kenji Lee, “Technical Measures for Reasonable Security Arrangements under the PDPA – A Roadmap”  (9 February 2018) (http://www.singaporelawblog.sg/blog/article/206)

    ** A PDF version of this entry may be downloaded here

Comment Section