Penetration Testing for Low Hanging Fruit - Part 7 of 7

Monday, November 08, 2010

Bryan Miller

F8f122d50eba11c3af5607575b277bc6

Do It Yourself or Outsource? - Part 7 of a 7-part series - (Part 1 Here) (Part 2 Here) (Part 3 Here) (Part 4 Here) (Part 5 Here) (Part 6 Here)

It is my hope that this series of articles have successfully made the case for performing regularly scheduled penetration tests. 

When combined with enforceable policies and procedures such tests can be an invaluable asset to any organization. 

The question of "enforceable" is usually illustrated by an organizations password policy.  The security officer might write a policy indicating a minimum password length of 8 characters. 

However, the employees might complain that the password is too long and hard to remember. Ultimately the password policy is changed to something smaller, say 5 characters. 

This effectively reduces the overall security and privacy benefits of having strong password policies.

One caution regarding penetration testing is to remember that penetration testing is not a magic bullet. It will not detect all problems in your networks and applications, especially when it involves custom code. 

By searching for and finding the LHF in your organization, you are taking a major step in securing the information that gives value to your company. 

From a privacy perspective, removing the LHF is one component of ensuring that sensitive data is not available by unauthorized users. 

Increasing the overall security posture by eliminating LHF will provide management with confidence that their privacy concerns are being addressed and will help reinforce the notion that security and privacy are inextricably intertwined. 

Regardless of how and when penetration testing is performed, none of the tests will be beneficial if the proper remediation steps are not completed.

Remember the goal is not just to fix what is broken but rather to incorporate the findings into long-term policies and procedures that will help to ensure that the issues found will not be recreated at some point in the future. 

Business owners do not want to pay for annual tests and continue to find the same issues year after year. Take the results of the tests and use them to refine your IT practices so that each year the list of vulnerabilities continues to decrease. 

You may never see that list reduced to zero but the real business value comes from the pursuit.

References

[1] http://en.wikipedia.org/wiki/Penetration testing

[2] Kevin Beaver, "Outsourcing security testing: What's right for you?", October 2004.http://searchcio-midmarket.techtarget.com/news/column/0,294698,sid183_gci1018599,00.html#

[3] http://en.wikipedia.org/wiki/Tiger_team

[4] PCI DSS Standards - https://www.pcisecuritystandards.org/

[5] Roger Irvin, "What is FUD?", 1998.  http://www.cavcomp.demon.co.uk/halloween/fuddef.html

[6] Stuart McClure, Joel Scambray, George Kurtz, "Hacking Exposed: Fifth Edition", McGraw Hill, 2005.

[7] ISECOM: http://www.isecom.org/

[8] SANS:  www.sans.org

[9] Foundstone:  http://www.foundstone.com/us/education-overview.asp

[10] http://dev.mysql.com/doc/refman/5.0/en/default-privileges.html

[11] http://support.microsoft.com/kb/313418

[12] http://download.oracle.com/docs/cd/B10501_01/win.920/a95490/username.htm

[13] http://www.securiteam.com/securityreviews/5DP0N1P76E.html

BRYAN MILLER has over 25 years of Information Technology experience. His education includes a B.S. in Information Systems and a M.S. in Computer Science from Virginia Commonwealth University (VCU) in Richmond, VA.  Industry certifications include the Cisco CCIE in Routing/Switching and the ISC CISSP. In August of 2007, Bryan founded Syrinx Technologies.  Email:  bryan@syrinxtech.com

Possibly Related Articles:
9250
Passwords Application Security Pen Testing Penetration Testing
Post Rating I Like this!
Default-avatar
James Lay An entirely useless series...merely talking about pen test and showing no actual pentest methods.
1289318418
6d117b57d55f63febe392e40a478011f
Anthony M. Freed James - The series was aimed at the non-technical folks who generally do not understand anything about the value of the pentest process as a security strategy, and was not meant to be a "how-to" on penetration testing. It is important to translate the high level technical aspects of sound security processes for the MBA-bred CxO class who are the primary budget setters, and this series did a fine job of explaining the value of penetration testing to that audience. I invite you to complete your member profile by uploading a picture and then submitting an article or series of your own that explores methodologies involved in the pentest process. Please contact me when you are ready to publish, and I will get you set up. We are all looking forward to an exposition of your expertise!
1289320731
F8f122d50eba11c3af5607575b277bc6
Bryan Miller James, while I appreciate all comments, I wish you had read the first couple of paragraphs of Part 1 before commenting. I never intended this to be a "how-to" hack series. There are thousands of articles, books, classes, etc. on how to do that. My intent, as Anthony restated, was to present a business case as to "why" an organization should perform pen testing. Once that decision is made, the next usual decision is DIY or outsource.
1289320942
E68c72e1e8be98215f1fa5155236f5c6
Anthonie Ruighaver While I agree with the need to find Low Hanging Fruit (LHF), I still don't like to use the term penetration testing. To find LHF you need a systematic process and that process should normally be part of an audit. In penetration testing you concentrate on removing the LHF and you end up in a costly continuing cycle of finding more difficult to find LHF and removing it. In an audit, you don't need to "hack" in general and you'll start concentrating on why that LHF is there. Removing the cause of LHF instead of LHF itself, is the way to a cost-effective information security approach.
1289348686
4072c1d979190d2cd781f241908d3a73
Anthony Wrather Personally I found the article very interesting as I often encounter resistance to security, functional, and load testing which I can never quite understand the rational behind.
However this article never tried to be a howto Pen Test guide and did clearly state so and even the basic courses tend to be a 5+ days.
I often encounter excuses like the sever is to unstable test (one of my favourites) … To unstable to test but that’s good enough to run a critical part of your department or business …
The title of the testing is almost an irrelevance, call it Pen , Load, Stress, Functional , Coverage, FAT, or SAT tests if there are basic errors in the system it represents a hazard to your department or business and sticking your head in the sand will not serve you well in the long run.
The only question is who is going to crash or compromise your systems first … Someone like me who will tell you about it … Or someone like “them” who will profit from your misfortune …
1289397085
F8f122d50eba11c3af5607575b277bc6
Bryan Miller Anthonie, I agree that audits have their place but they certainly aren't the only answer. Audits are great for finding out how the clients "say" the environment works, but only a true, hands-on test will validate the results. For example, I have performed audits where the client claims their password policy is "X, Y, Z". Sounds good on the surface, but after dumping the password hashes and running them through ophcrack, I can show the admin where 10% of the accounts fail their own policy.

Your comment on the LHF testing doesn't remove the core problem is true when you don't perform a thorough test and provide useful recommendations. My goal when testing my client's networks is to provide a list of what's wrong and how to fix it. That includes more than just "put patch A on server B". It's often a discussion of more advanced controls including IDS/IPS, NAC, 802.1x, encryption, etc. Firms that only run Nessus and give a report would fall into your LHF trap, not quality firms intent on truly helping the client improve their overall security posture.
1289399078
F8f122d50eba11c3af5607575b277bc6
Bryan Miller Anthony, I love hearing those reasons. I often hear some of the following:

1. Our employees aren't that smart.
2. We don't have anything that anyone would want.
3. If you tell us what's wrong, we'll have to fix it.

Really?
1289399133
E68c72e1e8be98215f1fa5155236f5c6
Anthonie Ruighaver Hi, Bryan. I meant to say that when I started in security 15 years ago, audits did include a systematic evaluation of security to find LHF. Nowadays, a lot of that has disappeared from audits and moved into "pen testing". For me pen testing still has the negative connotation that it is about penetration, not about a systematic evaluation. For instance, for me a security audit should also include proactive forensics.

Another issues is that security is not only about prevention, so if a pen test is detected that might mean your security is OK, even though penetration has been achieved..
1289439794
4072c1d979190d2cd781f241908d3a73
Anthony Wrather I very much agree that any form of testing should be systematic, repeatable, clearly defined, well documented, and come with clear, cost effective options to mitigate the risk in the short term and to resolve the issue in the long run. I will also try to engage the local sysadmin's so that once the solution is applied they can rerun the tests to ensure the issue is actually resolved and that later patches (or restored backups) do not cause a regression. It also has the added benefit that the "stock" tests can be rerun by the local staff and the offer of leaving the "Pen Testing" procedure can often get the local sysadmin's to buy into the process and solution.
Security is everyones concern every day of the week.
In the final analysis no amount of security on your front door will do any good if you leave the back door unlocked.
1289442585
F8f122d50eba11c3af5607575b277bc6
Bryan Miller Anthonie and Anthony, you both make great points. I actually don't like the term "pen testing" much myself either. I'm not crazy about "vulnerability assessment" either. I have never agreed with the limitation of pen testing is to find only 1 way in to the client networks. I believe in trying to find as many as possible given the obvious time constraints. I never look at it as simply "can I break in", but more like "how many ways can I find". This way I try and close as many holes as possible and most importantly, create additional P&P's, technical controls, training, etc. to make sure that same problem isn't repeated.
1289452368
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.