Image
 
linkedin_logo.png rss_logo.jpg
twitter_logo.png youtube_logo.jpg
Latest Additions
 
EH-Net Login
Welcome Guest.






Lost Password?
No account yet? Register
Who's Online
We have 83 guests and 3 members online
EH-Net News Feeds
Latest Additions
 
Advertisement

You are here: Home arrow Forum arrow Ethical Hacking Discussions and Related Certificationsarrow Network Pen Testingarrow Problematic Pen Testing situation
EH-Net
May 26, 2012, 07:20:22 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Advertise on EH-Net!! - Reasonable Rates, Highly Targeted Audience.
 
   Home   Help Calendar Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: Problematic Pen Testing situation  (Read 2782 times)
0 Members and 1 Guest are viewing this topic.
l33t5h@rk
Guest
« on: October 03, 2011, 12:03:57 PM »

I'm in a bit of a conundrum at work and have a question I'm just looking for ideas for. We have a large prospective client who wants to do a 3rd party pen test (on an agreed upon vendor) for two of our applications. Currently, we do vuln. scans and server/network scans on a scheduled basis so I have a good amount of info on the apps from those standpoints. Over the summer, I did an enterprise scale implementation of a static source code tool and have the results for all of the apps in question. One of the apps is fine, but the other is a complete f-ing disaster and has upward of 100 high risk (not severe like sql injections but null dereference, unreleased resources, race conditions, etc). The main issue is that the wording in the contract is that there is a hard timeframe they expect anything from the pentest to be corrected by, and it's like NFW the developers can fix these issues on that quick of a requirement. Any thoughts from the community? Do I just throw myself in front of it and try to delay? Planking on the CIO's desk?
Logged
ziggy_567
Sr. Member
****
Offline Offline

Posts: 302


View Profile
« Reply #1 on: October 03, 2011, 12:15:16 PM »

Forgive me for being blunt or ignorant if I'm missing something...

But as a penetration tester, your role is not to make those decisions. Your role is to find the vulnerabilities, try to exploit them, and report them. This is your role, so that the person paid to make the decisions has all the necessary information to make a well-informed decision that will benefit the company and its investors.

Period.
Logged

--
Ziggy


GSEC - GCIH - GCUX - RHCE - SCSecA - Security+ - Network+
hayabusa
Hero Member
*****
Offline Offline

Posts: 1304



View Profile
« Reply #2 on: October 03, 2011, 03:04:48 PM »

++1 @ziggy_567's reply
Logged

~ hayabusa ~ 

"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." - Sun Tzu, 'The Art of War'


OSCP , GPEN, C|EH
cd1zz
Sr. Member
****
Offline Offline

Posts: 393


View Profile WWW
« Reply #3 on: October 03, 2011, 03:18:47 PM »

I think he's saying they are contracting out the pentest and they're not doing it internally, right l33t?

If this is the case and you think there are issues with the contract, you just need to try and communicate your concerns. I don't know your role in the company but try not to sound like you're panicking or that that sky is falling. Use real data like, "remember when we had xyz problem and it took 6 months to fix? Well, we think there might be 100 of these vulnerabilities so the pentesting companies contract seems a little unrealistic."

Management will hopefully make decisions on real data or projected data, not just sheer emotions Wink

Stay professional and communicate clearly, that is the only way they'll listen to you. If this doesn't work, plank the CIO's desk and then go right into a batman on his credenza.

Logged

hayabusa
Hero Member
*****
Offline Offline

Posts: 1304



View Profile
« Reply #4 on: October 03, 2011, 03:34:42 PM »

I agree...  I guess what I meant with the "++1" was more along the line of, if you have a job to do, whether as a contracted pentester or as an internal auditor, you still should report what you're aware of, up the chain, to get it resolved.  You still have a responsibility to communicate what you're aware of, upstream, to try to protect your services / offerings, and your customers.

Period.

So ++1 to both.
Logged

~ hayabusa ~ 

"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." - Sun Tzu, 'The Art of War'


OSCP , GPEN, C|EH
l33t5h@rk
Guest
« Reply #5 on: October 04, 2011, 08:48:22 AM »

Thanks everyone for the responses. I should have been a bit more clear. I will not be performing the pentest - I am in charge of the app security functions (static source code analysis, vuln scans). Granted, I was a little frustrated when I threw this up yesterday so I'll be more precise. The client is looking to contract out a 3rd party pentester. We don't do this, we have our own. As with most management, I've been brought into the process late, and am now trying to tell them I know waaay too much about some of our coding issues to sign up for this. It's not the pentest I'm worried about, it's the expectation that findings (which will be tested by secondary pentest) will all be resolved in a 60 day window. I'm just looking if anyone has been in a similar situation and ultimately what some good options are.
Logged
cd1zz
Sr. Member
****
Offline Offline

Posts: 393


View Profile WWW
« Reply #6 on: October 04, 2011, 08:53:17 AM »

That's what I figured the situation was.

It's ultimately a matter of time and resources. If the time window is small, they're going to have to hire people to help you hit that deadline. If not, you'll miss it.

If this is the case, refer to my previous post on communicating your concerns clearly to management. Just make sure you CYA so that it they cant say you didn't speak up later.
Logged

Solinus
Newbie
*
Offline Offline

Posts: 31


View Profile
« Reply #7 on: October 04, 2011, 09:40:52 AM »

I have to agree with a lot of what has been said here. It is tough to go before someone with the knowledge that you have. It seems that no matter how you approach it, the messenger gets shot. Are you certain that all the findings are high risk? Can some be explained as acceptable because of business practices? I have seen so many instances where things marked as high risk really are not, and the opposite as well.
Make sure that there is a valid solution for the risks and present that. The best advice is to have all your data in presentable format before you get called on the carpet.
There may have been mitigating circumstances to some of these findings and you need to look back and thouroughly search them out. Be sure not to blame others for the circumstances because that never looks good, but also, don't volunteer to fall on the sword. It is your career that you need to have in mind. Management does not always understand that your being honest is critical to what you do.

Be prepared that they will most likely not like what you say and that you need to be sure of yourself when facing them.

If there are as many findings as you claim, then sixty days is an impossible target unless they are willing to supplement the team with outside assistance.


Let us know how it turns out.
Logged

Kerry
MCITP:EA | MCTS(x5) | MCSA+ | MCSE+ | Security + | CCNA | WCSP |
DSCE | PCT |CIW Security Analyst | CSSA
l33t5h@rk
Guest
« Reply #8 on: October 04, 2011, 09:51:32 AM »

Thanks again for the responses.

Yes, there are some issues marked as high risk can be explained away, I think I have a grasp on these talking points.

However, some of the issues (hard-coded pw ... FTW!) and a few dashes of CSRF/XSS it's like come on dudes we have way too much sec tools in place (and training) to be in these spots. Meeting is Thursday so messages going out then. If you don't hear from me after, tell wife/kids I loved them.
Logged
alucian
Full Member
***
Offline Offline

Posts: 190



View Profile
« Reply #9 on: October 04, 2011, 02:20:50 PM »

I understand your feelings. Try not to blame anybody, after all is the management's fault and you cannot blame them.
Through them the ball and let them play. Make sure you stay away.

This is one of those moments when you think is better to be a truck driver, you are responsible for your own faults only Smiley
Logged

CISSP ISSAP, CISM/A, GWAPT, eCPPT, OSWP
l33t5h@rk
Jr. Member
**
Offline Offline

Posts: 79



View Profile WWW
« Reply #10 on: December 01, 2011, 10:33:30 PM »

This issue was finally resolved for anyone interested or not interested.

We ended up working w/ the client and mapped out a plan w/ similar objectives from our preferred pen test contractor and the client accepted this. The test completed today and surprisingly, no high or urgent vulnerabilities were found. I guess my paranoia probably got to me on this one, but at the end of the day, we found no issues, and this particular problem was what caused me to seek out advice from the crew at ethicalhacker.net and become a registered user. Thanks to everyone for commentary and input, it's a wonderful site.
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines
Joomla Bridge by JoomlaHacks.com
Valid XHTML 1.0! Valid CSS!
Page created in 0.147 seconds with 22 queries.
 

gk_static-ad_feb2012.jpg
Global Knowledge: Build Security Skills to Protect & Defend

els_130x200fixed2.gif
eLearnSecurity Student Course Now Live!
5% Off with Code
ELS-EH-5

SANS Deals 4 EH-Netters
$150 OFF Any SANS Course in Any Format!
Coupon Code: EHN_Connect Including SANS Security West 2012 & SANSFIRE 2012
Recent Forum Topics

cbtnuggets_logo_125.jpg
Try CBT Nuggets Free!

Vote For EH-Net

Add to Technorati Favorites
technorati fave

 
         
Advertisement

© 2012 The Ethical Hacker Network
Joomla! is Free Software released under the GNU/GPL License.