Software development is not only about creating a product that operates according to requirements and makes life easier for the user, but also about elements that are "invisible" and whose impact only becomes apparent over time. When developing an app – in addition to architecture, code quality, testing and many other aspects - security is extremely important.
How to handle security is an important question that should be asked at the very beginning of application development, otherwise there can occur any number of security problems like leaks of personal data and / or passwords.
The fact that we are not only mindful of security during the development of clients’ applications, but also within our own company and processes is evidenced by the fact that we have reached the highest grade of security within the strict TISAX certification (Trusted Information Security Assessment Exchange).
Don't re-invent the wheel and don't rest on your laurels
When creating a secure mobile application, it is absolutely essential to follow the recommendations of Apple and Google and add additional, compatible layers.
An important resource for us is the MASVS standard (Mobile Application Security Verification Standard) from OWASP (Open Web Application Security Project). This standard specifies the rules that should be followed during development and divides them into several subgroups according to the sensitivity of the data and operations. Aided by this standard, we are able to quickly comply with universal security requirements before focusing on specific security needs. We don’t need to re-invent the wheel, but we will make excellent ones.
And because the technological world evolves so quickly and operating systems come up with new versions every year, it is important not to rest on one’s laurels. At Futured, we keep track of relevant resources for developers; we are part of a development community that shares specific recommendations; and, we attend conferences where the best in their field discuss security issues. We then pass on the knowledge to each other within the development teams so that we all have a maximum overview of the topic.
Security levels: Which to choose?
For each application, we adhere to a certain standard that eliminates basic security threats. Beyond that fact, there is a simple rule: The more sensitive data an application contains, the more important security becomes.
Although each application is unique, this does not mean that we cannot sort them into basic categories to serve as a guide on how to approach each of them. Unlike the aforementioned MASVS standard, which defines two categories with one extension, Futured uses three basic categories with one extension to better reflect our needs and especially those of our clients.
Steps in determining the security level
- Identify the data and operations with which the application works
- Determine the appropriate level
- Dialogue with the client, during which we go over why we recommend each step and feature how they affect the functionality of the application, and what they mean for the development of the application
I — Standard level
The security minimum that each of "our" applications must meet
Even a relatively simple application, which at first glance may not contain any sensitive data, needs security. Such protective measures are, for example, securely storing tokens in encrypted storage, code obfuscation, or the use of secure communication with the backend. In Futured, this is our basic level.
II — Higher level
For applications processing sensitive data or operations
For applications that work with, for example, financial, health or generally personal data, we recommend using a higher level of security implementation employing a two-factor user authentication at login, biometric application security, certificate pinning, or security against excessive login attempts.
III — Highest level
If security is the highest priority
For applications that perform, for example, financial operations or work in an e-government environment, security becomes the primary focus. The discussion needs to be much more detailed because security needs to be included in all aspects of development. In addition to elements from previous levels, we recommend, for example, working with threat models, having clearly defined cryptographic processes, or a defined disclosure policy.
Additional reverse engineering protection
So that attackers can't see under the "hood"
One possible threat is attacks that employ reverse engineering processes, where the attacker tries to see what is happening in the application or tries to modify it to pass as the original. This can be problematic for applications that work with intellectual property, or when such a modification could give the attacker some advantage, such as cheating in games. We aim to prevent such attacks through a verifiable application signature and / or by obfuscation. In the case of an application where such risk is more significant, we recommend implementing tools such as root / jailbreak detection, reverse engineering tool detection, or more complex obfuscation processes.
Specific approach
Now you know how we think about security at Futured. Although we've broken it down into several basic levels, it's always important to think carefully about the specifics of each application. This is the only way to choose a solution that ensures that the result is not only successful as a good looking product, but also ensures that users’ data are completely safe.
"It takes 20 years to build a reputation and a few minutes of cyber-incident to ruin it." — Stephane Nappo
Let's make something great together!
Contact Lukas, Futured CEO: [email protected] & +420 605 312 459
