On Sat, 30 Aug 1997, Frank Willoughby wrote:
> >But it is possible to minimize the hazard as
> >identified by you.
>
> You're right, it is possible to minimize the hazard. But so far,
> I haven't seen a solution which is secure enough for me and is
> less expensive (time, money, manpower) than doing it locally.
Secure tunnel to the DMZ of the tested network.
ObRussCooper: Microsoft's PPTP could do this with NT Server.
Most two node VPN software solutions are pretty cheap actually. Even if
you buy the RSA stuff, you're talking less than travel, room, and board.
> If all IP addresses belong to the same entity, (ie - your company)
> then nothing is really gained. One attacker may be monitoring one
> IP address range, another might be monitoring another address range.
> As the bad guys know who the good guys are, we have to assume that
> they are monitoring our network traffic and take appropriate precautions.
>
> If all of the IP addresses are at the same ISP, the process is even
> easier for the attackers.
That's assuming that the ISP is small enough, or the levels of traffic
from the ISP small enough that the traffic is statisticly significant.
Unless you're looking to test flood protection, you can do a heck of a
lot with dial-up ISDN or post-CIDR provider netblocks which don't get
registered to you.
> Even if attackers aren't set up at the ISPs your company is using,
> they might have cracked the customer's local ISP and set up a sniffer.
If that's the case, they'll probably get enough information to mount a
Net or non-Net based attack *anyway*. Your local testing won't find
that, and won't stop it from happening.
> The sniffer will probably be set to trigger on certain strings (password),
> or signatures (test signature of common commercial & attacker security
> scanners). They may also be using a scanner detector. The attackers
> don't even need to have the results in real time. They just need to
> check the results frequently enough to take advantage of the window
> of vulnerability & take out the system before the vulnerabilities are
> corrected.
That would be real-time, unless you're not watching the scanner results
in real-time. Then there's the fact that if they've gone to all that
trouble, not shutting down the scanner in real-time gives them the same
vulnerability asessment that the scanning firm has, I'm not sure that's
as bad as you'd make it seem, since we'd trust our scanning firm to get
us that report (out of band) as soon as they found a vulnerability.
> >I am lucky that I work for a company with world-wide presence, so
> >I am able to use several company-owned hops before I got to the
> >client to be tested (sometimes using encrypted and authenticated
> >tunnels... another reason for not doing automatically testing :-)).
> >The attacker then has to follow the track, but probaly isn't able to
> >recognize a test in progress at all.
>
> I disagree. If the attackers have taken out the ISP, they may have
> uploaded scanner detectors and are using them (it would sure make
> the sifting process easier).
But if, as asserted, the packets are encrypted, then (a) they can't forge
false returns without alerting the scanners, and (b) they can't know what is
going on. Not that they'll automatically jump to the good guy conclusion
anyway necessarily. There's more bad guys out there than good guys doing
penetration tests.
> >> PS - We offer a vendor-neutral Firewall Evaluation/Penetration Test
> >> Service in which subject the firewall to over 400 tough security
> >> tests (manual & automated). This helps to ensure that the firewall
> >> is robust enough to meet the security challenges posed by connecting
> >> a company to the Internet.
A firewall is *never* robust enough to meet the security challenges posed
by connecting a company to the Internet, limit, yes, meet, no. IP over
SMTP, Reverse Telnet over ICMP, http to a command CGI, there are a million
ways in and out of a "protected" network, most of which can be made fairly
indistinguishable from "real" network traffic.
> >I prefer to do the testing locally as well. Another advantage is that you
> >can create greater loads on the firewall than in the real (Internet)
> >world. So you you can indeed test the robustness of the firewall better.
>
> Excellent point.
And mostly moot, the majority of connections are small enough that they
can be flooded further back in the path, smurf.c is a prime example of
that working at provider's peering routers even.
> It's slightly more expensive than doing it remotely, but the
> customers should not be penny-wise & pound-foolish. They may
> end up putting their company at risk in order to save $1-2K USD.
If what you're saying is true, then the company is _already_ under
attack, so then they are possibly changing the chance of detecting an
attack vector, but they are not adding more risk to their scenerio. It's
already raining, forecasting humidity is moot.
> If the decision to do remote testing is an internal management
> decision, I would recommend escalating the issue and letting
> them be aware that the quality of the work, which is being
> performed by professionals such as yourself, is being put at
> risk (as is the company's reputation if something goes wrong).
> IMHO, it is simply not worth the risk.
And that management would probably argue that if the consultant can't solve
the problem of remote testing securely, then they're probably not as good
at security as they claim to be. YMMV.
>
> If the choice is the customer's, then I would point out to the
> customer, the risks of remote security testing. Let them see
> the wisdom in spending the extra $1-2K USD to have quality work
I'd rather spend that once to do a secure tunnel than every time I wanted
an external security audit.
> performed which won't put their company at risk. I would definitely
> try to make this point to the CFO. As the CFO's job is to manage
You'd be surprised how many times you wouldn't get to the CFO, ours sure
as heck wouldn't go against his CIO's recommendation without something
more firm than "quality, a little more, and may put at risk".
> >Another issue is the greater control you have when testing locally. You
> >can have feedback from the firewall immediately and react to that. In the
> >end it turns out to be much more efficient, more thorough and cheaper.
While there are some good reasons for local testing, I don't for a minute
belive that remote testing is automatically invalid, and that it can't be
done correctly. In my worldview, anyone who tells me there's only one
solution to my problem is too short-sighted to deal with on a long-term
basis. If I were shopping for external audit testing, I'd be looking for
someone who would be looking long-term, and I've been in this field long
enough to know that there's _always_ more than one way to do anything,
even when I can't see it myself.
On-site gives you physical access, and if I'm not auditing physical
access, then I may require that you do the penetration testing remotely.
I have to balance letting you on-site with my trust of you and your company.
It is getting harder to tell the bad guys from the good guys, and I might not
like the idea of finding out the hard way who's who.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts @
clark .
net which may have no basis whatsoever in fact."
PSB#9280
Follow-Ups:
References:
|
|
