Last Topic "PCI-Compliant Wireless Settings (PA-DSS 6.1.f and 6.2.b)"
The Restaurant Manager server computer shall have restricted inbound and outbound Internet access though use of firewall services between the server machine and the Internet. Access shall be limited to those needed by Restaurant Manager and related applications, such as credit card authorization, automatic anti-virus updates, and network time synchronization as examples.
The server machine shall be used solely as a server and not for other user functions, especially Internet activities such as email or web browsing. Those should be done from a separate machine on a separate subnet with isolated access to the Internet.
Never store cardholder data on Internet-accessible systems (e.g., web server and database server must not be on same server.)
The PCI standard requires that if employees, administrators, or vendors are granted remote access to the payment processing environment; access should be authenticated using a two-factor authentication mechanism. The means two of the following three authentication methods must be used:
Something you know, such as a password or passphrase
Something you have, such as a token device or smart card
Something you are, such as a biometric
ASI delivers patches and updates in a secure manner:
This section will describe how payment application updates and patches are delivered to the merchant. The method used must provide a secure chain of trust per requirements in PA-DSS 7.2.a, including:
Timely development and deployment of patches and updates - ASI develops patches and updates on a regular basis. Historically, at least one patch or update occurs at least once per business quarter. Patches and updates will be part of a build. More than one build may be released in a business quarter when deemed necessary.
Delivery in a secure manner with a known chain-of-trust - New versions builds are offered on the Patches and Utilities web page on the Dealer Services web site. Dealer must their unique user name and password to log onto the Dealer Services site to download the patch.
Delivery in a manner that maintains the integrity of the deliverable - Resellers can download new builds directly on the sites computers and the execute the installation package.
Integrity testing of patches or updates prior to installation - ASI tests new build prior to general release. ASI will first test the build in house (alpha testing). ASI will then test the new build at a beta site.
As a development company, ASI keeps abreast of the relevant security concerns and vulnerabilities in our area of development and expertise.
We do this by:
Payment Applications Data Security Standard (PA-DSS)" https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
Payment Card Industry Data Security Standard (PCI DSS) https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
Open Web Application Security Project (OWASP) http://www.owasp.org
PCI related seminars
Contacting Coalfire for clarification
Once we identify a relevant vulnerability, we work to develop & test a patch that helps protect Restaurant Manager against the specific, new vulnerability. We attempt to publish a patch within 30 days of the identification of the vulnerability. We will then contact resellers to encourage them to install the patch. Typically, merchants are expected to respond quickly to and install available patches within 30 days.
ASI does not deliver software and/or updates directly to the end user. This is the responsibility of the reseller. Resellers have several options to deliver a new build:
Remote access to customer networks and install the build directly from the Dealers Services website.
On site and install the build directly from the Dealers Services website
On site and install the build (obtained Dealers Services website) from an external device
For receiving updates via remote access, resellers must adhere to the following guidelines:
Secure remote access technology use, per PCI Data Security Standard 12.3.9:
PCI DSS 12.3 Activation of remote access technologies for vendors only when needed by vendors, with immediate deactivation after use. Reseller must use a software with two factor authentication (i.e. Logmein Central) with logging capabilities enabled.
The PCI standard requires that if employees, administrators, or vendors are granted remote access to the payment processing environment; access should be authenticated using a two-factor authentication mechanism (username/ password and an additional authentication item such as a token or certificate).
In the case of vendor remote access accounts, in addition to the standard access controls, vendor accounts should only be active while access is required to provide service. Access rights should include only the access rights required for the service rendered, and should be robustly audited.
If users and hosts within the payment application environment may need to use third-party remote access software such as Logmein Central etc. to access other hosts within the payment processing environment, special care must be taken.
In order to be compliant, every such session must be encrypted with at least 128-bit encryption (in addition to satisfying the requirement for two-factor authentication required for users connecting from outside the payment processing environment). Please note that ASI is recommending that Symantec pcAnywhere, Tight VNC, or Remote Desktop or similar products not be used to access accounts. However, if you choose to use one of these methods of remote access you should implement the following:
Remote Desktop Top (RDP/Terminal Services)- use the high encryption setting on the server. Note: the default port 2289 used for RDP/Terminal Services must be changed.
pcAnywhere/Tight VNC (or similar) – use symmetric or public key options for encryption.
Additionally, the PCI user account and password requirements will apply to these access methods as well.
When requesting support from a vendor, reseller, or integrator, customers are advised to take the following precautions:
Change default settings (such as usernames and passwords) on remote access software (e.g. VNC)
Allow connections only from specific IP and/or MAC addresses
Use strong authentication and complex passwords for logins according to PA-DSS 3.1.1 - 3.1.10 and PCI DSS 8.1,8.3, and 8.5.8 - 8.5.15
Enable encrypted data transmission according to PA-DSS 12.1 and PCI DSS 4.1
Enable account lockouts after a certain number of failed login attempts according to PA-DSS 3.1.8 and PCI DSS 8.5.13
Require that remote access take place over a VPN via a firewall as opposed to allowing connections directly from the Internet
Enable logging for auditing purposes
Restrict access to customer passwords to authorized reseller/integrator personnel.
Establish customer passwords according to PA-DSS 3.1.1 - 3.1.10 and PCI DSS Requirements 8.1, 8.2, 8.4, and 8.5.
The nature of our business requires remote access to a store network and server machine for support purposes. Such remote access is allowed, but only if proper protection and security methodologies are employed. Those methodologies include two-factor authentication and time-restricted access.
Below are two possible methods ASI offers for solutions regarding two factor authentication satisfaction:
(PCI DSS Requirement 8.3) Access authentication shall employee two factors of protection. The built-in protection of the access software (such as LogMeIn Free, Pro, etc) which employs a unique username and complex password can be one factor of protection. But a second factor of protection shall also be used. ASI recommends using LogMeIn Central with individual security tokens (e.g. emailed passwords) or cell phone notifications to satisfy two factor authentications. LogMeIn Central provides preference settings under the Security tab where you define the authentication parameters for every time a client site is accessed for each user account.
In addition, you will need to configure the following in LogMeIn Central to satisfy PCI DSS criteria:
1. Unique user accounts. Users cannot share remote access credentials.
2. Accounts of terminated employees are immediately disabled.
3. Strong passwords at least 7 characters long with letters and numbers as minimum complexity.
4. Remote access passwords must be changed every 90 days.
5. Automatic idle disconnect after 15 min of inactivity.
6. Logs are retained for at least one year, showing who remote controlled into what computer at what time and from what IP the connection originated.
7. Six incorrect login attempts on a user account locks out that account for a minimum of 30 minutes in order to slow down brute-force guessing.
8. Remote access logs need to be reviewed regularly for abuse.
(PCI DSS Requirement 8.3) Access authentication shall employee two factors of protection. The built-in protection of the access software (such as LogMeIn) which employs a unique username and complex password can be one factor of protection. But a second factor of protection shall also be used. In this method, ASI suggests using VPN with individual security tokens (e.g., Secure ID’s, certificates, or public keys). Therefore, access to a store would first require establishing a VPN connection, and then starting up a secure remote access connection (i.e. LogMeIn or similar) through the VPN.
i. VPN – access shall only be granted to users or vendors with business justification through a formal access granting process that is documented and tracked. In addition to the unique (to the user) username and complex password required to access servers within the payment processing environment, VPN users will need to have individually assigned access tokens.
ii. LogMeIn or other access software (PCI DSS) – Access accounts shall be set up for every user (person) with access rights to the store.
Any “always-on” connections from a computer to a VPN should be secured by using a personal firewall (PCI DSS 1.3.9). The firewall should be configured to meet specific standards and not be alterable by employees.
(PCI DSS Requirement 8.5.6) Vendor access accounts shall be disabled except during the time period when access is required. Prior to the necessity for access, an onsite trusted individual will enable access for the person requesting access. Following the access session, all access accounts will then be disabled.
The Restaurant Manager server computer shall have restricted inbound and outbound Internet access though use of firewall services between the server machine and the Internet. Access shall be limited to those needed by Restaurant Manager and related applications, such as credit card authorization, automatic anti-virus updates, and network time synchronization as examples.
The server machine shall be used solely as a server and not for other user functions, especially Internet activities such as email or web browsing. Those should be done from a separate machine on a separate subnet with isolated access to the Internet.
Unnecessary and insecure services and protocols shall be removed or not installed on the server machine. This includes such services as NetBIOS, file-sharing, Telnet, unencrypted FTP, and others.
The PCI DSS requires the use of strong cryptography and encryption techniques with at least a 128 bit encryption strength or at the data layer with algorithms such as RSA or Triple-DES) to safeguard cardholder data during transmission over public networks (this includes the Internet and Internet accessible DMZ network segments).
PCI DSS requirement 4.1: Use strong cryptography and security protocols such as transport layer security (TLS 1.2 or higher) and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks.
Examples of open, public networks that are in scope of the PCI DSS are:
The Internet
Wireless technologies
Global System for Mobile Communications (GSM)
General Packet Radio Service (GPRS)
Refer to the Data Flow diagram for an understanding of the flow of encrypted data associated with Restaurant Manager.
Restaurant Manager does not allow or facilitate the sending of PANs via any end user messaging technology (for example, e-mail, instant messaging, and chat). Reseller shall instruct end users not to email any cardholder data as part of doing business with their customers.
Although Restaurant Manager does not support non-console administration and we do not recommend using non-console administration, should you ever choose to do this, must use SSH, VPN, or TLS for encryption of this non-console administrative access
The PCI DSS requires that firewall services be used (with NAT or PAT) to segment network segments into logical security domains based on the environmental needs for Internet access. Traditionally, this corresponds to the creation of at least a DMZ and a trusted network segment where only authorized, business-justified traffic from the DMZ is allowed to connect to the trusted segment. No direct incoming Internet traffic to the trusted application environment can be allowed. Additionally, outbound Internet access from the trusted segment must be limited to required and justified ports and services.
Refer to the standardized Network diagram for an understanding of the flow of encrypted data associated with Restaurant Manager.
In addition to the preceding security recommendations, a comprehensive approach to assessing and maintaining the security compliance of the payment application environment is necessary to protect the organization and sensitive cardholder data.
The following is a very basic plan every merchant/service provider should adopt in developing and implementing a security policy and program:
Read the PCI DSS in full and perform a security gap analysis. Identify any gaps between existing practices in your organization and those outlined by the PCI requirements.
Once the gaps are identified, determine the steps to close the gaps and protect cardholder data. Changes could mean adding new technologies to shore up firewall and perimeter controls, or increasing the logging and archiving procedures associated with transaction data.
Create an action plan for on-going compliance and assessment.
Implement, monitor and maintain the plan. Compliance is not a one-time event. Regardless of merchant or service provider level, all entities should complete annual self-assessments using the PCI Self Assessment Questionnaire.
Call in outside experts as needed
ASI Reseller should visit the PCI Compliance web page on the Dealer Services website to view up to date information and additional tools to help clients.
The following documents provide additional detail surrounding the PCI SSC and related security programs (PA-DSS, PCI DSS, etc):
Payment Applications Data Security Standard (PA-DSS) https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
Payment Card Industry Data Security Standard (PCI DSS https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
Open Web Application Security Project (OWASP) http://www.owasp.org
Next Topic "Application System Configuration"
Proprietary and Confidential Information