Practice / 02 Continuous security

As we come to the end of this guide to mobile application protection, we’re sure that you’ll now have a clearer view of a few key themes. 

You’ll know your app’s most valuable assets and how attackers target them. You’ll see the importance of creating a threat model. And you’ll understand how protection mechanisms can be combined with security controls to prevent and mitigate those threats.

We hope that something else has become clearer, too: 

Security should be a continuous commitment.

Embracing continuous security thinking might involve a mentality shift. It might not be an easy one to make. But the benefits of shifting left - thinking about security from the very first stage of the app’s lifecycle and then still thinking about it years after its launch and after thousands or even millions of downloads - are clear.

Shifting left - also called security by design - can have a helpful domino effect, too. Best practice in one area tends to lead to best practice in another. And then another. You carry out a threat model which leads you to identify critical assets and potential attack vectors. This encourages you to write secure code and perhaps also to implement enhanced protection. You then need to perform thorough testing on each of these elements, potentially with the help of an external security audit. This can lead you back to reassess your code and your range of protection mechanisms, which can inform your decisions when you next update the app.

Remember, your app is continuously evolving with new features and functionalities. And at the same time attackers are constantly evolving their strategies.

As we’ve said, security should be a priority throughout every phase of the development and app lifecycles. On this page we’ll focus on 9 specific phases that we believe can help you to embrace a continuous security mindset:

Risk modeling means identifying potential risks involving your mobile app and evaluating their probable impact on both the app’s users and your organization as a whole. Threat modeling is one crucial element of this. It’s the process of identifying, analyzing, and prioritizing the potential threats and vulnerabilities that your app may face. This is an important step in the mobile app development process because it helps to ensure that your app is designed and built with security in mind.

Threat modeling is an integral part of continuous security. Not least because it shouldn’t only be carried out before implementation but rather across the whole dev cycle. An associated benefit is that the development team becomes empowered to spot potential security threats from the outset. They’re not left scrambling around at the end trying to fix issues when it might already be too late. 

Earlier in this guide we took you through how to create a threat model and explained why it’s so important. For that reason we won’t go into too much detail here. But it’s an essential starting point for your continuous security cycle.

Secure coding practices involve writing code that’s resistant to attack and isn’t vulnerable to common security threats. Implementing security controls such as access controls, input validation, and encryption can help to reduce the risk of exploitation.

Thinking about potential vulnerabilities and their likelihood to be exploited from the outset is a powerful thing. It means that you and your team will pause occasionally on the development journey to reflect on the costs and benefits of certain actions. Yes, that library might offer exactly the functionality you need, but do you know and trust who has created it? Are you certain that there isn’t any malicious or insecure code that might lead to an attack further down the line? 

Much of the focus of this guide has been on protection mechanisms designed to make your app resilient in the face of sophisticated attacks. It’s critical that these mechanisms cover all four layers of comprehensive protection covered earlier:

Applying these protection mechanisms is likely to be the final stage of the build process. That’s because it’s vital to guarantee the integrity of the final application package and all of the RASP mechanisms it contains against modification and tampering.

Open communication should continue with whichever security provider you decide to collaborate with. Having a transparent relationship with them will benefit you in the long run. There might be distinct ways that their security solution can be configured, for example. Choosing which protection mechanisms to enable can genuinely make the difference between an application achieving certification or not. 

Speaking of a security supplier, make sure that you choose one that values continuous security as much as you do. Their protection products should be security tested, refined, and certified themselves by independent labs - at least on a yearly basis. As we’ve discussed already, threats evolve over time. It isn’t enough for a security provider to simply assume that what worked to block threats last year will be good enough to do so this year. 

Quality assurance (QA) and security testing should be an integral part of the development process. This involves testing the app for functionality and security vulnerabilities, including both manual and automated testing. By testing the app thoroughly, you can make sure that it’s free of security flaws and remains resilient to attacks.

Testing for security vulnerabilities is most effective when it’s done early. Security testing at the end of the process can be extremely risky. It can sometimes be difficult to identify and fix all the vulnerabilities before the app is released. And this can result in launch delays and increase the overall cost of development.

The next step is penetration testing. This is invaluable when it comes to understanding how your app’s features interact with and influence one another from a security perspective. 

Essentially you’re evaluating the security of your mobile app here by attempting to exploit vulnerabilities. The most exhaustive way of doing this involves a mix of Black Box, Grey Box, and White Box testing.

Say you’re developing a mobile banking application and you test it for vulnerabilities. During testing, the team might discover your app is vulnerable to brute force attacks (when attackers try to find a password matching a specific user’s account). Other types of testing may not have picked up this vulnerability. Static analysis, for example, would never uncover this problem. By actively trying to exploit your app much as an attacker would, you can provide the proper remedy early on. 

When publishing your app, it’s important to make sure that it’s only available to authorized users and that the distribution channels used are secure. This involves implementing app signing and encryption, using secure communication protocols, and monitoring for unauthorized distribution or publication.

Monitoring your app is an essential part of maintaining continuous security. This includes monitoring for security events such as attempted attacks, data breaches, or unauthorized access. By monitoring the app, you can identify potential security issues early and take corrective action before they can be exploited.

Remember that how your app is used in the wild can often be quite different to how you imagined. Here at Licel we often use the app as a car analogy when speaking with clients. You can make your car as secure as possible on the factory floor, but once it’s out on the road all sorts of strange and unimagined hazards can present themselves. 

A quality threat intelligence solution can demystify app security by showing you exactly what kinds of threats your app faces on a day-to-day basis.

Users can be a potential weak point in your mobile app security. So, it’s important to educate them on how to use your app (and their mobile device more generally) in a secure way. This includes best practices for password management, avoiding suspicious links or downloads, and reporting any suspicious activity.

Finally on the theme of collaboration we come to your end users. The people you’ve designed your app for in the first place. Try to develop your app with empathy for your end users as a constant thread. This should be a simple thing to do as you’ve already stepped into your end user’s shoes. You do it every day. Whenever you make a quick bank transfer with your mobile banking app. Or whenever you chat with your doctor through your smartphone screen. These are tasks that we all carry out because we trust that those who have developed the application have protected it from the dangers that lurk in the digital world.

Don’t take this trust for granted. Honor it by protecting your application as robustly as your end users expect you to do. The alternative option - and the associated reputational damage to your business that comes with it - isn’t worth thinking about. 

So, you should educate your end users. Be clear with them about how you’ll get in touch so they can learn to spot imitators sending phishing scams. 

Teach them to be sceptical and suspicious. Explain to them that it’s okay to pause for a moment as the rest of the world rushes by around them. Long enough at least for them to ask themselves an important question; do I trust the person or company asking me to click on this link?