DEVOPSdigest

The software industry has accelerated its shift towards microservices and has fully embraced distributed, cloud native apps. Because existing application security models were designed for a different era, they are woefully inadequate, exposing both consumers and companies. By (mis)matching where software is going with what application security has been, and as evidenced by several recent high-profile leaks, we are all at risk.

Finding their roots in the 90s, “microservices are a more concrete and modern interpretation of service-oriented architectures used to build distributed software systems.” The 90s marked the dawn of the distributed application era as it exists today. Precisely and not surprisingly, it was also the time that defined data center security with the ubiquitous use of firewalls, ACLs, NAT, etc.

Given distributed applications’ history and coexistence with erstwhile proven security methods, the central question is what has changed to render these applications less secure? The answer is feature velocity, application scalability, and shifting topology.

Microservices and DevOps have enabled companies to be faster and more agile, delivering more features in less time. One of the “features” of cloud-native applications is scalability. Take the latest app craze, Pokemon Go, and notice its download patterns from a single mirror site.

There was a 6X download demand increase from May to June and a commensurate drop in July. As the game grew (and apparently shrank) in a short time, it put tremendous stress on the underlying infrastructure because of its constantly changing topology.

Before the cloud and the elasticity of its underlying infrastructure, and before microservices and the current-day distributed applications, change was infrequent, planned for, and required proactive provisioning. Accordingly, resource usage – or rather "reservations" – were predictable and resembled a step function (see “Your Father’s Oldsmobile” in the chart above). In contrast, distributed apps like Pokemon Go have unpredictable user demand curves and seem more like a random function. As the elastic infrastructure responds to the distributed application’s need for scale by provisioning more computation, storage, and network resources, the application topology changes. These rapid changes are disproportionately (quadratically) difficult to respond to when network communications are central to application security, making this precisely a mismatch between distributed application needs and existing security methods.

Existing security methods were designed when Your Father’s Oldsmobile was in vogue and change was more predictable and less frequent. Change request submissions tickets were issued to someone, approved manually, and rolled into production slowly. A bevvy of automation tools and startups are attempting to solve this problem through automation and machine learning; however, there are real technological and operational limitations that inhibit scaling. In the process, the application and, by extension, the user is left exposed to real security vulnerabilities.

Distributed applications require distributed security and a departure from the old-fashioned world of perimeter-based or network-enforced design models.

Amir Sharif is Co-Founder of Aporeto.