Increasing smartphone adoption rates coupled with the rapid growth in smartphone application counts have created a scenario where private and sensitive information is being pushed to the new device perimeter at an alarming rate. The smartphone mobile device is quickly becoming ubiquitous. It is not inconceivable to predict, in the near future, a world where smartphone and mobile device Internet usage becomes the de-facto standard for average business and personal consumer use, surpassing the desktop and laptop computing solutions. While there is much overlap with common operating system models, the mobile device security model has some distinct points of differentiation.
Many of the security models and paradigms used in the general computing environment translate well to the mobile smartphone device. However, there is also an increased threat landscape that should be identified and studied if we are to escape from making the same mistakes of a decade ago. To this end, this post defines a security stack that can be used as a method to analyze the security mechanisms of the mobile computing environment.
Breaking the security model into well-defined groupings will allow for future mobile feature developments to be analyzed based on their location in the security stack and will ideally allow security practitioners and system designers/developers the ability to refine the security of a mobile device in a comprehensive fashion.
The mobile security stack can be broken up into four distinct layers. The lowest layer of the stack is the infrastructure layer, followed upward by the hardware, operating system and application layers. These security stack layers each define a separate section of the security model of a smartphone or mobile device.
The infrastructure layer is the lowest and thus most supportive layer of the mobile security stack. This layer is the foundation that supports all of the other tiers of the model. The majority of the functional components at this layer are owned and operated by a mobile carrier or infrastructure provider; however integration into the handset occurs as data is transmitted from this tier upward.
Cellular voice and data carriers operate the infrastructure that carries all data and voice communications from end point to end point. Due to this fact, we must rely on the cellular carrier for the security of these components of the model. However, just because one must rely on a third party vendor to provide security does not mean that we should not enumerate and include the security of components at this tier in the security analysis of our devices. It simply means that we have to work in concert with a third party to effect any changes or modifications to the security infrastructure that are required.
The security of components at this level typically encompasses the protocols in use by the carriers and infrastructure providers themselves. Examples of such protocols include code division multiple access protocol (CDMA), global system for mobile communications (GSM), global positions systems (GPS), short messaging systems (SMS), and multimedia messaging systems (MMS).
Due to the low foundational nature of this particular security tier, flaws or vulnerabilities discovered at this tier are generally effective across multiple platforms, multiple carriers, and multiple handset set providers.
As we move up the stack to the second tier, we are moving into the realm of a physical unit that is typically under the direct control of an end user. The hardware layer is identified by the individual end user premise equipment, generally in the form of a smartphone or tablet style mobile device.
With the continued advancements in mobile technology, the hardware layer has progressed from generic feature phones to fully functioning mobile computing systems with as much power and usefulness as many of the desktop computing counterparts.
The hardware layer is accessible to the operating system allowing for direct control of the physical components of the unit. This hardware is generally called the “firmware” and is upgraded by the physical manufacturer of the handset and occasionally delivered by proxy through the phone carrier. The infrastructure interfaces with the firmware when passing data up the stack, while the operating system integrates with the firmware as a lower level computing base.
Security flaws or vulnerabilities discovered at this layer typically affect all end users who use a particular piece of hardware or individual hardware component. If a hardware flaw is discovered in a single manufacturer’s device, it is more than likely that all hardware revisions using that similar design and/or chip will be effected as well.
The third tier from the bottom in the mobile security stack is the operating system layer. This layer corresponds to the software running on a device that allows communications between the hardware and the application tiers. The operating system is periodically updated with feature enhancements, patches, and security fixes which may or may not coincide with patches made to the firmware by the physical handset manufacturer. Depending on the hardware in use, the operating system may be secured by the same organization as the hardware or potentially by a third party.
The operating system provides access to its resources via the publishing of application programming interfaces. These resources are available to be consumed by the application layer as it is the only layer higher in the stack than the operating system itself. Simultaneously, the operating system communicates with the hardware/firmware to run processes and pass data to and from the device.
Operating system flaws are a very common flaw type and currently tend to be the target of choice for attackers that wish to have a high impact. If an operating flaw is discovered, the entire install base of that particular operating system revision will likely be vulnerable. It is at this layer, and above, where software is the overriding enforcement mechanism for security. Specifically due to the fact that software is relied upon, the operating system, and the application layer above, is the most common location where security flaws are discovered.
The application tier resides at the top of the mobile security stack and is the layer that the end user directly interfaces with. The application layer is identified by running processes that utilize application programming interfaces provided by the operating system layer as an entry point into the rest of the stack.
There is a fine line between the operating system and application tiers allowing for some grey area blurring based on specific definition. For the sake of discussion we refer to any process outside of those provided with the operating system core as the application layer. These applications come in the form of services and user applications that general have an interface either with the outside world or the end user of the device directly. In the model this line can be shifted slightly as appropriate to accommodate for your specific requirements.
Application layer security flaws generally result from coding flaws in applications that are either shipped with or installed onto a mobile device after deployment. These flaws come in classes that are similar to the personal computing area. Buffer overflows, insecure storage of sensitive data, improper cryptographic algorithms, hardcoded passwords, and backdoored applications are only a sample set of application layer flaw classes. The result of exploitation of application layer security flaws can range from elevated operating system privilege to exfiltration of sensitive data.
When analyzing an individual device for security implications, one should take into account each of the layers of the mobile security stack and determine the effectiveness of the security mechanisms that are in place. At each layer determine what, if any, security mechanisms and mitigations the manufacturer has implemented and if those mechanisms are sufficient for the type of data you plan to store and access on the device.
In addition to the individual layers of the stack, enumeration of the transitions between layers can yield disclosure of additional risk. Of special interest is communication of secure data upward on the stack. Your organization may choose to implement an aftermarket package for strong encryption of data at rest on the device, but if that data is transmitted in clear text protocols at the infrastructure layer the effectiveness of the higher layer mechanisms is significantly diminished.
Depending on the risk tolerance of your organization you may find that a particular brand or model of mobile device does not have an adequate security model for the sensitivity of the data that you plan to access.
This model is by no means an all encompassing model. There are still areas to be flushed out and detailed in order for the model to be actionable in today's corporate environment. Use the comments section below to voice your thoughts and opinions and let's move this model into something practical.