2021 MAS TRM Revision

MAS is tackling Third-Party Risk Management. How does this affect you?

Introduction and Changes

The Monetary Authority of Singapore (MAS) recently announced the revision of its Technology Risk Management (TRM) Guidelines. The revised guidelines focus on addressing the cyber concerns of Financial Institutions (FIs) considering the growing usage of cloud technologies, application programming interfaces, rapid software development, and increasing reliance on third-party vendors.

Besides technical controls, the revision also provides additional guidance to directors and senior management to ensure that suitable and competent information security leaders such as Chief Information Security Officers (CISO) are appointed to take charge of the information security of the FIs. The board should also include members with the relevant knowledge to provide effective oversight of technology and cyber risks

Who is affected?

Financial Institutions

Clearly, Financial Institutions, which include “all banks, payment services firms such as GrabPay and Singtel Dash, as well as brokerage and insurance firms (Tham, 2021, 1)” are affected by the changes in guidelines.There is also a list of FIs that are subject to Notice on Technology Risk Management published by MAS for a more detailed reference.

Third-party vendors

Besides FIs, third-party vendors should pay close attention to the changes in guidelines. In order to continue their partnerships with FIs, third-party vendors will be expected to provide a high standard of security to support the FIs’ commitment to the TRM guidelines.

Any organization reliant on third-party vendors

If you are an organization that relies on third-party vendors for the processing of your data, you also need to be aware of the new changes. Although TRM guidelines are specific to FIs, all organizations are susceptible to threats to the supply chain. The updated guidelines can be adopted by any organization to take its third-party risk management program to a higher standard, minimizing the risk exposure.

Why the focus on third parties?

In view of the recent SolarWinds hack, third-party risk management has become a hot topic in the security space, but big data breaches resulting from third-party negligence are not new. In 2014, a data breach in Home Depot led to the theft of 56 million credit and debit card details and 53 million customer email addresses. The attacker gained the ability to breach Home Depot’s internal network all because the credentials of a third-party vendor were stolen.

The SolarWinds hack is another but likely not the last solemn reminder to all organizations of the importance of third-party vendor risk management. Aptly, the TRM guidelines update includes several important changes in the handling of third-party vendor risks, which we will explore in this article.

What does it mean to FIs?

There are a number of unique clauses in the recent updates to TRM guidelines in relation to third-party vendor risk management. Below are the highlights that you need to know about:

3.4.3: On having high standards of care and diligence 

Management of third-party vendors is an ongoing process. A one-off vendor selection exercise done in the past does not automatically make the selected vendor eligible for future partnerships. FIs should implement a process to regularly review and audit vendors to ensure that the data is protected continuously.

6.13 On open-source software codes from third parties

Review and test third-party and open-source software codes before any integration. FIs should implement best practices including Secure Coding, Source Code Review, and Application Security Testing. Rather than having new policies and procedures, FIs can simply include third-party and open-source software as part of existing best practice policies.

6.1.4 On timely vulnerability remediation

Remediate all software vulnerabilities — third-party or in-house — in a timely manner using a robust vulnerability management policy or procedure that prioritizes the fixing of these vulnerabilities by severity and data sensitivity. Additionally, your third-party vendors and you should have an open-door policy for reporting new vulnerabilities at any time. If you use open-source applications, keep an active lookout for vulnerabilities reported by the community. 

6.4.2 On vetting third parties

Develop a comprehensive checklist when it comes to reviewing third-party vendors. How is the vendor’s Data Privacy posture? Does it have relevant certifications such as SOC2, ISO 27001, or Trustmark? Be diligent on vendor selection with this holistic approach encompassing both business and information security deciding factors to help assess suitability.

Conclusion

Clearly, third-party risk management is more than contractual agreements and the one-time security requirements entailed in those agreements. Auditing of software code or in-depth assessments of security posture also needs to be part of your process. Don’t forget that if a security incident happens because of a third-party’s negligence, your organization also needs to pay the price.

Appendix

3.4.3 On an ongoing basis, the FI should ensure the third party employs a high standard of care and diligence in protecting data confidentiality and integrity as well as ensuring system resilience.

6.1.3 A policy and procedure on the use of third party and open-source software codes should be established to ensure these codes are subject to review and testing before they are integrated into the FI’s software.

6.1.4 To facilitate the remediation of vulnerabilities in a timely manner, the FI should keep track of updates and reported vulnerabilities for third party and open-source software codes that are incorporated in the FI’s software.

6.4.2 A well-defined vetting process should be implemented for assessing third parties’ suitability in connecting to the FI via APIs, as well as governing third party API access. The vetting criteria should take into account factors such as the third party’s nature of business, cyber security posture, industry reputation and track record.