1. Version Control

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 includePenetration testing is performed to :

•  Accurately Accurately evaluate organisational ability to defend against the attack

• Obtain the detailed information on actual, exploitable security threats

• Intelligently prioritise remediation activity, apply necessary security patches and allocate security resources

...

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.).

This section covers Open Banking security aspects of the API specification, including:

• 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.

...

Note: The APIs require TLS 1.2 Mutual Authentication and this may be used as a means of non-repudiation. However, it would be difficult to maintain digital records and evidence of non-repudiation if the API only relied on TLS 1.2. A solution for non-repudiation that does not rely on TLS, would be achieved by providing a JSON Web Signature (JWS) with detached content (as defined in RFC 7515 - Appendix F) in the HTTP header of each API request. The HTTP body would form an un-encoded payload as defined in RFC 7797. The JWS would be signed using an algorithm that supports asymmetric keys. A request would be signed by an AISP’s/PISP’s private key and a response would be signed by the ASPSP's private key. Digital signatures are used to provide non-repudiation and authenticity by using public key algorithms. Private and public key is used to encrypt/decrypt the hash of the content. The encrypted hash is called a digital signature. JSON Web Signature ( JWS ) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. The certificate is digitally signed by the trusted Certificate Authority (CA) – the hash of the certificate is encrypted with the private key of the trusted CA.

...

[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.

...