Credit Card Security Standard Issued 98
alphadogg writes "The Payment Card Industry Security Standards Council, the organization that sets technical requirements for processing credit- and debit-cards, Wednesday issued revised security rules, while also indicating next year it will focus on new guidelines for end-to-end encryption, payment machines and virtualization. PCI adherence has been pushed big time in the industry to help avoid more big breaches such as the one involving TJX. Those familiar with the standard say it could be expensive to implement and that there are some things those using wireless LANs will need to pay especially close attention to."
PCI standards and real life (Score:5, Interesting)
I don't know how many reading this have been through the whole PCI thing. Personally, I think that it is pushed by folks that are selling 'scanners' and other remediation software.
I believe that security standards are a good thing. I appreciate that PCI has helped many environments be more secure. However...
I have worked in 3 unix shops that were devoted to E-Commerce. Currently, I'm really impressed with the company that I work for and how they do things. Unfortunately, I have seen things that most Unix admins/Security admins would have nightmares about in some other places that I have consulted. Yet, no matter what security flaws are there, they always passed.
I shudder when I think of one company that I worked with. They are a very high level financial institution. Guess what their AIX HMC passwords are? Can you get to them from the outside world? Yep. Could I down their production servers, a year after I worked there? Yep. Are they considered compliant to DSS/PCI standards? Yep.
Re: (Score:3, Interesting)
Exactly.
I haven't worked with PCI specifically (although it's looking like I will soon) but I've seen the same sort of BS when working with telecom companies. They plop down a gargantuan checklist which is clearly the umpteenth managerial iteration over something that may have once been written by someone who knew what they were doing. Following the checklist does not mean that you are secure, but it is possible to be secure and also manage to check all of the boxes they want.
Re: (Score:1)
And yet, all the specs boil down to:
Thou shalt apply ROT13 encryption to all credit card data.
Re: (Score:2)
Thou shalt apply ROT13 encryption to all credit card data.
Twice.
Re:PCI standards and real life (Score:4, Insightful)
That's because PCI-DSS covers weak passwords but doesn't really test for them.
PCI is more about documentation and network layout than anything else. When my company did my audit they demanded segregated backend/ front end networks, SNORT machines on both and then followed up with a "pennetration test" that checked for common web server exploits and misconfiguration and the security scan actually encouraged us to hide all of the version numbers.
The upshot of all of this is that some of the things I had to do made things more secure but most of them were things that would look good on paper. I can still do things like not change passwords when people leave or put them on a paper I keep on a bulletin board and still keep my cert.
Re:PCI standards and real life (Score:5, Insightful)
I shudder when I think of one company that I worked with. They are a very high level financial institution. Guess what their AIX HMC passwords are? Can you get to them from the outside world? Yep. Could I down their production servers, a year after I worked there? Yep. Are they considered compliant to DSS/PCI standards? Yep.
I suppose AIX servers were in PCI environment (otherwise your comment is out of scope).
Then the situation you describe probabely violates the following requirements:
req. 2.1: "Don't use default passwords"
req. 8.5.4 "Immediately revoke access for any terminated users."
req. 8.5.5 "Remove/disable inactive user accounts at least every 90 days."
req. 8.5.6 "Enable accounts used by vendors for remote maintenance only during the time period needed."
req. 8.5.8 "Do not use group, shared, or generic accounts and passwords."
req. 8.5.9 "Change user passwords at least every 90 days."
req. 8.5.10 "Require a minimum password length of at least seven characters."
About the fact that you can connect to servers from outside: that means no segmentation which in its turn means that the whole internet is to be considered as part of the PCI environment of this company.
Now please tell me by WHOM are they considered compliant?
Being financial institution means that they are provider (and may be merchant too) they certainly have to be audited by a QSA (self assessment questionnaire would not be sufficient) which could mean one of tho things:
The QSA did not his job properly
The company concealed things form the QSA
Re: (Score:2)
I do know that nobody accessed our SERVERS to check the reports that the same SERVERS had made.
See that's another violation of the standard. Since your employer was a provider or merchant, they would have been required to have a QSA actually physically audit the network, which includes much more than just a network scan? Who was doing your compliance?
Re: (Score:2, Interesting)
Re: (Score:3, Interesting)
Well, financial institutions didn't care much about the safety of funds they have invested in, and that's their core business, why should they care about IT security?
I guess they couldn't have screwed up worse than they did, even if they had "1234" for all root passwords on their data centers.
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
Whew, I almost thought I might have to change the password on my luggage...close call.
Re: (Score:1)
Re: (Score:3, Insightful)
The problem with PCI is that it's a great deal of expense and trouble attempting to overcome a fundamental weakness in the system: That the card number is used as identification and authentication and by itself is sufficient to process a charge.
For the inevitable car analogy, it's like removing the door locks and replacing the ignition lock on a car with a simple toggle and pushbutton, then equipping the garage with a $10,000 state of the art security system and calling it good enough (completely ignoring t
Re: (Score:2)
Only because they lie to their assesors:
8.5.8.a For a sample of system components, examine
user ID lists to verify the following
Generic user IDs and accounts are disabled or
removed.
Shared user IDs for system administration activities
and other critical functions do not exist.
Shared and generic user IDs are not used to
administer any system components.
8.5.8.b Examine password policies/procedures to
verify that group and shared passwords are explicitly
prohibited.
8.5.8.c Interview system administrators to
Re: (Score:2)
Could I down their production servers, a year after I worked there? Yep. Are they considered compliant to DSS/PCI standards? Yep.
NO.
Passwords MUST change every 90 days at minimum, with a whole lot of rules. If they don't do that, they are NOT compliant. End of Story.
I work in the industry.
But when will consumers see additional security? (Score:5, Interesting)
Consumers in the US in particular are hugely behind the curve as far as end to end security goes. A lot of Credit and Debit cards are still being issues without Chip & Pin. Yet worse for some mind boggling reason Credit Card companies have started installing RFID into these cards.
In the EU, the UK in particular Chip & Pin is mandatory while RFID is nowhere to be found. Now I appeaciate that the US only recently moved away from Checks and still have a very questionable Direct Debit (bank to bank transfers) system in place but you would think one of the worlds leaders wouldn't be one of the worlds losers in terms of card security and fraud protection.
Re:But when will consumers see additional security (Score:4, Insightful)
I think you answered your own post. The EU is more up to speed because security has been regulated (fraud is the merchant's problem in the US, not the bank or processing network). Card issues care less about security and more about transaction volume.
I can't explain why our banking system sucks though. I would've thought we'd be ahead of the curve when it comes to moving money electronically. *shurgs*
Re:But when will consumers see additional security (Score:4, Insightful)
RFID is everywhere in Europe - just not on the credit cards. Yet. But the situation is changing.
The US is skipping on the chip-n-pin because it makes sense for them to jump directly to the RFID cards, which are physically more durable, and allow for different form factors (like mobile phones or keyfobs).
The RFID card security problems currently can be attributed to flawed security design, not to the technology itself. We trust TSL over WiFi, and WiFi is far more easier to skim than RFID comms.
Re: (Score:2)
I'm not convinced RFID makes much sense really.
With chip'n'pin there is cryptographic processing going on on the card to verify it's not being lied to by the shop or the bank. With RFID.... a number gets returned. Not so useful.
If you're referring to wireless EMV (or similar) then that's different, but is usually still going to be in card form.
Re: (Score:1)
RFID is not necessarily more secure, however, it's more convenient, but only if the proper education is given to vendors and consumers alike that adopt the cards and readers with RFID technology.
The whole idea behind RFID is convenience. No swiping and waiting, just pass over with a certain proximity and out comes the receipt, under $25 no signature required. DES is used primarily for security, but I'm sure whatever else the Payments industry is setting standards
Re:But when will consumers see additional security (Score:5, Insightful)
You misunderstand the system.
Credit card companies and banks make money from fraud. You (as a customer) pay for insurance that they use to cover the fraud. They have no incentive to change. Changing will just cost them money and won't affect their bottom line.
At least, that's been the situation for decades. However the consequences of handing billions to criminals is starting to have an effect. The criminals have billions in assets, and can leverage those for bigger and bigger forms of fraud, and they are.
I don't really want to hear any more of this crap about how they're going to "segment" my secret pieces of information behind a firewall. The whole system is a house of cards, built on "secret pieces of information" and heuristics about the kinds of transactions fraudsters perform. Once someone has stolen all the relevant secret pieces of information, all bets are off and the system has failed. These "secret" pieces of information are not hard to obtain, and adding more secret pieces of information (i.e. CVV2) is absolutely not a solution. I want end-to-end encryption and transactions which don't need to be perpetually stored in a database alongside my secret pieces of information.
In short, I want electronic, encrypted cash. When my wallet is stolen and not worry that I will lose any more than the cash actually in the wallet. I don't want to have any more transactions denied because I traveled to a foreign country.
But most importantly, I want to take those billions out of the hands of criminals.
Re:But when will consumers see additional security (Score:4, Interesting)
"Credit card companies and banks make money from fraud."
Not in the UK they don't. Oh sure, they probably have it insured, but until recently the liability for loss (where they couldn't prove the merchant or customer was complicit and don't catch anyone) was all theirs. This is because they supply the tech, they mandate the schemes, they set the standards.
EMV goes some way to what you want, there is encrypted information sent between the card and the issuing bank that nobody else can read, but is dependant upon PIN. The biggest hole in the scheme is that you are still allowed to fall back to magnetic strip transactions in some places. They tend to be where the fraud is done now.
Re: (Score:1)
Those losses have to be paid from somewhere. It's either paid by the consumer (hidden in the interest rates and fees), or by the merchants (in the transaction fees), or the credit card companies would go out of business. That was the GP's point.
Re: (Score:2)
There is no solution that would allow for the non logging of transactions that would also allow for accountability. Transactions simply must be logged for proof that the transaction happened and, in the case something goes wrong, to allow the rebuilding/ confirmation of the correct account balances.
Having said that PCI-DSS does demand end to end encryption and the requirements for storage encryption go up considerably if you actually store the entire credit card number (masking it out works better). CVV2
Re: (Score:2)
Open your wallet and look for the funny colored pieces of paper. It also does not have accountability, and has worked fantastically for thousands of years.
Accountability is something I can live without, and would occur at other points in the system (i.e. bank transfers, paycheck deposits, etc). Accountability with merchants is needed only if the system is so insecure that a merchant can act
Re: (Score:2)
An encryption scheme with the same properties as cash (and no accountability) can be easily created.
Go ahead and try. It's no so easy as you appear to think. To get you started, try answering this question: How do I know that this "e-cash" hasn't been duplicated (spent more than once) without a central database tying each unit to its current owner?
Cash works because it's tied to physical matter, and because effective counterfeiting is hard (and incurs highly disproportionate penalties). Even assuming that e-cash cannot be counterfeited per se (each "e-note" being securely signed by the issuer) you still h
Re: (Score:2)
Every person I know carries around a digital camera in their pocket. The number is printed on the credit card. CVV2 is treated as secret by certain parties, but fraudsters are certainly not going to play by those rules. As such, CVV2 is like the "orange alert" system. "Hey look! We're doing something!" It may mitigate some fraud occurring high in the CC processing chain, but I doubt that's not where most of the fraud
Re: (Score:2)
CVV2 is there to force the card theft to be either physical (from the back of the card) or real time (by monitoring transactions on the server).
If I take a picture of your credit card: I have one credit card and it took me several seconds to get it and I risk getting caught.
If I monitor the server I have to either transmit the data back to myself in real time or break in again to read my logs. Both increase my risk of being caught but I can gain hundreds or thousands of cards.
Before CVV2 If I broke in to y
Re: (Score:1)
Re: (Score:1)
Yes there is the insurance aspect, however it is useful to note that the card schemes attempt as much as possible to push liability to the card issuers who push to the acquirers / third party processors who push to the merchants.
The requirements relating to segmentation give the payment processor
Re: (Score:2)
Credit cards are an authorization based system and NOT a transaction-based system. If you hold the right credentials (secret pieces of information) you are authorized to perform any transaction you want, at any time. Did you know merchants you transacted with a year ago still have authorization to perform transactions later, without your consent?
I want a transaction-based system in which I can perform transactions, and no informat
Re: (Score:2)
That's fine if all you ever use your card for is buying things in a shop, but some people want to use it for recurring payments, which requires the merchant to be authorized for future transactions.
Ideally I'd like to be able to restrict *how much* they can take in a transaction, but I really don't want to have to fill in my details eve
Re: (Score:2)
So you sign a recurring "not to exceed" transaction.
Re: (Score:2)
At least, that's been the situation for decades. However the consequences of handing billions to criminals is starting to have an effect. The criminals have billions in assets, and can leverage those for bigger and bigger forms of fraud, and they are.
Are the former criminals going into politics or actually just starting their own banks now?
Re: (Score:1)
So start Bill's Credit Emporium. Merchants will surely jump to work with someone who is willing to be liable for all transactions (or rather, force their other customers to be liable, whatever).
Re: (Score:2)
The amusing thing about CVV2 is that you have to tell it to any merchant you want to charge something with. If you do, it becomes worthless, and if you don't, it's worthless.
Re: (Score:1)
Your software can't be trusted to tell others how much money you have, so your information has to be backed by credible sources. The best-case scenario is this: These credible sources keep your funds both private and accessible. They give you a physical key to unlock your funds when making physical purchases, and a digital key to send to Internet applications. The physical key should be difficult to copy and easy to invalidate and replace in case of theft or loss.
Check writing still rampant (Score:3, Interesting)
Now I appeaciate that the US only recently moved away from Checks...
Moved away from checks? Hardly. Go to any grocery store in the US the day all the old folks get their social security checks and you'll see what I mean. Most bills still are paid by check despite the cost, inconvenience and inefficiency. Checks remain very heavily used in the US anywhere you go. Hell, Visa even has an entire ad campaign for their debit cards to try to get people to use the cards instead of writing checks. Visa wouldn't be bothering if checks weren't an incredibly common method of paym
Any advancement? (Score:2)
* very very very hard way to physically clone a CC/DC;
* very very very strong encryption in communication;
* user-changeable authentication and authorisation, so it won't be enough to have just a copy of the data printed on the CC sides to make a purchase on internet.
Anything else, will simply suck as far as "security".
Re: (Score:3, Informative)
*very very very hard way to physically clone a CC/DC;
Done. Chip and Pin (or EMV as it should be known) makes it pretty impossible without an electron microscope.
* very very very strong encryption in communication;
Done. EMV cards use RSA to encrypt comms between themselves and the bank. Nobody else gets to read it. Online purchases are down to your e-tailer and their setup. Check your browser security bar.
* user-changeable authentication and authorisation, so it won't be enough to have just a copy of the dat
Re: (Score:2)
Maybe in the USA you have those authentication and authorisation features, but in Europe the CC PIN is seldom required, you cannot change it and when purchasing online is never asked.
So, again, I would say that electronic payments need some real advancement both in technology and in architectures. In my opinion.
Re: (Score:2)
GSM/Sim cards and EMV credit cards are a different game. On the better (more modern) cards there is a cryptographic processor with its own set of private keys, that cannot be read off, that perform various authentication operations.
I used to work in EMV and I know what you can do with custom programmable cards and card reader/writers. Unless you have the card private key you cannot clone them.
"Maybe in the USA you have those authentication and authorisation features"
I thought we were talking about why smart
Re: (Score:2)
This is also the case in France, which had C&P years before us, and most other places I've been to in Europe.
There have been some well-documented cases of C&P hardware hacking, usually by replacing the C&P unit with a hard-compromised one - Shell petrol stations suffered from this, for example, but newer terminals are mor
Re: (Score:2)
Could people stop talking about Europe as if it was one place.
This is how it works in sweden:
You either use the PIN or you use signature+ID, some merchants slack with the ID check but afaik IANAL that makes them liable.
When making online purchases it works the same all over the world, you use your card number+CVC code, however my bank offers virtual master cards where you can specify the amount of money it should contain and for how long it should last so if you generate a card with $20 that lasts 1 month y
Re: (Score:2)
"Could people stop talking about Europe as if it was one place."
"When making online purchases it works the same all over the world"
Head asplode with irony!
Evidently not - a lot of places in the UK are now using Verified by Visa, a system that takes you off the vendor site to Visa (or your card issuer's) site to enter a password, so that they can authorise (or not) the transaction based on that.
Re: (Score:2)
It does work the same all over the world, Verified by Vista is a global program not UK specific. It's still rather rare AFAIK since I havn't seen it around much, then again I only use 2-3 different online merchants(World of Warcraft, Komplett.se(swedish version of newegg and datorbutiken.com(an alternative to komplett.).
Re: (Score:2)
I work in the credit card industry.
There has never been a single fraud case with a cloned EMV chip+pin card in my country, and as far as I know, in the world as well.
You can copy the magnetic stripe off the card, and clone a magnetic card; this is sometimes done, and if a merchant does not check the chip, then fraud can be performed; but then it's the merchant's fault and liability for not checking the cip.
So, no, you cannot clone a EMV chip+pin. If it could be done, then it would be done by someone, as the
Re: (Score:2)
Chip and Pin as you're flogging is NOT secure as you're claiming...
http://www.chipandspin.co.uk/ [chipandspin.co.uk] points out that one CAN be defeated, and disturbingly EASILY. Heck, the supposedly even more secure Passport RFID was breached recently and in a way that at least the bulk of the RFID readers for it can't detect the tampering.
Re: (Score:2)
"points out that one CAN be defeated, and disturbingly EASILY."
where?
Show me the page. I can't find it. It says the same that I said - fallback to stripe is a major weakness (though due to be phased out) and the more modern cards do onboard crypto (dynamic authentication) whereas older ones don't.
Their "Middleperson Attack" is ludicrously complicated and requires not only a lot of coordination but specialist equipment. Whereas the similar hack for mag stripe is for them to take a copy in ten seconds and use
Re: (Score:2)
In fact, that site's full of crap.
"Dispute Resolution"
They say that because it was known that mag stripe cards could be cloned the dispute process was easier. What they don't say is that EMV cards have not yet been cloned and the bank can tell if a cloned card was used with chip or stripe. So if you dispute a transaction now you have exactly the same rights as before and the bank are even more likely to know about it in advance because the only way to clone an EMV card and use it for online transactions is
Re: (Score:1)
* user-changeable authentication and authorisation, so it won't be enough to have just a copy of the data printed on the CC sides to make a purchase on internet.
They already have this, at least we use it quite a bit in Australia. The Verified by Visa opt-in allows end-users to set an additional password to be used for online purchases. I know Skype uses it and some other popular vendors whose names elude me right now (I work in the Online Banking team for a bank, you'd think I'd know them). Visa also use a cardholder-selected question/phrase which appears on the purchase form so they know it's an official VbV password request.
Re: (Score:3, Interesting)
very very very hard way to physically clone a CC/DC
Actually, at least in Europe, it's already pretty hard to clone a debit/ATM card well enough that a modern ATM will accept them.
Did you notice the catch? "a modern ATM". That's why criminals only need to clone the magnetic strip (trivial) and get your PIN (also trivial), and then they send the data to their buddies in Eastern Europe to withdraw money using the not-so-modern ATMs used in these countries.
Self assessment (Score:5, Interesting)
As a small company who has recently been through the self assessment procedure, I can say that the guidelines are very poorly designed in many cases.
For example, on the instructions page (https://www.pcisecuritystandards.org/saq/instructions.shtml) there is a link to SAQ Validation Type 1 form (A) and describe the type of applicant thus:
"Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants."
But in form A part 2c it states:
"Merchant does not store, process, or transmit any cardholder data on merchant premises but relies entirely on third party service provider(s) to handles these functions;"
By answering yes to this question, a merchant is saying that they will not transmit the details on (i.e from, to or within) their premises. This would mean that e.g. a mail or telephone operator could not *transmit* the card details to a third party service provider. i.e. they cannot use the PAN in any way (they *can* store it on paper - so orders by mail are OK), but the requirement very specifically says "Merchant does not ... transmit any card holder data on merchant premises". If I cannot transmit this information on my premises I cannot send it out to our service provider for processing etc.
This does not make logical sense. In theory, I could process payments via a PDQ machine directly connected to the phone line system and as the phone company is a "third party service provider" this could be argued to be compliant, but if I send it via e.g. an HTTPS website to an application hosted by our hosting company, this is technically going through our internal network before going through the wider internet (albeit encrypted via SSL) to our third party service provider. This is clearly "transmission on merchant premises".
I'm probably interpreting things quite pedantically (but isn't that what you're supposed to do with this kind of security thing?), but the guidelines and forms are riddled with these ambiguities and contradictions. :(
Re: (Score:1, Interesting)
Re: (Score:2)
Actually it does make sense; at least as much sense as the rest of the spec.
The third-party handling they are refering to is front-to-back order processing. The merchant only gets the actual order; at no point do they handle the credit card data. Lots of companies outsource their mail-order phone sales.
I definitely agree the spec is filled with ambiguities and contradictions though. Reading the article though I didn't see anything that should have constituted news to anyone in the industry. WEP has been kno
Re: (Score:2)
Yes, it is very ambiguous, I agree with you, just making a comment about this part..
Reading the article though I didn't see anything that should have constituted news to anyone in the industry.
At first glance I thought it was all basic, common, best practice security principles too, until you get to the encryption key management parts. We're basically limited to high dollar "enterprise" level encryption products which must scare the living sh*t out of SMB's. Requirements 3.4 to 3.6 are what I'm talking about. 3.4.1.a disallows the commodity encryption features built into your OS, 3.6 is automatically very expe
Re: (Score:1)
Re: (Score:2)
Exactly, that's for merchants who never see your card number (as it often is and IMHO should be).
The merchant (i.e., the checkout page on the website) forwards the transaction details (amount + description) to a 3rd party secure processor; customer gets redirected to that 3rd party site, and handles the card authorisation; and the 3rd party responds to the merchant 'OK, we got the money!'.
In that way the small merchants do not have to worry about properly securing card information, which is good, since I ca
Is it a stick or a carrot and for who? (Score:2)
PCI was set up as an attempt to get merchants that don't care about security to consider it with out it being too hard and forcing them away from card payments. They pretend to have no conflict of interest yet the only way to get certified is by proving you do have a conflict of interest. Many of the ideas for standards tends to be controlled by people who want to micromanage how things are done (which means you can use their product). Some of the ideas tend to get implemented poorly just in a way to be
Ugh... I can hardly wait for 1.2 (Score:2)
PCI really seems like a good idea, gone wrong.
It's getting more and more expensive and convoluted to abide by if you have to do more than the self-assessment. All the while, quite a few companies skirt by dangerously by faking it or lying.
It seems like we might all be a little safer if they toned the requirements down a bit in a few areas, but beefed up the auditing requirements on the fundamentals.
a/v for linux (Score:5, Funny)
For instance, it clarifies that all operating systems associated with card processing have to run antivirus software, while many had thought this was only about Microsoft Windows.
great, now I have to run ClamAV on all my fully-patched and secured dedicated web servers that don't store CC data anyway. I thought about writing my own AV program:
#!/bin/sh
echo "scanning for viruses..."
sleep 10
echo "no viruses found."
exit 0
Re: (Score:2, Funny)
Re: (Score:2)
#!/bin/sh
echo "scanning for viruses..."
sleep 10
echo "no viruses found...no false positives."
exit 0
Re: (Score:1)
Completely off topic:
Thank you for posting a joke in code. Seriously, Slashdot is becoming overwhelmed with car analogies and yelling that I want to be able to mod -1 insufficiently nerdy.
Re: (Score:1)
Enterprise-grade AV software is supposed to consume all CPU time. So improve:
#!/bin/sh
echo "scanning for viruses..."
yes >/dev/null
Antivirus requirement (Score:4, Interesting)
From TFA:
For instance, [the PCI revision] clarifies that all operating systems associated with card processing have to run antivirus software, while many had thought this was only about Microsoft Windows.
"That sounds like a sensible piece of advice," says Sushila Nair, product manger at BT, who says organizations often deploy antivirus on Windows but erroneously believe Unix and Macs and other operating systems are somehow more invulnerable. However, she notes accommodating the clarified PCI rule on antivirus in many places will be "expensive."
So what would constitute compliance with this rule? Is running periodic ClamAV scans on my Linux server sufficient? Will saying that I have ClamAV installed on the audit form be sufficient to comply with the new rule?
This change seems to have as much to do with protecting the Windows franchise from erosion by *nix systems (in the name of "levelling the playing field") as it does with security. Not only does it ignore the very real differences in security among the various platforms, but it makes selling a Windows solution to upper management much easier than selling Linux. Of course a system with a Windows server and Norton or McAfee will pass muster. Linux+ClamAV? Who knows?
Re: (Score:3, Interesting)
I nearly had a stroke when I read that but thankfully it's a bad summary, The requirement is for machines "commonly affected by malicious software"
So my back end Linux servers will still not have AV software.
I'm not even sure why such a stupid rule even applies to windows really. A well maintained windows server should be safe from viral infection as long as it's not used for web browsing, email or file sharing. In other words nothing you would use a back end credit card processing server for.
Re: (Score:2)
I know the previous version specifically mentioned UNIX systems are not commonly affected by viruses in a footnote..
Still, it's pretty clear what they mean, I don't know why everyone was going crazy about this. They certainly didn't clarify it mean it includes UNIX (or -like) systems.
ah, from the summary of changes..
5.1 5.1 Requirement & Testing Procedure: Clarified
requirement applies to all operating systems types
Re: (Score:3, Interesting)
You can find a better summary here: http://pcianswers.com/2008/10/01/pci-dss-version-12-differences-and-updates/ [pcianswers.com]
Re: (Score:2)
At my company the security guy was also a bit apalled by this if you decide to get literal(we have been audited and passed against PCI). What about routers? Do we need to run a virus scanner on the "servers" running IOS or JunOS?-) There isn't really THAT much difference between a Unix box and IOS box even if the latter ones usually have a bit more specialized hardware for processing network packets.
Re: (Score:2)
However, she notes accommodating the clarified PCI rule on antivirus in many places will be "expensive."
So what would constitute compliance with this rule?
Most commercial AV products are also available in Linux versions because plenty of Linux systems have to interact with Windows and could become transmission vectors, even if they're not infected themselves.
This is certainly true of Sophos, McAfee and Symantec Enterprise.
The only minor problem is that they often offer realtime scanning and are therefore very distribution-specific because the only way they can do this is by hooking into the Linux kernel to intercept filesystem calls.
Re: (Score:2)
Or they could just use inotify, which has been present on every distro I've used in the past few years.
I guess that would make a little too much sense for an anti-virus vendor though.
Re: (Score:2)
Last time I tried using inotify it slowed the system down unacceptably - possibly because it was an IMAP server with maildir mailstores so it was dealing with notifications for thousands of files. This was a few weeks ago on Debian Etch.
Re: (Score:2)
PCI came form SETCo's specs (which I was involved with) and they still haven't caught up yet. The original idea is you need to run something like tripwire on your Unix systems and anti-virus stuff on your PCs and Macs (OS 10 didn't exist at that time). If your Unix systems are processing mail or file transfers and you have the ability to run anti-virus on the mail then you should. The idea was not to run Norton AV on your Unix OS.
Re: (Score:2)
Great, another monoculture (Score:2)
Anyway, monoculture is bad, mmkay. Not saying I have a nice pre-packaged solution with a pamphlet and everything....
No biggie (Score:1)
Should really be government regulated (Score:1)
Imagine if each bank/company could issue their own cash. They would each print their own denominations with different security features... it would be a mess.
So why doesn't the government regulate 'e-security'. At the very least, it should take opinion from the IEEE or something to guide the industry.
I'm still amazed we don't have chip cards.
Anywhose...
PCI doesn't provide actual security (Score:3, Interesting)
PCI is all about encrypting credit card numbers and expiry dates - and nothing else. Even a fully-PCI-compliant system is a rich source of unencrypted information for Identity Theft.
Although the PCI security standards recommend to companies that they do criminal history checks on suspect employees working with credit card data (and a company I worked for, claiming PCI compliance, had a compulsory criminal history check on the first day for *all* employees even though they were working nowhere near credit card data) it still doesn't address some of the weakest links: the human operators and the GUIs that they use.
I recently closed a Buyers Edge credit card, operated by GE Capital Finance in Australia. I couldn't supply the "account password" to the telephone operator on one call, but after supplying other identifying information the operator was able to READ MY ACCOUNT PASSWORD BACK TO ME. What's up with that: displaying the password for the account in clear text on the screen? Why aren't they encrypted? Why don't they have an input to type potential passwords in to that says "Yes it's right," or "No, it's wrong"? There's nothing stopping employees from snooping through customer records to gather saleable information for the Identity Theft market.
The only good thing I can say from my experience is, "I'm glad my credit card with them is closed."
Re: (Score:2)
Hell no. You don't know what you're talking about, read the PCI-DSS before even thinking about replying to this.
They make it pretty damned clear what the intent is, and what's tested.
PCI is all about encrypting credit card numbers and expiry dates - and nothing else. Even a fully-PCI-compliant system is a rich source of unencrypted information for Identity Theft.
For one thing, identity theft doesn't really enter into the equation here. For example, other identifying features like US social security numbers are not mentioned, or even relevant here. It also has nothing to do with preventing people from fraudulently signing up for credit cards in other people's names. This is about pro
The PCI one-size-fits-all mentality (Score:1)
I have the job of assuring PCI compliance at my company. In July the PCI rules changed and some of our systems suddenly became non-compliant as reported by our scanning service.
The two issues were:
1) we ran identd
2) we ran anonymous ftp
The problem is that just the existence of these services is a PCI violation. Even though it is possible (and we do) to configure these services securely.
For identd, the "threat" is that it will leak information about user accounts. We run the liedentd daemon