Authentication Is Not a Panacea
Generally, Web systems that don’t serve public content will require authentication to reduce traffic, and thus exposure, to only the intended population rather than anyone who can send traffic on the Internet. As we saw previously, websites with wide-use demographics may get very little value from authentication. In this case, these services are to be consumed only by paying customers. That, of course, won’t stop an attacker from obtaining a paying account from which attacks can be mounted. Authentication can’t be the only control in place, for this single reason. Still, and nonetheless, the vast majority of paying customers are looking for security protection, not for a system to attack. Authentication is likely to reduce the attack surface by at least removing exposure to all the automated attack sweeps that are ever present on the Internet.
But in this case, is it the user who should be authenticated? Well, yes and no. The users must be old enough to manage their accounts, manage their devices, configure their security policies, and, of course, pay for the services. For these reasons, there will have to be a user interface and user services. These will presumably employ authentication to tie account and services to users. The architecture presented in Figure 10.2 does not include the web authentication services. We examined these issues previously in the Web architecture example, Web-Sock-A-Rama.
What are shown are the other services that the software uses in an automated fashion. If the user were forced to authenticate every time he or she accessed the URL, I suspect that the security software would not have a very long or useful life on that person’s device. Instead, the software will have to authenticate to the services. That’s a slightly different architectural problem.
Should the application be the entity that authenticates? Or should it be the device? Again, there are arguments back and forth about this design choice, which we won’t go into in this example. There are strong reasons for authenticating the device. And that’s the pattern that this system employs. If it’s the device that’s under management, even if the software breaks down, the management service has some concept of the device itself. If the device is lost, it can contain an identifier, regardless of whether the software on it has been reset by a thief. The mobile carrier interacts with the device; the management service, which is able to identify the device, may interact with the carrier about the device, if necessary. Both the management services and the reputation service authenticate the device, not the user. I reiterate that, in general, mobile operating systems and architectures assume a single user per device.
One way to accomplish the authentication is to issue a certificate to the device. Along with the certificate, which can be validated, when the device is enrolled, its serial number and the carrier’s identifier will be tied together. The communicator brings up a TLS tunnel to the server, validating the server certificate, as per the TLS protocol. Then the device certificate is presented. If validated, communications can flow. This means that only enrolled devices are allowed reputation services and are under management.
The foregoing scheme does not protect the system against a rogue or compromised device. It doesn’t protect the system against a malicious, paying customer. Other protections will need to be placed around the services in addition to the authentication. Along with the authentication, all the protections together constitute a defense-in-depth. (The SaaS architecture below will delve into other protections.)