Not signed in (Sign In)

Vanilla 1.1.5a is a product of Lussumo. More Information: Documentation, Community Support.

Welcome Guest!
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.

Categories

    • Category General
    • Category description General questions about PCI DSS that do not apply to any specific controls. For example - level definition, legal requirements and scoping.
    • Discussions 0
    • Category Requirement 1: Install and maintain a firewall configuration to protect data
    • Category description The title is a bit misleading, after you don't need to install and maintain a firewall if you already have one and a firewall can be anything from a switch, router to full blown HA pair of Check Points running on some mobile phone company's hardware. The intent is to insure that any assets containing cardholder information are securely tucked away on a secure DMZ and cannot be directly accessed from insecure networks (eg internet, wireless). Segmentation is also essential in helping reduce scope. If your stored cardholder information is in a DMZ, then all assets outside this DMZ are usually out of scope. Transmitted cardholder information and retail environments are slightly different, but if you've invested in a good EPOS solution that isn't wide open for the world to see, then this will be of great help.
    • Discussions 0
    • Category Requirement 2: Do not use vendor-supplied defaults for systems
    • Category description The first part is pretty obvious - change default settings and passwords. Besides, they're all listed on sites such as http://www.phenoelit-us.org/dpl/dpl.html and it's generally not an idea to put a default configuration onto a live network as the thousands of script kiddies that are scanning for this sort of thing will pick you up in seconds.
      Section 2.2 asks you to develop configuration standards. Whilst this is quite easy to overlook, after all your Windows CD came with an installation manual, it's actually very important to maintain configuration standards so that if something ever did go wrong you could compare the hacked build with your standard build and very quickly identify what files have been added or indeed are missing. Don't rely on file integrity to pick this up and always have a manual method on standby in case the integrity of your integrity checking tools is also compromised.
      2.4 - Implement one primary function per server is literally pummeled into by the vendor community. HP and DELL think this means merchants/service providers should buy more hardware and point solution vendors rub their hands with glee as point solutions are usually licensed per node. Now a primary function refers to things like server, workstation, web server, application server, database. None of these functions should reside on the same machine in your cardholder network as the combined risk is too high.
    • Discussions 0
    • Category Requirement 3: Protect stored cardholder data
    • Category description Don't store cardholder data if you don't need to. Before even reading section 3, have a word with your acquiring bank or service provider and look at ways to shift cardholder data off your systems. It rarely needs to be there.
      Unfortunately, paying someone else to store cardholder data for you only works if you're a small company. Bearing in mind a 10p per transaction fee, this isn't going to go down well for a large level 1 merchant.
      If you do store it, don't keep it! Securely delete when you've finished with it so that hackers with root access cannot 'undelete' and find card numbers in slack space on your hard drive.
      Encryption is the obvious way to protect stored cardholder data, but make sure the encryption keys are securely managed. You DO NOT need an expensive HSM to achieve this. Manual processes are just as secure and work absolutely fine unless you're stretched for processing power and encryption pushes your end of day process to the end of the week..
      Hard disk encryption works well too. Remember the risks you're trying to address are physical theft and unauthorized access. If you do use hard disk encryption, make sure the access control system is independent of your local file system so that data files cannot be accessed once the machine is disconnected from your network. As an added measure, make sure DBAs and sysadmins cannot view cardholder data unless you run a small operations team and they need to.
    • Discussions 0
    • Category Requirement 4: Encrypt transmission of cardholder data on open public networks
    • Category description VPN use over public network is common practise, so this shouldn't cause too many problems. The PCI SSC have clarified what they think an Open, Public network is and put this firmly in the Internet/Wireless domain.
      Networks such as MPLS, X.25, DSL, POTS are acceptable as 'private' networks even though they really aren't and if cost isn't an issue I would recommend point to point encryption anyway.
      WEP will be prohibted by PCI DSS from Jun 30 2010. At time of writing that's only 17 months away and I can't think of any level 1 merchant that uses WEP will be able to rip out WEP based systems within that time period.
      I would hope the vendors come out with a workaround. I'm sure WPA would fit onto the standard flash memory of a router that only supports WEP and again see vendors profiteering from this.
    • Discussions 0
    • Category Requirement 5: Use and regularly update anti-virus software or programs
    • Category description Employ AV software on whatever systems support it. Lock-down technology is not an acceptable alternative as it only protects systems, rather than protecting, detecting and removing viruses as per PCI DSS requirements.
      Before breaking the bank with a nice looking enterprise AV system from one of the Big Five, think about combining host based technology that address other controls, for example IDS/IPS, file integrity, event management. There are plenty of products out there that will help you save money as long as you can get past the bigger vendors that say no such technology exists.
    • Discussions 0
    • Category Requirement 6: Develop and maintain secure systems and applications
    • Category description The best way to break this down?

      6.1 Make sure all software on your systems is patched and up to date
      6.2 Regularly check independent sources for new security vulnerabilities
      6.3 Develop ALL custom applications in your cardholder environment securely
      6.4 Follow change control for all software updates and configuration changes
      6.5 Develop all WEB applications according to OWASP best practise or similar
      6.6 Regularly test all PUBLIC facing web applications for security flaws, or use a Web Application Firewall if your Lead Developer has recently left the building with all the source code in his head

      The most common challenge I run into is that customers believe their applications are secure as they've hired a 3rd party testing company that says they are. However, this only addresses 6.6 and merchants/service providers should already be conducting their OWN tests to meet 6.3 and 6.5. Food for thought?
    • Discussions 1
    • Category Requirement 7: Restrict access to cardholder data by business need to know
    • Category description The aim of this section is to ensure unauthorized users cannot access card holder data and the immediate challenge that springs to mind is how to monitor database access, as this is typically where the crown jewels are stored. Databases are usually accessed by a generic application account and you may not be able to work out who is actually looking at your information unless logs from the database and application are correlated.
      So where do you start?
      Well, each organisation is going to be different and there's no set answer, but I would recommend taking a practical approach. Central log files showing database access attempts by a shared system account are not particularly useful, but if they show a marked increase or abornmal behaviour they certainly are. I'd expect to see an alert threshold defined to alert security managers when databases start getting hammered.
      Another point to remember is that if you have a large operation there is usually no need for dbas or sysadmins to see cardholder data. Don't let them...
    • Discussions 0
    • Category Requirement 8: Assign a unique ID to each person with computer access
    • Category description Two factors should be used simultaneously to authenticate remote users coming in to your network (including 3rd parties, contractors and service providers). These two factors should be one of the following:

      Human - biometric (ie retina or fingerprint scans)
      Personal - something in someone's head (ie a passphrase)
      Technical - something bound to physical means (ie smart card, certificate, token, mobile phone)

      Employees administering your environment internally do not need two factors. One is fine.

      Also falling into this section is the use of stored procedures for database queries. Only the dba should be able to run direct queries and nobody else.
    • Discussions 1
    • Category Requirement 9: Restrict physical access to cardholder data.
    • Category description This is hopefully straightforward. Typical areas to watch out for are CCTV systems. Most of the ones I've audited only store images for 30 days, whereas the requirement is 90. You can get round this with a webcam as long as it's out of reach and the cable secure (remove all furniture from your data centre if it's on the ceiling, for example).
      Media distribution must also be strictly controlled and documented (paper, tapes, CD/DVD, hard drives..).
    • Discussions 0
    • Category Requirement 10: Track and monitor all access to nw resources and cardholder data
    • Category description It's probably not a good idea to Google requirement 10 - you will get bombarded by SIEM (Security Incident Event Management) vendors that all claim they can help solve requirement 10 and get you compliant.
      Most of the legwork here is involved in auditing your systems and establishing exactly what sort of events need logging. I generally recommend logging the following:

      1) All administrative access
      2) All individual access to cardholder data (on the database)
      3) All application access to cardholder data (taken at the point of authentication eg the application and NOT the database)

      The main idea here is to provide an audit log in case of compromise so the forensic investigator can work out what's been going on, but the secondary idea is to ensure that any critical security alerts are dealt with promptly and someone gotten out of bed if necessary.
    • Discussions 0
    • Category Requirement 11: Regularly test security systems and processes.
    • Category description Wireless, network, vulnerability and application testing is mandated from both inside and out. You don't need a QSA to conduct this testing for you and it's best to insource this wherever you can to help improve your own internal security skillset.
      An ASV is required to scan all external IP addresses related to your cardholder network, but being fairly commodotised these days I don't see much value in paying any more than £5 per IP per year to run unlimited scans. Certain QSA/ASVs will charge over £100 per IP, but you have to question the value you get out of this.
      Penetration tests are a challenge - the industry is not regulated and what you get from Company A will always be different from Company B. My only advice here is to understand your own environment, invest in network/application security training and get the job done internally. OK, so you may need to outsource the first one or two to get an idea, but long-term the cost of using 3rd parties soon accelerates beyond what it would have cost to upskill internal staff.
      IDS/IPS is required wherever you have an egress/ingress point and most firewalls should support IDS/IPS functionality. An additional unit is rarely required.
      File integrity monitoring (FIM) is built into most operating systems. You don't need Tripwire!
      Saying that, Splunk do provide a combined FIM/SIEM product that neatly hits two birds with one stone.
    • Discussions 0
    • Category Requirement 12: Maintain a policy that addresses information security
    • Category description I always question why this comes last, as it's the most important part of maintaining PCI Compliance. The best technical controls in the world will ultimately fail if not managed properly according to set policies and procedures.
      DAILY operational security procedures are required.
      Formal designation of information security to a senior manager, director or company officer is required.
      A security awareness programme is required.
      An incident reponse policy is required.
      If you can get these four things right, you're on the right track to become PCI Compliant.
    • Discussions 0
    • Category Blog
    • Category description
    • Discussions 1