Re: Scanning through an IPS

["Andre Gironda" <andreg () gmail com>]

On Wed, Sep 24, 2008 at 10:43 AM, Matt - MRS Security
<matt () mrssecurity com> wrote:
> What are your thoughts on the above? Your saying don't do it... But
> why?
>
> Would it not be more cost effective for the merchant to have his full range
> tested? instead of maybe 2 ports? (SMTP/WWW)

PCI-DSS doesn't specify costs.  I don't think that I understand this question.

All PCI-DSS 11.2 and 11.3.1 network penetration testing includes every
device (network functions and operating systems), which means every
protocol in use (especially IPv4), each individual IP protocol, every
ICMP type code, and every TCP and UDP port from 0 to 65535.  The
OSSTMM 3.0 Lite methodology that I referenced specifies these in
further detail.  According to Chris McNab's Sentinel Test (as
presented at OWASP NYNJMetro in March, 2008), 2 out of 10 vendors
failed to perform a full port scan of all 65536 ports.  Of course, he
also found that manual assessments score way higher than automated
assessments.

What I'm saying (to get back to the main point) is that external
network penetration tests shouldn't be fully external.  I'm also of
the opinion that network penetration-testing is an unsafe practice,
and I'm not just talking about the use of cleartext testing over the
Internet.

I'm a fan of the local, non-listening agent approach.  In other words,
you run nessud on every operating system for every
server/desktop/laptop in the PCI-DSS scope (i.e. wherever card data is
held or travels across).  nessud never listens on a port.  In a secure
manner, you collect/send the data using standard nessus means (but
wrapped in stunnel or a similar qualified SSL wrapper) to a central,
secure location where it can be processed into reports.

This way there is no cleartext scanning or penetration-testing
information on any channel, exposed to possible listeners, sniffers,
MITM, or other internal/insider exposures - let alone from the
Internet.  To those without the proper infrastructure, deployment of
this strategy could be considered less cost-effective than a network
"scan" cleartext based approach.  This is also somewhat of a
compensating control since it doesn't meet the direct requirements of
the paper compliance criteria.

In a similar way, I find it hard to support application
penetration-testing as specified in 11.3.2 that takes place over a
cleartext wire.  It's one thing if you're testing over SSL to a secure
web application.  However, application penetration-testing is done
best with manual source code review with all of the artifacts present,
including a proper build and operational environment installation plan
(i.e. install War file into Tomcat version X.X with configuration diff
of XYZ, running on RedHat Enterprise Server version X.X with startup
configurations diff of XYZ, et al).  This way the installation
experience can be replicated in a lab exactly, and DevInpsect or
AppScan DE can provide hybrid/composite analysis to aid the manual
source code review process.

We should think about how safe our penetration-testing is, and realize
that the testing process itself could be easily subverted by
intelligent adversaries.

Cheers,
Andre

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Top 5 Common Mistakes in 
Securing Web Applications
Get 45 Min Video and PPT Slides

www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------