This article was written by Peter Gerdenitsch, Group CISO at Raiffeisen Bank International, and is based on a presentation given during Imvision’s Executive Education Program, a series of events focused on how enterprises are taking charge of the API security lifecycle.
Launching the “Security in Agile” program
Headquartered in Vienna, Raiffeisen Bank International (RBI) operates across 14 countries in Central and Eastern Europe with around 45,000 employees. Our focus is on providing universal banking solutions to customers, as well as developing digital banking products for the retail and corporate markets. Accordingly, RBI has a substantial R&D division, making for a very large community of IT and engineering professionals all over Europe.
Back in 2019, we began shifting to a product-led agile setup for RBI, introducing various security roles contributing and collaborating to achieve our strategic goals. As part of this journey, we established the security champion role within the DevSecOps team for each of our products. Besides our central “Security Design and Architecture “function, security specialists began working together to support products in implementing secure solutions.
More than anything, taking ownership over the security aspect of their product meant security champions were well-positioned to ensure that security-related stories get prioritized during backlog meetings, in alignment with the product owner’s acceptable levels of risk.
We also set up tribes consisting of several products associated with a specific business-line to foster a shared sense of community. Each tribe was given another role: the “security chapter lead”.
This role was tasked with supporting the other security champions in their tribe with requirements, risk assessment, design patterns and architecture, thanks to their enhanced expertise. These roles were transparent so that the knowledge carrier of security for each product and tribe was known across the entire organization.
Finally, we set up a community of practice, which includes monthly meetings where security champions from all of the different products could meet to exchange information, teach case studies, and generally share knowledge about their practice. We further began supporting this community endeavor with Monday bulletins, updates from the week, and in general encouraged an open exchange of information, knowledge, and experience.
Learn more on how to take charge of the API security lifecycle
Security ‘Martial Arts’ training program
The idea was – and still is – to make the security champion a completely volunteer-driven role, which at first had us worried that we wouldn’t be able to find enough willing volunteers. Fortunately, the opposite was true, and we were even able to recruit two people for each position to cover vacations and sick leave. Part of the success probably comes from the fact that we didn’t limit the role in terms of background, which meant we saw plenty of volunteers from various IT and business functions as well.
To further support this role, in early 2020 we set up a training program for our security champions based on the martial-arts’ belt system. It started with a 3-day basic training program in security that we called Yellow Belt training. It took off and we quickly gained insights into the program, which resulted in the launch of a slimmer 2-day version of the Yellow Belt that targeted anyone interested in learning more about security.
This shorter, generalized program for everyone was intended to foster collaboration and awareness across the organization by highlighting the importance of security in the product lifecycle and the rationale behind the security champion program. The security champion program’s extra day was focused on learning more about the RBI specific tools of the trade, especially the use of source code scanning and identity and access management tools.
Over time we set up additional, more advanced training courses to help security champions do their jobs more effectively. For example, we’ve got an API security course and cloud security course to deepen our security-related knowledge in these domains. We also encourage professional certification via external courses by providing our security champions with the budget and learning time they need to take them.
Taking charge of our API security lifecycle
In accordance with the Payment Service Directive (PSD), over the past several years banks have increasingly been required – and expected – to open their APIs to enable customers to access financial data easily, including through third-party tools and applications.
This regulation catalyzed a strong pivot to API use that was already in the making, and RBI’s API posture and consumption dramatically increased. Over the past several years, RBI developed many APIs: today, our API Market has 100+ externally exposed APIs, while internally, we counted ~1,000 different APIs. The rise in API implementation and use brought about security risks, which prompted us to think about ways to address API security.
As our API footprint wasn’t limited to just those required by PSD regulations, we quickly discovered that we didn’t necessarily have consistent visibility into all APIs we deployed. Like many other enterprises worldwide, we were challenged with gaining a central view of APIs, considering the high volume and number of APIs in use – so we can ensure that the appropriate and adequate level of security is in place.
To address some of these challenges, we decided to set up the Real-Time Integration Center of Excellence (RICE), which serves as a central management layer for RBI, including APIs that connect to the legacy core banking systems of the various subsidiaries and acquired companies.
As shown in the diagram below, the central API management layer has all the microservices bound together, serving the business functionality for the APIs and connecting on the outside to the various channels and use cases. This layer is a win-win for us, as it enables us to improve customer experience, performance — and security.
From the security perspective, as per the ‘Security in Agile’ approach, each one of the product teams included a security champion. They work with domain experts and the security chapter lead to coordinate security measures in line with the product owner’s designated levels of risk, taking a consultative approach with the relevant business owner defining the priorities.
API security: Keys to success
Building API security on strong collaborative foundations means that our business and dev counterparts are able to understand better the value of security, why we need to do this, and the importance of protecting the APIs.
Most importantly, it became clear that API security was a group endeavor, and that the entire team shared responsibility over that area:
From the business end, since APIs are a crucial part of the organization’s IT infrastructure that must be exposed externally, it’s clear to them that malicious actors would try to penetrate them by posing as API consumers. The program helped us realize that API security is shared between the product owner and IT security teams.
From the product end, being well-prepared, learning from experience and implementing additional layers of protection are key elements in securing APIs.
Furthermore, there’s a deep shared understanding that security should be taken into consideration throughout development, even from the design stage, and that no product should be launched without thorough penetration testing.
Learn more on how to get your security testing ready for the API-first era
Management buy-in and alignment is perhaps one of the most important factors in the proper implementation of API security in an enterprise. Making sure that they are aware of the importance of API security is key in achieving this buy-in.
Another important key success factor is the level of accuracy of the detection technology you choose to work with in your API security journey. The less false positives you get, the better off you are. In essence, for APIs it means you can detect behavior sequences attempting to manipulate the logic and do it in scale.
For security to work, it’s clear that this responsibility shouldn’t fall on just one department, but rather be shared by all teams. During our meetings with the RBI Management Board, we also focused on the benefits of the Imvision solution and how it enabled us to focus on top vulnerabilities, while understanding where the functional errors are to prioritize remediation and save resources.
Like with any partner you choose to work with, the level of cooperation is highly important. In general, the feeling was that the Imvison’s platform doesn’t only provide a powerful security mechanism, but also vast expertise, positive drive and responsiveness to our needs.