MICROSERVICES SECURITY: 12 PRACTICES TO MITIGATE VULNERABILITIES

Microservices Security is gaining weight thanks to  the growth of microservice architecture and an increase in cybercrime and a parallel proliferation of resistance forces.

When it comes to microservice adoption, 77% of software engineers and system architects say their company uses microservices.

The global cost of cybercrime will be  $1 trillion in 2021, according to McAfee’s “The Hidden Cost of Cyber Crime” report. IBM’s Data Breach Report found that a data breach costs an average of $4.2 million globally, and $9 million in the U.S. 

If those figures are not frightening enough, consider this: it took companies an average of 278 days to identify and contain a breach [that’s more than nine months!].

Even as the microservice concept spreads far and wide, it’s relatively new and best practices are still work-in-process. Our seasoned DevOps engineers and software architects readily share their know-how and recommendations.

What is Microservices-Based Architecture? 

As opposed to the monolithic structure, microservices-based architecture appeared as the solution to simplify development, deployment, and maintenance of big systems by breaking them down into smaller pieces.

Microservices Architecture is a structural approach to software development, whereby a system is designed from loosely-coupled, independently deployable and testable services, that are business function-centered.

Like Ford’s assembly line, this software solution breaks down a complicated process into several smaller operations. Teams specialize in a narrow service, and may choose their own programming language, release and test new features irrespective of other services.

This microservices method of structuring a software solution appeared as more monolithic systems proved too bulky to maintain, scale, and train teams to onboard and maintain them.

Microservices Security Challenges: Getting Bigger and More Nuanced 

Microservices security has always been a complex matter ridden with challenges. However, technological progress has led to new issues, even as it has helped to address others. 

For example, the evolution of technologies like 5G and IoT comes with downsides. As more cheap devices flood the market, they open up users to potential cyberattacks. Cheap IoT with substandard security features become even a bigger threat, when reinforced by the omnipresent connectivity and supersonic speed secured by 5G. 

Similarly, migration from on-prem deployment to hybrid or cloud environments presents its own set of challenges, as the perimeters become more blurred.  

Overall, the scope of common cyber weaknesses is broad, and so are the reasons for security concerns. 

An authority in the field, the non-profit organization based on the basis of the legendary MIT [Massachusetts Institute of Technology], compiled the industry’s point-of-reference catalogue: the Common Weaknesses Enumeration [CWE]. Not only do they classify every weakness as per research concepts, but they also keep updating the list as the new hazards emerge:

Interestingly, a report on cybersecurity evaluates a massive “154% increase in attacks year-over-year” between 2019 and 2020. In just one year.

Another 360 degree overview of the security challenges comes from another voice of authority in the field of information security: OWASP [Open Web Application Security Project]. The organization recently released its top 10 security concerns for 2021, its first update in four years.

You can see on the OWASP top 10 2021 draft chart below that Broken Access Control tops the chart, followed by Cryptographic Failures and Injection. 

Now that we have outlined the main challenges and know where to locate them, let’s get down to finer details and practicalities. Below are twelve best practices that can help ensure your microservices architecture is secure and attack-proof.

12 Microservices Security Patterns to Protect Your System 

Worldover, microservices security best practices are written based on costly mistakes. It’s safe to say that all of them are easier to prevent than face the consequences of ignoring them. Here are some of our recommendations for how to improve security and reinforce your microservices architecture.

1. Encrypt All Traffic to Microservices Using TLS

Encryption should be applied on all levels and for all services, especially  those carrying sensitive data. Even though any encryption is better than no encryption at all, we recommend using TLS 1.2 or later for this function. As of November 2021, TLS 1.3 is planned to be the latest version of the Transport Layer Security [TLS], which will help protect data flowing to and from microservices from such known vulnerabilities as CRIME, BEAST, POODLE, BREACH, and heartbleed.

• CRIME [Compression Ratio Info-leak Made Easy]
• BEAST [Browser Exploit Against SSL/TLS]
• POODLE [Padding Oracle On Downgraded Legacy Encryption]
• BREACH [Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext]
  

2. Authenticate All of Your Microservices Consumers

There are a lot of authentication techniques available, and some are more secure than others. Depending on the legacy systems you are using, you may be limited in alternatives, but it’s essential to protect each potential consumer of microservices [web services, mobile or web apps, IoT, end users].

Static API keys, usernames and passwords, cert-based mutual auth, one-time PINs, and biometrics can all be used among other methods of authentication.

3. Authorize with the Least Privilege Principle in Mind

Authorization and authentication are both often shortened to“Auth” — but they are not identical. While authentication involves verifying that an agent is who they claim to be, authorization involves giving permissions to access certain files once specific criteria is met.

A variety of different protocols for authorization exist, including  user-based, role-based, and permission-based authentication.

These are the common methods and tools used to authorize the access to a specific resource:

• OAuth 2.0
• Open ID
• XACML
• JWT

Whichever protocol your organization chooses to grant authorization to access a certain feature, it’s vital to ensure no blanket permissions are granted — only individual component permissions should be offered. Such an approach is referred to as the “least privilege principle”.

4. Protect Against DDOS Attack with Rate Limiting 

Bandwidth throttling or rate limiting is used to slow down malicious attackers. It can also be used to evenly distribute the network traffic and prevent bandwidth congestion.

A scaleup might assign low priority to this activity because they might not have as much traffic at first. However, this is a great measure to have in place from the beginning because it can help ensure continuity of service for the growing number of users.

Fun fact: in application development, this method is also used for revenue management purposes so that users can upgrade to premium accounts where there is no rate limiting.

When it comes to microservices security, rate limiting can be applied at different levels of services for multi-tier protection.

5. Have Automated Logging, Monitoring and Alerting Practices on Guard

Automated logging lets users drill down to the root causes of anomalies in a software system. Not only is it vital to log all major activities, but it’s essential to create automatic alerts in case of a brute force attack, or if somebody tries to use outdated credentials to log in.

If there is an irregular spike or decrease in normally observed patterns, a system should be programmed to send alerts to employees tasked with monitoring and reacting to these instances.

6. Design with Resilience in Mind

Servers may be not available, the application may stop having access to the file system, or a database may suddenly become inaccessible. These things will happen and the downtime can be decreased or avoided altogether by an array of methods. 

System availability and data loss prevention is critical for secure functioning of the microservices.

Having your servers in several regions is essential for resiliency, for example. You may want to ensure that your cloud can be switched in active-active mode, so that if one region becomes unavailable, the system is fully switched to another region. For applications that are not business critical, active-passive deployment will be more sensible with likelihood of some minor downtime but at a more reasonable cost.

7. Protect Your Most Sensitive Data: Encrypt and Store Securely

API keys, system credentials, passwords and other sensitive information should be encrypted — this data should never be stored as plain text.

Such sensitive data should never be stated into a source control system, but rather stored in environment variables (at minimum). In the best case scenario, similar delicate information should be encrypted and stored in special tools like HashiCorp Vault, AWS KMS, AWS CloudHSM, or even a physical HSM.

If you are overtaking a legacy system, check that there are no secrets in your source code by using SAST [Static Application Security Testing], which can be a part of source control systems like GitLab, GitHub, or a specific solution like SonarQube, Snyk, or Checkmarx.

8. Cloud Storage Security: Hash, Tokenize, and Encrypt Depending on the Data Type

Different types of sensitive information require different treatments for the best protection against malicious attacks and leakages.

Chintan Jain, the Director of Software Engineering, Consumer Identity, Capital One shared a table during the AppSecUSA 2017 conference:

Methods Of Sensitive Data Encryption And Hashing

9. Scan Infrastructure Code like Docker Files

Docker files is one of the microservices security best practices we couldn’t omit in this list. This lets you scan for known vulnerabilities in software used for a Docker image, or misconfigurations.  You can do this by either using Docker Hub or another solution like Clair, Falco, Snyc, or Qualys. 

It’s recommended that you use the right images from reliable sources to start with, opt for multi-stage builds and scan Docker images during the development and production stages. It’s also a healthy habit to update them periodically.

10. Automate Dependency Updates and Address Transitive Dependencies

Given that only 21% of code is custom-made, the sizable extent of reliability on third party libraries is telling. The situation grows increasingly complex as third-party libraries rely on other third-party libraries so scanning and controlling them becomes more difficult.

Those dependencies may have inherent vulnerabilities that create a hole in your application security ultimately. This is why updating them automatically as soon as their new versions come out is one of the popular ways to keep applications secure. 

Tools like Renovate, Dependabot, Greenkeeper, Glidebot, and Pyup are there to automate application dependencies updates.

Transitive vulnerabilities are tougher to patch and sometimes you’ll need to re-write the application to get rid of such dependency. 

11. Use RunAsUser in Pod Security Policy in Kubernetes

Kubernetes fans may consider configuring RunAsUser in their Pod Security Policy so that users cannot run containers as root.

For those using Docker Daemon to run docker containers, using rootless mode is the best practice.

Rootless mode is a good practice to protect your microservices from privilege escalation attacks. If a user runs containers as root and at least one of them is compromised, it’s a sure-fire way to compromise the whole containerized solution and all containers running on it.  

12. Defense in Depth 

If you have a military background, here’s a quick disclaimer: even though defense in depth derives from the military, it evolved along the way and means something totally different in IT.

Defense in depth here means that you design a tight-knit layered system of different defense techniques that are separately applied to every segment of your software system for maximum protection. 

This means that all of the practices described above should be used on every possible level for each separate service as well as for the system overall. For example, using well-designed authentication with MFA, implementing rate limiting, scanning dependencies, and putting a web application firewall to prevent web attacks is necessary to create a multi-layered application defense.

By baking security into your application proactively at early stages and across all facets of the software, you can save time and money.

It’s like having multiple different locks on every door to each room in your house and then a few locks on each safe in those rooms, as opposed to just having one lock on the entrance door. 

These twelve recommendations are in no way an exhaustive list of the measures you can take to protect your microservices architecture. But they are definitely a good starting point.

Getting Started with Security in Microservices 

84% of companies have adopted microservices to a certain extent by now, according to a 2019 survey by Kong. It’s only a matter of time until 100% of companies have adopted this approach and monolithic design becomes a thing of the past.

But as cybercrime continues to grow, microservices security architecture has received comparatively little attention.

If your organization contributes to the pool of companies who prefer to learn from their own mistakes or take an effort and instil proactively all the known barriers in the way of malicious agents is your own choice.

Communities like GitHub and organizations like OWASP and MITRE offer guidance and materials for the microservices security best practices discussed above.

If you want to audit your microservices architecture from a security perspective, DevPro’s DevOps engineers will happily share their expertise with you. Tell us about your security concerns using this form to find out what your urgent issues are and how to fix them.