How security controls affect web security assessment results

Results. That's what we look for in our web vulnerability and penetration testing. It's also what management expects.

However, time and again, I see web security testing taking place under the guise of deep inspection and full disclosure, but that's not really what's happening.

There are two sides to the web security assessment equation. There's the desire to find all of the security flaws so they can be resolved, and then there's the desire to protect one's territory -- and job. Unfortunately, these are conflicting goals, and this results in web security assessments that aren't where they need to be in terms of finding everything possible in the best interest of the business.

Front and center in this conundrum is the issue of whether or not to leave security controls that are built into firewalls, intrusion prevention systems and web application firewalls enabled when performing web application vulnerability scans and penetration tests. After all, these controls are real world, so why wouldn't you leave them enabled? But if the end goal is to truly find all the possible security flaws in the web environment, then leaving these controls enabled is not likely to enable you to get the results for which you're looking. 

Controls, such as denial-of-service prevention, port scanning detection or exploit blocking, can stop a network or web vulnerability scanner in its tracks, with no further progress to be made. Even perimeter controls, such as bandwidth throttling, can get in the way of web security testing and skew the results, especially when HTTP request failures occur and subsequent and proper retests are not done. This leaves those on the receiving end of web security assessment reports with a false sense of security.

It sounds like common sense that you would disable such controls, but they help maximize the efficiency of the tests and the number of flaws discovered. However, I often see network and security managers, who are frequently backed by their peers and superiors, state that protective measures will remain enabled.

This begs the question of how many security flaws, such as the commonly overlooked security basics that impacted organizations like Equifax and the U.S. Securities and Exchange Commission, are still lurking and waiting to be exploited because vulnerability scans and related penetration testing was blocked, and no further testing could be performed?

I have experienced this in numerous projects and, when it happens, the only thing that can be done is to put a caveat in the report that states specific testing was blocked and further tests could not be performed, along with recommendations to perform a fuller -- and proper -- web security assessment in the immediate future.

All of this begs the question: What is it you're trying to get out of your web application security testing? Are you trying to test your IT and security controls or are you trying to find application vulnerabilities? Since they're two different things, you have to distinguish between them. Furthermore, management needs to be in the loop as to which type of testing is being performed and why that decision was made.

I see this issue quite often in email phishing tests. The assumption is that if the phishing emails are blocked and don't make it to the end user, then everything is sound and secure. But what about the malicious email that does end up making its way into users' inboxes? It's a test of the users at that point. They're completely different things, but the latter is what has to be done if you're going to show proper testing has taken place.

I've never been impressed with the SSAE16 and SOC 2 audit reports that many people, including application service providers and cloud vendors, are so quick to push on us. By and large, they mean nothing in terms of web security -- specifically technical security checks, such as SQL injection, password security and user session management. Still, many people treat them as gospel.

The assumption is that since the data center audit report looks good, then the web environment is secure. That's absolutely not true.

In the context of leaving network security controls enabled, I'm starting to think the same thing about all web vulnerability and penetration test reports. Are they a true reflection of reality? Is the security posture of the web application really as it seems, or is there more to the story?

Unless and until web application security testing is performed unfettered, I'm going to say that there's more to it that remains unknown.

Unless and until web application security testing is performed unfettered, I'm going to say that there's more to it that remains unknown. In other words, if in-depth testing can be conducted with security controls disabled, then you can fully trust what you read in your web security assessment reports.

Incomplete web security assessments are not unlike incomplete CT scans or bloodwork. In the case of healthcare, the doctors may go through the motions, but stopping short of thorough testing and not getting good readings is a surefire way to misdiagnose the patient.

Like the patient and his primary care physician, does legal or executive management know the level of web security testing that has taken place? How about an internal audit? Are they aware that the true picture of web security health may not be fully represented?

Be it personal health or enterprise security, as long as expectations are properly set and decision-makers know that a complete analysis was or was not performed, then that's about all you can do.