The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally.
PCI DSS provides a baseline of technical and operational requirements designed to protect cardholder data. This applies to all entities involved in payment card processing – including merchants, processors, acquirers, issuers, and service providers, as well as all other entities that store, process or transmit cardholder data.
PCI DSS comprises a minimum set of requirements for protecting cardholder data, and may be enhanced by additional controls and practices to further mitigate risks.
There are six key areas addressed in PCI-DSS.
PCI DSS provides a baseline of technical and operational requirements designed to protect cardholder data. This applies to all entities involved in payment card processing – including merchants, processors, acquirers, issuers, and service providers, as well as all other entities that store, process or transmit cardholder data.
PCI DSS comprises a minimum set of requirements for protecting cardholder data, and may be enhanced by additional controls and practices to further mitigate risks.
There are six key areas addressed in PCI-DSS.
- Network security
- Card-holder data security
- Identifying and managing vulnerabilities
- String access control measures
- Regular monitoring and testing
- Information Security Policies
Network Security
- All WSO2 servers should be running behind a firewall - which only let in filtered traffic.
- Firewall rules should only permit a selected set of context paths to the WSO2 servers.
- In case a given server being deployed in DMZ, make sure only the required components are installed. WSO2 Feature Manager supports removing all unnecessary features. Say, for example, if you deploy WSO2 ESB as a Security Gateway in the DMZ, you can remove the complete UI Management console from it.
- Change the key stores. You can find two key stores (.jks ) that ship with WSO2 products at CARBON_HOME/repository/resources/security/ . Out of those two, wso2carbon.jks is the primary key store and client-truststore.jks is the trust store, where you will have the public certificates of trusted Certificate Authorities (CAs ). Once you change the key stores, you need to update the corresponding entries in the following configuration files.
CARBON_HOME/repository/conf/tomcat/catalina-server.xml
CARBON_HOME/repository/conf/carbon.xml
CARBON_HOME/repository/conf/axis2/axis2.xml
- Use Secure Vault to encrypt all the passwords in the following configuration files - and make sure all default passwords are being changed.
CARBON_HOME/repository/conf/user-mgt.xml
CARBON_HOME/ repository /conf/carbon.xml
CARBON_HOME/repository /conf/axis2/axis2.xml
CARBON_HOME/repository/conf/datasources/master-datasources.xml
CARBON_HOME/repository/conf/tomcat/catalina-server.xml
- Change the default ports. By default, WSO2 ESB runs on HTTPS port 9443 and HTTPport 9763 . Also, WSO2 ESB exposes services over 8243 and 8280 . To change the ports you can update the value of <Offset> at CARBON_HOME/repository/conf/carbon.xml
- All connections to the user stores (LDAP / AD) should be over TLS.
Card-holder data security
- Make sure any connection initiated from the WSO2 Carbon servers to the card holder data storage is protected by network/firewall rules or running over TLS.
- WSO2 Servers store client credentials as a salted hash. Make sure you configure for a strong hashing algorithm.
- Make sure your application data storage is well protected with encryption and access control rules.
- Make sure data exposed via APIs hosted in WSO2 servers enabled only on TLS.
- Access to the Management Console of WSO2 servers protected with TLS.
- WSO2 products do not maintain user credentials or any confidential data in cache.
Identifying and managing vulnerabilities
- Make sure the operating system, where WSO2 middleware running on, is up to date. Enable automatic update checks.
- Use and regularly update anti-virus software or programs.
- Make sure all the latest security patches for the WSO2 products are applied. All WSO2 productions customers are immediately informed whenever a security vulnerability being uncovered.
- All WSO2 products go through static code analyzing tools and OWASP recommended tools to identify and mitigate security vulnerabilities at the code level.
- WSO2 is part of all standard bodies, OASIS, W3C, IETF and other prominent open source communities. We are notified whenever a vulnerability being discovered, either at the code level or at the specification level.
- Make sure you have proper access control rule at the network level and at the physical machine level where you have deployed WSO2 middleware.
- Use standard fine grained access controlling to secure all your APIs exposing data. This can be done with XACML support in WSO2 product stack.
- Have strong Role Based Access Control to the management console of WSO2 products. Always adhere to the principle of least privilege.
- WSO2 servers, maintain audit logs of all privilege actions performed by end users.
- Use WSO2 BAM and WSO2 CEP for fraud detection and analyze access patterns.
Regular monitoring and testing
- Use network level monitoring tools to detect any violations in access control rules.
- Use WSO2 BAM and WSO2 CEP for fraud detection and analyze access patterns.
Information Security Policies
- Maintain a policy that addresses information security for all personnel.
- Authentication and Access Control policies can be developed, governed, enforced and evaluated through WSO2 product stack.