Slashdot Mirror

How are you defining "encryption at rest"? The term isn't defined in PCI DSS.

3.4.1 is about whole disk encryption, and your statement "Decrypt what you need and leave the rest encrypted" is vague. Whole disk encryption reads and writes encrypted data. The active memory has the encryption key, nothing which isn't being actively read into RAM is decrypted.

https://www.pcisecuritystandards.org/pci_security/glossary

Depends on what procedures they adopted. If it was something like the PCI standard they likely could have followed everything, well except the part about not retaining sensitive information, and still gotten hacked. The PCI standard is the bare minimum that should be followed but is something written for MBA types so it has checkboxes that give you a warm fuzzy feeling. It does offer some protection but there are better standards but these are harder and require actual thought. Also if they were reasonably intelligent they would have implemented some well known system benchmarks but those can be inconvenient for people who want the keys to the kingdom. Given what has happened I would guess they implemented the parts of PCI that didn't deal with personal information and called it a day.

Personally, even if they were using PCI, I would love to see them get browbeat because there are better standards, such as the US government's NIST Special Publication 800 and/or 1800 series, the NERC CIP standard, the Cybersecurity Procurement Language for Energy Delivery Systems document. If those weren't enough there are other well respected ones out there as well to choose from. If a business, especially a large one, isn't required to be covered by one I would suggest looking at all of them and make rational choices out of each of them. If a business is required to follow one fully implement that but then still pull from the others to go beyond and then get regulators to scrutinize competitors who are lacking.

Probably except for the part about not storing personal information but then they aren't card processors. The PCI standard while it is a standard is really the bare minimum that companies should be held to for them to not be found guilty of criminally negligence for breaches. The actual standard is here and having had to deal MBAs asking about our compliance makes it seems like it is something written for the MBA types to check off a bunch of stuff. There are much better standards and if you aren't an MBA you can figure out how to make them applicable to your business. Personally I like the NERC CIP standard with liberal utilization of the CIS benchmarks as a good starting point for securing a system. If you want others there is always the US government's set of security benchmarks, the DoE document Cybersecurity Procurement Language for Energy Delivery Systems, or a bunch of stuff at the SANS site that you could use as a guide.

Depends on the industry. The companies that handle the bulk electric grid in the the US and Canada do have rules and regulations covering their security. While not quite as strong companies handling payment card information also have some rules but they don't come backed with the force of law.

You'd probably be surprised just HOW vulnerable most of the world's critical infrastructure really is.

Concerning power grids, no I wouldn't and people in the US and Canada would actually be surprised how well protected the bulk electrical system is here when compared to what is reported. Even small operators like to follow the security requirements that the large ones have to even if they don't as it does allow them to say that they are following the industry best practices which is a good CYA from lawsuits. Other countries are a different story and vary greatly but even those who hadn't cared much before are coming around after the Dec. 23, 2015 hack of the Ukranian grid caused a lot of European companies to collectively shit themselves.

I'll just leave a few things here for you. In the US and Canada those are either the regulations for cyber security of our power grid or specific requirements being written into contracts for new control systems for our power grid. All of them have to follow NERC CIP with the the other 2 being optional but widely used as a CYA. The Europeans do not have such requirements and it varies from country to country but those that do have regulations they are often very far behind even previous version of NERC CIP. That is not to say that those make you secure but they do offer a good start and following any one of those documents would provide more security than the preferred PCI DSS standard that everyone outside of power grid world thinks is great and the be all end all.

To be fair not all SCADA systems are as unprotected as you would imply but they are not the fortress for security one would hope. In North America there is the NERC CIP standards that need to be followed for grid operators which are a good start and should be approachable for most /. readers. The nice thing is that NERC has teeth and fines can be huge (I believe up to $1,000,000 per violation per day of non compliance) The NERC CIP standards go a whole lot farther than the other major standard that is mentioned often in these discussion which is PCI DSS which seems to be written more for managers who like check boxes. Another consideration is the Cybersecurity Procurement Language for Energy Delivery Systems which is being picked up by a number of organizations as a set of requirements. Then there is always the reasonable and prudent CIS Benchmarks for the OSes and software you are running. I do think that a lot of SWIFT operators think that something like PCI DSS is good enough but it isn't.

Well usually an insurance company would require a SOC-1 or SOC-2 report to issue a policy but they are still under the belief that those magic pieces of paper are proof that you are secure but are really a joke. I mean you can negotiate with the company generating the report (large accounting firms usually do it) and they tend to not really know how to secure a system but are really good at seeing that you have the right checkboxes checked. You have AV on your systems check (not up to date), you have a firewall device check (not configured), you don't have lime wire running check, etc. The basic check boxes they follow are probably the ones layed out by PCI DSS which is a fucking joke of a standard.

As we all know this was worked around more than a decade ago and all browsers save an ancient Safari outlier are not vulnerable to it.

Yes, but due to the CVSS score, using CBC based ciphers in TLS 1.0 is a fail. Sure, the risks have been mitigated and they are good to use, but you can't if you want to be PCI compliant.

We all know that cipher suites can be turned on and off independent of TLS version.

Yes, but if you turn off the RC4 ciphers and turn off the CBC based ciphers in TLS 1.0, there are no TLS 1.0 browsers that have a compatible cipher. This results in TLS 1.0 browsers no longer working in such a configuration. Hence the problem here.

I would love for someone to provide a reference where in PCI a CVE scoring regime for PCI compliance is even mentioned.

Here you go - Page 22

"With a few exceptions (see the Compliance Determination—Overall and by Component section below for
details), any vulnerability with a CVSS base score of 4.0 or higher will result in a non-compliant scan, and
all such vulnerabilities must be remediated by the scan customer. "

Regardless these problems are not vulnerabilities when you turn off a broken cipher suite and implement workarounds having existed for more than a decade.

Sure, not vulnerabilities, but still a PCI fail due to the NIST CVSS scoring, which is the point here. (Bureaucracy)

I have vague memories of people trying this nonsense but it didn't last long.

Earlier this year when I was researching this, there were very many financial sites that used RC4 ciphers. They had no choice but to do this if they wanted to support TLS 1.0 browsers AND be PCI compliant.

Curse you NIST... or NASA or GEOINT or KGB or whoever for a completely broken chain of incoherent nonsense.

Indeed.

My personal opinion this is a CONSPIRACY.. more trivial work / check boxes for the Nessus button pushers to run while they abstract absurd amounts of cash from their victims.

Not so. I was there when this came about. In fact, I kinda seeded the notion that this had to be dealt with by fixing the CVSS scoring with the NIST. I was just frustrated with the problem and wanted to find a 'correct' fix. But it blew up as explained previously - damn you, NIST.

Here is your publication of what is "secure" - https://www.pcisecuritystandar...

Point of order: PCI compliance demands that you do *not* store customer CC data unless absolutely necessary (mind the PDF, Henry).

On the other hand, the company is based in Canada, and I'm not sure what their data retention laws may entail. Since the company is pre-IPO, they may have aligned their policies to the Canadian equivalent of SOX (if they have one), but otherwise I don't see much demand to store the CC info for any legit business purpose.

The Open Web Application Security Project website is a great place to start browsing from, to investigate both pen testing and secure development.

I would also recommend getting some familiarity with the PCI DSS standard. It is aimed at companies involved in online payments (and a bitch if you have to prove compliance.) However when used as a descriptive framework rather than a prescriptive one, it's great foundation for planning a company's IT security aspect.

I'm sure there's a bunch of other security standards for other industries that could be used in much the same way. A good security consultant should at least be able to name check them.

It is very illegal for a merchant to store your credit card number for more than the 5 seconds it takes to authorize the transaction, unless they implement fairly strong protection to make sure nobody can steal those numbers later. But even if they do this, it is still very illegal for them to try to share those card numbers and what they purchased, which would be necessary for different merchants to "track" your purchases.

You seem to have a pretty good understanding of the topic and I'd like to expand upon it. I've worked with several payment processors and been involved with many systems which handle credit card data and PCI compliance has very a specific definition (expanded, see also) about what card holder data is. Your first and last name, billing address, expiration, last 4 and the card type are not card holder data. Plenty there to "track" legally without touching the PAN (Primary Account Number). That said, I have no desire to see CurrentC implemented.

This doesn't even really touch companies like Acxiom. Here's a little scoop on the whole data broker thing for those unfamiliar with the scope of collection.

If you are going to be working with credit cards then read NOW and not later the PCI-DSS (Payment Card Industry - Data Security Standard) standards and follow them, or the company could be liable to penalties from your financial institution. Firewalls are indeed mandatory, as is proper documentation, management and review of the firewall rules.

Download PCI-DSS v3.0 here: https://www.pcisecuritystandar...

You need to look at the PCI-DSS requirements because this is what dictates the security standards of your network if you are storing credit card information. Specifically PCI-DSS dictates (not your contract) that there needs to be multiple levels of firewalls. Ergo you will need a firewall in front of the web server. You will then need a separate firewall in front of the DB servers. And the preferred setup is a three or more tiered system. Web server with firewall connects to the Application (WCF / web service server) which also has a firewall, which connects to your database server which also has a firewall. Also note that I am referencing hardware firewalls such as a Cisco ASA or a Dell Sonicwall. The servers should also have their own software firewalls enabled whether it's Windows Firewall or Linux IPTables. With that said we are "supposed" to be PCI-DSS compliant and should be for the sake of liability (and doing it the right way). Unfortunately I know many vendors who don't want to spend money on proper setups and run very insecure systems. If you can avoid it don't work for these people and go find a client that has the budget to do things right. PCI-DSS: https://www.pcisecuritystandar... A better option for a cheap client is to not store any customer data and use a tokenized system. Authorize.Net will store all sensitive data for an extra $10/mo and allow you to skirt PCI-DSS regulations. You should still run a firewall though and be as close to PCI-DSS as possible though. http://www.authorize.net/solut...

PCI/DSS isn't simply about being able to claim nebulous adherence to "best practices"; it's about an organization's ability to maintain a business relationship with their customers and an upstream merchant account provider under certain agreed upon minimum standards for data security. Quoting PCI Data Storage Do’s and Don’ts:

Do not store sensitive authentication data contained in the payment card’s storage chip or full magnetic stripe, including the printed 3-4 digit card validation code on the front or back of the payment card after authorization.

This point in particular is not flexible in nature. Storing that specific information, or failing to take specific steps to secure the access perimeter and specific systems through which said information traverses, are quick routes to termination of a merchant agreement. Such failures may also expose a business to significant legal liability; litigation rapidly becomes impressively expensive in the event of a breach whereby it comes to light that the business in question failed to follow basic PCI/DSS tenets, and said legal proceedings may turn into an even greater circus if dominant upstream EFT players such as Visa, etc believe there is reason to assume negligence on the part of an auditing firm that supposedly delivered a satisfactory report on compliance to the errant business. Reference the recent Target debacle for a fine example of such complications.

There are no magic bullets, but there are baselines. Those baselines could certainly use significant improvement, but that doesn't matter much if the business servicing the consumer doesn't care to consider even basic adherence to agreed upon information security standards as a critical factor.

Not really. Chip might be kinda easy to read using commodity hardware, but pin entry must be done through a PCI certified device (as in, lots of money for certification, passed on to you, the consumer)

https://www.pcisecuritystandar...

No support for chip&pin (EMV) yet, so this may have limited utility outside of the USA. They expect to start shipping in summer of 2014."

Considering that all US merchants have to be capable of using EMV[1] by October of 2015, perhaps that two year battery life is about right, because that's all the longer they will be useful. And most merchant services are pushing hard to have everyone capable of taking EMV by the middle of 2014.

Mag strip cards will be around for as long as the current ones out there last, but most new cards being issued now are EMV capable, and very soon, all of them will have to be. Without EMV support, this is, at best, a short term fad. And eventually, mag strip cards will just disappear, and merchants will have no reason to be able to take them.

[1]Technically, not required to stop taking mag strip only, but those who don't become 100% responsible for all fraud, automatically, regardless of the circumstances. As a carrot to go with the stick, those who get EMV up and going are not longer resopnsible for the sometimes pain-in-the-ass (and often expensive for small operations) requirements for PCI compliance.

When are corporations going to be held responsible for the security of their customers' information?

It used to be that companies really feared being out of compliance with PCI standards but things must have changed. I don't know for certain but if I had to venture a guess, companies probably find it more appealing to take chances being non-compliant rather than invest in appropriate infrastructure (including competent staff) to support full PCI compliance .

It's *extremely* difficult to sell proper security to management based on potentials. They want numbers to plug into their spreadsheets to measure cost vs. benefit but when you are working with a gradient like a compromise those numbers fall anywhere from 0 to infinity depending on the depth of the compromise (think Stuxnet) and what assets are at risk (adobe Photoshop source code). For those reasons, many companies only implement the bare minimum and hope for the best.

The payment card industry negotiates rates based on many things, including what your card handling practices are, if your entire network and organization is PCI compliant, volume, average transaction size, etc.

For example, I work for a company that does about $100B in retail revenue annually. Our holy IT mantra is to not do anything that even remotely would run afoul of the PCI audit, because losing certified compliance would cause the transaction fees to go up, which is literally a billion dollar mistake.

I'm going to assume that this is a serious question, if slightly fuzzily worded. And that what you want is the best security position that is practical, and still have a computing environment that is useful to you.

So this is going to draw some fire I suspect, but maybe start by reading the PCI DSS Data Security Standard and apply as much as possible of the practical stuff to your environment.

PCI DSS has its issues and its critics and is most definitely not perfect. But it is an attempt by a group comprising of all the major credit and debit card brands to define how to secure a computing environment that is connected to the internet and contains sensitive information.

A lot of it won't be relevant to you. But if you're not trying to achieve compliance, you can throw out the bits you don't need.

Because there are absolutely no industry standards for security. Oh wait, yes there are.

You might want to start here:

https://www.pcisecuritystandards.org/

There are reasons why a business has to upgrade. XP is 10 years old now, and in another two years (April 2014, IIRC), Microsoft will stop issuing security updates (and they seem to really mean it this time). Anybody who accepts credit cards is required to be PCI Compliant, and that means you stop using an operating system when it no longer gets patches. And if you have a lot of machines, two years isn't a long time to plan and deploy new boxes (and in all likelyhood, the XP machines are old enough they really should be replaced, not just upgraded).

If you don't maintain PCI compliance, you are 100% resonsible for all costs assciated with a breach, every last penny of the $100-1000 per card number stolen. This can easily put even a healthy company out of business.

From the PCI Security Standards Council "PCI Data Storage Do's and Don'ts":

Do not store any payment card data in payment card terminals or other unprotected endpoint devices, such as PCs, laptops or smart phones

And

At a minimum, PCI DSS requires PAN to be rendered unreadable anywhere it is stored – including portable digital media, backup media, and in logs.

Based on that information, I would say that PCs and, certainly in this case, game platforms (since the Xbox is really just a PC) would fall under the "endpoint device" category. Especially since the end-user has no control over whether or not that information is stored on their device because only Microsoft can alter the code that allows or disallows the storage.

The difference is that Ford doesn't head up a cabal of auto makers that hand out outragious fines to those who handle said cars insecurely.

Here, since you obviously don't realize what PCI means in this context.

Just maybe it'd be a good idea to link to the organization and define what the Payment Card Industry security standards are. This sounds like an issue with non-compliance. If it's a large enough scope, offer to lead a team to correct the problem before it becomes a liability. If not, mention it to those responsible for operations and legal. Both will appreciate not being fined.

Just maybe it'd be a good idea to link to the organization and define what the Payment Card Industry security standards are. This sounds like an issue with non-compliance. If it's a large enough scope, offer to lead a team to correct the problem before it becomes a liability. If not, mention it to those responsible for operations and legal. Both will appreciate not being fined.

Investigations after compromises consistently show common PCI DSS violations, including but not limited to:

Storage of magnetic stripe data (Requirement 3.2). It is important to note that many compromised entities are unaware that their systems are storing this data. I could find Requirement 3.2 but I'm pressed for time right now.

Read the all the docs here:
https://www.pcisecuritystandards.org/security_standards/documents.php?category=saqs

Make sure you're right before you tell other people they are wrong.

Investigations after compromises consistently show common PCI DSS violations, including but not limited to:

Storage of magnetic stripe data (Requirement 3.2). It is important to note that many compromised entities are unaware that their systems are storing this data. I could find Requirement 3.2 but I'm pressed for time right now.

Read the all the docs here:
https://www.pcisecuritystandards.org/security_standards/documents.php?category=saqs

Make sure you're right before you tell other people they are wrong.

Yep. That's called a reference transaction. Someone needs to go do some homework before continuing to accept credit cards.

Like most other "too big to obey rules" companies Valve just ignores PCI standards of keeping credit card information. PCI standards require that adherents not keep credit card information in a digital format, making it impossible to steel. Of course Valve can't be bothered to allow the annoyance of filling out a credit card form to break the urge to buy their [another persons] software. Now if you've ever used steam your credit card data is most likely compromised.

It sounds to me like they don't have a clue how many servers were compromised so I'll just go ahead and assume the hackers have the encryption key for the CC data and salt for the hashes. Now a simple rainbow table is required and then the hackers have your password/email - hope you don't use the same password on your banking site! Valves way of saying "thanks for using Steam".

All my cards already got compromised. Whee. I think some merchant somewhere was doing exactly what the PCI-DSS council says not to do.

Fortunately they all have 'zero liability' - wonder how long that will last? In my case, the best the hackers got were deactivated card numbers and a password that just became useless.

If you intend to process credit card payments through your custom application on the point-of-sale device, you'll likely fall under the purview of the Payment Card Industry's Payment Application Data Security Standard (PCI PA-DSS), which may require a source code audit and limit what you can have the software do. That may be no problem for you depending on your resources and intended use of your software, but it's worth keeping in mind.

They're facing a catch-22 critical mass problem. There have to be enough places that accept this for consumers to get on board, but retailers aren't going to spend money on new hardware and software to accept a fringe payment system that hardly any consumers use. Remember all the excitement about RFID in credit cards a few years ago? I've got two cards with them, and the only places I get to use this feature are CVS, Chevron and McDonalds, and most of the time the cashier tells me the system isn't working so I have to slide my card anyway. The major credit card companies were pushing this, yet the few retailers that bought into it can't be bothered to maintain the hardware. They already spend a lot of time, effort and money just keeping up with the requirements of the payment card industry (PCI), which is essentially MasterCard, Visa, AMEX, Discover and JCB. PCI has extraordinary power to dictate what retailers must do and sets deadlines for them to do it, but even they couldn't effectively push the move to RFID. Unless PayPal is offering an attractive, secure system that costs far less than the PCI alternatives, retailers will tell them they should be content with having PayPal-branded credit cards from Visa or MasterCard.

Then there are the little problems of PayPal living in regulatory limbo because it's not a bank, and the fact that many people distrust PayPal because of its attitude that it can do practically whatever it wants without accountability because it's not a bank. But the catch-22 problem makes these seem like minor issues.

I'd say this article is just wishful thinking on PayPal's part. "PayPal CEO Says he Wants to Supplant Trillion Dollar Credit Card Industry, and He'd Like A Diamond-Encrusted Flying Pony. Film at 11!"

RSA keys are compromised, Sony gets compromised, and meanwhile the bankcard industry continues to come down hard on independent retailers to force them to bring their internal systems into PCI compliance. I know small retailers that have invested tens of thousands to secure their WiFi, update their firewall, upgrade their debit pads, all to protect cardholder data. Seriously, what criminal is going to target Joe's Hardware Store to snag a few hundred bankcards? These guys want the big targets. As Willie Sutton didn't say, "That's where the money is". Criminals are going to aim at the top of the food chain, not at the mom and pop store. And even if they do hack the mom and pop store the damage is minimal compared to an RSA or Sony breach.

Get the documents. Have you and your host assess your setup.

https://www.pcisecuritystandards.org/security_standards/index.php

Also have security scan firms run scans of your site.

PCI/DSS standards clearly dictate that all customer data, when "at rest" (i.e. on disk, in a database, etc.) needs to be encrypted: https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf: "Do use strong cryptography to render unreadable cardholder data that you store, and use other layered security technologies to minimize the risk of exploits by criminals" That Sony (and all the other businesses and institutions that have been hacked, left laptops to be stolen, etc.) doesn't do this is inexcusable. Had this data been properly encrypted, it would have been unusable to anyone. It's trivial to incorporate this encryption as a part of the design.

You probably ought to read up on PCI DSS then. Start here:
https://www.pcisecuritystandards.org/merchants/index.php

The bank maybe doesn't audit you, but in this country they will demand certification from a QSA, and those guys will audit you because they're liable for your fuck-ups if they sign you off.

PCI

I thought all business that deal with CC transactions must be within a secured network. In fact, there's even PCI guidelines on recommended settings to secure your WiFi access points. Unless business are using WPA/WPA2, shouldn't they be busted for not adhering to PCI security protocol? I've included a link to a PDF below for anyone interested.

https://www.pcisecuritystandards.org/pdfs/PCI_DSS_Wireless_Guidelines.pdf

I have gone through this all as well. The grand parent either really sucks at their job, or is just lying out their ass. You are NOT supposed to store credit card numbers from mag stripe, and if you are ever audited for PCI compliance and they find out that you are storing them, you will be shut down.

"There is no need, nor is it allowed, to store data from the magnetic stripe on the back of a payment card."

http://www.pcicomplianceguide.org/pcifaqs.php#myth16

You can also take a look at page 15 in this document https://www.pcisecuritystandards.org/documents/pci_ssc_quick_guide.pdf which clearly states that you are NOT allowed to store magnetic data. Period.

Its industry "illegal" because you will not be able to take credit card numbers if you do this. So effectively, its like the bank is shutting you down and blacklisting you. You are playing a semantics game maybe but semantics are not going to save your sorry ass.

If that were only true,
PCI actually states that requirement only applies when the data is sent over an OPEN or wireless networks.

I don't know many that would be using HTTP over the internet, but the clause exists to say that if you do all data must be encrypted. This is to protect against siffing and hijacking, but your broad assertion that everything needs encrypting is actualy a small corner case.

Most of these devices are not running wireless or route over the internet without some form of an encrypted tunnel(think 3DES router B2B connections)
Plenty small mom and pop shops also do direct modem dial ups, but the devices effectively also encrypt the temporary pipe.

For private PCI compliant networks requirements exist to encrypt a smaller subset of data including the following;
Cardholder Data defined as: (All can be stored, but the PAN must be stored in an unreadable format)
- Primary Account Number (PAN
- Card Holder Name
- Service Code
- Expiration Date

Data which Must never be stored and must always be encrypted is defined as follows:
  - Full Magnetic Stripe
- CAV2
- CVC2
- CVV2
- CID
- PIN
- PIN Block

And Lastly
PCI requires operators "Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).
And have a security policy which states that "unprotected PANs are not to be sent via end-user messaging technologies." with or without encryption.

See Pages 8, 35, 36, PCI 2010 version 2.0 at https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

If you have credit card numbers stored on your webserver, I know some folks who would love to have a few words and/or fines with you.

You must have missed the all the articles about credit card info being stolen (just the first one I can think of) or never received one of the many notices going around saying, "You've been issued a new card number because of a data breached that may have affected your account" yet. Also, PCI compliance (which is what you are think of) doesn't require all information to be removed. Here's the actual overview if you want to know.

As an owner of a small business I can't imagine leaving our WiFi open. In addition to PCI requirements to protect credit card data it just doesn't make sense to leave your network open. Would a business install a network hub on a wall outside their building? As far as "managing" the wireless network, if the business has nobody that can implement a simple password protection scheme then they probably should not be maintaining their own network in the first place. Odds are they'll wind up with compromised servers spewing spam and malware, and infecting people that hop on to their open wireless network.

Just get out the manual and fix your open access points.

Well, there is a voluntary consortium of credit card firms seeking to enforce a standard for firms that process/store customer credit card information:

The PCI Security Standards Council is an open global forum for the ongoing development, enhancement, storage, dissemination and implementation of security standards for account data protection.

The PCI Security Standards Council’s mission is to enhance payment account data security by driving education and awareness of the PCI Security Standards. The organization was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa, Inc.

False.

You are permitted to store the information long enough to get authorization from your processor. You are permitted to transmit the data if it's encrypted. The encryption must meet the standards defined in the PCI DSS 1.2 appendix.

Look it up: https://pcisecuritystandards.org/

Was this supposed to be moderated Funny?

If you focus on the high-level requirements, it is certainly easy to take them out of context.

Quoted from the PCI document [1], "Malicious software, commonly referred to as âoemalwareââ"including viruses, worms, and Trojansâ"enters the network during many business approved activities including employeesâ(TM) e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats."

Is Linux commonly affected by malware? No auditor is going to expect UNIX servers to have anti-virus software installed.

Item 6, "Ha!" ... nevermind the multiple detailed requirements under the high level bullet.

PCI is fantastic. It allows IT departments leverage to implement sometimes costly best practices that companies prefer to consider cost centers.

I'm still hoping you're just trying to be funny.

[1] https://www.pcisecuritystandards.org/security_standards/download.html?id=pci_dss_v1-2.pdf

PCI is crap, because it's only really meant to be a way to cover your ass if something goes wrong. I see you skimmed the headlines of PCI compliance, and a lot of it is either just common sense or plain bullshit.

1.4 Install personal firewall software on
any mobile and/or employee-owned
computers with direct connectivity to the
Internet (for example, laptops used by
employees), which are used to access the
organizationâ(TM)s network.

There are a lot of points about making sure as few people as possible has access to the card data environment, but still they slap on this. I'm sure your PCI auditor can sell you such a software if you don't already have it...

5.1.1 Ensure that all anti-virus
programs are capable of detecting,
removing, and protecting against all
known types of malicious software.

My absolute favourite. Never mind that anyone familiar with computer science can prove that it is impossible to construct such an anti-virus program ever, you still have to check this box and claim you ensured this. I'm sure there are more points in the specification that are 100% bullshit that others can find:

https://www.pcisecuritystandards.org/security_standards/download.html?id=pci_dss_v1-2.pdf

I believe it is one of those overblown exaggerations by the developers. It's sort of like when they claimed the program wouldn't run in windows 2000 and the installer refused to run if it detected 2000 yet it worked perfectly fine in XP pre SP1. I was able to trick it into thinking it was running on XP pro by changing some registry settings and temporarily replacing a couple DLL for the install.

Your probably right in that there is no technical need to it to be the default. Some reports won't display if it isn't and some other functions will not work properly. Quick books isn't the only program like that either. I can't name the name of the other one I have personal experience with because the last time I did in a public forum, the consultants setting it up who were never named in my post sent lawyers to my employment threatening a lawsuit if I wasn't fired. Of course neither happened because I never said anything not true or named them at all. Anyways, it used MAPI calls to connect to outlook and even after finding every call and having them implemented into a different mail/messaging program, it didn't work because they specifically checked for outlook to be the default and if it wasn't it automatically threw an error.

There are several programs like this. I have heard the stories from others and witnessed them myself. The problem with contacting the manufacturer is that they know I have no power to return their $30,000 program and the sales guy will just claim I don't know what I'm doing.

Speaking of that, I literally had a credit card processing company (sales person) claim my network was screwed up at a site because I used an internal proxy server connected to a IPTables firewall that scanned all downloaded files and email attachments for viruses on the fly as they cam in as well as blocked most porn and gaming sites like pop cap games and so on.

And when I showed him the PCI data security standard from the security coalition that recommended using a proxy for the computers doing the processing, he told me I was reading it wrong. I think what shut him up was when I was looking over some packet captures attempting to find where the software was failing, I noticed the card information was being transmitted in clear text. That quickly got me in touch with one of their developers and the owner/president of the company. That problem was taken care of but to date, their software still doesn't run properly behind a proxy server. I had to punch a hole through it with another server and restrict all traffic except three ports to two different URLs. Their unwillingness to change the program was due to needing another security audit afterwords even though they clearly failed the first audit with the clear text communications. And again, if it the company I worked for was already invested to the sum of $20,000 in other (rental management) software so changing providers wasn't really an option and they knew it.

Some things just amaze me.