Desktop version

Home arrow Computer Science

Analysis: Peel the Onion

The data that forms the basis for making reputation decisions will likely come from many sources.* Where data are collected from, and precisely what types of data are involved, are deeply held trade secrets. And this proprietary mix is not germane to the security of the system. From our perspective, we need to know that data are pulled and received from many sources via a data-input function. That function, like the Data Gatherer in the business analytics example, must normalize and parse many different types of data so that the data may be kept in a unitary fashion that can be processed for reputations. One logical function, therefore, is the receipt and initial processing of the various data types. Neither of the figures of the SaaS architecture in this chapter portray reputation data collection. We will not explore this aspect of the service. We concern ourselves with the service as consumed by a mobile security application.

Once the data are in a form that can be processed, a continual process in the backend works through the data, continuously calculating and recalculating reputations. There would be an architectural decision in the development of the reputation service as to whether reputations were calculated upon request for a reputation (i.e., in “real time”).

Alternatively, a reputation calculation would perform its processing over every object that had changed based upon incoming data. Each of these possible paths has its pluses and minuses. The decision on which way to architect the system would be made based upon the relative merits and challenges presented by each method. For our purposes, neither of these paths presents a wildly different security problem. Let’s assume that there was a decision to make a separate process for calculating the reputation. And that process doesn’t receive traffic directly from the Internet.

One of the sources for new objects will be requests about objects that have not been encountered by the service previously. hese will be entirely new, having no reputation calculated. We will ignore this typical data input in this example, for simplicity’s sake.

The key piece of security information here that I’ve just laid out is that messages do not come directly from the Internet through to the processing function. If you remember from both the business analytics and Web-Sock-A-Rama examples, one of the key defenses in both cases was a recomposition of requests before the request was passed to an inner, more trusted layer. In this way, an attempt to attack the web layer stays at the web layer and isn’t forwarded on further beyond that initial layer. Although such a defense is not always possible, depending upon the nature of the applications in the back-end, it’s relatively common that requests that will need to be processed by inner layers are generated at the outer, less trusted layers rather than simply forwarding traffic from even less trusted sources. In this case, the least trusted source would be a mobile device. Although the entire system does attempt to keep mobile devices safe—that’s its purpose—there’s no guarantee that some clever attacker hasn’t breached the device through some means or other. Thus, an attacker could be in possession of a vector of attack in the demilitarized zone (DMZ)-exposed system. Furthermore, as we know, an attacker could very well just buy the software, put it on the attacker’s device, and then use that device as a launching pad for attacks against the system. Hence, despite the protections built into our mobile security software, including malware protection and certificate authentication of the device to the service, the reputation service should make no assumptions about the relative safety of communications from the device.

With the foregoing in mind, a more defensive security architecture will be one in which messages are received and processed from devices, that is, requests for reputations via a bastion front end application. The front end “reputation service” to which a device under management connects then regenerates a request for a reputation to the reputation processor based upon the parameters sent from the device.

The URL or other object about which the user is asking must still be passed through to reputation processing. The object data can be inspected, validated for proper form, and sanitized. That processing will take place in the front end. Still, some data that is received from the untrusted source will be moved through the front layer and on to the next. Hold that in mind as we dig deeper through the architecture layers and attack surfaces.

Because of the separation of functions, from a security perspective it doesn’t really matter whether the reputation-calculating software performs the reputation calculation when it gets a request or simply retrieves the reputation that’s been previously calculated and stored. As long as reputations are kept up to date, that’s all that matters to the customer: retrieving the most up-to-date calculation.

It is quite possible that there may be two back-end application functions: reputation calculation and reputation retrieval. For our purposes, this distinction isn’t really relevant and doesn’t change the security picture of the system. Some piece of software presents an attack surface by receiving requests from a less trusted layer. That’s the important security-relevant piece of information. In order to keep our diagrams simple, these two functions have been collapsed into a single component.

Figure 11.1 represents the cloud service as it may look, logically, from the user’s, that is, the mobility security software’s, perspective. The “cloud” means that the service has

SaaS Reputation Service architecture (in the cloud)

Figure 11.1 SaaS Reputation Service architecture (in the cloud).

multiple points of presence across the globe to be queried. Cloud also implies large scale to support thousands, even millions, of clients. The mobile device software doesn’t need to understand any of the details behind that service. In other words, the details of data retrieval, processing, rating, and responding to queries are entirely opaque to the querying software. This is my intention. Even in SaaS architectures, data and structure hiding is a worthy design goal. As long as the messages remain consistent across versions, there’s no need for the endpoint software to understand the details of how the query gets answered. This is no different than an API hiding a library or an object hiding its internal processing. This is nothing more than structured programming (a rather dated term) at a very gross, logical architecture level.

Decomposing one of the points of presence, Figure 11.2 shows more detail. If you recall the Web-Sock-A-Rama web store architecture, the application portion of the

Breakout of a SaaS application instance

Figure 11.2 Breakout of a SaaS application instance.

reputation service looks surprisingly similar to the previous web example. This is not to suggest that all web applications are the same. They decidedly are not. However, a three-tier architecture, separating the web termination, authentication, and message validation from front end processing logic, which is then separated from further processing, is one very typical architectural arrangement.

In order to represent the many management and configuration functions that support a secure web presence, I have diagrammed a management network, administrative interfaces, and configuration stores. These would all have to be implemented in order to run a cloud SaaS service. Since these were explored in the earlier web example, please refer to that if you have any doubts about the sorts of issues and resultant security architecture that will normally be put into place for the management of Internet-exposed systems. A demilitarized zone (DMZ) management network is employed to ensure that administrative access is highly controlled, just as we saw in the previous web architecture. In this case, access to the management network is through a single constrained point, which then proceeds to a management server. The management server is the only source from which the administrative interfaces on the various DMZ components can be accessed. As before, dual-factor authentication is required before access to the management network is granted.

As we noted in our mobility example, all devices containing the mobility software, which is under management, receive an X.509 certificate issued to that device. Only queries for reputations that present a valid certificate signed by a private key issued by the reputation service for the mobility software will be accepted. All other attempts at communication will be rejected. In this way, all the dross attack attempts that take place on the Internet are consistently rejected. This authentication does not mean that all attacks are rejected. The value of an authentication as a security control is based on its ability to reduce access, that is, reduce the attack surface, by rejecting “untrusted” sources. But “untrusted” is a value judgment. The question that must be asked in order to understand the value delivered by the authentication is how much does the issuance of the authenticator tie to some level of trustworthiness? As we’ve noted a couple of times, there is the distinct possibility that an attacker can become part of the population of devices running the mobility software.

 
Source
< Prev   CONTENTS   Source   Next >

Related topics