By Alex Omelchenko, Chief Security Officer at Paydock
In a world of increasing numbers of systems that need to work well together, APIs form an important piece of the puzzle.
APIs are necessary. They allow online systems and products to ‘talk to each other’ in near real time and (in theory) secure ways. They speed up business, reduce costs and provide better experiences for consumers. However this interoperability of systems can also lead to risks as the front door can be unlocked, as one would expect, by API ‘keys’. However with great power comes great responsibility, and APIs are about the most powerful things on the internet today. The invisible piping behind the scenes holding it all together.
Unlike what our web browsers tell us, the biggest risks are often not related to how many magic characters are in your less-than-90-days-old-password, but are via these other computer-language digital passwords. Any developer, knowing the URL to access can usually often figure out to use these keys to go for a roam inside the house. API keys really are the keys to the kingdom.
For sure, an open, or unsecure API endpoint is a deep programmatic sin, however in this world of endless integrations, de-integrations and re-integrations, it’s possible to be sympathetic to how this took place.
To eradicate the risk of this happening to your organisation we have compiled four key principles that you can review (and hopefully apply) as you consider your security posture as an organisation. We hope these lessons from our experience and knowledge will be valuable to you.
Handy Security Checklist
The following checklist forms a component of our broader internal security best-practice posture as it relates to API access, and might be most valuable to merchants who may be currently reviewing their own security posture in response to this week’s news.
 1. Authenticate Access
Endpoint authentication must be employed by default. This is the first, mandatory step. Inevitably, you will end up having some endpoints which will need to be public (though this does not mean unauthenticated). In this case, take a step further and carefully curate and maintain an allowlist of public endpoints and require authentication for all the other endpoints.
 2. Limit Access – Time-and-Scope Limited Tokens
API Access should only be granted to a limited scope of endpoints, with limited scope of methods (read, write or update). For example, we enable merchants to create unique access tokens (similar to API keys) to our services while also defining an expiry date. Access tokens can be generated with fine-grained permissions for specific actions on particular resources while also defining white or black lists of IP addresses to be used from. These methods of restricting resource access dramatically narrows the potential attack surface.
One benefit here is that even if a developer forgets to remove a token following integration (as can happen), access will expire in the background closing out the risk. Master tokens or keys can be managed by the central security function. Many payment systems do not have this ability to manage fine-grain permissions and introduce appropriate access expiry, and so our orchestration overlay increases the robustness of any end-to-end modern payment solution.
While universal API ‘master keys’ are still around, there are better ways to structure access and rotate limited-permission tokens now.
 3. Layered Security – 2FA and Password Recycling w. SSO/SAML
Access to systems that can be used to create access tokens should bemanaged under 2FA, password recycling and SSO/SAML regimes. A single password is not enough anymore. Utilising multiple factors of authentication is necessary.Â
4.  External Penetration Testing Must Be Ongoing
It may be obvious, but the PCI-DSS certification that Paydock adheres to ensures regular external penetration tests. Whether you are required to be PCI compliant or not, we recommend ensuring external penetration tests are regularly conducted along with endpoint scanning. This will flush out any exposure not removed using the above steps.
This is not a one time exercise, as hackers are always finding new ways to exploit vulnerabilities, even as your developers may accidentally open back doors in their day to day work.
There is of course much more that could be done, but these four easy steps could materially reduce any attack surface and help you sleep at night.Â
Interesting, but what does this have to do with payments orchestration?
Handling sensitive or secure data correctly is the cornerstone of consumer trust and individual privacy. In the payments sector, we are aware of the same risks and orchestration provides some comfort to merchants.
The risk area we solve daily is where merchants and corporations need to ‘stitch’ these vital systems together with resources from their internal teams or third party IT contractors. The problem is when these resources head on to their next contract or assignment, they can, through human error, sometimes leave API keys hardcoded in code or possibly leave an endpoint open (possibly used for testing). It can happen. API keys can also be copy-pasted into third party messaging, email or text services, not easily picked up in a data loss or scanning systems, even if split into multiple parts.Â
Prior to Paydock’s inception, we saw many merchants working with 3, 4 or more payment systems each handling secure payments data but not always protected to the extent required. Juggling PCI-DSS requirements and handling the back-end-forth shuffle of sensitive payments information across these platforms via numerous API keys for each system, under their own different security regimes is a significant load for any CIO and the complexity gets exponential as more and more services come into the modern payment mix. As the number of payment, authentication and authorisation systems increases, so do the risks and chances of a breach.
Payments orchestration provides a highly secure remedy for this inherent risk in the industry. Ensuring the entire end-to-end flow is wrapped in hardened API protocols, regularly tested by external penetration tests and can be underpinned by narrow time and scope limited access tokens, organisations can be comfortable their systems are secure. Remember, hackers will follow the path of least resistance, so a hardent posture is a significant deterrent in itself.
Payments orchestration with Paydock minimises data breach exposure exponentially, in the same way as not using a security focused overlay solution to defend third party API endpoints expands it. We’re proud to be helping merchants significantly harden their end to end payments security stance and if we can help in any way please connect.
