Cloud Native Security in the Financial Services Industry (Part 3): Design your architecture for security in an untrusted environment

Continuing in this series of articles covering the key challenges that Financial Services Institutions are facing in adopting cloud-native development and delivery models for technology services, this article covers the challenge of rethinking security models in the paradigm shift towards dynamic, highly distributed and “borderless” cloud-native architectures. 

Till recently, it was unacceptable for many financial institutions to let employees access corporate information remotely, using their own devices. In fact, any form of Software-as-a-Service solutions that supported corporate functions was likely not allowed. Because of this, many banks still have a perimeter security model in place. In this model, the network security architecture is basically broken into zones, contained by one or more firewalls, and each zone is granted a specific level of trust determining the network resources it is permitted to reach. However, with the advent of digital banking services, and banking customers expecting self-service access to a range of services from their mobile devices, including account opening, loan and mortgage applications, and investment management, financial institutions had to increasingly expose application services and data to customers. Following the perimeter security model, this is achieved by having resources that are deemed more sensitive such as application servers and database servers contained in the internal network zone, while using a specific zone, the famous “demilitarised zones” or DMZ, where data and access are restricted and inward traffic is tightly controlled, to act as a gateway layer serving external traffic through a reverse-proxy server. Unfortunately, this has also made the DMZ a prime target for more and more sophisticated cyber attacks, typically exploiting a flaw of one component in the DMZ and from there moving laterally to get access back into the internal network. This questions the effectiveness of relying on a hardened network perimeter for protection. 

These challenges not only require a shift in security design mindset at the architectural level, but present an opportunity to build security in-depth following a zero trust design approach. This approach is basically a concept centered on the premise that any system or technology service within the organization should not automatically trust anything inside or outside its perimeters, but must instead authenticate and authorise any request, before granting access to internal technology resources at any level of the architecture. This change in approach already gathers wide support from top management across industries, as highlighted in a recent survey by Pulse Security. The survey revealed that in 2020, 72% of organisations already plan to assess or implement zero trust capabilities in some capacity, to mitigate growing cyber risk. However, my personal experience leads me to predict that challenges will arise at the implementation level: too often the implementation of the zero trust approach is reduced to yet another security tooling implementation, with the FSI sector focusing on Single Sign-On, Privileged Identity Management, and Data Loss Prevention initiatives. Here, I’d like to highlight the right approach - which is not introducing additional layers of monitoring and tooling into the existing environment, but rather, go towards simplifying the overall architecture and security administration around it, with a focus on 3 principles:

• Build a unified layer of Enterprise Identity Management: Traditionally, financial services organisations have implemented different services to govern access - of internal employees to systems, of privileged users to internal technology resources, and of customers to digital banking services - with additional segregations between business entities and lines of business. The first fundamental shift required in a zero trust model is towards building a federated identity management capability that supports independent authentication leveraging a strong root of trust (i.e. mutual authentication based on an established Public Key Infrastructure) but also ensuring that communication between services remains secure. It is equally vital to embed the principle of least privilege, to limit the access or functionality that different users have, based on their role (including segregating privileges over separate accounts in case such users require some form of special access), and do so by verifying and enforcing access controls in real time where possible in order to limit exposure of revoked access credentials being used to access systems.
• Promote isolation at all levels in your system architecture design: Progressively adopting true microservice architecture for shared application components helps promote strong functional segregation, independent deployment, and decentralised data management for critical system functions. However, it is important to keep in mind that this is not sufficient to achieve software isolation. It is equally important to consider how micro-segmentation is achieved at other layers of the technology stack. In particular, having strategies for micro-segmentation of compute (where the use of containers orchestrated on kubernetes shines against hypervisor segmentation in cloud environments) and network (through segmentation based on a centralised, role-based access control service mesh, an overlay network that sits between services to transparently handle traffic flow, security and observability), is critical to manage zero-trust consistently in a complex, microservice architecture. The focus here should really be about simplifying the deployment and management of segregated system resources and eliminating implicit trust between separate services and system components, not building additional layers of administration and security handling, and in the process reducing the potential blast radius by preventing lateral attacks should a system or service become compromised. 
• Implement data-level security: Regulated institutions in the financial services industry are generally concerned with data access and movement-related compliance challenges, such as adherence to data sovereignty laws or GDPR compliance, where small mistakes in handling data can lead to serious consequences including fines or business sanctions. In the hybrid cloud, systems are becoming distributed. With the added complexity of open banking trends driving financial institutions to integrate their data with external partners, it has become extremely complex to ensure that the required degrees of enforcement of separation of duties, in terms of what data should be made accessible, is in place at all times. For this reason, financial institutions should have mechanisms in place to ensure that data can be managed throughout its whole lifecycle - including accurate classification, protection of the data at rest and in transit, real-time detection of security threats and timely response to them, recovery (protection of data in backup is a typical issue that often leads to unintended data breaches), and compliance. To this end, automation of data operations processes across all data sources, and improvement of data visibility and control via a standardised monitoring solution that can enable active Data Loss Prevention, are all critical enablers of an effective data-level security policy implementation. A good starting point from the technology point of view would be looking at how the implementation of cloud-native storage systems can facilitate this evolution, by providing a standardised, consistent data access interfaces with a unified layer of access control, authentication, authorisation and security via encryption management for technology services to consume data that is persisted in various storage devices across the enterprise. 

With the above architecture principles in mind, the shift to zero trust security, if done right, can actually lead to a simplification in the operating environment and security processes, together with increased compliance, increased security and lower cost of management.

External references:

Zero Trust Architecture, Special Publication 800-207 (National Institute of Standards and Technology, August 2020)

2020 Zero Trust Progress Report (Pulse Secure, 2020)

Zero Trust: The Modern Approach To Cybersecurity (Forbes, 12 June 2019) 

Cloud Native Security Whitepaper (Cloud Native Computing Foundation, November 2020)