[GRLUG] PCI v1.2 Compliance.

[Greg Folkert]

be wrned, my reply is long and could have been orders of magnitude
longer.

On Wed, 2008-12-10 at 16:05 -0500, Adam Tauno Williams wrote:
> On Wed, 2008-12-10 at 15:21 -0500, Greg Folkert wrote:
> > All I can say it *IT SUCKS*.
> 
> Actually I think PCI is a pretty good standard.  I think 98% of the
> recommendations are solid/good practices.   And it makes a nice club to
> beat good security practices into an organization.

Not to misunderstand me... *MOST* of the standards are HUGELY slanted
towards the exploit-ability of Windows. You should be forced into good
practices with Windows as your core infrastructure.

Well managed Linux typically doesn't require more than a well educated
*NIX slanted person for good LAZY practices. Practices that keep him or
her from having to DO THEM AGAIN or worry about someone fscking up the
machines.

With Windows, you have to worry about Windows crapping itself over a
website, which shouldn't be browsed from a server anyway!

> > Effectively, you have to be running an IDS at all times for all network
> > traffic.
> 
> Or at least all traffic ingress/egress-ing from a machine with payment
> card information.   Also you get a score regarding your PCI/DSS
> compliance,  almost nobody is 100% compliant;  PCI/DSS compliance is
> used as a risk analysis tool.
> 
> Personally this one bugs me because I haven't met an IDS yet that I
> think is worth the trouble;  if there is a category for crappy over-sold
> software then IDS is such a category.
> 
> > Also have to be running Anti-Virus on Linux machines that even "look
> > like they might have CHD" near them.
> 
> Yes, I don't see why that is a problem.  Install CLAMAV.

Its not a problem, but what benefit does running CLAMAV/Freshclam on a
set of EXCLUSIVELY MySQL DB servers where nobody has a login except the
DBA (only limited to MySQL related things) and I have only a Key-Auth
setup for the DBA and myself. And I am blocked from the DB and I don't
know the "admin passwords", though I *could* change it. Its a matter of
having trust (err acceptable risk) in your setup.

To be honest, I'd rather not have those resources soaked up by CLAMAV,
but used by adding InnoDB buffer pool memory to the instance(s) for
being able to hold more data in buffer. We are talking 32GB 64-bit
machines here with 16 cores and lotsa disk space in circular replication
enabled. the more memory they have the more I'd rather have MySQL use
it. Yeah I know ClamAV isn't much at using resources when its not doing
a thing... but *ANY* little bit helps in the trying times of people
being absolutely insatiable for faster response times. (long story if
you want to know in another e-mail sometime)

> > Also have to have logging (transactional and logins and traffic) going
> > back for 90 days minimum.
> 
> All good.

Yes, but very LARGE disk space is required. Already doing 30 days and
getting on the fat side of 1TB logs already. Which is 3 days
uncompressed and 27 days compressed. We are also logging all httpd
traffic to a mysql server on yet another machine for statistics and
billing for bandwidth.

We have our Web Application Server doing logging to a named pipe that
uses a syslog setup on our central server. Or Binary logs are also done
vie the same method and they are split via channel.

Sendmail and Qmail logs... Sendmail for most servers is easy to redirect
to a central server, qmail and because of using supervise it took a bit
of effort to get it to NOT truncate and rotate the logs... to not kill
the named pipe all the time.

Time Serving is another critical piece, if any machine becomes "lost"
its hard to get good logging data to verify or reconstruct a transaction
or session. We have four ntp peers referencing each other and 4
different external level 1 and 2 time servers. It is a good thing. Then
we use time1, time2, time3, time4 for all machine at regular intervals.

> > You are forced to have a "comprehensive" application firewall setup
> > (like mod_security2 for Apache2) that actively blocks all "known"
> > exploits and prevents common practices. This effective eliminates *ANY*
> > CMS transaction handling of *ANY* card holder data.
> > SOAP/XML/Streaming/AJAX virtually non-usable now unless fully double
> > encrypted in both directions with unique keys on a regularly updated
> > process.
> 
> It is difficult to interpret what it pragmatically means in some
> circumstances.   It does pose some real problems for allot of CMS and
> web systems,  but perhaps this is because most CMS / AJAX sites are
> ridiculously insecure.    Language like "all known",  all known to whom?
> It most cases regarding legal contracts such as SLAs this is really a
> requirement for best-effort using accepted best practices.

The language is very vague. Mod_Security2 Rules are written in LUA and
the bulk of them are explicitly for PHP... and they are very damaging to
most Content Management System (CMS from here on out). We use WebGUI and
are finding it more and more difficult, the more and more features
people want to use, the more and more the Rulesets we have block things
and have to be modified to work within params needed (we have 330K lines
of rules being scanned for). We use Perl/mod_perl stuff exclusively on
separate instances and proxy only servers for the mod_security2 and
actual proxy work.

One particular thing is Video/flash/gallery uploads... some customers
want 250MB or larger upload... this is a blatant rule violation for the
"breach network" and "got root" rulesets and since having a completely
separate CMS instance for https vs http is very unreasonable and
extremely hard for our 50 some Web-App customers to wrap their heads
around... let alone WebGUI in the first place.
Ajax/Javascript/Java/Flash all of these are external application
everyone wants to use now a days and don't REALLY CARE if they aren't
secure, because Web Designers today just Want to have cool slick looking
stuff without regard to CHD saftey. 

We have had customers leave us because of our insistence on good CHD
practices. Only to have them come back after finding out they slipped
XXXX number of donor's CHD out into the big bad world by not using
proper encryption (with proper key management) or truncation. They also
had to pay damages and help pay for other things. 

One ministry got a judgment against them for $8M, mainly because they
were led to believe that things were not what they really were and the
four spunky Web Developers and IT staff were all prosecuted for
something and got put in jail for a few months to one year.

> > Disk Encryption for most everything application related must be used,
> > goodbye NFS anything. 
> 
> I believe current versions of NFS are quite secure;  the latest versions
> of NFS can even perform authorization via GSSAPI.

Oh the current instances NFS v3/4 are secure, but they can't be
encrypted at the NFS server level even with current NAS or most
reasonable SAN appliances. This is an area that only local storage can
work (or things that act like local storage).

Authorization is another item to deal with. That is a different item on
this front.

> > NO WIRELESS PERIOD. WPA2 suspect now and likely to become non-allowed
> > shortly.
> 
> I don't believe WPA2 (if we mean PEAP or EAP-TLS + TKIP or AES) is
> suspect.  The recent reports of exploitation were grossly exaggerated.

Well according to some early drafts, WPA2 is going to heavily redacted
to what and where and how it can be used. Everything else will be
forcibly removed and kept that way. No 40-bit stuff or anything of the
like.

> > FYI, these are just a few of the things we have been told etc...

One other piece, SINCE we are a Virtual company with a Data Center in
the middle of the country and another one on the left coast... and one
in Canada, we have also been told that the PCI Level 1 for Service
Provider (I think that what it was transformed into) requires a physical
visit to each and every Employee's home and evaluating and inspecting
our machine and networking setup. Inspecting our machine for *ANY TYPE*
of CHD. I freely admit I have CHD info on my computer... a file for
every transaction from some days. But it seems as though the files are
encrypted... with a huge long key... and a freakishly STUPIDLY long
passcode/phrase.

This is big, we have people in Calgary, Grand Rapids, Chicago, Denver,
Los Angeles, Seattle, Thousand Oaks, Mad-Town, Indianapolis. Contractors
will have to provide PCI compliance ... some of these Contractors are
former Employees that ONLY work for us... and now have to become PCI
certified as well which means a $7K bill for them to become certified.
Its also going to cost us $15K-55K (depending on scope) plus travel and
per Diem during physical visits. All of these costs are YEARLY. Not to
mention the (upgraded) IDS console costs (Mainly NICE hardware with
lotsa disk space locally), the Networking services we have to real time
monitored now (port with all VLAN traffic tagged), nagios updates and
writing of plugins for specific events that apply to Windows machines
only but are forced to monitor them on Linux machines, because.... just
because.

I could go on and on and on and on... the specs are so vague that they
encompass *EVERYTHING* when they really means Windows.

We are a non-profit that services non-profits and the requirements don't
change, nor does the cost. I can understand the requirements not
changing, but dang now these trouble non-profits have to raise *THAT*
much more money to be able to take donations via Credit Card... which
made donation easier for the constituents.  

Its painfully obvious they want to see everything all the time, but in
doing so makes the environment even MORE complex and fragile and
exploitable. *SHOULD* someone get at my IDS or logging servers ... it
would be fairly simple to do everything these things were designed to
help prevent.

Of course, the penetration tester asked for a username and password on
these machines and the ports the consoles were running on. And I didn't
give them to him.

I gave him a Debian SID machine with a minimal install (but a public
interface and a private interface with SSHD running on the public side
only), with out any obvious way to get things onto the machine. No FTP,
no SCP (ssh client stuff), no wget, no curl... in fact the only thing
available was netcat and a few other "networking" tools left around. He
called me immediately and asked that I install this and that with a
smattering these things with a compiler and other nice to haves. I said:
"No, you are the penetration tester. I gave you a machine that I'd place
on the Internet straight and I even gave you tools I'd typically not
leave on the machine."

He reported us as non-compliant, I challenged that declaration. I won as
I was able to demonstrate the idiot wasn't a good penetration tester. He
had a public interface *WIDE* open and a Private Interface *WIDE* open.
With no IPTABLES loaded, no routing or forwarding ability. Effectively
an SSH relay machine with SSH turned off on the private side. I used
netcat and a combo of the tools on the machine to GET a compiler, a set
of rootkits, a remote command daemon and other things installed.
Including libraries and many other things needed for compiling. I then
went on and installed apache2, MySQL, nessus and other pieces to scan
the interior network and also nmap to sweep the network. All from HIS
account, without ever using root. I even found the IDS and other
monitoring machines and the logging server (though I couldn't get to
them as things are configured for access). All in all it took about 4
hours longer to get everything installed and compiled in his userdir...
but it all worked and like a charm.

By the way... Don't use TrustWave as a PCI QSA (or whatever its called).
Hint Hint.
-- 
greg at gregfolkert.net
PGP key 1024D/B524687C 2003-08-05
Fingerprint: E1D3 E3D7 5850 957E FED0  2B3A ED66 6971 B524 687C
Alternate Fingerprint: 09F9 1102 9D74  E35B D841 56C5 6356 88C0
Alternate Fingerprint: 455F E104 22CA  29C4 933F 9505 2B79 2AB2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://shinobu.grlug.org/pipermail/grlug/attachments/20081210/04d6b594/attachment-0001.pgp