Thursday, October 28, 2010

What's wrong with Penetration Tests, and how we can set it right (India Edition)

Penetration Testing is complicated, especially so for organizations that have to fix the issues from the debris, that is their IT infrastructure components. Over the past few months, I have had tons of experience leading and handling pen-tests for companies in the sub-continent and decided to rant. I thought of writing some of the problems that are out there and also some possible solutions to some of these issues, which will make these pen-tests a whole lot easier and a whole lot more efficient. They are:
Test Everything - Fix Nothing
This is a condition I have seen management typically have with Internal Pen-Tests or Large Application Pen-Tests. Management would like to include a ridiculously large scope of components to test. They include everything from their Database server, right from the laptops that they use at home as part of the Pen-testing activity. The results in most cases (especially with Internal Pen-Tests involving client side systems) is really ugly. Multiple exploits, backdoors and in some cases, traces of popular worms like Conficker (yes, I am not kidding). What follows is a gigantic report and what follows that is......Nothing. I have often seen that organizations who adopt this policy usually dont get anywhere in fixing the problem. They find so many loose ends to tie up, they huff and puff and eventually pack up and go home. This brings me to my first point in this rant-post:
Start small (or manageable) - Many organizations (especially ones new to VAs and Pen-tests) usually go gung-ho and then fizzle out after seeing adverse reports. My advice to you is to test everything in doses that you can handle. Prioritize on the critical components first and then phase your testing for across the year. Also, testing everything (literally) may not be required. Mirroring results for similar IT components/applications is easier than literally testing every single component. For instance, upon finding security holes in a Debian Server, it is probably a good idea to fix issues on a sample of servers and roll out similar operations across the other similar servers in the environment. Additionally creating a solid Hardening standard for Debian Servers, coupled with Patching would not necessitate the need for testing every single one of these similar components.
Ridiculous Time Frames
Sometimes, we are given ridiculous time frames to work with. "Hey, can you test my E-Commerce app in two days. I dont have more time than that. Also, I have to fix the problems after that." and my reaction to that is usually "Oh, you wont have to worry about too much to fix, I probably would need two days to just understand your site, and since you only have two days, I will give you a clean report" in my most sarcastic (and borderline mocking) voice. While time is a constraint, such super constrained timelines only result in a untested and potentially non-secure environment. I am sure no one, either management or the pen-tester would like to turn up with false negatives and find that their application/server/network component was super-vulnerable only because they hadnt the time to possibly test extensively. That will come back to bite a lot of people.
Fixers are Breakers
This is a condition I normally see with Application Pen-Tests, where the management is extremely clued in on the test before the commencement. Statements like "We would like you to be extremely comprehensive and give us all our security holes right between the eyes". Later when we deliver our report of their Hindenburg-like app and discuss with them, the very same people become the worst enemies of everything sane and secure. I would be discussing a gaping business logic flaw about a failed authorization flaw where a user would get to play admin with the application and they try to find explanations which are on the lines of "but the user would not be able to do much even if he/she became admin" or "I think this was an intentional feature that we had in case this eventuality." Earlier, I used to have a small explosion in my head, but yoga has taught me to react like Mr. Wolf from Pulp Fiction "I am here to help, if my help's not appreciated, tough luck gentlemen"

No comments:

Disclaimer

The views presented in this blog are entirely mine and are not those of my company.

© Abhay Bhargav 2010