Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
The detailed requirements in this section are relevant to WebSphere Commerce. Review each point carefully.
2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.
This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocol (SNMP) community strings, etc.).
In addition to changing default passwords, we recommend that you do not use any default ID names for the administrator accounts. For example, do not use wcsadmin, webadmin, root, or db2admin for any user IDs. The administrator account is created when you create the instance.
For information on changing passwords in WebSphere Commerce, see:
2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings..
WebSphere Commerce is not dependent on, or aware of, whether your network is wireless or not. If your internal network is wireless, ensure that you have taken sufficient steps to harden your wireless network against security threats.
Hardening is a procedure where you tighten security on the server by disabling unnecessary services and ports, making it harder to get into the system through unused features. Depending on your operating system, there are many hardening guidelines available on the Internet.
2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards..
Develop a set procedure for ensuring that the servers on which WebSphere Commerce is running follow a consistent security setup and test plan.
2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.) Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.
2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system.
Before you install WebSphere Commerce software, harden the operating system. Hardening is a procedure where you tighten security on the server by disabling unnecessary services and ports, making it harder to get into the system through unused features. Depending on your operating system, there are many hardening guidelines available on the Internet.
For your reference, a popular site for downloading security benchmarks and tools for many different operating systems is www.cisecurity.org.
2.2.4 Configure system security parameters to prevent misuse.
WebSphere Commerce has provided a set of enhanced security features documented here: Site security considerations
2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
WebSphere Commerce contains a rich set of features that can be enabled and disabled selectively. To disable WebSphere Commerce components, see: Disabling WebSphere Commerce components
2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.
SSL is used for the Management Center, Administration Console and WebSphere Commerce Accelerator. Refer to the following Web site for a list of the ports used:Quick reference to user IDs, passwords, and Web addresses
The ports for administrative access should not be available outside the firewall. You should require remote users to use a technology such as VPN to access their network before accessing any WebSphere Commerce administrative function.
2.4 Maintain an inventory of system components that are in scope for PCI DSS.
The merchant is responsible for maintaining an inventory of system components that are in scope for PCI DSS.
2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.
The merchant is responsible for documenting and communicating the security policies and operational procedures to all affected parties.
2.6 Shared hosting providers must protect each entity's hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.
Although this requirement is not directly applicable to WebSphere Commerce, if you are using WebSphere Commerce as a hosting environment, you must meet the additional responsibilities of a hosting provider.