PCI compliance requirement 2: Defaults

Diana Kelley and Ed Moyle, co-founders of Security Curve, address PCI compliance requirement 2: "Do not use vendor-supplied defaults for system passwords and other security parameters." PCI compliance requirement 2 calls for:

  • Documentation of a secure configuration, which includes removal of vendor-enabled passwords and unnecessary services
  • Implementation of security features like encryption for administrative connections

Ed and Diana review common PCI questions, including "What should be done about hosting providers?"

Watch the rest of the PCI compliance videos, as the experts continue their advice requirement by requirement.

Editor's note: This video is based on PCI DSS version 1.1. For updated information on the changes in PCI DSS version 1.2, see the following:

Read the full transcript from this video below:  

PCI compliance requirement 2: Defaults

Ed Moyle: I'm Ed Moyle and I am a QSA, or a Qualified Security Assessor, and this is...

Diana Kelley: I am Diana Kelley and I am a partner at SecurityCurve.

Ed: So, welcome back. Requirement 2 is… the requirement is do not use vendor supply defaults and security system passwords and other security parameters. Basically this means that you as an organization need to create a documented configuration that is standard, that does remove all of the various vendor-supplied, unnecessary services, things like telnet, things like RSH, things like RExec and so on. Remove those services; definitely get rid of any kind of default passwords, Scott Tiger for example, in an Oracle context.

Diana Kelley: SA Admin.

Ed Moyle: SA Admin, whatever it is, definitely pull that out of there. Not just on a system-by-system basis, but actually have a documented procedure that specifically addresses removing those accounts and removing those services. One of the things that we see a lot in the field is legacy components that are already fielded, that have some of these problems attached to them. Keep in mind that your QSA will pick a sample of the hosts in your environment, and they're going to look at them to make sure that those things are removed.If you have 100 systems fielded that have Scott Tiger on there, they might pick one of those and find that that password and user combination is in fact in use, in which case that could be problematic to you. 

Also, don't forget about your HTPP management interfaces. The specifics of this requirement indicate that you do need to use secure methods for managing infrastructure and other equipment. HTTP is handy and easy, and everybody has access to it, but there is a lack of security on that channel so definitely take steps to address that. 

Questions we hear a lot are: hosting providers. What are hosting providers doing in this case? Clearly they are providing a lot of systems to folks. They might even provide just a box, like a co-location facility that is pre-configured for you, or for your company. So what do they do? Take a look in that case to Appendix A, of the PCI Standards Document, which has specific requirements for hosting providers. A lot of them are very applicable to specifically this requirement. That's a useful resource. There is some specific guidance provided in line to the standards documentation itself about what hosting providers should or shouldn't do.

Diana Kelley: Also, in addition to your legacy infrastructure and applications, make sure that, one thing that is a lot of times is forgotten, the router, the configuration, the logins and the passwords, and the access points for wireless. Maybe you changed the SSID, but did you change the login to do the remote administration? You have to make sure that all of those are changed. Wireless especially if you've got a lot of retail sites, you put up a lot of the smaller wireless. They may not be centrally managed; you may just set them up and gone. You want to be very careful that you check all the default configurations, because you don't want an SSID of "Linksys" at one of your remote sites when the assessor comes around.

Ed Moyle: This happens, by the way.

Diana Kelley: All right. So some quick hits for requirement 2. You're going to change all those defaults on all your target devices, remembering wireless routers, some devices that may have missed the initial pass. You want to make sure you have all of them. Have one function per server where required. You don't want to have a lot of mixed-use servers, specifically the payment servers themselves. The payment server shouldn't be your e-mail server as well. You want to have one use for that. As well as, shut off any of the services that you don't need. When you set up your operating system, it brought up a whole bunch of services that are great and wonderful for the average user, they might not be so great and wonderful in securing down payments in some servers or applications, so make sure you turn off those things you don't need.

Ed Moyle: In the field, the No. 1 issue that we see associated with this is definitely the legacy equipment that we talked about. We do see a lot of systems that, for one reason or another, that have been fielded and do not have a secure configuration.

View All Videos

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.