Over the last 5-7 years, microservices became a well-established trend in software development and proved its reliability — which is not something you can say about microservices security (or so it seems). Is there something wrong? Let’s see.
- In 2017, Uber’s users found out that their data was exposed to a massive data breach, with 57m accounts hacked.
- Not far from that time, Amazon suffered an attack as well, causing its numerous clients to lose half of their sales.
- Even PayPal, an impeccable example of digital security, was not always safe. In 2014, The Washington Post reported about a huge security breach that claimed a huge authentication vulnerability.
No wonder these breaches share a whole bunch of similarities. All these companies clearly had problems with digital security maintenance. Also, they were all built with microservices architecture.
Is microservices testing approach poor?
These massive attacks give a reason for reflection. Could it be that microservices are not safe yet, compared to monoliths? Perhaps, we haven’t learned how build microservices testing strategy? Are these attacks accidental or they demonstrate a consistent pattern? Let’s take a closer look to find out.
What are microservices?
Microservices is a type of software architecture where, instead of building one monolith service, the system is divided into smaller parts. Microservices products can perform the same way as monoliths, handling many functions impeccably. However, unlike monoliths, the microservices architecture allows you to get a complex platform (like Amazon, Uber, or Paypal) that remains scalable and flexible. What are the security challenges?
The key distinction of microservice architecture is its modularity. The same way you can compile microservices into one functional system — you are able to remove and replace them to get many small well-functioning services.
Each microservice needs to be tested
When working with this modular architecture, it’s important to understand clearly the function of each component and make sure it’s performed correctly. Let’s see what this means in terms of software security.
Microservices’ modularity is both a strength and a weakness. On one hand, it’s easier to deconstruct the architecture into tiny pieces, check them one at a time, and compile together after bugs are fixed and microservices performance testing stage is over. On the other hand, if one microservice will have a huge vulnerability, it is likely to destabilize the entire system.
To prevent breaches in Paypal’s mobile app, product developers created a two-step authentication system. After you enter login and password, you receive a text with a code. Only after the numbers are entered into the app, the authentication is complete.
Things turned out not as planned. Researchers at Duo Labs identified a critical vulnerability – a loophole that allowed hackers to enter the profile without passing the second authentication stage. A single mistake in authentication service compromised the safety of user’s data and became a tremendous dent in before impeccable Paypal’s security reputation.
By treating each microservice as a separate product (which means, testing it thoroughly), you can avoid such critical issues and their terrible consequences.
Here, however, the possible threats do not stop. It’s not enough to simply test each microservice separately, eliminating vulnerabilities one by one. After you are done with it, it’s important to test the entire platform in order to check the connection and communication between the services.
In order for microservice architecture to function, data has to “travel” from one service to another. It means you need to test transmitting algorithms and make sure that information doesn’t leak in the process. Make sure all the connections are working smoothly — one broken service connection can disable the entire system.
Best Microservices Security Practice
Looking at all the breaches discussed above, it might seem that microservices are not as secure as monoliths are. This, however, would be the wrong interpretation of reality. In fact, there are a bunch of microservices that have proven the security of such architecture.
Take Netflix, for example. With their smart approach to testing, the company has secured its database, applying basic security testing measures that allowed to avoid huge troubles. Let’s take a look at how the enterprise handles safety issues and formulate best practices to secure microservices.
Method #1 – Defence in depth
The textbook definition of ‘defence in depth’ is assurance concept which presumes the placement of multiple-layered security controls throughout the software system. This might sound somewhat vague, but really, it just means identifying the weakest services, detecting vulnerabilities, and eliminating them one step at a time. If each of your services is secure — so is the entire system.
Method #2 – Don’t aim to test the entire system at once
This is actually where the beauty of microservice architecture is showing itself to its fullest extent. You don’t need to tackle issues throughout the entire system but instead focus on one microservice at a time. When one is fixed, move to another one.
A security-saving tip: diversify the security layers for different microservices. If you protect each one with the same algorithm, you’ll make hacking the system a piece of cake — it’s just enough to get into one service to have access to the rest of them. If you use different protection algorithms though, it will be impossible.
Method #3 – Use what others have adapted
Experimenting is fun, but experimenting with security it’s also dangerous. Instead of reinventing the wheel, explore open source microservice testing tools, used by tech-innovative corporations like Netflix. The reason why the platform is so secure is that Netflix flawlessly adapts open source resources in its security strategy.
Netflix uses GitHub to power its open source development, and you can do the same thing. Look at what is already released and adapt it to your business if needed.
Method #4 – Automate security updates
Doing manual check-ups turns out to be irregular and ineffective. To avoid later issues, figure out the way to automate security evaluation as soon as possible — preferably at the first stages of product development.
We use code checking tools that allow us to find security issues and eliminate them promptly. Not only we save the time of our security developers but also have regular reports on our projects’ security status.
Method #5 – Use containers
Dividing microservices into containers makes security management much easier. These are the main reasons why:
- You isolate different running environments. If one is vulnerable, it will not affect the rest of the system.
- If you need to adopt a new language version, it’s enough to use a different container, there’s no need to rewrite the whole functionality. If something goes wrong, you can always pull back.
- It increases services’ speed. Containers are lightweight, therefore, faster.
- You can place containers on a public network and increase both the speed and security of request processing. This is exactly what Amazon did by developing an AWS API gateway, therefore, taking the responsibility for processing thousands of APIs at the same time.
Conclusions on microservices security
Saying that microservices do not have security vulnerabilities would be delusional. In some aspects, like establishing the safety of communication, they are more challenging than monoliths, on the other hand, their decomposability makes it easy to isolate the vulnerability and eliminate it.
In the end, it all depends on security testing. Some, like Uber, constantly face security attacks, other, like Netflix, manage to build a thick wall behind their data. Security testing decides whether the software is able to resist attacks and detect problems before any harm is made. If you want to ensure your software uses the best security testing product or have an idea for microservices in mind, let us know. Our award-winning team of security testers is on board – just drop a line.