Comtrex Systems Corporation. CISP/PCI Implementation Guidance for Odyssey Suite

Transcription

1 CISP/PCI Implementatin Guidance fr Odyssey Suite Applicable Applicatin Versin This dcument supprts the fllwing applicatin versin: Odyssey Suite Versin 2.0 Intrductin Systems which prcess payment transactins necessarily handle sensitive cardhlder accunt infrmatin. The Payment Card Industry (PCI) has develped security standards fr handling cardhlder infrmatin in a published standard called the PCI Data Security Standard (DSS). The security requirements defined in the DSS apply t all members, merchants, and service prviders that stre, prcess r transmit cardhlder data. The PCI DSS requirements apply t all system cmpnents within the payment applicatin envirnment which is defined as any netwrk device, hst, r applicatin included in, r cnnected t, a netwrk segment where cardhlder data is stred, prcessed r transmitted. The fllwing high level 12 Requirements cmprise the cre f the PCI DSS: Build and Maintain a Secure Netwrk 1. Install and maintain a firewall cnfiguratin t prtect data 2. D nt use vendr-supplied defaults fr system passwrds and ther security parameters Prtect Cardhlder Data 3. Prtect Stred Data 4. Encrypt transmissin f cardhlder data and sensitive infrmatin acrss public netwrks Maintain a Vulnerability Management Prgram 5. Use and regularly update anti-virus sftware 6. Develp and maintain secure systems and applicatins Implement Strng Access Cntrl Measures 7. Restrict access t data by business need-t-knw 8. Assign a unique ID t each persn with cmputer access 9. Restrict physical access t cardhlder data Regularly Mnitr and Test Netwrks 10. Track and mnitr all access t netwrk resurces and cardhlder data 11. Regularly test security systems and prcesses Maintain an Infrmatin Security Plicy 12. Maintain a plicy that addresses infrmatin security The remainder f this dcument describes the essential guidance fr implementing Odyssey Suite in a PCI cmpliant envirnment. 1 f 7

2 PCI DSS Payment Applicatin Envirnment Requirements Access Cntrl The PCI DSS requires that access t all systems in the payment prcessing envirnment be prtected thrugh use f unique users and cmplex passwrds. Unique user accunts indicate that every accunt used is assciated with an individual user and/r prcess with n use f generic grup accunts used by mre than ne user r prcess. Additinally any default accunts prvided with perating systems, databases and/r devices shuld be remved/disabled/renamed as pssible, r at least shuld have PCI DSS cmpliant cmplex passwrds and shuld nt be used. Examples f default administratr accunts include administratr (Windws systems), sa (SQL/MSDE), and rt (UNIX/Linux). The PCI standard requires the fllwing passwrd cmplexity fr cmpliance: Passwrds must be at least 7 characters Passwrds must include bth numeric and alphabetic characters Passwrds must be changed at least every 90 days New passwrds can nt be the same as the last 4 passwrds PCI user accunt requirements beynd uniqueness and passwrd cmplexity are listed belw: If an incrrect passwrd is prvided 6 times the accunt shuld be lcked ut Accunt lck ut duratin shuld be at least 30 min. (r until an administratr resets it) Sessins idle fr mre than 15 minutes shuld require re-entry f username and passwrd t reactivate the sessin. These same accunt and passwrd criteria must als be applied t any applicatins r databases included in payment prcessing t be PCI cmpliant. Remte Access The PCI standard requires that if emplyees, administratrs, r vendrs are granted remte access t the payment prcessing envirnment; access shuld be authenticated using a tw-factr authenticatin mechanism (username/ passwrd and an additinal authenticatin item such as a tken r certificate). In the case f vendr remte access accunts, in additin t the standard access cntrls, vendr accunts shuld nly be active while access is required t prvide service. Access rights shuld include nly the access rights required fr the service rendered, and shuld be rbustly audited. Remte access t the payment applicatin must NOT be enabled fr supprt r even a custmer s wn access as it requires tw-factrs fr authenticatin PCAnywhere may be used ONLY if the fllwing tw cnditins are met Access is NOT always n it must be initiated frm the custmer envirnment, mnitred, and subsequently terminated after the need fr the supprt is cmplete All security settings in the sftware are enabled Settings 2 f 7

3 Launch with windws Unchecked Abnrmal end f sessin Cancel hst Checked Nrmal end f sessin Cancel hst Checked Secure by Lgff user Security ptins Prmpt t cnfirm cnnectin Checked Discnnect if timeut (10 secnds) Checked Encryptin level Symmetric Deny lwer encryptin level Checked Encrypt user ID and passwrd nly Unchecked Passwrds case sensitive Checked Callers Authenticatin type Windws Cnference Enable cnferencing Unchecked Prtect Item Strng passwrd that meets PCI standards as described abve in Access Cntrl sectin Nn-Cnsle Administratin Users and hsts within the payment applicatin envirnment may need t use thirdparty remte access sftware such as Remte Desktp (RDP)/Terminal Server, pcanywhere, etc. t access ther hsts within the payment prcessing envirnment. Hwever, t be cmpliant, every such sessin must be encrypted with at least 128- bit encryptin (in additin t satisfying the requirement fr tw-factr authenticatin required fr users cnnecting frm utside the payment prcessing envirnment). Fr RDP/Terminal Services this means using the high encryptin setting n the server, and fr pcanywhere it means using symmetric r public key ptins fr encryptin. Additinally, the PCI user accunt and passwrd requirements will apply t these access methds as well. Wireless Access Cntrl The PCI standard requires the encryptin f cardhlder data transmitted ver wireless cnnectins. The fllwing items identify the PCI standard requirements fr wireless cnnectivity t the payment envirnment: Firewall/prt filtering services shuld be placed between wireless access pints and the payment applicatin envirnment with rules restricting access Encrypt wireless transmissins using WIFI prtected access (WPA r WPA2) technlgy, IPSEC VPN, r SSL/TLS Never rely exclusively n wired equivalent privacy (WEP) t prtect cnfidentiality and access t a wireless LAN If WEP is used the fllwing additinal requirements must be met: Anther encryptin methdlgy must be used t prtect cardhlder data Use with a minimum 104 bit encryptin key and 24 bit initializatin value If autmated WEP key rtatin is implemented key change shuld ccur every ten t thirty minutes 3 f 7

4 If autmated key change is nt used, keys shuld be manually changed at least quarterly and when key persnnel leave the rganizatin Use WEP ONLY in cnjunctin with WIFI Prtected Access (WPA r WPA2) technlgy, VPN r SSL/TLS Restrict access based n media access cde (MAC) address Enable WIFI Prtected Access (WPA r WPA2) fr encryptin and authenticatin when WPA capable Vendr supplied defaults (administratr username/passwrd, SSID, SNMP cmmunity values, and WEP keys) shuld be changed Access pint shuld restrict access t knwn authrized devices (using MAC Address filtering) Disable SSID bradcast Additinally, Cmtrex encrypts all cardhlder data befre it is transmitted n any netwrk, wired r wireless. Transprt Encryptin The PCI DSS requires the use f strng cryptgraphy and encryptin techniques with at least a 128 bit encryptin strength (either at the transprt layer with SSL r IPSEC; r at the data layer with algrithms such as RSA r Triple-DES) t safeguard sensitive cardhlder data during transmissin ver public netwrks (this includes the Internet and Internet accessible DMZ netwrk segments). Additinally, PCI requires that cardhlder infrmatin is never sent via withut strng encryptin f the data. Netwrk Segmentatin The PCI DSS requires that firewall services be used (with NAT r PAT) t segment netwrk segments int lgical security dmains based n the envirnmental needs fr internet access. Traditinally, this crrespnds t the creatin f at least a DMZ and a trusted netwrk segment where nly authrized, business-justified traffic frm the DMZ is allwed t cnnect t the trusted segment. N direct incming internet traffic t the trusted applicatin envirnment can be allwed. Additinally, utbund internet access frm the trusted segment must be limited t required and justified prts and services. A simplified high-level diagram f an expected netwrk cnfiguratin fr a client payment applicatin envirnment is included belw: 4 f 7

5 Infrmatin Security Plicy/Prgram In additin t the preceding security recmmendatins, a cmprehensive apprach t assessing and maintaining the security cmpliance f the payment applicatin envirnment is necessary t prtect the rganizatin and sensitive cardhlder data. The fllwing is a very basic plan every merchant/service prvider shuld adpt in develping and implementing a security plicy and prgram: Read the PCI DSS in full and perfrm a security gap analysis. Identify any gaps between existing practices in yur rganizatin and thse utlined by the PCI requirements. Once the gaps are identified, determine the steps t clse the gaps and prtect cardhlder data. Changes culd mean adding new technlgies t shre up firewall and perimeter cntrls, r increasing the lgging and archiving prcedures assciated with transactin data. Create an actin plan fr n-ging cmpliance and assessment. Implement, mnitr and maintain the plan. Cmpliance is nt a ne-time event. Regardless f merchant r service prvider level, all entities shuld cmplete annual self-assessments using the PCI Self Assessment Questinnaire. Call in utside experts as needed. Visa has published a Qualified Security Assessr List f cmpanies that can cnduct n-site CISP cmpliance audits fr Level 1 Merchants, and Level 1 and 2 Service Prviders. MasterCard has published a Cmpliant Security Vendr List f SDP-apprved scanning vendrs as well. Payment Applicatin Cnfiguratin Baseline System Cnfiguratin Belw are the perating systems and dependent applicatin patch levels and cnfiguratins supprted and tested fr cntinued PCI DSS cmpliance: Micrsft Windws 2000 Service Pack 4, Windws XP Prfessinal with Service Pack 2, Windws embedded fr Pint f Service Versin 1.0. All latest updates and ht-fixes shuld be tested and applied. 256 MB f RAM minimum, 512 MB r higher recmmended 40 GB f available hard-disk space TCP/IP netwrk cnnectivity. 5 f 7

6 Applicatin Cnfiguratin In back ffice prgramming, select POS System Optins, then Credit Card Optins. Check the cnfiguratin screen fr prper entry as fllws: Tip Verificatin Percentage. Typically this entry will be 8.00%. The POS/2100 sftware uses this amunt when a POS Operatr, wh is an emplyee, clcks ut and prvides a reference f the actual amunt f tips paid (typically these are set as autmatically paid under the setting POS System Optins Miscellaneus Optins) and this percentage f the Operatr's net sales. Pre Authrizatin Percent. Typically this entry will be 30.00%. This amunt is used by the POS/2100 sftware when a credit card is authrized, prir t vucher presentatin t the custmer. NOTE: Unless there is a nn-zer value in at least ne f the abve fields, n "Tip" entry line will appear n the credit card vucher. Authrizatin Timeut. The default fr this is an entry f 60 secnds. Fr a DSL implementatin, it culd be set t 20 secnds. Yu DO NOT want t set this entry t lw hwever. Hld Card Authrize Amunt. Pertains t use f Buttn Type Hld Card, used t swipe a custmer's card and hld the infrmatin until payment. An amunt ther than $0.00 entered here will be pre-authrized by a Hld Card peratin. This allws the card t be checked and any pre-authrized amunt will be included if payment is finalized thrugh the credit card. If the custmer des nt pay by credit card, the pre-authrized amunt will reduce the available credit n the card fr at least ne business day, s the Hld Card Authrizatin Amunt shuld be reasnably small. Authrizatin Path. This is the IP Address used by the POS sftware fr authrizatin; either the in-stre Server's IP address r ne fr Mercury Payment. Yur entry here will be fixed as " " (DO NOT enter the qutatin marks) with either DIALePay r NETePay. Fr Internet authrizatin with Mercury Payment, the entry is fixed as "x1.mercurypay.cm;x2.mercurypay.cm" (DO NOT enter the qutatin marks). Card Interface Prcessr. If yu are nt using either credit authrizatin r egift Cards, select Inactive. In the U.S., select Datacap. Cmedia is fr U.K. use nly. Require Mgr fr Manual Card Entry. Nrmally yu will place a check mark here. It frces a manager t manually enter a card number since the fee is nrmally greater fr manually entered credit card numbers. Display Partial Credit Card Number. A check in this field will cause the printed vucher and all display at the pint-f-sale t suppress all digits f the credit card number except the last fur. Autmatically Clse Pre-Authrizatin. A check in this field activates an additinal "feature" n the pint f sale terminal. A "nrmal" preauthrizatin is used in a table service envirnment, where a tip will be added later. After interactin with the credit card prcessing netwrk, a vucher is autmatically printed "in the backgrund" with a tip line t present t the custmer. The advantage f a pre-authrizatin is that the terminal is immediately available fr use fr anther transactin. If n tip will be added, 6 f 7

7 nrmally yu wuld simply finalize t a credit card payment methd and await the accept r decline. The printed vucher wuld nt have a separate tip and ttal line. Hwever, in a cunter service situatin with a dial-up line, the delay in respnse may be up t thirty secnds. When the Table List Desktp is accessed by a POS Operatr with a check under Manager Mde Allwed, as set in POS Operatrs Manager Settings Tab, an additinal buttn will display n the Table List Desktp. Selecting this buttn will autmatically sequence thrugh each and every successfully pre-authrized rder and cmplete the authrizatin prcess, withut a tip. This flag is nly useful in cunter service situatins, where an InterNet Credit Card authrizatin is nt pssible because f the unavailability f DSL, t quickly free up the terminal fr the next transactin. Mre Infrmatin A cpy f the Payment Card Industry (PCI) Data Security Standard frm VISA s security website is available at the fllwing Internet address: Additinal infrmatin fr merchants frm VISA is available at the fllwing Internet address: tml?it=il /business/accepting_visa/ps_risk_management/cisp.html Merchants A listing f qualified security assessrs frm VISA is available at the fllwing Internet address: ml?it=l2 /business/accepting_visa/ps_risk_management/cisp_merchants%2ehtml As sessrs 7 f 7