There’s a reason why many residential communities prefer their police officers to live and raise their families in the same close knit neighborhoods they serve and protect. After all, patrolling a district that is ultra familiar to a police officer provides a greater chance for them to notice new or altered activities – or even potential threats that might otherwise be inadvertently glossed over.
The same is true for the mobile apps that we rely upon every day to conduct so many of our daily activities. The mobile apps themselves need constant monitoring and closeknit, developer-driven protections against today’s clever cybercriminals.
App store approval precautions and processes are the first step in ensuring mobile apps function as designed. Both Android and iOS apps typically go through rather extensive approval processes before they ever become available in the app stores. However, neither Google nor Apple can fully look into and analyze the internal workings of an app. It’s not their job. They are focused instead on how the app interacts within the iOS or Android ecosystem – and if the apps function in line with the terms of service and do only limited scanning on security related aspects of the apps. When it comes to protecting mobile apps from cyberattack – app developers and publishers are on their own.
Are mobile apps really at risk? Yes. There have been a host of recent threats, including something called app versioning, where updates of seemingly legitimate apps get malicious code added during an upgrade – code that was not previously there in older versions. And that’s just one attack type example that illustrates how criminals can get their foot in the door and cause havoc even if their rogue update is eventually discovered, albeit too late for victims. Other popular mobile app attacks include:
- Screen Overlay Attack – Malicious code of an app displays an overlay on top of a legitimate app on a device, tricking users into unknowingly interacting with fake interfaces.
- Supply Chain Attack – Attackers infiltrate the software development process by compromising a trusted component, injecting malicious backdoors to gain unauthorized access to the mobile app’s codebase.
- Open-Source Vulnerability – Attackers exploit vulnerabilities in open-source components to exploit.
- Payload Delivery Attack – Attackers deliver a payload to a device through abusing a legitimate, non-protected app.
- Geo-Spoofing – Tricking a company’s legit non-protected app into believing the app is in a different geographic location than it actually is in order to bypass security settings.
Then there are the security solutions that sit on the device (phone, tablet, etc) but are not within the app itself. This is greatly limiting from an effectiveness perspective, as security that sits on a device and not in an app has no way to know what an app should be doing. It can only approach protection from the old school approach of creating a blacklist of threats and malicious apps that can be blocked only once they’ve been discovered elsewhere as a threat. It’s reactive and takes time. Meanwhile, threats seep through and cause monetary or reputational damage to a host of potential parties.
Additionally, there are so many unmanaged consumer devices worldwide that no company or organization maintains or manages. If a company manages employee phones, for example, it can mandate an agent be placed on that phone to closely monitor it. But the owners of the world’s unmanaged consumer devices outside of that small, protected group of employees or users are never going to agree to download scoping-like or inconvenient security agents. Again, not realistic.
So, the answer lies within the apps themselves – the apps that users clearly want or need and prefer to be secure in the first place. They’ve chosen to select an app offered by a specific organization, and they’re holding that organization to account. It’s with this knowledge that more and more app developers are realizing that with in-app security they can exceed third-party on-device security that relies on blacklists by only allowing the app to communicate with whitelisted servers. Not only do they nearly eliminate incognito criminal communications with their app, but they themselves can determine the good, safe places it can talk to – and that’s an enduring difference compared to any security that sits outside the app. On top of that, they receive app-specific protection and app -focused monitoring and countermeasures.
An example of why the whitelist approach is so strategically important surrounds all the types of malware that use a domain generation algorithm to avoid being spotted by continually generating new domain names and IPs for the bad guys’ servers. If it’s not on the whitelist, it’s not happening.
The visibility and intelligence that in-app security can bring to app developers is not only appealing due to the insights it provides about one’s own app, but it can also be critical to a business’s bottom line that is often tied directly to the success of their app in the first place.
In conclusion, the multitude of cyber-related challenges facing app developers and publishers demand an elevated level of security to address the greatly increased risks. Since it’s becoming more and more difficult for hackers to bypass enterprise-level app servers deployed by larger organizations, bad actors look for alternative entry vectors and discover the mobile app path.
Once hardened to help secure the code from attack, mobile apps should be monitored 24/7 for external threats. If threats are detected, appropriate countermeasures need to take place immediately to prevent a cyberattack. By constantly analyzing threat data, some app attacks can even be predicted and prevented. Organizations that proactively protect and monitor their mobile apps can safeguard both their enterprise and their customers from the bad guys.
