1 Introduction
In the past years, application architectures have made another huge leap forward in their evolution. Microservices architectures and container-based deployments have become the new normal, with APIs (Application Programming Interfaces) being the means for interconnecting microservices. With that, the evolution of software architecture continues, from the early days of modularization such as in subprograms or CORBA to a massive modularity within the applications themselves.
Every user benefits from this evolution day by day, mostly unknowingly, with updates becoming granular and continuous, replacing the big updates of the past. What happens in the background is nothing else than the replacement of microservices by newer (and, hopefully, better) versions, and the addition of new capabilities through new microservices. As long as APIs remain stable (downward compatible), other parts of the solution remain unaffected.
But not only the individuals benefit, but entire organizations in their digital journey. Modern, granular microservice architectures and flexible, container-based deployments are the foundation for agile software development and DevSecOps (Development, Security & Operations), i.e., the close synchronization of software development & security testing, delivery, and operations of software.
Unfortunately, there is a price to pay: Securing agile, dynamic workloads where every microservice exposes APIs requires different approaches for software security than the traditional way of architecting and delivering IT services. This is not to say that microservices architectures are less secure. Done right, it can be the opposite. But the way security must become implemented must become as granular as the architecture, and as agile and dynamic as DevOps is.
With every microservice exposing APIs, every microservice is subject to attacks and must be protected. The attack surface is broadening, and the risk of so-called east-west traffic, i.e., attackers moving from one microservice to the next, is growing. The lateral attack surface is a challenge to address. Various attack vectors are of relevance, from the well-known OWASP Top 10 attacks to other types of attacks such as credential stuffing and others. Some of these attacks are also related to security challenges in the DevOps tools chain, where attackers might move laterally through the chain as well.
We observe a strong uptake in solutions for securing the gits (code repositories) such as GitHub, the DevOps tools chain, and the code, such as SCA, SAST, and DAST. SCA stands for Software Composition Analysis and is about understanding the components or modules within an application. A prominent use case is analyzing whether a software is affected by the Log4j vulnerability by identifying whether the Log4shell component is used. SAST and DAST are Static/Dynamic Application Security Testing, i.e., approaches that run tests against software to identify vulnerabilities in the applications, with DAST analyzing the run-time behavior of applications. Another area of software solutions is the field of API Security & Management products, which help in managing, monetizing, securing, and protecting APIs.
All these approaches sit outside of the software. Thus, they don't operate at the level of the individual microservices. The same holds true for solutions such as Web Application Firewalls.
While there is no single or simple solution for solving the security challenges in today's software, DevOps, and agile IT environments, and while all the various technologies mentioned are building blocks of a comprehensive approach on securing software, there is a need for baking security deeper into the world of modern applications, ideally without requiring developers to change code or to create custom integrations.
One approach in this field is the R&S®Trusted Application Factory by Rohde & Schwarz Cybersecurity. This solution integrates at the container- or pod-level to enforce web application and API protection.