How to complete the Secure Internet Site Declaration (SISD) form

Transcription

1 1 How to complete the Secure Internet Site Declaration (SISD) form The following instructions are designed to assist you in completing the SISD form that forms part of your Merchant application. Once completed, please submit your SISD form along with your Merchant application to your ANZ Merchant representative or fax to Online stores An online store is a website which you use to market or sell your products or services. Online stores allow customers to place orders via your website. Online stores may make use of shopping cart software to help manage multiple products/services, or they may simply offer a single product/service. If you accept credit card details through your website for any reason, answer YES to this question. 1.1 Shopping Carts If you are using a shopping cart, please state the shopping cart name and version you are using. If you do not use a shopping cart, select No Shopping Cart. 1.2 Payment Gateway(s) If the product you are using is ANZ egate, the secure gateway is ANZ. If the product you are using is ANZ egate and there is another third party Payment Gateway Service involved, please specify the name of the Payment Gateway Service Provider. If you are not using ANZ egate you should specify the name of the company providing you with Payment Gateway services. Payment Gateway Service Provider 1.3 Payment Pages A Payment Page is the section of an online store where customers enter their credit card information. In technical terms, this also includes any pages or scripts which process credit card information. For example: The web page where a customer enters credit card information Any pages or scripts which handle credit card information To protect customer information, Payment Pages must be secured with SSL certificates. Most online payment facilities offer a hosted solution (where the Payment Page is provided by a bank or gateway provider). However, some websites host the Payment Page on the merchant website in order to retain greater control over the customer experience. Bank or Payment Gateway Service Provider The Payment Page is hosted by ANZ or a Payment Gateway Service Provider. Customers are redirected to the Payment Page during the checkout process and card data is not seen or captured by the merchant website These hosted solutions must be Level 1 PCI DSS compliant with a documented certificate of compliance provided by an independent QSA (Qualified Security Assessor). Ask your Payment Gateway Service Provider to provide a copy of their PCI DSS compliance certificate document each year. On the website (Merchant hosted) The Payment Page is hosted by the merchant website. Customers do not leave the merchant website during the checkout process. Payment Gateway Service Provider

2 2 1.4 Security requirements for Payment Pages SSL Version 3.0 Data sent across the internet is typically visible to observers. To prevent unauthorised access to information which should be private, data needs to be encrypted before being sent. SSL is a commonly used encryption protocol supported by most modern browsers. It is mandatory for any card information sent via the Internet to be encrypted. Minimum security requirements for Payment Pages is SSL Version 3.0 (RSA Public Key 1024 bits). Displaying card numbers When a card number is displayed on a screen, receipt, or any other medium, the full card number must be masked. The full card number should never be displayed. If you cannot meet these requirements, please contact ANZ Merchant Services and ask for a Bank or Payment Gateway Service Provider hosted Payment Page.

3 3 1.5 Security requirements for Websites Security requirements for Websites These security requirements address security vulnerabilities which are commonly exploited by hackers seeking to steal customer information or cause damage to your website. Capturing card data through your website makes it an attractive target for criminals seeking to profit from stolen card data, and using a Bank or 3rd Party hosted solution can help you avoid most of these issues. If a Bank or 3rd party hosted solution is not an option, then the following are some of the security requirements which should be considered when setting up your website. Note that this is by no means an exhaustive list. Strong passwords & Administrator roles Use of strong passwords is essential for users who have access to card data, or for accounts with administrator functions (such as the ability to reset other users passwords or change user access levels). Strong passwords: are more than 7 characters long or a pass phrase include letters, numbers, upper & lowercase letters, symbols are changed regularly, at least every 90 days are different to previous passwords are not easy to guess (e.g. password, admin ) are not shared between different user accounts are not your username are not the default passwords provided with your account Vendor supplied passwords Many vendors provide applications and equipment with default passwords. These passwords are widely known and failure to change these passwords makes it easier for an attacker to gain access to systems and hardware. Securely developed Website - OWASP The Open Web Application Security Project (OWASP) is a not-for-profit worldwide charitable organisation focused on improving the security of web application software. OWASP periodically publish a list of the Top 10 most critical web application security vulnerabilities. 1. Injection Attacks (SQL etc.) 2. Cross-Site Scripting (XSS) 3. Broken Authentication and Session Management 4. Insecure Direct Object References 5. Cross-Site Request Forgery (CSRF) 6. Security Misconfiguration 7. Insecure Cryptographic Storage 8. Failure to Restrict URL Access 9. Insufficient Transport Layer Protection (SSL/HTTPS) 10. Unvalidated Redirects and Forwards For a more detailed description around the vulnerabilities and some basic techniques to protect against them, please see The OWASP Testing Guide can also be utilised to test for these vulnerabilities while the OWASP Development Guide could be used to provide guidance around creating secure web applications. PCI DSS- external vulnerability scans An external vulnerability scan enables an organisation to assess the level of security from potential external threats. Vulnerability scan results provide valuable information that support efficient patch management and other security measures that can improve protection against Internet attacks. The Payment Card Industry Data Security Standard (PCI DSS) external vulnerability scans are performed remotely over the Internet by an Approved Scanning Vendor (ASV) to help identify vulnerabilities and misconfigurations of websites, applications, and information technology infrastructures with Internet-facing Internet protocol (IP) addresses. The scan is intended to identify such vulnerabilities so they can be corrected. A list of Approved Scanning Vendors (ASVs) is maintained at this link by the Payment Card Industry Security Standards Council (PCI SSC) ( It is recommended that you talk to your web developer to find out what safeguards are in place to remove these vulnerabilities from your website.

4 4 1.6 Receipt Requirements In order for your website to be approved, your website must contain the following content. Merchant name This is your business trading name and should match the business name that customers will see on their credit card statement. Merchant online address The Internet Address or (URL) for your business website (e.g. Transaction amount and currency The total amount charged to the customer and the currency in which it is charged. This should include any other fees and/or charges you apply to the transaction. Transaction date The date when you will process a customer s transaction (this will be the current date unless you are delaying the transaction). Unique Transaction Identification Number A unique identifier which a customer can use to identify the transaction. This identifier cannot be re-used for any other transactions. Purchaser Name The name provided by the customer at the time of sale. Authorisation ID The authorisation ID provided to you by ANZ when the transaction is approved. Transaction type (Purchase or Refund) A Purchase transaction is a standard transaction where you debit a customer and receive funds. A Refund transaction is where you return funds to a customer from whom you have previously received funds. Description of merchandise/services A description of the goods or services that the customer has purchased with this transaction. 1.7 Policy Requirements In order for your website to be approved, your website must contain the following content. Complete description of the goods or services offered You must display a description for each product or service on your website. The description must provide customers with a reasonable expectation of the product or service. Returned merchandise and refund policy A return/refund policy outlines the process a customer needs to follow when seeking to return merchandise and/or seek a refund. If you do not offer refunds, the policy should clearly state that you do not offer refunds. Delivery policy A delivery policy outlines the means and timeframes for delivery, as well as any additional costs which may be incurred. Delivery policies for services should outline how a customer can access the service after making the order. Export or legal restriction(s), if applicable If there are export or legal restrictions associated with a product or service, the restrictions must be disclosed to the customer prior to taking payment. Currency of transaction is clearly stated on Payment Page This is the currency in which the transaction will be processed. Unless you are using a multi-currency product, this will be $AUD. Security capabilities and policy for transmission of payment card details Describe the mechanisms used to secure card details where stored or transmitted - e.g. SSL version 3.0. If you do not capture or store card information (e.g. using a bank or secure gateway hosted Payment Page), state that you do not handle card information directly, and provide the name of the 3rd party who is capturing card information on your behalf. Consumer Data/Privacy policy A consumer data/privacy policy details what personal information you collect, how it is stored, and any parties with whom you share this data. It should also detail any conditions under which you will share their personal information. Customer service contact, including electronic mail address and telephone number You must provide customers with a customer service contact phone number and address (where available). Address of your permanent establishment You must disclose the permanent street address of your business. This address cannot be a PO Box. For businesses which operate from a residential property, this is the street address of the residence from which the business operates.

5 5 2. Storage of credit card details Before you answer this question, you should check with your web host provider and web developer, as you may be unaware that you are storing card details. Businesses store credit card details for various purposes. While sometimes this is necessary to support legitimate business practices, storage of card data can lead to theft of customer information and significant impact to your business. ANZ recommend that card data is never stored on your systems. Some common reasons businesses store card data; Regular billing cycle (e.g. Internet Service Providers, Gym Memberships) A form of security (e.g. Car Hire, Video Rentals) Customer convenience (e.g. Restaurants, Online Music Stores) Marketing purposes. In some cases credit card information can be inadvertently stored in log files created by billing or batch applications. If you operate a merchant hosted Payment Page, you should confirm with your web host provider that they do not record any card data in log files. You should answer yes to this question if you store card details in any form masked, truncated, encrypted; in spreadsheets, databases, paper files etc. Your IT Personnel 2.1 Purpose of card data storage Recurring Batched Scheduled Pre-Authorisation Other This question requires you to identify the purposes for which you store card data. If the purpose is not covered by one of the transactional categories below, then you should answer Other and provide a brief explanation instead. Recurring transactions Recurring transactions are transactions which are processed at regular intervals, usually as part of an ongoing payment arrangement. Monthly subscription fees are a common example of recurring transactions. Expiry dates are not required for recurring transactions. Batched transactions Batched transactions are processed by creating a file containing the necessary transaction details, including card numbers and the value to be processed. The file is then either uploaded to a processing system, or imported into a batch application on a local PC. Scheduled transactions Scheduled transactions are transactions which are processed at some point in the future, but are not part of an ongoing payment arrangement. An example of a scheduled transaction is where a customer orders a product which is not in stock and provides their card details, and the transaction is not processed until the item is in stock. Authorisation and Complete (Pre-Authorisation) transactions Authorisation and complete transactions allow you to hold funds on your customers card without transferring the funds until you have confirmed the order. Generally, Payment Gateways do not require the card data to be stored after the Authorisation, only the reference number is required. Other If you store card data for a purpose other than those listed above, select other and provide a brief explanation. Refer: ANZ Merchant Services General Terms and Conditions and ANZ Fraud minimisation guide and chargebacks

6 6 2.2 Security requirements for Business and IT systems Strong network security is something you should always have in place, and is essential if you are storing or handling sensitive customer information or credit card data. Storing such information on your network poses a significant risk, as the cost of a security breach can be enough to shut down an otherwise healthy business. There are excellent alternatives to storing sensitive information on your network. There are many Service Providers who specialise in managing sensitive information securely, allowing you to remove most, if not all, of the risk from your business. If the use of a 3rd party Service Provider is not an option, the following is a list of some must have security mechanisms and processes. Firewalls Firewalls are used to protect your internal network from the Internet, and ideally should be used on all personal computers and servers. A firewall must be configured properly in order to be effective. The most effective use of a firewall involves blocking all non-essential traffic and only allowing connections from trusted sources. Intrusion Detection Services Intrusion detection services are used to alert you to potential breaches of network security. In addition to notifying you that a breach has taken place, they also should be monitored so that attempted intrusions can be stopped, and generate logs to allow for daily review with an audit trail history for at least 1 year. Documented Incident response procedures for a system breach or suspected data compromise Your incident response plan should be thorough and contain all the key elements to allow your company to respond effectively in the event of a breach that could impact cardholder data. For further information, download Visa s What to Do if Compromised? guide - Service providers Your business may require Service Providers to share or access credit card information for example call centre providers, outsourced IT staff, website developers, web hosting companies or others. If your business shares access to credit card information with your Service Providers, ensure this data is protected by maintaining a written agreement that acknowledges the Service Provider is responsible for the security of the of the card data they possess. Ask your Service Providers to provide an annual status of their compliance with PCI DSS (Payment Card Industry Data Security Standard). For more information on PCI DSS, visit the PCI SSC website: Information security policy & training A strong security policy sets the security tone for the whole company and lets your staff know what is expected of them. All staff should be aware of the sensitivity of data and their responsibilities for protecting it. For further information, visit the ISO27001 website for tools and templates to assist with developing your Information Security Policy: Anti Virus Anti Virus software protects your computers and computer network from malicious software by identifying and removing threats before they can cause damage. Anti Virus software needs to be updated regularly in order to be effective and should be running on all Personal Computers and Servers. Storing card numbers In general, card numbers should never be stored. When there is a legitimate business need to store card information, the card information should be stored for the minimum time possible. Card numbers must be encrypted when stored and the encryption keys should be protected. Encryption must meet PCI DSS standards. Encryption Key management processes must be documented and in place. Refer to for a complete list of requirements relating to the storage of card data. Card Security codes (CVV2/CVC2) Card security codes must never be stored in any form, even if encrypted. These codes can only be used if the card holder is directly providing card details at the time of the transaction. Your IT Personnel Your IT Systems Supplier Remember, using a Bank or 3rd party hosted solutions can remove most of the requirements for your business to store or handle card data directly. Talk to ANZ about alternatives today. Australia and New Zealand Banking Group Limited (ANZ) ABN ANZ s colour blue is trade mark of ANZ. Item No W232903