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.

In order to protect the confidentiality, integrity and availability of information and data in the Open Banking ecosystem, all participants should ensure that security is given sufficient profile and influence in their organisation. Recommended areas of security capability include (but are not limited to) Specialist Information Security function, IT Systems Controls around the infrastructure and applications, Penetration Testing, Cybersecurity Function (strategy, policy, governance), Counter Fraud Function, Monitoring and Reporting of threat, etc.

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, Volume 2 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). Penetration testing is performed to :

• Accurately evaluate organisational ability to defend against the attack

• Obtain detailed information on actual, exploitable security threats

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

All systems and infrastructure should be regularly tested for vulnerabilities by an external penetration testing expert. It is recommended that such an expert is professionally accredited.

Penetration testing for all ASPSP, AISPs and PISPs must be conducted by external experts every six months (at minimum) as per the rules laid out in the existing security and Open Banking rules issued by the CBB in Volume 1, Volume 2 and Volume 5 of the Rulebook.

Further, penetration and vulnerability testing may be additionally conducted by AISPs/PISPs/ASPSPs based on the Open Banking release cycle, i.e. every time a major release related to the entities' Open Banking systems, and any minor release that may potentially directly impact/expose any sensitive or personal data of users/customers.

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:

• ASPSPs should retain control over authentication method

• All authentication and authorisation protocols must adhere with OAuth 2.0 and OpenID Connect

Once a user/customer has authenticated with their ASPSP, tokens should be used to ensure the third party is acting within the bounds of the permissions granted. The third-party service should provide evidence that it is entitled to use the authorisation token (e.g. by way of providing a client ID and client secret) to the ASPSP.

Each ASPSP will be responsible for issuing its own tokens and ensuring third parties are in possession of legitimate tokens.

 OAuth 2.0:

• The OAuth 2.0 authorisation framework enables a third-party application to obtain limited access (i.e. set scope) to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its behalf. This specification replaces and obsoletes the OAuth 1.0 protocol

• OAuth 2.0 provides delegated authorisation workflows for diverse applications such as web applications, desktop applications, mobile phones and home automation devices while providing a simple platform for developers to harness

• In an OAuth based authorisation, a consumer requests access to resources under the control of a resource owner. For accessing these resources, the consumer is provided a different set of credentials

• This can be used for accessing the APIs from multiple devices including mobile apps, desktops, etc.

• Further details on the OAuth 2.0 specifications can be found on their website

OpenID Connect (OIDC):

• OpenID Connect (OIDC) is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of simplifying things and works over the existing HTTP standard

• OpenID Connect enables developers to create an authentication mechanism across websites and applications without creating a separate username/ password file combination of their own

• OpenID has the capability to manage multiple types of clients including browser based JavaScript and native mobile applications. Apps designed using OpenID are able to utilise sign-in workflows and receive confirmable assertions about the identity of the user (Identity, Authentication + OAuth 2.0 = OpenID Connect)

• This can be used for accessing the APIs from multiple devices including mobile apps, desktops, etc. in a manner similar to how Google/Facebook single sign-on works across other websites. This can be modified to include the UID as the access token against which an individual or an organisation can be authenticated

• Further details on the OIDC specifications can be found on their website

User/Customer consent for authorisation:

• In the context of data-sharing with a third-party, a principle of informed consent should be adopted. The user should clearly understand the authorisation they are being asked to provide, including:

  • Who they are providing authorisation to

  • What they are providing authorisation for (i.e. what the authorisation will permit the third party to do)

  • How long the authorisation will last for

To ensure accurate adoption of OAuth 2.0 and OpenID Connect (OIDC) frameworks while developing new API profiles, ASPSPs and AISPs/PISPs can leverage security structures and rules set by the OpenID Foundation’s (OIDF) Financial-grade API (FAPI) profile. The Financial-grade API security profile can be applied to online services in order to augment OAuth 2.0 or OpenID Connect. The Bahrain OBF use case API specifications are built keeping the FAPI and OAuth 2.0 principles in mind.

The OIDF Financial-grade API (FAPI) applies to REST APIs with higher risk data. These APIs are protected by the OAuth 2.0 Authorization Framework and other specifications. This profile describes security provisions for the server and client that are appropriate for Financial-grade APIs. Additional information on the FAPI profile is available on the OIDF website and on the links below:

Part 1: Read-Only API Security Profile

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.

API connections and data in transit must be encrypted using TLS 1.2 Mutual Authentication (MA) as a minimum, with a defined set of strong cipher suites.

Transport Layer Security (TLS) 1.2 MA

• TLS was designed with the goal of providing privacy and ensuring data integrity between two communicating applications

• This has two layers:

  • The first layer uses the TLS Record Protocol to encapsulate other higher level protocols

  • The second layer uses the TLS Handshake Protocol which allows the server and client to authenticate each other. The protocol allows negotiation and agreement of a cryptographic algorithm and keys prior to transmission or receipt of any data

• This is a basic level of security that rides on the TCP protocol and HTTPS. All RESTful APIs by default are created to use this as an encryption mechanism

While the participants are required to adhere to TLS 1.2 MA at minimum, they may additionally consider adopting the latest available TLS version.

In order to achieve full FAPI compliance, all Open Banking stakeholders may run an additional layer of AES 128/256-bit encryption of signatures.

The Industry stakeholders may also further consider non-repudiation of messages using digital signatures, and explore the usage and adoption of streaming APIs[1] for reading data, especially for AISP related use cases.

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

Further inputs of the OBC and industry discussions may be submitted to the CBB for further considerations to changes to the security guidelines.

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

• The API must provide support for out-of-band (OOB) authentication:

  • OOB authentication is a type of authentication that requires a secondary verification method through a separate communication channel along with the typical ID and password. Using a separate authentication channel makes it significantly more difficult for an attacker to intercept and subvert the authentication process

  • Forms of OOB authentication include codes sent to a mobile device via SMS, authentication via a voice channel, codes sent to a mobile app via push notifications, and codes sent to or received from a trusted execution environment connected to the host device that is trying to establish an authenticated connection

  • OOB is activity outside a defined telecommunications frequency band, or, metaphorically, outside some other kind of activity "Examples include secure authenticator mobile applications"

• ASPSPs must notify the user/customer asynchronously/OOB when significant actions have occurred (e.g. a change to a payee)

• The ASPSP API response should inform the third party that an OOB process is underway so that, where appropriate, they can inform the user/customer

• ASPSP and AISP/PISP should include fraud-relevant information (e.g. IP addresses, Geolocation) in the API messages

• The reporting of incidents and the process to handle it shall be covered as per the existing guidelines related to cyber risk in the CBB Rulebook

CENTRAL BANK OF BAHRAIN © 2020