How microservices have transformed enterprise security

The microservices revolution has swept across the IT world over the past several years, with 71% of organizations reporting adopting the architecture by 2021. When discussing microservices, we often hear their advantages framed in terms of agility and flexibility in delivering innovations to customers. But one angle that’s not spoken about as much are enterprise security concerns.

In the age of monolithic applications, a single security problem could mean hundreds or thousands of man-hours spent rebuilding an application from scratch. Along with having to patch out a security flaw itself, this also meant that DevOps and security teams would have to review and reconstruct the application to tweak dependencies — sometimes having to effectively reverse engineer entire applications.

Microservices have upended this paradigm. They allow DevOps to ring-fence security flaws or concerns and address them without worrying about breaking their entire application stack. This doesn’t just mean a quicker turnaround for security patches, but more resilient and efficient DevOps teams and IT stacks overall.

How microservices help ring-fence security flaws

Stepping back, it’s worth reminding ourselves what a microservice architecture is: A collection of services that are independently deployable and loosely tied together via 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 and standalone packages bundle application code with lightweight OSes, runtimes, libraries and configuration data. By using an orchestration system like Kubernetes, individual containers can exchange their outputs with one another, enabling them to perform the overarching task that would once have been achieved through a monolithic application.

The microservices architecture that is most commonly delivered by containers ring-fences many security risks by design. With individual microservices only exchanging their outputs via the intermediary orchestrating them, it’s very difficult for a breach or compromise of a single microservice to permeate the entire application. 

Playing with the calendar

But what does the above mean in practice? Here’s 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 that flaw into the calendar application that’s used in an enterprise environment. Now, imagine a black hat attacker spotted the issue before the security team did and then proceeded to obtain someone’s credentials and changed the current date in the calendar app to 1/1/1970. 

If the enterprise’s DevOps team worked with a monolithic application, they would have to do the following:

• First, they would have to contend with widespread system malfunctions arising from the attack, which they can’t fix until they address the flaw.
• Second, assuming they discovered the flaw was with their calendar app, they would have to examine the entire source code for the app and manually find where the problem lies.
• Finally, they would have to review the entire calendar app’s source code to change any references to variables or statements tied to the bugged lines of code.

What does this look like if that same DevOps team worked with a microservices architecture? 

• First, once the black hat attacker had changed the date, they would notice that the particular microservice that contains the flaw is malfunctioning. 
• Second, assuming they’re using containers, their Kubernetes distribution will flag that the particular container isn’t sending valid output data. 
• Finally, it’s a simple matter of the team reverting the offending container’s settings to before the malicious date change. 

Once they’ve done this initial diagnostic and workaround via a setting rollback, a team can then move to fix the underlying flaws that gave rise to the vulnerability. Throughout this entire process the broader calendar application — and everything that relies on it — has stayed online.

Microservices for efficiency and proactivity

There’s a big takeaway from the above story: In a microservices architecture, only the flawed component needs to be replaced or updated, not the entire application. This means less downtime when an issue or vulnerability does arise, since teams can identify and revert an individual microservice that’s compromised. Moreover, this creates less work for DevOps and security teams in addressing a flaw because they only need to rework an individual microservice, which is going to necessarily have less application code than a full monolithic app.

Additionally, microservices allow teams to be more proactive. Microservices enable this proactivity through the ring-fencing that prevents breaches or cascading vulnerabilities. This ring-fencing frees up teams to continually improve an individual microservice without having to think about the rest of the application.

That means a DevSecOps professional can focus on watching out for vulnerabilities or rolling out security updates. There’s no need for administrative or logistical work to stop a security update from breaking another microservice in the application. When it comes to fixing zero-day vulnerabilities or securing your app against emerging threats, this flexibility and freedom is priceless.

Because of microservices, teams can respond to security threats far faster and more effectively than ever before. And on the proactive side, microservices can enable teams to harden their systems at a dizzying rate. Altogether, that’s why microservices have changed the face of enterprise IT security: They let developers, operators and security teams work faster and with previously unparalleled flexibility.

Simon Wright is UK director of strategic solutions for Red Hat.

Originally appeared on: TheSpuzz