Mobility Often Implies Client/Cloud
We’re going to extend the feature set somewhat for mobility software. As of this writing, most devices are generally not islands unto themselves. For many of these devices, the network is “always on.” Except for the devices out of range or off-grid, the network connection is omnipresent as a core piece of the functionality of the device.
The protections from the security software must continue when the device is taken off the network, such as when it’s off-grid, or in airplane mode and similar. Still, much of the time, software writers can expect the device to be online and connected, not only to a local network but to the World Wide Web, as well. Web traffic, as we’ve seen, has its own peculiar set of security challenges. What are the challenges for an always- connected, but highly personalized device?
Most notably, attackers set up malicious websites. These can be returned through search engines, of course. But also, there are the ever-present phishing attacks bombarding users. In addition, people personalize their devices with special purpose applications of all kinds. Malicious website URLs get delivered through many different vectors. This mobility security software includes a URL reputation service running in the cloud. When the user clicks on the URL in order to access a website, an event gets generated from the kernel to the AV Engine, indicating that the URL needs to be checked first before access.
A reputation service is so-called because many behavioral data points are kept about a particular URL, file, or Internet Protocol (IP) Address. Data is collected from various sources about the observed behavior of the object for which reputation is being calculated. A URL (or other object) will fall somewhere in a continuum from absolutely malicious to reputable (good), with various degrees of “gray” in between those two poles. Based upon the reputation rating, software can prevent access, present the problem for user decision, or passively allow the access.
The details of the data used in the calculation are generally proprietary and closely held secrets of the vendors providing the reputation service. For our purposes, it’s probably enough to know that reputation services are often implemented in a cloud, generally a global cloud. They are operated as a Software as a Service (SaaS). Reputation is usually checked before proceeding by a piece of local security software (the AV engine, in this case). The check is performed over the Internet via some encapsulation within the HTTP protocol. The backend of the reputation service usually involves “big data,” the archive and examination of billions of individual data items that form the basis of reputation calculations.
We will take up the security of the reputation service below, when we analyze Figure 10.2. For the moment, it’s important to note that the communicator shown in Figure 10.1 implements all the functions listed previously for endpoint security software. There is one additional communication feature that has been added. The communications module must request reputation from the reputation service before taking action on an individual URL that the user has attempted to access.
Although it may not be apparent when looking at mobile devices, they do have permanent storage. Files are kept on the device’s permanent storage. Applications create files. Applications manipulate files. Device users view and edit files. Indeed, on the device’s storage, a typical operating system directory structure does, in fact, exist. There is a “tree” of directories (“folders”) that is exactly what you would find on your computer or your laptop, regardless of which of the usual operating systems you use. On many mobile operating systems, the file and directory details are hidden from the user. Most of these operating systems assume that there is but a single user who has access to all the files. Since mobile operating systems highlight application functionality, the details of file access are hidden behind application user interfaces.
The details are more or less hidden from the application, as well. Each application has a set of directories assigned within its sandbox. Visibility to other directories is not allowed.
Figure 10.2 Mobile security software with cloud management.
The presence of files implies a security need to examine files to identify those that may be malicious. Included among the user’s downloaded applications might be malicious applications. But bear in mind that a “mobile device” is nothing more than an operating system running on a computer. The usual assortment of vulnerabilities that are file based can also exist on a mobile device. As a result, again, just like endpoint security software, this architecture includes a file opener and parser. The same analysis applies as it did in the previous architecture that we examined.
“Intercept” in this architecture replaces the endpoint security software’s kernel driver. Analogous to the kernel driver, Intercept vectors events on the device to the engine for analysis. Depending upon the mobile operating system, the intercept module may exist as an operating system service, which is then made available to applications, or the intercept function must be supplied by the software vendor and installed with the security software.
In at least a couple of mobile platforms, no application may install software into the kernel. As was noted in Chapter 3, the “system” area exists between the application mode and the kernel. There are three layers—application, system, and kernel (in Figures 10.1 and 10.2, the kernel is not diagrammed, as it is not relevant to this architecture).
For our purposes, the security issues are approximately the same regardless of whether Intercept exists as a part of the operating system or whether it was written and installed with the application. If the intercept service is “native”—that is, a part of the operating system—obviously its secure coding and assurance is not under the control of the mobile software maker. Still, the design issues are analogous. The secure coding and code assurance activities will be the same in each case. If the interceptor is written for the operating system, the same requirements as given for the kernel driver above apply to the interceptor, as well. If the interceptor is supplied with the operating system, then the security software inherits whatever security strengths and weaknesses have been built by the operating system makers.
Intercept initialization should be performed and communication flows opened early in the operating system “boot” process, before the user is allowed to log on, in order to stymy misuse of the startup calls. We saw this previously in the endpoint example.
As in the previous architecture, events should flow only from system to application, never the other way, just in case an attacker gains control of the application. It is standard design practice to limit communications from lower privilege to higher privilege. The appropriate event flow is, of course, a design requirement.
Even though the file system appears to be closed, more or less, from the normal user of the device, every input we examined in the endpoint security case requires the same security requirements as we uncovered previously. After all, there is the possibility that a malicious program can transcend the sandbox and launch an attack via the device’s file system.
Figure 10.2 introduces the cloud aspects for the mobility security software. The diagram shows two different services interacting with the endpoint: management and policy services, and a reputation service.
For mobility architectures that I’ve encountered, enterprises and larger organizations (or highly security-conscious organizations) tend to prefer to deploy management consoles onto the organization’s network. Through local deployment, the organization can control this sensitive function. This situation is analogous to the management console that we examined previously for endpoint security software.