During the last few years, microservices have reached immense popularity in the software engineering world driven by, first, the move towards cloud computing; second, the availability of a plethora of enabling platforms, most notably, Docker, Google Container Engine and Amazon EC2 Container Service; and third, propelled by powerful evangelists, such as Amazon and Netflix, who are often cited as success stories in the adoption of microservices.
Although there is no formal definition, a microservices architecture can be described as a software engineering approach in which loosely coupled components communicate with each other using cross-platform messaging systems to implement large applications collaboratively. Other characteristics that define microservices are the support of standardized communication protocols (typically REST APIs over HTTP paths exchanging JSON or XML data), and a reliance on a “container” that provides infrastructure services such as transparent instantiation (which drives the scalability) and component isolation, which drives resilience and fault-tolerance.
In one way, we see microservices as a natural evolution of the increasing modularization of software: as in “progressively breaking down monolithic applications into smaller, more specialized components.” For instance, one component that became decoupled many years ago was the database; today few-to-zero developers would build a dedicated database system from scratch as part of the core application, but this has not always been the case.
In the microservices world, each of the conforming components range from a “simple” business logic calculation that the developer wants to isolate from the rest of the application, all the way to a very large component that requires its own application server, database, and storage.
The main advantages offered by microservices are scalability, availability, the ability to combine different languages, and to easily manage and run parts of the application as independent entities (also known as maintainability). On the other hand, like any other software design architectural pattern, microservices are not a silver bullet, and they are not ideal for every business case. In fact, requirements that had already been solved in traditional architectures, such as management and rollback of failed transactions, often require manual handling in microservices platforms.
Security in microservices: new architecture, same problems
To begin with, the most important risks represented by the OWASP Top 10 are still relevant. However, there are a few important differences between microservices and classic applications that make MVC security patterns not directly applicable to API security.
First and foremost, the notion of application perimeter blurs
Monolithic applications have clear and defined entry points, which define a “trusted” boundary layer within which, components can expect a fair behavior from each other. Some microservices design patterns recommend creating internal and external microservices equipped with different levels of validation protection and authentication (through API gateways). However we believe that a best practice to leverage all the benefits of the microservices architecture is to treat every single microservice as an independent cell without making many assumptions about its scope and its location inside their general app deployment ecosystem.
Second, the preferred response format in a microservices architecture is not HTML
The idea is that even client-facing microservices respond with structured data such as JSON and/or XML, not unlike a server-facing API, and subsequently a client-side API such as Angular is leveraged to format this API response, and assemble the content that the user browser ultimately renders. A very similar process involves the idea of web forms as data entities that provide data to the server. APIs don’t generally understand the HTML form concept, and consider everything to be a “link.” This complicates parameter binding validation.
Third, authentication and authorization become distributed
All services must perform checks to ensure compliance with business logic flaws to determine who can do what. Several design patterns help to build a distributed authentication, typically with the help of tokens and OAuth services. However, security bugs are only about 50% of the vulnerabilities, so developers must not forget the other 50%, business logic flaws.
Fourth, input validation also becomes distributed
Microservices must validate all inputs. This is no different than regular apps, but it is so important that we wanted to bring attention to the potential implications of having to do input validations across many microservices. In monolithic applications perhaps the team can do a good job with manual validations, but in microservices architectures, the complexity increases and automated validations gain attractiveness.
The combination of the differences above –no boundary, no HTML, multiple authorization checkpoints– hampers the ability of Web Application Firewalls (WAFs) to correctly protect a microservices architecture as traditional WAFs were designed with monolithic applications in mind.
According to Gartner, “Publicized API breaches, as well as ever-growing web API usage, are increasing the importance of API protection. However, to date, most API threat protection focuses on API content validation and traffic throttling, based only on preconfigured rules. This is the approach taken by many API mediation products, particularly API gateways, as well as application delivery infrastructure products, including web application firewall (WAF), content delivery network (CDN) and ADC products” – Hype Cycle for Application Security, 2018.
Hdiv approach to agile microservices security
Even more so than in traditional web applications, in microservices architectures security should be part of the entire Software Development Life Cycle (SDLC). The main reason is that the level of discipline and maturity required to secure an application based on microservices is high. The complexity of manual testing increases geometrically with the number of microservices, which is why automatic detection and protection become highly important.
Hdiv works with your microservices and APIs to enable DevSecOps methodologies and scalable automatic protection by providing the following essential protection:
Hdiv bug detection during microservices development
During development, Hdiv offers developers security bugs detection (such as SQL Injection, XSS, Path Traversal and up to 40 more) as well as third party vulnerable software detection and CVE protection. Hdiv provides an IAST approach (interactive application security testing), which is more efficient than the SAST and DAST approaches. Hdiv scores 100% in OWASP Benchmark with zero false positives.
Runtime protection against security bugs
Second, protect your microservices and APIs by deploying Hdiv security bug runtime protection. Not all security bugs can be resolved during development, due to the pressure to release code faster to production, and tight development deadlines. Hdiv blocks the exploitability of these security bugs that sneak into production applications. This approach also applies to legacy microservices.
Automated whitelisting to protect microservices business logic flaws
Syntax bugs only represent 50% of the security issues. Regarding business logic flaws, Hdiv provides API integrity enforcement that prevents business logic attacks, such as manipulation of REST URLs (a key element of microservices messaging schemes), manipulation of JSON bodies, and parameter tampering. How do we do this? Since Hdiv is a component embedded within your microservices, it has complete visibility of the data flow from request to response, which allows the creation of automatic whitelists. The whitelists enforce protection against business logic attacks.
Hdiv is cloud-ready
Hdiv supports any cloud environments, including Amazon EC2, Microsoft Azure, Google App Engine, Docker containers, and Cloud Foundry. Your microservices will be protected wherever they go.
According to Forbes, 2017 was the year of the API and microservices. At Hdiv our goal is to empower developers to create self-protected apps that are also scalable and portable.