Zero Trust with distributed access control
The rapid increase in API attacks, denial of service and malicious bots poses new challenges for traditional web application firewalls. The first Part of this article looked at how modern security solutions counter these threats: With multiple protection mechanisms and artificial intelligence.
This second part looks at how an identity-based zero-trust architecture can be implemented to protect cloud-native applications in particular from unauthorized access. We also provide tips for selecting a suitable WAAP protection solution.
Criticism and challenges
WAAP is an effective supplement to protect web applications and APIs from current threats and attacks. A comprehensive security strategy includes a whole bundle of measures: Automated vulnerability scans, regular penetration tests or training in secure programming. Strong authentication and strict access authorizations are also important barriers against attackers. Ideally, these checks are carried out before the application is accessed, with login often being delegated to an identity and access management system (IAM).
Critics complain that the negative security filters can be fooled by professional hackers. This criticism is only justified in the case of systems that counter every single vulnerability with a corresponding signature. Such signature-based filters can be circumvented by varying the attack or by clever coding, which is referred to as “filter evasion”. Modern WAAP solutions, on the other hand, first perform multiple decoding and normalization of the data before attack detection begins. With structural intelligence and a few rules, they are also able to recognize not only individual attack examples, but entire attack classes.
Microgateways for containers and zero trust
The trend towards microservices, continuous delivery and short release cycles can also be a challenge for WAAP systems, especially if they are managed centrally by the IT department. If an application change requires even minor adjustments to the security rules, coordination between the WAAP operator and app owner can quickly become a bottleneck. In order to avoid such delays, WAAP functions are sometimes disabled altogether - hopefully only temporarily.
This problem can be solved with decentralization and additional powers for the application teams. The protection component is shifted towards the application: instead of relying solely on centralized filtering, each application or API is also given its own small protection system. These lightweight “mini-WAAPs” usually live in the same container as the protected microservice and are therefore called microgateways.
To a certain extent, the application team itself becomes the WAAP operator and thus gains more autonomy with regard to the security rules. In the spirit of “Shift Left”, the protection functions can be activated very easily during development or testing. This reduces the coordination effort and possible fire drills shortly before the release. This decentralized version of WAAP enables a zero-trust architecture in which every access is checked and authorized again “on site”.
![[Translate to Englisch:] Microgateways - Verteilte Application Security mit Microservices](/fileadmin/_processed_/b/d/csm_EGN_Service_Blog_WAAP-Content_Microgateway_2ee2d32950.webp)
Checklist:
Six questions to ask yourself when introducing WAAP
When selecting a WAAP product, it is worth looking at a few points that go beyond the feature list. You can ask yourself the following questions:
- Secure default settings: Are the filters already preconfigured and activated by an application security expert? Or is everything allowed through from the outset and has to be configured first
- High security level: Are the filter rules continuously developed and hardened? A bug bounty program, for example, is a strong signal: Only a solution that is already very secure can even afford to pay security experts to uncover security vulnerabilities.
- Reaction to zero-day vulnerabilities: How quickly is the product updated in each case? Ask how long it took Log4Shell, for example, for the WAAP filters to block all forms of attack? Or were the applications protected even before the vulnerability became known?
- Simplicity and support: Is the product based on an open source solution or is there professional support? What are the availability and response times for questions and problems?
- Container environments: What architecture options are available to protect microservices or serverless applications? How can cloud-native and serverless applications be protected?
- DevOps/GitOps: How can the product be integrated into DevSecOps processes? Can security policies be defined as code?
Shift left and shield right
Web applications and APIs in particular remain a target for cyber criminals. Application security must therefore be addressed as early as possible, ideally during the design and development phase. In addition to this “shift left”, effective protection is also required at runtime, which corresponds to a “shield right”.
WAAP solutions form this final protective wall and thus complete the security concept. They not only detect targeted attacks during operation, but also fend off distributed DoS attacks and unwanted bots. In the cloud environment, a trend from centralized to distributed application firewalls is also evident: microservices and container applications are now protected by microgateways. The close-knit network of these “mini-WAAPs”, combined with access management, forms a zero-trust architecture: with this approach, identity becomes the new perimeter. Accordingly, the application and API security solutions used should also work closely with access management and, ideally, be able to support the concept of Continuous Adaptive Trust. Continuous Adaptive Trust means more security with less tedious interactions for the user.
Thanks to a continuous risk analysis and ongoing comparison with the current level of trust, security can increasingly remain in the background. The identity and authorization of each call are constantly checked with the help of an identity provider, and user behaviour is continuously examined for malicious intentions.
Back to Part 1: The WAF is dead — long live WAAP!
Blognews straight to your inbox
The Airlock newsletter keeps you informed about new blog articles.