AUSTRALIAN PAYMENTS CLEARING ASSOCIATION LIMITED ABN Manual CONSUMER ELECTRONIC CLEARING SYSTEM FRAMEWORK (CS3)

Transcription

1 Effective: 1 January 2015 Version 300 AUSTRALIAN PAYMENTS CLEARING ASSOCIATION LIMITED ABN A Company Limited by Guarantee Manual for CONSUMER ELECTRONIC CLEARING SYSTEM FRAMEWORK (CS3) Volume 1 Introduction and Member Obligations Commenced 14 December 2000 Copyright Australian Payments Clearing Association Limited ABN Australian Payments Clearing Association Limited Level 6, 14 Martin Place, SYDNEY NSW 2000 Telephone: (02) Facsimile: (02)

2 INDEX Manual for CONSUMER ELECTRONIC CLEARING SYSTEM FRAMEWORK (CS3) Volume 1 Introduction and Member Obligations INDEX PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Purpose of this manual CECS requirements APCA Application of these requirements Relationship with other standards or guidelines Standards development Inconsistencies Governing Law Interpretation Definitions PART 2 FRAMEWORK PARTICIPANT OBLIGATIONS Adherence to standards Issuers Acquirers Third Party Providers Compromised Terminals Acquirer Actions Issuer Actions Change Management Provision of statistics Terminal statistics Card fraud data Notification of a Disruptive Event Crisis Management Action Planning CECS Operational Broadcast How to Send an CECS Operational Broadcast BIN and AIN Change Management BIN and AIN Change Database Production of test cards Capacity Planning i

3 INDEX PART 3 CERTIFICATION Introduction Annual Security Audits Submission of Annual Security Audit Third Party Providers Auditor Signoff Exemption Requests Exemption Process Exemption Duration Introduction of New or Modified Devices or New Processes Certification of Prospective Framework Participant Guidance for External Auditors Review of Certification documentation ANNEXURE A ANNUAL SECURITY AUDITS... A.1 A.1 Acquirer Annual Security Audit (Part 1)... A.1 A.1.1 General Security Controls... A.1 A.1.2 Device Management... A.5 A.1.3 Supplementary Questions for Acquirers who are submitting Visa Audits. A.6 A.2 Acquirer Annual Security Audit (Part 2)... A.8 A.2.1 General Security Controls... A.8 A.2.2 Device Management... A.10 A.2.3 General Key Management... A.11 A.3 Issuer Annual Security Audit... A.18 A.3.1 General Security Controls... A.18 A.3.2 Device Management... A.21 A.3.3 Key Management... A.21 ANNEXURE B NEW FRAMEWORK PARTICIPANT CERTIFICATION... B.1 B.1 Acquirer Certification Checklist... B.1 B.2 Issuer Certification Checklist... B.3 ANNEXURE C EXEMPTION REQUEST FORM... C.1 ANNEXURE D CECS OPERATIONAL BROADCAST FORM... D.1 ii

4 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS 1.1 Purpose of this manual The CECS has been established to provide a consistent set of standards, practices and services for those aspects of card payments system management that are best handled at an industry level. These include minimum security standards, interoperability standards and value added services that support how payment cards are used throughout Australia. These standards and requirements are contained within the CECS Manual which is structured as follows: CECS Regulations Volume 1 Introduction & Member Obligations Volume 2 Issuer Requirements Volume 3 Acquirer Requirements Volume 4 Device Requirements & Cryptographic Management Volume 5 Settlement Volume 6 ATM Requirements Volume 1, this volume, provides an introduction to the CECS standards and services. In addition it identifies those obligations that CECS participation imposes on its members, referred to as Framework Participants. Volume 2 is intended for Issuers and contains those aspects of PIN security that are considered mandatory for all Issuers participating within the CECS. In addition this volume contains guidance and recommendations into nonmandatory aspects of Issuer PIN management. Volume 3 of the CECS Manual is intended for Acquirers and contains those aspects of PIN based Transaction security that are considered mandatory for all Acquirers participating within the CECS. In addition this volume contains device management requirements applying to all acquiring members participating in the CECS. Volume 4 identifies the security requirements applicable to Terminals, Security Control Modules and Key Injection and Loading devices that apply to all Secure Cryptographic Devices suitable for use under the CECS. Additionally it describes the approval process for those devices and the necessary requirements and process that enable an evaluation facility to seek approval for it to conduct device evaluations. This volume also specifies the minimum cryptographic algorithms, key lengths and processes that apply to all PINs and Transactions exchanged under the CECS. Volume 5 provides the operational practices and processes involved in CECS settlement. 1.1

5 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Volume 6 provides both the technical and operational aspects of ATM support under the CECS. Other supplementary documents supporting the CECS include the APCA Specification for a Security Control Module Function Set and the KIF Audit Guidelines. 1.2 CECS requirements APCA Ensuring appropriate security and other technical requirements is essential to the integrity of card payments. APCA administers certification procedures which are aimed at ensuring that Issuers and Acquirers meet prescribed technical, operational and security requirements. APCA s technical and security working groups which report to the CECS Management Committee develop requirements to be implemented industry wide through CECS Application of these requirements Inclusions CECS requirements apply to any Transaction which results in the exchange of an Item across a bilateral link, regardless of the type of Card and/or account being used and/or accessed. This means that the CECS requirements apply to: (i) (ii) all domestically acquired Transactions initiated with a non-scheme debit card, including Transactions initiated with the debit functionality of a Card that also has international card scheme credit and/or debit functionality; and Transactions initiated with an international card scheme credit or debit card which result in the exchange of an Item across a bilateral link (such as nearly all ATM Transactions initiated with a domestic scheme credit card or debit card). Exclusions Other than as described above, CECS requirements do not apply directly to the electronic processing of credit card Transactions and other international scheme Transactions. These are governed by the rules and regulations published by the various card schemes. 1.2

6 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Relationship with other standards or guidelines This Manual cross-refers to a number of existing standards and guidelines published by bodies other than APCA that apply to Framework Participants, in their various capacities, in consumer electronic Transactions and which may apply to Framework Participants either independently of or by virtue of their incorporation by reference in this Manual. The requirements of these separate schemes, standards or guidelines have not been duplicated in this Manual and Framework Participants are expected to have familiarised themselves with and adhere to their responsibilities under all such applicable requirements, as a separate matter from the specific standards and requirements which are detailed in this Manual. These existing schemes, requirements and guidelines include: Standard or Guideline Card Schemes Application All Issuers and Acquirers party to particular schemes All Framework Participants Monitor Various epayments Code Australian Securities and Investments Commission Guidelines for All Acquirers Australian Securities and EFT Security Investments Commission AS 2805 All Framework Participants Standards Australia ISO 9564 All Framework Participants International Standards Organization ISO All Framework Participants International Standards Organization Standards development In support of the CECS membership, and to further develop relevant CECS standards, APCA will maintain an active involvement in relevant standards development bodies, including but not limited to: (c) (d) Standards Australia relevant working groups and committees; International Standards Organization relevant working groups and committees; PCI Security Standards Council; EMV Co relevant working groups Inconsistencies If a provision of the Regulations or this Manual is inconsistent with a provision of the Constitution, the provision of the Constitution prevails. If a provision of this Manual is inconsistent with a provision of the Regulations, the provision of the Regulations prevails. 1.3

7 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Governing Law This Manual is to be interpreted in accordance with the same laws which govern the interpretation of the Constitution. 1.3 Interpretation In this Manual: (c) (d) (e) (f) (g) (h) (i) (j) words importing any one gender include the other gender; the word person includes a firm, body corporate, an unincorporated association or an authority; the singular includes the plural and vice versa; unless the contrary intention appears, a reference to a clause, part or annexure is a reference to a clause, part or annexure of the volume of the Manual in which the reference appears; a reference to a statute, code or the Corporations Law (or to a provision of a statute, code or the Corporations Law) means the statute, the code, the Corporations Law or the provisions as modified or amended and in operation for the time being, or any statute, code or provision enacted in lieu thereof and includes any regulation or rule for the time being in force under the statute, the code, the Corporations Law or the provision; a reference to a specific time means that time in Sydney unless the context requires otherwise; words defined in the Corporations Law have, unless the contrary intention appears, the same meaning in this Manual; words defined in the Regulations have, unless the contrary intention appears, the same meaning in this Manual; this Manual has been determined by the Management Committee and takes effect on the date specified by the Chief Executive Officer pursuant to Regulation 1.2; and headings are inserted for convenience and do not affect the interpretation of this Manual. 1.4 Definitions In this Manual the following words have the following meanings unless the contrary intention appears. Acquirer means a body corporate that in connection with a Transaction: 1.4

8 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS under arrangement with and on behalf of an Issuer, discharges the obligations owed by that Issuer to the relevant Cardholder; and engages in Interchange with that Issuer as a result. Acquirer Reference Number in relation to an Acquirer means a reference number which is unique to that Acquirer, allocated to it for identification purposes by the International Organisation for Standardization. Acquirer Identification Number and AIN The six-digit number assigned by ISO to identify an acquiring Framework Participant. (see also IIN, BIN). Approved Evaluation Facility means a testing laboratory that has been accredited by the Company to conduct SCD security compliance testing. AS means Australian Standard as published by Standards Australia. ATM means an approved electronic device capable of automatically dispensing Cash in response to a Cash withdrawal Transaction initiated by a Cardholder. Other Transactions (initiated by a debit card) such as funds transfers, deposits and balance enquiries may also be supported. The device must accept either magnetic stripe Cards or smart (chip) Cards where Transactions are initiated by the Cardholder keying in a Personal Identification Number (PIN). Limited service devices (known as Cash dispensers ) that only allow for Cash withdrawal are included. ATM Direct Charging Date means 3 March ATM Operator Fee means a fee paid by a Cardholder to the operator of an ATM to effect a Transaction through their Terminal. ATM Transaction means a Cash deposit, a Cash withdrawal, or a balance enquiry effected by a Cardholder at an ATM. Australian IC Card means an IC Card in respect of which the EMV Issuer Country Code data element (tag 5F28) equal to 036 (Australia). Authorisation in relation to a Transaction, means confirmation given by an Issuer that funds will be made available for the benefit of an Acquirer, in accordance with the terms of the relevant Interchange Agreement, to the amount of that Transaction. Except in the circumstances specified in this Manual, Authorisation is effected online. Authorised has a corresponding meaning. Authorised Device means a Secure Cryptographic Device that has been evaluated in accordance with CECS Manual Volume 4 (Device Requirements and Cryptographic Management) and which has been approved for use within CECS by the Company. 1.5

9 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Bank Identification Number and BIN means the registered identification number allocated by Standards Australia Limited in accordance with AS 3523 (also known as an Issuer Identification Number (IIN)). Card means any card capable of being read by a Terminal including a debit card, prepaid card and credit card. Cardholder means a customer of an Issuer who has been issued with a Card by that Issuer, enabling that customer to effect Transactions. Cash means Australian legal tender. CECS means the Consumer Electronic Clearing System (CS3). CECS Operational Broadcast means the form set out in Annexure D to CECS Manual Volume 1 (Introduction and Member Obligations). Certification has the meaning given in Part 3 of CECS Manual Volume 1 (Introduction and Member Obligations). Certification Checklist means in relation to an Acquirer, a checklist in the form of Annexure B.1 in CECS Manual Volume 1 (Introduction and Member Obligations) and in relation to an Issuer, a checklist in the form of Annexure B.2 in CECS Manual Volume 1 (Introduction and Member Obligations). Commencement Date means the date specified as such for CECS under Regulation 1.2. Compliance Certificate means a certificate issued by the Company to a requesting party evidencing successful Certification. Company means the Australian Payments Clearing Association Limited (A.C.N ). Compromised Terminal means a Terminal that has been tampered with for fraudulent purposes. Constitution means the constitution of the Company as amended from time to time. Corporations Law means the Corporations Act 2001 (Cth) and associated subordinate legislation as amended from time to time. Counterparty means the CECS Framework Participant direct settler (for example, an Issuer) identified in a File Settlement Instruction submitted by an Originator (for example, an Acquirer or Lead Institution), in accordance with this Manual and the requirements of the RITS Low Value Settlement Service. 1.6

10 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Credit Items includes all credit payment instructions, usually electronically transmitted, which give rise to Interchange, except as may be specifically excluded by the Regulations or this Manual. Crisis Management Action Plan [Deleted] Deleted effective Debit Items includes all debit payment instructions, usually electronically transmitted, which give rise to Interchange, except as may be specifically excluded by the Regulations or this Manual. Disputed Transaction means a Transaction which the Cardholder denies having initiated or where the Transaction amount is claimed to be incorrect. Disruptive Event means any processing, communications or other failure of a technical nature, which affects, or may affect, the ability of any CECS Framework Participant to Interchange. (Note: examples of a Disruptive Event are described in Volume 1.) Double-length Key means a key of length 128 bits including parity bits or 112 bits excluding parity bits. Doubtful Transactions means those Transactions which may not have been successfully completed, although the Transaction may be recorded against a relevant account. EFT means Electronic Funds Transfer. EFTPOS means Electronic Funds Transfer at Point of Sale. EMV means the specifications as published by EMV Co. LLC. EMV Phase 1 means the current transition arrangements through which a Transaction is created from the use of an EMV compliant Australian IC Card prior to the migration of the ATM system to full EMV functionality. (Note: a date for the migration of the ATM system to full EMV functionality has not yet been determined). epayments Code means the code of conduct administered by the Australian Securities and Investments Commission. Encrypting PIN Pad and EPP means a component of a Terminal that provides secure PIN entry and cryptographic services. Encapsulating Security Payload and ESP is a member of the IPsec protocol suite providing origin authenticity, integrity, and confidentiality protection of packets in tunnel mode, where the entire original IP packet is encapsulated, with a new packet header added which remains unprotected. 1.7

11 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Error of Magnitude means an error (or a series of errors) of or exceeding $2 million or such other amount as may be determined from time to time by the Management Committee. ESA means Exchange Settlement Account. Evaluation Facility in relation to the approval of a Secure Cryptographic Device for: an Acquirer, means an entity approved by the Management Committee in accordance with, and for purposes of, CECS Manual Volume 4 (Device Requirements and Cryptographic Management); and an Issuer, means an entity approved by the Management Committee in accordance with, and for purposes of CECS Manual Volume 4 (Device Requirements and Cryptographic Management). Exchange Settlement Account and ESA means an exchange settlement account, or similar account, maintained with the Reserve Bank of Australia. File Recall Instruction means a file in the format prescribed by the Reserve Bank of Australia and complying with the specifications for the RITS Low Value Settlement Service which can be accessed via a link on the Company s extranet. File Recall Response means a response to a File Recall Instruction, generated by the RITS Low Value Settlement Service. File Settlement Advice means an advice in relation to a File Settlement Instruction, generated by the RITS Low Value Settlement Service. File Settlement Instruction means a file in the format prescribed by the Reserve Bank of Australia and complying with the specifications for the RITS Low Value Settlement Service which can be accessed via a link on the Company s extranet. File Settlement Response means a response to a File Settlement Instruction, generated by the RITS Low Value Settlement Service. Framework Participant means a body corporate, which in accordance with the Regulations is a participant in CECS. HMAC and Hash-based Message Authentication Code is a specific construction for calculating a message authentication code (MAC) involving a cryptographic hash function in combination with a secret key. HMACs are formed in conformance with AS2805:4.2 Electronic funds transfer Requirements for interfaces Information technology -- Security techniques -- Message Authentication Codes (MACs) - Mechanisms using a dedicated hashfunction. 1.8

12 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Hot Card means a Card which has been reported by the Cardholder as lost or stolen, or for which there is evidence of fraudulent use. IC Card and ICC means a Card that contains an integrated circuit and that conforms to the EMV specifications. Institutional Identifier Change Date means one of at least three dates in each calendar year specified by the Management Committee and notified by the Company to CECS Framework Participants prior to the commencement of that calendar year as being the Institutional Identifier Change Dates for that year. Interchange means the exchange of Items for value between Acquirers and Issuers, via an Interchange Link, as a result of the use of an Issuer s Card by a Cardholder to generate a Transaction. Interchange arrangements may, but need not, be reciprocal. Interchange Agreement means an agreement between an Acquirer and an Issuer that regulates the arrangements relating to Interchange between them. Interchange Fee means a fee charged to one party to an Interchange by the other party to the Interchange for access to its consumer electronic payments facilities. Interchange Line means the physical communications infrastructure that provides the medium over which Interchange is supported. An Interchange Line contains, at a minimum, one Interchange Link. Interchange Line Encryption means encryption of the entire message, with the exception of communication headers and trailers that is being passed across an Interchange Line using, as a minimum, double-length keys and a triple-des process. Interchange Link means the logical link between an Acquirer and an Issuer which facilitates Interchange between them. Interchange Links are supported physically by an Interchange Line, and are either direct between an Acquirer and Issuer or indirect via a third party intermediary. Interchange Link Message Authentication means calculation and verification of the Message Authentication Code (MAC) that is being passed across an Interchange Link. Interchange Link PIN Encryption means encryption of the PIN in accordance with AS 2805 part 3.1. Interchange Settlement Report means a report substantially in the form of Annexure A in CECS Manual Volume 5 (Settlement). Internet Key Exchange and IKE is the protocol used to set up a security association in the IPsec protocol suite. 1.9

13 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Issuer means a body corporate which issues a Card to a Cardholder and, in connection with any Transaction effected using that Card: assumes obligations to the relevant Cardholder, which obligations are in the first instance discharged on its behalf by an Acquirer; and engages in Interchange with that Acquirer as a result. Issuer Identification Number and IIN means a six digit number issued by ISO or Standards Australia that identifies the major industry and the card issuer. The IIN also forms the first part of the primary account number on the Card. ISO means an international standard as published by the International Standards Organization. Issuer Sequence Number means a one or two digit number used at the option of the Issuer to identify a Card which may have the same primary account number as another Card and possible different accessible linked accounts. Items means Debit Items or Credit Items. Key Encrypting Key and KEK means a key which is used to encipher other keys in transport and which can be used to exchange Session Keys between two systems. Key Loading Device and KLD means a hardware device and its associated software that is used to inject keys into a Terminal. Key Transfer Device and KTD means a hardware device that is used to transfer a cryptographic key between devices. Typically KTDs are used to transfer keys from the point of creation to Terminals in the field. Lead Institution means a financial institution responsible for direct settlement of scheme payment obligations. Letter of Approval means a letter, issued by the Company, approving the use of a Secure Cryptographic Device within CECS. LVSS means the RITS Low Value Settlement Service. LVSS BCP Arrangements means the contingency plan and associated documents published by the Reserve Bank of Australia for the purposes of the RITS Low Value Settlement Service, and which can be accessed via a link on the Company s extranet. LVSS Contact means the person nominated by a CECS Framework Participant as its primary contact for LVSS inquiries, as listed on the Company s extranet. 1.10

14 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Management Committee means the committee constituted under Part 7 of the Regulations. Manual means the composite set of six volumes of the CECS Manual as amended from time to time. Merchant means a person which delivers goods or services to a Cardholder at point of sale and which, in the normal course, is reimbursed by the Acquirer to which, from the Terminal that it operates, it electronically transmits that Transaction. Merchant Principal is a participant in an EFTPOS system that is a merchant that sends transactions directly to issuers rather than through an acquirer and takes on the responsibilities usually undertaken by an acquirer. Message Authentication Code and MAC A code, formed using a secret key, appended to a message to detect whether the message has been altered (data integrity) and to provide data origin authentication, MACs are formed in conformance with AS 2805 part 4 series. Nine AM (9am) Settlement means the multilateral settlement of obligations arising from previous days clearings of low value payments which occurs in RITS at around 9am each business day that RITS is open. NODE or Node means a processing centre such as an Acquirer, an Issuer, or an intermediate network facility. Originator means the party (for example an Acquirer direct settler or Lead Institution) which, as a result of either acquiring a Transaction or, in the case of a Lead Institution, by arrangement, is responsible for the submission of a File Settlement Instruction in accordance with this Manual and the requirements of the RITS Low Value Settlement Service. Partial Dispense means a Transaction that results in an amount of Cash being dispensed from an ATM that is less than the amount requested by the Cardholder. PCI means the Payment Card Industry Security Standards Council. PCI Evaluation Report means an evaluation report, prepared by an Approved Evaluation Facility, which evidences the compliance of a device submitted for approval under Part 3 of CECS Manual Volume 4 (Device Requirements and Cryptographic Management) with the requirements set out in PCI PTS version 3.x. (PCI standards can be found at

15 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS PCI Plus Evaluation Report means an evaluation report, prepared by an Approved Evaluation Facility, which evidences the compliance of a device submitted for approval under Part 3 of Volume 4 with the PCI Plus Requirements, and if applicable, includes any delta report prepared in respect of the device. PCI Plus Requirements means the requirements set out in Annexure B of CECS Manual Volume 4 (Device Requirements and Cryptographic Management), being requirements for device approval in accordance with AS 2805 Annexes A, B and D, which are determined by the Company to be additional to the requirements of PCI PTS v 3.x. PCI Points means the attack potential calculated in accordance with Appendix B of the Payments Card Industry (PCI) document PCI PIN Transaction Security Point of Interaction Modular Derived Test Requirements, version 3.0, PED means a PIN Entry Device. Physically Secure Device means a device meeting the requirements specified in AS 2805 part 3.1 for a physically secure device. Such a device, when operated in its intended manner and environment, cannot be successfully penetrated or manipulated to disclose all or part of any cryptographic key, PIN, or other secret value resident within the device. Penetration of such a device shall cause the automatic and immediate erasure of all PINs, cryptographic keys and other secret values contained within the device. PIN means a personal identification number which is either issued by an Issuer, or selected by a Cardholder for the purpose of authenticating the Cardholder by the Issuer of the Card. Pin Entry Device and PED means a component of a Terminal which provides for the secure entry and encryption of PINs in processing a Transaction. Prepaid Card means a Card that: enables the Prepaid Cardholder to initiate electronic funds transfers up to a specified amount (subject to any other conditions that may apply); and draws on funds held by the Prepaid Program Provider or third party by arrangement with the Program Provider (as opposed to funds held by the Prepaid Cardholder). The definition of a Prepaid Card extends to both single use and reloadable/multiple use Cards. Prepaid Cardholder means a person that is in possession of a Prepaid Card. Prepaid Program Provider means either: 1.12

16 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS (c) (d) an Issuer that issues a Prepaid Card; or a person that issues a Prepaid Card in conjunction with a sponsoring Issuer. Record of Transaction has the meaning given in the epayments Code and CECS Manual Volume 3 (Acquirer Requirements). Regulations means the regulations for CECS, as prescribed by the Company. Remote Management Solution and RMS means a solution comprising both hardware and software which connects to an SCM over a network and provides access to an SCM while it is in a sensitive state. Retained Card in relation to an ATM Transaction, has the meaning given in clause 2.8 of CECS Manual Volume 6 (ATM Requirements). RITS means the Reserve Bank Information and Transfer System. RITS Low Value Settlement Service means the Reserve Bank s settlement file transfer facility which must be used by: each Acquirer and Lead Institution to submit File Settlement Instructions and associated File Recall Instructions; and each Acquirer, Lead Institution and Issuer, if it so elects, to receive File Settlement Advices, File Settlement Responses and File Recall Responses. RITS Regulations means the regulations for RITS published by the Reserve Bank of Australia. Secure Cryptographic Device and SCD a device that provides physically and logically protected cryptographic or PIN handling services and storage e.g., PIN entry device, Key Injection Device or hardware security module. SCD Security Standards in relation to an SCD, means the standards from time to time published in CECS Manual Volume 4 (Device Requirements and Cryptographic Management). SCM means a Security Control Module sometimes referred to as a host security module (HSM). Secretary means the person appointed under Regulation 7.14 to perform the duties of secretary of the Management Committee. Security Control Module and SCM means a physically and logically protected hardware device that provides a set of secure cryptographic services. 1.13

17 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS Session Key is a generic reference to any one of a group of keys used to protect Transaction level data. Session keys exist between two discrete points within a network (e.g., host-to-host and host-to-terminal). Sponsor means the Acquirer which, as among all Acquirers for a Terminal, is taken to be the lead Acquirer for that Terminal, with ultimate responsibility for the integrity and security of PED software and encryption keys for Transactions involving that Terminal. Statistically Unique means an acceptably low statistical probability of an entity being duplicated by either chance or intent. Technically, statistically unique is defined as follows: For the generation of n-bit quantities, the probability of two values repeating is less than or equal to the probability of two n-bit random quantities repeating. Thus, an element chosen from a finite set of 2n elements is said to be statistically unique if the process that governs the selection of this element provides a guarantee that for any integer L the probability that all of the first L selected elements are different is no smaller than the probability of this happening when the elements are drawn uniformly at random from the set. Tamper-responsive SCM means a Security Control Module that when operated in its intended manner and environment, will cause the immediate and automatic erasure of all keys and other secret data and all useful residues of such data when subjected to any feasible attack. A Tamper-responsive SCM must comply with the requirements of CECS Manual Volume 4 (Device Requirements and Cryptographic Management). Terminal means an electronic device containing a PED which can be used to complete a Transaction. Terminal Identification Number means the unique identification number assigned by an Acquirer to identify a particular Terminal. Terminal Sequence Number means a number allocated sequentially to each Transaction by the relevant Terminal. Third Party Provider means a body corporate which provides an outsourced facility to a CECS Framework Participant for any function involving: Amended effective (c) (d) interchange; PIN processing; transaction processing; key management; or 1.14

18 PART 1 INTRODUCTION, INTERPRETATION AND DEFINITIONS (e) any other service which directly or indirectly supports any of the functions described in clauses to (d) above. Transaction means a Transaction initiated by a Cardholder which allows for the accessing of available funds held in an account, or account information. Track Two Equivalent Data means the contents of the EMV data element tag 57. This data element contains the data elements of track two according to AS , excluding start sentinel, end sentinel and Longitudinal Redundancy Check. Triple-DES means the encryption and decryption of data using a defined compound operation of the DEA-1 encryption and decryption operations. Triple-DES is described in AS2805 Part 5.4. Unattended Device has the meaning given in clause in CECS Manual Volume 4 (Device Requirements and Cryptographic Management). Unattended Payment Terminal and UPT means a Terminal intended for deployment in an EFTPOS network without Merchant oversight. Next page is

19 PART 2 FRAMEWORK PARTICIPANT OBLIGATIONS PART 2 FRAMEWORK PARTICIPANT OBLIGATIONS 2.1 Adherence to standards Issuers Subject to clause 4.1 of the Regulations, Issuers must ensure that they and their Third Party Providers ensure: (c) PIN security complies with the requirements specified in CECS Manual Volume 2 (Issuer Requirements); Any SCMs used in CECS Interchange comply with both the APCA SCM Specification and CECS Manual Volume 4 (Device Requirements and Cryptographic Management) and are approved for use by the Company; and Settlement procedures comply with the requirements and processes given in CECS Manual Volume 5 (Settlement) Acquirers Subject to clause 4.1 of the Regulations, Acquirers must ensure that they and their Third Party Providers ensure: (c) (d) (e) (f) PIN security complies with all relevant requirements given in the CECS Manual Volume 3 (Acquirer Requirements); ATM requirements and procedures comply with all aspects of CECS Manual Volume 6 (ATM Requirements); any SCMs used in CECS Interchange comply with both the and CECS Manual Volume 4 (Device Requirements and Cryptographic Management) and are approved for use by the Company; any SCDs used in CECS Interchange comply with the security requirements specified in CECS Manual Volume 4 (Device Requirements and Cryptographic Management) and are approved for use by the Company; settlement procedures comply with the requirements and processes given in CECS Manual Volume 5 (Settlement); all Key Injection Services and Devices comply with the relevant requirements specified in CECS Manual Volume 4 (Device Requirements and Cryptographic Management); and 2.1

20 PART 2 FRAMEWORK PARTICIPANT OBLIGATIONS (g) all parties to the Interchange, including merchants and any intermediate network entities maintain procedures and practices for preventing the unauthorised disclosure of Cardholder Data and ensure that unencrypted authentication is not stored outside of an SCD (see CECS Manual Volume 3 (Acquirer Requirements)). 2.2 Third Party Providers Amended effective (c) A Framework Participant may contractually engage one or more Third Party Providers to provide outsourced services and functions, which may include services procured to satisfy the Framework Participant s obligation to perform specific CECS functions and requirements. It is the responsibility of the Framework Participant to verify the capacity of its Third Party Provider to provide the outsourced services and functions. It is the responsibility of the Framework Participant to manage, direct and control the provision of outsourced services and functions by its Third Party Providers, and to ensure such Third Party Providers and any subcontractor engaged by the Third Party Provider are contractually obliged to comply with all applicable CECS standards and requirements. 2.3 Compromised Terminals Clauses to are Confidential Acquirer Actions Issuer Actions 2.4 Change Management Any proposal to modify or upgrade an existing Interchange that also involves changes by the other party to the Interchange, must be advised by the applicant to the Framework Participant affected no less than 180 days (unless otherwise bilaterally agreed) prior to the date upon which the proposal is to be implemented ( Implementation Date ). Each Framework Participant must use reasonable endeavours to make such changes to its own Interchanges by the Implementation Date, or a date otherwise bilaterally agreed, as may be necessary to give effect to a proposal notified to it under this clause. 2.2

21 PART 2 FRAMEWORK PARTICIPANT OBLIGATIONS 2.5 Provision of statistics Terminal statistics Acquirers must report to the Company the number of ATM and EFTPOS terminals they deploy on a state by state basis for the periods ending on December, March, June and September. The report must separately identify those terminals which the Acquirer directly owns and any other terminals for which it provides acquiring services (e.g., white label terminals owned by a third party). Consolidated figures will be provided to all Framework Participants and also made available from the CECS ATM and EFTPOS Statistics Database facility found on APCA s Extranet Card fraud data ( e?openview) Issuers must report card fraud data to the Company on a monthly basis. Information in the report must comply with the requirements set out by the Company and made available from time to time on APCA s extranet. ( ydate?openview&start=1&count=100&expand=1)) Consolidated figures will be provided to all Framework Participants and also made available from the CECS Card Fraud Database facility found on APCA s Extranet. ( View&Login) 2.6 Notification of a Disruptive Event A Framework Participant that experiences a Disruptive Event must notify the Company and all Framework Participants that will or are likely to be affected by the Disruptive Event as soon as possible. Notification of a Disruptive Event must be given to the operational contacts listed on APCA s Extranet and subsequently by a CECS Operational Broadcast (see clause 2.8). 2.3

22 PART 2 FRAMEWORK PARTICIPANT OBLIGATIONS Upon notice of a Disruptive Event, the Chief Executive Officer may, if he considers it appropriate to do so, invoke the Member Incident Plan which is available on the Company s Extranet, either by written notice to, or verbally notifying the Management Committee. The Member Incident Plan provides a framework for Management Committee communication and consultation during applicable contingency events. If the Chief Executive Officer invokes the Member Incident Plan, the Management Committee must comply with its requirements. 2.7 Crisis Management Action Planning Deleted effective CECS Operational Broadcast Framework Participants may provide operational advice to other Framework Participants by issuing an CECS Operational Broadcast (set out in Annexure D). The CECS Operational Broadcast form may be used to notify other Framework Participants about: (i) (ii) (iii) (iv) (v) unscheduled network outages; scheduled network outages; to facilitate the exchange of general operational information relevant to network operations; Disruptive Events; or any technical inability to comply with a notification given by the Secretary under Part 5 of the Regulations (BIN and AIN Changes) How to Send an CECS Operational Broadcast The CECS Operational Broadcast form is an online form which can be accessed, completed and sent by Framework Participants using APCA s extranet that is available and processed 24/7. An CECS Operational Broadcast about a Disruptive Event must include the following information: (i) (ii) (iii) the time when the Disruptive Event commenced or is expected to commence; the time when normal processing is expected to resume or resumed; and the current status of the Disruptive Event. 2.4

23 PART 2 FRAMEWORK PARTICIPANT OBLIGATIONS 2.9 BIN and AIN Change Management This clause 2.9 applies to those BINs and AINs involved in bilateral interchange BIN and AIN Change Database (c) (d) (e) Other than in the context of a new direct clearing and settlement arrangement, the introduction of a new BIN or AIN, or deletion of or change in the routing of an existing BIN or AIN must occur on an Institutional Identifier Change Date. A Framework Participant wishing to introduce a new BIN or AIN, or change the routing of an existing BIN or AIN, must give the Secretary no less than 10 weeks notice in advance of the relevant Institutional Identifier Change Date on which such change is to occur. A Framework Participant wishing to delete an existing BIN or AIN must give the Secretary no less than 10 weeks notice in advance of the relevant Institutional Identifier Change Date on which such change is to occur. The Secretary must promptly notify all Framework Participants of the new BIN or AIN or the deletion of or change in the routing of an existing BIN or AIN and the Institutional Identifier Change Date on which such change is to occur. Framework Participants must recognise the new BIN or AIN or deletion of or change in the routing of an existing BIN or AIN on and from the relevant Institutional Identifier Change Date notified by the Secretary in accordance with clause 5.1(d) of the Regulations. Note: recognise for the purposes of this clause 2.9.1(e) means making such host system and Terminal changes as are reasonably necessary to ensure that Cards issued on the changed BIN and / or AIN are accepted at Terminals and that Transactions are processed and authorized accordingly Production of test cards 2.10 Capacity Planning Issuers that give notice of the introduction of a new BIN or a change to the routing of an existing BIN pursuant to clause 5.1 of the Regulations must, on request by an affected Framework Participant, ensure production of any necessary test Cards in sufficient time to allow testing to occur before the applicable Institutional Identifier Change Date. The CECS Management Committee will undertake the facilitation of regular meetings of those Framework Participants engaged in interchange to: 2.5

24 PART 2 FRAMEWORK PARTICIPANT OBLIGATIONS (c) (d) (e) (f) (g) consider the capacity and performance requirements for periods of peak demand; ensure that Framework Participants engaged in Interchange have sufficient capacity and performance to maintain services during peak periods of demand; share information (such as changes in switch arrangements or major product launches) relevant to capacity and performance to maintain the efficiency of the Australian card payments network at all times; provide assistance in developing action plans for any Framework Participants engaged in Interchange that consider they may not have the required capacity and performance during a period of peak demand; monitor the action plans for Framework Participants engaged in Interchange that may not have the required capacity and performance during a period of peak demand; report and discuss any issues that it considers may affect the integrity, security or efficiency of interchange, from a capacity requirement and performance perspective, to the Management Committee for appropriate action; and provide recommendations, as appropriate, on issues that have been discussed and agreed by a majority for consideration by the CECS Management Committee. Next page is

25 PART 3 CERTIFICATION PART 3 CERTIFICATION 3.1 Introduction This Part 3 sets out the certification requirements to be met by applicants, and the annual compliance requirements for all Framework Participants. By completing the relevant checklists, an applicant or Framework Participant confirms, for the benefit of all Framework Participants and the Company, that when it operates in the CECS with other Framework Participants it meets the applicable requirements in force at that time, including that: (c) (d) it conforms with CECS Manual Volume 3 (Acquirer Requirements); it conforms with CECS Manual Volume 2 (Issuer Requirements); all PEDs, SCMs and Key Loading and Transfer devices it uses have been approved by the Company and are listed on the Approved Devices List; (see the SCMs it uses are compliant to the APCA SCM Specification; (e) its settlement procedures conform with CECS Manual Volume 5 (Settlement); (f) (g) it conforms with CECS Manual Volume 6 (ATM Requirements); and any services provided on its behalf by Third Party Providers are provided in conformance with the relevant standards and requirements specified in this Manual. Amended effective Annual Security Audits The Annual Security Audits (Annexure A of this Volume 1) is designed to ensure that uniform security audit procedures are applied among all Framework Participants. To be effective, all entities involved in either the processing of Interchange PINs from entry at the PED up to and including its delivery to the Issuer s authorisation processor, or involved in the management and security of PINs must adhere to an agreed set of procedures and adopt a common audit process to ensure adherence to those security procedures Submission of Annual Security Audit All Framework Participants must complete an Annual Security Audit (see Annexure A) once every calendar year. Framework Participants must give the Company prior written notice of the date by which they will complete their Annual Security Audit. It must be signed by the Framework Participant and countersigned by either an internal or external auditor. 3.1

26 PART 3 CERTIFICATION Acquirers who have completed a Visa PIN Security Requirements Self Audit (appendix C of the PCI PIN Security Requirements manual, version 2.0 dated January 2008 or later) within the immediately preceding 6 months may meet the requirements in this clause by completing Annexure A.1 and submitting a duly signed copy of the Visa checklist should accompany this submission Third Party Providers Amended effective Where services and functions are provided by a Third Party Provider, its compliance with CECS standards and requirements must be demonstrated by the Framework Participant by either submission of: (i) (ii) a separate Annual Security Audit checklist for the Third Party Provider; or by inclusion of the Third Party Provider within the Framework Participant s own Annual Security Audit checklist. Framework Participants compliance with the obligation to manage service provision by Third Party Providers as set out in this clause will be assessed as part of the annual security audit Auditor Signoff Auditors co-signing Annual Security Audit must be engaged to perform an independent review of the compliance checklists completed by the Framework Participant, and to form an opinion on their completeness and accuracy. The following is a suggested audit process that could be used by an auditor: (i) (ii) Obtain the completed relevant checklist from the Framework Participant. Select a representative sample of questions from the checklist, including: (A) (B) all questions which indicate non-compliance with the CECS Manual; and a sample of questions which indicate compliance with the CECS Manual. (iii) Perform a walk-through of each of the selected questions with the relevant staff, focusing on how they have assured themselves that the responses to the checklist are complete and accurate. 3.2

27 PART 3 CERTIFICATION (iv) Where non-compliance is noted on a checklist, ensure that the Framework Participant have an adequate and timely action plan in place, including: (A) (B) (C) remedial actions which will ensure future compliance to the CECS Manual; realistic and appropriate resolution time frames; and accountability is allocated to the relevant staff within the Framework Participant. (v) (vi) Raise all concerns with the Framework Participant and achieve satisfactory resolution/agreement. The auditor should continually be asking the relevant staff as to: (A) (B) how they ensure compliance with the CECS Manual; and to provide evidence which demonstrates that their compliance control/monitoring procedures are operating effectively. 3.3 Exemption Requests All Framework Participants must at all times comply with the requirements specified in the CECS Manual unless specifically exempted by the Company. A Framework Participant requiring an exemption from certain requirements must make an application to the Company. The application must include the following information: (i) (ii) (iii) (iv) (v) (vi) the name of the Framework Participant requiring the exemption; date of the request; date the out-of-compliance situation occurred; a description of the risk and a risk rating; the section(s) of the Manual with which the Framework Participant is not in compliance; description of the requirement with which the Framework Participant is not in compliance; (vii) a statement on the reason for non-compliance; (viii) a full description of any compensating controls that are offered as justification for the authorisation of the request; and 3.3

28 PART 3 CERTIFICATION (ix) exact details of the Framework Participant s action plan to comply with the requirements and an indication as to the likely date of achieving compliance. (c) An exemption request form is provided in Annexure B Exemption Process The Company will review the exemption request and accompanying documentation and determine if the proposed remedial action/compensating controls with respect to areas of non-compliance are satisfactory to the Company, having regard to the integrity and efficiency of CECS. The Company will advise the Framework Participant of the acceptance or rejection of the exemption request Exemption Duration Exemptions will only be granted for a defined period of time. The Company may grant duration different to the one requested by the Framework Participant. All exemptions granted for non-compliance, regardless of when they expire, must be reviewed and renewed annually Introduction of New or Modified Devices or New Processes In cases where a significant change will cause the Framework Participant to be out of compliance with the CECS requirements, the Framework Participant may not proceed unless appropriate exemptions have been duly granted. Examples include: (c) deployment of any new SCD (not currently on the Approved Devices List); continued deployment of an SCD which has reached its approval sunset date; or implementing changes to PIN or cryptographic key handling or management processing. 3.4 Certification of Prospective Framework Participant Each applicant must arrange for Certification as part of their membership application. Certification checklists must be used for Certification. An applicant seeking Certification must complete the relevant New Framework Participant Checklist (see Annexure B) and the relevant Annual Security Audit (see Annexure A). Any further evidence of compliance which is reasonably requested by the Secretary or the Management Committee must be promptly produced to the Secretary following the request. 3.4

29 PART 3 CERTIFICATION (c) All applicants must ensure that Third Party Providers meet the obligations set out in clause 2.2 and clause of this Volume. Inserted effective Guidance for External Auditors When Certification is sought by an applicant who does not have, or does not wish to use, an internal auditor, the Certification checklist must be accompanied by a report of an agreed upon procedures engagement (refer Accounting Standard AUS 904) from an external auditor. The external auditor engaged by an applicant must be acceptable to the Company. The Company maintains a set of Guidance Procedures for applicants wishing to use an external auditor, which contain a proposed set of acceptable audit procedures. Once an acceptable external auditor has been selected by the applicant the external auditor may obtain the Guidance Procedures from the Company Review of Certification documentation The Company will review the Certification checklists referred to in clause 3.4 above and accompanying documentation and provide a report of its review to the applicant. Details of the application will be provided to the Management Committee for its consideration under Regulation 4.3 as to whether: all requirements appear to have been met, or any proposed remedial action/compensating controls with respect to areas of non-compliance are satisfactory to the Company having regard to the desirability to maintain the integrity and efficiency of CECS. Next page is A.1 3.5

30 ANNEXURE A ANNUAL SECURITY AUDITS ANNEXURE A ANNUAL SECURITY AUDITS Note: Annexure A.1 Acquirer Annual Security Audit (Part 1) must be completed annually by all Acquirer Framework Participants in combination with either Annexure A.2 Acquirer Annual Security Audit (Part 2) or a duly signed copy of a Visa PIN Security Requirements Self Audit Note: Annexure A.3 Issuer Annual Security Audit must be completed annually by all Issuer Framework Participants. A.1 ACQUIRER ANNUAL SECURITY AUDIT (PART 1) This checklist presents mandatory requirements relating to general procedures and controls associated with the management of PINs and the associated cryptographic practices. The mandatory requirements are based on the requirements of AS The following documents are referenced in this checklist; AS AS /Amdt 3/2007 AS Electronic funds transfer Requirements for interfaces Part 3: PIN Management and Security Electronic funds transfer Requirements for interfaces Part 6.1: Key management Principles Electronic funds transfer Requirements for interfaces Part 14.2: Secure Cryptographic Devices (retail) Security compliance checklists for devices used in magnetic stripe systems A.1.1 General Security Controls Third Party Providers Please provide details of all Third Party Providers used in providing acquiring services. Please use a separate sheet if necessary. Third Party Providers Type of service provided A.1

31 ANNEXURE A ANNUAL SECURITY AUDITS All parties to the Interchange, including merchants, Acquirers, Third Party Providers and any intermediate network entities maintain procedures and practices to prevent the unauthorised disclosure of Cardholder Data, which includes but is not necessarily limited to the Primary Account Number, Cardholder Name, Service Code, Expiration Date, Reference CECS Manual Volume 3, clause 2.5. (c) Sensitive authentication data, including but not limited to, Full magnetic stripe (or equivalent), CVC2/CVV2/CID, PIN/PIN Block is not stored, outside of an SCD, subsequent to Authorisation. Reference CECS Manual Volume 3, clause 2.6. (d) Message Authentication applies to all Interchange Links. The MAC must be calculated using, as a minimum, a DEA 3 (128-bit) key, Triple-DES and an algorithm conforming to AS All interchange PIN and MAC cryptographic functions are performed within a Tamper responsive SCM. Reference AS (e) Message Authentication applies to all Terminal to Acquirer Links for all financial and key management messages Reference AS A.2

32 ANNEXURE A ANNUAL SECURITY AUDITS (f) Interchange Lines are be subject to whole-of-message encryption in accordance with AS (CECS Manual Volume 3, clause 2.4.4) (g) Interchange Links comply with the key management practices of CECS Manual Volume 4, clause (h) Interchange Lines comply with the key management practices of CECS Manual Volume 4, clause (if applicable) (i) Terminal key management practices comply with the requirements of CECS Manual Volume 4, clause (j) Host systems which support Terminals using the TCP/IP protocol for communications meet the requirements of CECS Manual Volume 3, clause (k) Privacy of communication complies with AS for all Terminal to Acquirer links, or any other privacy of communication standard approved by the Management Committee (EFTPOS terminals only) CECS Manual Volume 3, clause A.3

33 ANNEXURE A ANNUAL SECURITY AUDITS (l) Documented procedures exist, and are followed to ensure all PINs are encrypted using DEA 3 when transmitted outside a Secure Cryptographic Device. PINs are not stored in any form. If a transaction is logged, the encrypted PIN block is masked or deleted from the record before it is logged. Reference AS clauses 5.2 and (m) No procedure requires or permits the Cardholder to disclose the PIN (verbally or in writing). Reference AS , clause 5.4. (n) Each type of SCD used in Interchange and those devices providing a Remote Management Solution for Security Control Modules have been evaluated by a Company accredited Evaluation Facility using the method in and against the criteria in CECS Manual Volume 4 (Device Requirements and Cryptographic Management), and have been approved for use by the Company. An SCD includes but is not limited to an ATM, PED, SCM or Key Loading and Transfer Device. Reference AS , clause ; AS (o) Clear text PINs and Clear-text keys exist only in an SCD designed for use in its operational environment. A.4

34 ANNEXURE A ANNUAL SECURITY AUDITS A.1.2 Device Management Documented procedures exist, and are followed, to determine that the SCD is managed in accordance with the privacy shielding requirements in clause of CECS Manual Volume 3 (Acquirer Requirements). Documented, auditable, key management procedures exist and are followed for the secure management of any Acquirer controlled key used in the authentication processes associated with PED software authentication. (c) For terminals running multiple applications, documented, auditable, key management procedures exist and are followed for the secure management of any key used in the authentication processes associated with PED software authentication. Inserted effective (d) If the SCD can translate a PIN from one PIN block format to another or if the SCD verifies PINs, then procedures exist, and are followed, to prevent or detect, repeated unauthorised calls resulting in the exhaustive determination of PINs. (e) Documented procedures exist, and are followed, to ensure that any Remote Management Solution for an SCM is managed in accordance with the requirements of clause of CECS Manual Volume 3 (Acquirer Requirements). A.5

35 ANNEXURE A ANNUAL SECURITY AUDITS (f) From 1 January 2013, all symmetric encryption functionality weaker than DES-3 has been disabled within every deployed SCM. (g) Acquirers shall maintain a register of all authorised non-payment applications per device. Inserted effective A.1.3 Supplementary Questions for Acquirers who are submitting Visa Audits Note: The following requirements are only to be completed by Acquirers submitting a duly signed copy of a Visa PIN Security Requirements Self Audit to accompany this A.1 Acquirer Annual Security Audit (Part 1) submission (as described in clause 3.2.1). Compliance with the requirements of the Visa PIN Security Requirements Self Audit has been confirmed. Documented procedures exist and are followed for each of the individual requirements in the Visa PIN security Requirement Self Audit. SIGNED for and behalf of THE FRAMEWORK PARTICIPANT By signing this Acquirer Annual Security Audit (Part 1) the signatory states that the signatory is duly authorised to sign this Audit for and on behalf of the Framework Participant. Name of Authorised Person Signature of Authorised Person Office Held Date A.6

36 ANNEXURE A ANNUAL SECURITY AUDITS AUDITOR SIGNOFF By signing this Acquirer Annual Security Audit (Part 1) the signatory states that the signatory is duly authorised to sign this Audit as auditor for and on behalf of the Framework Participant and that the signatory is satisfied with the accuracy of the responses contained within the Audit. Name of Auditor Signature of Auditor Date A.7

37 ANNEXURE A ANNUAL SECURITY AUDITS A.2 ACQUIRER ANNUAL SECURITY AUDIT (PART 2) Annexure A.2 Acquirer Annual Security Audit (Part 2) must be completed unless submitting a duly signed copy of a Visa PIN Security Requirements Self Audit. This checklist presents mandatory requirements relating to general procedures and controls associated with the management of PINs and the associated cryptographic practices. The mandatory requirements are based on the requirements of AS A.2.1 General Security Controls Please provide the details for all ATM and POS devices that you currently have deployed. Please use a separate sheet if necessary. ATM POS Manufacturer Model No. Approx Quantity. Please provide the details for all SCM devices that you currently have deployed. Please use a separate sheet if necessary. Manufacturer Model No. Quantity. A.8

38 ANNEXURE A ANNUAL SECURITY AUDITS (c) Any clear-text PIN block format combined with a PIN encryption process has the characteristics that, for different accounts, encryption of the same PIN value under a given encryption key does not predictably produce the same encrypted results. (Note the format 0 and format 3 PIN blocks specified in AS meet this requirement.) Reference AS , clause (d) Documented procedures exist, and are followed to ensure all PINs are encrypted using DEA 3 when transmitted outside a Secure Cryptographic Device. PINs are not stored in any form. If a transaction is logged, the encrypted PIN block is masked or deleted from the record before it is logged. Reference AS clauses 5.2 and (e) Operating procedures and the design of devices utilized require that the Cardholder can reasonably prevent others from observing the entered PIN. Reference AS , clause A.9

39 ANNEXURE A ANNUAL SECURITY AUDITS A.2.2 Device Management Any SCD capable of encrypting a key and producing a cryptogram of that key is protected against unauthorised use to encrypt known keys or known key components. This protection takes the form of either or both of the following: (i) (ii) Dual Access controls are required to enable the key encrypting functions; and/or Physical protection of the equipment (e.g., locked access to it) under dual control. Reference AS , clauses E12 and E13. Documented procedures exist, and are followed, to determine that an SCD has not been subject to unauthorised modification or substitution prior to loading cryptographic keys. This assurance takes the form of one or more of the following procedures: (i) (ii) Physical inspection and/or testing of the equipment immediately prior to key loading; and/or Physical protection of the equipment. (c) Documented procedures exist, and are followed, to ensure that the SCD is physically protected (e.g., locked access) to protect against the possibility that the SCD may be stolen, modified in an unauthorised way, and then returned to storage without detection. A.10

40 ANNEXURE A ANNUAL SECURITY AUDITS (d) Documented procedures exist to ensure that keys are not installed in any SCD where suspicious alteration of an SCD has been detected until the SCD has been inspected and a reasonable degree of assurance has been reached that the SCD has not been subject to any unauthorised physical or logical modifications. A.2.3 General Key Management Documented procedures exist, and are followed to control keys so that they exist in only one or more of the permissible forms: (i) (ii) (iii) In a SCD; Encrypted under a DEA 2 or DEA 3 key; or Managed as two or more full length components using the principles of dual control and split knowledge. Documented procedures exist and are followed to ensure a person entrusted with a key component reasonably protects that component such that no person (not similarly entrusted with that component) can observe or otherwise obtain that component. (c) Documented procedures exist and are followed to ensure keys and key components are generated using a random or pseudo-random process such that it is not possible to determine that some keys are more probable than other keys from the set of all possible keys. A.11

41 ANNEXURE A ANNUAL SECURITY AUDITS (d) Documented procedures exist to ensure each of the following: (i) (ii) (iii) (iv) A key is changed if its compromise is known or suspected; Keys encrypted under or derived from a compromised key are changed; Key is not changed to a variant or a transformation of the compromised key; and The amount of time in which the compromised key remains active is consistent with the risk to all affected parties. (e) Documented procedures exist and are followed to ensure a key is used for only a single designated purpose. (f) Documented procedures exist and are followed to ensure that when a key is installed under dual control using key components that these key components are only combined within a SCD. (g) Key components are combined to form a key by a process such that no active bit of the key could be determined without knowledge of all components. Key components are combined using one of the following functions: (i) (ii) XOR; and/or Encryption via DEA. A.12

42 ANNEXURE A ANNUAL SECURITY AUDITS (h) Documented procedures exist and are followed to ensure when in secure transit, cleartext key components are protected from compromise in one of the following manners: (i) (ii) Key components are transported in separate tamper-evident packaging; and/or Key components are transported in a device meeting the requirements of a Physically Secure Device. Reference AS (i) Documented procedures exist and are followed to ensure a cleartext key component is: (i) (ii) (iii) (iv) Under the supervision of a person authorised by management with access to this component; or Locked in a security container in such a way that can be obtained only by a person with authorized access; or In secure transit; or In a physically secure SCD. (j) Documented procedures exist and are followed to ensure if keys are loaded or transported using an electronic key loading device then: (i) (ii) (iii) The key loading device has been evaluated and meet the applicable security requirements (see clause A.2.2); The key loading device is under the supervision of a person authorised by management, or is stored in a secure manner (e.g., in a safe) such that no unauthorised person may have access to it; and The key loading device is designed or controlled so that only authorised personnel under dual control can utilise and enable it to output a key into another SCD. Such personnel ensure that the transfer is not being monitored, e.g., that there is no key recording device inserted between the SCDs. A.13

43 ANNEXURE A ANNUAL SECURITY AUDITS (k) Documented procedures exist and are followed to protect the transfer of a key or key component into SCDs so as to prevent the disclosure of the key or key components. Examples of procedures include physical inspection of the SCD equipment to detect evidence of monitoring and dual custody of the loading process. (l) Documented procedures exist and are followed to ensure that a key exists at only the minimal number of locations consistent with the operation of the system (e.g., including disaster recovery purposes, dual processing sites). (m) Documented procedures exist and are followed, to prohibit, except by chance, the entry or use of the same key in more than one PIN entry device. Yes No N/A If N/A response: Reason (n) If for archival purposes, reconstruction of a given key is required at a later date, procedures exist and are followed to ensure the key is retained in a form such as to preclude it being intentionally used again as active keying material. Yes No N/A If N/A response: Reason A.14

44 ANNEXURE A ANNUAL SECURITY AUDITS (o) Documented procedures exist and are followed to ensure a key shared between communicating parties is not shared, except by chance, between any other communicating parties. (p) Procedures exist and are followed to ensure a key or key component that has been used for a cryptographic purpose is erased or destroyed when it is no longer required using approved destruction procedures. (q) Documented procedures exist and are followed to ensure that when a key transport key (KTK) is changed because its compromise is known or suspected, an organisation which has previously shared the key is informed of the compromise even if the KTK is no longer in use. (r) Documented procedures exist and are followed to monitor cryptographic synchronisation errors and to investigate multiple synchronisation errors to ensure the SCD is not being misused to determine keys or PINs. (s) Documented procedures exist and are followed to ensure if two or more of a key s components are stored within the same security container (which is under dual control), then the components are secured in tamper evident packaging to preclude one component holder from gaining access to the other component. A.15

45 ANNEXURE A ANNUAL SECURITY AUDITS (t) Documented procedures exist and are followed to ensure a key loading device does not retain a clear-text copy of any key it has successfully transferred. (u) If personal computers are used to load encryption keys into a PIN entry device, procedures exist and are followed to ensure, at a minimum the following controls: (i) (ii) (iii) (iv) (v) (vi) The software loads the encryption key without recording the value in non-volatile storage; Hardware used for the key loading function is maintained under dual control; Hardware use is monitored and logs of key loading activity are maintained; Cable attachments and hardware are examined before each use to ensure that the equipment is free from tampering; That the computer is started from power off position for each site s key loading activity; and An SCD is used in conjunction with the personal computer to complete all cryptographic processing and for the storage of all encryption keys. (v) Documented procedures exist and are followed to maintain a record of every instance when a container securing cryptographic materials is opened to record date, time, person(s) involved and the purpose of the access. A.16

46 ANNEXURE A ANNUAL SECURITY AUDITS SIGNED for and behalf of THE FRAMEWORK PARTICIPANT By signing this Acquirer Annual Security Audit (Part 2) the signatory states that the signatory is duly authorised to sign this Audit for and on behalf of the Framework Participant. Name of Authorised Person Signature of Authorised Person Office Held Date AUDITOR SIGNOFF By signing this Acquirer Annual Security Audit (Part 2) the signatory states that the signatory is duly authorised to sign this Audit as auditor for and on behalf of the Framework Participant and that the signatory is satisfied with the accuracy of the responses contained within the Audit. Name of Auditor Signature of Auditor Date A.17

47 ANNEXURE A ANNUAL SECURITY AUDITS A.3 ISSUER ANNUAL SECURITY AUDIT This checklist presents mandatory requirements relating to general procedures and controls associated with the management of PINs and the associated cryptographic practices. The mandatory requirements are based on the requirements of AS The following documents are referenced in this checklist; AS AS /Amdt 3/2007 AS Electronic funds transfer Requirements for interfaces Part 3: PIN Management and Security Electronic funds transfer Requirements for interfaces Part 6.1: Key management Principles Electronic funds transfer Requirements for interfaces Part 14.2: Secure Cryptographic Devices (retail) Security compliance checklists for devices used in magnetic stripe systems A.3.1 General Security Controls Please provide the details for all SCM devices that you currently have deployed. Please use a separate sheet if necessary. Manufacturer Model No. Quantity. Third Party Providers Please provide details of all Third Party Providers associated with the management of PINs and the associated cryptographic practices used in providing issuing services. Please use a separate sheet if necessary. A.18

48 ANNEXURE A ANNUAL SECURITY AUDITS Third Party Providers Type of service provided (c) Any clear-text PIN block format combined with a PIN encryption process has the characteristics that, for different accounts, encryption of the same PIN value under a given encryption key does not predictably produce the same encrypted results. (Note the format 0 and format 3 PIN blocks specified in AS meet this requirement.) Reference AS , clause (d) Documented procedures exist, and are followed to ensure all PINs are encrypted using DEA 3 when transmitted outside a Secure Cryptographic Device. If a transaction is logged, the encrypted PIN block must be masked or deleted from the record before it is logged. Reference AS clauses 5.2 and (e) No procedure requires or permits the Cardholder to disclose the PIN verbally or in writing. Reference AS , clause 5.4. A.19

49 ANNEXURE A ANNUAL SECURITY AUDITS (f) All parties to the Interchange, including Third Party Providers and any intermediate network entities maintain procedures and practices to prevent the unauthorised disclosure of Cardholder Data, which includes but is not necessarily limited to the Primary Account Number, Cardholder Name, Service Code, Expiration Date, (g) Message Authentication applies to all Interchange Links. The MAC must be calculated using, as a minimum, a DEA 3 (128-bit) key, Triple-DES and an algorithm conforming to AS All interchange PIN and MAC cryptographic functions are performed within a Tamper responsive SCM. Reference AS (h) Interchange Lines are subject to whole-of-message encryption in accordance with AS (CECS Manual Volume 3, clause 2.5.4) (i) Interchange Links comply with the key management practices of CECS Manual Volume 4, clause (j) Interchange Lines comply with the key management practices of CECS Manual Volume 4, clause (if applicable). A.20

50 ANNEXURE A ANNUAL SECURITY AUDITS (k) Open network PIN change solutions available to Cardholders meet relevant requirements. Reference CECS Manual Volume 2 (Issuer Requirements). A.3.2 Device Management Each type of SCM used in Interchange, and those devices providing a Remote Management Solution for Security Control Modules have been evaluated by a Company accredited Evaluation Facility using the method and against the criteria given in CECS Manual Volume 4 (Device Requirements and Cryptographic Management) and have been approved for use by the Company. Reference AS , clause ; AS , CECS Manual Volume 4 (Device Requirements and Cryptographic Management). Documented procedures exist, and are followed, to ensure that any Remote Management Solution for an SCM is managed in accordance with the requirements of CECS Manual Volume 4, clause A.3.3 Key Management Documented procedures exist, and are followed to control keys so that they exist in only one or more of the permissible forms: (i) (ii) (iii) In a SCD; Encrypted under a DEA 2 or DEA 3 key; and/or Managed as two or more full length components using the principles of dual control and split knowledge. A.21

51 ANNEXURE A ANNUAL SECURITY AUDITS Documented procedures exist and are followed to ensure a person entrusted with a key component reasonably protects that component such that no person (not similarly entrusted with that component) can observe or otherwise obtain that component. (c) Documented procedures exist and are followed to ensure keys and key components are generated using a random or pseudo-random process such that it is not possible to determine that some keys are more probable than other keys from the set of all possible keys. (d) Documented procedures exist to ensure each of the following: (i) (ii) (iii) (iv) A key is changed if its compromise is known or suspected; Keys encrypted under or derived from a compromised key are changed; A key is not changed to a variant or a transformation of the compromised key; and The amount of time in which the compromised key remains active is consistent with the risk to all affected parties. (e) Documented procedures exist and are followed to ensure a key is used for only a single designated purpose. A.22

52 ANNEXURE A ANNUAL SECURITY AUDITS (f) Documented procedures exist and are followed to ensure that when a key is installed under dual control using key components that these key components are only combined within a SCD. (g) Key components are combined to form a key by a process such that no active bit of the key could be determined without knowledge of all components. Key components are combined using one of the following functions: (i) (ii) XOR; and/or Encryption via DEA. (h) Documented procedures exist and are followed to ensure when in secure transit, cleartext key components are protected from compromise in one of the following manners: (i) (ii) Key components are transported in separate tamper-evident packaging; or Key components are transported in a device meeting the requirements of a Physically Secure Device. Reference AS A.23

53 ANNEXURE A ANNUAL SECURITY AUDITS (i) Documented procedures exist and are followed to ensure a cleartext key component is: (i) (ii) (iii) (iv) Under the supervision of a person authorised by management with access to this component; or Locked in a security container in such a way that can be obtained only by a person with authorized access; or In secure transit; or In a physically secure SCD. (j) Documented procedures exist and are followed to ensure if keys are loaded or transported using an electronic key loading device then: (i) (ii) (iii) The key loading device has been evaluated and meets the applicable security requirements (see clause A.3.2); The key loading device is under the supervision of a person authorised by management, or is stored in a secure manner (e.g., in a safe) such that no unauthorised person may have access to it; and The key loading device is designed or controlled so that only authorised personnel under dual control can utilise and enable it to output a key into another SCD. Such personnel ensure that the transfer is not being monitored, e.g., that there is no key recording device inserted between the SCDs. (k) Documented procedures exist and are followed to protect the transfer of a key or key component into SCMs so as to prevent the disclosure of the key or key components. Examples of procedures include physical inspection of the SCD equipment to detect evidence of monitoring and dual custody of the loading process. A.24

54 ANNEXURE A ANNUAL SECURITY AUDITS (l) Documented procedures exist and are followed to ensure that a key exists at only the minimal number of locations consistent with the operation of the system (e.g., including disaster recovery purposes, dual processing sites). (m) If for archival purposes, reconstruction of a given key is required at a later date, procedures exist and are followed to ensure the key is retained in a form such as to preclude it being intentionally used again as active keying material. (n) Documented procedures exist and are followed to ensure a key shared between communicating parties is not shared, except by chance, between any other communicating parties. (o) Procedures exist and are followed to ensure a key or key component that has been used for a cryptographic purpose is erased or destroyed when it is no longer required using approved destruction procedures. (p) Documented procedures exist and are followed to ensure that when a key transport key (KTK) is changed because its compromise is known or suspected, an organisation which has previously shared the key is informed of the compromise even if the KTK is no longer in use. A.25

55 ANNEXURE A ANNUAL SECURITY AUDITS (q) Documented procedures exist and are followed to ensure if two or more of a key s components are stored within the same security container (which is under dual control), then the components are secured in tamper evident packaging to preclude one component holder from gaining access to the other component. (r) Documented procedures exist and are followed to ensure a key loading device does not retain a clear-text copy of any key it has successfully transferred. (s) Documented procedures exist and are followed to maintain a record of every instance when a container securing cryptographic materials is opened to record date, time, person(s) involved and the purpose of the access. SIGNED for and behalf of THE FRAMEWORK PARTICIPANT By signing this Issuer Annual Security Audit the signatory states that the signatory is duly authorised to sign this Audit for and on behalf of the Framework Participant. Name of Authorised Person Signature of Authorised Person Office Held Date AUDITOR SIGNOFF By signing this Issuer Annual Security Audit the signatory states that the signatory is duly authorised to sign this Audit as auditor for and on behalf of the Framework Participant and that the signatory is satisfied with the accuracy of the responses contained within the Audit. Name of Auditor Signature of Auditor Date A.26

56 ANNEXURE B NEW FRAMEWORK PARTICIPANT CERTIFICATION ANNEXURE B NEW FRAMEWORK PARTICIPANT CERTIFICATION Note: Annexure B.1 Acquirer Certification Checklist is ONLY to be completed by a new Framework Participant. B.1 ACQUIRER CERTIFICATION CHECKLIST To: Re: From: The Secretary Australian Payments Clearing Association Limited Level 6 14 Martin Place Sydney NSW 2000 Consumer Electronic Clearing System Name of Applicant ( Applicant ): Place of Incorporation: ACN / ABN / ARBN: Registered Office Address Name of Contact Person:: Telephone Number: ( ) Address: CERTIFICATION OBJECTIVES The objective of Certification is to ensure that each CECS Applicant that becomes an Acquirer confirms for the benefit of each other Framework Participant and the Company that it meets the technical, operational and security requirements applicable to Acquirers which are set out in CECS Manual Volume 3 (Acquirer Requirements), CECS Manual Volume 5 (Settlement) and CECS Manual Volume 6 (ATM Requirements) as applicable. REPRESENTATIONS AND UNDERTAKINGS By signing this Acquirer Certification Checklist, the Applicant: acknowledges that membership of CECS is conditional on the Applicant having obtained Certification in accordance with the CECS Regulations and Manual and that this Acquirer Certification Checklist is required to obtain that Certification; B.1

57 ANNEXURE B NEW FRAMEWORK PARTICIPANT CERTIFICATION (c) warrants that it satisfies the requirements applicable generally to Acquirers as set out in clause 2.1 of CECS Manual Volume 3 (Acquirer Requirements), CECS Manual Volume 5 (Settlement) and CECS Manual Volume 6 (ATM Requirements) as at the date of this Acquirer Certification Checklist, and that the information contained in this completed Acquirer Certification Checklist is correct and accurately reflects the results of system testing against current CECS requirements and including, if applicable, use of an appropriate test script supplied by the Company; if the Applicant is granted Certification, agrees to: (i) (ii) immediately notify the Company if it becomes, or has become, aware that any information contained in this Acquirer Certification Checklist is wrong or misleading (including without limitation because of any omission to provide relevant additional information); and provide to the Company with full particulars of any such wrong or misleading information. Terms used in this Acquirer Certification Checklist have the same meanings as in the CECS Manual unless otherwise defined. SIGNED for and behalf of THE APPLICANT By signing this Acquirer Certification Checklist the signatory states that the signatory is duly authorised to sign this Acquirer Certification Checklist for and on behalf of the Applicant. Name of Authorised Person Signature of Authorised Person Office Held Date AUDITOR SIGNOFF By signing this Acquirer Certification Checklist the signatory states that the signatory is duly authorised to sign this Acquirer Certification Checklist as auditor for and on behalf of the Applicant and that the signatory is satisfied with the accuracy of the responses contained within the certification checklist. Name of Auditor Signature of Auditor Date B.2

58 ANNEXURE B NEW FRAMEWORK PARTICIPANT CERTIFICATION Note: This Annexure B.2 Issuer Certification Checklist is ONLY to be completed by a new Framework Participant. B.2 ISSUER CERTIFICATION CHECKLIST To: Re: From: The Secretary Australian Payments Clearing Association Limited Level 6 14 Martin Place Sydney NSW 2000 Consumer Electronic Clearing System Name of Applicant ( Applicant ): Place of Incorporation: ACN / ABN / ARBN: Registered Office Address Name of Contact Person:: Telephone Number: ( ) Address: CERTIFICATION OBJECTIVES The objective of Certification is to ensure that each CECS Applicant that becomes an Issuer confirms for the benefit of each other Framework Participant and the Company that it meets the technical, operational and security requirements applicable to Issuers which are set out in CECS Manual Volume 2 (Issuer Requirements) and CECS Manual Volume 5 (Settlement) as applicable. REPRESENTATIONS AND UNDERTAKINGS By signing this Issuer Certification Checklist, the Applicant: acknowledges that membership of CECS is conditional on the Applicant having obtained Certification in accordance with the CECS Regulations and Manual and that this Issuer Certification Checklist is required to obtain that Certification; B.3

59 ANNEXURE B NEW FRAMEWORK PARTICIPANT CERTIFICATION (c) warrants that it satisfies the requirements applicable generally to Issuers as set out in Part 5 of CECS Manual Volume 2 (Issuer Requirements) and CECS Manual Volume 5 (Settlement) as applicable, as at the date of this Issuer Certification Checklist, and that the information contained in this completed Issuer Certification Checklist is correct and accurately reflects the results of system testing against current CECS requirements and including, if applicable, use of an appropriate test script supplied by the Company; if the Applicant is granted Certification, agrees to: (i) (ii) immediately notify the Company if it becomes, or has become, aware that any information contained in this Issuer Certification Checklist is wrong or misleading (including without limitation because of any omission to provide relevant additional information); and provide to the Company with full particulars of any such wrong or misleading information. Terms used in this Issuer Certification Checklist have the same meanings as in the CECS Manual unless otherwise defined. SIGNED for and behalf of THE APPLICANT By signing this Issuer Certification Checklist the signatory states that the signatory is duly authorised to sign this Issuer Certification Checklist for and on behalf of the Applicant. Name of Authorised Person Signature of Authorised Person Office Held Date AUDITOR SIGNOFF By signing this Issuer Certification Checklist the signatory states that the signatory is duly authorised to sign this Issuer Certification Checklist as auditor for and on behalf of the Applicant and that the signatory is satisfied with the accuracy of the responses contained within the Issuer Certification Checklist. Name of Auditor Signature of Auditor Date B.4

60 ANNEXURE C EXEMPTION REQUEST FORM ANNEXURE C EXEMPTION REQUEST FORM Framework Participant: Approval to disclose to eftpos Payments Australia Limited given / not given (delete as applicable): Authorised by: Date: Date of Request: Date of Original Request: Reference Number: Section & clause number of requirement If exemption is sought in respect of a particular device, insert Manufacturer, model, revision and software version Requirement for which Framework Participant is not in compliance Type in the actual wording of the Requirement with which the Framework Participant is not complying Situation (reason for noncompliance) Describe the situation, including when and why out-ofcompliance occurred. Risk Rank Compensating Controls Residual Risk Describe the risks the out-of-compliance situation poses High, Medium or Low List the compensating controls that reduce the risk High, Medium or Low Action to be taken and timeframe List what you are doing to correct the non-compliance For Extension Request Indicate the reason why an extension is sought Promised date of correction Indicate the date when the situation will be corrected. Risk Weighting HIGH MEDIUM LOW potential loss of integrity of PINs potential material losses to Framework Participants, Card Acceptors or Cardholders potential mass fraud potential loss of public confidence potential reduced integrity of PINS potential changes to financial content of transaction potential monetary losses to Framework Participants, Card Acceptors or Cardholders could be significant. minimal effect on the integrity of PINs potential monetary losses to Framework Participants would not be significant. C.1

61 ANNEXURE D CECS OPERATIONAL BROADCAST FORM ANNEXURE D CECS OPERATIONAL BROADCAST FORM Disclaimer: This document has been compiled from information provided by third parties. No representation or warranty is made by APCA as to the truth or accuracy of the information and APCA, its officers, employees and agents expressly disclaim all and any liability in respect of the information. DOCUMENT TITLE <Framework Participant> <Brief Broadcast Title> DOCUMENT NUMBER: DETAILS Date of Advice: Notifying Framework Participant: Framework Participant Experiencing Difficulty: CECS CS3\COB\nnn.yyyy <DD/MMM/YYYY> CONTACT POINT Name: Phone Number: Fax Number: Address: <Contact Name> <Contact Phone> <Contact Fax> <Contact > PAYMENT SYSTEM AFFECTED PROCESSES AFFECTED CECS Issuers and Acquirers Framework List of processes affected which may directly or indirectly impact other Framework Participants: Unscheduled network outage; Scheduled network outage; Exchange of Operational Information; and Disruptive Event. EXPECTED DURATION OF AFFECTED PROCESS Date Occurred / Scheduled: Start Time of Outage: End Time of Outage: <DD/MMM/YYY> <HH:MM> (Approximate) <HH:MM> (Approximate) D.1

62 ANNEXURE D CECS OPERATIONAL BROADCAST FORM COMMUNICATION PROCESS Advise Framework Participants: Advise Non- Members: APCA to provide prepared Statement: (Please attach text of statement in Attachments below) Refer media to affected Framework Participant: <YES / NO> <YES / NO> <YES / NO> <YES / NO> COMMENTS ATTACHMENTS Attach any CECS Operational Broadcast (COB) related documents here. APCA Comments END D.2