A. Introduction
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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).
- The current Version 1 of the Standard targets the following critical areas:
| Authentication | Authorisation |
|---|---|
| Validating user identity and ensuring legitimate access. Examples of forms of authentication methods include biometrics, personal identification numbers or multi-factor authentication code generators. | Defining and validating user access rights to relevant resources within the app, and creating systematic controls and validation of user access rights within an application. |
| Data Storage (data-at-rest) | Anti-Tampering & Anti-Reversing |
|---|---|
| Safeguarding the integrity and confidentiality of sensitive data (such as personally identifiable information) in user's device and app server. | Implementing of measures to prevent tampering or compromising app. Anti-tampering and anti-reversing security controls, such as anti-malware detection and anti-keystroke capturing, are additional measures that developers can implement to counter malicious actors attempting to tamper with or compromise their applications. |
C. The Four (4) Critical Areas in Version 1 of the Standard
- 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:- 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.
- 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. - 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:
- 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.
- 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.
- 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:
- 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.
- 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
- 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.
- 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.
- Apps should use Multi-Factor Authentication (MFA) to
authenticate high-risk transactions*
D. Conclusion
- 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.
- 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.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
