Microservices introduce hidden security complexity, analyst warns

Companies are rushing to climb aboard the microservices bandwagon, but they are not doing it for security reasons, warns Alexei Balaganski, lead analyst at KuppingerCole.

“They are doing it for agility, reducing time to market, simplifying deployment and scalability in the cloud, which are all important, but they are not thinking about security at all,” he told Computer Weekly.

When it comes to developing applications for new business functionality or revenue, said Balaganski, security is either not a priority or security teams are still working in isolation from development and operations teams.

“This isolation is probably the biggest challenge, and it is the challenge of getting security and production people to work together and not against each other that the notion of DevSecOps is aiming to address, and for this reason, it is an important methodology for organisations to consider,” he said.

The problem is that very few organisations have implemented this approach, said Balaganski, and so most are still focused on getting new applications into production as quickly as possible, thinking they can deal with the security implications later.

“And whenever a particular security challenge arrives, the response is usually a point solution,” he added. “And so a company will deploy a container security system, for example, because they are running most of their systems in containers, and think the job is done, but it isn’t because they have 10 other exposed threat vectors that they also have to think about.” 

At the heart of the problem is that there is no single way to design a microservice, which means a single application can be made up of microservices running in different environments, using different communication channels and even written in different programming languages.

“While this approach makes it easier to develop, deploy, debug, maintain and operate microservices separately from all the other components of the application, it also means that several layers of complexity are introduced,” said Balaganski.

“But it is distributed and not as noticeable as it would be in a monolithic development team, and therefore it is easy to overlook. As a result, not enough attention is paid to securing low-level infrastructure, such as the virtual machines and containers that are common in a microservices architecture.”

The security complexity is further compounded by the fact that every framework development stack has its own problems, he said. “Then there is an API [application programming interface] layer, which has its own security challenges, as well as messaging protocols used alongside or instead of APIs for communications between microservices.”

And on top of all of that, there is some kind of control plane, or service mesh layer that controls service-to-service communication over a network and automates some basic functionalities, such as secure communications, service discovery and load balancing.

“So you have this huge new complexity on many levels, and yet many people – especially developers – tend to think it will sort itself out somehow,” said Balaganski. “But the fact is that in most cases, nobody is thinking about it as a whole.

“Developers, security professionals, operations people and compliance officers all have their own areas they are focused on, but more often than not, no one is looking at the bigger picture, and this is probably the biggest problem because on the one hand you have this new level of complexity, and on the other hand you have complete loss of visibility on the whole system.”

Microservices security is something that needs to be tackled urgently, but this is challenging, said Balaganski, because there are almost no established design patterns, best practices or standards for the design, implementation and maintenance of microservices.

“It is important for organisations to first realise that there is a problem that they were not previously aware of and that they need to start asking the right questions and looking for the answers,” he said. “If organisations are not aware of the problems, they won’t be looking for solutions.”

Understanding the basics of how microservices work and the security implications of using this architecture is a good place to start, said Balaganski. “If you don’t know the basics, you can’t plan your further strategy based on an informed risk assessment,” he said.

“In terms of finding out what questions to ask, they should be looking at the draft special publication from Nist [the US National Institute of Standards and Technology] on Security strategies for microservices-based application systems, which is basically a list of things that need to be considered.”

The document summarises all the security problems associated with microservices, said Balaganski. “I am pretty sure most security people have not thought of at least three-quarters of these potential risks, and it is up to each company to evaluate the likelihood of each potential risk,” he said.

“If you can’t assess the potential security impact for your organisation, you will probably end up spending your budget in the wrong way.”

In the absence of any standards or frameworks, said Balaganski, the most important thing is awareness of the problem, so that organisaions begin to work out how to make security another useful tool in improving developer agility and business continuity, rather than security being a liability.

“For developers, operations and business people, microservices are awesome because they seemingly reduce complexity of application development, but there needs to be awareness that complexity is hidden elsewhere,” he said.

“The complexity doesn’t go away – it is typically just redistributed to a technology stack like Kubernetes or a third-party vendor, and organisations have to understand that and keep it in mind. By using a microservices architecture, organisations are adding more layers of complexity and someone has to manage those layers.

“Someone has to think about the new risks that those layers are exposing, and although it is partially becoming the responsibility of a third party, it is the organisations that own the code and data that will suffer in the end if security vulnerabilities lead to data breaches.”

Balaganski will discuss this topic in more detail in a presentation entitled Securing microservices: Not as easy as you might have expected in a dedicated microservices  track at the European Identity & Cloud Conference 2019 from 14 to 17 May in Munich.