IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Does general PCI q? belong here?
If so:

I have a corp network with mostly off the shelf software.

I have a custom app written by a 3rd party company that has about 10 employees. They write an occasional tweak now and then. It stores all the critical data, including PCI relevant data. It executes a client on the Windows PC which stores the data in an OI database on Windows server.

What level of encryption and protection can I, as the admin, enforce on this environment?

What do I need to tell my vendor to do in order to make sure it passes a PCI security review? What documents do I need to forward to my vendor? Does it require a full PCI review on them?

I have a custom built website hosted offsite by the vendor who wrote it. The vendor claims PCI compliance in lit, but of course would like to do as little as possible.

It is based on Linux/PHP/Drupal. I threw a bunch of various scans at it and did not trigger any issues, but I have no idea what level of coding competence they had, so I don't know what trapdoors and time bombs are waiting for me.

It collects orders, including key PCI fields. It packages them up and send them to our inhouse system via an encrypted session. It logs information locally, but it strips all CC fields and does not store them. In the event of a "missed" order to our internal system, we can log into the web site and get the client contact info, but we HAVE to call them for the CC card info at that point, which we don't mind.

Again:
What do I need to tell my vendor to do in order to make sure it passes a PCI security review? What documents do I need to forward to my vendor? Does it require a full PCI review on them?

I do an occasional piece of code. I have admin rights everywhere. While we have another admin, he's a "learn on the job mostly windows kind of guy" and does not know enough about security to be called in to be my "2nd" in these situations. There is no one else in the company that can read or review it, they simply don't have the skills. It is up to me to make sure it "works" and doesn't do anything "bad".

What type of compensating control can be put in place that does not include hiring another coder or calling in an outside auditing firm every time I write a script? Do I even need to think about it? My code is more for operational scripting than data stuff. I guess if it simply does not run on any system within the PCI subnet, I don't need to think about it.
New If you don't store the CC#
You have seriously dodged a huge bullet there.

You still have CHD though that needs to be secured. CHD == Card Holder Data.

But since you don't store payment info (either CC#/EFT#/other), you are a lot further along than you thought. You'll just need to make sure you primary application and your logins to it "expire" on a certain amount of inactivity and will require a "re-authentication" to get back to working. There are also successive failure locks out the user. and you will need a paper trail on administratively resetting the account. Our system for the SSH version we have is 5 failures successively, triggers an 1800 second timeout. If you try again within 1800 seconds it resets. After 1800 seconds, you will be allowed ONE more attempt. Failure there will cause another 1800 second wait. Passwords will need to hanged every 3 months and no password used in the last 4 iterations maybe reused. It will also require a certain length and certain number of non alpha characters and probably a capital.

That is about as much as we had to do, but since we DO store payment type info, we had to encrypt the CC# fields. This requires having a "Key Management" program in effect, with only certain people able to view that info... so CHD policy levels. Its gets more and more complicated the more stuff you do.

You have to make sure the Drupal app is reviewed by your Auditor. They probably will require the host to present their PCI certificate of compliance.

To me it seems a lot of the PCI crap is just that. Its precautions for Windows Servers and Windows computers and Windows VPNs and policy... etc.

One last thing, if you start actually processing your own CC transactions, you will need to make sure you do it right... penalties are excessive. Even for not submitting Level 2 Card Tax info with the transaction (not required for Consumer cards only Business to Business credit cards)... they can be more than the actual transaction.
New You missed it
and something tells me you need to type a lot more.

Our web app does not store the CCs, it forwards them to our internal system that does.

It does it via an HTTPS push to a Windows box which then writes the file. This file is then picked up by another box (linux automation) to be pushed into the internal system, custom OI app under Windows.

So now how much hell am I in for?
New HAHAHAHAHAHAHAHAHA!!!!!!! Oops ... sorry
This stuff is exactly why two different places I've worked have gone very far out of our way to not store the #s. Every time it moves from one box to another is a mountain of shit to wade through.

And like Greg said, most of this is assuming you're on Windows. I've seen auditors who wanted proof that Symantec or McAfee was installed. Sysadmin argued until he was blue in the face that there was no product from either of them that could be installed on the AIX box, the auditor didn't care.
--

Drew
New Let's all relax here
This is a self assessment.

For a company with a low volume of CC usage, and a small client base.

An audit is very unlikely, but I'd like to be prepared.

And yes, I remember the days of forced virus on Linux scans, I used that story on my boss. Happened to me at another company.

Not anymore. PCI now says to only put virus scans on systems that matter and are commonly affected by viruses.
New Audit happens every...
year for re-certification and the initial audit is a BIG PITA.

Its just like an Accounting Audit in attitude and methods.

Yes, but they would rather you have AV on everything... including Linux. Clam AV is suitable... in case they *HAVE* to have something.
New Maybe to you
But we are tiny.

You don't audit tiny,
you check their paperwork
for stupid stuff and wave them on.

Of course, not always. So you have
to be prepared, but we do not have
an auditing firm, it is not a
requirement that I am aware of.

Is it?
New What do you think the initial PCI compliance...
work is all about?

They are getting YOU to audit everything and then verifying it to be that way.

How much per year does this company do in Payments? I'm not looking for exact numbers.

$1M? $5M? $25M? $100M?

I don't know where the cut off is any more since they keep lowering the number. They also eliminated the lower classes recently.
New Is this "required" required?
Is this a "voluntary" certification that, in practice, VISA/MC won't work with you if you don't have it? Or is it a hard requirement? Just curious.
--

Drew
New Oh its the Voluntary one.
But good luck processing any transactions with out it.

The required part though is the certification the PCI Auditors give you so that VISA/MC see you've voluntarily become PCI compliant.

But then again, remember Heartland?
New Oh, it's required.
And yes, I know what's it's for. I spent 3 hours in a meeting explaining it to a company owner yesterday. It's a new world, and if you want to use credit cards, you gotta dance to their tune and build it into the budget.

We spent about 15 minutes trying to figure out how to run the company without storing the CC numbers. We can't. We hold seminar and conferences. We do automated refunds. There are situations where prepayed courses are canceled, and we immediately refund the money. Also, we delay charging for certain courses depending on certain situations. So we get the CC number and store it, and then do batch charges and refunds.

Our CC vendor say:
The old payments app (that we gave you) you are using is not PCI compliant.
You MUST stop using.
Here is the new one.
Please test it.

So we test it, it works, and then the vendor says:

Where is your PCI cert? You CANNOT use this new app unless you are PCI certified.

So they yank the app, tell us to use the old, non-PCI compliant one, until we get EVERYTHING else done, and then, and only then, will they allow us to use the new one.

And then tell us since they know we are not PCI compliant, the clock is ticking, and the hammer could come down at any moment.

We were in the process of setting up a new web site, the old one did not stand a chance of passing. Ever. So now that the new site is done, we are working through all the other issues.

Also, we had an old employee who was in charge of the web site. The old web site. The one that was not necessarily doing everything the right way. He had spent years directing me to do things that I didn't necessarily agree with, but he was the boss. And this X-employee pretended to be a concerned client who detailed their worry about how we were handling CC transactions, and sent it to Visa. Visa contacted our CC service company, and they contacted us.

So we are in their sights.

But back to you question: Tiny. Let's say $2M to $4M.
New Your company falls..
right in to that gap it can go either way.

But since you had someone "Tattle" on you... you know which way its going.

It sucks!
New AIX? That's a tree-chopping implement, right?
You guys have my sympathy.

Cheers,
Scott.
New Actually, AIX...
I liked AIX better than HP-UX. But not as well as OSF/1 (DEC) errr Tru64 (Compaq).

AIX has a lot of features that makes it very easy to install system patches and run with them still not yet committed, able to be removed/backed out all on the fly. Also, has a lot of advanced features that make things work easier for installs and volume management.

Since Oracle purchased KSlice... that feature is now gone for Linux, except for "Unbreakable" Linux (Oracle's RHEL clone).

New Ouch.
The Windows machine is going to be a big sore point. Even using it to store the data for a short bit.

This means the CC# has to be encrypted during transit, err the actual CC# has to be stored encrypted everywhere. At no point can it be "in a file or db" un-encrypted, even if the file is transmitted encrypted over the internet or any public part of your network... Windows Desktop are in Black Zone. Application Server and DB servers are in White Zone. Webservers having to be accessed from the Internet and Workstations are in Grey or those kinds of things.

Well, since you *ARE* storing the CC# in the internal system here is what we had to do:

1) Establish a strict policy that NO Payment Card Data is copied, stored, moved, cut-n-pasted, e-mailed, "captured" in anyway shape or form on any computer or computing device, other than stored in the DB and displayed only by authorized persons (more on that). This is a single instance firing policy. Break it once... by by.

2) The CHD DB has to store the Payment Card (Debit, Credit, EFT, etc...) number completely encrypted. There is a Key handling policy framework that has to happen, with two sides (phases) to the deal... a Key manager, someone outside of IT, typically a department head. Then the IT/App side of things which "signs" the key. This is to keep things "honest". These keys will need to be changed/renewed yearly. We start with an initial Key generation request, which goes to the Key Manager, they enter the password/passphrase and it needs to be recorded and put in a safe spot and then once that is done, the IT side can then do it thing and put the "signed" key into place and the old one expired.

3) Levels of access need to established. Those who can and can't see the actual card info. Those who can and can't see the CHD, besides the card info, those that can enter information into the system and edit non-CHD info. This is where access levels can be tricky, since we already had some controls in place for this kind of access and restrictions, it was straight forward. This forced us to goto a single authentication mechanism. LDAP for us as we are 100% Linux. You will probably have to join the Linux machines to the Windows AD Domain setup. Though Root and Administrator for the Linux machines are not LDAP sync'd for other purposes. Also our LDAP servers are outside the LDAP domain for logins, hence my work this week.

4) Keeping track of all this stuff in a documented way for password, access infractions and Human Resources tracking... PCI is not just about the computer systems, they also will want Physical Access to the servers restricted (usually with swipe card and PIN) and logged and monitored with Video for 90 days. We ended up having to put a Camera system with cameras enough, one at each door of our colo cabinets front and back. All because our Colo only goes back 60 days on Video.

5) Now as far as PCI compliance, there is also other parts of this. You hiring processes are part of it. Keeping track of Firing and reasons and so on. Security Incidents and resolutions (infractions of CHD exposure inappropriately, system cracks/compromises and resolutions) all this stuff and you gotta friggin air your dirty laundry to. If you don't have any they "Audit" harder and find stuff to be picky about.

Final review is a long process also, it can take weeks to get all of the Data and documentation in order. They want SCREEN Capture proof of things being what they want, not just an editable list. (like rpm -qa, or iptables-save on a scrolling terminal and getting progressive screens or on Windows shots of all the options screens and configuration set etc)

Good luck and don't be a hardass with the Auditors, do be a hardass with your Boss, they are there to tell VISA that you are doing the right things... and are placing their certification on the line for you and your company. They are just as liable for PCI data leaks as you are, unless they can prove you were hiding stuff from them (which some companies do and get caught with their pants down, remember Heartland?)

Remember *I HATE* PCI Compliance Certification. To me much of the rules and regulations are simply people making policy decisions that do not know better. PCI has a LOT of good things in it... but a LOT of annoying stuff as well.

Compensating Controls when used have to agreed upon by the Auditors. Be fair, listen to them and help them understand, why the a Comp Cont is appropriate in "this" instance.

Sorry for the rambling and ranting... but its hard to not do it... mainly because this week I'm doing the

Do White/Grey/Black Zone Nessus (with Professional Feed) Scans and remediation
Do External Paid for "Rapid7" Scans and remediation
Do Root/Administrator password changes on all machines.

Hope this makes more sense to you, than it does to me... I wandered a bit, but gave you much of what you need to consider and do.

If you need more answers... I'm thinking e-mail would be better.
New All good stuff
Thanks
And yes, read it all.
Feel free to pour more pain out in an email to me.
New What Greg said.
If you need an auditing firm, we had a pretty good relationship with Coalfire Systems. (still true, Greg?)

Even with self assessment, you need to prove external scans by an ASV. Check the website https://www.pcisecuritystandards.org/ for the latest list of vendors.

Good luck - I'm glad to not currently be a part of that world.
New We got the scan vendor
Our CC processing company told us to use a particular vendor for scans. They have a deal with them, and feed their customers. The security vendor will scan for free, and support you through the process of the SAQ, but they have an ulterior motive.

They want to sell consulting services. And they get to judge if my company is PCI compliant. So any mistep means they can declare us not compliant, and then come in to sell their services. This is a major conflict of interest.

On the other hand, we are tiny, single computer room, 3 servers internally and an external hosted website. They know they can't make any real money from us, so they are usually very helpful by default. They just want us off their plate.

Our new web site passed the scan yesterday and we can put their logo on it. Yay!
New woot
Passing a scan is praiseworthy indeed.
     Does general PCI q? belong here? - (crazy) - (18)
         If you don't store the CC# - (folkert) - (17)
             You missed it - (crazy) - (16)
                 HAHAHAHAHAHAHAHAHA!!!!!!! Oops ... sorry - (drook) - (10)
                     Let's all relax here - (crazy) - (7)
                         Audit happens every... - (folkert) - (6)
                             Maybe to you - (crazy) - (5)
                                 What do you think the initial PCI compliance... - (folkert) - (4)
                                     Is this "required" required? - (drook) - (1)
                                         Oh its the Voluntary one. - (folkert)
                                     Oh, it's required. - (crazy) - (1)
                                         Your company falls.. - (folkert)
                     AIX? That's a tree-chopping implement, right? - (Another Scott) - (1)
                         Actually, AIX... - (folkert)
                 Ouch. - (folkert) - (4)
                     All good stuff - (crazy)
                     What Greg said. - (Steve Lowe) - (2)
                         We got the scan vendor - (crazy) - (1)
                             woot - (Steve Lowe)

The revolution will not be televised. You can apt-get it from the usual mirrors, however.
95 ms