For the most part, I agree with Matt. Most of what's below should be intuitively obvious to the most casual observer, but..
Using your cheat-sheet idea, lots of classes have "open book" tests. While you don't want this info in the hands of an attacker, it really shouldn't matter that much if it gets out. Having the book is not that much help if you don't know how to find the right answers in it. The testers still need to find an exploit to make use of the data you provided. You indicate your company is paying for this. One thing to consider is what do you want them spending their time doing? They charge by the job, but there is a "per-hour" expectation hidden in there someplace. Spending time finding the "obvious" isn't really cost effective. If you know they are going to find it, hand it over. You also want them to get/find ALL of your exposed/public systems, not just the ones they came across in discovery. While they could do an external NMap/Masscan sweep, doing so may trigger various IDS systems you have in place skewing their results. A good tester would see this, but not all of them will. It also depends on how many systems did get scanned before the block and how many may be left to tell if it's worth continuing. Having you unblock so they can rescan takes time/effort. It's good to show they were detected, but then move on. Note the super low/slow attacker may not be detected/blocked. Test teams have limited amounts of time to get the job done. There are 2 major types of "pen tests" or "audits" or ... One is considered the "Red-Team" event. This is when the testers are coming at you with no starting information. This can actually be a good thing to commission as well. It's amazing how much they can learn about your company with only a name and address to start with. With any luck, these teams are going to find very little and or set off all your IDS/IPS alerts in the process. They may get far into your systems, if they are stealthy enough and have a long term strategy for "attack". The "Blue-Team" style events are where the tester is working WITH internal people to see what they can do. Yes, the system is skewed in favor of finding the bad stuff, but wouldn't you rather have them find it than some script kiddie over seas? These tests tend to bring forth the real problems you need to deal with. Consider what the real attackers may do.. We have seen where hackers will get come foot-hold into a site. Nothing major, but a starting point. Lots of very slow exploration can take place from that initial intrusion. If done properly, they can probably drop a couple of additional back doors on related desktops in case 1 is discovered. Now after days/weeks/months of slow dig, they have mapped out your world as seen from those desktops. Every now and then, increase the web of infected machines into new areas. Over time they probably have most if not all of your network map. At least enough of the functional components so they know where to target specific attacks. Get in quick, gather data, get out. Hopefully don't get caught. If they do chances are they still have the other infected desktops. Maybe you'll notice. It may also be the case that these attackers are waiting for the next big undetectable 0day to burst from their safe little foothold. Now ask yourself the goal of the testing. Is it to make your team look good by the test team not finding anything significant, or do you want to find/fix security vulnerbilities before it becomes a problem. A fresh set of eyes on your infrastructure is a good thing. Chances are the test team has ways of thinking about your configuration and how to exploit it that you never even considered. In most cases they didn't create those exploit methods, but learned about them through investigating real attacks. Be nice to the test crew. If they are doing any of this on-site, provide them snacks, dew, energy-bars, fresh fruit, ... Make friends. In most cases they will tell you what they are doing and why. Chances are if you have an issue you think needs some additional attention, let them know. While they may not "discover" it or have considerable evidence to back it up. they can probably drop a recommendation into the report that they think some addtional effort could be applied to improving _____. Instead of thinking of them as the enemy, make them a tool in your arsenal to get things done. Isn't that your goal? Pass the tests with a set of recommendations for improvements that mimics what you've been telling mgmt for years? Treat the test crew like crap. Make it hard to do their job. All you'll get out of it is the report, and it probably won't be good. --Gene Matt Disney made the following keystrokes: >I've had different experiences than Yves. I've never had that info used >against me in that way exactly (but more on this below). Here's my two cents. > >It isn't uncommon for pen testers to ask for this info. If you really want to >maximize the experience of having someone tell you what your weaknesses are, >there's no good reason not to give them this. > >However, pen testers can do a blind test, where you don't give them any info. >This is also testing you but is more of an evaluation of the tester as well. >That evaluation can indeed be valuable in interpreting the results, but not >necessarily. > >Yves' point about having info used against you is valid, though. If this is >something you are commissioning to help you be better, I recommend sharing >the info. How ever, if this is commissioned by someone else and will be an >error-prone and misconstrued assessment/audit used as a hammer, consider >asking for a blind test to level the playing field. > >Matt > >> On Jun 9, 2014, at 18:58, Yves Dorfsman <[email protected]> wrote: >> >>> On 2014-06-09 16:50, Evan Pettrey wrote: >>> My company is currently in the process of obtaining a pentester to test >>> security on our systems and one that a colleague of mine has recommended >>> has >>> asked us for the below information: >>> >>> * Public IPs >>> * Public DNS records >>> * Network map of full infrastructure >>> >>> >>> To me this seems like sitting to take a test and having a cheatsheet. The >>> IPs >>> and DNS records should be easy enough to figure out on their own and the >>> network map I don't believe should be provided. >>> >>> >>> Am I just being too skeptical here or does this seem like inappropriate >>> questions to ask as a security auditors? >> >> >> No, you're not. This is a classic, they ask you for as much details as >> possible that might not look too suspicious, then highlight the fact you >> gave so much detai > ls to a stranger as a security issue (which it would be). >> >> >> -- >> Yves. >> _______________________________________________ >> Discuss mailing list >> [email protected] >> https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss >> This list provided by the League of Professional System Administrators >> http://lopsa.org/ >_______________________________________________ >Discuss mailing list >[email protected] >https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss >This list provided by the League of Professional System Administrators > http://lopsa.org/ _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
