Skip to content Skip to sidebar Skip to footer
Home Resources Blog Exploring KBC’s journey to the cloud

Exploring KBC’s journey to the cloud

9 minutes reading time

Exploring KBC’s journey to the cloud

The financial industry has traditionally been cautious about embracing the cloud, often clinging to the familiar fortresses of on-premises data centers. But banks and other financial organizations cannot deny the agility offered by cloud technology either. How are they weighing the potential of the cloud versus its risks? How can they devise a cloud strategy that unlocks innovation and efficiency? And what are some of the best practices for securing cloud applications and data? The Cyber Security Coalition addressed these and other questions to Walter Adriaens, Delivery Manager at KBC Group, one of Europe’s leading bank-insurers.

Exploring KBC’s journey to the cloud 

The balancing act between security and cloud performance

The financial industry has traditionally been cautious about embracing the cloud, often clinging to the familiar fortresses of on-premises data centers. But banks and other financial organizations cannot deny the agility offered by cloud technology either. How are they weighing the potential of the cloud versus its risks? How can they devise a cloud strategy that unlocks innovation and efficiency? And what are some of the best practices for securing cloud applications and data? The Cyber Security Coalition addressed these and other questions to Walter Adriaens, Delivery Manager at KBC Group, one of Europe’s leading bank-insurers.  

How did KBC’s recent journey to the cloud evolve? 

Walter Adriaens: “The journey to the cloud for KBC is obviously linked to its strategy and history.  In 2017, KBC set an initial ambition to embrace cloud technology. Over the subsequent years, KBC was indeed slowly but surely moving things to the cloud. This deliberate pace is due to our careful consideration of privacy and security concerns. The signing of the EU – US Data Privacy Framework in 2023 has certainly aided our efforts, yet the privacy and security of our customers’ data remain paramount. Our experience has taught us that regulations can evolve and sometimes take unexpected turns. 

In 2024, KBC announced it would build two new datacenters. How does this align with KBC’s cloud strategy?  

Walter Adriaens: “Well, if you go to the cloud, you need to think about your strategy, and the first key question is: why do you want to use the cloud? For KBC there were three important drivers. The first one is faster development, using several out-of-the-box services. An example of this is KBC’s digital assistant Kate, which could not have developed so quickly without the cloud. Another example is transaction enrichment data on the KBC mobile app, for instance transaction locations, which have also been developed in the cloud. 

Innovation is the second driver. Being able to use big data, machine learning, generative AI as a power to accelerate development. And the last driver is that the cloud enables us to collaborate better between different entities within the KBC Group.  

The second important strategic question is: what are the risks involved in moving to the cloud? The first risk we identified is cross platform communication. If you build something partially in the cloud and partially on premise, communication between the two components can become complex and introduce operational risks. Another potential issue is that of losing control because of the sheer possibilities in the cloud and setting up things at a fast pace, the so-called ‘cloud sprawl’. And linked to that, there is the risk of losing track of costs too. Security posture is another important factor, as the more ways there are to connect and to set up applications, the bigger the potential attack scope becomes. And lastly, there is always a risk you introduce multiple solutions for the same problem.”  

Assessing these opportunities and risks, what are the key elements of KBC’s cloud strategy? 

Walter Adriaens: “There are several strategic principles we adhere to when it comes to cloud. The first one is that we believe our organization should use the environment appropriate for the workload. We don’t believe in going to the cloud because everybody is doing it. We go to the cloud whenever it is useful, and indeed sometimes it can be useful to stay on-premises. We use a clear process to make that decision.  

Another leading principle is the way we look at ‘hybrid’. We don’t want to build something that runs partly in the cloud and on-premises. It is either completely on-premises or completely in the cloud. Obviously there will be communication between the two environments, but that communication is strictly organized, via what you can call ‘secure internet protocols’, like API, HTTPS calls, etcetera.   

The final principle is that when going to the cloud, we use existing cloud services as much as possible. We don’t develop something that exists out-of-the-box. When it comes to services, we prioritize SaaS over PaaS, and we avoid IaaS. So, we do not allow any virtual machines, or EC2s for that matter. We do this because we want to use the power of the cloud without having to build and manage things on top of that. And finally, we do not allow any manual actions in the cloud: everything is pushed via CICD pipelines.” 

How does this strategy connect to addressing security issues? 

Walter Adriaens: “It goes without saying that while selecting an environment suitable for the workload, security is a top priority. If you have something sensitive, it may be useful to put it on premises. Also, within the devops roles, for instance, we have a strict account separation, both on user (admin) access as on networking access.  

When it comes to how we approach ‘hybrid’, meaning either completely in or out of the cloud, the strict separation reduces the risk. By limiting the communication protocols to the outside world, even considering on premise as outside, and letting them flow only through gateways, you also make sure security is maintained and possible mistakes are reduced to a minimum. And finally, by using cloud services whenever possible, we lower classic attack surfaces, we can use CSP security tools more out-of-the-box and ensure that admin access is limited.” 

Can you explain how KBC implements cloud security in practice? 

Walter Adriaens: “When implementing security, we first look at three levels with corresponding responsibilities. Obviously, there is the level of the cloud as well, but there the responsibility lies with the cloud service provider. So, the first layer on the KBC side is the landing zone, where the responsibility for security lies with what we call the foundation team. One level up, when it comes to services, security is handled by the central services and platform team and finally, at the top layer of the applications, the responsibility lies with the developers.” 

And on each of these levels KBC applies various security tools and technologies? 

Walter Adriaens: “Indeed. At the level of the landing zone, we apply the classic security requirements like identity and access management, making sure that logging in and access are secure. For detection purposes we use SIEM and security tooling. Additionally, there is everything involving network access, including firewalls and DDOS. And finally, encryption services are enforced from within the landing zone. 

The second layer is the layer of security built into the cloud services. The first measure here is that we use a very strict catalog of allowed services. All services are disallowed by default and need to be approved. Before they get approved, we apply a secure configuration baseline, where we basically start from the most secure way of implementing the service. All teams need to follow that secure baseline when implementing that same service. 

Lastly, we have created a control center to detect and verify that what is supposed to be implemented is really implemented and followed up, that what is changed is reported and so forth. In this center, we follow up on usage, configuration and enforcement, among other things. 

In the final layer of Applications, we use strict secure development practices and always steer on development within the cloud context. We really need to have our developers knowing and thinking that they are building something for the cloud.” 

How do you ensure that the implemented security measures work? 

Walter Adriaens: “Obviously, there are regular reviews by the internal audit department, which KBC is also legally required to do. We perform pen testing as well. But to really put things to the test, KBC also arranges for ethical hacks that so far have offered valuable insights. The first one is that you need to assume that you are going to be breached someday. This is not an easy mindset for people to grasp or adopt. You really need to think the other way round. For instance, you could assume that an application is perfectly safe when it can only be accessed by a single person with a difficult password. Well in that case, you need to assume it is not and that someone may have found a workaround to get access. Monitor the seemingly impossible events; they can be indicators that something is wrong. 

Another thing you need to consider is what your weakest security element is. And the answer to that question is most often…people, and even worse, the admins. And lastly, don’t trust your workstations. At KBC, for instance, there is no way of using your own personal workstation in the organization’s network.”  

What are some of the good practices to follow to mitigate possible cloud security issues? 

Walter Adriaens: “Well, a first measure to take is to avoid admin login, this can be done by always using pipelines  and avoiding manual actions. If manual actions are necessary, establish different levels of access/ The highest level should be closely monitored, with a justification required for its use. Regularly evaluate these actions and consider alternatives, preferably automated solutions. Also make sure to define exactly which rights are for each user and limit access to the minimum needed. At the same time, limiting and monitoring data transit possibilities is a good practice to follow, as data is obviously valuable for malicious hackers. Also, disallow all services by default, only allow what is strictly needed. And finally, monitor all abnormal things though SIEM.” 

What does the future bring, and how does KBC look at technology such as CNAPP? 

Walter Adriaens: “As mentioned, KBC uses out-of-the-box tools, which have been satisfactory so far. We have been evaluating and monitoring technologies such as cloud-native application protection platforms (CNAPP), and we believe it now has come to a maturity that warrants us to start looking further into it. It is obvious that for a large organization such as KBC it is key to choose the right and dependable vendor when it comes to new technologies.  

KBC is surely not cloud sceptic. Yet, it is no surprise that we pay a lot of attention to security. Banks are a target of malicious persons all the time, so they need to tread carefully when it comes to change. KBC is actively using the cloud today, and we are looking at the opportunities that AI offers. At the same time, we will remain critical of when and where we use the cloud.”  

About the author
Jo De Brabandere

Jo De Brabandere

Experienced Marketing & Communications Expert and Strategist
Jo De Brabandere is an experienced marketing & communications expert and strategist.
Join our podcast
Please choose your preferred listening platform and language

Spotify

EN

FR

NL

Apple

EN

FR

NL

Join our newsletter

Cyber Pulse keeps you up-to-date on the latest cybersecurity news, community actions and member stories.