Our journey to API security at Raiffeisen Bank International

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^[1]

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 makingf, 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 take charge of
the API security lifecycle^[2]

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^[3] 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^[4]
doesn’t only provide a powerful security mechanism, but also vast
expertise, positive drive and responsiveness to our needs.