Scale in the age of Secure Everything
At Apple’s WWDC (World Wide Developer Conference) in June, the mobile mogul announced that as of January 1, 2017, all apps in the app store MUST (that’s the RFC style MUST for those networkers following along) use App Transport Security (ATS).
Basically, it forces apps to use HTTPS rather than HTTP.
Now, what that means for people is that they have just a few months to:
- Update their mobile apps
This seems obvious. After all, the requirement is for mobile apps on iOS to use HTTPS. So yeah, there’s that. - Support HTTPS on the backend
This may not be so obvious, but the whole point of HTTPS is to secure communications which implies at least two-parties involved. In the case of mobile apps that’s some kind of endpoint (app, service, API gateway) either on-premise or in the cloud. This, too, needs to support HTTPS.
It’s that second requirement that is more involved, technically and operationally, than the first because it isn’t just a matter of flicking a switch. There’s certificate and key management, distribution, upgrades, changes to configurations on web servers and API gateways that previously weren’t supporting HTTPS. There may be extensive changes to infrastructure (and architecture) to support. And then there’s operational changes that have to be made, including watching for expirations on certificates and replacing them.
Scaling in an age of Secure Everything is not just a matter of capacity, but of operational capability. The operational impact on supporting a secure app infrastructure is not trivial. It’s not just checkboxes or a new configuration file.
1. Process changes
If you’re “doing DevOps” (or even if you aren’t) you need to examine your deployment pipeline process and make sure it includes the necessary components to support HTTPS. That means keys, certs, and configuration must included in the process.
2. Management changes
Certs expire. And when they do it’s a Bad Thing™. Operations has to know when certs will expire and make sure there’s a process in place to renew those certs and then get them deployed (which is basically GOTO #1 – Process Change).
3. Capacity changes
Encryption and decryption aren’t cheap in terms of compute. Even if they aren’t as greedy as they used to be, secure connections still consume more resources than insecure ones. You might see no discernable difference for apps that have very few users. But for those that are heavily in use (simultaneously) you’ll need to examine what capacity is available to scale out. And not just servers (virtual or physical) but the infrastructure, too. This includes API gateways (or devices/systems acting like API gateways) and, potentially, service registries (if you’re using containers and microservices already).
4. Architectural changes
An end-to-end secure connection can hamstring every security service between the user and the app, making them virtually useless in preventing malware or malicious code from reaching apps and services that have access to sensitive data. The ability to intercept secure connections and inspect them – both on the way in (request) and on the way out (response) – is an important component of a successful security strategy. Architectural changes may be required to ensure that critical security infrastructure continues to have the visibility necessary to perform its role in preventing breeches and infections.
A two-tier architecture in which secure connections are managed by the core network can alleviate much of the operational pains associated with having certs and keys sprawling across the app infrastructure. That’s because the secure connection can be terminated in the core network by a secure proxy. Communication with back-end apps can continue to be plain-text, if so desired, or re-encrypted to maintain end-to-end secure communication. Unencrypted data can be mirrored to security solutions (like IDS/IPS) for further inspection, maintaining the investment in existing infrastructure. That means one, central location at which certs and keys must be deployed, managed, and monitored. It also provides a strategic point in the N-S data path where interception and inspection can occur without interfering in mobile <—> app communications.
Regardless, the impact on scale of a Secure Everything approach to apps (mobile and otherwise) is not just a computing resource issue, but an operational one, too. And while Apple is certainly a driver of these changes, they aren’t the only one. Remember that despite the elimination of the SSL/TLS requirement for HTTP/2 from the official standard, the web browser community will only support HTTP/2 over SSL/TLS. Meaning as more of the web moves from HTTP/1x to HTTP/2, Secure Everything is simply going to continue to expand its reach.
This continued march toward the elimination of any kind of unencrypted communication between apps and users (by fiat or feature) will for some organizations require significant changes in process as well as products.