On 01/22/2014 06:55 AM, Paul Robert Marino wrote:
> 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
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>>
>>>
>>
>

Thank you!

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computers are like air conditioners.
They malfunction when you open windows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~