The majority of our assessment clients choose a full-disclosure approach to security assessments. They realize that this helps us maximize results in terms of vulnerabilities discovered thus providing the most value for a given cost. Other times assessment clients are interested in zero-knowledge assessments that simulate an attack from an outside threat with minimal knowledge of a target. Although both scenarios are valid we don’t think they have to be mutually exclusive. Why not have your cake and eat it too? And with that we now offer the testing of primary and secondary security controls separately in order to gain knowledge of a target’s multiple security postures.
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?
I’m not saying that it isn’t important to measure the effectiveness of secondary security controls like WAFs. To the contrary, I’ve seen too many WAFs deployed in such a way that they are all but worthless. I’ve seen security personnel who were quite certain their WAF would stop my attacks during an assessment only to find out that the WAF was still in “learning mode,” the way it was left when the WAF vendor did the initial installation. The dead-bolt doesn’t help you much if you leave the key stuck in it.
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.
Thinking in terms of multiple security posture or security “states” fosters a better understanding of a target’s total vulnerabilities and the effectiveness of secondary security controls. Furthermore, this method of thinking leads to a better idea of what to expect in the event of a failure or improper configuration in these secondary security controls.