How Microservices Transformed Enterprise Security

THE microservices revolution has swept the IT world in recent years, with 71% of organizations reports adopt the architecture by 2021. When we talk about microservices, we often mean their advantages in terms of agility and flexibility in delivering innovations to customers. But one angle that isn’t talked about as much is that of enterprise security concerns.

In the age of monolithic applications, a single security issue can mean hundreds or thousands of hours of work spent rebuilding an application from scratch. In addition to having to fix a security flaw himself, it also meant that DevOps and security teams had to review and rebuild the application to adjust dependencies – sometimes effectively having to reverse engineer entire applications.

Microservices have changed this paradigm. They allow DevOps to isolate flaws or security issues and fix them without worrying about breaking their entire application stack. This doesn’t just mean faster execution of security patches, but more resilient and efficient DevOps teams and IT stacks overall.

How microservices help contain security vulnerabilities

Taking a step back, it’s worth remembering what a microservice architecture is: a collection of services that are independently deployable and loosely linked together through intermediaries such as APIs. These individual services typically reflect the most fundamental building blocks of your applications.

In practice, containers are the technology used to deliver microservices architectures. These lightweight, self-contained packages bundle application code with lightweight operating systems, runtimes, libraries, and configuration data. Using an orchestration system like Kubernetesindividual containers can exchange their outputs with each other, allowing them to perform the overall task that would once have been done through a monolithic application.

The microservices architecture that is most often provided by containers isolates many security risks by design. Since individual microservices only exchange their outputs through the intermediary orchestrating them, it is very difficult for a breach or compromise of a single microservice to permeate the entire application.

Play with the calendar

But what does the above mean in practice? Here is a thought experiment.

A few years ago, manufacturers discovered that many consumer devices were rendered unusable if their date was changed to 1/1/1970. Imagine if we introduced this flaw in the calendar application used in an enterprise environment. Now imagine a black hat attacker spotted the problem before the security team, then obtained someone’s credentials and changed the current date in the calendar app to 01/01/1970 .

If the enterprise DevOps team was working with a monolithic application, they should do the following:

• First, they would have to deal with widespread system malfunctions resulting from the attack, which they cannot resolve until they fix the flaw.
• Second, assuming they discovered that the flaw was in their calendar app, they would have to examine the app’s entire source code and manually find where the problem lies.
• Finally, they should review the entire calendar application source code to change any reference to variables or statements related to buggy lines of code.

What would it look like if that same DevOps team were working with a microservices architecture?

• First, once the black hat attacker changed the date, he would notice that the particular microservice that contains the flaw is malfunctioning.
• Second, assuming they are using containers, their Kubernetes distribution will report that the particular container is not sending valid output data.
• Finally, it is simply for the team to restore the settings of the offending container before the malicious date change.

Once they have performed this initial diagnosis and workaround via a settings restore, a team can then move in to fix the underlying flaws causing the vulnerability. Throughout this process, the larger calendar app – and everything that depends on it – has remained online.

Microservices for efficiency and proactivity

There is a big lesson to be learned from the story above: in a microservices architecture, only the faulty component needs to be replaced or updated, not the entire application. This means less downtime when an issue or vulnerability arises because teams can identify and roll back an individual microservice that has been compromised. Additionally, it creates less work for DevOps and security teams to fix a flaw, as they only need to rework an individual microservice, which will necessarily have less application code than a full monolithic application.

Additionally, microservices allow teams to be more proactive. Microservices enable this proactivity through silos that prevent breaches or cascading vulnerabilities. This separation allows teams to continually improve an individual microservice without having to think about the rest of the application.

This means that a DevSecOps professional can focus on monitoring vulnerabilities or deploying security updates. No administrative or logistical work is required to prevent a security update from breaking another microservice in the application. When it comes to fixing zero-day vulnerabilities or securing your application against emerging threats, this flexibility and freedom is invaluable.

Thanks to microservices, teams can respond to security threats much faster and more efficiently than ever before. And on the proactive side, microservices can allow teams to harden their systems at a dizzying rate. Overall, this is why microservices have changed the face of enterprise IT security: they allow developers, operators, and security teams to work faster and with unprecedented flexibility.

Simon Wright is UK Director of Strategic Solutions for Red Hat.