Visa U.S.A. Cardholder Information Security Program (CISP)

Payment Application Best Practices (PABP)

As a business entity that processes credit cards, in terms of both getting authorizations as well as processing sales, you are required to be compliant with the 'Payment Card Industry Data Security Standard' (PCI DSS). There are several levels of PCI DSS compliance. One criterion is the number of credit card transactions processed in a year. You need to review the compliance documentation at https://www.pcisecuritystandards.org and take the necessary steps to obtain and maintain your appropriate PCI DSS compliant status.

By AutoClerk, Inc. being PABP compliant, we support your PCI DSS compliance. Our being PABP compliant does NOT make you PCI DSS compliant.

The PCI DSS consists of 12 Requirements that cover the handling, processing and storage of credit card data:

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data
Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

This Implementation Guide explains your and AutoClerk's role in the security of your guests' credit card data; instructs you and your network administrator how to enable security settings in regards to both your network and hardware; instructs you on secure AutoClerk product implementation; and defines some of your responsibilities for meeting PCI DSS requirements.

Following these guidelines does NOT make you PCI DSS compliant, nor does it guarantee your network's security. It is your responsibility, along with your network administrator, to ensure that your hardware and network systems are secure from internal as well as external intrusions.

AutoClerk makes no claims on the security of your network, nor of your level of being PCI DSS compliant.

One of the most vulnerable areas for credit card data is within what is referred to as 'legacy data'. Legacy data includes, but is not limited to AutoClerk installations on computers no longer in use, backups on old computers, backups on old zip disks, and backups on other storage devices. In addition, any stored paper records that contain credit card data, including but not limited to registration slips, folios and reports. Legacy AutoClerk data may be found at existing AutoClerk properties, not running the PABP compliant version.

Appendix A to this Implementation Guide details what EVERY existing property MUST do to securely delete this legacy data from their systems. Once the data has been securely deleted, you must then have your network administrator use a wipe tool to scrub the unused space to make it unreadable and unrecoverable.

Depending on when your property came online with the AutoClerk PMS, you received Data Security Letter(s) dated July 24, 2006; October 12, 2006 and/or February 2, 2007. These gave information and instructions on user password security and data security in regards to credit card information. Please review the letters and implement any security measures as needed. These letters and security issues apply to ALL AutoClerk clients, regardless of size or when they came online with AutoClerk. If you cannot find your copies, they are attached as Appendixes B, C and D to this Guide.

Anytime AutoClerk was installed at your property, you were required to follow AutoClerk's system specifications (specs). You must review the current specs and have your network administrator verify that your AutoClerk network meets them. Changes the network administrator will need to make include adding in unique user names and complex Windows passwords for ALL the hotel's employees as well as other password restrictions. There are probably other changes which need to be made to bring your system to AutoClerk's current specs. Following AutoClerk's specs does NOT make you PCI DSS compliant; however, it contributes to your PCI DSS compliance as it includes sections on security issues such as user passwords and setting up a secure network. AutoClerk's System Specifications can be found at http://www.myautoclerk.com and are also attached as Appendix E to this document.

This Implementation Guide is organized by the PABP requirements which AutoClerk must meet to be PABP certified. In many cases, the measures you need to take have already been discussed and detailed either by the Data Security Letter(s) and/or the AutoClerk System Specifications. It also references the PCI DSS (Version 1.1 Release: September 2006) and the Appendixes.

Keep this Guide in a safe location for future reference. This Guide will also be posted on http://www.myautoclerk.com . AutoClerk will issue updated pages and/or sections as required.

Once you have read through this Guide; have had your network administrator make all necessary changes on your computers, network, and AutoClerk data; and you have taken the additional necessary steps such as formulating, maintaining and adhering to an inhouse security policy, you MUST sign and fax, mail or email back the signature page found at the end of this document. If you eamil, the address is: pabp@autoclerk.com. Please include the full property name, your name and position in the email.

The magnetic stripe on the back of a credit card contains sensitive data including the cardholder's name, Primary Account Number (PAN), expiration date and other information necessary to process the card for an authorization and/or sale. The card validation code or value is either 1) the 2 or 3 digit number embedded in the magnetic stripe or 2) the 3 or 4 digit number next to the signature field on the back of a card or on the front of an American Express card. A PIN (Personal Identification Number) is used when a debit card is used as a debit transaction rather than a credit card transaction.

Since December 2007, AutoClerk's credit card interface (Data capture) has been certified by Shift4 that we meet their specifications. Shift4 and its 'Dollars on the Net ^TM' is "a real-time payment gateway between merchants' point-of-sale systems and their bank/processor". By processing guests' credit cards through Shift4, the credit card number is kept by the AutoClerk PMS on your hardware as a truncated number with a token. (PCI DSS Req. 3.2 - 3.4) A token is a unique code which represents and points to the actual card number, which resides at Shift4.

Truncation is when a cardholder's PAN has been substantially replaced by X's. For example, XXXXXXXXXXXX4957 is a truncation format used when viewing and/or printing a guest folio receipt in AutoClerk; 5474XXXXXXXX4957 is a truncation format used by Shift4 for a hotel's internal reporting purposes; and 547463XXXXXX4957 is a truncation format used by AutoClerk for a hotel's internal reporting purposes, such as the Transaction Reports.

AutoClerk requires ALL properties that have the AutoClerk data capture interface use Shift4 as the property's payment gateway.

When a credit card is used within the AutoClerk client for an authorization or sale it is either swiped through a magnetic card reader or the number and expiration date are manually entered. It is then sent by the AutoClerk client to Shift4's Universal Transaction Gateway (UTG) which encrypts the number and transmits it to Shift4. Shift4 processes the card authorization and/or sale and returns the number in encrypted format to the UTG on your AutoClerk PMS server and then to the AutoClerk client as a truncated number and a token. The full magnetic stripe data is not kept on your hardware and the tokens that are returned by Shift4 are of no value to a thief.

If you have ANY questions regarding Shift4’s UTG, its security and/or compliance, you must contact your Shift4 representative directly.

When a credit card number is manually entered into the PMS for an authorization and/or sale, the staff has the ability to include the card's validation code or value as well as the billing address's zip code. If the card's code and/or value is entered, neither are retained anywhere within the AutoClerk PMS. (PCI DSS Req. 3.2.2) They are passed to Shift4 who uses them only to further validate the card. They are not returned to the PMS once an authorization or sale has been obtained.

A debit card's PIN and/or PIN block data is one of the most dangerous numbers to retain. The AutoClerk PMS does not support pin based debit transactions. AutoClerk's credit card interface does not allow for the processing of debit cards as anything other than a credit card therefore transmitting the PIN is not possible. (PCI DSS Req. 3.2.3)

When a reservation is entered in the PMS, a property typically requires a valid credit card number and expiration date to guarantee it. Once the reservation is saved, it is sent to the AutoClerk PMS' server program called AutoServe. AutoServe then encrypts the card information and sends it back to the AutoClerk client. Anyone looking at the reservation will only see a truncated credit card number and expiration date. AutoClerk's reservation form does not have a field to enter the Card Validation Code/Value and/or the PIN block data so any card validation codes/values and PIN block data are also not kept within the PMS. (PCI DSS Reqs. 3.2-3.4)

AutoClerk client versions prior to Version 7 could retain the PAN and expiration date in an untruncated format within the AutoClerk client as well as on backups. Beginning with AutoClerk client Version 8, the PMS truncates PANs and expiration dates on reports and also encrypts them on backups. (PCI DSS Reqs. 3.2-3.4) The PMS' backups are compressed using zip and are kept on the AutoClerk server computer; on zip disks; on other removable media; and/or sent off site.

The only cryptographic key material in earlier versions of the AutoClerk client was a built-in credit card encryption key in executables such as ac2g.exe, bw2.exe and resonweb.exe. Part of the AutoClerk conversion/upgrade process to Version 8 includes securely deleting all instances of the AutoClerk PMS client executables within the active data. This process securely deletes any cryptographic key material and/or cryptogram from previous versions in the active data.

You must implement Appendix A – Legacy Data Deletion to search for and then securely delete any legacy executables which may be on any of your system’s computers. This will securely delete the cryptographic keys. As with the other legacy data, once it has been securely deleted, you MUST scrub the unused space.

Existing properties may have legacy data on computers, removable media or paper. Legacy data includes, but is not limited to, neglected and/or forgotten AutoClerk backups and/or AutoClerk PMS data on computers that have been replaced; data copied to perform computer upgrades, or to set up additional stations; and data copied for system maintenance. All of this data is outside of the AutoClerk active data and poses a security risk if not found and securely deleted. The active AutoClerk data is automatically backed up and encrypted during each night audit.

You MUST investigate and locate all the computers where a guest's credit card information may still be within past backups and/or copied AutoClerk data. This may include, but is not limited to, employee laptops at their home, retired PCs, and/or computers that have been relocated at the property.

Once all the computers have been located, your network administrator MUST read and follow the steps in Appendix A to this Guide - Legacy Data Secure Deletion. The Appendix lists places within a computer where AutoClerk's PMS data may reside, where log files are held, and where/what other files need to be found and securely deleted. Once the deletion is complete, your network administrator must scrub the drives using a wipe tool. Eraser http://www.heidi.ie/eraser/ (free) and CyberScrub's Privacy Suite v.5.0 http://www.cyberscrub.com/ (cost) are two (2) products some of our clients have used.

Not completing these steps to securely delete all legacy data and cryptographic key material and then scrub the unused space makes the hotel NON-PCI DSS Compliant.

Legacy data also includes neglected and/or forgotten backups, and/or AutoClerk data on stored zip or other removable media. It is your responsibility to locate those media. Once found, they must be securely stored or destroyed per your property's data retention policy and security policy. (PCI DSS Reqs. 3.1, 9.10) "Store media back-ups in a secure location, preferably in an off-site facility, such as an alternate or backup site, or a commercial storage facility." (PCI DSS Req. 9.5) One way to destroy removable media such as zip disks is to reformat them and then scrub the magnetic surface. You can also physically destroy the media by drilling a hole through the magnetic surface and/or taking them apart to expose the magnetic disk which must then be cut with scissors.

It is your responsibility to research and locate ALL the places where a guest's full PAN may still be outside of residing on computers or other electronic media. It is considered legacy data and must be securely stored and/or destroyed. (PCI DSS Req. 9.10)

You MUST develop and maintain written policy and procedures for all your credit card data retention and disposal. (PCI DSS Req. 12) You must limit the retention and storage time to "that which is required for business, legal, and/or regulatory purposes". (PCI DSS Req. 3) Data storage MUST be kept to a minimum both in terms of duration as well as the physical amount. Those limitations must be part of your data retention and security policy.

Depending on your property's check in/guest registration policy, a credit card imprint may have been taken at check in or during the course of a guest's stay. This imprint may be on the registration slip or other form that was retained after the guest's stay. You may also have retained forms sent to the property with credit card information to guarantee and/or pay for a past guest's stay. In addition, you may have retained hard copies of reports such as past shift reports or night audits that may have untruncated PANs. All of these are legacy data.

Legacy and current hard copy data, if kept and stored for legitimate business purposes, must be in a safe and secure location. Access to this data must be strictly controlled and monitored. (PCI DSS Req. 9) An example would be once the guest has checked out; the paperwork is kept under lock and key on the property. In this example, you must also have a log for the access key, a procedure to monitor who has access to this stored data as well as how the data is handled. (PCI DSS Req. 7, 9 and 10)

As per your written security policy, all data containing credit card information, especially untruncated PANs, must be securely deleted and/or destroyed when the time limit has been reached. If the credit card data is in paper form such as an imprint on a registration slip, one way to destroy it is to cross cut shred it. (PCI DSS Req. 9.10) All electronic media must also be destroyed when it is no longer needed.

It is imperative that your written security procedures be maintained and updated as necessary. In addition, they must be part of new employee training and management changeovers. (PCI DSS Reqs. 12.1, 12.5, 12.6) It must include policies on who has access; logging and monitoring access; logging 'incidents'; as well as the proper wiping, deleting and/or destroying of the data.

There may be instances when you need to retrieve a guest's full credit card number and expiration date. Depending on the situation, you will get the card number and expiration date from either Shift4's 'Dollars on the net' ^TM website or from within the AutoClerk PMS.

The AutoClerk PMS has the ability to show an unencrypted credit card number only on an existing reservation and only to specific staff. View ability is based on user permissions which are set by property management through the PMS' ACAdmin program. All views of unencrypted credit cards numbers held in the PMS are logged by AutoServe. You must limit the number of staff who has access to this data. When setting up your users in AutoClerk and Shift4, only those employees with a 'need to know' should have access to read full card numbers, process refunds, etc. (PCI DSS Reqs. 7.1, 9)

Although you may need to access a guest's PAN and expiration date after checkout, it must only be accessed for the time it takes to complete your task. If it is necessary to write down the PAN, it must be securely deleted after use. Two easy ways to accomplish this are to use a dry erase board and/or if you have the credit card information in a paper form, crosscut shred the paper. Shift4 retains processed credit card information for 24 months. AutoClerk retains reservations with a guaranteed, hold, share-with, wait list, checked in/out, no show, and/or canceled status for two (2) months past the arrival date. During that time, an authorized staff member has the ability to go back and retrieve a guest's untruncated credit card information. Shift4's maintains its own access/view logs.

AutoClerk support staff or an integrator will only transfer required data for specific troubleshooting. The data is transferred to a known location with limited access. The backed up data being transferred is already in an encrypted format. In addition, the credit card numbers within the data are already truncated or encrypted. Once the data has been used, it is securely deleted.

AutoClerk's PMS' responsibility is to make sure that any PAN is masked when displayed, but can be displayed "to those employees and other parties with a specific need to see full PAN." (PABP Req. 2.1) The PAN is unreadable anywhere it is stored. The PMS stores credit card PANs using encryption or tokenization. By using Shift4's UTG in conjunction with AutoClerk's data capture when processing credit card authorizations and/or sales, the full credit card data is stored at Shift4. The reports and historical data produced and maintained by the PMS contain only the truncated credit card numbers and expiration dates. (PCI DSS Reqs. 2.1-2.2)

The AutoClerk PMS' encryption keys are in the registry on the server computer. They are protected by the Windows registry protection mechanism which, when properly set up, prevents access by any network user or any user of the same computer without the correct credentials. (PCI DSS Req. 2.4)

Encryption keys and log ins are controlled by property management. Each key has an expiry date which can be seen in the registry. A warning will appear in AutoClerk on the Night Audit report when a key is about to expire. When the credit card encryption key has expired, or on demand, an administrative user can invoke a program which will generate a new key, re-encrypt every cc number in the data set, and install the new key. This key must be changed at least once a year, or when any compormise of the key is suspected. (PCI DSS Req. 3.6) 

You must change the encryption key of your ResOnTheWeb interface at least once a year or when the possibility of a security compromise has occurred. The encryption key is used to protect cardholder data transmitted over the Internet.  AutoClerk's Night Audit will produce a report reminding you that your encryption key needs to be replaced for two weeks prior to the expiration. ResOnTheWeb interfaces are interfaces to all reservation systems web based or not with the exception of Best Western. Some examples of ResOnTheWeb are InnLink, Topaz, GenaRes, Synxis, Travelclick, Innpoints, ABVI ... etc.  When the encryption key is changed it must be changed on two sides:

1) Within the AutoClerk PMS

2) Your ResOnTheWeb Partner (InnLink, Topaz, Genares...etc). The changes must take place at the same time, or the interface will not work.  To properly change the encryption key of your ResOnTheWeb interface, you must do the follow:Contact AutoClerk Support.  The hotel's contact must be a Key Management person such as the General Manager on file in our support database, or someone who has been granted permission to act on the owner's behalf.You must generate a strong key.  You may use the utility provided by AutoClerk that will generate a 72-character random key or create your own. AutoClerk support will copy that key into our support database.  This key must be distributed to your ResOnTheWeb partner in a secure fashion.  One way to do this is to create a text file that contains the key and burn that text file onto a CD and nowhere else.  This CD needs to be mailed to the proper support contact at your ResOnTheWeb partner.  You must follow this up by calling and or emailing your ResOnTheWeb partner to let them know that you need to change your encryption key and once they receive the CD, they need to call to schedule the change to the encryption key.  Once you have a date and time set, you must contact AutoClerk so they may schedule a techncian or support person to help you make the changes.Once your ResOnTheWeb partner is ready to install the new encryption key on their side, you must call AutoClerk.  AutoClerk support will install your new encryption key on the AutoClerk PMS side.  Once the encryption key has been installed on both sides, you should make a test reservation via your ResOnTheWeb partner to verify that the interface is working properly.

At each shift change and on the Night Audit, the AutoClerk PMS performs a backup of data which contains encrypted credit card information. AutoClerk administrators must set up two (2)  separate strong keys for backup encryption. It is mandatory that two (2) people each enter and keep one key.  The administrators enter the keys manually, and store it per their security policy.  The backup keys should be changed yearly through the ACAdmin program. (PCI DSS Req. 3.6)  The keys will be needed if AutoClerk staff needs your data to troubleshoot a problem, or if you have a hardware failure and we need to restore your data from a backup.

It is your responsibility to 1) protect stored cardholder data (PCI DSS Req. 3); 2) restrict access to cardholder data (PCI DSS Reqs. 7 and 9); and 3) develop and maintain a strong information security policy for employees and contractors. (PCI DSS Req. 12)

Per AutoClerk's System Specifications (Appendix E) and a requirement for your PCI DSS compliance, every employee who has computer access must have a unique user name and password. (PCI DSS Reqs. 8.1, 8.2) Your network administrator must set up every network user with a unique user name and complex password for logging onto Windows on the computer(s) they will be using during their shift.

User names must always be unique and cannot be any vendor supplied default. (PCI DSS Req. 2.1) The users must NOT have Windows administrative rights. Any Windows user account with administrative rights MUST also have an additional account that is used day-to-day with non-administrative rights. All Administrative users are advised to not use the account or have the account disabled.

Windows passwords must be 'complex' in that they must contain at least 7 characters and include both letters and numbers. Passwords can be even more secure by including upper and lower case and/or symbols. (See Appendix E and PCI DSS Section 8.5 for additional Windows password requirements)

Any property with AutoClerk's data capture interface and Shift4 has another level of password protection and credit card security. Shift4 will train the hotelier on setting up their users with Shift4's 'Dollars on the Net™'. Shift4 users are set up with specific permission levels so only those employees that 'need to know' can see a full PAN and expiration date. (PCI DSS Req. 7) You must limit the number of people with full Shift4 rights, thereby limiting the number of people with access to full credit card data.

Every employee using the AutoClerk PMS must have a unique user name and password that is used when they log into an AutoClerk session. You cannot have duplicate user names or initials. Individual user permissions are based on groups within AutoClerk. AutoClerk passwords must be at least 7 characters and contain at least one number and one letter. In addition, they can contain at least one uppercase letter, one lowercase letter, and a special character (i.e. punctuation). The user name and password should follow at least the same rules as other users and passwords you have set up on your network and in Shift4. (PCI DSS Req. 8.5) Setting up a user's log in name and password should be done immediately upon their hire. Do NOT set up or use any default AutoClerk user accounts or passwords. (PCI DSS Req. 8.5.8) A manager must have two (2) user accounts in AutoClerk: one for everyday use and another to administer user names and passwords within AutoClerk's AC Admin program.

You must establish, maintain and follow a written password policy. All employees must be trained and kept current with your security policies. Procedures must be established to change all users' passwords, in both Windows and in AutoClerk on a regularly scheduled basis, at a minimum, every 90 days.

AutoClerk's users' passwords expire after 90 days and have to then be reset. They cannot use any of the past four (4) passwords. If an AutoClerk PMS user fails to log into a terminal 6 times, they will be locked out of that terminal for 30 minutes. Rebooting the terminal does not shorten the timeout of this feature. (PCI DSS Reqs. 8.5.8 -8.5.15) All AutoClerk PMS user passwords are encrypted. In addition, all log in attempts are logged by the PMS server. (PCI DSS 8.4)

When an employee leaves your employment, you must delete ALL their users in Windows, in the PMS and in Shift4 immediately. (PCI DSS Req. 8.5.4) Take any other steps necessary depending upon the access the ex-employee had, such as changing locks on storage areas for credit card data.

Your property's written security policy must include your rules regarding users, passwords and access to ALL credit card data whether it is on the active dataset; within Shift4; on removable backup media; and/or paper.

AutoClerk advises all its customers and resellers/integrators to apply these password guidelines to ALL systems, PCs, servers and databases that contain payment applications and/or cardholder data.

The AutoClerk PMS automatically creates a log of transactions done within AutoClerk. The log includes the logged in user's initials, shift, time, transaction number for the day, and computer station number for each transaction. These are part of the Standard Transaction Report that can be printed at any time. By default, all the detail is also part of the Night Audit Zout Report which can be reprinted at any time. (PCI DSS Req. 10.1 - 10.3)

AutoClerk's PMS server application logs those events that affect security including each time a staff member logs into AutoClerk, successful or not; when an employee views an untruncated credit card PAN and expiration date; as well as actions taken by an AutoClerk PMS administrator. These logs cannot be disabled. These logs are accessible only to someone logged onto a terminal as a Windows administrator.

Shift4 maintains its own logs of which users who have signed into a property's account so a manager can see who has accessed the account and potentially guest records. Depending on how a property has set up their Shift4 account, the manager, accountant or other designated person can also receive email alerts/notifications when settlements are processed, when there is unusual and/or excess activity on a card or other levels of notification.

Windows keeps its own separate logs. When setting up your computer network, your network administrator must enable the Windows logging function. Your network administrator must also familiarize you with these logs: where they are kept, how to maintain them, and how to read them, etc.

This section of the PABP Requirements applies to AutoClerk, Inc. and how we write, develop, test and implement our software application. It is important you are made aware of how the PMS is developed, tested, released and implemented to aide you in complying with PCI DSS Req. 6.

All upgrades to the AutoClerk PMS client, server and/or interface applications are tested in house by our QA department per their test plans prior to being released to our clients as either a beta or a production version. (PCI DSS Req. 6.4) If necessary, 'test only' credit cards, issued by merchants such as First Data, are used during testing. No 'live' credit card numbers are used.

Before a new property is put online with AutoClerk, a dataset is created from an Installation Form filled out by the property as part of their online process. We start with blank data and build their dataset based on the information provided on the Installation Form. No test or individual guest credit card information is used when creating the property's dataset.

Development, testing and production are separate departments at AutoClerk. Any new code comes from development to QA. QA oversees the testing of the new code. Once satisfied, QA then passes it to the production/tech department for implementation into the field. (PCI DSS Req. 6.3) The code that is passed from QA to tech to be implemented in the field is an executable file. No test data is given to tech.

When the new version is implemented at properties, the General Manager is advised they can go to http://www.myautoclerk.com for the version release notes. They can also find any documentation on new features as well as training videos.

Wireless connections to the AutoClerk network segment must NEVER be used as stated in Data Security Letter #2 of October 12, 2006; Data Security Letter #3 of February 2, 2007; as well as our specs.

If ANY non-AutoClerk workstations are wirelessly connecting to your network, they MUST be configured to meet or exceed the following specifications: encrypt the transmissions by using WiFi Protected Access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS; and never rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN.

·        Use with a minimum 104-bit encryption key and 24 bit-initialization value.

·        Use ONLY in conjunction with WiFi Protected Access (WPA or WPA2) technology, VPN, or SSL/TLS.

·        Rotate shared WEP keys quarterly (or automatically if the technology permits)

·        Rotate shared WEP keys whenever there are changes in personnel with access to keys.

·        Restrict access based on media access code (MAC) address.

Your network administrator must verify that the wireless technology has been protected with personal firewall software. The firewall software secure configuration must not be alterable by the employee. All vendor defaults, including keys, must be changed at installation and whenever the person knowing the key leaves or changes positions; SSID broadcast is disabled; default SNMP community strings are changed; all access point passwords are changed; enable WPA or WPA2 if possible.

This section of the PABP refers to AutoClerk's internal processes to keep up to date on potential security risks to the AutoClerk program and credit card data.

We subscribe to several Internet alert services, including the SANS Institute, Microsoft, BZ Media (Software Test & Performance), Tech Republic and ComputerWorld. (PCI DSS Req. 6.2)

If any possible threats are found to the AutoClerk application, they are investigated, patched, tested and deployed to our customers in a 'timely' manner. All updates are delivered securely via two-factor authentication and through our internal 'chain-of-trust'.

It is your responsibility to do the same for your network including having your network administrator run regular network scans to check for any intrusions and/or unauthorized access attempts. (PCI DSS Req. 11)

Per AutoClerk's Specs, you must have certain security tools in place. These tools include, but are not limited to, an external hardware firewall, anti-virus software and traffic filtering devices.

Updates to these entities such as your Windows operating system, anti-virus program, etc. need to be managed, monitored and installed. (PCI Reqs. 5.2, 11.4) Be sure your network administrator installs these tools and trains management and staff on their use, management and maintenance.

Having these security tools implemented on your network computers does NOT interfere with the AutoClerk PMS server, client or interface applications when they are properly configured. (PCI DSS Reqs. 1, 3, 4 and 5)

Credit card data processing is sent by Shift4 in an encrypted format to their data center where it is processed and then returned to AutoClerk as a token, which includes the truncated credit card number.

The AutoClerk installation must NEVER be put on a server and/or computer that is directly facing the outside public Internet.

AutoClerk's Specs require that the computer running AutoClerk's AutoServe program must have high speed Internet access. "It must be persistent and static and must be accessible via public (not private) address. Examples of such broadband services would be: DSL, T1, or Cable Modem". AutoClerk does not access properties via a dial-up modem.

Because the server has a static and persistent IP it must be secured behind your hardware firewall per AutoClerk's specs. (PCI DSS Reqs. 1.3.9 and 12.3.9) Proper configuration of the firewall will allow access only to those approved vendors/persons/entities. Any Regional stations must also have at a minimum a personal software firewall installed and properly configured in a secure manner.

When AutoClerk support staff access your system to install updates to the AutoClerk PMS, we access the property using Bomgar and two-factor authentication. The two-factors are an encrypted hardware solution (Bomgar) as well the remote user initiating the connection. The Bomgar solution will not interfere with RADIUS, TACACS, or Corporate VPNs. All remote access is recorded and archived.

Per PCI DSS Req. 8.3, two-factor authentication must be used whenever ANYONE accesses your network remotely. Two-factor authentication requires users to produce two credentials to access a system. Credentials consist of something the user has in their possession (for example, smartcards or hardware tokens) and something they know for example, a password). To access a system, the user must produce both factors.

For all remote access, you MUST use and implement remote access software security features such as requiring a unique user name; authenticating all users; changing all default settings; enabling lockouts; enabling data encryption; enabling logging; allowing connections only from specific (known) IP/MAC addresses; and establishing customer passwords according to the PCI DSS requirements. (PCI DSS Reqs. 8.1, 8.2, 8.4, 8.5)

PCI compliant use of all remote stations must be part of your property's security policy. (PCI DSS Req. 12.3)

Neither the AutoClerk server nor the AutoClerk client programs interfere with outside entities using two-factor authentication to access your network.

AutoClerk support staff use two-factor authentication whenever we need to gain access to a hotel's network. All remote access by AutoClerk support is facilitated by known secure hardware solutions by trusted providers such as Bomgar, RSA Labs, etc.

AutoClerk support sessions are facilitated by a security appliance called the BOMGAR BOX.  This appliance is owned, administered and hosted by AutoClerk.  Our appliance is integrated with AutoClerk's Radius server and can only be used by AutoClerk employees with a current, valid RSA token code.  This code changes every 60 seconds. Each employee is issued their own RSA security token.

Support sessions to our hotel customers can be conducted in the following ways:
1-  Customers can initiate an AutoClerk support session by visiting "esupport.autoclerk.com" from a browser on the station they are working at, and entering a 7 digit pin code our support agent will give them over the phone. That pin is only good for that support session.
2-  An AutoClerk support agent may email a link to the customer.
3-  The link may be accessible via other locations.
4-  The client software may be permanently installed on hotel computers, such as dedicated server computers, or others. 

AutoClerk relies on Shift4's UTG to securely transmit payment card data over open/public networks.

The PMS has the ability to send guests a reservation confirmation via email. However, even if the email confirmation letter is formatted to send the credit card number used to guarantee the reservation, it is pulling the truncated PAN. The truncate PAN is restricted to the last four digits of the account.

You must NEVER include any full payment card information in an unencrypted email. (PCI DSS Reqs. 3, 4.2) If you must send account information via email, use an encryption solution such as PGP.

Not sending unencrypted PANs via email must be part of your property's security policy and procedures. (PCI DSS Req. 12.2)

In order for all non-console administrative access to be encrypted, you MUST use technologies such as SSH, VPN or SSL/TLS. (PCI DSS Req. 2.3) If you have AutoClerk Regional Stations, they MUST use Terminal Services. (See Appendix E for AutoClerk's specs on Terminal Services)

By default, Windows Server 2003 Terminal Services uses ‘high’ level of encryption, which encrypts data transmission in both directions using a 128-bit key. Your network administrator should use this default level.

AutoClerk's website for our customers is http://myautoclerk.com . It contains the following: Data Security Letters sent out 7/26/06, 10/12/06 and 2/2/07; AutoClerk's System Specifications; a link to our interactive training videos; training documentation our clients can view or print; and the Release Notes (under the 'What's New' tab) that we provide for each version and/or update. Customers can also click on 'Help' at the top of the PMS's main menu and get access to documentation.

Prior to installation or upgrade, a copy of this Guide will be provided to the property. A signature page is also provided to verify receipt and understanding which will need to be returned to AutoClerk, Inc.

This Implementation Guide can also be found at http://www.myautoclerk.com . It will be reviewed and updated at least on a yearly basis, even if any new AutoClerk versions/updates do not require it.

Version 1.2 (August 18, 2008)

Signature Page

Once you have read through the attached Implementation Guide, please fill out the information below and fax back to AutoClerk at (925) 284-3423, Attn: Gary Gibb

You may also save it and email it as an attachment to pabp@autoclerk.com.

By this signature, I state that I have read and understand the attached Implementation Guide and all its appendixes produced by AutoClerk, Inc. I understand that this signature page will be kept as part of my Client file by AutoClerk, Inc.

___________________________________________________________________________
Property Name                                                                                                       (Phone)

___________________________________________________________________________
Property's Owner (Signature)                                                                                 (Date)

___________________________________________________________________________
Property's Owner (Print)                                                                              (Email Address)

___________________________________________________________________________
Property's General Manager (Signature)                                                           (Date)

___________________________________________________________________________
Property's General Manager (Print)                                                           (Email Address)

___________________________________________________________________________
Property's Network/Hardware Administrator - Company Name

___________________________________________________________________________
Network/Hardware Administrator Contact                                                            (Phone)