16
COMMENT
PSD2 and GDPR: A perfect storm for prioritising API security
Jason Macy, CTO of Forum Systems, explains just how great an impact impending regulation can have on the banks – and what exactly they can do about it
T
he Payment Services Directive (PSD2) will fundamentally impact how banks share their data. Through PSD2, bank customers will grant third party providers direct
access to their finances; an example of this would be paying for your Amazon order without having to enter your credit card or go through PayPal. At the same time, banks are facing the introduction of the General Data Protection Regulation (GDPR), which adds new, stricter requirements for data protection that must to be applied to all data exchanges (while introducing some very stiff penalties to organisations that fail to protect their customers’ data).
So, what does this all mean? How do banks secure this data? Both reasonable questions, as it appears PSD2 and GDPR are asking banks to do the impossible. They must find ways to provide their customers’ sensitive data for Open Banking, while at the same time meeting GDPR’s strict requirements for authentication, authorisation and data privacy of this data. This is like asking banks to keep their doors open and locked at the same time!
The convergence of PSD2 and GDPR has prioritised the need for banks to look at their APIs, and more importantly, their API security. And it’s about time too. While high-profile data breaches have become a part of daily news, those specifically attributed to API vulnerabilities are starting to grow at an alarming rate. Just look at the fallout from Equifax’s recent data breach which reportedly affected 143 million Americans and cost the jobs of its CIO, CSO, and later even its CEO, or Instagram’s embarrassing API breach which leaked the email addresses and phone numbers of high profile users, including a very unhappy Justin Bieber.
The security industry at large is also starting to wake up to
API security. For the first time ever, unprotected APIs were proposed among the first draft of the top 10 vulnerabilities facing web applications today (2017), according to the Open Web Application Security Project (OWASP), which monitors the global security landscape. While unprotected APIs were subsequently removed from the top 10 in a later revision, the fact it was debated for the first time shows the ubiquitous use of APIs today and has given the threat a much great focus in the security industry going forward.
The need to weather the storm with API Security Gateways
API security gateways are perfectly positioned to protect banks against the coming PSD2/GDPR storm because they protect both data and user access at the point at which it enters and leaves the bank’s own systems (i.e. the API gateway). These are the two convergent requirements of PSD2 and GDPR. From a practical point of view, they are also very efficient, since they ensure security is embedded within the network itself, and not the apps that access the APIs. This leaves API/app developers to focus their time on improving the functionality of their applications, because they know the API security is already taken care of. Security, just like app development and everything else in life, is best left to the experts after all.
API threats are the dark side of modern innovation. They underpin everything we do today, from banking to shopping to controlling our smart devices. But it is banking APIs – with their direct access to our savings and investments – that represent the biggest prize for those looking to exploit API vulnerabilities. With GDPR and PSD2, we may finally have the focus we need to close these doors.
www.ibsintelligence.com | © IBS Intelligence 2017
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52
