James
thats a great analysis I highly encourage you to write an article on
the subject some time.

one more thing I would add is about authentication. If you are planing
to use centeralized authentication make sure you do a full LDAP 3
implementation with TLS and Kerberos 5. do not use the standard config
most people use where they put a password in the LDAP client
configuration always use Kerberos Keytab files and secure them well.

I would also highly suggest a password auditing system esspecially if
you dont intend to use centralized authentication. There is a decent
one thats not to expensive Ive used in the past which also acts as a
password vault called Password Manager Pro from Manage Engine.
Unfortunately there are no free alternative out there which surprises
me because it wouldn't be too difficult a project to write. Again that
should be in its own isolated local network that is not accessible
from any where but a few internal workstations.




On Wed, Jan 22, 2014 at 6:11 AM, James Rogers <[log in to unmask]> wrote:
> Just one more thing: you must run your datastore of card holder information
> on server separate from your external interface. The cardholder datastore
> should be accessible only via a local (non-routable) network. Ideally, you
> should mac address restrict this using IPTables on the machine that holds
> 'things'. Never store CVV codes, although you might want to discuss with
> your client the relative benefits of CVV codes vs address verification.
> Gateways charge more for CVV/CVF. You might want to request the code, never
> store it, and check it only according to internal constraints, but always
> perform address verification.
>
>
>
>
> On Wed, Jan 22, 2014 at 5:40 AM, James Rogers <[log in to unmask]>
> wrote:
>>
>> You'll need an application firewall. If you're using Apache, mod_sec will
>> work. Put up a proxy and filter connections. Don't run the proxy on the same
>> machine (VM or HM) as your app and/or its storage if you can manage.
>>
>> Likely this means running a separate VM/HM in front of your web app and
>> that acts as a scanning proxy running mod_sec.
>>
>> You should also run a HID on all machines and an NID on your border
>> firewalls. Pick people from your client's execs to send the warnings &
>> reports to (not the same person)  as you will need to list them in your PCI
>> docs, along with a _responsible_ tech who actually pays attention at 4AM.
>>
>> As far as HID's: Tripwire is venerable, AIDE is current from my
>> understanding. You might also check into Beltaine/Lucifer.
>>
>> And NID: SNORT or Suricata. And if you feel brave / if you need it: feed
>> the output of your NID into iptables for an active firewall. If anyone trips
>> you're HID, it's kind of baby vs bath-water time anyway once you have it
>> tuned: they're in... what do you do. Always leave some trips around that let
>> people know even if it is a rarely occurring legitimate changes. Testing the
>> alarms regularly is a part of the alarm system.
>>
>> Unless you're _providing_ PCI compliance to your client as a documented
>> service, you should ask them for their requirements. In other words, don't
>> eat more liability than you need to. Unless you're a lawyer, then you will
>> have separate ethical requirements.
>>
>> This is vague (certainly not legal) advice, give more on your requirements
>> and/or seek a lawyer.
>>
>>
>> On Wed, Jan 22, 2014 at 5:10 AM, James Rogers <[log in to unmask]>
>> wrote:
>>>
>>> PCI compliance is largely related to what PCI level your client is at.
>>> That level is related to how much money they move each year.
>>>
>>> Selinux (or Apparmor) is good. Some sort of MDAC on your machines that
>>> handle PIF is a good thing, but as you noted, it won't protect you from
>>> social hacks, just from the chaff spewed on the internet by C2 servers and
>>> their botnets.
>>>
>>> If you don't find it too onerous, encrypt the swap and the filesystem. Be
>>> aware of the dangers of this before you start and plan for them. Have
>>> safe-houses your client plans and pays for that store the relevant
>>> information. Use M-Disks to store it? And encrypted drives.  You'll know
>>> what to do once you explore the dangers of encrypted filesystems, and your
>>> client will produce locations.
>>>
>>> As far as AV... hmmm... I would go with 3 engines of your choice, one of
>>> which should be ClamAV. I would go with Frisk/F-Prot as the next (they're
>>> not expensive). And then maybe sophos if your clients have the cash to
>>> spend. What you're largely looking at from the AV scanners is that they
>>> protect the people visiting your site. Unless you're doing something with
>>> the DoD and then you will have different requirements.
>>>
>>> The next place to look (or the first even) will be an active daily
>>> scanner for your external reporting. If you're dealing with a Merchant Bank
>>> / Acquiring Bank, use theirs as that will be least expensive. Otherwise...
>>> Hackersafe/MCafee is a reasonable choice as it is automated and you don't
>>> have to deal with people very often; they're owned by Intel so they're not
>>> going to dry up and blow away, which is a plus. You should be doing their
>>> job beforehand using nessus/something else. Your external scanner will give
>>> you a badge to display. Basically, the scanning company will run a port and
>>> vulnerability scan and then offer you remediation recommendations and
>>> requirements. If you don't solve your problems, you lose their seal on your
>>> site.
>>>
>>> Every year you will need to forward PDF reports from the company you
>>> contract to scan you to your merchant bank and any other parties that
>>> require PCI compliance. It's not a big thing, but something that must be
>>> done, and you will need to find the contact information for the people
>>> involved and make your client aware that they need to pay attention to it
>>> and keep track of any change in contacts after your contract expires.
>>> Remember to charge for the time you spend on this. Contractors often forget
>>> to charge for doing small things, and so they don't get done. Make a point
>>> to charge your client and provide the information they need to keep doing
>>> business.
>>>
>>> This is likely more than you wanted.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jan 21, 2014 at 12:39 AM, ToddAndMargo <[log in to unmask]>
>>> wrote:
>>>>
>>>> Hi All,
>>>>
>>>>    I am in the thinking phase of a new server for
>>>> a customer.  The server needs to be PCI Compliant
>>>> (credit card security).  PCI is really a huge
>>>> paper chase and although it adds a lot of good
>>>> practices, it doesn't really address the human
>>>> factor like it should, which is where most of the
>>>> breaches come these days.
>>>>
>>>>    I was going to suffer with SE Linux left on.
>>>> Samba with SE Linux: I will say a few blue
>>>> words before it is over.  :'(
>>>>
>>>>    I have the File Integrity Software picked out
>>>> (CimTrak) as I has used it in the Windows Arena
>>>> and like how it works.  And the sales and tech support
>>>> is astounding.
>>>>
>>>>    What I have yet to pick out is an Anti Virus (AV).
>>>> It is part of the paper chase.  Looking over at
>>>>
>>>>    http://chart.av-comparatives.org/chart1.php
>>>>
>>>> I am not seeing Clam AV.  I know Kaspersky has one,
>>>> but the last time I tried it, it was a mess.
>>>> Any thoughts on an AV?
>>>>
>>>>   If you look at the chart, no one did worse than
>>>> M$ Security Essentials in December.  Chuckle.
>>>>
>>>> Many thanks,
>>>> -T
>>>>
>>>> --
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> Computers are like air conditioners.
>>>> They malfunction when you open windows
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>
>