A shield is a block of code that modifies application behaviour to fix a known exploitable vulnerability. Like a micro service, it becomes a functional part of the application. For the exploitable flaw to be secured, all traffic must flow through the shield, hence traffic is forced through a reverse proxy hosting the shield, placed in front of the application.
The reverse proxy is integrated into the application flow using the existing vulnerable application messages , hence no code in the application need to be touched. Once deployed, the vulnerability is not longer present hence no alerts are generated hence no 24/7
monitoring is required. However the application team must consider the presence of a shield during any functional changes.
Also note that given a shield is a block of code, it is subject to the laws of appsec, so should be in scope of security testing itself.
Example Shield for injection on the login parameter username
Example Shield for predictable session cookie leading to session hijacking
A WAF rule contains both a detection signature and action/s to perform. It is applied to traffic at the http layer. The detection signature may include behavioural characteristics over a number of requests.
Standard detection rulesets (eg OWASP ModSecurity Core Rule Set) are available either open source or within vendor products. The actions available include:
- Send an Alert to a SOC/SIEM
- Block or Allow ( blocking is either via a TCP reset in a SPAN port deployment or responding with a blocking page in a reverse proxy deployment)
- Add/Remove header or cookie
A shield is a block of code that modifies application behaviour to fix an exploitable vulnerability in the application.
Due to the potential to block legitimate traffic that has been classified as suspicious, log monitoring and emergency tuning is required 24/7
Example WAF rule for injection on the login parameter username. Note no WAF rule can be developed predictable session cookies