Penetration Tests: Not just the normal cup of joe

Well, last week celebrates the ever so fun Information Security Summit in Independence Ohio. I usually try to sit in a few topics here and there to see what people are talking about. I must have sat in three different presentations where they preached that only high level risk assessments could find the core deficiencies in a security program. While I tend to agree to an extent on this, they also made the bold claim that penetration testing cannot accomplish this and is only used for "technical" findings.

Every time I hear this at presentations I wish Bobby Bouchey (pronounced "Boo-SHAY") from Waterboy would come out and pummel the guy on stage.



Unfortunately, nothing happens and I have to continue to hope one day Bobby or Terry Tate the office linebacker answers my prayers.





I'm not discrediting risk assessments at all, in fact they are a necessity, however, a penetration test can absolutely bridge technical and high level findings and identify core deficiencies in current process.

Lets take an example we see all the time during a penetration test. Lets say we do a buffer overflow on a third party application, lets pick on HP's OpenView. We see that OpenView has continuous buffer overflows all across the clients network, we also see that Veritas NetBackup has a ton of buffer overflows, lets see, so does VNC, and the list goes on.

One could logically deduce that third party patch management in the organization is failing and there is a process breakdown for the inventory and maintenance of these third party applications.

Lets take this a step further, a client has multiple domains, Domain A and Domain B. Domain A has a 10 character password lockout, 4 invalid attempts, logs everything, uses IPSEC for all communications, using NTLMv2 hashes, and all that other great security stuff you can do through group policy. Domain B has a 3 character password, unlimited attempts, no encryption, LM hashes, etc. etc. etc. We can assume that hardening techniques are not uniformly applied across the entire organization.

My point to all of this is penetration testing has evolved far beyond the "fix this patch and your golden" because we all now realize that if we fix this patch, there's another patch six months down the road that isn't patched and we have the same risk. Instead of doing the "fix this patch, fix this patch" we can say "fix your patch management process". Not many pentesting companies out there are doing this nor even understand what I'm talking about here. It's always been challenging to teach the nerds how to understand higher level functions of security.

Risk Assessments and Penetration Testing compliment each other extremely well. Where organizations say their patch management is an A+, when the pentesters come and rip open all third party applications and their grade is a D-, validation and testing offers and excellent understanding of gaps within current policies, procedures, and standards.

To close this whirlpool of thoughts, penetration testing isn't just for the techno weenies to plug holes, its to understand where the core deficiencies are within current process within the organization. Don't get me wrong, patching those holes are important and winning the battle, but identifying the root cause of those problems will ultimately help reach your secured state and win the war.