When we did the original design for the Okay solution, there was one guiding principle: "Assume that a security breach of the smartphone's underlying operating system has either already happened, or that it is going to happen." 

This principle led to design choices that we've written about before: instead of protecting an entire application, our primary design choice was to focus on the security of the user's authentication and the transaction verification. Why? Because this is the most likely target for an attacker. 

Focusing on a single area made it possible for Okay to implement security mechanisms that would have otherwise been too inconvenient or simply impossible. Examples are our robust secure execution environment or the unique security mechanisms that directly protect against root-level malware. This type of approach was something we decided to name "paranoid security."

Over the last few years, a particular security framework has gained popularity within enterprise security. It is called the "Zero Trust Security Model" and was created by John Kindervag. Kindervag spent years researching with the Security and Risk Team at Forrester Research. The result was a new model of trust, a new approach to cybersecurity, and a security strategy designed to stop the mounting data breaches. (Read more about his implementation, misconceptions, and strategy at helpnetsecurity.com).

While the Zero Trust Model looks at the entire IT infrastructure of enterprises, it also echoes some of the "paranoid security" design choices we made with the Okay solution. That's because the Zero Trust Model, like Okay, saw that network and application security had become very complex.

Such complexity came from the rapidly escalating and evolving nature of adversary threats, making it likely for breaches to occur (or had already occurred) undetected. And, since today's services and applications are distributed, located on cloud services where end-users can run applications anywhere, it makes it much harder to protect these services than ever before. 

Source: Varonis - “What is Zero Trust”

In the good ol' days, any given network-connected PC was typically protected by combining the firewall and antivirus software. Once users had access to the network, they were essentially marked as "trusted," with few limitations to what they could do on their computers or the local network. 

However, in the more modern "Zero Trust" alternative, user access is limited to only what is strictly needed, with anomalous or malicious activity constantly monitored. To make this happen, five steps are taken:

1. Identify the protect surface
2. Map the transaction flows
3. Build a Zero Trust architecture
4. Create a Zero Trust policy
5. Monitor and maintain

We aren't going to go into detail about each of these steps in this post, but we do want to point out that the first step is arguably the most important. That's because the "protect surface" is made up of the network's most critical and valuable data, assets, applications, and services. 

In addition to the protect surface, there is also the "attack surface": the place where an attacker might try to breach security. Considering all the places employees can access company data in an enterprise, the attack surface is typically much larger than the protect surface. This is why the strictest security mechanisms should be as close to the protect surface as possible, where a Zero Trust policy decides what and who should have access to which data.

While each of these steps doesn't protect against any particular threat, it means that if a malicious actor manages to gain access to one app or device, at least the protect surface is still keeping the most sensitive data and applications secure.

As I've described above, there is some overlap between the design principles behind Zero Trust, and the principles used by the applications protecting sensitive data in the Okay solution. These include the following:

1. You need to identify what you should protect in your app. This is typically the user authentication and transaction verifications for a banking app, where Strong Customer Authentication (SCA) is required. Our post on PSD2 compliance can help you with this.
2. All data-flows for transactions should be mapped. If you're a regulated entity (e.g., have a banking license), this is something you should already be doing. 
3. Numbers one and two should help you create an architecture and a policy for how transactions should be protected, both when approved by the user and when data is transferred on the network.
4. And finally, the solution you choose to protect transactions should have a strong solution for monitoring and alerting you if any security issues pop up.

With mobile apps, we see much the same situation as enterprises: there has been a rise in attacks. While both Google and Apple have done a lot to improve security over the last few years, many devices still don't get security updates. And as you may know, if you are an app provider, you're in a much weaker position than an enterprise when it comes to managing your services.

As an app provider, you can't restrict what other applications your users are running on their devices, how strong their passwords are, etc. While some banks restrict payments initiated on devices with out-of-date software, this is not only unpopular with end-users but lends the risk of completely losing customers.

Under the PSD2 regulation, you're also more liable for fraud, as it opens for unconditional refunds, making it even more important to be aware of the security of your apps. You can read more on why you should care about the PSD2 in our blog. 

If you want more of this content, feel free to sign up for new-post notifications through our LinkedIn!