Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
maxLevel1
stylenone

1. Version Control

Version

Date

Description of Changes

Bahrain OBF v1.0.0

25th Aug 2020

Initial Release

2. Overview

This chapter covers the key considerations for security that would be essential for the Bahrain Open Banking ecosystem and applicable to ASPSPs and AISPs/PISPs. The PDPL and the CBB Rulebook provide direction on multiple internal security controls, processes and rules for adherence by ASPSPs and AISPs/PISPs. The objective of the chapter is to provide additional guidance and best practices on leveraging globally accepted and widely adopted security standards to help create a more robust/secure Open Banking ecosystem in Bahrain. 

In all cases, external assurance and certification of Information Security adherence is preferable to self-certification.

3. Open Banking System Security Guidelines

It is recommended that all stakeholders in the Open Banking ecosystem must align to ISO27001: 2013 standard and may consider referring to OWASP API security and NIST SP 800-95 secure web services while developing the standards.

...

All ecosystem participants (ASPSP/AISP/PISP) must ensure compliance with existing guidelines published by the CBB on cyber risk, cyber and internet security (CBB Rulebook Volume 1 and Volume 5).

3.1 Vulnerability Assessment and Penetration Testing

Penetration testing systematically probes for vulnerabilities in applications and networks and should be undertaken in a controlled manner (to minimise any impact on live operations). The benefits of penetration testing include:

...

Vulnerability assessment of business critical systems, servers and appliances should be conducted on a periodic basis (atleast every quarter) in compliance with the requirements of the NIST 800-53.

4. Open Banking API security specifications

All participants must implement the Open Banking security aspects of the API specification, including authentication, authorisation, access levels, permission and encryption. The following API security specifications leverage the OpenID foundation’s financial API (FAPI) to read and write an API security profile. This specification is published on the OpenID Foundation website - openid.net (OpenID Foundation, a non-profit international standardisation organisation of individuals and companies committed to enabling, promoting and protecting OpenID technologies, is working to ensure that the profile is maintained as a world-class security standard which provides the very best protection available for all users/customers.).

...

  • Authentication and Authorisation

  • Data Encryption

  • Fraud Detection and Monitoring

 4.1 Authentication and Authorisation

The process through which a user/customer authenticates itself to its data attribute provider or ASPSP (in order to further authorise third party access) will be a tripartite process and should be designed to minimise digital friction. Specifically:

...

Part 2: Read and Write API Security Profile

4.2 Data Encryption

API connections and data in transit should be encrypted to ensure that all data in transit is safe and secure.

...

[1] Streaming APIs enables a subscription for receiving events in near real time using push technology. Streaming APIs invert the conversational nature of REST and enables the ASPSP server to send information to an AISP/PISP when an update is ready. While the AISP/PISP can, in theory, request an update, the streaming server of the ASPSP should pre-empt this with updates as ready. Streaming API reduces the load on the system by reducing the number of API calls thereby improving performance.

4.3 Fraud Detection and Monitoring

In addition to the counter fraud function, all participants must include completed risk indicators within their payload to facilitate strong security across the Open Banking ecosystem and aid fraud detection and prevention.

...