If you haven't heard of it there is a new banking directive in the U.K. called the Open Banking Directive. This directive went into effect on January 13, 2018. It's significant for U.S. based banks, because this Directive could apply pressure stateside if this Directive is a success.
What is the Open Banking Directive?
In August 2016 the United Kingdom Competition and Markets Authority (CMA) issued a ruling that required the nine largest banks Barclays, HSBC, Lloyds, Santander, Allied Irish Bank, Danske Bank, Nationwide, Bank of Ireland or RBS Banks to participate in the Open Banking Directive. At that time over 80% of UK citizens bank with one of the Big Nine banks. The Open Banking Directive seeks to open accessibility to banking data by allowing third party providers the ability to develop applications that innovate the financial services industry. Some examples of the intended innovation include providing new ways to apply for loans, issue bill payments, transfer money, monitor egregious fees. The Directive, in affect, would and could render banks as the financial ledger or record but the transactions would be conducted via third party applications.
Open Banking also part of a sweeping piece of European legislation known as the second Payment Services Directive, or PSD2. Sometimes the two get confused: essentially, Open Banking is the UK version of PSD2. The difference is that whereas PSD2 requires banks to open up their data to third parties, Open Banking dictates that they do so in a standard format.
Starting in January 2018, with your approval and consent, every major bank in the U.K. must send a list of your banking transactions to a third-party. If you want to give a third-party money management application all of your banking data, your bank must comply--and if that application recommends you switch to a different bank for a better deal, your bank must comply with all laws and regulations.
There are very few restrictions on who can become a third party application provider, other than accreditation and regulation by the Financial Conduct Authority (FCA).
Enforcement of the Open Banking Directive
The system is being set up by Open Banking Limited, a non-profit created specially for the task. However, enforcement rests with the Competition & Markets Authority. Protection for consumers will be done by the banks (for payments) or the Information Commissioner's Office (for data).
Securing Open Banking Web Applications and APIs
At no point in the Payment Services Directive or the Open Bank Directive do the regulations require security as part of the third party application in order to connect to participating banks. The only thing that is covered is consumer privacy and consent, which is a good thing, but it NOT security. As a reminder, data privacy is not data security and data security is not data privacy; but you need both to ensure good data protection hygiene.
I have not seen an Open Banking Web Application Checklist, so hopefully this is a good starting point for some.
1. Ensure HTTPS: This one is pretty simple but HTTPS protects authentication credentials in transit for example passwords, API keys, or JSON Web Tokens. It also allows clients to authenticate the service and guarantees integrity of the transmitted data.
2. Security Tokens: There seems to be a convergence toward using JSON web tokens as the format for security tokens. JSON web tokens are JSON data structure containing a set of claims that can be used for access control decisions. If you are looking for more on JSON formats, here's a good starting point.
3. Access Control: Non-public rest services must perform access control at each API endpoint. Web services in monolithic applications implement this by means of user authentication, authorization of logic in session management. To this right at scale, user authentication should be through a centralized Identity Provider which issues their own tokens.
4. Input Validation: Anyone developing for a while knows this is a requirement. If you don't sanitize inputs your application days are numbered. Contact me if you want the full-list on this one.
5. Restrict HTTP Methods: Apply a whitelist of permitted HTTP Methods (e.g. GET, POST, PUT) and make sure the caller is authorized to use the incoming HTTP method on the resource collection, action, and record. Leverage 405's when rejecting all requests not matching the whitelist.
6. API Keys: API Keys can reduce the impact of denial of service attacks. However, when their issue to third-party clients, they are easy to compromise. There are a couple things you can do to mitigate security risks including require API keys for every request to the protected endpoint. You can also returning a 429 message "too many requests" if the volume of requests are to high. Do not rely solely on API keys to protect high-value resources.
7. Validate Content Types: A rest request a response body should match the intended content type in the header. Otherwise this can cause misinterpretation at the consumer/producer side lead to code injection/execution. Some additional things to think about:
- Validate Request Content Types
- Send Safe Response Content Types
8. Manage Endpoints: There is a couple things you can do to securely manage your end points. Avoid exposing your management and points by way of the Internet. If your management and points must be accessible to the Internet, make sure that all users authenticate using strong authentication mechanisms such as multi factor authentication. Security by obscurity is not always a good strategy, but exposing management endpoints by way of different HTTP ports or host on different/restricted subnets can also reduce some risk. Lastly restrict access to these endpoints by firewall ACL's.
9. Error Handling: Keep error message is generic in nature. Try to avoid revealing details of any and all failures when necessary. This will help prevent giving the potential attackers the information they need to game the system or perform a secondary attack with the new information.
10. Security Headers: This one is sometimes overlooked, but to make sure the content of the given resources is interpreted correctly by the browser, the server should always send the "content-type" header with the correct content type, and preferably the "content-type" header should include a charset. The server should sent the "X-Content-Type-Options: nosniff" security header to make sure the browser does not detect a different "content-type" that what is actually sent as that can lead to XSS.
11. Cleanse Sensitive Information in HTTP Requests: Penetration testing companies make a living on gleaning sensitive information from HTTP requests. When using RESTful web services should be careful to prevent leaking credentials. Passwords, security tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.
- In POST/PUT requests sensitive data should be transferred in the request body or request headers.
- In GET requests sensitive data should be transferred in an HTTP Header.
12. Cross Origin Resource Sharing (CORS): CORS is a W3C standard to flexibly specify what cross-domain requests are permitted. By delivering appropriate CORS Headers your REST API signals to the browser which domains, AKA origins, are allowed to make JavaScript calls to the REST service.
- Disable CORS headers if cross-domain calls are not supported/expected.
- Be as specific as possible and as general as necessary when setting the origins of cross-domain calls.
13. Audit Logs: Write audit logs! I can't stress this enough - I see many organizations that do not log their web activity before and after a security related event. The result is those organizations can not appropriately investigate or remediate a security problem on in their application.
If you have a web application or API's you are looking to secure, visit OWASP for more information - they are a tremendous resource for getting started. If you have a web application you are confident in but want security support then contact us for penetration testing services and vulnerability remediation support.
