For example, in the realm of web application security, an example of a primary security control might be parameterized database access to prevent SQL injection attacks or strict output encoding to prevent cross-site scripting (XSS) attacks. An example of a secondary security control might be a web application firewall (WAF) that also attempts to prevent such attacks before they reach the web application. Under these circumstances, a web application security assessment might be more of an assessment of the WAF’s security posture than an assessment of the web application’s security posture. Only those attacks that are not blocked by the WAF would actually reach the web application. The results of such an assessment would likely miss flaws that reside in the actual assessment target, the web application.
“So what? That’s what the WAF is for right?” you might ask. Well…
- Can your web application firewall policies become disabled inadvertently?
- Could future WAF policy changes negate some WAF protection?
- Could the hidden flaws in your web application be replicated by your development staff in other applications, possibly applications not protected by a WAF?
- Do you have public staging and test environments also protected with the same WAF policies?
- What about simple due diligence to make sure that your application defends itself?
- Could new methods of attack obfuscation bypass WAF policies in the future?
What I am saying is, if it doesn’t cost any extra, why not test both primary and secondary security controls? Assess the application’s “naked” security posture without WAF protection. Then enable the WAF protection and see which vulnerabilities are still vulnerabilities. Since it doesn’t take much time to re-validate what’s already been identified, we offer this additional service to those clients who desire it for no additional charge.
This way you get a clear picture of two different application security postures, the bare application, and the application with WAF protection. You also get to measure the true effectiveness of the secondary security controls you paid so dearly for, which might actually surprise you. Finally, you can remediate vulnerabilities at their source, in your application, so that if your WAF fails or becomes disabled, your more sensitive database content stays on your side of the firewall. These flaws are then known by your development staff and best practices to prevent them are integrated into future development efforts.
This concept goes beyond application security assessments and WAFs. Consider the following scenarios:
- A network vulnerability or penetration assessment will test any Intrusion Prevention System (IPS) protecting the assessment targets. Based on the client's needs, Depth Security might start the assessment exempt from preventative IPS policies to get an actual assessment of the security posture of the “naked” target hosts. Then once the "worst case scenario" results are documented, the IPS exemptions could be removed to determine which vulnerabilities are exploitable and which are mitigated by the IPS. Again, the point is to assess the "pure" security posture of the target and the "real world" security posture of the target plus any secondary security controls. For those clients with managed IPS services, this process really identifies the value (or more typically, lack thereof) that their vendor is providing. In the event that the IPS failed open or was improperly configured, the client would also have a solid idea of their network security posture without IPS protection.
- A social engineering scenario is requested that targets help-desk members with phishing attacks in an attempt to obtain their credentials or other sensitive information. The first control that this assessment would test would be any anti-spam functionality. In the case that anti-spam system fails to stop the phishing emails from being delivered, the next step would be to make anti-phishing exemptions to actually test the help-desk members susceptibility to any phishing emails that might make it through anti-spam controls. The first test verifies a secondary control, anti-spam; the second test targets a primary control, help desk members’ common sense.