Testing the security controls for a notional FDX Open Banking deployment

\n

Introduction

\n

Unlike other Open Banking initiatives that are mandate-driven in a top-down approach, the North-American Open Banking standardisation effort is industry-led, in a bottom-up fashion by the Financial Data Exchange (FDX), a non-profit body. FDX's members are financial institutions, fintechs, payment networks and financial data stakeholders, collaboratively defining the technical standard for financial data sharing, known as FDX API.
As Security is a core principle followed in development of FDX API, it's worth examining one of the ways in which F5 customers can secure and test their FDX deployments.

\n

Architecture

\n

To understand the general architecture of an Open Banking deployment like FDX, it is helpful to visualise the API endpoints and components that play a central role in the standard, versus the back-end functions of typical Financial Institutions (the latter elements displayed as gray in the following diagram):

\n\n

In typical Open Banking deployments, technical functions can be broadly grouped in Identity & Consent, Access and API management areas. These are core functions of any Open Banking standard, including FDX.

\n

If we are to start adding the Security Controls (green) to the diagram and also show the actors that interact with the Open Banking deployment, the architecture becomes:

\n\n

It is important to understand that Security Controls like the API Gateway, Web Application and API Protection or Next Generation Firewalls are just functions, rather than instances or infrastructure elements. In some architectures these functions could be implemented by the same instances/devices while in some other architectures they could be separate instances.
To help decide the best architecture for Open Banking deployments, it is worth checking the essential capabilities that these Security Controls should have:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

WAAP (Web Application and API Protection)	\n \n Negative security model / known attack vectors database \n Positive security model / zero-day attack detection \n Source reputation scoring \n Security event logging \n L7 Denial of Service attack prevention \n Brute-force and leaked-credential attack protection \n Logging and SIEM/SOAR integration \n Bot identification and management \n Denial of Service Protection \n Advanced API Security: Adherence to the FDX API OpenAPI spec Discovery of shadow APIs \n \n
API Gateway	\n \n Authentication and authorization \n Quota management \n \n
(NG)FW	\n \n Layer 3-4 Denial of Service attack prevention \n Prevention of port scanning \n \n
IDS/IPS	\n \n Anomaly detection \n \n
Databases	\n \n Privacy protection for data at-rest \n \n
Client-side protection	\n \n Fraud detection \n \n

\n

One possible architecture that could satisfy these requirements would look similar to the one depicted in the following high-level diagram, where NGINX is providing API Gateway functionality while F5 Distributed Cloud provides WAF, Bot Management and DDoS protection.

\n\n

In this case, just for demo purposes, the notional FDX backend has been deployed as a Kubernetes workload on GKE and NGINX API Gateway was deployed as an Ingress Controller while Distributed Cloud functionality was implemented in F5's Distributed Cloud (XC) Regional Edges, however there is a great degree of flexibility in deploying these elements on public/private clouds or on-premises.
To learn more on the flexibility in deploying XC WAAP, you can read the article Deploy WAAP Anywhere with F5 Distributed Cloud

\n

Automated security testing

\n

Once the architectural decisions have been made, the next critical step is testing this deployment (with a focus on Security Controls testing) and adjust the security policies. This, of course, should be done continuously throughout the life of the application, as it evolves.
The challenge in testing such an environment comes from the fact the Open Banking API is generally protected against unathorized access via JSON Web Token (JWT), which is checked for authentication and authorisation at the API Gateway level. \"Fixing\" the JWT to some static values defeats the purpose of testing the actual configuration that is in (or will be moved to) Production, while generating the JWT automatically, to enable scripted testing is fairly complex, as it involves going through all the stages a real user would need to go through to perform a financial transaction.

\n

As an example of the consent journey an end-user and the Data Recipient have to go through to obtain the JWT can be seen in the following diagram:

\n\n

One solution to this challenge would be to use an API Tester that can perform the same actions as a real end-user: obtain the JWT in a pre-testing stage and feed it as an input to the security testing stages.
One such tool was built using the Open Source components described in the diagram below and is available on GitHub.

\n

The API Tester is using Robot Framework as a testing framework, orchestrating the other components. Selenium WebDriver is used to automate the end-user session that would authenticate to the Financial Institution and give the user consent for a particular type of transaction. The JWT that is obtained is then passed by Robot to the other testing stages which, for demo purposes, will perform functionality tests (ensuring valid calls are being allowed) and security testing (ensuring, for example, known API attacks are being blocked).\n

\n

The API Tester is automatically deployed and run using GitHub Actions and Terraform Cloud. A full pipeline will go through the deployment of the the GCP's GKE infrastructure required to host the notional FDX back-end and the NGINX Ingress Controller API Gateway, the F5 XC WAAP (Web Application and API Protection), and the API Tester hosted on the F5 XC vk8s infrastructure.
A run is initiated by creating a repository branch and, following the deployment and test run, a report is being received via email.

\n

Here's the API Tester in action:

\n

Conclusion

\n

F5 XC WAAP and NGINX API Gateway can provide the levels of protection required by the Financial Services Industry, the current article focussing on a possible security architecture for FDX, the North-American standard for Open Banking.
To test the security posture of the FDX Security Controls, a new API Tester framework is needed and the main challenge that is solved is the automated generation of JWT, following the same journey as a real end-user.
This allows the testing of deployments having a configuration similar to the one found in Production.

\n

For more information or to get started:

\n

Introduction

\n

Unlike other Open Banking initiatives that are mandate-driven in a top-down approach, the North-American Open Banking standardisation effort is industry-led, in a bottom-up fashion by the Financial Data Exchange (FDX), a non-profit body. FDX's members are financial institutions, fintechs, payment networks and financial data stakeholders, collaboratively defining the technical standard for financial data sharing, known as FDX API.
As Security is a core principle followed in development of FDX API, it's worth examining one of the ways in which F5 customers can secure and test their FDX deployments.

\n

Architecture

\n

To understand the general architecture of an Open Banking deployment like FDX, it is helpful to visualise the API endpoints and components that play a central role in the standard, versus the back-end functions of typical Financial Institutions (the latter elements displayed as gray in the following diagram):

\n\n

In typical Open Banking deployments, technical functions can be broadly grouped in Identity & Consent, Access and API management areas. These are core functions of any Open Banking standard, including FDX.

\n

If we are to start adding the Security Controls (green) to the diagram and also show the actors that interact with the Open Banking deployment, the architecture becomes:

\n\n

It is important to understand that Security Controls like the API Gateway, Web Application and API Protection or Next Generation Firewalls are just functions, rather than instances or infrastructure elements. In some architectures these functions could be implemented by the same instances/devices while in some other architectures they could be separate instances.
To help decide the best architecture for Open Banking deployments, it is worth checking the essential capabilities that these Security Controls should have:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

WAAP (Web Application and API Protection)	\n \n Negative security model / known attack vectors database \n Positive security model / zero-day attack detection \n Source reputation scoring \n Security event logging \n L7 Denial of Service attack prevention \n Brute-force and leaked-credential attack protection \n Logging and SIEM/SOAR integration \n Bot identification and management \n Denial of Service Protection \n Advanced API Security: Adherence to the FDX API OpenAPI spec Discovery of shadow APIs \n \n
API Gateway	\n \n Authentication and authorization \n Quota management \n \n
(NG)FW	\n \n Layer 3-4 Denial of Service attack prevention \n Prevention of port scanning \n \n
IDS/IPS	\n \n Anomaly detection \n \n
Databases	\n \n Privacy protection for data at-rest \n \n
Client-side protection	\n \n Fraud detection \n \n

\n

One possible architecture that could satisfy these requirements would look similar to the one depicted in the following high-level diagram, where NGINX is providing API Gateway functionality while F5 Distributed Cloud provides WAF, Bot Management and DDoS protection.

\n\n

In this case, just for demo purposes, the notional FDX backend has been deployed as a Kubernetes workload on GKE and NGINX API Gateway was deployed as an Ingress Controller while Distributed Cloud functionality was implemented in F5's Distributed Cloud (XC) Regional Edges, however there is a great degree of flexibility in deploying these elements on public/private clouds or on-premises.
To learn more on the flexibility in deploying XC WAAP, you can read the article Deploy WAAP Anywhere with F5 Distributed Cloud

\n

Automated security testing

\n

Once the architectural decisions have been made, the next critical step is testing this deployment (with a focus on Security Controls testing) and adjust the security policies. This, of course, should be done continuously throughout the life of the application, as it evolves.
The challenge in testing such an environment comes from the fact the Open Banking API is generally protected against unathorized access via JSON Web Token (JWT), which is checked for authentication and authorisation at the API Gateway level. \"Fixing\" the JWT to some static values defeats the purpose of testing the actual configuration that is in (or will be moved to) Production, while generating the JWT automatically, to enable scripted testing is fairly complex, as it involves going through all the stages a real user would need to go through to perform a financial transaction.

\n

As an example of the consent journey an end-user and the Data Recipient have to go through to obtain the JWT can be seen in the following diagram:

\n\n

One solution to this challenge would be to use an API Tester that can perform the same actions as a real end-user: obtain the JWT in a pre-testing stage and feed it as an input to the security testing stages.
One such tool was built using the Open Source components described in the diagram below and is available on GitHub.

\n

The API Tester is using Robot Framework as a testing framework, orchestrating the other components. Selenium WebDriver is used to automate the end-user session that would authenticate to the Financial Institution and give the user consent for a particular type of transaction. The JWT that is obtained is then passed by Robot to the other testing stages which, for demo purposes, will perform functionality tests (ensuring valid calls are being allowed) and security testing (ensuring, for example, known API attacks are being blocked).\n

\n

The API Tester is automatically deployed and run using GitHub Actions and Terraform Cloud. A full pipeline will go through the deployment of the the GCP's GKE infrastructure required to host the notional FDX back-end and the NGINX Ingress Controller API Gateway, the F5 XC WAAP (Web Application and API Protection), and the API Tester hosted on the F5 XC vk8s infrastructure.
A run is initiated by creating a repository branch and, following the deployment and test run, a report is being received via email.

\n

Here's the API Tester in action:

\n

Conclusion

\n

F5 XC WAAP and NGINX API Gateway can provide the levels of protection required by the Financial Services Industry, the current article focussing on a possible security architecture for FDX, the North-American standard for Open Banking.
To test the security posture of the FDX Security Controls, a new API Tester framework is needed and the main challenge that is solved is the automated generation of JWT, following the same journey as a real end-user.
This allows the testing of deployments having a configuration similar to the one found in Production.

\n

For more information or to get started:

\n

Testing the security controls for a notional FDX Open Banking deployment

Introduction

Architecture

Automated security testing

Conclusion

For more information or to get started:

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS

Introduction

Architecture

Automated security testing

Conclusion

For more information or to get started:

Introduction

Architecture

Automated security testing

Conclusion

For more information or to get started:

WAAP (Web Application and API Protection)	Negative security model / known attack vectors database Positive security model / zero-day attack detection Source reputation scoring Security event logging L7 Denial of Service attack prevention Brute-force and leaked-credential attack protection Logging and SIEM/SOAR integration Bot identification and management Denial of Service Protection Advanced API Security: Adherence to the FDX API OpenAPI spec Discovery of shadow APIs
API Gateway	Authentication and authorization Quota management
(NG)FW	Layer 3-4 Denial of Service attack prevention Prevention of port scanning
IDS/IPS	Anomaly detection
Databases	Privacy protection for data at-rest
Client-side protection	Fraud detection