The principle behind zero trust is straightforward. Being inside a bank’s network does not, by itself, make a user or device trustworthy. 

Dr Alex Constantinidis is group chief information security officer of QNB Group. In this contributed piece he sets out QNB’s zero trust approach and what it has taught the bank about resilience, he explains how applying that discipline for almost a decade has shaped the way the bank contains a compromise, governs what leaves its network and prepares for change.

Access must be explicitly authorised and limited to what is needed. If an account, device or application is compromised, the security architecture should help contain the consequences.

That works in two directions. Looking inward, it governs what a potentially compromised account or system can reach once inside the network. Looking outward, it governs what employees and systems are allowed to reach beyond it. Both matter, and a bank’s resilience depends on applying the same discipline to each.

At QNB Group, a zero trust approach has guided both for almost a decade. It has shaped how we design our network security architecture to contain a potential compromise, and how we govern what connects outward from it, as our digital environment has evolved. That experience offers a practical perspective on a central responsibility for banks: expanding digital capabilities while protecting the institution’s systems, its employees and, by extension, the customers who depend on it.

For us, zero trust connects everyday security decisions with the Group’s long-term resilience and ability to adapt.

Containing a compromise

An airport offers a useful way to understand layered access. Entering the terminal does not entitle a traveller to go everywhere. Identity checks, security screening and restricted zones each serve a purpose, and additional authorisation is required to pass from landside to airside.

Passengers already inside the terminal are not assumed to be safe. They pass through further checkpoints that revalidate their identity and confirm they carry nothing dangerous before they board. Presence inside the perimeter is not treated as proof of trust.

Phishing remains the leading vector of compromise, and it illustrates why this matters. An attacker who phishes an employee does not break into the network; they are admitted to it, with the same level of access as the employee they are impersonating. The architecture must therefore assume that a legitimate identity can be misused, and limit what any single identity can reach.

In a digital environment, access to one resource should confer no automatic right to another. We combine access controls with segmentation and defined routes into sensitive systems to limit an attacker’s ability to move through the environment after an initial compromise.

The same thinking shapes the security architecture of our customer-facing applications. Their components are separated into distinct layers and placed in separate zones, each with its own controls on what can reach it. If one component is compromised, the attacker is contained within that zone and cannot easily move between layers to reach the systems and data behind it.

At QNB, this principle also shapes administrative access. Administrators access servers through a separate, controlled management environment with additional authentication. Separating administrative activity from everyday workstation use reduces the number of systems an attacker could reach through a single compromised device.

This reflects a realistic view of cybersecurity. New vulnerabilities can emerge in widely used technologies, so resilience requires attention to both prevention and containment. The question is not only how to prevent a compromise, but how effectively the institution can limit its impact and maintain operations if one occurs.

Controlling what leaves the network

Few online interactions involve only one party. When an employee opens a webpage, the browser connects not only to the site itself but also to the trackers, advertising networks and analytics services embedded in it. Each of these is a separate connection the user never sees. Governing access therefore means assessing these third-party dependencies alongside the primary service.

At QNB, employees request access to the external sites and services they need for their work, so that those requirements can be assessed before access is granted. This helps us distinguish connections that serve a business need from those that introduce unnecessary exposure.

For internet-based business applications, we analyse every dependency on external resources before access is granted. Many applications rely on shared public infrastructure, such as public storage services, and an access requirement that resolves to one of these can inadvertently open a route to the wider service. Permitting that route could allow data to be exfiltrated or allow an attacker to host malicious code behind a trusted domain name. We assess each requirement to ensure it is scoped to the service itself and does not extend to public resources beyond it.

Adapting through preparedness

Making zero trust work requires more than technical controls. Security teams must understand what employees need to accomplish and explain the reasons for access restrictions. Executive backing provides a consistent mandate and ensures that decisions reflect the Group’s agreed appetite for risk.

One of the clearest lessons from our experience is that zero trust becomes sustainable when it is embedded in how the organisation makes decisions. Technology provides the controls; leadership and operational processes sustain their effective use.

That consistency becomes particularly valuable as technology evolves. When our zero trust journey began, QNB’s environment was predominantly on premises. New services and technologies have since introduced different dependencies and access requirements, while the underlying principles have continued to guide how we assess and manage them.

Preparedness also means anticipating needs before they become urgent. Before Covid-19, we had established remote-access capabilities for a limited group of users. When the pandemic created a wider requirement for remote working, that provision gave us a foundation we could expand. It demonstrated the value of building security capabilities that support the Group’s ability to adapt to disruption.

A mature security foundation should allow new regulatory or certification obligations to be met through targeted enhancements rather than complete redesign, and should support new technologies and ways of working. Alongside the volume and severity of security incidents, this adaptability is one of the measures by which we assess the effectiveness of our cybersecurity programme.

Setting expectations for technology partners

These principles also inform how we assess business applications. A system holding public marketing information may appear less sensitive than one holding confidential customer data. Yet its permissions and connections to the wider environment still matter. An asset containing little sensitive information can still provide a route to something more valuable.

We therefore apply a strong, consistent security baseline, and assess each application on two counts: where it sits within the internal environment, and what it needs to reach outside it. Protecting the environment requires an understanding of how its parts interact.

Technology partners have an important responsibility here. Banks need clarity about a product’s external dependencies, its access requirements and its ability to operate within a controlled environment. A product whose dependencies cannot be clearly described cannot be properly assessed. These questions should be addressed early in the selection process, when they can still inform the decision to proceed. Where a product’s dependencies cannot be separated from shared public infrastructure, that limitation should be understood and weighed before adoption, not discovered afterwards.

This leads to a clear expectation: software products should be designed to work within an institution’s security architecture. If adopting a product requires established protections to be weakened, its design should be challenged and alternatives considered.

For QNB, almost a decade of applying zero trust has reinforced the value of consistent principles as banking technology changes. Understanding connections, controlling access and containing the impact of a compromise provide a foundation for adopting new capabilities with greater confidence. Financial institutions and their technology partners can strengthen that foundation by making compatibility with security requirements an expectation from the outset.

The post Why a Zero Trust Approach Matters to Banking Resilience appeared first on The Fintech Times.