Editor's note: This post was originally published in September 2022 in IDG TECH(talk).
Agentless security for mobile is an approach that promises businesses protection from attack without having to add any security related software into their mobile apps. In this article we will look at the pros and cons of adopting this approach compared to alternative mechanisms.
‘Agentless’ and ‘no code’ security approaches are commonly touted as appropriate for protecting mobile centric businesses and it’s easy to see why this resonates with development and DevOps teams equally. We are all familiar with the time it takes to release new mobile app versions and more importantly how long it takes for users to update their apps in the field, enabling companies to retire older mobile app versions. As a result, when it comes to considering whether to add a new SDK to your mobile app then the question “do we really need to do this?” is sure to be asked by someone!
This article will help organisations to answer that question in a reasoned and logical way, because it is not as simple to evaluate as you might think. Let’s look at some of the main things to consider.
There is an argument that all API traffic can be treated equally, regardless of where it comes from, or rather where it claims to come from. As convenient as this is to believe, it is rarely true. Consider first the variation of potential sources of traffic:
To give an idea of scale, the Imperva 2022 Bot Report concludes that 42.3% of web traffic is automated and 27.7% of the total is from bad bots. This implies that each of the above categories represents a significant amount of traffic.
Next, consider the medium used by API traffic. Backend servers could be communicated with by any of the following:
Once you recognize that almost all source and medium combinations are possible, and you consider that each combination has a different risk profile, it becomes clear that all web API traffic is not equal and further it is extremely important to be able to confidently know from what and from where API requests have come.
Mobile is at the extreme end of the risk spectrum because apps contain significant amounts of valuable business logic and because anyone can download them and study them for as long as they want. For mobile, it is vital to know that a genuine app, running in a safe environment, is making API requests.
Most things in life require compromise and security is no different. If it was possible to determine with 100% certainty the exact source and medium by simply examining every API request in your backed environment then of course you would do that.
However, such certainty is not possible and the best that can be hoped for is that the majority of fraudulent requests will be caught, the ones that get through will not be too significant and that false positive numbers (identification of fraudulent requests which later turn out to be from genuine users) don’t impact your customer experience too much.
Given these uncertainties, if it was super easy to drop a software agent into your mobile app which signalled to your backend with each API request that the mobile app is present, is unmodified, is not being manipulated by a hacker on a compromised device, and is not a bot or script, that would seem like a solid step to take in order to provide certainty at the edge.
Much is made of the ‘cost’ of having to add software agents to mobile app but the real ‘cost’ is the tradeoff between how easy it is to do and how much value it brings to your overall security risk profile.
Expanding on the previous point, there are a number of security risks associated with mobile apps:
It’s not credible to imagine that you can differentiate between each of the above 4 cases just by what you see in an API request on its own. It’s often said that in security, context is everything and this situation is a prime example of that.
Any backend behavioral analysis approach needs to look at a sequence of API requests and their timing in order to reach any sort of conclusion. This requires the analysis to train itself and even then when it is applied to live traffic there is a danger of false positives - where some valid behavior falls outside the previous training and gets rejected. Further, when significant upgrades are made to your platform, the previous training data may be invalidated for a period and cause interrupted service to genuine customers as well as nefarious activities passing through unnoticed.
To ensure that you only process requests by genuine users running genuine apps on safe mobile devices, you must have context; you must have a positive security approach based upon unspoofable proof that the request is what it says it is and comes from where it says it comes from.
Another of the arguments made against adding a software agent into a mobile app is that you need to update your mobile as new threats emerge or you want to adjust your security policy. If this is true for mobile solutions you are looking at then it is certainly something to consider.
That said, if minor adjustments to security detections and policies can be delivered instantly over-the-air to deployed mobile apps, then this argument against software security agents in mobile apps is significantly diminished.
Further, if sensitive data such as app secrets used for API access and certificates used for API pinning can be delivered just-in-time to deployed apps, the argument against software agents starts to look weak.
When ‘agentless’ security is proposed for API-centric businesses with a strong mobile element, the cost consideration that is proposed focuses on the development, monitoring and management costs of having to deal with additional software in your mobile apps. There is of course a real cost associated with that but if that cost is relatively low and it enables you to have true certainty about the veracity and authenticity of your incoming API requests, it is probably worth it.
The true cost of attempting to deal with the security of mobile traffic purely at the backend is the cost of dealing with:
It’s very important, as you assess potential security solutions for API and mobile protections, that you consider all the costs involved. It’s tempting to just look at the development implications of each solution, but remember that your platform will be in production for a lot longer than it is in development and you must consider the full lifecycle costs of your choices.
Security has always been about layers of protection. It’s never been about shift left (secure code development) or shield right (secure deployment), but a mixture of the two. Similarly for the cost implications of security solutions - you need to think through the development costs incurred as well those related to running, monitoring and managing your platform.
On top of that, it’s worth remembering that stopping threats as early as possible in your deployed infrastructure is very cost effective too. After all, why have the costs of processing traffic in your backend when you can already identify at the edge that it is not coming from a genuine and trusted source?
There is a place for backend API traffic analysis as one tool in your toolbox to protect your platform from the many and varied attacks it will face. But it, just like any other tool in that box, does not solve every problem. Specialized tools have always been needed for specific tasks. They often bring cost savings on their own which more than justify their individual costs, and that has never been more true than it is now.
If you are curious to know more, or to understand how easy deploying a mobile security agent can be, please request a meeting with one of our security experts.