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 (SOA) used to build distributed software systems. Like in SOA, [microservices] are processes that communicate with each other over the network in order to fulfill a goal.” [source] 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 recently to render these applications less secure and more exposed? That change is taking place along three dimensions: feature velocity, scalability, and application topology.
Microservices and DevOps have enabled companies to be faster and more agile; this means more features in less time and the ultimate ability to outrun the competition. One of the “features” of cloud-native applications is the ability to scale quickly. Take Pokemon Go, the latest app craze. The following chart shows user demand for downloading Pokemon Go from a mirror site (apkmirror.com). Notice the near 6X explosion on download demand (just from that site) from May to June and the commensurate precipitous drop in July.
Pokemon Go was a dream for its creators. The apps user base grew phenomenally quickly, a “problem” we should all be so lucky to have. Despite some outages, the game responded reasonably well to user demand. 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 infrastructure provisioning. Accordingly, resource usage (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 (more precisely, 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.
Isaac Asimov wrote: “It is change, continuing change, inevitable change, that is the dominant factor in society today. No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be …” Taking this concept to heart, we need to rethink security for distributed applications, knowing that change in features, scale, and topology are constants, and therefore they should be anticipated.
Distributed applications require distributed security and a departure from the old-fashioned world of perimeter-based or network-enforced design models. We, at Aporeto, are busy building the new Trust-Centric Security design. Stay tuned as we share more of our thoughts.