In the world of software development, microservices is a variant of service-oriented architecture (SOA). It is an architectural style in which software applications that are typically built as monoliths and run in a single process are decomposed into smaller parts. Each of these parts is called a microservice, running independently with its own process.

Creating a mental picture of monolith versus microservices is relatively easy:

Microservices is a great way to redefine large-scale software projects because it is more flexible and allows for on-demand scalability and much shorter release cycles. As a result, forward-thinking organizations have been increasingly moving to the microservices development style. With this architecture’s fine-grained services and lightweight protocols, it can help teams increase product modularity, making applications easier to develop, test, deploy, modify and maintain over time.

Microservices is also good for scalability. If teams want to scale up one component, they can do that without having to scale the entire project. Scaling up can therefore be a lot faster and less costly.

It might sound like microservices is a cure-all for software development woes. But like any other domain, it has its disadvantages; moving to microservices adds complexity and security implications. Regardless of how an application is designed, major gaps could potentially be introduced on the platform level. In microservices, security concerns can get exacerbated due to the various network connections and application programming interfaces (APIs) used to forge communication channels between the components of the microservice architecture. Another issue is that, if not properly designed, the standardized replicable nature of containers could spread out any vulnerability manyfold.

From managing user access to the code all the way to implementing a distributed firewall, one thing is clear: Ditching monolith for microservices may be right for your organization, but the relevant security considerations must be addressed early in the process.

The Microservices Trinity: Cloud, Containers and DevOps

Microservices are containerized and accessed on scale via cloud infrastructures. To make microservices flow effectively, organizations must adopt a DevOps culture where small, multidisciplinary teams work autonomously, applying Agile methodologies and including operations in their scope of responsibility.

This combination of factors can increase overall security risk for the organization in general and, more specifically, through the phases of a microservice-based application project: planning, development and post-deployment operations in cloud-hosted architectures.

Key Concerns: Knowing Where to Look First

In general, organizations nowadays are aware of their overall risk appetite and know that new projects always introduce new risk considerations. With a move to microservices, we are looking at a gradual process that breaks one large, monolithic project into smaller parts, each of which needs to be managed as its own project. Below are a few key concerns to look out for when operating a microservices architecture.

Isolation

Isolation is at the core of the microservices concept. To be an autonomous piece of the overall application puzzle, a microservice needs to be its own island in a sense — architected, created, deployed, maintained, modified, scaled and, eventually, retired without affecting any of the other microservices around it.

One area where isolation is much-needed is on the database level. Monolithic applications where every part of the application can access any part of the databases can, over time, impact performance due to deadlocks, row locks and errors. Microservices, in contrast, can avoid that if isolation is applied — for example, if it is decided that only one microservice will access one data store and integration with the entire database is eliminated. In a security sense, that means more microservices and more data stores to secure. But if done correctly, one microservice will not be able to access the data of another and, if compromised, it will not give way to an attacker moving laterally.

Another area that requires isolation is deployment. The goal is to ensure that each microservice is deployed without impacting others around it and, should it fail, that the effect would not bring down other microservices as well. The biggest challenge typically applies to multitenant applications, which require isolation on both the microservices and data levels, such as in software-as-a-service (SaaS) scenarios.

A Preference for Hybrid Clouds

Developing at scale usually takes place in the cloud, and most organizations have been doing it for years now. That can also mean that any given organization operates different parts of its infrastructure of different clouds with different vendors. Securing microservices will therefore have to be cloud-agnostic and applicable to any environment with relevant controls in place to achieve uniform effectivity across the various cloud infrastructures.

Insecure DevOps Tool Sets

There are some great open-source tool sets out there built for DevOps teams, and they can be used in most Agile developments. What these tools may not always offer is proper security. Integrating open-source tools into the team’s projects requires assessing exposure and adapting controls ahead of integration, as well as reevaluating them over time. Open-source also means access for all, and that often gives way to opportunities for attackers to plant or exploit vulnerabilities and infect tools with malicious code.

Interservice Communications

Interservice communication is typically not a good idea for projects that exist autonomously, but in some cases it is necessary. These channels can be risky and costly if not designed and implemented properly. Securing interservice communications calls for high standards and encryption on the data level where needed.

Managing Data Layers

Each microservice manages its own data. As a result, data integrity and consistency become critical security challenges to reckon with. This is partly because of the intricacy in planning data stores to keep entries once in each store, avoiding redundancy. One store can keep a reference to a piece of data stored elsewhere, but it should not be duplicated across many stores. From a security viewpoint, we are looking at the CIA triad of confidentiality, integrity, availability — all of which must be managed correctly to provide the organization with better levels of performance and continuity than it had in its monolithic days.

Dive Into Microservice Security

Microservice architectures bring agility, scalability and consistency to the development platform. However, security in these environments often lags behind.

A major concern we face in that domain is imposing the right level of isolation based on application type, platform and data in context. We also look at privacy, regulatory concerns and possible security automation to incubate within the DevOps life cycle.

Though DevOps has already made some strides toward integrating security into the development life cycle, there’s still significant work to be done in this space.

Want to learn more? Check out our paper, “Securing Microservice Architectures — A Holistic Approach.”

More from Application Security

X-Force Identifies Vulnerability in IoT Platform

4 min read - The last decade has seen an explosion of IoT devices across a multitude of industries. With that rise has come the need for centralized systems to perform data collection and device management, commonly called IoT Platforms. One such platform, ThingsBoard, was the recent subject of research by IBM Security X-Force. While there has been a lot of discussion around the security of IoT devices themselves, there is far less conversation around the security of the platforms these devices connect with.…

4 min read

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

12 min read - ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

12 min read

Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023

4 min read - Deployment of backdoors was the number one action on objective taken by threat actors last year, according to the 2023 IBM Security X-Force Threat Intelligence Index — a comprehensive analysis of our research data collected throughout the year. Backdoor access is now among the hottest commodities on the dark web and can sell for thousands of dollars, compared to credit card data — which can go for as low as $10. On the dark web — a veritable eBay for…

4 min read

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

17 min read - Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

17 min read