Thoughts on Endpoint Security in an Android/iOS World

Alex LisleAndroid, Enterprise Security, iOS


Android and iOS are becoming the standard for consumer devices. I go into meetings and I see more iPads and less MacBooks.  Sales teams are moving to ChromeBooks. Apple is increasingly bringing OSX and iOS inline with each other. Within the next 5-10 years the majority of endpoint devices within a company will be driven by Android and iOS. 

This presents a problem within the endpoint market. Endpoint security grew up in a different world to Android and iOS. The endpoint model was built to answer the fundamental question, “what is this endpoint doing and is that something bad?” It turns out that answering this question isn’t particularly easy. 

The most obvious way to answer this question is to look at every piece of code which is running on that machine. This is incredibly invasive and grinds the machine down to a halt.  

The current wave of endpoints developed a telemetry based approach. Instead of trying to look at the code before it was going to be run, look at the side-effects which running that code causes, i.e. What system calls are being made? What network connections are being made? What files are being touched? Take all this telemetry and send in to an analytics engine and crunch all this information to determine if something bad has happened.

This approach for the most part worked.  As the endpoint is only reporting events, it has a smaller impact on the device and you can adapt the analytics to fight the changing threat landscapes.  There are trade offs with this type of approach however, the biggest being that you are always being reactive.  You know something bad is happening only after the fact and only if that bad action leaves fingerprints. However, this approach gained traction and showed practical results and many great companies saw success with this approach.

Now comes along Android and iOS.  At first they were tangential to the core infrastructure of companies. But this has changed and, increasingly, companies are trying to figure out how to do security on these types of devices. An Endpoint security solution for Android and iOS is a natural fit. As companies start looking at how to do endpoint on these devices, they look at the impressive telemetry based systems they have created for Windows, OSX and Linux and try to apply that approach on Android and iOS. 

Now, this is where things get sticky. Android and iOS are not Windows and OSX. Android and iOS have been designed with a security model from the ground up. All code must be signed to run. There is a set of explicit permissions which need to be granted to access core parts of the OS and features. Code is isolated and run within sandboxes.  

This presents a problem with telemetry based approaches. You need to be able to see what the device is actually doing but this requires special permissions which effectively allow an endpoint app to circumvent the security model of these devices. When your security app fights against the security model of the OS, you have problems. 

Instead of trying to retrofit a tool built for the last generation of OS’s to fit the new model, a new approach is needed. The key is that both iOS and Android require code to be signed in order to be run. This guarantees that if I download an app from the Play Store which matches the signature of the app on your phone they are exactly the same apps.

This gives us a strong axiom to work with. Given a list of apps and their signatures and the version of the operating systems, we have all the code running on your device. Secure in the knowledge this has to be the case given the axiom of all code is signed.

We can now do a full analysis of that device offline, using static analysis, dynamic analysis, forced path execution. Because we aren’t doing this on your actual device, we know nothing personal can be leaked and also we can be as invasive as needed to fully check the characteristics of the apps.

This has several advantages over the telemetry based approach. Firstly, we are checking all possible paths the code can execute allowing for us to know if the app has the capabilities of doing something nefarious before it does it, rather than reporting after the fact.  It also fits well within the security model, as it doesn’t require special privileges on the device. Additionally, it gives us a much more in depth understanding of what the risks of a device are, not based on telemetry, but based on what the apps on the device are capable of doing.

There is a natural affinity to adapt solutions from now to problems of the future. Changing from what we are comfortable doing to something new can be scary and there is a momentum with keeping with the status quo. However, if you’re prepared to look at things in a different way, things which were a problem can turn out to be a great asset.