Circular to licensed corporations Review of internet trading cybersecurity

23 Sep 2020



The Securities and Futures Commission (SFC) recently conducted a thematic review1 of selected internet brokers2 which provide online trading services on desktop, mobile or designated website platforms with a focus on cybersecurity issues and vulnerabilities associated with mobile trading applications. The SFC surveyed 55 internet brokers and conducted onsite inspections of 10 of them. The review found that most of the brokers were in compliance with the SFC’s key regulatory requirements.

A report on the thematic review, issued today, summarises the key findings and observations and provides guidance on our expected standards. It also highlights deficiencies and instances of non-compliance in areas such as Two-Factor Authentication (2FA), data encryption, session timeout and monitoring and surveillance to identify suspicious unauthorised transactions. The report also includes reminders of other requirements and good practices adopted by these brokers.

In conjunction with the above, this circular elaborates on the regulatory expectations set out in the Guidelines for Reducing and Mitigating Hacking Risks Associated with Internet Trading3 (Cybersecurity Guidelines) that came into effect in July 2018. In addition, given that some vulnerabilities which are unique to mobile trading applications have not been covered in the Cybersecurity Guidelines, this circular also provides guidance on specific system security controls which internet brokers should employ for mobile trading applications as required under the Code of Conduct for Persons Licensed by or Registered with the Securities and Futures Commission (Code of Conduct).

A.   Two-Factor Authentication (2FA) for system logins

Under paragraph 1.1 of the Cybersecurity Guidelines, internet brokers should implement 2FA for logins to clients’ internet trading accounts where 2FA refers to an authentication mechanism which utilises any two of these factors: what a client knows, what a client has and who a client is.

In practice, for “what a client knows”, internet brokers commonly adopt user IDs and passwords. For “what a client has”, internet brokers typically provide a one-time password (OTP) to the client through different means, or bind or register the client’s device with their internet trading system so that the device is recognised as belonging to that client. “Who a client is” generally utilises biometric authentication, a process which compares a client’s fingerprint or facial recognition with information stored in that client’s mobile device.

The SFC’s thematic review identified a number of control deficiencies and instances of non-compliance, such as:

  • delivering the OTP by email which is not effective as a second authentication factor4;
  • allowing clients to deactivate 2FA for system logins; and
  • problems with binding clients’ devices such as technical security loopholes or allowing clients to bind an excessive number of devices.

To address the above deficiencies, internet brokers should:

(i)     not deliver the OTP by email;

(ii)    not allow clients to deactivate 2FA for system logins;

(iii)   regularly perform technical assessments to identify security loopholes;

(iv)  not allow a client to bind or register an excessive number of devices to his or her internet trading account, and should implement controls over concurrent logins, for example: 

  • understand why an individual client requests to bind or register more than three devices and assess the reasonableness of the request;
  • where a corporate client requests to bind or register multiple devices so that they can be operated by its authorised persons, internet brokers should advise the corporate client of the creation of sub-accounts (each with its own 2FA); and
  • where a sub-account arrangement is not feasible, concurrent logins should be limited to the number of persons authorised to operate the corporate clients’ internet trading accounts.

B.   Monitoring and surveillance mechanisms to detect unauthorised access

Under paragraph 1.2 of the Cybersecurity Guidelines, internet brokers should implement an effective monitoring and surveillance mechanism to detect unauthorised access to clients’ internet trading accounts.

During the thematic review, a number of control deficiencies were noted which could result in late detection of suspicious unauthorised transactions and delayed follow-up.

These include:

  • some large internet brokers only reviewed client transactions manually;
  • monitoring and surveillance only performed on an ad hoc, weekly or monthly basis; and
  • design flaws in the automated internet protocol (IP) address monitoring tool such as mistakenly assigning the same generic IP address to all login attempts from different mobile or web users.

To address the above deficiencies, internet brokers should:

(i)    take into account the scale of their internet trading operations and implement a monitoring and surveillance mechanism which is appropriate and commensurate with their business needs;

(ii)   perform monitoring and surveillance at least daily; and

(iii)  conduct sufficient technical and user testing before implementing an automated IP address monitoring tool.

C.   Data encryption

Under paragraph 1.4 of the Cybersecurity Guidelines, internet brokers should implement strong encryption algorithms for data transmission and storage. 

During the thematic review, it was noted that some firms failed to adequately encrypt and protect client login credentials, passwords and trading data as they were using encryption algorithms which did not meet international security standards (eg, the cryptographic standards provided by the National Institute of Standards and Technology).

Internet brokers should review international security standards on an ongoing basis, check the status of their data encryption algorithms and upgrade them as appropriate.

D.   Session timeout

Under paragraph 1.6 of the Cybersecurity Guidelines, internet brokers should set up stringent controls to ensure session timeout after a period of inactivity.

During the thematic review, it was noted that session timeout could be either disabled by clients or too long; the idle timeout period could be as long as 24 hours.

To address the above deficiencies, internet brokers should:

(i)    not allow their clients to disable session timeout;

(ii)   limit the idle timeout period (eg, within 30 minutes) subject to prior assessments and ongoing monitoring. For example, a client conducting programme trading may need to be on standby to effect transactions at any time. In that case, a longer idle timeout period could be allowed, but the internet broker would then have to monitor that client’s login and logout records and trading activities more closely; and

(iii)  perform sufficient testing to ensure session timeout controls are configured and functioning properly.

E.   Secure network infrastructure

Under paragraph 2.1 of the Cybersecurity Guidelines, internet brokers should deploy a secure network infrastructure through proper network segmentation, ie, a Demilitarised Zone (DMZ) with multi-tiered firewalls.   

The thematic review noted improper network segmentation which jeopardised the security of the network infrastructure, eg, internet trading applications and other critical systems were placed within a DMZ rather than behind a DMZ.

To address the above deficiency, internet brokers should:

(i)    place internet trading applications and other critical systems within the trusted internal network behind a DMZ; and

(ii)   host servers with less sensitive data, eg, the web server hosting the company webpage, within a DMZ.

F.   Security controls for remote connections

Under paragraph 2.3 of the Cybersecurity Guidelines, internet brokers should grant remote access to their internal networks on a need-to-have basis and implement security controls over such access.

During the thematic review, it was noted that some vendors were granted remote access at all times which increased cybersecurity risks.

To address the above deficiency, internet brokers should avoid granting permanent remote access to external parties.

G.   Patch management

Under paragraph 2.4 of the Cybersecurity Guidelines, internet brokers should monitor and evaluate security patches or hotfixes released by software providers on a timely basis and, subject to the evaluation, conduct testing as soon as practicable and implement the security patches or hotfixes within one month following the completion of testing.

During the thematic review, control deficiencies were noted which could delay the implementation of critical security patches and hotfixes. These include:

  • taking more than six months to implement security patches and hotfixes, even for those ranked as critical or of high severity;
  • only doing patch management in batches every six months; and
  • using end-of-life (EOL) software[5]. Vendors no longer provide security fixes for EOL software, exposing network and system vulnerabilities which may be exploited by hackers.

To address the above deficiencies, internet brokers should:

(i)    identify and implement urgently needed security patches or hotfixes as soon as possible;

(ii)   only adopt batch implementation for non-critical security patches and hotfixes, and implement batches at least on a quarterly basis unless, after evaluation, it is determined that they may be incompatible with system applications and cannot be implemented; and

(iii)  ensure that vendors support the software they use by monitoring the validity of existing software on an ongoing basis and in a timely manner, and replacing or upgrading software that is EOL or close to EOL.

H.   Cybersecurity management and supervision

Under paragraph 3.1 of the Cybersecurity Guidelines, the Responsible Officer-Internet trading should define a cybersecurity risk management framework and set out key responsibilities, such as arranging to conduct a self-assessment of the framework on a regular basis.

The thematic review noted that a large number of firms did not sufficiently cover the baseline requirements in their IT audits or self-assessments. 

To address this deficiency, internet brokers should review their compliance with the baseline requirements in their IT audit or cybersecurity assessments at least annually.

I.   Mobile trading applications

Of the 10 inspected firms which provided mobile trading applications, many were unable to meet the security control requirements set out in paragraph 1.2.4 of Schedule 7 to the Code of Conduct. In particular:

  • six were unable to detect and block compromised devices from logging into their internet trading systems;
  • five did not adequately protect their source codes which could allow hackers to by-pass built-in security controls;   
  • three had unused code libraries or modules in their mobile trading applications resulting in increased risk of hackers installing malware;
  • six allowed storage of clients’ sensitive information in the mobile devices and this information was not removed from the system process memory after logoff. This increased the risk that information could be accessed by hackers; and
  • one allowed a client’s biometric data stored in that client’s mobile device to be amended without proper validation and did not disable biometric authentication after repeated failed attempts. 

To address the above deficiencies, internet brokers should:

(i)    detect and block compromised devices from logging into their internet trading systems;

(ii)   obfuscate their source codes to better protect them from manipulation;

(iii)  purge unused code libraries or modules from their source codes;

(iv) purge clients’ sensitive information from their internet trading applications installed on clients’ mobile devices once the clients exit the applications or log off their internet trading accounts; and

(v)  tighten security controls for biometric authentication, eg, subjecting any changes to clients’ biometric data to validation checks and limiting the number of failed authentication attempts.

While no hacking of client accounts was reported after the baseline requirements came into effect in July 2018, internet brokers should:

  • take heed of the above guidance;
  • familiarise themselves with existing requirements; and
  • critically review their systems and controls, which should be commensurate with their business models, and rectify or enhance them as needed.

Given the technical nature of this subject matter, internet brokers should seek professional assistance from their vendors and other consultants as needed.

Should you have any queries regarding the contents of this circular, please contact your case officers.

Intermediaries Supervision Department
Intermediaries Division
Securities and Futures Commission

Enclosure

End

SFO/IS/033/2020


1   The review primarily covered the system controls and related management controls of selected internet brokers to assess their compliance with the 20 baseline requirements contained in the Cybersecurity Guidelines and other relevant cybersecurity requirements of a general nature included in the Code of Conduct. 
2   Licensed corporations which engage in internet trading business in Hong Kong.
3   The requirements in the Cybersecurity Guidelines are principles-based and internet brokers are free to select which controls and measures to implement provided that they are adequate, effective and commensurate with their structures, business operations and needs.
4   This is because the person logging in using an email OTP may not be the actual client, on the premise that an email OTP: (a) can be delivered to multiple devices, eg, both a mobile phone and a computer, and be accessed or read by multiple applications on each of these devices and (b) may not always be directed to the client as the login credentials for email accounts can be shared with multiple persons. Furthermore, security protection for email accounts is insufficient, eg, the email forwarding function may result in inadvertent sharing of the OTP with others.
5   This refers to software which has reached the end of its useful life and its vendor has stopped supporting it (eg, Windows Server 2008).

Click here to download the document


Supplementary document

Appendix

Page last updated: 23 Sep 2020