firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: PCI DSS & Firewalls (lordchariot@embarqmail.com)
2. Re: PCI DSS & Firewalls (Victor Williams)
3. Re: PCI DSS & Firewalls (Chris Blask)
4. Re: PCI DSS & Firewalls (Chris Blask)
5. Re: PCI DSS & Firewalls (Marcus J. Ranum)
6. Re: PCI DSS & Firewalls (Paul D. Robertson)
7. Re: PCI DSS & Firewalls (Jim Seymour)
----------------------------------------------------------------------
Message: 1
Date: Thu, 2 Apr 2009 17:38:30 -0400
From: <lordchariot@embarqmail.com>
Subject: Re: [fw-wiz] PCI DSS & Firewalls
To: "'Firewall Wizards Security Mailing List'"
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <000301c9b3db$5e29d7a0$1a7d86e0$@com>
Content-Type: text/plain; charset="us-ascii"
> 5.1.1 Ensure that all anti-virus programs are capable of detecting,
> removing and protecting against all known types of malicious software.
>
> [Honestly? All TYPES? Every time?]
Hmm, all known types...
I'm really surprised it doesn't say all UN-known types, too. That's where
the risk really is.
...of malicious software.
Is the exploitable application the offender or the data that tries to get in
and trigger the exploit? Which one do I delete or protect against? The
programs that read the PDF or the PDF itself?
------------------------------
Message: 2
Date: Thu, 02 Apr 2009 19:34:20 -0500
From: Victor Williams <bwilliam13@windstream.net>
Subject: Re: [fw-wiz] PCI DSS & Firewalls
To: mjr@ranum.com
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <49D5598C.3010408@windstream.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Marcus J. Ranum wrote:
> Victor Williams wrote:
>> PCI DSS is pretty sad. They could have taken another
>> already-established standard with some brains behind it and adopted
>> it instead...
>
>
> What makes you think they didn't?
>
> mjr.
Good question. Have you read it? I'll defer to what Paul already
stated, and some of the outtakes of the standard that he posted.
I will 2nd the notion that the only thing it is doing is making a lot of
other people (QSA's included in that bunch) a lot of money. When the CC
processors themselves aren't even following the PCI "standard"...
True story...
I was told by qualified PCI external scanner companyA 3 weeks ago that a
part of our web app needed to change because their scanner tool detected
a "possible" vulnerability. Upon 2 weeks of code review of this
particular app, it was proven out that what the scanner was "possibly"
detecting was in fact a false positive. The code and the design behind
it was solid. The funny thing about the issue is that the app in
question was considered non-production, and had no exposure whatsoever
to credit card information. None. However, it had to be scanned
because the IP address in question belonged to the same block that was
being used for production apps--something if you ask 3 QSA's, they will
all give you different answers on. The production system had the EXACT
same code, was scanned by the same external scanner, and was never
flagged. Now, were we able to send our findings/exception to the
scanner and have them negate the failing score? Nope. It doesn't work
that way. You have to remove the "possibly" offending code,
regardless. There is no review process. Why is this important?
Because your acquiring bank will be sent your failing score if you fail
to fix it within X amount of time. At that point, they will then do one
of a few things; have you bring in a QSA to do an audit and make you
remediate any issues, or if you put it off/refuse, have you stop taking
credit cards as payment...or just freeze your accounts so you "can't" do
any business with credit cards. Either way, you're out money...because
your 3rd-party scanner couldn't tell bad source code / bad behavior from
good, or false positives from actual positives--keep in mind you're
still paying them too. So what's the workaround? Schedule your re-scan
for after-hours, put up a dummy site instead on the same IP address, let
the scan run and let it pass, put your original site back up. You
pass...you're green across the board again. Seem like a solid process?
It's worthless. That's only a subset of the "standard."
If you're (your company as well) actually concerned about security, you
won't waste your time with PCI or even reading it. If an exec asks you
"are we PCI compliant?", the only thing you should tell him is, "Hire
companyX and have them come and tell us." Someone already commented
about good design and coding, and good QA before deploying being the
best/easiest way to make sure you're not prematurely vulnerable, and
following best-practices thereafter for your implementation of X.
Assuming you do that, PCI is nothing but a distraction, and is indeed a
bunch of checkboxes. The QSA's I've encountered don't want to hear
about your exceptions, or don't have enough knowledge to tell you if
they are good or bad judging by your business and the processes it requires.
------------------------------
Message: 3
Date: Thu, 2 Apr 2009 19:56:49 -0700 (PDT)
From: Chris Blask <chris@blask.org>
Subject: Re: [fw-wiz] PCI DSS & Firewalls
To: mjr@ranum.com, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <322231.33461.qm@web33806.mail.mud.yahoo.com>
Content-Type: text/plain; charset=us-ascii
From: Marcus J. Ranum <mjr@ranum.com>, Thursday, April 2, 2009 2:17:10 PM
>Chris Blask wrote:
>> having more Pen Testing done in the world is itself a move in a positive direction, so that's a good thing by any metric.
> I disagree.
Now, how did I know you might?
> What does pen testing show?? Pen testing can show one of two things:
> - your security sucks
> - your security is better than your pen tester
> Neither of those two determinations are equal to "your security is
> good."
Well, this brings us back around to the age-old debate. Namely: "Can we start over or do we make the best of the sow's ear that we have?" As you know I'm not big on holding out hope for starting over, and I'm not so sure that if we did we'd avoid the 'Ah Ha!" moments which always crop up halfway into any huge projects and thoroughly shoot the idea of a Pure Implementation in the foot anyway.
But since we aren't going to rebuild the whole thing - or even a single business network - we do with what we have. And in that case, pointing out some of the ways your security sucks - and showing you how to fix those - is statistically a step in the right direction. Maybe you won't be the one to get compromised - maybe they'll get the next guy who didn't even try to secure his system - and maybe you'll start taking security more seriously as you continue to build out your business systems.
I'm much more an advocate of paying attention to what the hell is going on with your network then simply doing testing to find the weaknesses, but both fall into the realm of tuning and operating what you have as well as it can be managed.
.d.
> a root cause and it's that "your managers are stupid" or "your
> executive management is clueless" or both. Those are not especially
> popular results but we both know of infinite numbers of stories of
> executives who didn't take security seriously until some pen
> test rubbed their nose in it. Pen testing may be a short-term
> cure for stupid, but it's a fairly expensive way of doing
> it and I doubt that it works particularly well in the long-term.
It's not our jobs to cure stupid, it's to make systems more secure, whatever the situation on the ground happens to be. As in the case where you buy more or less insurance, whether or not you have been smart or stupid will not be resolved until the risk the insurance covers does or does not occur. We're just here to sell and install the risk mitigation that we can help you understand and that you choose to pay for.
.d.
> So, generally I disagree with you, Chris. I think pen testing
> serves as an indicator of stupid more than anything else.
> Don't be confused by the fact that the indicator is in the
> red zone; it doesn't mean what you think it does.
I know you do, it's one of your more enduring characteristics. :~)
-cheers!
-chris
------------------------------
Message: 4
Date: Thu, 2 Apr 2009 20:18:25 -0700 (PDT)
From: Chris Blask <chris@blask.org>
Subject: Re: [fw-wiz] PCI DSS & Firewalls
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <949397.72658.qm@web33806.mail.mud.yahoo.com>
Content-Type: text/plain; charset=us-ascii
From: Paul D. Robertson <paul@compuwar.net>
> On Thu, 2 Apr 2009, Potter, Albert (Al) wrote:
>> Chris hits the nail on the head.
Perhaps the most intelligent comment in recent decades... ;~)
.d.
> No- the fine is what does that, the DSS is just the artifact with which to
> do it. However as a "Standard" it's worse than ICSA Firewall testing
> criteria! ;-P
Now, Al's being nice to me, how can I respond to that? Keep walking, nothing to see here!
>> Is it perfect? No, but it is regularly revised (the DSS) and has a
>> mechanism to get better.
> Not only is it not perfect, it's frankly about as bad as a document can
> get and claim to be a "Security Standard." It *has* to have the mechanism
> to get better, it really would have to try to get any worse... Are two
> revisions really "regularly revised?"
We have to keep in mind that we aren't just talking about securing networks where they have a Paul Analog (PA) on staff. Even where they do have a PA on staff, most often he is banging his head against a brick wall of corporate resource management. A good PA (or a good PCI consultant, QSA, whathaveyou) seizes on the opportunity to leverage the attention of the Great Purse Holders and have them pour some cash on worthy efforts that make the network more secure than it was previously.
> *cough*
> Isn't Verizon a QSA?
> *cough*
You should really get that looked at, it could turn into pneumonia...
-woof!
-chris
------------------------------
Message: 5
Date: Thu, 02 Apr 2009 20:04:07 -0500
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] PCI DSS & Firewalls
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <49D56087.4030104@ranum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
AMuse wrote:
> Isn't the point of pen-testing to take up an attackers' perspective and
> hit all your defenses to see if you missed something or misconfigured
> something? I mean, unless you're the only person who set up 100% of
> your infrastructure, how are you to know that someone didn't
> accidentally leave telnet open?
By that logic, I'd want to have another expert system administrator,
not a pen tester, go through my configuration docs and my design
and validate my implementation against my design and docs.
Why would I want someone taking an outsider's perspective - I'd
be much more likely to find something really useful if I had
another expert red-team my configuration and design. Once that's
done, I could validate my implementation against my design as
often as I liked and - if I were really paranoid - I could put
technology in place to make sure I was notified if my
implementation had changed.
This is not simply theoretical, by the way, it's real and I've
put it in practice. The last website I set up, I enumerated
all the connectivity I could expect to reasonably see on
the backend network, so my syslog server was set up to
double as an intrusion detection system by simply running
tcpdump through a program that threw away all the traffic
that was within the enumerated connectivity list, and
alerted on anything else.
Good design just works. You cannot pen test a bad design
into a good design any more than you can patch a badly
coded piece of shovelware into a robust, secure operating
system. (*ahem*) Or turn a sow's ear into a silk purse.
> If you didn't write 100% of the webapps
> your company is using, how are you to know they don't have SQL injection
> flaws?
There's this thing called a "design review" and a "code review"
and if you're putting webapps on the Internet and you don't
know what those things are, you're toast no matter how much
pen testing you do.
So, the design for your webapps should have touch-points
which enumerate all the places where end-user data is pushed
into the system, how it's transformed, and where it's used
in constructions. Those touch-points should all vector
through common input cleaning libraries. Again, this should
be in the design docs and comments and code. Before you field
it, you might want to hire some expert coder to review and
make sure the implementation matches the design - and/or use
a workflow system like Fortify's source code* security suite,
to map out the data-flows, look for buffer overruns, etc. Or
hire a company like Gary McGraw's Cigital, which specializes
in software security and have them do a red team design
review. That's how the grown-ups do it.
mjr.
--
Marcus J. Ranum CSO, Tenable Network Security, Inc.
http://www.tenablesecurity.com
(* disclaimer; I am on a technology advisory board for Fortify,
so you can consider me biassed.)
------------------------------
Message: 6
Date: Thu, 2 Apr 2009 22:51:55 -0500 (EST)
From: "Paul D. Robertson" <paul@compuwar.net>
Subject: Re: [fw-wiz] PCI DSS & Firewalls
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <Pine.LNX.4.44.0904022240491.4989-100000@bat.clueby4.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 2 Apr 2009, Chris Blask wrote:
> > No- the fine is what does that, the DSS is just the artifact with which to
> > do it. However as a "Standard" it's worse than ICSA Firewall testing
> > criteria! ;-P
>
> Now, Al's being nice to me, how can I respond to that? Keep walking, nothing to see here!
That's just me poking fun at Al - my fingers got into that pie too when I
was at TruSecure...
> We have to keep in mind that we aren't just talking about securing
> networks where they have a Paul Analog (PA) on staff. Even where they
> do have a PA on staff, most often he is banging his head against a brick
> wall of corporate resource management. A good PA (or a good PCI
> consultant, QSA, whathaveyou) seizes on the opportunity to leverage the
> attention of the Great Purse Holders and have them pour some cash on
> worthy efforts that make the network more secure than it was previously.
Once again, that doesn't relieve the PCI DSS folks of their responsibility
to do a good job[tm]. See the posting from Victor Williams to see what
folly lies in the obvious stuff that most of us came up with in minutes
about where the flaws lie.
In fact, the fact that you don't have a PA means that training the staff
that's there is more important, not less important- and one way to do that
is with well-written, detailed and intelligent criteria.
The pouring cash on the problem thing is solved contractually with the
fines- again, that's not germain to how poorly thought-out and written the
criteria are.
> > *cough*
> > Isn't Verizon a QSA?
> > *cough*
>
>
> You should really get that looked at, it could turn into pneumonia...
It's already laryngitis :(
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
paul@compuwar.net which may have no basis whatsoever in fact."
Moderator: Firewall-Wizards mailing list
Art: http://PaulDRobertson.imagekind.com/
------------------------------
Message: 7
Date: Fri, 3 Apr 2009 07:32:59 -0400 (EDT)
From: jseymour@linxnet.com (Jim Seymour)
Subject: Re: [fw-wiz] PCI DSS & Firewalls
To: firewall-wizards@listserv.icsalabs.com
Message-ID: <20090403113259.26EC5E129@jimsun.linxnet.com>
<lordchariot@embarqmail.com> wrote:
>
> > 5.1.1 Ensure that all anti-virus programs are capable of detecting,
> > removing and protecting against all known types of malicious software.
> >
> > [Honestly? All TYPES? Every time?]
>
> Hmm, all known types...
> I'm really surprised it doesn't say all UN-known types, too.
Problem is: Many anti-malware tools aren't capable of detecting much of
what they haven't been taught about and, on the systems most vulnerable
(or most widely-exploited today), many exploits, once they become
established, prevent anti-malware tools from seeing them. (I'm
certainly not telling *this* crowd anything it doesn't already know.
I'm just being complete. [Or pedantic. Take your pick ;).]) The
latter problem being due to a combination of poor system design,
brain-dead apps and bad end-user practices.
> That's where
> the risk really is.
Eh. Not really. Yes: The risk is certainly there with these, but
that doesn't reduce the risk posed by known (FSVO "known") malicious
software.
>
> ...of malicious software.
> Is the exploitable application the offender or the data that tries to get in
> and trigger the exploit? Which one do I delete or protect against? The
> programs that read the PDF or the PDF itself?
If y'all will bear with me through a short story...
Years ago, back when dialup and glass ttys were still the way we
accessed systems remotely, one of the software engineers wanted to do
something he felt was Totally Safe. (I no longer recall what it was.)
One of the other software engineers, who was also a part-time admin,
was in favour of allowing it. I shot it down. I explained that many
security compromises were not the result of one, big, gaping hole, but
often a series of little vulnerabilities that, taken separately, might
not seem like such a big deal, but that, when chained-together, were a
Real Threat. Then I showed them how that applied to what they wanted
to do. They were quite astonished.
The point of that story is this: The reasons that the currently most-
widely-exploited systems *are* that way isn't for any single reason.
It's for a series of reasons that, when put together, turn them into
what I call "electronic petri dishes." It is inadequate design; poor
design and coding practices of the OS, OS-level stuff and its
applications, and poor end-user practices--sometimes literally
*mandated* by these things--even when general cluelessness is not at
fault. How are customers told to address these weaknesses? By hanging
bags off the side of them. Ineffective bags.
It's kind of sounding to me like PCI is current history repeating
itself.
I can't say as I'm overly surprised. And I'm kind of getting past
being disappointed.
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.linxnet.com/contact/scform.php>.
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 36, Issue 7
***********************************************
No comments:
Post a Comment