Founders Guide on MVP Security

What mobile app framework to choose from a security angle?

Best of all — stick to iOS if you can. Due to a variety of factors iOS-based apps are much secure than its Android counterparts.

Pay attention to performance and new features — they arrive first tonative dev frameworks, like Swift (Security Guide for iOS) and Kotlin (Android one) first.

On the other hand — the development process would be faster with one of two major rivals — React Native and Flutter, both have security guides (React Native, Flutter).

However, only the former has provided a clear workflow to report a vulnerability. You might end using all four security guides, sometimes hints are pretty universal.

Last but not least — try to use one mobile app dev framework for both Android and iOS if you need both platforms.

A smaller single codebase means smaller attack surface, less effort for code maintenance and review.

How to validate the mobile app security posture before going live?

Here's the deal — a mobile app is like a desktop one, it means there is not just front-end, but back-end options, too.

Thus — check how secrets are stored inside your app, for instance, use MobSF for Android, objection for iOS and AppMon for both Android/iOS.

Next risk are the libraries used — are they vulnerable or not? Otool would visualize them helping understand what you'll need to check.

Last and hardest thing there is the testing of business logic embedded — and there you'll need a human brain with mobile app security testing skills uploaded.

Okay, how to resolve all the security issues within the mobile app?

There's golden truth for mobile app security — if you could use the mobile app as a pure front-end, apply Web App coding style and don't store any secrets inside — this would make your attack surface much smaller.

If not — keep libraries updated and use proven third-party identity providers instead of developing your own — like Google or Microsoft accounts.

What back-end framework to choose from a security angle?

The back-end is API now, these two pieces became one.

Before proceeding you have to know where to get advice on industry-standard proactive controls (go no further — OWASP 10 proactive controls are there).

The second choice — which architecture you would use for API — SOAP, REST or GraphQL. From a security standpoint last is best, use this cheatsheet to build it securely.

Hasura is a good example of a GraphQL oriented back-end framework, and there is no lack of these nowadays.

How to validate back-end / API security posture before going live?

The first line of defence there is the self-validation inside the dev team.

Developers could check their designs using industry-recognized patterns like cheatsheets for logging and microservices.

If you plan to perform aggressive user acquisition you might consider designing security controls very thoroughly — Security Framework for Web security is your assistant there.

The second life of defence there is the static application security testing.

There are hundreds of tools for it, for example Snyk for dependency analysis and retire.js for JavaScript security.

A third line of defence is the business logic security testing, which is usually a manual task requiring a security expert to check your app.

Last but not least — apply continuous monitoring of your API to know what is happening in the field right now,

Resolving security issues in back-end / API

That's a trick— sometimes a fintech startup could pursue a use case simple enough to employ of a Back-end-as-a-Service.

This way, you would not be bothered by a lot of architecture decisions — and a need to fix most of the security issues, but will lose flexibility.

Examples of such options are Corezoid and Very Good Security.

Further reading - you can also check my article TOP-12 API Security Controls, where I explain more about API Limiting and geo-location controls.

What kind of cloud to choose from a security angle?

Basically you could choose from three kinds of cloud — IaaS (like AWS EC2), PaaS (like Google Kubernetes Engine) and Serverless (like Azure Functions).

Each kind could be properly secured, but the last two requires additional layers of API Security — they're usually managed through APIs.

Usually, that's not a problem, and kind of API Gateway is always present even if the cloud vendor is a young one (like Yandex.Cloud).

How to choose a cloud vendor from a security perspective?

Here's a thing — as a Fintech Startup you're a custodian of valuable customer data, so you have to make sure the data is adequately protected. Usually, it sticks to 3 core things:

1. The cloud vendor should have an information security management system in place (ISMS), usually certified under the international ISO 27001 standard by an independent body.
2. The cloud vendor should have it's own Security Operation Center in place to know what's going on on their premises.
3. The cloud vendor should provide a Security Guide for their customers where its security controls are described and customer security tasks are written down.

There are relevant guides from all major vendors — AWS, Azure, Google and even Alibaba.

How to choose a cloud vendor from a compliance perspective?

But wait — security is not the end of the journey for a Fintech startup, there are some compliance questions that have to be addressed when you select a cloud vendor:

1. The residence of your primary customers defines a country where it would be convenient to store their data, so consider using Alibaba for China, AWS\Google\Azure for U.S. or EU and Azure for Russia.
2. The cloud vendor should offer a range of certifications to support yours — ISO 27001, ISO 27018 (security of personal data), FedRamp (for U.S.), MPLS (for China), FZ-152 (for Russia). Sometimes they even offer a guide to support FI specific challenges like PCI DSS guide from AWS.
3. The cloud vendor should provide a way to report vulnerabilities and clear rules for conducting penetration testing. At least some external penetration testing effort is usually required by any security compliance standards.

How to validate cloud security posture before going live?

There are 3 main methods to validate security in your cloud:

1. Use internal tools from a cloud vendor like AWS Inspector or AWS Config — keep in mind, this is not free usually.
2. Use commercial tools from CWPP product category (Cloud Workload Protection Platforms).
3. Use open-source tools or hire an external team of experts for delivering a pentest (it is required by PCI DSS for example).

At the end of the day, you could find 3 main kinds of security issues in the cloud:

1. All kinds of misconfiguration (like open S3 buckets or excessive access rules) and vulnerabilities of components used for application delivery (web servers etc).
2. Misused or forgotten credentials / secrets stored in GitHub where it was convenient for your dev team to store them.
3. Absence of Anti-DDoS controls and weak architecture that leaves you vulnerable to any decent DDoS attack

How to remediate your cloud security findings?

Some security controls in the cloud are just inevitable when you build a fintech app and they could be grouped as shown below:

1. Secrets and sensitive data management — AWS Secrets Manager, AWS CloudHSM and AWS Nitro Enclaves (isolated computing environments) are good examples of these.
2. Identity management is an area which can't be overestimated in cloud management, so pay close attention to who has access to what, including your vendors and partners. There are numerous tools to manage and audit it, both from cloud vendors (like AWS IAM) and free ones (visualisation scripts stored on GitHub like Netflix-skunkworks).
3. Strong cloud edge — Azure network security groups, Azure DDoS Protection, Azure WAF\Application Gateway and Azure Load Balancer are usually required for B2C use cases. Don't forget to set geolocation controls there — they're extremely useful for fintech startups that can't serve a lot of geographies anyway because of legal or AML restrictions.
4. Back-up and disaster recovery controls should be quite obvious and could be delivered via another cloud vendor, possibly much cheaper one.
5. Cloud security centres are kinds of single panels of glass and are essential to speed up any security certification, audit or questionnaire that you would have to pass. Usually, you could use CWPP instead of them, that is a matter of price actually (CWPPs are generally pricier).

Others are configuration changes — which can be implemented by modern approaches like DevOps and IaC, and the most important thing to remember there is to store all configuration changes somewhere like Gitlab or Jenkins.

This was a lot of things to remember— yeah? :)

A most effective way to manage it all is to hire someone well-versed with the security world (or use our DevSecOps-as-a-Service solution).

The second important thing is to select and implement an information security framework — personally, I like PCI DSS as a basis.

The last but not least — once you make sure your business will last for a while, — implement a GRC tool where you would store controls and evidence — even a free one (eramba, SimpleRisk) and stay in touch with new articles in our blog:)