Over the last few years, Okay has gone through both security certifications and penetration testing. While they represent two uniquely different processes, each has greatly improved our product’s security, code quality and architecture. In this post, we discuss the importance of each, as well as what we've learned along the way.
In the world of IT and Cybersecurity, security evaluations are an important measure of a company's commitment to providing products with exceptional quality. Although requirements differ across the globe, European security evaluations are now required under various legislation, including the Payment Services Directive 2 (PSD2).
Speaking from experience, we can say that the evaluations have proven to be nothing but useful when reviewing against a set of requirements. In the latest case, this would be the PSD2's RTS (Regulatory Technical Specification).
The RTS contains a list of requirements for products, plus a requirement of regular external audits and an evaluations done by a "competent authority" to help prove, both to yourself and others, that your product matches the provided set of requirements. Depending on the process you use to document your solution, it can also help find logical human mistakes in your implementation.
As part of Okay's evaluation process, we worked with a consulting and auditing company, PROSA Security, which modelled protocols and data flow through our systems. Based on this model, we could automatically see how encryption protected different assets, and whether we made any mistakes with our implementation.
That was quite useful, as it becomes increasingly complex to track how sensitive payment data moves through a system simply by reading the code and documentation.
Penetration testing is a totally different process. Also known as ethical hacking, penetration testing is a fake cyberattack used to identify a system's weaknesses and strengths regarding how well it does or does not protect its features and data.
The partner we chose for our penetration testing, YesWeHack, facilitates the connection between companies and white-hat hackers who are paid bounties if they manage to break the solution's security. When it came time to test Okay, we first defined a set of bounties before inviting a set of hackers to try to break a "hackme" system.
As we guessed, setting up a separate system for penetration testing proved to be a great idea, as penetration testing can lead to serious loads on your systems.
One common way to break into a system is something called "fuzzing". This is when you use software to try every possible API call and argument to see if something breaks.
While we were quite confident about our backend security, we still turned on all possible debug-logging for the "hackme" backend. This led to gigabytes of logs for just a single fuzzing session, and with multiple attackers working on it, the backend eventually ran out of space.
Ultimately, there have been no security issues found by the team of white-hat hackers, but one never knows if that might change.
Okay decided to use SRC gmbh of Germany to evaluate our product. Having emerged from the banking industry, SRC functions as a central link between research, products and services. Recently, our compliance was re-evaluated and we are excited to share that is has officially been approved. SRC was happy to offer the following statement:
“Okay AS makes use of industry-wide accepted best practices in both its design and use of technology, especially in cryptographically securing and authenticating its credentials and its client-
server communication. Therefore, the Okay Secure Platform can be considered a state-of-the-art solution."
Unlock updates, insights, and exclusive content delivered to you.
Security evaluations and penetration testing are useful and necessary tools when trying to pinpoint product issues.
While the formalised method used by security evaluators can be handy in finding logical errors and lack-of-documentation, the practical approach used by security testers motivated by bounties can help you find the bugs in your implementation that were originally missed.
Of course, both approaches require work and can be a bit daunting, but we believe they're both rewarding and worth the effort.
————
Two months after this blog post was published, we re-evaluated our app once more to ensure we were meeting the ever-shifting compliance regulations. You can read about it, and our cooperation with PROSA Security and SRC Gmbh for the re-evaluation, here.