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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~