Twin Oaks Club Management Software v6.x PA DSS Implementation Guide v2.0 PDF

Club Management Software v6.
3 PA-DSS
Implementation Guide
v2.0
August 1, 2014
Twin Oaks Software Development, Inc. Confidential
Revision History
Purpose
To establish a procedure for updating our Implementation Guide to reflect any changes or updates to our
payment application to maintain our PA DSS adherence and certification.
Policy
Beginning August 15, 2013 and continuing annually until no longer necessary, the Implementation Guide
will be updated to reflect any and all changes made to Twin Oaks Club Management Software (“TOCMS”)
and/or Twin Oaks Software Development, Inc.’s (“TOSD or Twin Oaks”) internal policies and procedures in
the previous year. 2 weeks prior to August 15th or the closest business day to it, a TOSD representative
will be designated to manage and complete this task. The employee designated will have the required
security clearance and authority to complete this task. Representative will work closely with our QSA to
update the Guide and insure compliance is maintained. A log of the representative designated with this
task and a summary of changes made to the Implementation Guide and tasks performed by QSA and the
completion date will be appended to this document beginning with the first annual review and maintained
thereafter.
Date Initiated Representative Name Completion Date
August 1, 2012 MJ Laliberte
August 1, 2012 Page i

Table of Contents
1 INTRODUCTION AND SCOPE ........................................................................... 1
1.1 Introduction ......................................................................................... 1
1.2 Purpose .............................................................................................. 1
1.3 Scope ……………………………………………………………………………………………………………………………..1
1.4 PCI PA-DSS Guidance .............................................................................. 1
1.4.1 THE 12 REQUIREMENTS OF THE PCI DSS: ...........................................1
1.4.2 CONSIDERATIONS FOR THE IMPLEMENTATION OF TOCMS IN A PCI-COMPLIANT

ENVIRONMENT ..........................................................................................2
1.5 ENTER CARDHOLDER DATA IN FIELDS DESIGNED FOR THAT PURPOSE .................. 3
2 SECURE DELETION OF DATA AND PROTECTION OF STORED CARDHOLDER DATA .......... 3
2.1 Delete sensitive authentication data stored by previous application versions (PA-
DSS 1.1.4.a) ………….......................................................................................... 3
2.2 Delete any SENSITIVE AUTHENTICATION DATA (pre-authorization) gathered as a

result of troubleshooting the payment application (PA-DSS 1.1.5.c) ............................ 4
2.3 Purge cardholder data after customer-defined retention period (PA-DSS 2.1) ....... 4
3 CRYPTOGRAPHY AND ACCESS CONTROLS .......................................................... 5
3.1 Cardholder Data Encryption Key Management (PA-DSS 2.5.c and 2.6.a) ............... 5
3.2 Delete cryptographic key material or cryptograms stored by previous payment

application versions (PA DSS 2.7.a)...................................................................... 6
3.3 Use unique usernames and secure authentication for administrative access and
access to cardholder data (PA DSS 3.1) ................................................................. 6
3.4 Use unique usernames and secure authentication for access to PCs, servers, and
databases with payment applications (PA DSS 3.2) .................................................. 7
4 LOG SETTINGS, REQUIRED PROTOCOLS AND SOFTWARE DEPENDENCIES .................... 8
4.1 Implement automated audit trails (PA DSS 4.1.b, 4.2, 4.3, 4.4.b) ...................... 8
4.2 Required protocols and software dependencies (PA DSS 5.4.c) ......................... 9
5 PCI COMPLIANT WIRELESS SETTINGS ................................................................ 9
5.1 Securely implement wireless technology (PA DSS 6.1.f and 6.2.b) ..................... 9
August 1, 2012 Page ii

5.2 Secure transmissions of cardholder data over wireless networks ...................... 10
6 CARDHOLDER DATA STORAGE, REMOTE ACCESS AND APPLICATION UPDATES ............ 10
6.1 Store cardholder data only on servers not connected to the Internet (PA DSS 9.1.b)
………………………………………………………………………………………………………………………………………….1
0
6.2 Implement two-factor authentication for remote access to payment application (PA
DSS 10.2)………. .............................................................................................. 11
6.2.1 Twin Oaks Access .................................................................... 11
6.2.2 Securely implement remote access software (PA DSS 10.3.1 and 10.3.2.b) 11
6.2.3 Securely deliver remote payment application updates (PA DSS 10.3.1) .... 11
7 SECURE TRANSMISSION AND ENCRYPTION ........................................................ 12
7.1 Secure transmissions of cardholder data over public networks (PA DSS 11.1.b) .... 12
7.2 Encrypt cardholder data sent over end-user messaging technologies (PA DSS 11.2.b)
12
7.3 Encrypt non-console administrative access ................................................. 12
8 OTHER REQUIREMENTS ............................................................................... 12
9 APPENDIX A – ADDRESSING INADVERTENT CAPTURE OF PAN.................................. 13
10 APPENDIX B – ADDITIONAL WINDOWS SETTINGS ................................................. 20
August 1, 2012 Page iii

1 Introduction and Scope
1.1 Introduction
Payment applications must be capable of being implemented in a PCI DSS compliant manner. This
guide and all associated policies, standards, and procedures of the PCI DSS security program
establish specific control requirements, performance criteria, and minimum thresholds for
security controls required to safeguard the protected cardholder information processed by TOSD’s
Twin Oaks Club Management System payment application.
1.2 Purpose
This guide will assist TOSD’s clients in implementing TOCMS in a PCI Compliant manner and
ensuring that the installation of TOCMS does not make any client Non-compliant with PCI DSS
requirements.
1.3 Scope
The Twin Oaks Club Management System PA-DSS IMPLEMENTATION GUIDE applies to version 6.3.x
of the Twin Oaks Club Management System application running on the following Operating
Systems: Windows XP, Windows 7 and Windows 8. Running this application on any other OS could
cause you to be Non-compliant with PCI DSS requirements.
1.4 PCI PA-DSS Guidance

The protection of cardholder data is an important responsibility for any company that stores,
processes or transmits credit card data. Using any single software application cannot make you
compliant and no software vendor can claim that simply by using their product you are free from
all payment processing security issues. What a vendor should be able to say is that proper
installation and use of their software will not keep you from being compliant.
The following guidance is given to ensure that Twin Oaks’s customers can install the Twin Oaks
Club Management System application in a PCI DSS compliant manner. It is up to each company to
adhere to all PCI DSS requirements and meet compliance to protect cardholder data. This guide
will ensure that the installation of Twin Oaks Club Management System will not keep your
company from being PCI DSS compliant.
1.4.1 THE 12 REQUIREMENTS OF THE PCI DSS:
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 Cardholder Data
3. Protect Stored Data
4. Encrypt transmission of cardholder data and sensitive information across public networks
August 1, 2012 Page 1

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 cardholder data
Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
Maintain an Information Security Policy
12. Maintain a policy that addresses information security
1.4.2 CONSIDERATIONS FOR THE IMPLEMENTATION OF TOCMS IN A PCI-COMPLIANT

ENVIRONMENT
The following areas must be considered for proper implementation in a PCI-Compliant

environment.
 Sensitive Authentication Data requires special handling
 Remove Historical Cardholder Data
 Set up Good Access Controls
 Properly Train and Monitor Administrative Personnel
 Key Management Roles & Responsibilities
 PCI-Compliant Remote Access
 Use SSH, VPN, or SSL v3/TLS for encryption of administrative access
 Log settings must be compliant
 PCI-Compliant Wireless settings
 Data Transport Encryption
 PCI-Compliant Use of Email
 Network Segmentation
 Never store cardholder data on internet-accessible systems
 Use SSL v3 for Secure Data Transmission
 Delivery of Updates in a PCI Compliant Fashion

1.5 ENTER CARDHOLDER DATA IN FIELDS DESIGNED FOR THAT PURPOSE
All Cardholder account information must only be entered in the fields designed for that purpose.
The tokenization/encryption is tied into the Account Number field and the Secondary Credit Card
#/POS Card # field. These are the only fields that properly protect Cardholder account
information.
Entry of Cardholder account information in another field may cause you to be out of PCI
Compliance due to storage of unencrypted Cardholder account numbers.
2 Secure Deletion of Data and Protection of Stored Cardholder Data
2.1 Delete sensitive authentication data stored by previous application versions

(PA-DSS 1.1.4.a)
Historical SENSITIVE AUTHENTICATION DATA (“SAD”) was not stored by previous versions of
TOCMS. SAD is defined as magnetic stripe data; card validation codes; PINs; and PIN blocks.
Removal of SAD data is absolutely necessary for the end-user’s PCI DSS Compliance. Since prior
versions of TOCMS did not store SAD, there is no need for secure removal of this historical SAD
data by the application as required by PA-DSS v2.0.
Earlier Twin Oaks versions designated as 3.x or 4.x by default stored all data in the
C:\Tosdwin\Data directory. Backups of this data may also be found in the C:\Tosdwin1 or
C:\Tosdwin2 directories. A secure deletion tool is recommended. File Shredder is an example
of a secure deletion tool and is available at www.fileshredder.org. The default settings for File
Shredder are best for securely deleting your files. The Algorithms should be set for
DoD5220.22.M. Using File Shredder, you can delete a file by right clicking on the file and
choosing File Shredder in the box that appears on your screen.
 TOCMS does not generally store Primary Account Number (“PAN”); or SAD beyond
authorization. TOCMS uses a store and forward function in that each time PAN card
data is entered into the designated account number field(s) in a member record in the
TOCMS program, a secure, encrypted web service is called. The web service
exchanges the PAN data with a system created token, unique to the individual
client/member record combination. If the web service is unavailable at the time card

account information is being entered or updated, the PAN data is stored in a secure
method, with the data encrypted using AES. Upon any subsequent connection to the
web service, the PAN/token exchange takes place and the PAN data is eliminated from
the TOCMS database. By design, even if the normal web service exchange of token
data fails, the PAN data storage must never be longer than thirty (30) days. During the
course of the secure data exchange of the recurring monthly billing process, any
outstanding PAN data will be transmitted with the underlying token information
returned to the TOCMS database.
 Credit card data is located in the following: pendingtoken table. This file will be
located in the “Twin Oaks Software” directory located in the folder where you
installed TOCMS (example: C:\Database).
 If for any reason you want to delete your pendingtoken data, refer to the instruction in
section 2.3 of this document for use of the secure deletion tool included with TOCMS.
2.2 Delete any SENSITIVE AUTHENTICATION DATA (pre-authorization) gathered as

a result of troubleshooting the payment application (PA-DSS 1.1.5.c)
 SAD (pre-authorization)must only be collected when needed to solve a specific

problem
 Collection of this data must been done in a secure manner with data encrypted and
securely transmitted
 Such data must be stored only in specific, known locations with limited access
 Only collect a limited amount of such data as needed to solve a specific problem
 SAD must be encrypted while stored
 Such data must be securely deleted immediately after use. Please use the secure
deletion tool included with TOCMS. Refer to section 2.3 of this document for detailed
instructions on how to use this tool. For deletion of all files, a secure deletion tool is
recommended. File Shredder is an example of a secure deletion tool and is available
at www.fileshredder.org.
 During troubleshooting, Twin Oaks follows these same rules to protect any client data.
2.3 Purge cardholder data after customer-defined retention period (PA-DSS 2.1)
As a rule, PAN data is not retained in TOCMS. All data is automatically deleted upon
communication with the Twin Oaks web service and the exchange of the unique token.
Each customer must develop policies that identify the length of time to retain any stored
cardholder data. The timeframe must be as short as possible based on the business need. PAN
data is supposed to be purged by the customer based on the customer-defined retention period.
Manual Removal
A utility exists to manually purge PAN data in the pendingtoken table. You must understand that
this process is irreversible and by performing this function some people will not have updated
billing information at Twin Oaks for monthly billing purposes.
The process to manually purge PAN data is as follows:

1. Login to the Utilities Module.
2. Choose the Admin Options choice in the pull down menu.

Select the option to Purge PAN Data. You will be prompted for a date. All data in the
pendingtoken table with a date prior to the one entered will be securely deleted.
Addressing Inadvertent Capture of PAN
Please refer to Appendix A
3 Cryptography and access controls
3.1 Cardholder Data Encryption Key Management (PA-DSS 2.5.c and 2.6.a)
The following key management functions must be performed per PCI DSS:
 Generation of strong cryptographic keys
 Secure cryptographic key distribution
 Secure cryptographic key storage
 Cryptographic key changes for keys that reached the end of their cryptoperiod (for
example, after a defined period of time has passed and/or after a certain amount of
ciphertext has been produced by a given key), as defined by the associated application
vendor or key owner, and based on industry best practices and guidelines.
 Retire keys when the integrity of the key has been weakened
 Replace known or suspected compromised keys
 If retired or replaced cryptographic keys are retained, the application cannot use these
keys for encryption operations
 Manual clear-text key-management procedures require split knowledge and dual control of
keys
 Prevention of unauthorized substitution of cryptographic keys
TOCMS utilizes an application embedded encryption system. This system, which generates strong
encryption keys using a combination of the separated keys embedded in the application along with
the user specific public, private and key encrypting key (“KEK”), alleviates the need for the user
to:
 Restrict access to keys to the fewest number of custodians necessary
 Store keys securely in the fewest possible locations and forms
 Securely generate, distribute, protect, change, store, and retire/replace encryption keys,
where customers or resellers/integrators are involved in these key management activities
 Have key custodians that acknowledge that they understand and accept their key
custodian responsibilities

 Perform the key management functions as defined above
3.2 Delete cryptographic key material or cryptograms stored by previous

payment application versions (PA DSS 2.7.a)
All cryptographic key materials are replaced by new versions automatically. The TOCMS
application gives regular program and .dll updates using a secure, encrypted process. Twin Oaks
releases new application embedded cryptographic keys on at least an annual basis, and more
regularly if needed. Old cryptographic keys are overwritten automatically by this update
process, so user intervention is not required. The removal of old cryptographic materials is
required for PCI DSS compliance.
Earlier Twin Oaks versions designated as 3.x or 4.x stored executable program files and .dlls in
the C:\Tosdwin directory. To ensure elimination of any old cryptographic information, these
directories must be deleted. This can be accomplished using a secure deletion tool. File
Shredder is a recognized example of a secure deletion tool and is available at
www.fileshredder.org.
3.3 Use unique usernames and secure authentication for administrative access
and access to cardholder data (PA DSS 3.1)
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 with no use of generic group accounts used by
more than one user.
The TOCMS application allows the setup of individual accounts for each user of the software. The
setup includes a unique username and password combination (something you know) for the
authentication of access.
 Credit card data is located in the following file: pendingtoken. This file will be located in
the Twin Oaks Software directory located in the folder where you installed TOCMS
(example: C:\Database). Access to this file or the directory where it is contained must
only be through authenticated access. Failing to implement proper access controls to
these files and/or directory will result in non-compliance with PCI DSS regulations.
 Do not use default administrative accounts for payment application logins.
 Assign secure authentication to default accounts (even if not used), and disable or do not
use the accounts.
 Always use secure authentication for the payment application and system.
 Generic user IDs and accounts such as “Guest” are disabled or removed.
 Shared user IDs for system administration activities and other critical functions do not
exist.
 Password policies and procedures must prohibit group or shared passwords for any user.
 Administrative users must be forced to change their passwords at least every ninety (90)
days.

 Administrative passwords are required, at a minimum, to be at least seven (7) characters

in length.
 Administrative passwords are required to be composed of both numeric and alphabetic
characters.
 Administrative password parameters are set to require that new passwords cannot be the
same as the four previously used passwords.
 Administrative password parameters are set to require that a user’s account is locked
out after not more than six invalid logon attempts.
 Administrative password parameters are set to require that once a user account is locked
out, it remains locked for a minimum of 30 minutes or until a system administrator
resets the account
 System idle settings for TOCMS administrative workstations must time out after 15
minutes or less of inactivity. You must set the operating system screen saver to activate
within 15 minutes and require a password to resume the user session.
3.4 Use unique usernames and secure authentication for access to PCs, servers,
and databases with payment applications (PA DSS 3.2)
 To ensure PCI DSS compliance you must control access, via unique user ID and PCI DSS-
compliant secure authentication, to any PCs, servers, and databases with payment
applications and cardholder data. Your system is delivered with an application default
username of 001 and a password of Master01. This login is expired by default. You will
be forced to change this password upon initial login.
 The TOCMS program is designed so each user can be assigned a unique username and
password for better security and to meet the requirements of PCI DSS. You must only
give people access to the least number of modules, and menu items within each module,
as needed to perform their job function.
 Credit card data is located in the following table: pendingtoken. This table will be
located in the Twin Oaks Software directory located in the folder where you installed
TOCMS (example: C:\Database). Access to the PCs where this file or the directory is
contained must only be through authenticated access. Failing to implement proper
access controls to the PCs running TOCMS will result in non-compliance with PCI DSS
regulations.
 Generic user IDs and accounts such as “Guest” are disabled or removed.
 Shared user IDs for system administration activities and other critical functions do not
exist.
 Password policies and procedures must prohibit group or shared passwords for any user.
 Users must be forced to change their passwords at least every ninety (90) days.
 Passwords are required, at a minimum, to be at least seven (7) characters in length.
 Passwords are required to be composed of both numeric and alphabetic characters.
 Password parameters are set to require that new passwords cannot be the same as the
four previously used passwords.
 Password parameters are set to require that a user’s account is locked out after not
more than six invalid logon attempts.

 Password parameters are set to require that once a user account is locked out, it
remains locked for a minimum of 30 minutes or until a system administrator resets the
account
 System idle settings for TOCMS administrative workstations must time out after 15
minutes or less of inactivity. You must set the operating system screen saver to activate
within 15 minutes and require a password to resume the user session.
In is the responsibility of the user entity to institute proper personnel management techniques for
allowing administrative user access to cardholder data. The application has functionality to
control whether each individual administrative user can see credit card PAN or only the last 4.
In most systems, a security breach is the result of unethical personnel, so it is important to pay
special attention to the administrative users that can be trusted to view full decrypted and
unmasked payment information.
4 Log Settings, Required Protocols and Software Dependencies
4.1 Implement automated audit trails (PA DSS 4.1.b, 4.2, 4.3, 4.4.b)
 Credit card data is located in the following table: pendingtoken. This table will be
located in the Twin Oaks Software directory located in the folder where you installed
TOCMS (example: C:\Database).
 Logging of access to the pendingtoken table through the TOCMS program is enabled by
default, and this setting is not configurable by the user. The TOCMS program logs every
instance of any account number being viewed or changed. Logs must not be disabled.
The disabling of logs will result in non compliance with PCI DSS.
 You must review the logs of access to any PAN data on a regular basis. A report is
available for this review in the Utilities Module called System Logs. This report can be
run as desired based on a range of dates entered.
 PCI DSS requires further logging information. The user must verify they have addressed
other areas covered by the PCI DSS requirement.
 The following must be logged:
1. All individual user access to cardholder data. (pendingtoken)
2. All access to audit trails.
3. Any access by users with “root” or administrative privileges.
4. Invalid logical access attempts.
5. Use of application’s identification and authentication mechanisms.
6. Initialization of audit logs.
7. Creation and deletion of system level objects within or by the application.
 The logs must contain:
1. User ID
2. Type of Event
3. Date and time

4. Success or failure
5. Origination of event
6. Identity or name of affected data, system component, or resource
 Log files must be protected from modification through the use of file integrity
applications, access control mechanisms, physical segregation, and/or network
segregation.
 Read access to log files must be only those with job related needs.
 Log files must be promptly backed up to a central log server or media that is difficult to
alter. The log files from the application can be exported for storage on the centralized log
server by selecting the System Logs report from the Utilities module. The user has
multiple export options.
 Log files for external facing technologies (DMZ, firewalls, wireless, etc) are copied onto a
secure centralized internal log server or media.
 Audit log policies and procedures must include:
o a daily review of security logs
o follow-up to security exceptions is required
o audit log retention of at least one year
o a regular review of all system component logs
 All server clocks must be synchronized utilizing a Network Time Protocol (NTP) or similar
technology that is kept current.
o Only a select number of internal servers must poll external resources for NTP
updates and share those with the rest of the internal servers.
4.2 Required protocols and software dependencies (PA DSS 5.4.c)

TOCMS does not require the use of any insecure services or protocols. TOCMS does require the
following services and protocols: HTTPS; SSL v3/TLS.
5 PCI Compliant Wireless Settings
5.1 Securely implement wireless technology (PA DSS 6.1.f and 6.2.b)
The TOCMS application does not utilize wireless technology and was not intended to be utilized
with wireless technologies. Before a company implements wireless technology, they must evaluate
the business need against the risk. Twin Oaks recommends only implementing wireless technology
for non-sensitive data transmission. If you do not use wireless technology you must scan quarterly
to ensure no rogue access points have been installed on your network and your incident response
plan must contain a response in the event a rogue access point is detected.
If wireless is used within a payment card processing environment, to meet PCI DSS requirement
1.2.3:

 You must install a perimeter firewall to control traffic to and from the wireless network
and any systems that store cardholder data. These firewalls must deny or control any
traffic from the wireless environment into the cardholder data environment.
To meet PCI DSS requirement 2.1.1:
 Wireless vendor default settings must be changed before implementing the technology into
the production network. These include: SNMP community strings, encryption keys, default
usernames or passwords; firmware updates must be completed to support strong
encryption for authentication and encryption; and any other applicable default security
settings. Encryption keys must also be changed anytime anyone with knowledge of the
keys leaves the company or changes positions
To meet PCI DSS requirement 4.1.1
 You must use industry best practices (for example, IEEE 802.11.i) to ensure strong
encryption is available for authentication and transmission.
 Strong encryption such as SSL/TLS, IPSEC and SSH must be used to safeguard payment card
transmissions.
 Physical access to the wireless access points must be restricted to job related needs.
 Scan quarterly to ensure only authorized wireless access points are installed.
 Wireless IDS/IPS must be implemented and provide alerts to appropriate staff.
 Incident Response plan must include a response to rogue access points.
5.2 Secure transmissions of cardholder data over wireless networks

If wireless is used within a payment card processing environment:
 Strong encryption such as SSL/TLS, IPSEC or SSH must be used to safeguard payment card
transmissions.
o Industry best practices such as IEEE 802.11i must be used to implement strong
encryption for authentication and transmission.
o The use of WEP as a security control was prohibited as of June 30, 2010.
o Never send unprotected PANs by end user messaging technologies such as email,
chat, instant messaging, etc.
6 Cardholder Data Storage, Remote Access and Application Updates
6.1 Store cardholder data only on servers not connected to the Internet (PA DSS
9.1.b)
Do not store cardholder data on Internet-accessible systems. TOCMS has no need for the database
to be on a system directly connected to the internet. Putting any cardholder data on systems
connected to the internet increases the risk of compromise to the data and could put you out of
PCI DSS compliance.

6.2 Implement two-factor authentication for remote access to payment

application (PA DSS 10.2)
TOCMS does not include a built-in remote access solution. When implementing remote access to a
payment card application, you must use two-factor authentication (username and password and
an additional authentication item such as a token). Any remote access to the payment application
must be activated only when needed and immediately deactivated after use.
6.2.1 Twin Oaks Access
Twin Oaks uses either GoToAssist or Ultra VNC which requires the user to download the server
application, login to the provider and select the appropriate session information as instructed by
Twin Oaks staff members. Access rights must only include those needed fort the service
rendered.
6.2.2 Securely implement remote access software (PA DSS 10.3.1 and 10.3.2.b)
If you choose to use remote access to your payment application you must use remote access
software security features such as:
 Change default settings in the remote access software (for example, change default
passwords and use unique passwords for each customer).
 Allow connections only from specific (known) IP/MAC addresses.
 Use strong authentication and complex passwords for logins. Please refer to section 3.4 of
this document for further guidance.
 Enable encrypted data transmission according to PCI DSS Requirement 4.1.
 Enable account lockout after a certain number of failed login attempts.
 Configure the system so a remote user must establish a Virtual Private Network (“VPN”)
connection via a firewall before access is allowed.
 Enable the logging function.
 Restrict access to customer passwords to authorized reseller/integrator personnel.
 Establish complex customer passwords. Please refer to section 3.4 of this document for
further guidance.
6.2.3 Securely deliver remote payment application updates (PA DSS 10.3.1)
The necessary installation files are securely transmitted to you using SSL/TLS transmission and
username and password authentication, built into the TOCMS program. If you need to acquire the
installation package please contact Twin Oaks Tech Support at (800) 829-2339. The Twin Oaks
Tech Support team will work with you to securely deliver the updates and/or installation package.
If the Twin Oaks Tech Support team must use remote access to connect to your computer
system(s), you must use an application that requires two-factor authentication (username and
password and an additional authentication item such as a token). Twin Oaks uses GoToAssist or
Ultra VNC for remote access purposes. You must verify that the GoToAssist or Ultra VNC access is
deactivated as soon as Twin Oaks Tech Support has completed all activity.
For any VPN or other high-speed, always-on connection, you must always install a securely
configured either hardware or software firewall to protect against unauthorized access to your
computer system(s).

7 Secure Transmission and Encryption
7.1 Secure transmissions of cardholder data over public networks (PA DSS 11.1.b)
Implement and use SSL/TLS or some other strong encryption method for secure cardholder data
transmission over public networks.
TOCMS uses an encrypted web service sent from client location to Twin Oaks for storage purposes
for future authorization and settlement. This web service utilizes 128 bit SSL encryption with a
1024 bit RSA key.
7.2 Encrypt cardholder data sent over end-user messaging technologies (PA DSS
11.2.b)
TOCMS does not utilize any messaging technologies as part of its processes. It is strongly
recommended that you do NOT ever send PANs by end-user messaging technologies. If you have a
business need to send cardholder data over end-user messaging technologies you must implement
and use a PCI DSS compliant encryption solution, such as PGP.
7.3 Encrypt non-console administrative access
TOCMS does not utilize non-console administrative access. If you choose to utilize non-console
administrative access you must implement and use SSH, VPN, or SSL/TLS for encryption of any
non-console administrative access to payment application or servers in cardholder data
environment.
8 Other Requirements
In addition to the preceding security recommendations, a comprehensive approach to assessing
and maintaining the security compliance of the payment application environment is necessary to
protect the organization and sensitive cardholder data.
The following is a very basic plan every merchant/service provider must adopt in
developing and implementing a security policy and program:
 Read the PCI DSS in full and perform a security gap analysis. Identify any gaps between
existing practices in your organization and those outlined by the PCI requirements
 Once the gaps are identified, determine the steps to close the gaps and protect
cardholder data.
Changes could mean adding new technologies to shore up firewall and perimeter
controls, or increasing the logging and archiving procedures associated with
transaction data
 Create an action plan for ongoing compliance and assessment
 Implement, monitor and maintain the plan. Compliance is not a one-time event.
Regardless of merchant or service provider level, all entities must complete annual
self-assessments using the PCI Self-Assessment Questionnaire
 Call in outside experts as needed

9 Appendix A – Addressing Inadvertent Capture of PAN

Windows 7
DISABLE SYSTEM RESTORE SETTINGS
Disabling System Restore
1. Right-click on Computer and select Properties
2. Select System Protection from the top left list. The following screen will appear:
3. Select Configure. The following screen will appear:

4. Select Turn off system protection
5. Click Apply, and click OK to close the System Protection window
6. Click OK again to close the System Properties window
7. Reboot the computer
ENCRYPT THE SYSTEM PAGEFILE.SYS

Encrypting PageFile.sys
Note: In order to perform this operation, the hard disk must be formatted using NTFS.
1. On the Windows task bar, click on the Windows “Orb” and in the search box type in
“cmd”
2. Right-click on cmd.exe and select Run as Administrator
3. To Encrypt the PageFile, type the following command: “fsutil behavior set
EncryptPagingFile 1”
4. To verify configuration, type the following command: “fsutil behavior query

EncryptPagingFile”
5. If encryption is enabled, EncryptPagingFile = 1 should appear
6. In the event you need to disable PageFile encryption, type the following
command: “fsutil behavior set EncryptPagingFile 0”

7. To verify configuration, type the following command: “fsutil behavior query

EncryptPagingFile”
8. If encryption is disabled, EncryptPagingFile = 0 should appear
CLEAR THE SYSTEM PAGEFILE.SYS UPON SHUTDOWN
Windows has the ability to clear the PageFile.sys upon system shutdown. This will purge all
temporary data from the PageFile.sys (temporary data may include system and application
passwords, cardholder data (PAN/Track), etc.).
Note: Enabling this feature may increase windows
shutdown time.
1. Click on the Windows “Orb” and in the search box type in “regedit”
2. Right-click on regedit.exe and select Run as Administrator
3. Navigate to HKLM\System\CurrentControlSet\Control\Session Manager\Memory

Management
4. Change the value from 0 to 1
5. Click OK and close Regedit

6. If the value does not exist, add the following:
o Value Name: ClearPageFileAtShutdown
o Value Type: REG_DWORD
o Value: 1
DISABLE SYSTEM MANAGEMENT OF PAGEFILE.SYS
Disabling System Management of PageFile.sys

1. Right-click on Computer and select Properties
2. Select Advanced System Settings from the top left list. The following screen will
appear:

3. Under Performance, select Settings and click on the Advanced tab. The following
screen will appear:

4. Select Change under Virtual Memory. The following screen will appear:
5. Uncheck Automatically manage page file size for all drives
6. Select Custom Size
7. Enter the following for the size selections:
o Initial Size – as a good rule of thumb, the size should be equivalent to the
amount of memory in the system.
o Maximum Size – as a good rule of thumb, the size should be equivalent to 2x the
amount of memory in the system.
8. Click OK three times. You will be prompted to reboot your computer
DISABLE WINDOWS ERROR REPORTING

Disabling Windows Error Reporting
1. Open the Control Panel
2. Open the Action Center

3. Select Change Action Center Settings
4. Select Problem Reporting Settings
5. Select Never Check for Solutions

10 Appendix B – Additional Windows Settings

PASSWORD POLICY
Password Policy
In Windows Vista, Windows 7 or Windows 8 Pro click the start menu and type secpol.msc.
In Windows XP, click the start menu. Then choose “run” and type secpol.msc.
Go to the Security Settings, then Account Policy. You should see the following window.
Under Password Policy, set the policies as follows:
 Enforce password history – At least four passwords

 Maximum password age – No more than 90 days
 Minimum password length – At least seven characters
 Password must meet complexity requirements – Enabled
 Store passwords using reversible encryption – Disabled
We’d recommend setting the following:
 Minimum password age – One day

Under Account Lockout Policy, set the policies as follows:
 Account lockout duration – At least 30 minutes

 Account lockout threshold – No more than six invalid logon attempts
 Reset account lockout counter after – 15 minutes

AUDITING POLICY
Auditing Policy
Go to Security Settings, then Local Policies.
Under Audit Policy, set the policies as follows:
 Audit account login events – Success, Failure

 Audit account management – Success, Failure
 Audit directory service access – Success, Failure
 Audit logon events – Success, Failure
 Audit object access – Success, Failure
 Audit policy change – Success, Failure
 Audit privilege use – Success, Failure
 Audit process tracking – Success, Failure
 Audit system events – Success, Failure
Close the Local Security Policy Window.

ENABLE SCREENSAVER TIMEOUT AND LOCK
Enable Screensaver Timeout and Lock

In Windows 7, click the Start menu and type gpedit.msc.
In Windows XP, click the Start menu. Then choose “Run” and type gpedit.msc.
You should see the following window. This is the Local Group Policy Editor.

Go to User Configuration, then Administrative Templates, then Control Panel.
Under Personalization, set the policies as follows:
 Enable screen saver – Enabled

 Password protect the screen saver - Enabled
 Screensaver timeout – Enabled

When you enable the Screensaver timeout, be sure to set the Screensaver timeout to a number
that is not more than 900 seconds.

DISABLE SYSTEM RESTORE
Disable System Restore

While still inside the Local Group Policy Editor, go to Local Computer Policy, expand Computer
Configuration.
Next expand Administrative Templates, then System.
Under System Restore, set the options as follows:
 Turn off configuration – Enabled

 Turn off system restore – Enabled
Finally, reboot the computer and log back in.

WINDOWS 8 CORE SETTING

Windows 8 Core Settings (aka Home or Basic)
From the main tiles screen type cmd.exe
Right-click on cmd.exe this will put a checkmark on the cmd.exe tile.
Towards the bottom of the screen choose Run as Administrator
At the command prompt, type, SecEdit.exe /export /cfg c:\temp.cfg
Next, edit the policy that has been copied to c:\temp.cfg by typing notepad.exe c:\temp.cfg
This will open the temp.cfg in notepad for editing. Change the following options from their
defaults to the values listed below.
Under the [System Access] section:
 MinimumPasswordAge = 1
 MaximumPasswordAge = 90
 MinimumPasswordLength = 7
 PasswordComplexity = 1
 PasswordHistorySize = 4
 LockoutBadCount = 6
 ResetLockoutCount = 30
 LockoutDuration = 30
Under the Event Audit section:
 AuditSystemEvents = 1
 AuditLogonEvents = 1
 AuditObjectAccess = 1
 AuditPrivilegeUse = 1
 AuditPolicyChange = 1
 AuditAccountManage = 1
 AuditProcessTracking = 1
 AuditDSAccess = 1
 AuditAccountLogon = 1
After making these changes, click the File menu and then click Save. Then close notepad.
Back in the cmd.exe window enter the following command:

SecEdit.exe /configure /db %windir%\security\local.sdb /cfg c:\temp.cfg /areas
SECURITYPOLICY
If you would like to confirm the settings, type net accounts

Close the command prompt.
To configure the screensaver settings, press the Windows Key and type screensaver.
Below the search box, you will see that settings has 3 matching items. Select settings.
To the left choose Turn Screensaver On or Off
In the Screen Saver Settings Window change the wait time to 15 minutes and check the box that
says “On resume, display login settings”
Once the changes are made, click Apply, and then OK.

END OF DOCUMENT

Twin Oaks Club Management Software v6.x PA DSS Implementation Guide v2.0 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Twin Oaks Club Management Software v6.x PA DSS Implementation Guide v2.0 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Club Management Software v6.

Date Initiated Representative Name Completion Date

August 1, 2012 MJ Laliberte

August 1, 2013 MJ Laliberte

August 1, 2014 MJ Laliberte

August 1, 2012 Page i

1 INTRODUCTION AND SCOPE ........................................................................... 1

1.1 Introduction ......................................................................................... 1

1.2 Purpose .............................................................................................. 1

1.3 Scope ……………………………………………………………………………………………………………………………..1

1.4 PCI PA-DSS Guidance .............................................................................. 1

1.4.1 THE 12 REQUIREMENTS OF THE PCI DSS: ...........................................1

1.4.2 CONSIDERATIONS FOR THE IMPLEMENTATION OF TOCMS IN A PCI-COMPLIANT

2 SECURE DELETION OF DATA AND PROTECTION OF STORED CARDHOLDER DATA .......... 3

2.2 Delete any SENSITIVE AUTHENTICATION DATA (pre-authorization) gathered as a

3 CRYPTOGRAPHY AND ACCESS CONTROLS .......................................................... 5

3.2 Delete cryptographic key material or cryptograms stored by previous payment

4 LOG SETTINGS, REQUIRED PROTOCOLS AND SOFTWARE DEPENDENCIES .................... 8

5 PCI COMPLIANT WIRELESS SETTINGS ................................................................ 9

August 1, 2012 Page ii

5.2 Secure transmissions of cardholder data over wireless networks ...................... 10

6 CARDHOLDER DATA STORAGE, REMOTE ACCESS AND APPLICATION UPDATES ............ 10

6.2.1 Twin Oaks Access .................................................................... 11

7 SECURE TRANSMISSION AND ENCRYPTION ........................................................ 12

7.3 Encrypt non-console administrative access ................................................. 12

8 OTHER REQUIREMENTS ............................................................................... 12

9 APPENDIX A – ADDRESSING INADVERTENT CAPTURE OF PAN.................................. 13

10 APPENDIX B – ADDITIONAL WINDOWS SETTINGS ................................................. 20

August 1, 2012 Page iii

1 Introduction and Scope

1.4 PCI PA-DSS Guidance

1.4.1 THE 12 REQUIREMENTS OF THE PCI DSS:

Build and Maintain a Secure Network

1. Install and maintain a firewall configuration to protect data

Protect Cardholder Data

3. Protect Stored Data

August 1, 2012 Page 1

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 cardholder data

Regularly Monitor and Test Networks

11. Regularly test security systems and processes

Maintain an Information Security Policy

12. Maintain a policy that addresses information security

1.4.2 CONSIDERATIONS FOR THE IMPLEMENTATION OF TOCMS IN A PCI-COMPLIANT

The following areas must be considered for proper implementation in a PCI-Compliant

 Sensitive Authentication Data requires special handling

 Remove Historical Cardholder Data

 Set up Good Access Controls

 Properly Train and Monitor Administrative Personnel

 Key Management Roles & Responsibilities

 PCI-Compliant Remote Access

 Use SSH, VPN, or SSL v3/TLS for encryption of administrative access

 Log settings must be compliant

 PCI-Compliant Wireless settings

 Data Transport Encryption

 PCI-Compliant Use of Email

 Never store cardholder data on internet-accessible systems

 Use SSL v3 for Secure Data Transmission