Question

As you consider the reputation service and the needs of customers or individual consumers, as well as, perhaps, large organizations that are security conscious like our fictitious enterprise, Digital Diskus, what will be the expectations and requirements of the customers? Will consumers’ needs be different from those of enterprises? Who owns the data that is being served from the reputation service? In addition, what kinds of protections might a customer expect from other customers when accessing reputations?

Answer 1

ANSWER:
1. The request can be tied to the user. And if the user is a member of the customer organization, then the request can be tied to the organization, as well. Requests are likely to have some value. If I know the sorts of web properties in which a consumer is interested, I can direct sales efforts to those interests. And that is precisely how search engines and social media services generate revenue. These services appear to be free, but they are far from it. If the service knows that you’re passionate about skiing, it will attempt to sell you skiing equipment, skiing vacations, and so forth based upon your demonstrated interests. This is precisely how social media and search engine revenue is generated; the advertising is highly targeted.

2. Furthermore, each customer, probably each user, won’t necessarily want to disclose their web viewing and interaction habits to any other user. If the string of reputation requests from a user were to be accessed by another user, not only would that be a breach of privacy in many jurisdictions, it might also give the receiver a great deal of information about the habits, interests, and activities of the individual.

3. In the case of an organization, the interests of its employees might be used competitively to understand future directions, pricing models, customer interactions, sales prospects, and all manner of sensitive business activity. Perhaps any one individual’s activities might not be all that useful in isolation from the rest of the organization? But if an attacker could gather information about many of the organization’s employee activities, significant information will likely be disclosed. For instance, if several of the researchers or executives access the website of an interesting new startup, a competitor might infer that the company was considering an acquisition. Any particular reputation request in isolation may not be all that significant. But the aggregation of reputation requests that can be tied back to an entity are probably quite valuable.

Hence, a reputation service does indeed have a multitenancy challenge. How can the service make sure that no tenant (or other attacker) can have access to all the other tenants’ request history?

5.One solution would be to toss all reputation requests once the request has been satisfied. If no reputation request history is kept, if all reputation requests are ephemeral, then the best an attacker can get is a picture of the requests at any particular attack moment.[1] The deletion of all reputation request history is certainly one viable strategy.

6.However, the software vendor may lose valuable data about the efficacy of the reputation service. Certainly, the reputation service would need to keep metadata about reputation requests in order to compute performance statistics, log failures, spot anomalies from expected usage, and similar telemetry information. Metadata are going to be very useful in order to assess the workings of the service and to spot problems with the service as quickly as possible.

Will metadata be valuable to attackers? Perhaps. But the metadata certainly will not be as valuable as reputation request histories that can be tied to entities of interest. Consequently, another viable security strategy might be to throw away all actual request history and only keep metadata.

7. Consider the case where only metadata is kept, that is, the case where no data is kept about objects for which a reputation request has been made. Once again, in this strategy, valuable data needed by the software vendor about the running of the service would be lost. For one thing, if there’s an error in reputation calculations, it may be impossible to know how many customers were ill-informed. That might be another acceptable business risk? Or not. In order to understand who may be affected, the service would probably have to keep reputation request history for each entity.

8. If reputation history is kept for each user of the system, then the system has a significant multitenancy challenge. Each customer expects that her or his reputation request history is private to the customer. A number of international jurisdictions have enacted laws, so-called “privacy” laws, which legislate exactly this premise: Browsing or other evidence of personal activity is private and, thus, protected information.

Since our cloud service is global, it will be subject to at least some jurisdictions’ privacy laws wherever it serves protected customers. Compliance is, of course, one driver of security posture. I would argue that merely to comply is to miss the point of security. There are other business drivers of an appropriate security posture. Large organizations, enterprises, governments, and the like, tend to take a dim view of loss of employee data, whatever that data may be. Meeting a customer’s expectation for protection of the customer’s data should, in spirit at least, also meet many legal privacy requirements.

Having established the need to keep at least some reputation request history for each user, how can user data protection be implemented? As noted above, this is a significant design problem. We will explore this only in terms of general patterns. An actual design for a specific product is out of scope.

We will not propose what some companies have attempted. Occasionally, a service will build what I call “table stakes” security—firewalls, intrusion prevention, administrative privilege controls, the collection of typical and well-known security infrastruc- ture—and then declare, “Your data are protected.” I’m not dismissing these controls. But none of the typical controls deal with multitenancy. Standards such as NIST 80053 are based upon an implicit assumption that the controls are built for a single organization’s security posture.[2] And that is not the case when infrastructure and processing is to be shared, in this case, highly shared. In the case of multitenant, shared services, customers expect to be segregated from each other and to be protected from the service vendor’s access, as well.

There are three architecture patterns that seem to be emerging to provide sufficient tenant data protection.

• 1. Encrypt data as it enters the service; decrypt data when it exits.
• 2. Separate processing within the infrastructure. Each customer essentially receives distinct infrastructure and processing.
• 3. Encapsulate data such that it remains segregated as it is processed.