A. Introduction

1. There has been an increase in the prevalence of scammers in Singapore in recent years. The Singapore Police Force released its Mid-Year Scams and Cybercrime Statistics on the overall scams and cybercrime situation for the period of January to June 2023. During this period, the number of scam and cybercrime cases had increased by 69.4% (to 24,525 cases), as compared to the number of cases (13,576 cases) in the same period in 2022. In the first half of 2023 alone, more than S$330 million was lost to scammers, and when breaking down the types of scams or fraudulent schemes that are being more frequently perpetrated, there has been a clear increase in e-commerce scams.
2. It is no coincidence that with the ubiquity of smart phones and the wide variety of mobile applications available to facilitate online transactions, Singaporeans have also experienced an increase in online shopping fraud. From a survey conducted by a renowned financial technology company of 1,000 Singaporeans aged from 18 and over 65, over one (1) in five (5) of the surveyed individuals had fallen victim to online shopping fraud in the preceding six (6) months. The survey showed that it was those aged between 18 and 34 who were hit the hardest, experiencing the highest fraud rate at 52%. Perhaps most significantly, 85% of the participants voiced concerns regarding the security of their funds during online transactions.
3. With the aim of making high-risk transactions via all kinds of apps more secure, the Cyber Security Agency of Singapore (CSA), in consultation with the industry partners, developed the Safe App Standard (the Standard). The Standard provides a common benchmark and guidance to local app developers and providers on the necessary security controls and best practices to better protect their applications, and, in turn, their end-users, against common malware and phishing attempts.
4. This article provides an overview of the best practices set out in the Standard, and what local app developers can do to integrate the best practices and guidelines so as to enhance the protection of user data and app transactions.

B. The Standard

5. The CSA developed the Standard to provide a recommended standard for mobile applications (apps), with the objective of putting forward a recommended baseline of security controls for mobile app developers and providers to follow. This would ensure that there was a similar set of security controls for all mobile apps to comply with, and provide a compliance benchmark for all local apps. This, in turn, would raise the security levels of the apps hosted and created in Singapore, and hopefully provide greater security to end users during online transactions.
6. The Standard provides recommendations and suggestions to developers to assist them in implementing security functions into their apps. The recommendations and suggestions are aimed towards assisting developers in mitigating against a broad spectrum of cybersecurity threats and protecting their apps from the latest mobile scams and mobile malware exploits.
7. In terms of the legal nature of the recommendations, the Standard makes it clear that its contents are non-binding, and are provided on a non-reliance basis and meant to be informative in nature. The Standard was not intended to exhaustively identify potential cybersecurity threats, nor exhaustively specify processes or systems that developers should put in place to address or prevent such threats. The contents of the Standard are not intended to be an authoritative statement of the law or a substitute for legal or other professional advice.
8. Notwithstanding its non-binding nature, it is made clear in the Standard that it is very much a “living document” that will be subjected to review and revision periodically. It is intended that the Standard will be regularly updated to match the current and evolving threat landscape and new attack vectors, and so local app developers will need to refer to the CSA’s website to stay updated with the latest version of the Standard. It is also made clear that the Standard is to be read in conjunction with, and does not replace, vary, or supersede, any legal, regulatory, or other obligations and duties of app developers and providers, including those under the Cybersecurity Act 2018 (and its subsidiary legislation).
9. The current Version 1 of the Standard targets the following critical areas: 

C. The Four (4) Critical Areas in Version 1 of the Standard

10. As highlighted above, Version 1 of the Standard focuses on the four (4) critical areas of authentication, authorisation, data storage (data-at-rest) and anti-tamper & anti-reversing. These critical areas are included to ensure the standardisation of mobile app security against the most common attack vectors used by malicious actors in the Singapore local ecosystem. The Standard provides a clear and concise set of security controls, guidelines, and best practices for enhancing the security of mobile apps that provide or enable high-risk transactions.
    

    (i) Authentication

    For the authentication component of most mobile applications, the best practices recommended by the Standard include the following:
    
    1. Apps should use Multi-Factor Authentication (MFA) to authenticate high-risk transactions*
       
       In traditional single-factor authentication systems, users only need to input one (1) set of information, such as username and password. If this single factor fails or is compromised, the entire authentication process is vulnerable to threats.
       
       MFA is an authentication procedure that adds layers of identity verification. Implementing MFA makes it more challenging for malicious actors to compromise accounts and enhance the overall security of the authentication process.
       
       

    *The term “high-risk transaction” is defined in the Standard as a transaction that involves:

    • (a) changes to financial functions – examples include but are not limited to registration of third-party payee details, increase of fund transfer limit, etc.
    • (b) initiation of financial transactions – examples include, but are not limited to, high-value funds transactions, high-value funds transfers, online card transactions, direct debit access, money storage functions, top-ups, etc.
    • (c) changes to the application’s security configurations – examples of this include, but are not limited to, disabling authentication methods, updating digital tokens or credentials, etc.
    2. Apps should use context-based factors to authenticate
       
       Context-based factors introduce dynamic elements such as user location and device attributes. While MFA provides a robust layer of security by requiring multiple authentication factors, incorporating context-based factors creates a more comprehensive and adaptive authentication process that can offer additional benefits in addressing the evolving risks of unauthorised access.
    
    
    3. Apps should implement brute force protection for authentication
       
       Brute force attacks involve automated and systematic attempts to guess user credentials, for example, by trying various combinations of usernames and passwords to gain unauthorised access.
       
       Brute force protection restricts the number of login attempts within a specified period, which can significantly mitigate the risk of unauthorised access, protect user accounts and maintain the integrity of the authentication process.

(ii) Authorisation

For the authentication component of most mobile applications, the following are some of the best practices suggested by the Standard:


1. Apps should implement server-side authorisation
   
   Server-side authorisation refers to validating and granting access permissions to users or apps by a server or an authorisation server. This ensures that access control decisions and permissions are managed and enforced on the server-side rather than the client.
   
   By implementing server-side authorisation, developers reduce opportunities for malicious attackers to tamper or bypass security measures on the app to gain unauthorised access to sensitive data.


2. Apps should notify users of all required permissions before they start using the app
   
   Required permissions are specific rights and capabilities that the app requests from the mobile device. These permissions define what resources or functionalities (such as camera, microphone, location, etc.) the app can access on users’ devices.
   
   By implementing proper notifications that inform the users of what permissions are being requested, developers can prevent users from unknowingly granting excessive permissions, which may allow malicious actors to exploit vulnerabilities and steal sensitive data.


3. Apps should notify users of all high-risk transactions that have been authorised and completed.
   
   If an app has high-risk transaction functionalities, users should be notified immediately when a transaction has been authorised and completed.
   
   By implementing this control, developers can ensure that users are made aware immediately when high-risk transactions have been authorised and completed so that they may be able to identify potential fraudulent transactions as soon as possible.

(iii) Data Storage Room (data-at-rest)

For the data storage security component of most mobile applications, the best practices suggested by the Standard include the following:


1. Storing sensitive data that is only necessary for transactions
   
   Sensitive data is defined as user data and authentication data (e.g., credentials, encryption keys, etc.). Developers should only store sensitive data that is necessary for app business functions. Accumulating unnecessary information increases the impact of potential security breaches, making an app an attractive target for malicious actors.
   
   By implementing this security control, developers can ensure that exposure is limited to the data required for specific business functions, minimising the impact in the event of unauthorised access or data breaches.


2. Implementing secure storage of sensitive data
   
   Secure storage for mobile apps refers to implementing techniques and practices to protect sensitive data stored on mobile devices and app servers from unauthorised access, theft, or tampering.
   
   This involves best practices such as encryption, hashing, tokenisation, and proper access controls. By implementing secure storage, developers can mitigate against unauthorised access, device compromise, potential data breaches and data leaks.

(iv) Anti-Tampering & Anti-Reversing

1. Signing an app with certificates from official app stores
   
   Apps are often spoofed by malicious actors and distributed via less strictly regulated channels. Signing an app with certificates provided by official app stores assures the mobile operating system and users that the mobile app is from a verified source.
   
   Implementing code signing helps operating systems determine whether to allow software to run or install based on the signatures or certificates used to sign the code. This helps prevent the installation and execution of potentially harmful apps. In addition, code signing also assists with integrity verification, as signatures will change if the app has been tampered with.


2. Implementing anti-malware detection
   
   Malware apps are increasingly used by malicious actors as a vector to compromise users’ mobile devices, as such devices provide users with the convenience needed to perform day-to-day transactions.
   
   Malware apps primarily utilise sideloading features as a channel to get users to install malware on their devices. By implementing anti-malware detection capabilities on an app at runtime, developers can prevent users from being exploited via malware exploiting app vulnerabilities and OS vulnerabilities, stealing credentials, taking over the device, and executing fraudulent transactions.

D. Conclusion

11. The Standard, which has been developed by the CSA, aims to provide a common benchmark and guidance to local app developers and providers on the necessary security controls and best practices to better protect their applications, and, in turn, their end-users.
12. While the Standard is currently non-binding, and provides non-binding recommendations and suggestions to developers to assist them in implementing security functions into their apps, local app developers are encouraged to adopt the Standard in their app development, as, by doing so, developers can ensure that their applications are secure, and their users are protected.