IMPLEMENTATION DETAILS

Transcription

1 Plicy: Title: Status: 1. Intrductin ISP-I10 Payment Card Security Apprved Infrmatin Security Plicy Dcumentatin IMPLEMENTATION DETAILS 1.1. This dcument supprts implementatin f the "Payment Card Industry Data Security Standard (PCI DSS) cmpliance" plicy referred t in plicy dcument Cmpliance Plicy (ISP-S3) The Payment Card Industry Data Security Standard (PCI DSS) is a wrldwide infrmatin security standard defined and published by the Payment Card Industry Security Standards Cuncil. The standard was created t help payment card industry rganisatins that prcess card payments prevent payment card fraud thrugh increased cntrls arund data and its expsure t cmprmise. The standard applies t all rganisatins that hld, prcess, r exchange cardhlder infrmatin. Enfrcement f cmpliance is dne by the rganisatin s card prvider. Organisatins that fail t meet the cmpliance requirement risk lsing their ability t prcess payment card payments and being audited and/r fined Definitins Payment card - A card backed by an accunt hlding funds belnging t the cardhlder, r ffering credit t the cardhlder such as a debit r credit card. PCI DSS - The Payment Card Industry Data Security Standard (see abve). Stripe / track data - Infrmatin stred in the magnetic strip r chip n a payment card. PAN - A Primary Accunt Number is a 14 r 16 digit number embssed n a debit r credit card and encded in the card's magnetic strip which identifies the issuer f the card and the accunt. PIN - A Persnal Identificatin Number is a secret numeric passwrd used t authenticate payment cards. CAV2/CVC2/CVV2/CID 3-digit security cde displayed n payment cards. Cardhlder Data Payment card data including: Primary Accunt Number (PAN), name f cardhlder, expiratin date and service cde. Sensitive Authenticatin Data - Full magnetic stripe data r equivalent n a chip, CAV2/CVC2/CVV2/CID r PINs/PIN blcks. Cardhlder Data Envirnment (CDE) - Area f cmputer system netwrk that pssesses cardhlder data r sensitive authenticatin data and thse systems and segments that directly attach r supprt cardhlder prcessing, strage, r transmissin. PDQ Machine A credit card swipe machine. PED PIN Entry Device. Payment Card Security (ISP-I10) V13 Page 1 f 8

2 Internal Security Assessr (ISA) A persn wh has been certified by the PCI Security Standards Cuncil t audit merchant they are emplyed by fr Payment Card Industry Data Security Standard (PCI DSS) cmpliance Qualified Security Assessr (QSA) A persn wh has been certified by the PCI Security Standards Cuncil t audit merchants fr Payment Card Industry Data Security Standard (PCI DSS) cmpliance This dcument includes statements n: 2. Scpe Scpe PCI DSS utline PCI DSS cmpliance plicy Authrisatin and respnsibilities Payment card prcessing Electrnic cardhlder data handling Paper cardhlder data handling Retentin f cardhlder data Physical security f payment card prcessing equipment 2.1. Plicy statements in this dcument apply t: All staff invlved in payment card prcessing All payment card prcessing arrangements acrss the University Bth manual and IT-based payment card prcessing 3. PCI DSS utline 3.1. The Payment Card Industry Data Security Standard (PCI DSS) sets ut an extensive and detailed list f requirements and security assessment prcedures. The gals and requirements f the standard (currently v3.1) are summarised as: Build and Maintain a Secure Netwrk Requirement 1: Install and maintain a firewall cnfiguratin t prtect cardhlder data Requirement 2: D nt use vendr-supplied defaults fr system passwrds and ther security parameters Prtect Cardhlder Data Requirement 3: Prtect stred cardhlder data Requirement 4: Encrypt transmissin f cardhlder data acrss pen, public netwrks Maintain a Vulnerability Management Prgram Requirement 5: Use and regularly update anti-virus sftware r prgrams Requirement 6: Develp and maintain secure systems and applicatins Implement Strng Access Cntrl Measures Requirement 7: Restrict access t cardhlder data by business need t knw Payment Card Security (ISP-I10) V13 Page 2 f 8

3 Requirement 8: Assign a unique ID t each persn with cmputer access Requirement 9: Restrict physical access t cardhlder data Regularly Mnitr and Test Netwrks Requirement 10: Track and mnitr all access t netwrk resurces and cardhlder data Requirement 11: Regularly test security systems and prcesses. Maintain an Infrmatin Security Plicy Requirement 12: Maintain a plicy that addresses infrmatin security fr all persnnel. 4. PCI DSS cmpliance plicy 4.1. All University card prcessing activities and related technlgies must cmply with the Payment Card Industry Data Security Standard (PCI-DSS) This plicy dcument frms part f University f Leicester infrmatin security plicy and directly meets the PCI DSS requirement t Maintain a plicy that addresses infrmatin security fr all persnnel Card prcessing activities must be cnducted as described herein and in accrdance with the PCI DSS standards. N activity may be cnducted nr any technlgy emplyed that might bstruct cmpliance with any prtin f the PCI-DSS All relevant staff must be made aware f the imprtance f cardhlder data security and must be aware f the requirements stated in this plicy This plicy shall be reviewed annually and updated as needed t reflect changes t business bjectives, t the risk envirnment r t PCI DSS The prspective prcurement f any slutin that includes card payment prcessing must be validated as being PCI-DSS cmpliant prir t purchase. As a requirement all prspective slutins must be cntractually specified as being PCI-DSS cmpliant within the University f Leicester s IT infrastructure. (Nte: Certain requirements stated in this plicy are nt part f the PCI DSS itself; hwever, are included t facilitate University PCI DSS cmpliance.) 5. Authrisatin and respnsibilities 5.1. Staff r departments must nt plan, cmmissin, use r mdify any payment card prcessing prcedures r systems withut cnsultatin with the Finance Office and authrisatin by the Finance Directr. (This includes any payment card prcessing activity t be undertaken n behalf f the University r which invlves any use f University IT r netwrking equipment.) 5.2. The Finance Office is respnsible fr managing PCI DSS cmpliance acrss the University and may remve any payment card prcessing activity causing unacceptable risk IT Services is respnsible fr arranging and assessing the results f the external and internal netwrk security scans required fr PCI DSS cmpliance. (Apprved external and internal netwrk scans must be run at least quarterly t check fr security against external access t any netwrked devices that prcess payment card data.) Payment Card Security (ISP-I10) V13 Page 3 f 8

4 5.4. The Finance Office and Infrmatin Assurance Services are jintly respnsible fr making all relevant staff aware f the imprtance f cardhlder data security and the requirements stated in this plicy The Finance Office is respnsible fr ensuring that fr service prviders with whm cardhlder infrmatin is shared: Cntracts require adherence t PCI-DSS by the service prvider. Cntracts include acknwledgement r respnsibility fr the security f cardhlder data by the service prvider. Their PCI DSS cmpliance status is mnitred at least annually A list f all staff currently authrised t rutinely use devices t prcess payment cards, such as tills, PEDs, PDQ machines etc. must be maintained by the department respnsible fr prviding that service and a cpy submitted t the Finance Incme Systems Specialist wh maintains the central lg Staff are reminded f the requirement t reprt security incidents and any suspected security weaknesses as specified in Reprting Infrmatin Security Incidents (ISP-I3) The Finance Office is respnsible fr maintaining a current list f all University payment card service prviders. 6. Payment card prcessing 6.1. Students wishing t pay curse fees by payment card must be directed t use the nline payment system (see 6.8). Where that is nt pssible anther frm f payment i.e. cheque, draft r bank transfer must be used instead Staff must nt request transmissin f any payment card infrmatin frm University custmers via , SMS/text, Skype, scial netwrking, Micrsft Lync r ther enduser messaging technlgies Departments shuld, under n circumstances, ask students/custmers t release the three-digit security cde held n the reverse f their card. (The University pays a higher payment card transactin fee t avid having t cllect and prcess the security cde.) 6.4. When staff prcess card details n a PED r PDQ credit card terminal, they shuld press the Enter key in rder t skip the three-digit security cde entry field. (Please nte this des nt apply t GPRS mbile terminals refer t 6.10) 6.5. Any electrnically stred legacy payment card data, r data stred in errr, must be deleted securely Payment card infrmatin, including full PAN numbers, must nt be displayed r made visible t anyne except authrised staff. Fr example, payment equipment such as tills must nt shw the full PAN. (The first six and last fur digits are the maximum number f digits that may be displayed.) 6.7. Full credit card numbers may nly be viewed by authrised staff with a need t see them as part f their duties Students must nt be specifically directed t University f Leicester IT equipment t use University f Leicester prvided nline payment slutins. If a student wishes t use Payment Card Security (ISP-I10) V13 Page 4 f 8

5 University IT infrastructure t make an nline payment, then it is their chice and nt mandated by the University Administratrs f the Recurring Card Payment, when setting up a new payment plan n behalf f a student, are permitted t ask fr the three digit security cde if prmpted by the system. This is an allwed exceptin t Finance prvides GPRS mbile PED fr shrt term. When making a MOTO payment, administratr s using this type f terminal maybe prmpted fr a CVV and are permitted t ask fr the three digit security cde if prmpted. This is an allwed exceptin t Electrnic cardhlder data handling 7.1. Staff must nt stre any electrnic payment card infrmatin, whether r nt encrypted, n any cmputers r strage devices whether by scanning, keying r any ther means. Nte: This applies t all types f payment card data including PAN, PIN, three-digit security cdes and full track data. This requirement limits the scpe f the CDE and s cntrls the cst, difficulty and feasibility f implementing and maintaining the PCI DSS cntrls necessary fr cmpliance Staff must nt send cardhlder data via , sms/text, Skype, scial netwrking, Micrsft Lync r ther end-user messaging technlgies, whether r nt encrypted Systems which are specifically designed and deplyed t transfer cardhlder data electrnically such as tills, PEDs and PDQs and utsurced e-cmmerce slutins must d s in a way that meets PCI DSS cmpliance requirements. When planning and deplying such systems, the Finance Office will wrk with departments, IT Services, system vendrs, ISAs and QSAs as apprpriate t achieve and maintain PCI DSS cmpliance Cmputers must nt be used by University staff t access utsurced e-cmmerce slutins, such as WPM r YESPay, n behalf f custmers University staff may nly use PDQ machines t make payments n behalf f custmers Authrised university staff may nly access the WPM Recurring Card Payment applicatin via the secure remte desktp & virtual server slutin prvided by IT Services Authrised university staff may nly access the Realex virtual terminal via the secure remte desktp & virtual server slutin prvided by IT Services. 8. Paper cardhlder data handling 8.1. The aim shuld be t reduce and preferably eliminate the need fr cardhlder data t be held in paper frm. Prcesses shuld be regularly reviewed t determine whether nline payment prcesses can be implemented t replace paper-based prcedures Sensitive card authenticatin data must nt be recrded n paper Cardhlder data stred n paper, which exclude sensitive authenticatin data, must be: Payment Card Security (ISP-I10) V13 Page 5 f 8

6 In a lcked cabinet whenever nt in use r supervised. Offices husing such cabinets must als be lcked when nt ccupied. Keys t afre mentined lcked cabinets and ffices shuld be kept securely at a lcatin away frm the lcked cabinet and ffice. Destryed when n lnger required by secure nsite crss-cut shredding, incineratin r pulping. (Paper recrds hlding unwanted payment card infrmatin must be lcked away until destryed.) (als see 9.2 belw.) Marked t distinguish it frm ther paperwrk. Departments may use their wn classificatin and marking system fr cardhlder data paperwrk. A suitable slutin wuld, fr example, be t use distinctively clured statinery. Phtcpies f credit cards shuld never be taken r stred Where it is necessary t transfer paper cardhlder data within the site: The nly acceptable methd is delivery by hand during ffice hurs. The internal mail system must nt be used. Card hlder data mvement must be lgged with a despatch recrd and crrespnding received recrd. Bth shuld be recnciled t ensure mvement f the data is cmplete. Card hlder data when being transprted shuld be in a sealed envelpe r packet Incming mail cntaining cardhlder data frm utside the University may be received thrugh the internal mail system. Hwever, regard shuld be had t Sectin 8.1 with a view t eliminating the need fr paper-based prcesses There shuld nt be any requirement fr cardhlder data t be sent via an external pstal service. Hwever, if in exceptinal circumstances a need shuld arise, apprval must be first btained frm the Directr f Finance. In such cases the data must be delivered by hand t the Pst Rm and a tracked curier service must be used A recrd must be kept detailing any transfer f payment card data within the University and by external pstal service shuld a need arise. Management apprval is required prir t the transfer The use f faxes t receive card data shuld be discuraged, hwever if it is necessary t receive a fax, then the fax machine being used shuld nt have an internal memry, hard drive r ther strage slutin capable f recrding details f the received fax University multi-functinal devices, netwrk fax machines r cmputer based fax slutins shuld nt be used t receive card data. 9. Retentin f cardhlder data 9.1. Cardhlder data, excluding any sensitive authenticatin data, may be retained nly as paper recrds. The nly acceptable card hlder data stred as paper recrds after prcessing a custmer credit card are Merchant Receipts generated by: Finance distributed Chip & Pin devices University EPOS system Chip & Pin devices Chip & Pin devices cnnected t XN sprts management system Hwever it shuld be nted that under nrmal business prcedures merchant receipts d Payment Card Security (ISP-I10) V13 Page 6 f 8

7 nt display the full pan and that paper recrds f the PAN number after prcessing are nt kept. (See 9.6) 9.2. Except in exceptinal circumstances and with explicit apprval f the Finance Office, retained cardhlder data fr any financial year (August-July) must be destryed by the end f the fllwing January Card hlder data that is due t be destryed must be secured in lcked cntainers prir t destructin. The cntent shuld nt be accessible Card hlder data will be destryed by the University s shredding service, using a means that makes it impssible t recnstitute the cntent f the paper based media Audits will be cnducted by the Finance Office t ensure destructin The retentin f card hlder data after it has been prcessed is nly permitted after written cnfirmatin by the Deputy Directr f Finance, subject t the team/ department/ staff member having: A prven business reasn t retain card hlder data The necessary prcesses and prcedures in place t secure the card hlder data in a cmpliant manner. A prven data management prcess that supprts auditing, remval and secure destructin f the card hlder data when n lnger required. 10. Physical security f payment card prcessing equipment Devices used t prcess payment cards, such as tills, PEDs and PDQ machines must: Only be used by staff authrised t d s as part f their duties. Be prtected frm physical access ut-f-hurs by thse nt authrised t use the equipment r authrised t be in the area. (Small devices such as PDQs must be lcked away and larger devices such as tills must be in rms with restricted access when nt in use.) Be subjected t rutine visual inspectin, preferably each day r befre use. Equipment, cabling and cnnectins shuld be inspected fr signs f tampering. The wrking area in the vicinity f the equipment shuld be checked fr any suspicius devices, hidden cameras etc. Nt be taken ff site fr testing, repair r use withut written apprval f a senir member f the Finance team Out-f-hurs visitrs t areas giving access t payment equipment must be supervised and details f such visits must be lgged The installatin f new r replacement equipment must be validated and apprved by Finance wrking with IT services t ensure security f payment equipment has nt been cmprmised Payment devices must nt be psitined where University CCTV cameras can pick up card numbers, pin numbers and/r secure card data The use f University issued r persnal vide recrding devices by University Staff must nt be used in the vicinity where card numbers, pin numbers r secure card data can Payment Card Security (ISP-I10) V13 Page 7 f 8

8 be bserved. This includes bdy cameras, Ggle Glass (and similar) and mbile phne cameras. Custmers shuld be asked t deactivate any such device if they are in the vicinity f a card payment device. Failure t cmply with University Plicy may lead t disciplinary actin. The fficial versin f this dcument will be maintained n-line. Befre referring t any printed cpies please ensure that they are up-t-date. Payment Card Security (ISP-I10) V13 Page 8 f 8