Scott McKellar is currently a Technical Consultant at Mimecast where he has been since early 2019. Scott has been working in the technology industry for fifteen years and is passionate about technology & security. Scott enjoys understanding his customers and prospects often complex business challenges and aligning them with technology to solve problems and add value. Prior to his role at Mimecast, Scott headed up the technology team for an Australian leading Wi-Fi analytics SaaS and IaaS provider; Discovery Technology (a Data#3 company).
Compiling microservices have become the leading method of application development.
A 2021 survey showed that 71% of organisations had adopted them in some shape or form. But while microservices have many strengths, their mass adoption has introduced serious cybersecurity risks.
An application can be made up of hundreds of microservices, each with their own entry points and flaws, increasing your attack services exponentially.
What is a microservice?
A microservice is a software module that carries out a specific, narrowly targeted task. Each module functions independently with its own data storage and can be replaced, connected to or transferred from one project to another. Each microservice functions a separate service, and by arranging them in different ways, you can create a powerful application that can serve many functions. Effectively, they work as a single brick in a shifting wall of software architecture.
Microservices bring obvious advantages, and are hugely popular in cloud-based applications. They are readymade software modules that are relatively straightforward to deploy, can be upgraded separately, offer flexible scaling and have simpler programming requirements. As a result, they allow companies to keep costs down, increase app stability and reduce downtime, while offering far more flexibility than a more rigid, monolithic approach of building an entire app from scratch.
How microservices can introduce cyber risks into your organisation
The strength of microservices is that each is independent and different. Each has its own set of APIs, its own data entry and exit points and its own communication methods. Microservices may also have been designed in different environments, using different programming languages.
This mix introduces complexity, with each application potentially being made up of hundreds of microservices. You can test each microservice for flaws, such as the high-profile recent log4j zero-day vulnerability, but this process is a knotty one:
microservices are distributed across a range of cloud environments
individual services communicate over different layers of infrastructure, and communication between services may not always be tested
the numerous access points of a microservice architecture need to be managed, secured and regulated in real time
data will move, change and be stored in different places for different purposes across microservices, making monitoring difficult
the code base and data stores will grow as microservices are developed, and each item of new code brings potential vulnerabilities
Let’s break down the key risks, and how you can manage them.
Make sure containers are secured
Application containers are often used for microservice deployment, but they bring risks of their own:
They are based on software images, which may contain vulnerabilities of their own. Regular scanning will help ensure your images do not present any security issues.
They have both internal and external threat surfaces. Limiting user permissions via least-privilege or zero-trust policies is a crucial measure. Secrets should never be stored on a container.
Additionally, isolation rules can be set so that individual microservices can be implemented, maintained, extended and updated without affecting nearby services. Isolation should also be implemented on other infrastructure layers such as your database.
Data is at risk unless you protect it
We’ve seen how your data can be at risk if your organisation depends on microservices. HTTPS and encryption can reduce the chances of an attacker being able to access data. It’s also worth being cautious with plaintext, which can be easily read and copied. Personal information should be masked.
Modern microservices often span many networks and have multiple entry points. By limiting services to a single access point, or API gateway, you can authenticate users, manage access and stop users from directly communicating with microservices, reducing the risk of an exploit. An API gateway can offer SSL termination, protocol conversion, monitoring and request-caching, as well as token-based authentication.
Protect against DDoS attacks
Distributed denial of service (DDoS) attacks are increasingly targeting enterprise applications. These attacks seek to disrupt service by making multiple log-in attempts using different credentials, and a high-speed attack that can bog down requests and make resources unavailable. By configuring rate limits to accept only a set number of requests within a given time period, you can protect microservice-packed apps from DDoS danger.
Monitoring is a crucial part of any strategic mix
Microservices must be monitored for attacks and vulnerabilities and recommended changes should be implemented promptly to ensure code is up to date and applications are kept safe. Combining monitoring with all the approaches above will harden your defences, limiting gaps and protecting your data.
Microservices bring vulnerabilities – but they can be managed
Microservices will continue to grow, and for good reason. Thanks to their flexibility and role in the cloud they can help organisations build responsive, scalable operations that can exploit changes in the market.
Yet with any application potentially containing hundreds of microservices, they bring risk to your company, thanks to their sheer number and complexity. Security needs to be considered throughout their design, deployment and upgrading. Measures such as API gateways, least-privilege approaches and effective monitoring can help you ensure that your microservices don’t cause macro problems for your organisation.