Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Book Reviews Books Media

PCI Compliance 115

Posted by samzenpus from the read-all-about-it dept.
Ben Rothke writes "It has long been rumored that manufacturers of items such as razors and batteries specifically produce their products to an inferior level in order to ensure repeat business. A similar paradox is occurring in the information security space where many are complaining that the PCI Data Security Standard (PCI DSS) is too complex and costly. What is most troubling is that such opinions are being written in periodicals and by people that should know better." Read on for the rest of Ben's review.
PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance
author Tony Bradley
pages 352
publisher Syngress
rating 9
reviewer Ben Rothke
ISBN 1597491659
summary Great for anyone who has PCI responsibilities or wants to gain a quick understanding of the PCI DSS requirements.


PCI came to life when Visa, MasterCard, American Express, Diner's Club, Discover, and JCB collaborated to create a new set of standards to deal with credit card fraud. PCI requires that all merchants and service providers that handle, transmit, store or process information concerning any of these cards, or related card data, be required to be compliant with the PCI DSS. If they are not compliant, they can face monetary penalties and/or have their card processing privileges terminated by the credit card issuers.

The primary purpose of PCI is to force organizations to embrace common security controls to protect credit card data and reduce fraud and theft. The following are the six primary control areas and 12 specific requirements of the PCI DSS:

Build and maintain a secure network

1. Install and maintain firewall configurations

2. Do not use vendor-supplied or default passwords

Protect cardholder data

3. Protect stored data

4. Encrypt transmissions of cardholder data across public networks

Maintain a vulnerability management program

5. Use and regularly update anti-virus software

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7. Restrict access to need-to-know

8. Assign unique IDs to each person with computer access

9. Restrict physical access to cardholder data

Regularly monitor and test networks

10. Monitor and track all access to network resources and cardholder data

11. Regularly test security systems and processes

Maintain an information security policy

12. Maintain a policy that addresses information security

A quick review of these 12 items shows that PCI is a textbook example of the fundamentals of information security. With that, PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance is an excellent resource that provides the reader with all of the fundamental information needed to understand and implement PCI DSS.

The books 13 chapters provide the reader with a comprehensive overview of all of the details and requirements of PCI. The first three chapters provide an overview of the basics about PCI and the basic requirements of the standard. The following six chapters go into detail about each of the primary control areas.

In particular, chapter 6 provides a good overview of the PCI logging requirements. This requirement can be time-consuming to put into place. The author notes that a commonly overlooked but essential requirement, namely that of accurate and synchronized time on network devices. Enterprise information network and security infrastructure devices are highly dependent on synchronized time and PCI recognizes that correct time is critical for transactions across a network.

In a further discussion about synchronized time in chapter 9, the author unfortunately makes an error when he states that local hardware is considered a stratum 1 time source since it gets its time from its own CMOS. From an NTP perspective, only a device that is directly linked to a stratum-0 device is called a stratum-1. CMOS clocks are notoriously inaccurate and can't be relied upon.

The title of chapter 12 is both amusing and accurate 'Planning to fail your first Audit'. The irony is that so many organizations lack a CISO or formal business security program in place designed to protect corporate information assets. They don't focus on information security as a process, rather as a set of products or regulatory items to be checked-off. Yet, these same organizations are surprised when they fail an audit.

The book concludes in chapter 13 with the well-known observation that security is a process, not an event. The book astutely notes that it is impossible to be PCI compliant without approaching security as a process. Trying to achieve compliance without integrating the various aspects in an integrated fashion is bound to fail.

Overall, PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance is a great book for one of the most sensible security standards ever. Anyone who has PCI responsibilities or wants to gain a quick understanding of the PCI DSS requirements will find the book to be quite valuable.

Ben Rothke is a security consultant with BT INS and the author of Computer Security: 20 Things Every Employee Should Know

You can purchase PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

PCI Compliance More

PCI Compliance

Comments Filter:
  • But there are a number of typos in the glossary.

  • "PCI" or "PCI" ? (Score:2, Informative)

    by bradgoodman ( 964302 )
    I don't think this is talking about the "PCI" that most of us know and love... :-O TMA!

  • And for those wondering what PCI refers to (Score:5, Informative)

    by adamwright ( 536224 ) on Monday August 27, 2007 @01:47PM (#20374677) Homepage
    It's "Payment Card Industry" (maybe in the USA this is a common term, but I've never heard it in the UK, to my knowledge). From the summary, I thought it was some kind of PCI (Peripheral Component Interconnect) bus level security (i.e. encrypted electrical transport), for DRM!

    • Re: (Score:2, Insightful)

      by OptimusPaul ( 940627 )
      I'm in the US and I've never heard of it. I was a bit confused at first thinking it was refering to the PCI bus. Learn something new everyday...

      • Re: (Score:1)

        by archen ( 447353 )
        Whenever I see this topic brought up, most people haven't heard of it despite the fact that it's been swirling around for well over a year. So I wonder how effective this will actually all be. I've gotten a few vendors that have called who chime in with "Are you compliant with the new PCI regulations?" - attempting to panic me with some mystery regulation to get their foot in the door I suppose.

        Among one of the many things you are supposed to do (and this one is actually realistic), you are not supposed to

    • Re: (Score:2, Interesting)

      by butters the odd ( 729841 )
      I work for a retail chain that went PCI compliant recently. We had to put a separate firewalled network in each store, and that was very costly. Now it's a pain to access point of sale servers, because we can only access that network through a VPN. To those complaining about calling it PCI in the article, in the retail industry PCI means payment card industry. They are even worse than the RIAA. They bleed small to medium sized companies dry with their fees. You pay the fees, or you don't get to take c

      • Re: (Score:3, Insightful)

        by virtual_mps ( 62997 )

        I work for a retail chain that went PCI compliant recently. We had to put a separate firewalled network in each store, and that was very costly. Now it's a pain to access point of sale servers, because we can only access that network through a VPN.
        Um, good. As a consumer, I'm glad that you can no longer directly access my credit card information from any node on your corporate network. Score one for the good guys (PCI).

        • Agreed. I work for a fairly small company that classifies as a mid-tier vendor for PCI purposes, and while the requirements have been a pain in the butt to implement at times, the fact of the matter is that most of the stuff required is pretty necessary and really should have been implemented all along. A big part of the problem is that vendors have been by-and-large shielded from the real costs of identity theft, and as such haven't had any motivation to build in even the most rudimentary protections and

    • From the summary, I thought it was some kind of PCI (Peripheral Component Interconnect) bus level security (i.e. encrypted electrical transport), for DRM!
      Same here. And when I first read "Visa" I read it "Vista" and had to stop and reread the sentence when I hit "MasterCard" (after the "WTF is MS doing with the credit card companies, I should stop reading right now and post something" moment of /.-style outrage).
    • I've never heard of it either, and I have a credit card merchant account. The difference may be that I don't have any terminals, I'm a web-only merchant.
      • Maybe I've seen an instance of this. I think my parent's merchant account became more costly until they had the Address Verification System (AVS) enabled). I think it cut their fees down by 1% of the total transaction.

    • Re: (Score:2)

      by renoX ( 11677 )
      Thanks a lot!

      Are the submiter or the editor dumb?
      It's very weird to allow such article to pass through without having PCI defined!

  • Costly... (Score:4, Interesting)

    by BobMcD ( 601576 ) on Monday August 27, 2007 @01:48PM (#20374695)

    Regularly monitor and test networks

    10. Monitor and track all access to network resources and cardholder data

    11. Regularly test security systems and processes
    These two stand out as the most costly. Are they things you SHOULD do? Yes. Can you reasonably mark either of these as 100% compliant at any time? Maybe, but this isn't going to be pretty, or cheap...

    Lets look at #10 first. What does "all access to network resources" define out to be? These days EVERYTHING is a network resource, and not all of them are within the admin's control. Take the iPhone for example. Is the PCI-compliant admin supposed to certify that every iPhone on the company's network cannot be accessed by others, thereby turning it into a 'network resource'? How do I, as an admin, track that Joe and Jim transfered files peer-to-peer style between their phones? I assume that we have to then ban all these devices?

    It is _possible_ to comply with 'all access to network resources', but this is costly.

    Cardholder data, on the other hand, can be limited and is perfectly reasonable as a requirement.

    For #11, does 'regular' imply frequent as well? Does that compound with 'all network resources'? If so, this is a HUGE time sink. It could also be done, but this has a cost attached as well.

    • Re: (Score:3, Insightful)

      by Attila Dimedici ( 1036002 )

      Lets look at #10 first. What does "all access to network resources" define out to be? These days EVERYTHING is a network resource, and not all of them are within the admin's control. Take the iPhone for example. Is the PCI-compliant admin supposed to certify that every iPhone on the company's network cannot be accessed by others, thereby turning it into a 'network resource'? How do I, as an admin, track that Joe and Jim transfered files peer-to-peer style between their phones? I assume that we have to then ban all these devices?

      It is _possible_ to comply with 'all access to network resources', but this is costly.

      I am pretty sure that when they say "network resource", I am pretty sure that they are talking about the network that the cardholder data is on. It is not necessary that all of your company's business goes on on the network that handles your credit card processing. As a matter of fact, it is probably a good idea if things like cell phones that access the company network, don't access the network that handles credit card data.

      • You are correct. I've been through PCI and before that, CISP. Our office network is not involved. The production network where card numbers go is heavily audited and tracked.

        OSSEC-HIDS helped a lot in the monitoring requirements, along with nmap and the LOG/ULOG targets in iptables.

      • Yes. Auditors have to be quite careful about which devices are in scope and minimising the scope of what needs to follow the requirements greatly decreases the cost of being compliant.

        From the standard:

        These security requirements apply to all "system components." System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or se

    • Workarounds... (Score:3, Informative)

      by tempest69 ( 572798 )

      Regularly monitor and test networks

      10. Monitor and track all access to network resources and cardholder data

      11. Regularly test security systems and processes

      These two stand out as the most costly. Are they things you SHOULD do? Yes. Can you reasonably mark either of these as 100% compliant at any time? Maybe, but this isn't going to be pretty, or cheap...

      Lets look at #10 first. What does "all access to network resources" define out to be? These days EVERYTHING is a network resource, and not all of

      • Re: (Score:2)

        by BobMcD ( 601576 )

        That's pretty solid, actually. Except perhaps that the App won't like that config and the vendor will never have heard of doing it that way before.

        It would be rare to see the network that houses the workstations to be considered 'open'.

        You'd pretty much be forced to go thin-client, too.

        Again, assuming this is your only reason for implementing these measures, costs will attach...

        • Re: (Score:2, Insightful)

          by 2bitcomputers ( 864663 )
          Nope, what the OP described is exactly how we handled our PCI requirements. The corporate LAN is treated as a DMZ. Otherwise we would have had to install SNORT on every workstation, back up logs from every workstation, install trip wire on every work station to make sure log files are not altered. require two factor auth on every workstation, the list goes on. PCI compliance is a HUGE PITA. I (thanks /.) actually understand how computer security should work, but IMHO PCI rules are specifically worded so th

          • Re: (Score:1)

            by wfberg ( 24378 )
            Why is there credit card information on your workstations? Seriously wondering; I'd expect transactions to only hit some web and database servers (which should have logging, firewalls etc.); if people are looking at lists of transactions, the last 4 numbers of cards should suffice to read out to customers, that's the sort of thing I'd expect to happen on workstations.
            • This is the alternative to locking down the CC using servers - you need to log access to anything that could access the servers that use cc data and, if you don't have an isolated network, that includes everything. Even the laptop some sales guy brings in for a sales pitch.

            • Re: (Score:2)

              by BobMcD ( 601576 )

              I don't the issue would be that there IS data on the workstations, but proving that there cannot be. If you can't prove that, you'd have to assume that there is.
            • If you can SSH from your desktop to the DB server without having to use a VPN it is considered in-scope for PCI.

          • Re: (Score:2)

            by alcourt ( 198386 )
            Having gone through PCI audits, I agree they can be a nuisance, but mainly if you do not have an organization dedicated to audit response[1]. Responding to an audit requires professionals who actually work closely with every auditor, not just once a year, and are literally preparing for audits year round and are a central point for all audits. I found the PCI audit refreshing for the preciseness compared to the SOX audit which was more of a "hope the auditor interprets policy the exact same way you do."

            Th

    • Re: (Score:3, Informative)

      by Amoeba ( 55277 )
      PCI is actually much less complex than other compliance standards like SOX, HIPAA, GLBA... If I had to choose a compliance requirement to deal with PCI would be my choice. Overall, it's the most sane compliance guideline I've seen which actually improves your overall security if done correctly. It's like being forced to be a good security-citizen with your data. Some clarification on your comments:

      Lets look at #10 first. What does "all access to network resources" define out to be? These days EVERYTHING i

    • Re: (Score:2)

      by Qrlx ( 258924 )
      These days EVERYTHING is a network resource

      Everyone, let's welcome John Gage to Slashdot.

      Though I must say, I'm intrigued by your choice of username, and that your UID is even higher than mine.

    • Re: (Score:1)

      by impver ( 1136985 )
      You are right in that it is a time sink and has a high cost. You have to have all of this independently verified so you HAVE to pay someone to scan your systems for problems and they normally do it once, tell you whats wrong(sometimes very vaguely and with many false positives) and let you fix it. Then they scan again, rinse and repeat. Every time they do a scan you get charged and no matter what you do there will be false positives so it's almost always a 2 scan process. Now as for your statement about iP
      • >>>Every time they do a scan you get charged and no matter what you do there will be false positives so it's almost always a 2 scan process.

        Negotiate, Negotiate, Negotiate. Yes, it can be expensive, but you can negotiate and quickly lower the price.

    • Re: (Score:2)

      by ajs ( 35943 )

      It is _possible_ to comply with 'all access to network resources', but this is costly.

      Cardholder data, on the other hand, can be limited and is perfectly reasonable as a requirement.

      For #11, does 'regular' imply frequent as well? Does that compound with 'all network resources'? If so, this is a HUGE time sink. It could also be done, but this has a cost attached as well.

      It gets worse. PCI is a far-reaching set of requirements, when read in specific. It even has implications as far as how you run your business, outside of technical security.

      In general, companies tend to isolate the PCI-compliance requirements to a section of the company that simply doesn't interact with the rest of the company except through tightly controlled channels. This becomes even more important as you add on any fiduciary requirements from the U.S. Federal Government or privacy restrictions from th

    • PCI is a good model for any company to follow who would like to secure sensitive data and audit, log, and track usage of said data. Most of the requirements are items that a good IT department should have in place to begin with. Part of the process is implementing an Information Security Policy in which all employees, contractors, or third parties must adhere to if they connect to your network. This is something that TONS of companies lack to begin with, and it brings an awareness of data sensitivity to you
    • PCI is talking about the "network" that touches their money. The best way to handle things like iPhones is to make the POS network separate and hardened from everything else. If you have Wi-fi or such it's always treated as a hostile device... always. Then you don't have a problem.
  • ...PCI is an excuse to hire the KPMGs, Accentures and EDSs of the world. They will charge you $xM for "experts" to put in controls and make your systems secure. All the while, only a few percent of your card transactions are fraudulent. The thing about PCI is that you can't just take the hit for fraud anymore...you get smacked with huge fines for every leaked credit card number, etc.

    I'm not a big believer in the whole "identity theft" hype -- if someone steals your credit card numbers or social security num
    • Actually, it's a reaction to TJ-Max (and others) losing 45.7 million credit and debit card numbers. http://www.msnbc.msn.com/id/17853440/ [msn.com]
      • What????? The TJMAXX hack occurred under a year ago.

        PCI is a few years old. In fact, had TJMAXX been PCI compliant, they would never have had a breech.

    • Re:Just like HIPAA or Sarbanes-Oxley... (Score:5, Informative)

      by ScentCone ( 795499 ) on Monday August 27, 2007 @01:59PM (#20374819)
      if someone steals your credit card numbers or social security number, just get copies of your credit reports, make the appropriate phone calls, and the problem goes away

      Never had it happen to anyone you know, huh? The problem doesn't just "go away" if your checking account is cleaned out right when you need to make a mortgage payment. It doesn't just "go away" if this happens to you during your job application cycle, especially to a secure or trusted position. It can take months or years to clean up after something like this, and you have to watch it like a hawk pretty much for the rest of your life.

      • Re:Just like HIPAA or Sarbanes-Oxley... (Score:5, Informative)

        by gEvil (beta) ( 945888 ) on Monday August 27, 2007 @02:15PM (#20374997)
        Exactly right. It can take years to clean up. And if your stolen information is used on the other side of the country, you need to file police reports with the appropriate authorities in that other city/county/state. And guess what, they'll probably want you to come into their offices in person to do it. And if you don't have a copy of the appropriate police reports, the big three reporting agencies won't even want to hear from you, cos you're obviously just wasting their time (remember, you are not their customer--the credit companies are). Yeah, it's no problem to get crap like this removed from your record. I'm usually not the type of person to say this sort of thing, but I really hope ErichTheRed has his identity stolen some time so he can see just how "simple" the whole process is...
    • >>>>..PCI is an excuse to hire the KPMGs, Accentures and EDSs of the world. They will charge you $xM for "experts" to put in controls and make your systems secure.

      Well.... If the merchants would have been smart enough to do a basic level of security in the first place, they would not have to spend such $$$$. In fact, this is a good fine and penalty for them since they were derelict in their duties in the first place.

      >>>>All the while, only a few percent of your card transactions ar
    • "From what I've seen, PCI's just a consultant-employment excuse. Anyone can still write down credit card numbers and sell them."

      The truth of the matter is, criminals will always find a way. You can setup hidden cameras in strategic locations inside businesses now-a-days, and use software to rip CC #'s. There's been a problem with retailers and other places that use credit cards for payment having their employee's (and sometimes employers) enabling fraud.

      The truth of the matter is, any electronic payment t

  • Maybe they do know. (Score:3, Interesting)

    by Spazmania ( 174582 ) on Monday August 27, 2007 @01:54PM (#20374751) Homepage
    For those who didn't catch the acronym, PCI = payment card industry, i.e. Visa, Mastercard et al.

    many are complaining that the PCI Data Security Standard (PCI DSS) is too complex and costly. What is most troubling is that such opinions are being written in periodicals and by people that should know better.

    Maybe the opinions got it right. I lead the systems administration team for an organization which does a tremendous number of credit card transactions. PCI DSS compliance is a joke. You answer a long questionaire, much of which has no relevance (virus scanner for your Linux web server!?). Next you submit to a black-box scan of your exterior network interface by an external auditor who does nothing more than run Nessus against your address space. Then they hassle you about all the faulty Nessus hits. Yes we are running SSL IMAP and no it doesn't have any known security vulnerabilities despite the rank 7 nessus hit documented by a URL that returns a 404 error. Commence eyeroll.

    • PCI DSS compliance is a joke. You answer a long questionaire, much of which has no relevance (virus scanner for your Linux web server!?)

      Whoever drew up the questionnaire is not competent. From the document:

      5.1 Deploy anti-virus software on all systems commonly affected by viruses (particularly personal computers and servers)
      Note: Systems commonly affected by viruses typically do not include UNIX-based operating systems or mainframes.

      You may argue about whether the term "UN

      • Systems commonly affected by viruses
        IOW, systems running OSes produced by one Microsoft Corporation.

      • >>>>Whoever drew up the questionnaire is not competent. From the document:

        What??? Whoever drew up the questionnaire really knows what they are talking about.

        >>> 5.1 Deploy anti-virus software on all systems commonly affected by viruses (particularly personal computers and servers) Note: Systems commonly affected by viruses typically do not include UNIX-based operating systems or mainframes.

        What that means is AV only on Microsoft products. I can be pci compliant and not need AV on m

        • >>>>Whoever drew up the questionnaire is not competent. From the document:

          What??? Whoever drew up the questionnaire really knows what they are talking about.

          You are confusing the specification document with the questionnaire drawn up the the OP's consultants. The original specification does state that anti-virus is only relevant for some platforms, but I interpreted the OP to say that that the questionnaire he had to complete did not make this distinction. The questionnaire should have been

      • Right. I am not sure if the GP really knows about PCI compliance or is blowing smoke. If his organization does a "tremendous number of credit card transactions" and he "leads the systems administration team " then I worry about that organization and team.

        Also you can perform your own scans. An external vendor is not required. You simply need someone certified in PCI vulnerability assessment. In a large organization, a security team should have one or more people with this certificiation.
    • I feel your pain, I had to deal with this for ages, one of our Internal Firewalls honeypots if you scan it. And its an out the box feature from the manufacturer that they haven't created the ability to turn off yet. For us PCI compliance is mostly about the legacy data, where a couple minutes of physical access on various Point of Sale servers you can rack in a few years of credit card data. Also retail outlets like to share their passwords and the turnover is huge, so its pretty hard to give everyone thei
    • Every year we have an auditor spend a few days going over all of our logs and network access rules to maintain our ROC. He even checks the patch history of servers having card holder data and inactive users still in AD.

    • Re: (Score:2)

      by mike2R ( 721965 )
      I got the feeling that they designed the form mainly to scare small companies into using an online gateway. This to be honest is a good thing IMO.

  • Sauce for the goose... (Score:4, Insightful)

    by UncleTogie ( 1004853 ) * on Monday August 27, 2007 @01:57PM (#20374783) Homepage Journal

    I'm going to have to call foul here. Working with point-of-sale systems, we deal with PCI compliance in software regularly, so I've tried to keep up with the PCI regs as it pertains to the software packages we sell.

    It's a blatant double-standard. They want to lock down EVERYTHING downstream from them, with accountability, yet even after numerous break-ins, apparently have not applied the same standards to *themselves*.

    On the flip side, most of our customers couldn't give a rat's kazoo about compliance, and would do without it 'cause of various inconveniences... {You can only transfer CC-orders twice per order, per spec...} We get buy-in by explaining the penalties if they're caught, and let 'em know that while it may be IMPROBABLE, it's quite possible.
    • I don't know what verticals you work with in POS. But for us and the hospitality industry, it's been a PITA for compliance and pre-authing tip amounts. It seems like restaurant owners are freaking at the fact they can't pre-auth over 20% on the invoice to guarantee some form of tip...
      • Yup. The pre-auth's bit us in the rear a few times, but that order-transfer is the EVIL one. Example: Pizza joint. Cashier takes a phone order and gets CC number. Driver takes the order, cashier transfers it over. The issue? When the wrong driver is transferred to, or swaps deliveries with another driver. You can't transfer the order anymore, by rule. So, now due to PCI compliance, the numbers for the driver deliveries end up bolloxed. We've had clients literally yelling over the phone about this. It'd be n
  • I do server admin and light coding work for a small company that has a primarily web-based business. Going through ScanAlert not only do we have a nice logo to put on the website but we also get a list of stuff that could cause problems such as XSS and software package vulnerabilities (and can check to see if problems are fixed after we've patched the problem).

    The thing is, obtaining PCI certification is not that hard. Any decent web admin should already be halfway there, the rest is just locking down ap

    • Re: (Score:3, Informative)

      by sjhwilkes ( 202568 )
      At the lowest level, yes it's trivial. However it's a graded program:

      * Level 1-Visa U.S.A. and MasterCard World Wide transactions totaling 6 million and up, per year, and any merchants who experienced a data breach.
      * Level 2-Visa and MasterCard transactions totaling 1 million to 6 million per year. (The new requirement expands the number of Level 2 merchants to include former Level 4 merchants.)
      * Level 3-Visa and MasterC
  • Having worked for a multi-billion dollar mutual fund company as the head of network security I saw first hand the many paradoxes of standards vs reality, as I am sure we all have in the security field.

    1. Receive "quality" industry wide standard and procedures that are meant to protect and secure.
    2. Huddle around a conference table and try and dissect what this means for the company.
    3. Try and find the cheapest and best "close to scenario" for complying with the standards.
    4. Implement and cheer that "WE HAVE
  • I led an effort at a Fortune 100 company to bring their online storefront and it's backing systems into compliance with the PCI Standard. We started with doing a gap analysis, implementing the changes and improvements, doing an internal audit, and then an external audit for Visa.

    The requirement language is sometimes a little vague but by using your best judgement and putting your security and customer hats on, it isn't too hard to figure out.

    I actually found the requirements a great tool to convince

  • FWIW: Razors: what is secret is how long they last (Score:3, Insightful)

    by jerryasher ( 151512 ) on Monday August 27, 2007 @03:50PM (#20376121)
    As I recall from a class a long time ago, all of those n-bladed hexi-flexi razors are built to very high technology standards. It was apparently a $1B and bet your company kind of investment by Gillette to initiate these sorts of razors and create the machines that could do the sort of precise welding needed.

    The razors themselves are high tech and excellent quality -- they don't want you to cut yourself which would be bad for repeat business.

    What is kept very secret is how the manufacturer thinks they should last. To create repeat business, they won't tell you to replace the blade daily, weekly, or monthly. They'll let you decide.
  • as a sysadmin for a managed hosting company the PCI compliance issues we run into are 99.9% of the time not even real legit issues that would be of a major risk to a credit card processing website. most of them are simply flag checks of versions of software that are installed. most of the time, say on a RHEL system the actual version numbers remain old and the required patches are backported into the rpm. almost any time i get the "OMG I AM SO OUT OF DATE" request from a client it means i simply have to
  • PCI compliance is (a) a sensible set of rules to better protect the privacy and security of credit card transactions but, more importantly, it is (b) a new mechanism for banks to levy astronomical fees against non-compliant merchants and (c) build a self-serving governance consulting industry which will promote the rather profitable idea that banks are outside of the loop when bad things happen in the payment card industry.
    First off, banks are parasitic business -- they do not typically kill the host. Whi
    • Although I agree with you, there is one point I could add: the banks themselves are mostly not PCI compliant.

      Yes, Visa and Mastercard push banks and payment processing companies to be PCI compliant, but they offer to check compliance through procedure called "Self audit". That is - you have to tell them you are compliant. So of course everyone is.

      I was responsible for PCI compliance in one payment processing company in north Europe, so I know what it's like - a list of sometimes dumb rules you have to imple
  • PCI is NOT a problem for techies, it is a problem for managers. Several places I've worked there has been intense pressure to circumvent PCI because it all appears as 'non-functional' requirements on their charts.

    I've even seen one place recycling client data as test data: those customers were seriously peeved about the odd charges and paybacks on their bills. Which was why I was brought in. Try explaining to a management team that a bug isn't in the code but in their technique.

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close