Compared to monolithic applications, which house all code in a single system, microservices are small, autonomous units that address individual functions and work with others to help an application function. This helps organizations deliver large and complex applications rapidly and more reliably.
Along with the many benefits of updating monolith systems to microservices architecture, there are also new security challenges that organizations need to address.
Instead of a single entry point, microservices offer many potential points of vulnerability, and as such each one needs to be effectively secured in order for an application to operate effectively.
Secure By Design
Integrate security into the development lifecycle by turning the DevOps model to DevSecOps. With a DevSecOps model in place, performance, scalability, and security are weighed equally without any bias. Establish continuous tests like Static Analysis Security Testing (SAST) and Dynamic Analysis Security Testing (DAST).
SAST is a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. It is one of the most mature application security testing methods in use, its white-box testing, where source code is analyzed from the inside out while components are at rest. Understanding security flaws is the first step toward remediating security flaws and thus reducing software risk.
DAST is a process of testing an application or software product in its running state. DAST comes into play when an application has gone into production or entered runtime, after initial development phases. It is a black-box security testing technique in which the application is being tested without exposing the source code or the application architecture. In this way, it can cast a spotlight on the runtime issues which cannot be easily identified during a static analysis like the authentication and server configuration issues, as well as issues or vulnerabilities which is detected only when a known user logs into the portal.
DAST can also cast a spotlight in runtime problems that can’t be identified by static analysis for example, authentication and server configuration issues, as well as flaws visible only when a known user logs in.
Defense in Depth
“Defense in depth” is defined as “an information assurance concept in which multiple layers of security controls (defense) are placed throughout an information technology system.” You need to identify your most sensitive services and manually apply many different security layers to them to get more challenging for a potential attacker who can exploit one of your security layers.
The goal of a defense-in-depth strategy is to prevent potential attackers from exploiting the entire application. If one microservice is exploited, the attacker, ideally, should not be able to move laterally to other services.
Practice Isolation
In a typical microservices-based application, you should be able to build, test, extend, deploy, and maintain the application in an isolated way, i.e., none of these activities should affect the functioning of any of the other microservices in the application.
You should implement isolation at the database level as well. This means that each microservice should have its copy of data and should not be able to access the data pertaining to the other microservices in the application. By implementing isolation at all layers, you can make your microservices-based application more secure.
Container Security
Microservices more often than not, rely on container technology. Therefore, securing containers is one way to reduce the attack surface and risks. There are several official industry standards which provide security recommendations on securing your containers.
- NIST Special Publication 800-180, NIST Definition of Microservices, Application Containers and System Virtual Machines It was originally published on https://www.apriorit.com/
- NIST Special Publication 800-190, Application Container Security Guide It was originally published on https://www.apriorit.com/
- NISTIR 8176, Security Assurance Requirements for Linux Application Container Deployments It was originally published on https://www.apriorit.com/
Namely, some practices to secure your containers are:
- Create immutable containers
- Run images from trusted sources only
- Secure access to images with a registry
Scan Dependencies
More than often, many libraries used to develop software depend on other third-party libraries. These relatioships might pose vulnerabilities for your systems. You should regularly scan an application’s source code repository, new code contributions, and deployment pipeline for vulnerable dependencies.
Use Access and Identity Tokens
In microservices deployment, a large number of applications and services will require secure authorization and access control. An authorization framework such as the OAuth 2.0 and OpenID enables you to process the tokens securely, hence protect your microservices.
OAuth is one of the most effective strategies for user identity and access control. Although there are several other authorization protocols, and you can also build your own, it is best practice to use the OAuth since is more standard, stable, and widely accepted.
Encrypt and Protect Secrets
API keys, secrets and credentials used for communication should be protected. Do not store them in your source control system. Encrypt them using tools like Microsoft Azure Key Vault and Amazon KMS. This approach ensures the keys needed to decrypt any data are always unique and safe.
Use Rootless Mode
Docker 19.03+ has a rootless mode that was designed to reduce the security footprint of the Docker daemon and expose Docker capabilities to systems where users cannot gain root privileges. If you are running Docker daemons in production, this feature adds an extra layer of security.
Time Based Security
Time-based security assumes that a system is never fully secure. In addition to preventing intruders from entering the system, detection and reaction are essential for securing a system.
Client Traffic Rate Limiting
Limiting the external traffic prevent issues such as denial of service (DoS) attacks as well as instances where some clients consume most of the application bandwidth.
You can rate limit using the API gateway, through the code, or any other technique. Usually, most of the SaaS environments have API rate limiting to minimize abuse by users as well as attacks.
Use API Gateways
In a typical microservices-based application the service consumers are not able to communicate with the microservices directly. An API Gateway is used that provides a single point of entry for directing traffic to various microservices.
This way the clients don’t have any direct access to the services and cannot exploit the services. If your API Gateway is placed behind the firewall, you can add a layer of protection around the attack surface.
Once you have placed the API Gateway behind the firewall, you’ve secured all the microservices you’re using in this application. API Gateways are usually secured using token-based authentication.
Monitor Your Systems and Services
Since microservices rely on distributed systems, you need to have a reliable and effective monitoring strategy for all the individual components. Deploying continuous monitoring allows you to detect and address security risks in a timely manner.
Dimitris is an Information Technology and Cybersecurity professional with more than 20 years of experience in designing, building and maintaining efficient and secure IT infrastructures.
Among others, he is a certified: CISSP, CISA, CISM, ITIL, COBIT and PRINCE2, but his wide set of knowledge and technical management capabilities go beyond these certifications. He likes acquiring new skills on penetration testing, cloud technologies, virtualization, network security, IoT and many more.
