Why Automation is the Crucial Ingredient in Microservices Security

Microservices security is different from securing other technologies—and much more difficult

Microservices are nothing new. Neither is the conversation about best practices for securing microservices. Typically, that conversation centers on strategies such as making each microservice as small as possible to minimize your attack surface, preventing unnecessary interactions between microservices so that a breach of one service won’t compromise the others and securing network endpoints.

Those are all good practices for keeping microservices applications secure, and I certainly recommend following them.

For most teams, however, that is easier said than done. When it comes to actually implementing these microservices security strategies, obstacles tend to arise quickly.

The antidote is automation. It’s only by embracing automation that you can operationalize microservices security best practices.

Let’s explore how automation makes microservices security possible. This is a topic I discussed in a recent podcast with The New Stack, and I’d like to elaborate on some of those concepts here.

What Makes Microservices Security Different

Microservices have been widely used for years. Their cousin, service oriented architecture (SOA), is even older.
Yet, despite the fact that most of us are familiar with microservices now as a deployment concept, it can be easy to overlook the ways in which microservices change the game from a security perspective. In several key security-related ways, microservices are fundamentally different:

  • A microservices environment contains more services that need to be monitored on an individual basis. This is the most basic and most obvious difference between microservices and monoliths, but it’s one that has crucial security implications. The more microservices you have, the more areas you need to watch for signs of a vulnerability or intrusion.
  • Microservices environments are constantly changing in scope and configuration. Port addresses are updated. Endpoints change. Entirely new microservices may be added to an existing application. All of this dynamism means that monitoring for security issues manually is often impractical.
  • Microservices create more complex traffic patterns. With a microservices application, you have to monitor not only the external network traffic, but also the complex network of communications between microservices. Anomalies within internal communications are often your first sign of a security issue.
  • Microservices deployment technologies, like containers, lend themselves to new security strategies, such as immutable infrastructure. When you deploy microservices in containers, you can update individual microservices by pushing out a new container image. This is something that is much more difficult to do with monoliths, and it can improve security significantly because it allows you to avoid the unexpected consequences that tend to follow live patching. It also makes it easier to detect malicious activity by looking for changes to a configuration or service that were not triggered by an immutable infrastructure update.

All of the above means not only that microservices require you to revamp your overall security strategy and tools to accommodate a rapidly changing, highly scalable application environment, but also that you should rethink the processes that you use to operationalize your security strategy.

Why Automation Enables Microservices Security

How do you do that? You embrace automation. Without automation, implementing microservices security best practices is not at all practical.

(I hesitate to say it’s impossible because technically, if you have a very large team, a huge amount of patience and/or a very small environment to manage, you probably could pull off effective microservice security without the help of automation. But I would not recommend it. And I certainly don’t think you can do it efficiently at scale.)

When you automate, you can monitor as many microservices at once as you need. You can also monitor internal network communications, no matter how complex they are. And you can deploy updates automatically using immutable infrastructure principles, while also adjusting your security monitoring policies and tools in real time as your environment’s configuration and scale change.

Taking full advantage of automation starts with having the right tools. You want your deployment, orchestration and monitoring tools to be as automated as possible. That means that they can operate with a minimum of human oversight and intervention. Ideally, they’ll also be able to configure themselves to the fullest extent possible, so that even setup does not require significant manual effort.

Automation for microservices is about more than just tools, however. You also want to ensure that your CI/CD processes are automation-friendly. By that, I mean that they should support automated hand-offs, while also allowing for manual interventions to take place without disrupting the rest of the pipeline. If you notice a security issue with a particular microservice during testing, for example, you’ll want to be able to have your developers intervene to fix that issue without slowing down the delivery of other microservices.

Finally, I’d extend the automation argument even to your people. Obviously, you can’t automate human behavior (at least not yet—and I’m not sure doing so would be a good idea from an ethical standpoint, anyway). But you can instill an automation-first mindset within your team. Whenever your engineers face a problem, their first thoughts should be of ways they can build an automated solution. That may not be possible in every case, of course, but automation should be the go-to strategy. At the same time, your team should strive to reap the full benefits of automation by ensuring that they put the time it creates to good use by completing tasks that simply can’t be automated, such as assessing overall application design to improve security.

Conclusion

Microservices security might be possible to pull off using manual tools, processes and mindsets, but it’s not practical. Organizations that succeed in securing microservices are those that adopt an automation-centric strategy, enabling them to put microservices security best practices into … well, practice.

John Morello

John Morello is the Chief Technology Officer at Twistlock. As CTO, John leads the work with strategic customers and partners and drives the product roadmap. Prior to Twistlock, John was the CISO of Albemarle, a Fortune 500 global chemical company. Before that, John spent 14 years at Microsoft, in both Microsoft Consulting Services and product teams. He ran feature teams that shipped security technologies in Windows, Azure, and Office 365 and served as the Lead Architect of the hybrid cloud consulting team for the Americas. A self-proclaimed "public school guy," John is passionate about building out more modern curricula for cybersecurity. In fact, in May 2018 he established a Twistlock outpost at Lousiana State University’s Innovation Park in order to pay off this vision. John lives in Louisiana with his wife and two young sons. A passionate fisherman and scuba diver, he also serves as Chairman of the Coalition to Restore Coastal Louisiana.

John Morello has 3 posts and counting. See all posts by John Morello