Cloud adoption for financial services is well underway globally, and with the impending release of the Cloud Technology Risk Assessment Guidelines (CTRAG – currently in draft) the central bank of Malaysia is moving to ensure that both Institutional and Neo banks under its jurisdiction are provided with clear and updated guidelines as they embrace the move to the cloud.
What implications, if any, may arise from this new regulatory guidance, and how would it affect your existing information technology (IT) organisation? This article attempts to provide insights and our impressions after reviewing the draft CTRAG to help prepare Malaysian financial services for this new regulatory requirement.
Document Structure
While the current Risk Management in Technology (RMiT) is still relevant and a solid foundation for IT operations in general, the CTRAG expands on the RMiT Cloud Services section. First impressions are its guidelines are generally forward-thinking, in line with the challenges and disruption that come with cloud adoption. This article highlights a few discussion points and is broken up into two sections. The first section covers Cloud Governance, while the second covers Cloud Design and Control.
Cloud Governance
The key takeaway from the cloud governance section is that it is not business as usual. The regulator emphasises this in multiple subsections, which we will delve into. To help address the points below, we advocate establishing a central cloud team, such as a Cloud Centre of Excellence (CCoE), to define and drive policies related to the broader organisation’s secure and compliant use of the cloud.
There is a call out in the section for financial institutions to understand the shared responsibility model and how it varies between the Cloud Service Provider (CSP) and the financial institution when adopting different cloud services (Infrastructure-as-a-Service/IaaS, Platform-as-a-Service/PaaS, and Software-as-a-Service/SaaS).
Regardless of the type of service adopted, what is unwavering is that the responsibility for securing customer data and ensuring service reliability falls on the financial institution. In practice, we have observed organisations invest in cloud service threat modelling. This is done as part of a service attestation process, resulting in a structured and methodological process to track implementation before allowing the use of a service in any production environment.
Technology risk management is integral and should not only be extended to but modernised for the cloud. CTRAG suggests that risk management strategies should be tailored to cloud service models – a crucial point we strongly echo. Trying to replicate traditional approaches in the cloud can lead to several pitfalls and is likely to prevent financial institutions from realising the benefits of cloud computing. It is therefore essential to holistically re-assess all control requirements (including but not limited to regulatory ones) and build a risk management framework befitting of the broader context of cloud, DevOps and CI/CD.
CTRAG brings up cloud usage policies highlighting the importance of observability and inventory control of information assets and systems, which implies developed data and information asset classification frameworks. This would lead to the determination of which asset classifications are allowed to be hosted on cloud environments. The CTRAG guidance is logical, and we have seen similar implementation in other financial institutions to varying degrees. We recommend that the framework offer a level of granularity that maps to the controls that must be implemented to allow hosting on the cloud. The framework should reduce ambiguity to enable data and information system owners to make appropriate assessments and avoid being overzealous in their classifications. Such classification can lead to over-engineering cloud controls, which ultimately can result in limited uptake of the cloud as it’s perceived to be too expensive and difficult.
We welcome the emphasis on training and advocacy at all levels and functions of the entire organisation. Proper investment in people and training often determines the success of cloud programs and should not be overlooked. What was interesting were some explicit calls for risk management and compliance functions to upskill in cloud computing which resonates with our experience in investing consulting cycles with these departments to update policies and practices that might be dated or suboptimal in cloud environments.
Cloud Design and Control
The second section of the document starts with directions on the design of the cloud platform along with application delivery. This section is much more prescriptive but does not set hard enforcement directives. Overall, the takeaway is that the regulator encourages financial institutions to modernise and consider progressive approaches to best take advantage of the cloud and achieve the benefits it offers.
The advice provided aligns with our thinking on how we should ensure appropriate network segregation by environments and the micro-segmentation of applications, all of which fall under best practice. The section provides some interesting recommendations for adopting progressive approaches in Zero Trust principles for infrastructure and application security and the call to consider treating infrastructure as immutable, which opens the door to modern deployment practices that are easier to implement in cloud due to the automation possibilities cloud enables.
With respect to application delivery, the section states that modern DevOps practices are highly encouraged with the use of CI/CD pipelines, immutable deployments, and Infrastructure as Code (IAC), all of which we welcome and fully endorse. There is a section that re-emphasises the need to ensure that virtual machines consumed by applications in the cloud are hardened as per internal and public benchmarks, which would be no different from current on-premise standards. In any pipeline developed for application delivery, it is prudent to include automated policy enforcement through controls to ensure that only hardened and approved images are selected for application deployments. A previous whitepaper emphasizes this need for centralised, automated controls enforcement at the Cloud Platform level in more detail.
Areas with Room for Discussion
Multi-Cloud
Guidance for multi-cloud as an option came up with respect to resilience and business continuity of critical applications as well as for exit strategies. We agree with planning options to mitigate concentration risk and vendor lock-in and that these should have well-defined strategies. However, we typically advise organisations to first start with a primary cloud and gain experience and maturity before embarking on a secondary cloud. Supporting two CSPs requires more than twice the budget, time, and capable talent of supporting one, adding significant hurdles and complexity to the cloud strategy.
Key Management for Critical Systems
For critical systems, the guidance was given that ownership of the encryption keys used for the application should reside with the financial institution on-premises or be hosted by an independent 3rd party. The section provides an example of hosting an HSM module or equivalent SaaS service on-premise or with a secondary cloud provider.
Our concerns are that this architecture will increase the cost and operational complexity of the impacted cloud applications. As such, the organization should aim to keep the number of critical systems hosted on the cloud low and provide clear guidelines on categorising such systems to remove any ambiguity. Alternatively, controls and automation could perhaps be used to lower the criticality rating and the need to meet this requirement.
For Neo banks, this would potentially impact their core banking systems and restrict their technological choices. For example, it would be more challenging to adopt managed services where cryptographic operations are transparent if a cloud-native encryption service manages the keys. This could be mitigated if the regulator is open to having the cryptographic material imported (Bring-Your-Own-Key/BYOK) with the key still residing with the cloud provider or allow an exemption justified by an audit of the CSP for key integrity and accessibility.
Machine Image Portability
Finally, there is an expectation that virtual machine and container images be made portable across CSPs. While this is a given for containers, simply copying virtual machine images across providers is not possible per se. We could envisage the use of pipelines and automated runbooks to replicate and build images to similar specifications across multiple CSPs, so perhaps this is a case of semantics and some re-wording in the final version would make this more achievable.
Conclusion
CTRAG guidelines are more prescriptive than RMIT and are overall aligned to modern cloud best practices. There were some discussion points discussed above that may have been offered as feedback among other areas to the regulator before the final draft.
Sourced Group has been advising and implementing cloud programs for financial institutions for over a decade. We remain committed to offering our expertise to support those who are concerned about new regulatory changes. Contact us should you require help or have concerns about changes in the regulation.
Are You Ready for CTRAG?
Reach out now for a complimentary preliminary assessment of your organisation’s readiness for CTRAG.
Get In Touch
Somnath (Som) is a Principal Consultant at Sourced with over 4 years of cloud consulting experience in regulated financial institutions. In his time at Sourced his areas of focus have been in developing cloud platforms, and being a trusted advisor in cloud security and solution architecture.
Thomas is a Lead Consultant at Sourced with over 18 years of experience in delivering digital products. He gained a passion for evangelising Serverless architecture through his enthusiasm for cloud and entry into the AWS Ambassador programme.
Max is a lead consultant at Sourced and brings over 15 years of extensive experience in security and risk management. His expertise lies in identifying and solving complex security and compliance issues, both at technology and process level.
