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