4 Steps To Secure Requests Between Microservices

George Lawton

March 19, 2021

Microservice architectures break applications into smaller parts that work together. This improves the reuse of services and development agility, but it comes with potential cost. As the number of microservices in an application increases, so does the exchange of requests between them. The result: more opportunities for attackers to gain access to the system.

Enterprises have pursued a variety of approaches for securing requests between microservices. These come with trade-offs between development complexity, performance, and security.

A basic, and ineffective, strategy is to secure the collection of microservices behind a firewall and hope for the best. As part of this approach, sophisticated teams adopt Zero Trust architectures to mitigate the damage if and when a breach occurs. Another approach lies in combining these techniques with sophisticated API monitoring to detect and mitigate increasingly subtle forms of persistent attacks. At the high end of the protection spectrum teams are adopting improved API security tools that provide a deeper level of monitoring and control.

Here are four steps that can be used to secure potentially vulnerable communication between microservices.

1. Protect Microservices Running on Secure LANs

Web application firewalls (WAFs) address various vulnerabilities baked into legacy and poorly coded applications. A WAF can be configured to provide a basic level of protection for a collection of microservices running on a secure local area network (LAN) behind them. Over the years WAFs have been enhanced to address several common threats such as cross-site forgery, cross-site scripting, and SQL injection. The earliest WAFs used regular expression-matching to look for common attack patterns. Runtime Application Self-Protection (RASP) emerged as a way to integrate WAF capabilities directly into applications.

Next Generation Web Application Firewalls (NGWAFs) capture the application’s business context to enhance security policies. These can provide protection to multiple collections of applications composed of microservices on different secure LANs. Sophisticated variants can provide deeper insights into security-related events across different kinds of microservices infrastructure, such as Kubernetes for container orchestration and service meshes like Istio and Envoy.

Both WAFs and NGWAFs reduce the risk that malicious traffic can target individual microservices. Developers may feel free to allow microservices to message each other since the firewalls can provide a basic protection against data leakage or bad actors. An added layer of security can be implemented relatively easily by using a virtual private network to secure all communications between microservices. This can involve using strategies like local host isolation and network segmentation to organize related microservices onto local trusted networks.

2. Secure Containers That Host Microservices

Microservices are generally hosted in containers that run on physical hardware. New vulnerabilities are regularly being discovered at all levels of the operating system and container stack. If hackers manage to take control of the container used to host one or more microservices, they can begin probing for weakness and listen to communications between services (known as East-West traffic), or spoof their own messages to appear to be originating from other microservices.

A strategy for securing containers needs to address issues like vetting known good software sources and maintaining a secure container registry used to launch new instances. Teams may also consider hardening the host OS used to run the containers holding microservice applications.

3. Start With Zero Trust

Another emerging concept, called Zero Trust security, starts with the assumption that any system might be breached. Hence, the best strategy is to treat every system, actor, or API as potentially hostile. The methodology requires authenticating everyone and everything that talks to any service in the system. This idea is particularly gaining steam after incidents like the Facebook API data breach highlighted new ways attackers use to penetrate seemingly secure API.

A Zero Trust architecture should provide API-level security controls that use public key encryption to identify, authenticate, and protect message traffic between microservices. Trust is established using a security service that issues tokens and public key cryptography to sign all messages. Newer generation API security tools make use of API-centric security token frameworks that decouple applications from authentication. These can include API keys, OAuth2.0, OpenID Connect, and JSON Web Tokens.

One challenge for security teams is that developers sometimes reuse these tokens with session identifiers, hoping to reduce the computational overhead of checking each transaction. This opens the door for hackers to penetrate a system using session hijacking, taking over working sessions to burrow deeper into the applications. Once in control of a session, they can make any request that service is allowed to make.

4. Keep a Watchful Eye on the ‘Perfectly Normal’

All the preceding approaches can mitigate breach risk. But once a malicious actor has penetrated a microservice application, other means may be required to identify the breach and lock them out.

Older security-monitoring tools were designed to operate at the level of traditional application stacks or to look for unusual network patterns. However, new kinds of API attacks often look perfectly normal from a network traffic perspective. Attackers are now perfecting new techniques that target APIs at the business logic level, which are difficult to detect using traditional monitoring approaches. These kinds of attacks allowed hackers to take over accounts at Uber and access admin functions at Shopify.

Keeping Pace with New API Threats

New approaches are required to capture more in-depth traces of microservice traffic, which can help to detect these more subtle types of API attacks and to craft more dynamic rules for securing systems. The next generation of API security tools are starting to optimize logging, distributed tracing, and heuristic analysis for identifying these new types of attacks.

Security teams should also prioritize tools that not only identify threats, but can also automatically block them, such as Traceable Defense AI. This requires the ability to correlate more comprehensive observability data with new kinds of threat signatures.