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

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 1800 555 427.
1. 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’.
Who can help answer
Web Developer
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.
Who can help answer
Web Developer
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
• T hese 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.
Who can help answer
Web Developer
Payment Gateway Service Provider
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.
Who can help answer
Web Developer
Web Host Provider
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
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
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)
(https://www.pcisecuritystandards.org/approved_companies_providers/approved_scanning_vendors.php)
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.
Who can help answer
Web Developer
Web Host Provider
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. www.[yourbusinessname].com.au).
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.
Who can help answer
Web Developer
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 email 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.
Who can help answer
Web Developer
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.
Who can help answer
Your IT Personnel
Web Developer
Web Host Provider
2.1 Purpose of card data storage
Recurring
Batched
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.
Scheduled
Recurring transactions
Pre-Authorisation
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.
Other
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
Who can help answer
Web Host Provider
Web Developer
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 http://www.visa-asia.com/ap/center/merchants/riskmgmt/includes/uploads/AIS_Guide_what_to_do_if_compromised.pdf
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:
https://www.pcisecuritystandards.org/index.php.
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:
http://www.iso27001security.com/index.html
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 www.pcisecuritystandards.org 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.
Who can help answer
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 11 005 357 522. ANZ’s colour blue is trade mark of ANZ. Item No. 85053 07.2011 W232903