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