F5 Friday: How Standardization Enables a Customizable Per-App (Microservices) Approach to App Security

I’ve talked, and talked, and talked some more about the increasing need for application-affine services to cozy up the apps they protect, scale, and optimize. Just as app developers are finding its more efficient and agile at scale to break down monoliths into more focused, granular microservices, so too does the infrastructure need to mirror this move to continue providing the same level and quality of service at scale.

But this approach is not just for microservices architectures. It’s also for organizations that need to deliver per-app policies at scale, and do so quickly. Consider research that found that “85% of companies have a mobile backlog of between one and 20 applications, with a majority (50%) having a backlog of between 10 and 20 apps”. That’s in addition to the plethora of existing apps (our research showed nearly half of organizations have between 1 and 200 apps, the other half, well more than 200 including the somewhat mind-boggling 10% with more than 3000 apps to deal with) that need updates to be rolled out.

Most of which require very specific policies to ensure their scale, security, and performance. You’ve got to scale, but you’ve got to scale fast to manage it all.  

One of the disadvantages of a per-app service approach, of course, is that each one must be tailored to meet the unique requirements of the app it is delivering. That’s the point, of course, but without a strategic approach to scaling the operations behind policy creation and deployment to meet that demand, such an approach could potentially lead to slower, not faster, deployment times.

This is why DevOps and its infrastructure as code philosophy combined with attention to automation should be considered not only appropriate, but desirable, for security operations to embrace. Because only by shifting web security to the left can a holistic microservices approach across both apps and app services be successful. It’s critical, in fact, if security will be able to match the speed with which IT today is expected to deliver its services to the customers it supports.

That’s what drove Catholic Education South Australia (CESA), which delivers IT services to over 98 schools distributed across South Australia, to adopt the F5 platform. CESA was struggling with challenges arising from traditional provisioning and deployment methods that simply didn’t provide them with the horizontal scaling required to keep up with demand. What they needed was a customizable framework for deploying applications and automating associated tasks. And that eventually included web security.

Simon Sigre, senior network engineer at CESA, explains why they needed to make a change, “We were required to start building Layer 7 (L7) security policies that wrapped like a glove around each web app.”

CESA needed to deliver per-app policies but they needed to do it fast, and at scale. Meaning they required automation to accomplish this feat. But that’s not all they needed. Tailoring policies – especially policies so tightly coupled to the app they protect – takes time. But not everything about an application is unique. There are common elements, particularly those related to protocols (like TCP and HTTP) and platforms (like the web or app server software) that remain the same across many applications. Configuring policies to secure those aspects also takes time; time that is duplicated across multiple applications. 

This where standardization comes to the rescue. One of the hallmarks of standardization is the ability to take advantage of commonalities in APIs, templates, command and control systems, and scripts to improve efficiency that translates into reduced operating costs and faster time to market. Which is exactly what CESA did when it took advantage of F5’s programmability not just to automate scalability but to standardize security policies by creating high-level templates for common technologies in use and then customize them to accommodate differences in each new service. They were able to build out the per-app security policies they needed without incurring  the costs typically associated with customization by treating infrastructure (web security) as code (templates), effectively eliminating the costs associated with recreating the base policy each and every time they need to deploy a new service.

You can read more about CESA’s experience with F5 and its technologies right here in this customer story.