Home Computer Science Securing Systems Applied Security Architecture and Threat Models
For the consumer and the small business markets, management is typically provided through a multitenant, shared service run by the software manufacturer. Because the service is shared across many “tenants,” the cost of providing the services for each customer is minimized. Economies of scale help to lower the price so that individual consumers and small businesses can purchase protection from their more limited budgets. It is this case that we will examine in this example.
Communications from each endpoint must flow across the untrusted Internet. Any number of networks and Internet providers may be crossed as packets are routed. Hence, in Figure 10.2, the arrow from the communicator reaches into the Internet, whereas disconnected arrows move to the cloud-based services. The disconnect between arrows is to indicate the unknown nature of routing, the unknown networks across which the traffic must pass.
With thousands of devices or perhaps millions to support, communications are instigated from the device to the service. Most mobility operating systems include a service to “push” a “notification” to the device, even to a particular application. In this case, in order to simplify the architecture for study, let’s assume that the only push notification issued by the management service is a command to instigate communications in order to receive further commands or updates. Although, in actuality, notifications might be more complex, this one notification would be sufficient to roll out updates, policy changes, and the like. Assuming the architectural limitation of a single, “call home” notification, allows us to state that all communications from the communicator to the cloud services originate from the communicator. Notifications pushed through the operating system service come through the interceptor and appear as an event passed to the engine. Push notifications have a different flow than communications from the application to its services.
Exactly the same problems exist from the management service to the mobile endpoint software that exist from the management console to the endpoint. Communications must be protected over untrusted networks. The device must authenticate to the service, at the very least. The security software must have some method for validating the authenticity and integrity of code and data downloaded from the site to the device. Each of these issues was examined in some length, above. The requirements are the same.
What is different with cloud services are the challenges from multitenancy. In the last, cloud architecture example, we will examine multitenancy at some depth. This is a service problem. It’s not really germane to an examination of an endpoint security solution. We will hold off until we investigate the next architecture.
As we saw in the Web-Sock-A-Rama example, simply placing services on the Internet invokes a raft of security necessities: server hardening, layering and trust levels, management interfaces, and so on. If you feel unfamiliar with this coterie of requirements, please return to that earlier analysis for an in-depth discussion of Internet exposure.
Let’s turn our attention to the additional feature: the reputation service introduced in Figure 10.2. As we noted above, “reputation” in this context refers to how trustworthy or malicious an object may be. “Object” might be a URL (web destination), a file, an email domain or address, an IP address, and so forth. The calculation of reputation is outside our scope. It is sufficient to acknowledge that security reputation services exist, both free and commercial. The object is presented to the service, which returns a reputation—some sense of how safe or dangerous the object may be to access. Usually, reputation is delivered as a grade along a scale from known to be malicious to known to be safe. Considering the hundreds of millions of websites on the Internet, gathering sufficient information about websites and then calculating a score is a nontrivial, “big data” problem. Significant resources are expended in order to make as good a guess about reputation as possible.
Usually, the commercial services are “cloud” grade. That is, the services are available across the globe so that user access time is reduced. The services are always available, with failover systems that can pick up upon an instance failure. Cloud services are usually redundant and backed up to various points of presence spread out geographically so that a local catastrophe cannot bring the service down. (We will take a look at the backend architecture of a cloud service in the next analysis.)
One of the big challenges with cloud-based reputation checks is performance. Users don’t typically want to wait a few seconds while the reputation of potential URLs is checked. Most of us have come to expect that websites are at the immediate tips of our fingers and that access and loading of the content should take place rapidly and without delay. This presents a tricky security problem.
Since the reputation service exists in the cloud, the challenge can be summed up as, “How can a reputation be securely retrieved without slowing Web access down so much as to create a poor user experience?” The details of cloud performance, points of presence, calculating the shortest distance, data caching, and associated issues are largely beyond the domain of security. We will take a cursory look at some of these issues in a subsequent, cloud-based SaaS service analysis. Still, it’s important that the security components of the reputation service don’t inordinately affect overall performance. This is one of those cases in which there has to be “just good enough” security, and no more, because security controls often impact performance. For instance, bringing up a Transport Layer Security (TLS) connection takes a fair amount of computer and transmission time.
One key question when designing a service such as a reputation service is to decide how secret the reputation needs to be kept. Obviously, if attackers know that a malicious site has a poor reputation, they may respond to that situation by changing the domain of the site, or they may take other evasive action. That’s an argument for only allowing the mobility software to check reputations and to protect the reputation service from query by any other systems. Further, if the vendor intends the service as a commercial offering for profit, allowing open access to everyone would be a competitive disadvantage.
On the other hand, owners of domains may have their web properties misclassified. Domain owners need a method to check the reputation of a domain and to address a poor reputation rating with the reputation service provider. I personally have had a couple of websites misclassified once or twice over the years and have had to go to a reputation service and complain. Supposedly, all my websites are legitimate. As far as I know, none of my sites allow or foster malicious activities, at least not intentionally. Still, I have been classified as malicious a couple of times. Mistakes get made. Any reputation service that expects to stay viable must offer domain owners a way to check their domains and URLs and to lodge a complaint if misclassified. Obviously, redress can also be abused; no doubt, redress services are abused.
So, what is the right security posture for a cloud-hosted reputation service? The answer to this question is hotly debated regularly. Even within organizations, there will be a diversity of opinions about how much security is “enough.” Most security controls, unless it is trivial to implement, are likely to draw significant discussion and generate at least a few strong opinions. Even so, we have a system under analysis. One of the system’s components is a cloud-based reputation service that provides proprietary features for commercial mobile security products. Therefore, the reputation service cannot be wide open and without access restriction.
As we have seen, security decisions must be based on the objectives that are to be fulfilled by the security. Earlier examples have explored the issues confronting an Internet-exposed system. Both services in this example require the same protections from constant and unremitting attack from the Internet. This should come as no surprise. These protections must include host and network hardening, as well as all the management security capabilities that have been previously laid out.
|< Prev||CONTENTS||Next >|