User Tools

Site Tools


pci_compliance

PCI Support Training

Windward Software Inc.

What is the difference between PCI Compliance and PA-DSS Validation?

PA-DSS PCI-DSS
What it is? PA-DSS is the standard against which System Five has been tested, assessed, and validated. PCI-DSS Compliance is obtained by the merchant, and is an assessment of your actual server (or hosting) environment.
What it's for? PA-DSS Validation is intended to ensure that System Five will help you achieve and maintain PCI Compliance with respect to how System Five handles user accounts, passwords, encryption, and other payment data related information. “PCI DSS Compliance” is the responsibility of the merchant and their hosting provider, working together, using PCI compliant server architecture with proper hardware & software configurations and access control procedures.

Payment Card Industry (PCI) has developed security standards for handling card holder information in a published standard called the PCI Data Security Standard (DSS). The security requirements defined in the DSS apply to all members, merchants, and service providers that store, process or transmit card holder data.

The PCI DSS requirements apply to all system components within the payment application environment which is defined as any network device, host, or application included in, or connected to, a network segment where card holder data is stored, processed or transmitted

The 12 Requirements of the PCI DSS

Outlined below are the 12 requirements for the PCI DSS. For more details, refer to this link

Build and Maintain a Secure Network
1. Install and maintain a firewall configuration to protect data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Card holder Data
3. Protect Stored Data
4. Encrypt transmission of card holder data and sensitive information across public networks
Maintain a Vulnerability Management Program
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
Implement Strong Access Control Measures
7. Restrict access to data by business need-to-know
8. Assign a unique Id to each person with computer access
9. Restrict physical access to card holder data
Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and card holder data
11. Regularly test security systems and processes
Maintain an Information Security Policy
12. Maintain a policy that addresses information security

Sensitive credit card data requires special handling

Keep in mind the following guidelines when dealing with sensitive Credit Card data:
  • Collect card holder data only when needed to solve a specific problem.
  • Store such data only in specific, known locations with limited access.
  • Collect only the limited amount of data needed to solve a specific problem.
  • Encrypt card holder data while stored.
  • Securely delete such data immediately after use.
  • Never collect or store sensitive data (MSR track 2,PIN,CVV)

Sensitive Data: This data can not be stored

  • Track 2 – the magnetic track data from the credit card
  • CVV 1) or CVV2 2) – 3 or 4 digit number from the back of the card
  • PIN and PIN Block – the pin number or pin block from the PIN Pad
  • Cardholder data 3)

Cardholder data that requires encryption

System Five uses AES256 encryption

  • Credit Card PAN 4) (primary access number)
  • Expiry date
  • Card holder name
  • Also user passwords must be encrypted.

Note: The chip contains track equivalent data as well as other sensitive data, including the Integrated Circuit (IC) Chip Card Verification Value (also referred to Chip CVC, iCVV, CAV3 or iCSC).
source: Page 8

Set up Good Access Controls

The PCI DSS requires that access to all systems in the payment processing environment be protected through use of unique users and complex passwords. Unique user accounts indicate that every account used is associated with an individual user and/or process with no use of generic group accounts used by more than one user or process. Additionally any default accounts provided with operating systems, databases and/or devices should be removed/disabled/renamed as possible, or at least should have PCI DSS compliant complex passwords and should not be used. Examples of default administrator accounts include “administrator” (Windows systems), “sa” (SQL/MSDE), and “root” (UNIX/Linux).

Password Requirements

The PCI standard requires the following password complexity for compliance (often referred to as using “strong passwords”):

  • Administrator passwords must be at least 7 characters.
  • Administrator passwords must include both numeric and alphabetic characters
  • Administrator passwords must be changed at least every 90 days.
  • New administrator passwords can not be the same as the last 4 passwords.
PCI user account requirements beyond uniqueness and password complexity are listed below:
If an incorrect administrator password is provided incorrectly 6 times then the account should be locked out.
Account lock out duration should be at least 30 min. (or until an administrator resets it).
Administrator Sessions idle for more than 15 minutes should require re-entry of username and password to reactivate the session. Note: System Five can automatically log out all users after 5 minutes of inactivity.
Do not use group, shared or generic user accounts

Log Settings must be Compliant

  • System Five has logging enabled by default and is not configurable.
  • The log file can be viewed by an administrator via the System Five View Event Log window 5) under the Utilities menu.
  • All access to non truncated Card holder data is logged by System Five. In addition, all logins, attempted logins, password changes, configuration changes and accesses to the log file itself are logged. Log file entries are date/time stamped and identify the user and system component.

Maintain an Information Security Program

The Windward Support policy, regarding the collection of data for testing purposes, requires the owner of the data to use the System Five Zip and Transfer utility, which excludes all sensitive credit card data, to prepare and transfer their non-sensitive data to a designated windward site. For more information please consult the Windward Support Policy.

Conducting Test Transactions

  • Do not use real card numbers for testing, demonstration or training. On initial setup of payment processing a real transaction should be made to ensure that all money is successfully deposited into your bank account. This transaction should be made several days in advance of going live and you should verify the successful bank deposit prior to running further transactions.
  • Please contact support for test merchant accounts and test card numbers for testing, demonstration or training purposes. It is important that you do not use test numbers in a live merchant account as this may prevent the batch from closing and loss of the entire batch.
  • For further information on conducting test transactions, refer to Defining the Payment Gateway above.

The following files may contain prohibited or sensitive information from prior versions

  • comment.btr may contain track2 data from dos ICVERIFY in version 5.25. If you never used ICVerify using System Five DOS version this will not pertain to you.
  • lcomment.btr may contain encrypted and / or truncated merchant receipts prior to 5.40
  • blobhead.btr
  • blobdata.btr may contain encrypted electronic merchant receipt copy.
  • words.btr used to contain un-encrypted passwords in versions prior to 5.43.

The following files may contain sensitive encrypted information.

  • CNUMBERS.BTR Encrypted card holder information
  • WORDSTOO.BTR
  • WORDSLST.BTR User and security information
  • BLOBHEAD.BTR
  • BLOBDATA.BTR Encrypted Signature capture data.
  • HIGHENC.BTR Encrypted credit card receipt information
  • SIGHEAD.BTR
  • SIGDATA.BTR Encrypted Signature capture data.

Event Logging

System Five in accordance with PCI rules tracks certain events. System Five also tracks other events that may show fraudulent activity. The event logging has two purposes.

  1. To detect users who are trying to access the system in an unauthorized manner.
  2. In the event of a system comprise, to determine who, where and why the system was compromised.

The events that are logged are as follows.

  • General user events.
  • Viewing of the log file.
  • Changing passwords.
  • Any Users logging in (including administrators)
  • Failed attempts of users logging in.
  • Users logging off
  • Invoice reprints.
  • Opening of cash drawer
  • Deleting a payment.
  • Running toolbox routines.
  • Changing of configuration settings.
  • Running or being prompted to run the PCI Compliance check.
  • Accessing non-trusted (code signed) programs and controls required for payment processing.

The following information is logged.

  • Date and time. For this information to be useful, all computer clocks must be synchronized. System Five has an automatic utility for detecting if a computer's time and date is different from other computers who are running System Five. This option is automatically enabled, but can be configured in the Setup Wizard, Miscellaneous, Time/Date Checking. The options are to use time date checking, and the time offset to the main server if you are running in different time zones.
  • Terminal. The terminal number of the event.
  • User. The user number of the event.
  • Operation. The event type.
  • File and Record. If the event affected a certain record.
  • Check Sum. A check sum which will detect if the event log record has been tampered with externally.
  • Sequence. A sequence number which will aid in detecting if a record has been deleted externally.
  • Text. A description of the event.

Key Management

All sensitive data in System Five is encrypted with Data Encryption Keys (DEK) which are automatically dynamically created as required. The Data Encryption Keys are encrypted stored in the database and are encrypted with Key Encrypting Keys (KEK). When System Five is first installed a standard set of KEKs are used. Before integrated payment processing is enabled, the standard KEKs must be replaced with a set of Dynamic company specific set of encryption keys in order that the payment application is PCI compliant

  • Debug logging
  • Debug logging must never log cardholder data or sensitive information.
  • Debug logging should not be employed in a production environment.
1)
CVV - Card Verification Value (Visa and Discover payment cards)
2)
CVV2 - Card Verification Value 2 (Visa payment cards)
3)
Cardholder Data: At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code See Sensitive Authentication Data for additional data elements that may be transmitted or processed (but not stored) as part of a payment transaction.
4)
PAN: Acronym for “primary account number” and also referred to as “account number.” Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account.
5)
Navigator → Setup Tools → Utilities → View Event Log
pci_compliance.txt · Last modified: 2013/12/05 12:52 by cromo