The impact of 46% of organizations reported experiencing fraud in the last 24 months, these fraud attempts can range from revenue streams disrupted, damage to reputation and customer trust erosion.
PwC’s Global Economic Crime and Fraud Survey in 2022 found that Fraud scenarios and they are getting more and more common with every passing day, from technical approaches to social engineering methodologies to obtain information. The motivation of attackers to hijack the resources of companies and individuals, flowing through mobile applications, is very high. According to an article, the price for a credit card with substantial balance inside can be bought for 120$ USD on the dark web. Similarly, fraudsters in Indonesia exploited a vulnerability in a ride-hailing app and were earning 650$+ USD every single day, causing disruptions in revenue and eroding the trust of its users.
While there may be many ways to conduct fraud, both technical and socially powered, the end-goal of an attacker remains same: either to receive recognition, cause sabotage for any reason or to earn money. Therefore, it is important to assess the technological landscape of your company for security vulnerabilities in order to better identify these risks and apply mitigation practices in the best way possible.
In general businesses are hesitant in investing in security, many business leaders believe, for various reasons, that their applications are “good enough”, that they have utilised the skills of the top developers who understand the best practices of DevOps. Furthermore, implementing security does not have direct ROI, which is also a bottleneck in getting approvals. However, the reality is, security is important, to say the least. The investment into the security of your resources protects and brings value on many levels and forefronts, such as uninterrupted business, trust of customers, allowing C-level to focus on operations such as expansions, product improvements through their channels.
As businesses move towards a more mobile-front approach for interfacing with their customers, its crucial to protect that channel to protect the revenue resource and retain customers. In general, protection of mobile applications can be achieved through gearing up the mobile application against root/jailbreak, emulator, hooking, cloning attempts. It can be hardened further by protection against more sophisticated attacks such as side channel attacks and static analysis techniques. An additional step to protect the mobile application is to then protect the resources bundled with the application and those generated at runtime. But then the question is: Is it enough?
Is it the best practice to provide all the armour in the world to the application and send it out to the battle? Not at all.
The best way to protect the application is to provide an architectural pattern in which the protected mobile application (in-app protection) can communicate with the Backend servers to provide the necessary input regarding the state of security. The application should be able to send signals on the threat scenarios in real-time so that the SOC centre can act, either automated or manually, in order to protect the resources of the company and its customers (in-app monitoring and control).
In-app Monitoring and Control, what is it, how does it work?
So, lets dive a bit more into in-app monitoring, what is it, what features does it consist of – what scenarios fuel the need for these set of functionalities and what can each counterpart get out it.
In-app monitoring and control is the ability of the mobile application to work in conjunction with Backend components to:
- Understand the ever-present and emerging threats.
- Act on that insight as per security policies.
- Understand the ever-present and emerging threats.
The threat surface of mobile applications increases as the value of the service, or the data being processed through it increases. Attackers will experiment with instrumentation frameworks, in most scenarios, to get the most out of the vulnerable application. Some of the attack scenarios for mobile applications look like this:In an ideal situation, the application not only protects from these scenarios but also informs the SOC teams of the ongoing or attempted attacks scenarios. With in-app monitoring, it is possible to understand the active threats and take necessary actions against the threats.
Action on threat insights per security policies.
Upon detection of active threat scenarios, the ones mentioned above, two potential responses can be generated by the service provider, Remote Lock & Remote Wipe.
Remote lock means that the application logic will be locked from further use, possibly the end-user would have to do some sort of step-up authentication in order to gain the access back, to read more on remote lock and remote wipe, check this Build38 article. The possible triggers for this kind of response come from the violation of basic security policies, such as using an application on a rooted/jailbroken phone, emulator, hooking framework detection and so on.
Remote wipe is more serious than remote lock, as in the name, the application data will be wiped from secure storage upon detection of maleficence. This ability to exercise control over the end-user’s application via Backend query is the result of a breach of security policies set by the company.
Both these features give the Service Providers the ability to:
- Have better implementation of the security policies.
- See the policies in action and be able to retrospect on them given the real-world scenario.
- Firsthand identification and response in an active threat scenario.
Use cases of Remote Lock and Remote Wipe
Some scenarios in which the Remote Lock or Remote wipe features can come in handy, included but not limited to, are:
- Theft of the mobile phone of the end-user.
- Loss of mobile phone.
- Attacker, unknowingly gaining access to the mobile phone.
- Discovery of vulnerability in a certain set of devices/OS.
- On-going attack on the mobile application.
- Major flaws/bugs found in the code of your application.
In the above-mentioned scenarios, it is important to extend the capabilities of your mobile application, from in-app protection to in-app monitoring and control, to protect your mobile-first business to the maximum. With the help of these additional controls, the Service Providers can extend the control, depending on the scenario, from:
- A single instance (one user; attacker or legit reason)
- A certain type of device/library (device/OS vulnerability)
- The whole library (major bug or vulnerability)
- This Backend-based decision-making for exercising control over critical operations is highlighted and required by standardization such as PCI, eIDAS, and PSD2 among others.
As a provider of mobile application security, Build38 not only provides Runtime Application Self Protection (RASP) but also in-app monitoring through fine granular control mechanisms necessary for providing uninterrupted service. Build38 delivers these capabilities to protect Business Critical Applications in Mobile Payment and Banking, Mobile Identity, Digital and Mobile Healthcare and many more. You can explore the references and case studies available in our Resources section. Moreover, reach out to us today to understand further how Build38’s security can help your company. Get a demonstration and Free Trial so you can experience the power of Mobile App Security right now.