SKIDATA Sales Documentation Package V10...30.05.2014 06.00 DAGE Several Changes for the release 08 validation 10.06.2014 06.01 DAGE Changes in section 7.2 12.11.2014 06.02 DAGE Review

SKIDATA Sales Documentation Package V10

Thank you for your interest in purchasing a SKIDATA Parking System. The following package contains a PCI-DSS Secure Implementation Guide.March 2017

PURCHASER ACKNOWLEDGMENT FORM V1.1

PLEASE RETURN THE COMPLETED ACKNOWLEDGMENT FORM TO ___________________, ATTN: ____________________, AS FOLLOWS:

Via Facsimile: ______________; or Via Email: ______@_________

SKIDATA WILL NOT PROCESS AN ORDER, NOR PROVIDE AN ACCESS CODE FOR ANY SERVICE OR PRODUCT FOR WHICH IT HAS NOT YET RECEIVED A SIGNED PURCHASER ACKNOWLEDGEMENT FORM.

__________ (“Purchaser”) hereby acknowledges its receipt of the following documents:

SKIDATA PCI DSS/PA DSS Secure Implementation Guide, version _____

SKIDATA AG’s Software License, version ________

Those documents checked off are collectively referred to hereinafter as the “Acknowledged Documents.”

Purchaser further acknowledges having had the opportunity to fully review the acknowledged documents and having asked any questions desired and clarified the meaning of all terms, instructions and other information contained within the acknowledged documents, and agrees to comply and consents to be bound to the terms of each. WITHOUT LIMITATION, PURCHASER FURTHER COVENANTS AND AGREES THAT IT WILL

FULLY AND STRICTLY COMPLY WITH THE ACKNOWLEDGED DOCUMENTS AND WITH ALL

REGULATIONS AND PROTOCOLS OUTLINED IN THE ACKNOWLEDGED DOCUMENTS, AS THEY

MAY BE AMENDED BY SKIDATA FROM TIME TO TIME.

Purchaser further makes the material representation upon which it intends others to reasonable rely that the person signing below on behalf of an entity has all requisite power and authority to bind the entity to the terms and conditions set forth herein.

Purchaser:

Company: _________________________________ Name: _________________________________ Title: _________________________________ Address: _________________________________ County: _________________________________ State: _________________________________ Date: _________________________________

Signature _________________________________

__________ Facility

siaa

Typewritten Text

908-243-0660

siaa

Typewritten Text

CHAX

siaa

Typewritten Text

siaa

Typewritten Text

SKIDATA.COM

siaa

Typewritten Text

siaa

Typewritten Text

V10 (08.04) Dated 12-12-16

siaa

Typewritten Text

1.3 Dated 2013

SKIDATA V10.00.xx PCI DSS / PA DSS Secure Implementation Guide Covering PCI v3.2 and PA DSS v3.2 requirements Author: Gerhard Daxer Version: 08.04 12.12.2016

PCI/PA DSS Secure Implementation Guide

© 2016 SKIDATA AG, PCI PA DSS Secure Implementation Guide v08.04 Page 2 of 68

SKIDATA AG Untersbergstraße 40 A-5083 Grödig/Salzburg Telefon: +43 6246 888-0 Telefax: +43 6246 888-7 Internet: http://www.skidata.com E-Mail: [email protected]

Copyright © 2016 by SKIDATA AG. All rights reserved. All information in the following document is protected by copyright law. No part of this document may be reproduced without the written consent of SKIDATA AG. SKIDATA AG reserves the right to make any changes of specification and other information in this document without further notice.

Note Great care was taken to make the information contained in this documentation as correct and accurate as possible. Although the documentation is updated regularly, SKIDATA AG cannot guarantee absolute correctness and completeness of the information contained therein.

Trademarks This documentation may contain representations of registered product or service trademarks owned by SKIDATA AG or third parties, as well as references to proprietary know-how protected by copyright laws or other legal provisions. In any case all rights remain exclusively with their respective owners. SKIDATA® is a registered trademark of SKIDATA AG in the USA, the European Union and other countries.

http://www.skidata.com/

mailto:[email protected]



Version History

Date Version Changed by Description of Changes

04.11.2010 03.00 DAGE Changes in chapters: 4.3, 4.5, 4.7

13.01.2011 03.01 DAGE Changes in chapters: 3, 4.2.5, 4.2.6, 4.3.2, 4.3.3, 4.5.2, 4.7.1,

4.7.1.2, 4.7.1.3, 4.7.1.4, 4.7.1.5, 4.7.1.6, 4.7.1.7, 4.9.1,

4.11.1, 4.12.1,

31.01.2011 03.02 DAGE Changes in chapter: 3.0, 4.2.2,

03.02.2011 03.03 DAGE Changes in chapters: 3.0, 4.4.2 during validation; added

section 6 and 7

04.02.2011 03.04 DAGE Changes in section 4.5.2

23.02.2011 03.05 DAGE Changes in sections: 3.0, 4.1.1.1

20.10.2011 04.04 DAGE Several Changes for the release 06 validation

24.10.2011 04.05 DAGE Changes in sections: 4.0


21.10.2013 05.01 DAGE Changes in section 8.2

06.11.2013 05.02 DAGE Changes in sections: 5.1.1.5, 5.2.5, 5.11.3

14.11.2013 05.03 DAGE Several Changes during release 07 validation

15.11.2013 05.04 DAGE Several Changes during release 07 validation



10.06.2014 06.01 DAGE Changes in section 7.2

12.11.2014 06.02 DAGE Review and extensions in section 2.10


11.06.2015 07.00 DAGE General: added SRV2012/SQL2012, removed SSL, added

TLS; Changes in: 3, 5.3.1, 5.8.1, 5.9, 5.10.1, 5.12.1, 5.13.1, 8

18.06.2015 07.01 DAGE Changes in section 4.2, 5.2.1, 5.11.2.2

29.06.2015 07.02 DAGE Changes in: 5.9

06.09.2016 08.01 DAGE Review and extensions for PA DSS 3.2 and V10

20.09.2016 08.02 DAGE Minor changes in section 5.6

28.09.2016 08.03 DAGE Minor changes

12.12.2016 08.04 DAGE Minor changes



1. Table of Contents 1. Table of Contents ....................................................................................................... 4 2. Payment Systems Security ........................................................................................ 6 2.1 Introduction ................................................................................................................ 6 2.2 Visa CISP History ....................................................................................................... 6 2.3 The PCI Industry Standard ......................................................................................... 6 2.4 Payment Application Best Practices / PABP ............................................................... 6 2.5 Change to the PCI Security Standard Council / PA DSS............................................. 6 2.6 Card associations ....................................................................................................... 7 2.7 Acquirers .................................................................................................................... 7 2.8 Merchants .................................................................................................................. 7 2.9 Merchant Applications ................................................................................................ 7 2.10 Difference between PCI Compliance and PA-DSS Validation ..................................... 8 3. About this Document.................................................................................................. 9 4. How to start ................................................................................................................. 9 4.1 Activate the Software Module “PCI/PA-DSS” (Program Settings/ Software Module)... 9 4.2 Complete the Password Change Wizard .................................................................. 10 4.3 Additional Information ............................................................................................... 11

5. SKIDATA Security Validation ................................................................................... 14 5.1 PA DSS reference 1.0 - Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data ..................................................................... 14 5.2 PA DSS reference 2.0 - Protect stored cardholder data ............................................ 18 5.3 PA DSS reference 3.0 - Provide secure authentication features ............................... 26 5.4 PA DSS reference 4.0 - Log payment application activity ......................................... 32 5.5 PA DSS reference 5 - Develop secure payment applications.................................... 35 5.6 PA DSS reference 6.1 - Protect wireless transmissions ............................................ 35 5.7 PA DSS reference 7.0 - Test payment applications to address vulnerabilities and maintain payment application updates ................................................................................. 38 5.8 PA DSS reference 8.0 - Facilitate secure network implementation ........................... 40 5.9 PA DSS reference 8.2 - The payment application must only ..................................... 44 5.10 PA DSS reference 9.0 - Cardholder data must never be stored ................................ 46 5.11 PA DSS reference 10.0 - Facilitate secure remote access to payment application ... 47 5.12 PA DSS reference 11.0 - Encrypt sensitive traffic over public networks .................... 50 5.13 PA DSS reference 12.0 - Secure all non-console administrative access. .................. 51 5.14 PA DSS reference 13 - Maintain a PA-DSS Implementation Guide for customers, resellers, and integrators ..................................................................................................... 53 6. Documentation and Training ................................................................................... 54 6.1 Documentation ......................................................................................................... 54 6.2 Training .................................................................................................................... 54 7. Typical SKIDATA parking system and CDE configuration .................................... 54 7.1 Seldom used Parking System Configurations ........................................................... 55 7.2 Operating Systems and Database Systems supported ............................................. 57 7.3 Network Segmentation ............................................................................................. 57

8. Credit Card Clearing Methods – Data flow diagrams ............................................. 58 8.1 Real Time Authorization using Credit Card Authorization Server .............................. 58 8.2 Real Time Authorization with Credit Card Tokenization ............................................ 60 8.3 Offline (Batch) Transaction using Encrypted Text File .............................................. 63



8.4 Real Time Authorization using External Terminals .................................................... 65 9. Maintain an Information Security Program ............................................................. 67 10. References, Acknowledgments, License ................................................................ 67 10.1 References ............................................................................................................... 67 10.2 Acknowledgments .................................................................................................... 67

11. Appendix A – Sample Authorized Key Custodian Form ........................................ 68



2. Payment Systems Security

2.1 Introduction The landscape of merchants’ electronic payment systems has changed radically over the past ten years. What were once mostly proprietary (closed loop) systems has become a network of computers connecting to multiple partners and services (ASP’s) via the public Internet. In the past five years alone, Internet and computing technologies have grown at such a rate that many corporations today must provide substantial resources (policy and human-power) devoted solely to systems security. Keeping information such as customer and market data confidential has rapidly become one of the highest corporate priorities. In April 2000, Visa began a proactive approach to payment security by announcing the Cardholder Information Security Program (CISP) as a standard for securing Visa cardholder data. Effective since June 2001, CISP compliance has been required for all entities that store, process or transmit Visa cardholder data. Today the program has been embraced and expanded upon by other card associations and a new PCI standard defined to ensure multiple association compliance. This document is designed to provide customers with instructions, notes and pointers on how to implement a PCI/PA-DSS compliant system.

This document is based on Security Standard Council documents PCI DSS version 3.2 and PA DSS version 3.2.

2.2 Visa CISP History When customers offer their bankcard at the point of sale, over the Internet, on the phone, or through the mail, they want assurance that their account information is safe. That is why Visa USA has instituted the Cardholder Information Security Program (CISP). Mandated since June 2001, the program is intended to protect Visa cardholder data wherever it resides ensuring that members, merchants and service providers maintain the highest information security standard.

2.3 The PCI Industry Standard To achieve compliance with PCI/PA-DSS, merchants and service providers must adhere to the Payment Card Industry (PCI) Data Security Standard, which offers a single approach to safeguarding sensitive data for all card brands. This Standard is a result of collaboration between Visa and MasterCard and is designed to create common industry security requirements, incorporating the CISP requirements. Other card companies operating in the U.S. have also endorsed the PCI Data Security Standard within their respective programs.

2.4 Payment Application Best Practices / PABP Developed by Visa, the Payment Application Best Practices is a set of requirements and guidelines designed to address security and the risks associated when full magnetic stripe data or CVV2 values are stored after authorization by payment applications. The Best Practices assist software vendors in creating secure payment applications that help ensure merchant PCI compliance.

2.5 Change to the PCI Security Standard Council / PA DSS The Security Standard Council was founded by the main card issuing companies and has taken over the responsibility for all PCI related belongings. All PCI certifications are issued solely by this organization from now on. Certified applications are listed on the Security



Standard Council website from now on. The PA DSS – Payment Application Data Security Standard replacing the former PABP standard for payment application certification from now on.

https://www.pcisecuritystandards.org/

2.6 Card associations These are the actual associations like Visa and MasterCard who define and ultimately enforce the rules. As quoted from Visa's website: “The Visa USA Operating Regulations govern the activities of member financial institutions and, by extension, merchants and service providers as participants in the Visa payment system. The simplified requirements (located at http://www.visa.com/cisp/) should help clarify the intent of the more formal regulations“.

2.7 Acquirers These are the merchant Acquiring banks that underwrite merchant accounts onto the respective payment networks. This is either done in-house or via a network of Merchant Service Providers who act as agents/members for the Acquiring bank. As quoted from Visa's website: “Members are responsible for ensuring the PCI compliance of their merchants, service providers, and their merchants' service providers. Although there may not be a direct contractual relationship between merchant service providers and acquiring members, all members remain responsible for any liability that may occur as a result of PCI non- compliance. Acquirers must include a PCI compliance provision in all contracts with merchants and non-member agents.”

2.8 Merchants The end company receiving payment for goods and/or services. While the Acquirer or Merchant service provider should have explained (and be actively working you through) PCI/PA-DSS, it is ultimately the Merchant's responsibility for verification and compliance.

2.9 Merchant Applications As defined in the Visa PABP, Software vendors are the developers of applications specifically for credit card transactions. Examples are point-of-sale (POS) and shopping cart products.

Notes on fines: As quoted from Visa's website “If a merchant or service provider does not comply with the security requirements or fails to rectify a security issue, Visa may:

• Fine the acquiring member • Impose restrictions on the merchant or its agent • Permanently prohibit the merchant or its agent from participating in Visa programs

Members receive protection from fines for merchants or service providers that have been compromised but found to be PCI-compliant at the time of the security breach. Members are subject to fines up to $500,000 per incident for any merchant or service provider that is compromised and not PCI-compliant at the time of the incident.”

https://www.pcisecuritystandards.org/

http://www.visa.com/cisp/)



2.10 Difference between PCI Compliance and PA-DSS Validation As a software vendor, our responsibility is to be “PA-DSS Validated.” We have performed an assessment and certification compliance review with our independent assessment firm, to ensure that our platform does conform to industry best practices when handling, managing and storing payment related information. PA-DSS is the standard against which Payment Application has been tested, assessed, and validated. PCI Compliance is then later obtained by the merchant, and is an assessment of your actual server (or hosting) environment. Obtaining “PCI Compliance” is the responsibility of the merchant and your hosting provider, working together, using PCI compliant server architecture with proper hardware & software configurations and access control procedures. The PA-DSS Validation is intended to ensure that the Payment Application will help you achieve and maintain PCI Compliance with respect to how Payment Application handles user accounts, passwords, encryption, and other payment data related information.

The Payment Card Industry (PCI) has developed security standards for handling cardholder 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 cardholder 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 cardholder data is stored, processed or transmitted.

Important notes regarding the communication of PCI compliancy

“Acceptance and/or listing of a given product by the PCI Security Standards Council, LLC (PCI SSC) only applies to the specific version of that product that was reviewed by an assessor or test laboratory qualified by PCI SSC (Assessor) and subsequently accepted and listed by PCI SSC (the “Accepted Version”), and only while such acceptance and listing are in effect. If any aspect of a product or version thereof is different from that which was reviewed by the applicable Assessor and accepted and listed by PCI SSC – even if the different product or version (the “Alternate Version”) conforms to the basic product description of the Accepted Version – then the Alternate Version should not be considered accepted by PCI SSC, nor promoted as such. The authoritative lists of products currently accepted by PCI SSC can be found on the PCI SSC website at www.pcisecuritystandards.org. Please notify PCI SSC if you believe that any product purportedly accepted by PCI SSC does not appear on these lists. No vendor or other third party may refer to a product as “PCI Approved” or “PCI SSC Approved”, and no vendor or other third party may otherwise state or imply that PCI SSC has, in whole or part, accepted or approved any aspect of a vendor or its services or products, except to the extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or in a corresponding letter of acceptance provided by PCI SSC. All other references to PCI SSC’s approval or acceptance of a product or version thereof are strictly and actively prohibited by PCI SSC, should be reported to PCI SSC, and constitute a breach of applicable PCI SSC program requirements.

When granted, PCI SSC acceptance is provided to signify the Assessor’s determination that the product has demonstrated achievement of certain security and operational characteristics important to the security of payment card data, but such acceptance does not under any circumstances include or imply any endorsement or warranty by PCI SSC regarding the product vendor, the product, or the functionality,

http://www.pcisecuritystandards.org/



quality, or performance of the product or any other product or service. PCI SSC does not warrant any products or services provided by third parties. PCI SSC acceptance does not, under any circumstances, include or imply any product warranties from PCI SSC, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement, all of which are expressly disclaimed by PCI SSC. To the extent any rights or remedies regarding products or services that have received acceptance from PCI SSC are provided, those rights and remedies shall be provided by the party providing such products or services, and not by PCI SSC or any of its payment brand members.”

3. About this Document This document describes the steps that must be followed in order for your SKIDATA installations to comply with Payment Application – Data Security Standards (PA-DSS). The information in this document is based on PCI Security Standards Council Payment Application Data Security Standards program (version 3.2 dated May, 2016). SKIDATA or its partner organizations are instructing and advising their customers to deploy SKIDATA applications in a manner that adheres to the PCI Data Security Standard (3.2). Subsequent to this, best practices and hardening methods, such as those referenced by the Center for Internet Security (CIS) and their various “Benchmarks”, should be followed in order to enhance system logging, reduce the chance of intrusion and increase the ability to detect intrusion, as well as other general recommendations to secure networking environments. Such methods include, but are not limited to, enabling operating system auditing subsystems, system logging of individual servers to a centralized logging server, the disabling of infrequently-used or frequently vulnerable networking protocols and the implementation of certificate-based protocols for access to servers by users and vendors.

If you do not follow the steps outlined here, your SKIDATA installation will not be PA-DSS compliant and therefore PCI compliancy is not possible!

4. How to start The initial setup of the SKIDATA Parking System software is always performed by a SKIDATA technician (or an authorized technician from a partner company). If demanded by the customer the system will be pre-configured correctly to support the PCI compliancy of the customer.

The following basic configuration tasks have to be performed before start of normal operation to maintain a PCI/PA-DSS compliant SKIDATA parking system.

4.1 Activate the Software Module “PCI/PA-DSS” (Program Settings/

Software Module) The software module can be activated immediately after new installation within the initial run of the automatic configuration program or at any time within the program Settings/Software Module.

The activation of the software module PCI/PA-DSS will automatically activate or configure the following settings:

• Possibility of encryption key change • Minimum password length of 7 digits • Maximum password length of 25 digits



• Minimum password age 1 day • Password different setting 2 (number of characters) • Alphanumeric passwords • Mixed alphanumeric/numeric passwords • Automatic forced password change at least every 90 days • Reuse of last 4 passwords used not possible • Maximum number of login attempts to 3 • Blocking time after false login 60 minutes • Automatic lock of workstation after 15 minutes • Rendering of credit card numbers except last 4 digits within applications • Rendering of credit card numbers except last 4 digits on receipts • Software Module “Change Logging” is activated and pre-configured automatically

4.2 Complete the Password Change Wizard The password change wizard will be started automatically by the system in the following situations:

Automatically after first log-on (of Administrator only, as there is no other application

user at this point) if PCI/PA DSS had been activated within the initial run of the automatic configuration program.

Automatically after activation of the PCI/PA DSS software module.

Note: The wizard can also be started manually (passwords only) within the program Settings/Parking Facility if all passwords need to be changed for any reason (e.g. PCI requires that passwords are changed before 90 days).

Execution will only be done and possible if user has either service or administrative privileges.

Detailed description of wizard functionality:

• Step 1 – Check if all devices are online - if devices are offline the wizard will be

suspended until all devices are online if started automatically and closed if started manually.

• Step 2 - Change of the “Credit Card Data Encryption Key” and the “Credit Card Key

Password”. The key change tool will be executed as always on top. Program cannot be closed till key change has been performed.

Waiting for step 3 - Application waits until all devices are back online.

Step 3 - Guided change of passwords for: Database system administrator (sa),

Database administrator (Administrator), Application database user (Parkuser), Data exchange user (parkexchange), Online database access user (online), Column User

Waiting for step 4 - Application waits until synchronization of passwords has been finished.



Step 4 - Change of operating system passwords for domain administrator (Administrator) and application domain user (Parkuser). Program cannot be closed till password change has been performed.

Database user/pw configuration in case of paged-out database: Database user and passwords have to be configured at the paged out SQL Server manually before start of the parking system password configuration wizard.

Note: The Admin-User will be automatically prompted to change the default application user password during the first login procedure.

Passwords for database user or encryption key can only be changed if all parking system devices are online.

Once passwords for database users or encryption key passwords are changed, there is a 60 minutes blocking timeout which gets active to prevent faulty or undesired changes.

SKIDATA strictly recommends that all passwords and the credit card identity value are stored by the customer in a secure manner. This is required by PCI DSS regulations.

SKIDATA strictly recommends also that you should not use the same passwords for the different existing accounts.

4.3 Additional Information Change of credit card configuration If any credit card configuration is changed or extended after activation of the PCI/PA-DSS software module the rendering configuration for credit card receipts has to be configured manually in a PCI compliant manner (last 4 digits). This is not performed automatically.

Activation of the PCI/PA-DSS software module SKIDATA advices service technicians to activate the PCI/PA-DSS software module immediately after system setup. With the first startup of the automatic configuration program the software module can be activated within this program. If the activation has not been performed the application will inform the user automatically before leaving the program. The service technician can then accept having a non-PCI conform system or return to the program for software module activation.

Application information about non-compliancy: As long as the PCI/PA-DSS software module has not been configured corresponding non- compliancy information will be displayed within the program information dialog of all parking system programs.

Information about certified credit card clearing methods: There are four different methods for credit card clearing within the parking system application:

- Online Authorization via Authorization server protocol The credit card transaction is authorized online. No magnetic stripe data are stored within the system at all. Magnetic stripe data are sent by the application to the real time credit card



integrations for authorization. In the event the processor is not reachable no authorization is possible. Also in this case no magnetic stripe data are stored.

- Online Authorization via Authorization server protocol and Credit Card Token The credit card transaction is authorized online. No magnetic stripe data and no PAN are stored within the system at all. Magnetic stripe data are sent by the application to the real time credit card integrations for authorization. The central credit card authorization server (processor) returns a credit card token (reference number) back to the parking system. This token is stored within the parking system database. No credit card PAN is stored within the parking system database at all. In the event the processor is not reachable no authorization is possible.

- Online Authorization via External Terminal hardware (Chip&Pin Solutions) The credit card transaction is authorized online by the terminal itself. There are no magnetic stripe data delivered from the terminal to the application in this case. In the event the processor is not reachable the transaction is declined. The usage of PED/PTS compliant terminal hardware is mandatory.

If payment authorization has been succeeded the payment transaction including PAN is stored by the parking system securely within the database.

- Offline Authorization via encrypted batch-files As offline batch clearing is still common in European countries this possibility cannot been discarded by the parking system within a short time frame. If offline clearing is configured within the parking system the whole clearing file is encrypted before authorization. The encrypted file contains PAN and sometimes also magnetic stripe data as this is still needed with some clearing formats in some countries (only pre-authorization).

Encryption will take place in memory so no temporary unencrypted data are generated. After clearing (either by use of secure file transfer or data carrier) the files will be deleted irretrievable by the system immediately. The encryption method can be configured within the system (symmetric or asymmetric methods and key management).

If choosing this clearing method PCI requires to treat the relevant encryption keys securely and to change them in a PCI compliant manner.

Country specific Interface Implementations: Interface Implementations are generally not covered by the PA DSS validation of the SKIDATA Parking System as they have not been part of the onsite PA DSS assessment. While these interface implementations may not qualify as full "Payment Applications", they are in scope of the customers’ cardholder data environment and thus they are part of the customers’ PCI responsibility.

That means interface implementations have to be part of the customers PCI site assessment. This is valid for every parking system interface and of course also for the Electronic Payment Interface (EPI).

Virus Scanner and Firewalls Operating System built-in Firewall The built in firewalls of the parking system devices and servers are configured and activated by default. All personnel of SKIDATA or partner organizations are advised that deactivation



of firewalls is strictly forbidden except in case of troubleshooting. The deactivation of built-in firewalls will result in a NON-PCI compliant parking system!

Virus Scanners Virus scanning programs are mandatory for PCI compliance. Please contact technical support to get more information about the actual virus scanning software SKIDATA recommends. The virus scanning engines on parking system devices and servers have to be configured and activated. All personnel of SKIDATA or partner organizations are advised that deactivation of virus scanners is strictly forbidden except in case of troubleshooting. The deactivation of virus scanners will result in a NON-PCI compliant parking system!

Virtualization (VMware etc.) The usage of VMware or any other virtualization technology is not subject of the SKIDATA Parking.Logic application. If customers decide to use virtualization then this part is in the sole responsibility of the customer. Virtualization solutions such as VMware are NOT validated in the course of the Parking.Logic PA DSS validation. These kinds of solutions have to be validated separately in the course of the customers PCI site compliancy examinations.

Hard Drive Image Backup's and Shadow Copies (SRV2008/SRV2012) SKIDATA does not support these functionalities within the standard deliverable. If customers device to use hard drive imaging as backup's tool or activate the SRV2008/SRV2012 own shadow copy functionality, then these backups have to be treated in a secure way following the corresponding PCI requirements. This is demanded by PCI. These kinds of data backup solutions have to be validated separately in the course of the customers PCI site compliancy examinations.

Parking System User Management with Customer Active Directory Infrastructure From Parking.Logic version 08.00.* onwards the system does support the application user management utilizing an existing active directory infrastructure of the customer.

Important Note: This is not a standard SKIDATA parking system configuration which can be covered by our PA DSS validation at all, as we are depending on an “external” PCI compliant active directory infrastructure management. This configuration would additionally extend the PCI scope (CDE) to the existing IT infrastructure beyond the parking system. Therefore PCI DSS compliancy has to be validated also for the parking system during a PCI site compliancy assessment!



5. SKIDATA Security Validation Without limiting any other requirements set forth in this document, all distributors, resellers, customers, merchants and any other user of the SKIDATA payment application(s) (collectively, “Users”) must fully comply with the requirements set forth in this Implementation Guide, as SKIDATA may update or amend it from time to time, as SKIDATA determines in its sole discretion.

Users acknowledge and agree that any statement that a SKIDATA product is “verified,” “approved,” or is otherwise PCI-SSC compliant means only that the User’s use of that product in accordance with (a) all terms and conditions relating to that use and (b) the requirements set forth in this Implementation Guide, will not impact the User’s ability to obtain site-specific approval from PCI SSC. Further, Users understand that in order to achieve and maintain site-specific compliance from PCI SSC, Users will need to comply with the standards promulgated by PCI SSC, including, without limitation, PCI’s Data Security Standard, as that document and those standards may be updated by PCI SSC from time to time.

5.1 PA DSS reference 1.0 - Do not retain full track data, card

verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data

5.1.1 PA DSS reference 1.1 - Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

Sensitive authentication data includes the data as cited in the following Requirements 1.1.1 through 1.1.3.

Aligns with PCI DSS Requirement 3.2

5.1.1.1 PA DSS reference 1.1.1 - After authorization, do not store the full contents of any track from the magnetic stripe (located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

In the normal course of business, the following data elements from the magnetic stripe may need to be retained: the accountholder’s name, primary account number (PAN), expiration date, and service code. To minimize risk, store only those data elements needed for business.

Aligns with PCI DSS Requirement 3.2.1



SKIDATA:

SKIDATA does not store card verification code or value or PIN verification value data elements at any time within the system.

SKIDATA does not store any magnetic track data or complete PAN information within trace or log files even for troubleshooting purposes at any time. Every information is rendered in PCI compliant manner. Although SKIDATA service technicians are strictly instructed to reset the trace levels after troubleshooting has been finished and to securely delete all the concerned log files and System Error Reports from the local parking environment (the appropriate SKIDATA wiping tool is included in every parking system) as there could be other sensitive information within these files like parking system customer data. Additionally the whole SKIDATA support chain and the SKIDATA development staff are instructed to delete concerned files securely after the support / bug fixing case has been finished.

There are four different methods for credit card clearing within the parking system application:

Online Authorization via Authorization server protocol The credit card transaction is authorized online. No magnetic stripe data are stored within the system at all. Magnetic stripe data are sent by the credit application to the real time credit card integrations for authorization. In the event the processor is not reachable no authorization is possible. Also in this case no magnetic stripe data are stored.

Online Authorization via Authorization server protocol and Credit Card Token The credit card transaction is authorized online. No magnetic stripe data and no PAN are stored within the system at all. Magnetic stripe data are sent by the application to the real time credit card integrations for authorization. The central credit card authorization server (processor) returns a credit card token (reference number) back to the parking system. This token is stored within the parking system database. No credit card PAN is stored and used within the parking system database at all. In the event the processor is not reachable no authorization is possible.

Online Authorization via External Terminal hardware (Chip&Pin Solutions) The credit card transaction is authorized online by the terminal itself. There are no magnetic stripe data delivered from the terminal to the application in this case. In the event the processor is not reachable the transaction is declined. The usage of PED/PTS compliant terminal hardware is mandatory.

If payment authorization has been succeeded the payment transaction including PAN is stored by the parking system securely within the database.

Offline Authorization via encrypted batch-files As offline batch clearing is still common in European countries this possibility cannot been discarded by the parking system within a short time frame. If offline clearing is configured within the parking system the whole clearing file is encrypted before authorization. The encrypted file contains PAN and sometimes also magnetic stripe data as this is still needed with some clearing formats in some countries (only pre-authorization).



Encryption will take place in memory so no temporary unencrypted data are generated. After clearing (either by use of secure file transfer or data carrier) the files will be deleted irretrievable by the system immediately. The encryption method can be configured within the system (symmetric or asymmetric methods and key management).

If choosing this clearing method PCI requires to treat the relevant encryption keys securely and to change them in PCI compliant manner.

Note: The PCI/PA-DSS software module has to be enabled in the program “Settings/Software Module”. The setting PCI/PA-DSS has to be enabled in the program “Credit Card Settings”.

Country specific Interface Implementations: Interface Implementations are generally not covered by the PA DSS validation of the SKIDATA Parking System as they have not been part of the onsite PA DSS assessment. While these interface implementations may not qualify as full "Payment Applications", they are in scope of the customers’ cardholder data environment and thus they are part of the customers’ PCI responsibility.

That means interface implementations have to be part of the customers PCI site assessment. This is valid for every parking system interface and of course also for the Electronic Payment Interface (EPI).

5.1.1.2 PA DSS reference 1.1.2 - After authorization, do not store the card validation

value or code (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.


SKIDATA: Card validation codes are not used by the SKIDATA parking application. On that score SKIDATA does not store this information at all within the system.

5.1.1.3 PA DSS reference 1.1.3 – After authorization do not store the personal

identification number (PIN) or the encrypted PIN block.


SKIDATA: PIN Verification Values are not used by the SKIDATA parking application. On that score SKIDATA does not store this information at all within the system.



5.1.1.4 PA DSS reference 1.1.4 - Securely delete any track data (from the magnetic stripe or equivalent data contained on a chip), card verification values or codes, and PINs or PIN block data stored by previous versions of the payment application, in accordance with industry-accepted standards for secure deletion, as defined, for example by the list of approved products maintained by the National Security Agency, or by other State or National standards or regulations.

All Users shall ensure that historical data is removed from previous versions of the payment application, including without limitation, magnetic stripe data, card validation codes, PINs or PIN blocks.

Aligns with PCI Requirement 3.2

SKIDATA: SKIDATA service technicians who are performing system software updates from non-PCI compliant versions onto PCI compliant versions are strictly instructed to either wipe the hard disks before installation or use completely new hard disks for the installation procedure and destroy the old ones (see “SKIDATA Secure Guidelines for Employees” documentation).

Note: The removal of this historical data is absolutely necessary for PCI DSS compliance!

5.1.1.5 PA DSS reference 1.1.5 - Do not store sensitive authentication data on vendor

systems. If any sensitive authentication data (pre-authorization data) must be used for debugging or troubleshooting purposes, ensure the following:


SKIDATA:

SKIDATA does not store card verification code or value or PIN verification value data elements at any time within the system.

SKIDATA does not store any magnetic track data or complete PAN information within trace or log files even for troubleshooting purposes at any time. PAN information is rendered in PCI compliant manner.

Although SKIDATA service technicians are strictly instructed to increase trace levels only in case of troubleshooting. The data have to be stored only within the assigned SKIDATA IT infrastructure. The access rights for this IT infrastructure are administrated correspondingly by the central SKIDATA IT department. SKIDATA service technicians are strictly instructed to reset the trace levels after troubleshooting has been finished and to wipe all the concerned log files and System Error Reports from the local parking environment (the appropriate SKIDATA wiping tool is included in every parking system) as there could be other sensitive information within these files like parking system customer data. Additionally the whole SKIDATA support chain and the SKIDATA development staff are instructed to wipe concerned files after the support / bug fixing case has been finished.



Customers and resellers/integrators:

• Collect sensitive authentication 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 sensitive authentication data while stored • Securely delete such data immediately after use

Note: The increase of Trace levels and the generation of System Error Reports have to be performed only if obliged by SKIDATA support personnel in case of problems and troubleshooting. After bug fixing (patch or service pack installation) the SKIDATA service technicians are strictly instructed to decrease the trace levels and to wipe all the concerned Trace, Trace back files and System Error Reports from the local parking environment (the appropriate SKIDATA wiping tool is included in every parking system).

5.2 PA DSS reference 2.0 - Protect stored cardholder data

5.2.1 PA DSS reference 2.1 - Software vendor must provide guidance to customers regarding secure deletion of cardholder data after expiration of customer-defined retention period.

Aligns with PCI Requirement 3.1

Cardholder data exceeding the customer-defined retention period must be securely

deleted. A list of all locations where the payment application stores cardholder data (so that

customer knows the locations of data that needs to be deleted). Instructions that customers need to securely delete cardholder data when no longer

required for legal, regulatory, or business purposes. Instructions on how to securely delete cardholder data stored by the payment

application, including data stored on underlying software or systems (such as OS, databases, etc.)

• Instructions for configuring the underlying software or systems (such as OS, databases, etc.) to prevent inadvertent capture or retention of cardholder data—for example, system backup or restore points.

SKIDATA: All credit card information is stored encrypted within the database. The Microsoft SQL Server 2008/2012 included encryption mechanism is used for this purpose. As key type the strong encryption type AES with 256 bit key length is used. All security relevant data that are stored temporarily within the system (.tmp files) are encrypted using a 256bit AES algorithm with a randomized changed key (based on the facility number and a random salt part).

After a definable period of time all cardholder data will be automatically completely removed from the application database (on a daily basis). The default value configured for the automatic data deletion is 62 days.



Note: The default value for the automatic data deletion must not be changed by the customer without corresponding business justification.

Typically the SKIDATA setup procedure handles installation and configuration of the operating system and the database system automatically. In rare cases this is done by customer own IT personnel, in this case the customer is advised to prepare the underlying software as demanded by PCI.

The following operating system functionalities are disabled automatically for PCI compliancy:

Backup and Restore System Protection / Restore Points Backup Tasks

The following operating system functionalities are activated automatically for PCI compliancy:

Encryption of the System Pagefile.sys Disable System Management of Pagefile.sys Disable Windows Error Reporting

Note: If for any reason operating system settings are changed, SKIDATA strongly advises that the above settings have to be verified manually!

This is also described in detail within the SKIDATA software installation manual. In seldom cases customers are integrating the Parking.Logic devices into their existing domain infrastructure. Parking.Logic version 09.00.* does support this operation mode but the SKIDATA domain prerequisites have to be fulfilled as follows.

SKIDATA domain network requirements:

Domain functional Level: Windows Server 2008 R2 • Parking System gets an own Organizational Unit (OU) “Parking” • User and Computer for the Parking System located in the OU “Parking” • No inherited GPOs from the domain. -> Option “Block Inheritance” for the OU

“Parking” and no enforced GPOs that effects the OU “Parking” • One User defined from the IT to manage the OU “Parking”. This user must have the

right to add users and computers to the domain. • User “parkuser” and user “exchange” are required in the OU “Parking”. • User are allowed to read the Computer and User Objects of the OU “Parking”



5.2.2 PA DSS reference 2.2 - Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.

Note: This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, legal or payment card brand requirements for point-of-sale (POS) receipts.


SKIDATA: All application screens, reports, logs, printouts and receipts only display PAN numbers truncated to the last four digits for operators. Even Parking system administrators do not have access to complete credit card data. The rendering (truncation) configuration depends on the activation of the PCI/PA-DSS software module. This setting is not reversible once set.

The payment application displays truncated PAN in the following locations (display & printout):

• Customer administration • Customer present card • Customer movements • Credit card present cards • Credit card movements • Credit card black list • Parking movements • Reservation administration • Manual cash application

Payment receipts including the truncated PAN are produced by the following application parts:

• Manual cash application • Automatic payment machine • Exit column (exit field device)

Note: The PCI/PA-DSS software module has to be enabled in the program “Settings/Software Module” to activate the above described behavior. The display of credit card numbers is basically configurable, only if the PCI/PA-DSS module has been activated the credit card number truncation is activated accordingly throughout the system.

If any credit card configuration is changed or extended after activation of the PCI/PA-DSS software module the rendering configuration for credit card receipts has to be configured manually in a PCI compliant manner. This is not performed automatically.



5.2.3 PA DSS reference 2.3 - Render PAN unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography (hash must be of the entire PAN) • Truncation (hashing cannot be used to replace the truncated segment of PAN) • Index tokens and pads (pads must be securely stored) • Strong cryptography with associated key-management processes and procedures.


SKIDATA: All credit card information is stored encrypted within the database. The Microsoft SQL Server 2008/2012 included encryption mechanism is used for this purpose. As key type the strong encryption type AES with 256 bit key length is used.

Additionally all database backup files contain encrypted data only. All security relevant data that are stored temporarily within the system (.tmp files) are encrypted using a 256bit AES algorithm with a randomized changed key (based on the facility number and a random salt part).

After a definable period of time all cardholder data will be automatically completely removed from the application database (on a daily base). The default value configured for the automatic data deletion is 62 days.

Notes: The complete data encryption is part of the parking system functionality with no additional configuration necessary.

Debugging Logs: SKIDATA does not store any magnetic track data or complete PAN information within trace or log files even for troubleshooting purposes at any time. Every information is rendered in PCI compliant manner. Although SKIDATA service technicians are strictly instructed that log files must be protected in accordance with PCI DSS. Trace levels have to be reset /deactivated after troubleshooting has been finished and all concerned log files and System Error Reports have to be deleted securely from the local parking environment (the appropriate SKIDATA wiping tool is included in every parking system) as there could be other sensitive information within these files like parking system customer data. Additionally the whole SKIDATA support chain and the SKIDATA development staff are instructed to delete concerned files securely after the support / bug fixing case has been finished.

5.2.4 PA DSS reference 2.4 - Payment application must protect keys used to secure cardholder data against disclosure and misuse.


SKIDATA: The access to the data encryption key for the credit card information is protected by a strong password. This password is changeable by application users with administrator rights only.



Note: During installation a default password will be established by the system. PCI requires the change of the credit card key password after installation, update installation or re-installation of the system caused by hardware defects (see “How to start section” within this document). The naming within the application GUI is “Credit Card Key Password”.

SKIDATA strictly recommends that:

• Access to keys is restricted to the fewest number of custodians necessary. • The SKIDATA application does not allow you as a merchant to store the actual key at

any time. The application automatically only stores the keys in a single location. You should protect the password (“Credit Card Key Password”) if it is ever stored for any reason and then it must be stored securely and in the fewest possible locations and forms.

5.2.5 PA DSS reference 2.5 - Application must implement key management

processes and procedures for keys used for encryption of cardholder data.


5.2.5.1 PA DSS reference 2.5.1 - Generation of strong cryptographic keys

SKIDATA: Microsoft SQL Server 2008/2012 included encryption mechanism is used for this purpose. As key type the strong encryption type AES with 256 bit key length is used. This applies to all cardholder data.

Additionally the SQL Server 2008/2012 is not only simply encrypting the data, but also using a salt and timestamp mechanism to increase encryption security.

Link for detailed information on the AES encryption: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

5.2.5.2 PA DSS reference 2.5.2 - Secure cryptographic key distribution

SKIDATA: The cryptographic keys are programmatically generated and not distributed outside of the system.

5.2.5.3 PA DSS reference 2.5.3 - Secure cryptographic key storage

SKIDATA: The key is stored encrypted in the Microsoft SQL Server 2008/2012 system tables of the application database (built in Microsoft SQL Server 2008/2012 functionality). A backup or separation of the key is not possible so it can be guaranteed that the key only resides within the application database

http://en.wikipedia.org/wiki/Advanced_Encryption_Standard



5.2.5.4 PA DSS reference 2.5.4 - Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text 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 (for example, NIST Special Publication 800-57).

SKIDATA: The parking system application offers the possibility to change the data encryption key manually. After changing the data encryption key, all data are re-encrypted with the new key and the old key is dropped from the database so only the new key will exist further on. The data encryption key is changeable by application users with administrator rights only.

No automatic key change has been implemented, because the subsequent re-encryption of the database could affect the whole system performance. Because of this a change of the keys has to be a manual action planned by the responsible persons.

Note: PCI requires the change of the data encryption key at least once a year or after an update onto a new major version of the parking system software. The application will display a notification message after this period to inform about a PCI compliant key change. During installation a default data encryption key will be established by the system. PCI requires the change of the data encryption key after installation, update installation or re- installation of the system caused by hardware defects. Also if keys are known or suspected to be compromised, PCI requires the change of the data encryption key (this includes the change of the credit card key password).

Find subsequently a description how the change has to be done.

How to change the data encryption Key:

Only parking system users with parking system administrator rights are allowed to perform a change of the data encryption key.

1. The functionality to change the data encryption key can be found in the program

“System/Data Encryption” 2. The user has to input the current credit card key password for the current encryption

key (if the password is the default password this step will be skipped). The naming within the application GUI is “Credit Card Key Password”.

3. The User has to input the new credit card identity value, minimum 10 digits including minimum 1 special character and minimum 1 numeric digit (2 times for confirmation). The naming within the application GUI is “Credit Card Identity Value”.

4. The User has to input the new strong credit card key password, minimum 20 digits including minimum 1 special character and minimum 1 numeric digit (2 times for confirmation). The naming within the application GUI is “Credit Card Key Password”.

After the successful change, the system will generate the new data encryption key and starts to perform the re-keying process of the existing data automatically.

PCI requires that key-custodians are signing a form specifying that they understand and accept their key-custodian responsibilities. Refer to appendix A for a sample authorized key custodian form.



SKIDATA strictly recommends additionally that:

• All passwords and the Credit Card Identity Value have to be stored in a secure manner.

• Access to keys is restricted to the fewest number of custodians necessary. • Keys have to be stored securely in the fewest possible locations and forms.

This is required by PCI DSS regulations.

5.2.5.5 PA DSS reference 2.5.5 - Retirement or replacement of keys (for example: by

archiving, destruction, and/or revocation as applicable) as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component, etc.) or keys are suspected of being compromised.

SKIDATA: PCI requires the change of the data encryption key after installation, update installation or re- installation of the system caused by hardware defects. Also if keys are known or suspected to be compromised, PCI requires the change of the data encryption key (this includes the change of the credit card key password).

SKIDATA implemented a manual procedure for changing the credit card encryption key including re-keying (means re-encryption of existing data with new key) of data.

The old encryption key for credit card data is removed using the DROP SYMMETRIC KEY statement of the Microsoft SQL Server 2008/2012. Using this statement the key is deleted from the application database where Microsoft states that the key cannot be recovered anyway. Even the key would remain somewhere it is still encrypted with the password phrase and therefore not usable (and no data exist which are still encrypted with this key). The corresponding pages are marked as free and will be reused (and therefore be overwritten) if new pages are requested later on. Additionally the pages formerly used by the key are zeroed out immediately after the drop process using the SQL Server 2008/2012 defined procedure “sp_clean_db_free_space”. This procedure guarantees that no data from the key exist any longer somewhere in the application database.

Link for detailed information on the DROP SYMMTETRIC KEY statement: http://msdn2.microsoft.com/en-us/library/ms182698.aspx

Link for detailed information on the sp_clean_db_free_space procedure: http://msdn.microsoft.com/en-us/library/dd408732.aspx

5.2.5.6 PA DSS reference 2.5.6 - If the payment application supports manual clear-text cryptographic key-management operations, these operations must enforce split knowledge and dual control.

SKIDATA: The application does not support manual clear-text cryptographic key-management operations.

http://msdn2.microsoft.com/en-us/library/ms182698.aspx

http://msdn.microsoft.com/en-us/library/dd408732.aspx



5.2.5.7 PA DSS reference 2.5.7 - Prevention of unauthorized substitution of cryptographic keys

SKIDATA: Only parking system users with parking system administrator rights are allowed to change the data encryption key. Additionally a strong “credit card key password” is necessary to change the data encryption key.

5.2.6 PA DSS reference 2.6 - Provide a mechanism to render irretrievable any cryptographic key material or cryptogram stored by the payment application, in accordance with industry-accepted standards.

These are cryptographic keys used to encrypt or verify cardholder data.

• That cryptographic material must be rendered irretrievable • How to render cryptographic material irretrievable • That such irretrievability is absolutely necessary for PCI DSS compliance • How to re-encrypt historic data with new keys


SKIDATA: The former non-PCI compliant versions did not use any cryptographic material. Within the versions 02/19 and 03/20 which are compliant a key management system is in place and the crypto keys are removed irretrievable after every change and re-keying of the database. The application cares about the irretrievability of cryptographic material.

Note: Customers and resellers/integrators are required to remove all cryptographic material irretrievable and acknowledge that the irretrievable removal of cryptographic material is absolutely necessary for PCI DSS compliance. As this is performed automatically during the key change procedure, customers and resellers/integrators are advised to change the encryption key as set forth in section 5.2.5.4.



5.3 PA DSS reference 3.0 - Provide secure authentication features.

5.3.1 PA DSS reference 3.1 - The payment application must support and enforce the use of unique user IDs and secure authentication for all administrative access and for all access to cardholder data. Secure authentication must be enforced to all accounts generated or managed by the application by the completion of installation and for subsequent changes after installation.

The application must enforce 3.1.1 through 3.1.11 below:

Note: The term “subsequent changes” as used throughout Requirement 3 refers to any application changes that result in user accounts reverting to default settings, changes to existing account configurations, and changes that generate new accounts or recreate existing accounts.

Note: These password controls are not intended to apply to personnel who only have access to one card number at a time to facilitate a single transaction. These controls are applicable for access by personnel with administrative capabilities, for access to systems with cardholder data, and for access controlled by the payment application. This requirement applies to the payment application and all associated tools used to view or access cardholder data.

Aligns with PCI DSS 8.1 and 8.2

Roles and default accounts with administrative access: There is only one default application account which is created automatically during setup:

Username: Administrator Role: Admin

Note: Customers and resellers/integrators are strongly advised that:

• To maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.

• Secure authentication has to be assigned to all default accounts in the environment. • Secure authentication has to be assigned to default accounts that won’t be used, and

then disable or do not use the accounts.

Important Note: Parking System User Management with Customer Active Directory Infrastructure From Parking.Logic version 08.00.* onwards the system does support the application user management utilizing an existing active directory infrastructure of the customer.

This is not a standard SKIDATA parking system configuration which can be covered by our PA DSS validation at all, as we are depending on an “external” PCI compliant active directory infrastructure management. This configuration would additionally extend the PCI scope (CDE) to the existing IT infrastructure beyond the parking system. Therefore PCI DSS compliancy has to be validated also for the parking system during a PCI site compliancy assessment!



5.3.1.1 PA DSS reference 3.1.1 - The payment application does not use (or require the use of) default administrative accounts for other necessary software (for example, the payment application must not use the database default administrative account).


SKIDATA: Default administrative accounts are not used at all.

Resellers and Integrators are advised against using default administrative accounts for payment application logins (for example, don’t use the “sa” account for payment application access to the database).

5.3.1.2 PA DSS reference 3.1.2 - The application must enforce the changing of all

default application passwords for all accounts that are generated or managed by the application, by the completion of installation and for subsequent changes after installation. This applies to all accounts, including user accounts, application and service accounts, and accounts used by the vendor for support purposes.


SKIDATA: This requirement is enforced by the application with the completion of system installation after activation of the “PCI/PA-DSS” software module (see section 4.2 password change wizard).

Note The application uses a single backend database (Microsoft SQL Server 2008/2012). The application does not use the default database administrative account for accessing the database. The default administrative database account (sa) is configured with a strong password (alphanumeric including special characters).

5.3.1.3 PA DSS reference 3.1.3 - The payment application assigns unique IDs for user

accounts.

Aligns with PCI DSS Requirements 8.1.1

SKIDATA: Unique IDs are assigned by the application automatically during creation of an application user account.



5.3.1.4 PA DSS reference 3.1.4 - The payment application employs at least one of the following methods to authenticate all users: Something you know, such as a password or passphrase; Something you have, such as a token device or smart card; Something you are, such as a biometric.

Aligns with PCI DSS Requirements 8.2

SKIDATA: The application does not permit operators any direct user access to cardholder data. The application access is completely secured by a unique username and a complex password. No access to the application is possible throughout the system without username and password. The user roles and the appropriate rights can be configured by the administrator role.

Note: For systems that contain new lane equipment “Power.Gate” or “Lite.Gate” (new parking column lane device types): normal application user login has to performed also on these lane devices to access the service menu.

5.3.1.5 PA DSS reference 3.1.5 - The payment application does not require or use any

group, shared, or generic accounts and passwords.


SKIDATA: The application does not require or use any group, shared or generic accounts and passwords.

5.3.1.6 PA DSS reference 3.1.6 - The payment application requires that passwords

meet the following: Require a minimum length of at least seven characters. Contain both numeric and alphabetic characters.

Alternatively, the passwords/phrase must have complexity and strength at least equivalent to the parameters specified above.

SKIDATA: The password for the login into the SKIDATA system has to be between 7 and 25 characters alphanumeric. These application passwords are strong one way hashed by the application (SHA-2/512) at the time of creation and stored within the database.

Note: To activate the secure password functionalities the software module “PCI/PA-DSS” has to be activated by the customer in the program “Settings/Software Module”.

5.3.1.7 PA DSS reference 3.1.7 - The payment application requires changes to user

passwords at least once every 90 days.


SKIDATA: All users, also admin users are forced by the application to change their password before 90 days.



Note: For systems that contain Automatic Payment Machines (APM450.Cash, Easy.Cash or Credit.Cash units), or utilize the Web Control Centre: A password change is not possible on these devices. Passwords have to be changed at the Data Administration Unit or on parking system workstations.

Customers are advised to monitor the parking system user accounts on a cyclic basis; this is required by PCI; monitoring and changes can be performed within the program System/Staff. User accounts that do not change their passwords within the 90days timeframe and those who are inactive shall be deactivated. User Accounts who are not needed any more shall be deleted.

5.3.1.8 PA DSS reference 3.1.8 - The payment application keeps password history and

requires that a new password is different than any of the last four passwords used.


SKIDATA: The application does not allow the reuse of passwords (last four). Additionally a defined number of characters have to be different for the new password; the number of characters can be configured within the application (default 2).

5.3.1.9 PA DSS reference 3.1.9 - The payment application limits repeated access

attempts by locking out the user account after not more than six logon attempts.


SKIDATA: The number of maximum login attempts is restricted to 3 per default.

5.3.1.10 PA DSS reference 3.1.10 - The payment application sets the lockout duration

to a minimum of 30 minutes or until an administrator enables the user ID.


SKIDATA: The number of maximum login attempts is restricted to 3 per default. After this number of invalid attempts has exceeded the login is blocked for 60 minutes. Only admin users are allowed to enable the locked account manually.

5.3.1.11 PA DSS reference 3.1.11 - If a payment application session has been idle for

more than 15 minutes, the application requires the user to re-authenticate to re-activate the session.


SKIDATA: Every workstation is locked automatically after 15 minutes idle time and the operator has to perform a normal login again.



Note: concerning the automatic lock mechanism – all open windows in the main menu will be closed; this may affect running processes like e.g. blacklist import or similar. Please contact technical support for further information on this if needed, as this can be solved by configuration.

For systems that contain Automatic Payment Machines (APM450.Cash, Easy.Cash or Credit.Cash units): during service activity the SKIDATA technician or user must activate the mouse or keyboard within the configured automatic logoff timeout (default 15 minutes) otherwise the current user will be logged off, and the machine will go into alarm mode. A login has to be performed again.

5.3.2 PA DSS reference 3.2 - Software vendor must provide guidance to

customers that all access to PCs, servers, and databases with payment applications must require a unique user ID and secure authentication.

Aligns with PCI DSS Requirement 8.1 and 8.2

SKIDATA: Users of the parking system normally do not have the need to access the devices of the system at operating system level; therefore they normally do not have the rights to access the PC’s and Servers at OS level. Only SKIDATA technicians and technicians of partner organizations do have the right to access the operating system and the system network. These access rights are also given to customer IT employees if demanded explicitly.

The database is accessed only by the application itself using fixed database users. The passwords for these users can be changed.

Only one special directory, which is used for external data exchange (sharing “Exchange”) is accessible by external systems with a special operating system user and a separate user specific password.

Note: During installation a default data exchange password will be established by the system. PCI requires the change of this password accordingly after installation, update installation or re- installation of the system caused by hardware defects.

The above described behavior is only valid for all parking system devices and servers delivered by SKIDATA.

If non-parking system devices and servers existing and running in the customers IT environment (and thus in the payment application environment) the customer is solely responsible for PCI compliant configuration, user and account management as well as for corresponding password policies at all.

This is also true for “Paged-Out SQL Server” configurations where the parking system database is located on a Microsoft SQL Database Server hardware that already exists in the customer’s IT environment (because he might use Microsoft SQL Server technology already in his IT environment for other applications).



Customers and resellers/integrators are strongly advised to control access, via unique user ID and PCI DSS complaint secure authentication, to any PCs, servers and databases with payment applications and cardholder data, this is required by PCI. Access should only be provided to those individuals whose job responsibilities specifically require them to have such access. The payment application supports the use of these unique IDs if they are set by the customer and/or reseller/integrator.

Properly Train and Monitor Admin Personnel It is your responsibility to institute proper personnel management techniques for allowing admin user access to cardholder data, site data, etc. You can control whether each individual admin user can see credit card PAN (or only last 4).

In most systems, a security breach is the result of unethical personnel. So pay special attention to whom you trust into your admin site and who you allow to view full decrypted and unmasked payment information.

5.3.3 PA DSS reference 3.3 - Secure all payment application passwords

(including passwords for user and application accounts) during transmission and storage.


5.3.3.1 PA DSS reference 3.3.1 - Use strong cryptography to render all payment

application passwords unreadable during transmission.

SKIDATA: All database traffic is encrypted by using TLS 1.1 functionality.

5.3.3.2 PA DSS reference 3.3.2 - Use a strong, one-way cryptographic algorithm, based on approved standards to render all payment application passwords unreadable during storage.

Each password must have a unique input variable that is concatenated with the password before the cryptographic algorithm is applied.

SKIDATA: All application passwords are stored within the database as a strong one way hash (SHA- 2/512) including a complex salt which depends on the application user. During log-on procedure only the created hashes are compared instead of the password itself.

5.3.4 PA DSS reference 3.4 - Payment application must limit access to

required functions/resources and enforce least privilege for built-in accounts:

By default, all application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account. By default, all application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Aligns with PCI DSS Requirement 7



SKIDATA: The application does only create one application admin account after installation. This admin account is assigned to the application administrator role. It is authorized to create and administrate all other additional application accounts.

Every application user account can be assigned to a user role. For each user role there are different application authorizations and rights defined per default within the application depending on the field of duties. User role examples would be “main cashier”, “cashier” or “facility manager”. The application authorizations and rights of each user roles can be configured if needed by the administrator role. Customers are strongly advised to assign only appropriate roles to their different application users. Every user shall on have the rights which are really needed for their specific field of duties and responsibilities.

5.4 PA DSS reference 4.0 - Log payment application activity

5.4.1 PA DSS reference 4.1 - At the completion of the installation process, the “out of the box” default installation of the payment application must log all user access and be able to link all activities to individual users.


SKIDATA: Parking.Logic has PA DSS compliant logging enabled by default. This logging is not configurable and may not be disabled. Users acknowledge and agree that disabling or subverting the logging function of Parking Logic in any manner will result in non-compliance with PCI DSS.

Card holder information is not accessible for parking system users. Payments entered into the system are tracked, including the application user who initiated the transaction. Application transaction logging settings are always active and not configurable by customers with the exception enabling debug logging that can only be performed by system users with administrator rights or SKIDATA technicians for troubleshooting purposes.

Users of the parking system normally do not have the need to access the devices of the system at operating system level; therefore they normally do not have the rights to access the PC’s and Servers at OS level. Only SKIDATA technicians and technicians of partner organizations do have the right to access the operating system and the system network. These access rights are also given to customer IT employees if demanded explicitly.

The following logs are maintained by the SKIDATA application:

Arcfile*.LOG – Arcnet monitoring ArcServError*.LOG – Arcnet service DATABASE.LOG – database installation ERRORLOG.* - error log of SQL Server INSTALL.LOG – installation INSTOOLS.LOG – installation utilities QWNotProcessed*.LOG – not processed statements START450.LOG – system start process



TRACE*.LOG – trace process TB* - trace back files; trace process *IPC*.LOG – inter process communication *.SDJ – electronic journal

5.4.2 PA DSS reference 4.2 and 4.3 – Payment application must provide an

automated audit trail to reconstruct the following events (4.2.1– 4.2.7). Payment application must record at least the following audit trail entries for each event (4.3.1-4.3.6)

Aligns with PCI DSS Requirements 10.2 and 10.3

SKIDATA: All application screens, reports, logs, and printouts only display PAN numbers truncated to the last four digits for operators. Even parking system administrators do not have access to complete credit card data, so no one does have access to cardholder data at all.

Users of the parking system normally do not have the need to access the devices of the system at operating system level; therefore they normally do not have the rights to access the PC’s and Servers at OS level. Only SKIDATA technicians and technicians of partner organizations do have the right to access the operating system and the system network. These access rights are also given to customer IT employees if demanded explicitly. The login of all users and SKIDATA technicians will be traced in the parking system events backend program.

The SKIDATA parking system has three programs for monitoring and logging all system events, all money related transactions, and configuration changes. The access rights for these programs can be configured within the parking system authorization program.

System / System Events: Within this program all system events that occur in the whole parking system will be logged.

All Irregularities, system events, information about scheduled jobs, login, logout, blocking of users due to invalid login attempts, application problems, device alarm, device problems, All password changes, application resets, shift information etc.

Log details: Date /time, system event designation, system device designation, operator/user information, remarks and additional information containing application details and notes for the user.

System / System Journal: Within this program all system events and additionally all money related transactions that are performed in the whole parking system will be logged.

Transactions, transaction numbers, amounts, cancellations, payment method, article types, irregularities, etc.

Log details: Date /time, system device designation, transactions, journal information containing detailed information about the transaction.



System / Change Logging: Within this program configuration changes within the different programs are logged in detail.

Log Details: Program (e.g. Settings/Rates), Sub program (e.g. Rates/Rate Schemes), Staff number, Date/time of change, Old value, New value, Action (New, Delete, Change), Origin of change.

Note: PCI requires the review of logs in a cyclic manner. The above mentioned application programs have to be used therefore. To perform also a review of the operating system own event viewer logs, either the SKIDATA technical support can be contacted to enable this or these log data have to be exported in a SKIDATA standard data file export and reviewed by the customer itself.

The software module “Change Logging” is activated and pre-configured automatically once the software module PCI/PA-DSS has been activated. So Parking Logic has PA DSS compliant logging enabled by default. This logging is not configurable and may not be disabled. Users acknowledge and agree that disabling or subverting the logging function of Parking Logic in any manner will result in non-compliance with PCI DSS.

5.4.3 PA DSS reference 4.4 - Payment application must facilitate

centralized logging.

Note: Examples of this functionality may include, but are not limited to:

• Logging via industry standard log file mechanisms such as Common Log File System (CLFS), Syslog, delimited text, etc.

• Providing functionality and documentation to convert the applications proprietary log format into industry standard log formats suitable for prompt, centralized logging.


SKIDATA: The Parking.Logic software modules “Customizable Data Export” or “Data Exchange” shall be used to export data files containing all relevant logging information on a cyclic and scheduled base for further integrations with Common Central Log File Systems.

Depending on the needs of the specific Central Log File System used by the customer, the SKIDATA data files can be generated in different formats e.g. ASCII or XML. These files can then be converted into industry standard log formats suitable for prompt, centralized logging.

The SKIDATA customizable data export / data exchange functionality has to be configured by a technician to export the data file in a cyclic way to be then incorporated into the central log file system of the customer. The data conversion functionality itself is not part of the SKIDATA Parking.Logic application. The customer has to care about the necessary data converter and the further integration with his central log file system.

The customer is responsible to add these data into his central logging environment. This is required by PCI. SKIDATA is only delivering the necessary data and can provide integration support if commissioned by the customer.



5.5 PA DSS reference 5 - Develop secure payment applications.

5.5.1 PA DSS reference 5.4.4 - The vendor’s published versioning methodology must be communicated to customers and integrators/resellers.

SKIDATA Versioning Methodology:

SKIDATA release identification e.g. 05.00.03

5. Major release identification (major enhancements) PA-DSS requirements will normally be impacted.

00. Minor release identification (minor enhancements) PA-DSS requirements could be impacted.

03. Service pack identification (only bug fixing, no enhancements) PA-DSS will never be impacted. Since it is bug fix and minor features that do not impact the PA-DSS requirements, this third level is not part of the listed version.

PA DSS listed versions would look like: 05.00.xx

Note: The current version information can be found in every Parking.Logic application in the help/program information menu.

5.6 PA DSS reference 6.1 - Protect wireless transmissions

5.6.1 PA DSS reference 6.3 - Provide instructions for customers about secure use of wireless technology

Aligns with PCI DSS Requirements 1.2.3, 2.1.1, & 4.1.1

SKIDATA: The SKIDATA parking system does not support wireless technologies within the parking system network and CDE (Cardholder Data Environment) environment. From APT450.Logic release 22.00 / Parking. Logic release 05.00 SKIDATA supports a new generation of mobile parking system devices called “Mobile.Gate”. These PDA devices are based on Windows Mobile and connected via Wi-Fi (see Figure 1 below). The mobile devices are communicating via web-services (https only) running on the parking system data administration unit (DAU). Mobile.Gate can be used for issuing short term parking tickets and for collecting the parking tariff due.

Note: The SKIDATA parking system does not support wireless technologies within the parking system network and CDE (Cardholder Data Environment) environment. Wireless devices are only supported if completely physically separated from the network and CDE. Thus the Wi-Fi access device for mobile devices has to be outside and completely separated from the parking system network and CDE (see figure 1 below).



No credit card data are transmitted at any time from Mobile.Gate to DAU or vice versa and there is no credit card related administrative functionality. Therefore the Mobile.Gate is not in PA DSS scope.

From Parking.Logic release 06 onwards the SKIDATA Mobile.Gate client application offers also the possibility to integrate with separate PTS validated 3rd party hardware terminals to enable mobile credit card payment additionally to the existing cash payment.

The SKIDATA Mobile.Gate client application has been extended therefore with an interface for electronic payment called EPI. No credit card data are sent via this EPI interface at any time, only the amount to be authorized.

These separate and dedicated PTS validated mobile payment terminals are communicating e.g. via Bluetooth with the SKIDATA Mobile.Gate PDA device and via the EPI with the SKIDATA Mobile.Gate client application running on this PDA.

The whole credit card payment (authorization, settlement) is handled at the PTS mobile payment terminal hardware only, not on the SKIDATA Mobile.Gate PDA.

If customers are integrating a mobile credit card payment solution at the SKIDATA Mobile.Gate utilizing the EPI interface and separate PTS validated mobile payment terminal hardware then these integrations are of course in the PCI scope of the customer and have to be validated separately. This is not in the scope of the Parking.Logic PA DSS validation.



GPRS Edge or UMTS communication

Figure 1

Note: However, should the merchant implement wireless access within or outside of the cardholder data environment, the following guidelines for secure wireless settings must be followed per PCI Data Security Standard 1.2.3, 2.1.1 and 4.1.1. The customer is solely responsible for the implementation of the following requirements:

PCI DSS 1.2.3 Perimeter firewalls must be installed between any wireless networks and systems that store cardholder data, and these firewalls must deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.

PTS Termi

nal Mobile.Gate

Mobile.Gate

WLAN Access Point

Mobile.Gate

Firewall

Router

Internal Ethernet Backbone Facility 2

SKIDATA DAZ

Pay On Foot Pay On Foot

Entrance Column

and Gate

Exit Column

and Gate



PCI DSS 2.1.1: Change wireless vendor defaults per the following 5 points:

• Encryption keys must be changed from default at installation, and must be changed anytime anyone with knowledge of the keys leaves the company or changes positions

• Default SNMP community strings on wireless devices must be changed • Default passwords/passphrases on access points must be changed • Firmware on wireless devices must be updated to support strong encryption for

authentication and transmission over wireless networks • Other security-related wireless vendor defaults, if applicable, must be changed

PCI DSS 4.1.1: Industry best practices (for example, IEEE 802.11.i) must be used to implement strong encryption for authentication and transmission of cardholder data. Note: The use of WEP as a security control was prohibited as of June 30, 2010.

The SKIDATA Mobile.Gate client application requires only TCP/IP port 443 therefore customers are strictly advised to activate only this port for communication at the firewall to the wireless network and deactivate all other traffic in order to be PCI compliant. The different networks have to be configured in a secure way.

5.7 PA DSS reference 7.0 - Test payment applications to address

vulnerabilities and maintain payment application updates

5.7.1 PA DSS reference 7.1 - Software vendors must establish a process to identify and manage vulnerabilities, as follows

Note: Any underlying software or systems that are provided with or required by the payment application (for example, web servers, third-party libraries and programs) must be included in this process.


SKIDATA: As documented within the SKIDATA Software Development guidelines. The software development policy specifies functionality, efficiency, and security testing. Security testing includes verifying all new and existing security controls function as intended, as well as vulnerability testing on all application systems.

The SKIDATA software development and the Quality assurance department have dedicated persons who are responsible for identifying new vulnerabilities of the used Microsoft products (Microsoft subscription, Experts exchange, etc.). New cumulative security patches are tested and released normally every 3 months by the quality assurance. Crucial vulnerabilities are tested and released immediately depending on the severity.

Note: SKIDATA security patches for Microsoft products are released every 3rd month. Information about the release schedule is provided by the local technical support. SKIDATA will actively inform their customers, if serious vulnerability problems occurring, which have to be fixed accordingly with a patch.



5.7.2 PA DSS reference 7.2.3 - Provide instructions for customers about secure installation of patches and updates

Information about:

• How the vendor will communicate notifications of new patches and updates • How patches and updates will be delivered in a secure manner with a known chain of

trust. • How to access and install patches and updates in a manner that maintains the

integrity of the patch and update code

SKIDATA: Patch and update notification: SKIDATA central technical support will notify subsidiaries and partner organizations about the availability of patches and updates per email. Local technical support of subsidiaries and partner organizations is advised to inform customers accordingly in written form (e.g. email).

SKIDATA Software Deployment: SKIDATA distributes major software upgrades on DVD/USB stick. To download patches and updates securely, SKIDATA offers an https secured platform for subsidiaries and partner organizations (restricted access to authorized users only). Patches and updates are also sent per email on request to subsidiaries and partner organizations. The patches itself are contained in a .zip archive which is secured by a cyclically changed password where AES256 encryption is used. The password is always distributed separately.

Software installation and data integrity: Manual update on site - manual update (major upgrades, service packs, patches) is started from within the application by selecting an installation package from a data carrier (USB stick, CD, DVD …). All service technicians are advised to use IT approved equipment only for these actions. Except patching all manual update routines cannot be initiated by the customer itself but only by a service technician.

Manual update remote - SKIDATA service technicians additionally do have the possibility to deliver service packs or patches by remote access to customer networks. This remote access is restricted to SKIDATA service personnel only. In case of a remote access to the parking system the SKIDATA service technician has to obtain the permission from the customer before.

Automatic Update - automatic update (service packs, patches only) can also be done from a dedicated SKIDATA server located in Austria. The domain name of this server is fixed and cannot be changed. The server access is fully secured by using FTPS and a SKIDATA certificate which is checked before any download activity is initiated. The download process itself runs fully automated. The only decision possibility the customer has is to configure if we wants to install the files immediately after download or at a specified time. The prerequisite for this functionality is a secure internet connection provided by the customer.

File integrity - all installation packages (major upgrades, service packs, patches) are signed with a SKIDATA certificate to guarantee the origin of the package. Additionally all packages are delivered with an extra file containing an encrypted hash signature based on HMAC- SHA256. This hash can only be reproduced if the internal key is known. It is checked both on starting the installation within the application and within the installation process itself to prevent later replacement of packages.



5.8 PA DSS reference 8.0 - Facilitate secure network implementation

5.8.1 PA DSS reference 8.1 - The payment application must be able to be implemented into a secure network environment. Application must not interfere with use of devices, applications, or configurations required for PCI DSS compliance.

For example, payment application cannot interfere with installation of patches, anti-malware protection, firewall configurations, or any other device, application, or configuration required for PCI DSS compliance.

Aligns with PCI DSS Requirements 1, 3, 4, 5, and 6

SKIDATA: The SKIDATA parking system is basically a closed network environment, although all PCs and servers of the system are secured with the Microsoft built in firewall. The Firewall is configured securely during the system installation. SKIDATA Application components are not hindering secure network implementations. The recommended Anti-virus software products and the tested SKIDATA security patch installation do not negatively affect applicable systems.

Note: Information about the recommended anti-virus software products and the availability of security patches are provided by the local technical support.

The SKIDATA parking system is basically a closed network environment, thus the network security of the system outwards is in the sole responsibility of the customer. PCI requires that there is no direct internet connection to SKIDATA parking system devices. Connections to the internet have to be implemented via dedicated non SKIDATA servers (e.g. proxy server). State of the art security techniques like e.g. firewalls, hardware firewalls and secured communication (TLS1.1, SSH, VPN) have to be implemented to comply with present PA DSS and PCI DSS requirements.

SKIDATA recommends setting up a physically separated network. If the parking system has to be operated based on an existing IT infrastructure SKIDATA recommends configuring a virtual LAN solely used by the parking system. This is required by PCI.

PCI requires the review of firewall and router configurations and rules on a cyclic basis at least every six months. This is demanded by PCI-DSS 1.1.6.

Users shall not disable any features that are required within this Implementation Guide, PCI DSS, PCI PA-DSS or other requirements promulgated by PCI SSC or SKIDATA. This shall include, without limitation, a prohibition on disabling any anti-virus software or firewalls.

5.8.1.1 Additional Note concerning Optional Parking System Components: SKIDATA offers additionally to the parking system product several software products and components which may exist beside the parking system CDE optionally. These components are described subsequently.



5.8.1.2 SKIDATA Main Administration Unit (MAU) This Application is used for administration and configuration purposes of multiple subjacent parking facilities. Basically an MAU is a normal parking system Data Administration Unit (DAU) that is configured as Main Administration Unit (MAU) hierarchically.

MAU functionalities:

• Central reporting (daily, monthly reports, statistics) • Central data exchange (central data file collection and distribution) • Central customer data administration • Central configuration (articles, staff, email, rental agreements, etc.) • Central credit card settlement (This kind of credit card settlement must not be used

together with PCI / PA DSS parking facilities!)

Communication: The MAU is connecting automatically to the different subjacent parking facility data administration units once a day during night time for distributing and collecting data files. Different connection possibilities are supported from dial-in onto VPN, although in the meantime VPN connections seem to be the standard type of connection.

No credit card data are transmitted at any time from MAU to DAU or vice versa.

Note: There is legacy functionality for clearing credit card transactions centrally via MAU. This kind of credit card settlement must not be activated on MAU devices at PCI / PA DSS parking facilities!

The connection between the SKIDATA main administration unit MAU and the parking system data administration unit DAU must be secured by an additional external hardware firewall or the connection must be based on a VPN network. Customers who decide to use the SKIDATA MAU have to ensure that the connections are secure following the PCI-DSS specifications (PCI-DSS item 1 / PA DSS item 8). Customers shall not use unsecure methods of connecting the SKIDATA main administration unit MAU and the parking system data administration unit DAU.

5.8.1.3 SKIDATA Main Control Centre (MCC) This “add on” application is used for central monitoring and control of multiple parking facilities e.g. in a central control room. With this “Control Room” application the different devices of the different parking facilities can be monitored (status, events, failures) and controlled remotely (open barrier, close barrier, etc.).

The MCC application is connected permanently to the different subjacent parking facilities via a SKIDATA proprietary IP socket protocol utilizing a VPN tunnel connection. The MCC application is using normal parking system authentication features and mechanisms. Multi- factor authentication is supported and recommended.

No credit card data is transmitted at any time from MCC to DAU or vice versa and there is no credit card related administrative functionality. Therefore the MCC is not in PA DSS scope.

Note: The connection between the SKIDATA main control center MCC and the parking system data administration unit DAU must be secured by an additional external hardware firewall or the connection must be based on a VPN network. Customers who decide to use the SKIDATA MCC have to ensure that the connections are secure following the PCI-DSS



specifications (PCI-DSS item 1 / PA DSS item 8). Customers shall not use unsecure methods of connecting the SKIDATA main control center MCC and the parking system data administration unit DAU.

5.8.1.4 Remote Monitoring and Control (REMCO) This application has basically the same intended purpose as the MCC application - “Remote Monitoring and Control” of parking system devices. MCC is the old mature product currently in maintenance mode and REMCO is the new successor application. REMCO additionally supports new functionalities like SLA management etc.

The REMCO application is connected permanently to the different subjacent parking facilities via an SKIDATA proprietary protocol utilizing a VPN tunnel network connection.

The REMCO application itself is basically a central hosted service (hosted by SKIDATA or the customer) communicating with a local REMCO-agent application located at the local parking facility. This REMCO-agent application either resides on a separate small REMCO- agent PC (embedded PC) or directly as an additional service running at the parking system data administration unit DAU.

The REMCO-agent application is communicating with the parking system application via a SKIDATA proprietary IP socket protocol authenticated by a special SKIDATA certificate.

No credit card data are transmitted at any time from REMCO to DAU or vice versa and there is no credit card related administrative functionality. Therefore REMCO is not in PA DSS scope.

Note: Due to the fact that REMCO is a hosted application (hosted by SKIDATA or the customer), the connection between the local REMCO-agent application and the central hosted REMCO component must be secured by an additional external hardware firewall or the connection must be based on a VPN network. Customers who decide to use the SKIDATA REMCO component have to ensure that this connection is secure following the PCI-DSS specifications (PCI-DSS item 1 / PA DSS item 8). Customers shall not use unsecure methods of connecting the local REMCO-agent application (within the parking system environment) and the hosted SKIDATA REMCO component.

5.8.1.5 Interface to the SKIDATA Direct to Access component (DTA) The parking system data administration unit DAU offers an interface to the SKIDATA DTA component. The SKIDATA DTA component offers therewith one broker platform that is able to support multiple different SKIDATA systems for the integration of web shops, self-service terminals and other sales channels. Parking space reservation and sales transactions can be performed utilizing the SKIDATA DTA platform. 3rd party systems can be easily integrated using state of the art SKIDATA web services on top of DTA. The SKIDATA DTA component is not an integral part of the parking system itself. The parking system is only interfacing with this component for data exchange purposes where the data transmission between the parking system and the SKIDATA DTA component will be encrypted.

No credit card data are transmitted at any time from DTA to DAU or vice versa and there is no credit card related administrative functionality. Therefore DTA is not in PA DSS scope.

Note: Due to the fact that the SKIDATA DTA component is a hosted application (hosted by SKIDATA or the customer), the connection between the parking system data administration



unit DAU and the SKIDATA DTA component must be secured by an additional external hardware firewall or the connection must be based on a VPN network. Customers who decide to use the SKIDATA DTA component have to ensure that this connection is secure following the PCI-DSS specifications (PCI-DSS item 1 / PA DSS item 8). Customers shall not use unsecure methods of connecting the parking system data administration unit DAU and the hosted SKIDATA DTA component.

5.8.1.6 Interface to the SKIDATA Data Warehouse component (DWH) The parking system data administration unit DAU offers an interface to the SKIDATA DWH component. Business relevant information from multiple data feeding systems e.g. parking systems can be collected in a standardized and unified format within this new SKIDATA DWH. Applications can be built on top of the SKIDATA DWH for reporting, ERP or CRM usage. The SKIDATA DWH component is not an integral part of the parking system itself. The parking system is only interfacing with this component for data exchange purposes where the data transmission between the parking system and the SKIDATA DWH component will be encrypted.

No credit card data are transmitted at any time from DAU to DWH and there is no credit card related administrative functionality. Therefore DWH is not in PA DSS scope.

Note: Due to the fact that the SKIDATA DWH component is a hosted application (hosted by SKIDATA or the customer), the connection between the parking system data administration unit DAU and the SKIDATA DWH component must be secured by an additional external hardware firewall or the connection must be based on a VPN network. Customers who decide to use the SKIDATA DWH component have to ensure that this connection is secure following the PCI-DSS specifications (PCI-DSS item 1 / PA DSS item 8). Customers shall not use unsecure methods of connecting the parking system data administration unit DAU and the SKIDATA DWH component.

5.8.1.7 Interface to the SKIDATA Central Rate Configuration The parking system data administration unit DAU offers an interface to the SKIDATA central rate configuration component. With this component the rate structure of multiple facilities can be configured centrally. The SKIDATA rate configuration component is a central hosted service that communicates only via web-services that are running on the parking system data administration unit (DAU).

No credit card data are transmitted at any time from this component to DAU or vice versa and there is no credit card related administrative functionality. Therefore this application is not in PA DSS scope.

Note: Due to the fact that the SKIDATA central rate configuration component is a hosted application (hosted by SKIDATA or the customer), the connection between the parking system data administration unit DAU and the SKIDATA central rate configuration component must be secured by an additional external hardware firewall or the connection must be based on a VPN network. Customers who decide to use the SKIDATA central rate configuration component have to ensure that this connection is secure following the PCI-DSS specifications (PCI-DSS item 1 / PA DSS item 8). Customers shall not use unsecure methods of connecting the parking system data administration unit DAU and the SKIDATA central rate configuration component.



5.9 PA DSS reference 8.2 - The payment application must only

use or require use of necessary and secure services, protocols, daemons, components, and dependent software and hardware, including those provided by third parties, for any functionality of the payment application

Note: SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of SSL or early TLS. Applications that use or support TLS must not allow fallback to SSL.


SKIDATA: Services and Protocols Parking.Logic does not require the use of any insecure services or protocols. Here are the services and protocols that Parking.Logic does require:

• TCP/IP (base protocol for the overall communication) • SQL Server/Agent/VSS Writer (for accessing the application database) • SQL Server Offline (for local configuration database, not network accessible) • Remote Desktop • Remote Access Connection Manager • Windows Firewall • Windows Event Log • Group Policy Client • Base Filtering Engine • Cryptographic Services • Themes • Power • Secondary Logon • SKIDATA Arcnet Service • SKIDATA Remote Communication Service • SKIDATA Scan Service • SKIDATA Admin Service • Net.Tcp Port Sharing • SNMP (on HP servers) • System Event Notification • Task Scheduler • Windows Deployment (Server 2008/2012 only) • Windows Update • Several base services of Windows 7/Server 2008/2012 (Server, WS, Browser, • Plug&Play, DHCP, DNS, DCOM, COM+, WMI, Netlogon, RPC, Printer Spooler …).

The following services can be disabled without influence on the operation of the system (only services which are not disabled by default are listed):

• Application Experience • Application Management • Certificate Propagation



• Diagnostics Service Host • Diagnostics Policy • Offline Files • Program Compatibility Assistant (Windows 7 only) • Security Centre (Windows 7 only) • Shell Hardware Detection • SNMP (on non HP servers) • SNMP Trap • Superfetch (Windows 7 only) • Windows Audio • Windows Audio Endpoint Builder • Windows Defender • Windows Font Cache • Windows Time

SKIDATA Main Software Components

• Control Center Application • Application for monitoring and control of the various parking system devices (e.g.

manual barrier open etc.) • Pay Station Application • Attended POS application for payment and sale of parking tickets. Various payment

methods like cash, credit cards or coupons are possible. • Mobile Control Center Application • An internal web based light version of the regular control center above, no credit card

or administrative functionality is available. • Main Menu Application • Various applications for configuration, logging and reporting of the parking system

including logon functionality. • Entrance and Exit Column Control Processes • Devices for short term parking ticket production and barrier control. Various ticket

media can be read e.g. barcode, magnetic stripe etc. The exit column also has optional credit card payment functionalities.

• Automatic Payment Machine Application • Unattended POS application for payment and sell of parking tickets. Various payment

methods like cash, credit cards or coupons are possible. • Authorization Server Application • Handles actual communication with processors

Additional Software Components

• Ghostscript PDF Printer • OpenSSL

Dependent Components

• Entrance columns and barriers for entry lanes • Exit columns and barriers for exit lanes • Data Administration Unit (DAU) • SQL Server (external SQL server) • Manual pay stations with coder • Automated payment machines for automated payments • Credit card authorization servers • Router and firewalls



• Ethernet backbones • Mobile.Gate handheld devices

Dependent Software

• Microsoft Operating Systems (see section 7.2 for details) • Microsoft SQL Server (see section 7.2 for details) • .NET Runtime • Visual Studio Runtime • UPOS for .NET

5.10 PA DSS reference 9.0 - Cardholder data must never be stored on a server connected to the Internet.

5.10.1 PA DSS reference 9.1 - The payment application must be developed such that any web server and any cardholder data storage component (for example, a database server) are not required to be on the same server, nor is the data storage component required to be on the same network zone (such as a DMZ) with the web server.


SKIDATA: N/A – SKIDATA application is not Internet or Web-based.

Note: Users nevertheless acknowledge and agree that they

• Shall not store cardholder data on any Internet-accessible systems. • Use a DMZ to separate the Internet from systems storing cardholder data (for

example, installing a web server component in a DMZ and installing a data storage component on an internal different network zone).

• Configure their firewall to open only required ports

A list of services/ports that the application needs to use in order to communicate across two network zones can be requested at the responsible technical support department if needed.



5.11 PA DSS reference 10.0 - Facilitate secure remote access to payment application

5.11.1 PA DSS reference 10.1 – Multi-factor authentication must be used for all remote access to the payment application that originates from outside the customer environment.

Note: Multi-factor authentication requires at least two of the three authentication methods be used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication methods).


SKIDATA: The SKIDATA parking system offers the possibility to access the system from outwards with remote tools called “SKIDATA Remote Desktop Parking (RDP)” and “SKIDATA Remote Desktop Web Access”.

SKIDATA Remote Desktop Parking (RDP) – is a small client application which uses Microsoft Terminal Services technology with the highest encryption possible preconfigured. These pre-settings cannot be changed.

SKIDATA Remote Desktop Web Access – is a possibility to use the Microsoft Internet Explorer browser at a client PC to connect to the parking system remotely. This remote access option removes the need to install any additional remote access software on a customer’s client workstation. Microsoft Remote Desktop Web Access services with the highest encryption possible preconfigured is used by SKIDATA to connect to a web page located at the DAU of the parking system. The security pre-settings cannot be changed.

The remote connection to the parking system can be performed via LAN or WAN infrastructure. The tools mentioned above are utilizing the same parking system users and the same login mechanisms which are used on local Workstations. Only access to the SKIDATA application is possible, no administrative access on OS level.

PCI requires the following: If remote access to the parking system network environment is performed then PCI requires that a multi-factor authentication mechanism (user ID and password and an additional authentication item such as a smart card, token or PIN e.g. RSA token) has to be used for establishing a VPN connection in every case.

To comply with PA DSS Requirement 3.1.4, two of the following three authentication methods have to be considered:

1. Something you know, such as a password or passphrase 2. Something you have, such as a token device or smart card 3. Something you are, such as a biometric



5.11.2 PA DSS reference 10.2 - Any remote access into the payment application must be performed securely, as follows:

5.11.2.1 PA DSS reference 10.2.1 - If payment application updates are delivered via remote access into customers’ systems, software vendors must tell customers to turn on remote-access technologies only when needed for downloads from vendor, and to turn off immediately after download completes.

Alternatively, if delivered via virtual private network (VPN) or other high-speed connection, software vendors must advise customers to properly configure a firewall or a personal firewall product to secure “always-on” connections.

Aligns with PCI DSS Requirements 1 and 12.3.9

SKIDATA Software Deployment: SKIDATA distributes major software upgrades on DVD/USB stick. Major software upgrades of the system can only be performed by SKIDATA service technicians on site.

SKIDATA offers an https secured platform for subsidiaries and partner organizations to download patches and updates securely (restricted access to authorized users only). Patches and updates are also sent per email on request to subsidiaries and partner organizations. The patches itself are contained in a .zip archive which is secured by a cyclically changed password where AES256 encryption is used. The password is always distributed separately.

Software installation and data integrity: Manual update on site - manual update (major upgrades, service packs, patches) is started from within the application by selecting an installation package from a data carrier (USB stick, CD, DVD …). All service technicians are advised to use IT approved equipment only for these actions. Except patching all manual update routines cannot be initiated by the customer itself but only by a service technician.

Manual update remote - SKIDATA service technicians additionally do have the possibility to deliver service packs or patches by remote access to customer networks. This remote access is restricted to SKIDATA service personnel only. In case of a remote access to the parking system the SKIDATA service technician has to obtain the permission from the customer before.

Automatic Update - automatic update (service packs, patches only) can also be done from a dedicated SKIDATA server located in Austria. The domain name of this server is fixed and cannot be changed. The server access is fully secured by using FTPS and a SKIDATA certificate which is checked before any download activity is initiated. The download process itself runs fully automated. The only decision possibility the customer has is to configure if we wants to install the files immediately after download or at a specified time. The prerequisite for this functionality is a secure internet connection provided by the customer.

File integrity - all installation packages (major upgrades, service packs, patches) are signed with a SKIDATA certificate to guarantee the origin of the package. Additionally all packages are delivered with an extra file containing an encrypted hash signature based on HMAC- SHA256. This hash can only be reproduced if the internal key is known. It is checked both on starting the installation within the application and within the installation process itself to



prevent later replacement of packages. If the application check fails the software is not installed at all and a corresponding message is displayed. Additionally a system event is logged in this case by the application automatically.

SKIDATA Software Products - Frequency: SKIDATA application service packs are generated normally twice a year, application patches on demand, depending on the severity of the problem.

3rd Party Product Patches (e.g. Microsoft OS) - Frequency: As a development company, we keep abreast of the relevant security concerns and vulnerabilities in our area of development and expertise.

The SKIDATA software development and the Quality assurance department have dedicated persons who are responsible for identifying new vulnerabilities of the used Microsoft products (Microsoft subscription, Experts exchange, etc.). New cumulative security patches are tested and released normally every 3 months by the quality assurance. Crucial vulnerabilities are tested and released immediately depending on the severity.

SKIDATA security patches for Microsoft products are released every 3rd month. Information about the release schedule is provided by the local technical support. SKIDATA will actively inform their customers, if serious vulnerability problems occurring, which have to be fixed accordingly with a patch.

Note: For receiving updates via remote access, customers must adhere to the following guidelines. Secure remote access technology use, per PCI Data Security Standard 12.3.9:

• Activation of remote access technologies for vendors only when needed by vendors,

with immediate deactivation after use.

• If remote access is via VPN or other high-speed connection, the connection is secured according to PCI DSS Requirement 1.

SKIDATA recommends activating remote access only if requested by SKIDATA service technicians; this is also required by PCI. In case of activating the automatic service pack download functionality: Connections to the internet have to be implemented via dedicated non SKIDATA servers (e.g. proxy server). State of the art security techniques like e.g. firewalls, hardware firewalls and secured communication have to be implemented to comply with present PA DSS and PCI DSS requirements.

5.11.2.2 PA DSS reference 10.2.3 - Remote access to customers’ payment applications

by vendors, integrators/resellers, or customers must be implemented securely.

Aligns with PCI DSS Requirements 2, 8 and 10

SKIDATA: The SKIDATA parking system offers the possibility to access the system from outwards with remote tools called “SKIDATA Remote Desktop Parking (RDP)” and “SKIDATA Remote Desktop Web Access”.



SKIDATA Remote Desktop Parking (RDP) – is a small client application which uses Microsoft Terminal Services technology with the highest encryption possible preconfigured. These pre-settings cannot be changed (FIPS140-2 / TLS1.1 or higher depending on the server version).

SKIDATA Remote Desktop Web Access – is a possibility to use the Microsoft Internet Explorer browser at a client PC to connect to the parking system remotely. This remote access option removes the need to install any additional remote access software on a customer’s client workstation. Microsoft Remote Desktop Web Access services with the highest encryption possible preconfigured is used by SKIDATA to connect to a web page located at the DAU of the parking system. The security pre-settings cannot be changed.

The remote connection to the parking system can be performed via LAN or WAN infrastructure. The tools mentioned above are utilizing the same parking system users and the same login mechanisms which are used on local Workstations. Only access to the SKIDATA application is possible, no administrative access on OS level.

Access via LAN or WAN The SKIDATA parking system is basically a closed network environment, thus the network security of the system outwards is in the sole responsibility of the customer. State of the art network security techniques like e.g. firewalls, hardware firewalls and VPN connections have to be implemented to comply with present PA DSS and PCI DSS requirements.

General Note per PA DSS requirement 10.2.3: When requesting support from a vendor, reseller, or integrator, customers are advised to take the following precautions:

• 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 (See PA-DSS

Requirements 3.1.1 through 3.1.11). • Enable encrypted data transmission according to PA-DSS Requirement 12.1. • Enable account lockout after a certain number of failed login attempts. (See PA-DSS

Requirement 3.1.8.) • Establish a VPN connection via a firewall before access is allowed. • Enable the logging function. • Restrict access to customer environments to authorized personnel.

5.12 PA DSS reference 11.0 - Encrypt sensitive traffic over public

networks.

5.12.1 PA DSS reference 11.1 - If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including at least the following:

Only trusted keys and certificates are accepted.



The protocol in use only supports secure versions or configurations The encryption strength is appropriate for the encryption methodology in use

Note: SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of SSL or early TLS. Applications that use or support TLS must not allow fallback to SSL.

Examples of open, public networks include but are not limited to:

• The Internet • Wireless technologies, including but not limited to 802.11 and Bluetooth • Cellular technologies, for example, Global System for Mobile Communications

(GSM), Code division multiple access (CDMA) • General Packet Radio Service (GPRS) • Satellite communications


SKIDATA: Application implementations implemented by customers and resellers/integrators which rely on public network for transaction transmissions have to observe the following requirements to safeguard cardholder data during transmission (this includes the Internet and Internet accessible DMZ network segments).

• Only strong cryptography and security protocols must be used if cardholder data is

ever transmitted over public networks (e.g., IPSEC, VPN or TLS). • Only trusted keys and/or certificates have to be accepted. • Use only secure versions and secure implementations of security protocols. • Use the proper encryption strength for the encryption methodology in use.

Refer to the dataflow diagrams of the different clearing methods in section 8.0

5.12.2 PA DSS reference 11.2 - If the payment application facilitates

sending of PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat), the payment application must provide a solution that renders the PAN unreadable or implements strong cryptography, or specify use of strong cryptography to encrypt the PANs.


SKIDATA: The SKIDATA application does not allow or facilitate the sending of PANs via any end user messaging technology (for example, e-mail, instant messaging, and chat).

5.13 PA DSS reference 12.0 - Secure all non-console administrative

access.

5.13.1 PA DSS reference 12.1 and 12.1.1 - If the payment application facilitates non-console administrative access, encrypt all such



access with strong cryptography. Instruct customers to encrypt all non-console administrative access with strong cryptography, for web-based management and other non- console administrative access.

Note: Clear-text protocols such as Telnet or rlogin must never be used for administrative access. SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of SSL or early TLS. Applications that use or support TLS must not allow fallback to SSL.


SKIDATA: Customers are responsible to choose and maintain the remote access administration software. There is no administrative remote access built into the SKIDATA application (only the remote access tools mentioned in section 5.12 that allows access to the SKIDATA application only, no administrative access on OS level possible). Although the SKIDATA application does not support non-console administration and SKIDATA does not recommend using non-console administration, should you ever choose to do this, you must use strong cryptography such as SSH, VPN, or TLS1.1 or higher for encryption of this non-console administrative access.

Note: The SKIDATA parking system is basically a closed network environment, thus the network security of the system outwards is in the sole responsibility of the customer. PCI requires that state of the art network security techniques like e.g. firewalls, hardware firewalls and VPN connections have to be implemented to comply with present PA DSS and PCI DSS requirements.

5.13.2 PA DSS reference 12.2 - Use multi-factor authentication for all

personnel with non-console administrative access.

Note: Multi-factor authentication requires at least two of the three authentication methods be used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication methods).


SKIDATA: Based on PA DSS 3.2 multi-factor authentication is required also for local non-console administrative access within or into the cardholder data environment (CDE). This means that also local access/connection to the parking system using the SKIDATA remote access tools “Remote Desktop Parking (RDP)” or “SKIDATA Remote Desktop Web Access” would require multi-factor authentication by default. These SKIDATA tools do not have any built-in multi factor authentication capabilities and always require additional and separate multi-factor authentication mechanisms (as described in chapter 5.11.1 for remote access from outside).

Therefore these SKIDATA tools cannot be used for local access/connection to the parking system any more (e.g. usage as local workstation)!



Independent if from local network inside or outside of the CDE. As an alternative normal SKIDATA workstation devices can be used. SKIDATA does not support any non-console administrative access within the local environment.

5.14 PA DSS reference 13 - Maintain a PA-DSS Implementation Guide

for customers, resellers, and integrators

5.14.1 PA DSS reference 13.1, 13.1.1, 13.1.2, 13.1.3 - Develop, maintain, and disseminate a PA DSS Implementation Guide(s) for customers, resellers, and integrators that accomplishes the following.

SKIDATA: This PA DSS Implementation Guide is reviewed on a yearly basis, whenever the underlying application changes or whenever the PA DSS requirements change. Updates are tracked accordingly and the current version is available on the SKIDATA member’s page within the repository section. Additionally the latest version will be distributed by the responsible persons in the local organizations to the customer.



6. Documentation and Training

6.1 Documentation General Documentation: SKIDATA provides all relevant product documentation on the member’s web page within the repository section. All Subsidiaries and Partner organizations have access to this information source and are told to provide these documents to the customers.

Release documentation: Documentation about new features, solved bugs, known bugs etc. are available with the release of a new version. These documents are also available with the SKIDATA repository.

Information about product availability: The schedule of the product availability e.g. for major versions, service packs, security packs etc. is available on the SKIDATA own Confluence Wiki page. All Subsidiaries and Partner organizations have access to this information source and are told to provide these information’s to their customers.

6.2 Training General Product Training: SKIDATA offers different kind of product training, depending on the audience. Subsequently some examples:

• Car Access Basic System Training • Car Access Advanced System Training • Car Access Hardware Training • Car Access Service & Repair • Car Access Basic Software Application Training • Car Access Advanced Software Application Training Release dependent (e.g. v08)

Specific Training: SKIDATA offers additionally specific detailed trainings for the different system interfaces like Transaction Interface, Host-com, License Plate Recognition interface etc.

SKIDATA offers also PCI related training. This training will cover the whole aspects of a PCI/PA-DSS compliant system. Subsequently some items of the training circumference:

• SKIDATA secure application configuration regarding PCI/PA DSS • The SKIDATA PA DSS Secure Implementation Guide • Network and system environment • Secure communication with the outside world

7. Typical SKIDATA parking system and CDE configuration



Typical SKIDATA parking system and CDE configuration

7.1 Seldom used Parking System Configurations Depending on the customer and the specific parking system solution there are the following additional configurations possible. These configurations differentiate from the typical above only in the location where the parking system database resides. The parking system database itself is always 100% the same independent of the location where it resides. This is also true for every communication with the database.

Additional Separate Server for the Database: The parking system database can be located on an additional database server hardware device (controlled by the parking system application) instead of the Data Administration Unit (DAU). The SKIDATA naming for this is “External SQL-Server”. See figure below.

Aquiring Bank / Payment Service

Provider

Authorization Server Software Components: Authorization Server Application

Firewall Parking System Cardholder Data Environment CDE

Manual Pay Station Software Components: Main Menu Application Pay Station Application Router

Ethernet Backbone

SQL Server Database

Data Administration Unit Software Components: Control Center Application Mobile Control Center App. Main Menu Application Entrance Column Control Process Exit Column Control Process Pay Station Application

Entrance Column & Barrier Exit Column & Barrier

Automatic Payment Machine Software Components:

Automatic Payment Machine Application

Entrance Column & Barrier Power.Gate & Barrier.Gate

Entrance Column & Barrier Power.Gate & Barrier.Gate



Database on Customer IT Environment: The parking system database can be located on a Microsoft SQL Database Server hardware (no SKIDATA device) that exists already in the customer’s IT environment because he might use Microsoft SQL Server technology already in his IT environment. In this configuration SKIDATA only gets the SQL Database Server location and the credentials to create and modify the database needed for the parking system. In this case the customer is responsible for maintenance, security and all other issues concerning the database server environment – also for PCI compliancy. The SKIDATA naming for this configuration is “Paged-Out SQL- Server”. See figure below.

Parking System Database at the customer‘s MS SQL


Provider

Database Server Hardware

Data Administration Unit

Manual.Cash

Firewall

Ethernet Backbone

Parking System Cardholder Data Environment CDE

Router Column.Gate

Automatic Payment Machine .Cash


Provider

Firewall Parking System Cardholder Data Environment CDE

Router

Ethernet Backbone

Data Administration Unit External SQL Server Manual.Cash

Column.Gate Automatic Payment Machine .Cash



7.2 Operating Systems and Database Systems supported The SKIDATA parking system application supports the following different operating system and database system configurations:

Data Administration Unit (DAU)

• Windows Server 2008 R2 Standard 64bit / SP1 • Windows Server 2012 R2 Standard 64bit / SP1 • Microsoft SQL Server 2008 R2 Standard 64bit / SP1 • Microsoft SQL Server 2012 Standard 64bit / SP1 • Microsoft SQL Server 2012 Express 64bit / SP1

Manual Pay Station (POS)

• Windows 7 Professional 32bit / 64bit SP1

Automated Payment Machines (APM or POF) • Windows 7 Embedded Standard 32bit

Lane Devices (Columns)

• Linux Untersberg built on Core Yoctoproject Krogoth 2.x • SKIDATA proprietary Oasis 5.x

Note: Parking.Logic V09 basically supports also Microsoft SQL Server 2014 but only in so called “paged-out” configurations (see 7.1 / Database on Customer IT Environment). This SQL server version is only used in rare cases and therefore not part of the V09 PA DSS validation. If needed this version has to be validated during the site acceptance test of the customer.

7.3 Network Segmentation The PCI DSS requires that firewall services be used to segment network segments into logical security domains based on the environmental needs for internet access. Traditionally, this corresponds to the creation of at least a DMZ and a trusted network segment where only authorized, business-justified traffic from the DMZ is allowed to connect to the trusted segment. No direct incoming internet traffic to the trusted application environment can be allowed. Additionally, outbound internet access from the trusted segment must be limited to required and justified ports and services.



8. Credit Card Clearing Methods – Data flow diagrams There are four different methods for credit card clearing within the parking system application which are described in detail subsequently.

• Real Time Authorization using Credit Card Authorization Server • Real Time Authorization with Credit Card Tokenization • Offline (Batch) Transaction using Encrypted Text File • Real Time Authorization using External Terminal

8.1 Real Time Authorization using Credit Card Authorization Server

8.1.1 Overview

The SKIDATA application allows credit cards to be inserted in a SKIDATA payment device for payment purposes. Examples of payment devices are Exit Columns, Transaction Panels, Manual Pay Stations (MPS) and Automated Payment machines (APM). When a credit card is swiped in one of the above units, it will read the credit card information and through a central authorization server send the credit card data to the acquirer for processing. Besides swiping the card the transaction can also be performed by manually entering the PAN. Credit Card refunds can also be done at the Manual Pay Stations which is manned by a cashier. Swiped transactions are that are captured at any of the SKIDATA payment devices are sent to the Credit Card Authorization Server Application through the internal or private network through a TCP/IP socket using the Credit Card Authorization Server Protocol. There are various Credit Card Authorization Server Applications that communicate to various credit card clearing houses.

8.1.2 Implementation Diagram



8.1.3 Cardholder Data Flow

The cardholder data is sent in the internal network from the Pay Stations (P/S), Exit Devices and Automated Payment Machines to the local Credit Card Authorization Server (using TLS1.1). From this server it is encrypted and sent to the Host processor network where it gets authorized and sent back to the internal network as an approval or rejection.

Data Flow Order of Events:

1. Credit card is read / swiped at the card reading device

2. Track data are sent to PC on which the

card reading device is connected to

3. Track data is sent from the PC to the local credit card authorization server (TLS1.1)

4. Track data is sent from the credit card authorization server to the acquiring bank / payment service provider utilizing secure communication methods (VPN/TLS1.1)

5. Authorization response is sent back to the parking system (TLS1.1). This includes only authorization code but no PAN or Track data

6. If transaction is granted then the PAN is stored within the central database

Note: No track data is stored at any time PAN is not stored if authentication fails

Automatic Payment Machine

or Manual Pay Station PC

Data Administration Unit PC

Credit Card Authorization

Server

Track 4

Data

TLS1.1

4

/ VPN

Aquiring Bank / Payment

Service Provider

Credit Card Reading Device 1 at Manual Pay Station or in


Credit Card Reading Device 1 at Exit Column

or Entrance Column

2 Track Data 2 Track Data

PAN PAN

6 6

5 3 DB 3 5

Track Data

5 5

5 5

Conf

irmat

ion

/ Rej

ectio

n

Conf

irmat

ion

/ Rej

ectio

n



8.2 Real Time Authorization with Credit Card Tokenization

8.2.1 Overview

The SKIDATA application allows credit cards to be inserted in a SKIDATA payment device for payment purposes. Examples of payment devices are Exit Columns, Transaction Panels, Manual Pay Stations (MPS) and Automated Payment s (APM). When a credit card is swiped in one of the above units, it will read the credit card information and through a central authorization server send the credit card data to the acquirer for processing. The acquirer will send a credit card token (reference number) back to the parking system. This token is stored and used within the parking system database. No credit card PAN is stored and used within the parking system database at all.

The advantage of this so called “low-risk-mode” is that the PAN will never be stored in the parking application database at all.

Besides swiping the card the transaction can also be performed by manually entering the PAN. Credit Card refunds can also be done at the Manual Pay Stations which is manned by a cashier. Swiped transactions are that are captured at any of the SKIDATA payment devices are sent to the Credit Card Authorization Server Application through the internal or private network through a TCP/IP socket using the Credit Card Authorization Server Protocol. Every time a card is swiped, the credit card data are sent to the acquirer for processing and a corresponding token is sent back to the application. No credit card PAN is stored within the parking system database at all.

There are various Credit Card Authorization Server Applications that communicate to various credit card clearing houses.





Getting the token Every time a credit card is swiped, the application has to start an inquiry to get the credit card token as there is no local link between token and credit card number within the parking system.

Once swiped, cardholder data is sent in the internal network from the Pay Stations (P/S), Entry, Exit Devices and Automated Payment Machines to the local credit card authorization server (using TLS1.1). From this server it is encrypted and sent to the Host Processor Network. The local credit card authorization server gets back a credit card token. No cardholder data are returned or stored within the parking system. The parking system is only storing and using the token within the database.

Data Flow Order of Events for getting Token:

1. Credit card is read / swiped at the card reading device.

2. Track data are sent to PC on which the card reading device is connected to.

3. Track data is sent from the PC to the credit

card authorization server (TLS1.1).

4. Track data is sent from the credit card authorization server to the acquiring bank / payment service provider utilizing secure communication methods (VPN/TLS1.1).

5. Authorization response is sent back to the parking system (TLS1.1). This includes only the Token but no PAN or Track data.

6. Token is stored within the central database.

Note: No track data or PAN is stored at any time.





Server

Track 4

Data

TLS1.1

4

/ VPN


Service Provider




or Entrance Column

2 Track Data 2 Track Data

Token Token

6 6

5 3 DB 3 5

Track Data

5 5

5 5

Toke

n

Toke

n



Performing payment Before performing a payment transaction, the credit card token has to be inquired online every time. After receiving the credit card token, the application is using this token to initiate payment.

The credit card token is sent in the internal network from the Pay Stations (P/S), Exit Devices and Automated Payment Machines to the local credit card authorization server (using TLS1.1). From this server it is encrypted and sent to the Host Processor Network where it gets authorized and sent back to the internal Network as an Approval or Rejection.

Again no cardholder data are returned or stored within the parking system. The parking system is only storing the token together with the payment transaction within the database.

Data Flow Order of Events for payment:

Before initiating payment, the credit card token will be inquired online every time. This procedure is decribed in the section above getting the Token .

The description below is only for the payment procedure. So precondition for this order of events is that the application has already received the credit card token for the card which has been swiped.

1. Token is sent from the PC to the credit card authorization server to initiate payment (TLS1.1).

2. Token is sent from the credit card authorization server to the acquiring bank / payment service provider utilizing secure communication methods (VPN/TLS1.1).

3. Authorization response is sent back to the parking system (TLS1.1). This includes only token and authorization code but no PAN or Track data.

4. If transaction is granted then the token is stored within the central database.

Note: No track data or PAN is stored at any time.





Server

Token 2

TLS1.1

2

/ VPN


Service Provider

Credit Card Reading Device at Manual Pay Station or in


Credit Card Reading Device at Exit Column

or Entrance Column

Token Token

4 4

3 1 DB 1 3

Token

3 3

3 3

Conf

irmat

ion

/ Rej

ectio

n

Conf

irmat

ion

/ Rej

ectio

n



8.3 Offline (Batch) Transaction using Encrypted Text File

8.3.1 Overview

In certain markets (predominantly Europe) Credit Card Transactions are still processed as a Batch File. The SKIDATA application allows the clearing of Credit Card Data by fully encrypting the clearing file. This encryption uses both Symmetric and Asymmetric Encryption algorithms (strong encryption methods which are PCI compliant like AES or Triple DES) and all encryption takes place in memory; no temporary unencrypted data is generated. The encrypted file contains PAN and sometimes also magnetic stripe data as this is still needed with some clearing formats in some countries (only pre-authorization). This encrypted file can be processed with the bank by transferring it using secure FTP after which the file will be deleted irretrievable.








The cardholder data is sent in the internal network from the Pay Stations (P/S), Exit Devices or Automated Payment Machines to the SKIDATA Data Administration Unit DAU. The SKIDATA application authorizes the credit card payment transaction and stores the data of the transaction securely within the central SQL database.

Once a day or on demand, the application generates an encrypted settlement file and processes it to the clearing bank by using secure FTP. Afterwards the file will be deleted irretrievable.



2 Track Data


or Entrance Column

2 Track Data

4


1. Credit card is read / swiped at the card reading device

2. Track data are sent to PC on which the card reading device is connected to

3. Track data and PAN is encrypted and stored within the central database.

Track Data & PAN Track Data & PAN 3 3

DB

Track Data deletion

4

Settlement Batch File deletion

6

4. Based on an automatic schedule or on demand the credit card settlement processs can be started. Out of the track data and PAN of the different payment transactions a batch settlement file will be created that is additionally encrypted utilizing a strong encryption method. After creation of the file all relevant Track data are deleted from the database. Only the PAN ist stored a dedicated period of time (default 62 days) and is then deleted automatically.

Secure FTP

Track Data 5

& PAN

5. The batch settlement file is then sent to the Acquiring bank / Payment service provider using Secure FTP.

6. After successful transmission the batch settlement file is deleted securely from the Data Administration Unit.

Acquiring Bank / Payment

Service Provider



8.4 Real Time Authorization using External Terminals

8.4.1 Overview

In order to deal with Chip&Pin and Debit Cards the SKIDATA application handles such transactions using certified Hardware. This hardware normally consists of an MSR (Magnetic Swipe Reader) and a Pin-pad. There is a wide range in the Hardware selection different from country to country.

8.4.2 Overview Diagram




The cardholder data is sent from the External Terminal directly to the Host Processor Network where it gets authorized and sent back to the internal Network as an Approval or Rejection. There is no communication between the SKIDATA application and the Terminal for the authorization procedure; this is solely done by the External Terminal itself.


1. Credit card is read / swiped at the external credit card terminal built into the Skidata devices (non Skidata terminal hardware PTS validated)

2. Track data is sent directly from the credit card terminal to the acquiring bank / payment service provider utilizing secure communication methods (as specified by PTS)

3. Authorization response is sent back from the acquiring bank / payment service provider to the credit card terminal. This includes only authorization code but no PAN or Track data

4. Authorization response, authorization code and optionally the PAN is sent to the parking system if the transaction is granted.

5. If the PAN is returned to the parking system it is stored encrypted within the database for a dedicated period of time (default 62 days) and is then deleted automatically. (this is optional and depends on the terminal type)

Note: No track data is stored at any time PAN is not stored if authentication fails




LS V


Service Provider

Credit Card Terminal (non Skidata) Credit Card Terminal (non Skidata) 1 at Manual Pay Station or in

Automatic Payment Machine 1 1 at Exit Column

or Entrance Column

4 4

3 3

PAN PAN 5 5

DB

2 Track Data Track Data 2

3 3

T 1.1 / PN

2

Conf

irmat

ion

/ Rej

ectio

n

Conf

irmat

ion

/ Rej

ectio

n



9. Maintain an Information Security Program 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 should 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 on-going 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 should complete annual self-assessments using the PCI Self-Assessment Questionnaire.

• Call in outside experts as needed.

10. References, Acknowledgments, License

10.1 References This document references the following publications.

1. PCI SSC / PCI version 3.2 2. PCI SSC / PA DSS version 3.2

SKIDATA Documentation:

1. SKIDATA PA DSS Software Development v08-0x.pdf (last actual version) 2. SKIDATA PA DSS Technical Guide v08-0x.pdf (last actual version) 3. JIRA1.0_Workflow_ProductRequest_v02-01.pdf 4. JIRA_Workflow_Feature_v02-01.pdf 5. JIRA_Workflow_Defect_v02-02.pdf 6. ReleaseNotes_21_00_xx.pdf (example) 7. 090717_APP_SW_4x0_Release_20_01_02.pdf (example) 8. SymantecEndpointProtection-1-3-en-ins.pdf 9. SKIDATA_IT-Security_Policy_English_v04-00.pdf 10. SKIDATA Secure Guidelines for Employees v08-0x.pdf (last actual version) 11. SKIDATA_Data_Security_Guideline_v01-04.pdf

10.2 Acknowledgments Windows is a registered trademark of Microsoft Corporation. All rights reserved. All other trademarks and copyrights are property of their respective owners. All rights reserved.



11. Appendix A – Sample Authorized Key Custodian Form All <Company> staff that hold responsible authorized positions where they manage or handle encryption keys must sign the following document. As a condition of continued employment with <Company>, and as an employee that has access to key management tools and equipment, you are obligated to sign the following to indicate acceptance of your responsibility.

The signatory of this document is in full employment with <Company> on the date shown below and has been afforded access to key management devices, software and equipment, and hereby agrees that, he or she

• Has read and understood the policies and procedures associated with key

management and agrees to comply with them to the best of his/her ability, and has been trained in security awareness and has had the ability to raise questions and has had those questions answered satisfactory.

• Understands that non-compliance with the key management procedures can lead to

disciplinary action including termination and prosecution. Exceptions to compliance only occur where such compliance would violate local, state, or federal law, or where a senior officer of the company or law enforcement officer has given prior authorization.

• Agrees to never divulge to any third party any key management or related security

systems, passwords, processes, security hardware or secrets associated with the <Company> systems, unless authorized by an officer of the <Company> or required to do so by law enforcement officers

• Agrees to report promptly and in full to the correct personnel, any suspicious activity

including but not limited to key compromise or suspected key compromise. Suspicious activity can include: signs of unauthorized equipment usage during evenings and weekends, phone requests from unidentifiable callers for access to secure information, unidentifiable files found on file servers, and unusual activity recorded in log files.

I agree to the above and understand that this original copy will be held on my personnel record and kept by the company indefinitely.

Signed: [ ] Witnessed:[ ]

Print Name: [ ] [ ]

Date: [ ]

SKIDATA Sales Documentation Package

Thank you for your interest in purchasing a SKIDATA Parking System. The following package contains a Software License Agreement.

October 2010

Page 1 of 5

Version License V1.3 2013

SKIDATA SOFTWARE LICENSE

The following terms govern your use of certain SKIDATA software that is being licensed to you by SKIDATA AG (“SKIDATA”), an

Austrian corporation, with an address of Untersbergstrasse 40 A-5083 Grödig/Salzburg Austria (SKIDATA and you are hereafter

collectively referred to as the “Parties,” each a “Party”). These terms also apply to any software updates, supplements and support

services that you may obtain from SKIDATA. By signing the document below, signing the acknowledgement that was sent with these

terms, or by using the software that is identified in the purchase order (“Software”) and further described in the Software Fact Sheet

you have accepted (“Fact Sheet”), you accept these terms and the Agreement as a whole. If you do not accept these terms, do not

use the Software.

In addition, the Parties acknowledge and agree that your obligations hereunder are in consideration of SKIDATA’s extension of the

right to you to use the Software as set forth within this Agreement, and you acknowledge the receipt, adequacy and legal sufficiency of

that consideration by SKIDATA.

THE LICENSE

You are granted a non-exclusive, non-transferable (unless authorized by SKIDATA which will not be unreasonably withheld),

conditionally revocable, limited license to use the Software in connection with SKIDATA products and systems for your business

activities as they have been described to SKIDATA (“License”) as follows: you may use one single copy and one back-up copy, which

is to be for solely back-up and/or archival purposes, of the Software at a single location (“Device”). You must purchase a sufficient

number of Software licenses corresponding to the number of Devices. The Software may only be used with compatible hardware and

software as identified in the respective Software Fact Sheet you have accepted that describes the software functionality and system

requirement (“Fact Sheet”).

While you may own the disk or other physical media upon which the Software is recorded or fixed, SKIDATA retains

ownership of the Software itself and all trademarks, copyrights, patent, trade secret, and other intellectual property proprietary rights

therein. Nothing herein shall provide you with any right, title or interest in the Software other than pursuant to the limited License being

granted. You promise not to do anything inconsistent with SKIDATA's ownership of the Software and shall not claim adversely to

SKIDATA, or assist any third-party in attempting to claim adversely to SKIDATA, such ownership.

TRANSACTIONS THROUGH AUTHORIZED DISTRIBUTOR

The License may be provided to you through one of SKIDATA’s authorized, third-party distributors (“Authorized

Distributor”). You acknowledge that you are not a third party beneficiary of any separate agreement between SKIDATA and the

Authorized Distributor with respect to the Software. You will make suitable arrangements directly with the Authorized Distributor for the

ordering and/or delivery of the Software.

Moreover, in the event that the License is obtained through an Authorized Distributor, you agree to pay the fee associated

with the license of the Software (“License Fee”) to that Authorized Distributor. Notwithstanding the foregoing, you agree to direct all

payments directly to SKIDATA upon SKIDATA’s written request.

License Fee

SKIDATA shall be entitled to receive from you a non-recurring or a recurring license fee for the granting of the license.

The amount of payment for such license fee is stipulated in a separate contract between the Parties. Unless otherwise agreed upon in

writing recurring license fee shall mean annual fee payable for one year in advance and are due upon the effective date of the

separate contract between the Parties.

SKIDATA is entitled to reasonably adjust recurring license fees annually. Any reimbursement of already paid license fees

or any adjustment of due license fees in case of termination is excluded.

Page 2 of 5


YOU RESPONSIBILITIES

You covenant and agree to comply strictly with all E.U. and U.S. export control laws and/or export or import regulations in

other countries that are applicable to the Software and obtain all licenses to export, re-export or import the Software.

You hereby grant to SKIDATA or any representative it authorizes, the right to examine your systems, computers, books,

records and accounts during normal business hours. Where such audit discloses that the permitted number of Devices is exceeded,

you will promptly pay SKIDATA the appropriate License Fee for the additional Devices.

You shall not sublicense, transfer any of the rights to the Software. This license is conditionally assignable as authorized by

SKIDATA which will not be unreasonably withheld.

You acknowledge that SKIDATA has invested and will continue to invest significant time and money in the development and

promotion of its products and services, which has and will continue to result in the generation of proprietary, confidential and/or trade

secret information and materials, tangible and intangible, which properly belong to SKIDATA, or as to which SKIDATA has the right to

utilize on a confidential basis. All such information that you learn relating to the Software shall be deemed confidential information. You

covenant and agree to perpetually hold all confidential information in strict confidence and in trust. You shall not use, or disclose to

any third parties, any confidential information other than as expressly permitted herein. You will not yourself, nor will you allow any

third party to: (a) reverse engineer, decompile, disassemble or otherwise reduce the Software to any human perceivable form; (b)

modify, adapt, translate or create derivative works based upon the Software, the written materials accompanying the Software, or any

part thereof; (c) combine the Software with any kind of open-source-software; (d) use or permit the Software to be used for or in a third

party product ; or (e) make or use any copies of the Software, even if the Software has been merged or included with other software,

or any accompanying materials for any purpose other than as provided in this Agreement. If you create a back-up copy in accordance

with the provisions herein, you shall (a) include all copyright notices and/or proprietary notices that are affixed to or appearing in the

original copy; and (b) shall provide SKIDATA with immediate written notice of the same.

Use of the Software may be subject to third party and regulatory requirements. It is solely your responsibility to determine

what of these apply to you and ensuring that you are complying with those requirements. Nevertheless, such third party requirements

include, without limitation, those set forth in the respective Distributor Proposal you accepted..

Your obligations under this section shall survive termination of this Agreement.

MAINTENANCE, UPDATES AND UPGRADES

SKIDATA may provide you with Software updates, including without limitation, any compatible hardware, service packs, hot

fixes, patches, installation, setup, and maintenance services as they become available, or as necessary to comply with applicable

laws, regulations and/or compliance requirements, including without limitation, security and operational standards issued by the ISO or

the PCI Security Standards Council, LLC (collectively, the “Updates”). SKIDATA may provide Updates to you, but shall not be

obligated to do so. Updates of the Software may be subject to changed system requirements and may require the installation of

preceding Updates, third party components and/or additional changed hardware. While nothing herein shall obligate you to install any

Updates, you acknowledge and agree that your failure or refusal to do so will be at YOUR OWN RISK. By not installing an Update,

you may risk the security and operation of your Software and related systems, and may violate third party licenses and/or legal

regulations and laws by not installing the Update. You may also void any warranties that have been offered on the systems with which

the Update-related Software is being utilized. SKIDATA shall not be liable for any loss relating to this, and you waive and release all of

the SKIDATA Parties (as defined below) from any and all damages that you may incur relating thereto.

In addition, SKIDATA or your Authorized Distributor may, from time to time, offer and/or provide you with upgrades to the

Software, including new releases or versions of the current or then-current Software (collectively, “Upgrades”), as they become

available. SKIDATA or the Authorized Distributor may charge additional fees for such Upgrades. As the purchase of such Upgrades is

not covered by this Agreement, the purchase of such Upgrades must first be agreed upon in separate agreements between SKIDATA

or your Authorized Distributor and you. Nothing herein shall obligate SKIDATA to provide you with any Upgrades. In addition, nothing

herein shall obligate you to install such Upgrades. Nevertheless, you acknowledge that, in accordance with the respective release

planning, older versions of the Software may not be supported after a certain period of time.

You acknowledge that SKIDATA is entitled to reduce or in further consequences abandon single software functionalities in

case of your non-payment of the recurring license fee.

Page 3 of 5


In the event of recurring license fees, no automatically renewal of the license period of single software functionalities is

agreed. You acknowledge that such renewal is solely in your scope of responsibilities. Although SKIDATA attempts to inform you

about the expiration of your license, you acknowledge that SKIDATA has no obligation to do so and that a lack of information does not

entitle you to any claims or remedies whatsoever.

You acknowledge that license models can change after an upgrade. Especially, but not limited to, SKIDATA may be entitled

to invoice recurring license fee instead of non-recurring license fees.

If SKIDATA does provide you with Updates or Upgrades without your agreement to purchase those Upgrades, this

Agreement shall be extended to them unless a newer version of this Agreement is applicable to such Upgrade or Update in which

case the newer version will be delivered to you and shall be binding upon you as it relates to that Upgrade or Update.

DISCLAIMER OF ALL WARRANTIES

THE SOFTWARE IS PROVIDED “AS IS.” SKIDATA SPECIFICALLY DISCLAIMS ANY AND ALL WARRANTIES AND/OR

CONDITIONS, EXPRESS OR IMPLIED, WITH RESPECT TO THE SOFTWARE AND ANY UPDATES AND/OR UPGRADES TO THE

SOFTWARE INCLUDING BUT NOT LIMITED TO ANY WARRANTY AS TO THE DESIGN, FUNTIONALITY OR UTILITY OF THE

SOFTWARE, UPDATES AND/OR UPGRADES, THAT THE SOFTWARE, UPDATES AND/OR UPGRADES WILL PERFORM IN

ACCORDANCE WITH THEIR SPECIFICATIONS AND THAT THE SOFTWARE, UPDATES AND/OR UPGRADES WILL OPERATE

UNINTERRUPTED OR ERROR-FREE. SKIDATA ALSO DISCLAIMS ANY AND ALL WARRANTIES OF MERCHANTIBILITY OR

FITNESS FOR A PARTICULAR PURPOSE, EVEN IF SKIDATA HAS BEEN INFORMED OF SUCH PURPOSE. NO AGENT, AFFILIATE

OR REPRESENTATIVE OF SKIDATA IS AUTHORIZED TO ALTER OR EXCEED THE WARRANTY OBLIGATIONS OF SKIDATA AS

SET FORTH HEREIN. FURTHERMORE, YOU SPECIFICALLY ACKNOWLEDGE AND AGREE THAT ANY AND ALL WARRANTIES

PROVIDED WITH RESPECT TO THE SOFTWARE, UPDATES AND/OR UPGRADES, IF ANY, ARE PROVIDED BY THE

DISTRIBUTOR, RESELLER AND/OR OTHER THIRD PARTY. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF

EXPRESS OR IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. IN THAT EVENT, SUCH

WARRANTIES ARE LIMITED IN DURATION TO THE MINIMUM AMOUNT OF TIME AS PERMITTED BY LAW FROM THE DATE OF

SHIPMENT OF THE SOFTWARE FROM SKIDATA. NO WARRANTIES APPLY AFTER THAT PERIOD.

LIMITATION OF LIABILITY

To the fullest extent permitted by law, in the event that SKIDATA (a) breaches this Agreement; (b) breaches any limited

warranty; (c) otherwise fails to perform in accordance with this Agreement; or (d) otherwise commits wrongdoing giving a cause of

action to you, whether directly or indirectly related to this Agreement, the sole liability of the SKIDATA Parties (as defined herein),

and your exclusive remedy, shall be limited to the amount equal to the License Fee you paid for the Software under this Agreement.

Moreover, this exclusive remedy shall only apply to Software which SKIDATA has actually delivered to you that you installed

pursuant to the directions for use of the Software. No other remedies shall be available to you of any nature whatsoever, whether for

Software delivered or undelivered. You acknowledge that you have a duty to mitigate any damages for which SKIDATA may be liable

that are under your direct or indirect control.

Except where specifically required by law, in no event shall the SKIDATA Parties be liable for any indirect, special, punitive,

exemplary, incidental and/or consequential damages of any kind (including, but not limited to, lost profits) whether based in contract,

tort, strict liability or otherwise which arises out of or is any way connected with any use of the Software or this Agreement including,

without limitation, any identification of, or referral to, any products sold or licensed hereunder, including, without limitation, Software, as

PCI SSC Approved, or the cancellation, revocation or suspension of any such approval.

TERM AND TERMINATION

This Agreement is effective until terminated. You may freely terminate this Agreement, which shall be effective upon written

notice to SKIDATA or your Authorized Distributor of the same. SKIDATA may terminate this Agreement, in the event that you are in

breach of the terms and conditions of this Agreement or any other agreement that you have with SKIDATA, your Authorized Distributor

or any of the other SKIDATA Parties (as defined below). Such termination shall be effective immediately upon issuing written notice to

you of the same. Immediately upon termination, you shall (a) immediately discontinue use of the Software; (b) destroy or return to

SKIDATA all copies of the Software in whatever form they exists, including all back-up copies; and (c) certify in writing to SKIDATA

within ten (10) days thereafter that all copies have been returned or destroyed. Immediately upon termination, all rights and licenses

granted to you hereunder shall immediately cease and terminate.

The non-payment of the recurring license fee may lead to a limitation of software functionalities and to a premature

expiration of the license term.

Page 4 of 5


DISPUTE RESOLUTION

The following shall apply if the Software was delivered to you in the United States of America:

The Parties may not institute a suit at law or equity regarding any dispute, whether directly or indirectly related or collateral to

this Agreement. All such claims or disputes, whether between or among the Parties, shall be submitted to binding arbitration under the

American Arbitration Association and its Commercial Arbitration Rules. Without limitation, any dispute over the arbitrability of a matter

shall be specifically reserved for the arbitrator to exclusively hear, and shall not be submitted to the court. However, notwithstanding the

foregoing, either prior to, during or after the arbitration process, any Party to this Agreement may institute a suit in equity for a

temporary injunction (a) to preserve the status quo; (b) to enjoin a breach or threatened breach of this Agreement; (c) to obtain specific

performance; (d) to compel the arbitration or further its purposes and/or enforce a settlement or award or such arbitration; and/or (e) for

any other equitable relief.

The Agreement shall be governed by the laws of the State of New Jersey. Each of the Parties hereby irrevocably consents

to submit to the exclusive jurisdiction in the state courts of New Jersey, Somerset County or, the United States District Court for the

District of New Jersey, Trenton Vicinage, if jurisdiction exists, for any action or proceeding in any court or before any governmental

authority for actions to compel the arbitration and actions to enforce its award. Moreover, the Parties acknowledge and agree that

arbitration shall take place in Somerset County, New Jersey.

The following shall apply if the Software was delivered to you in the European Union or any other country outside the United

States of America:

The Parties may not institute a suit at law or equity regarding any dispute, whether directly or indirectly related or collateral to

this Agreement. All such claims or disputes, whether between or among the Parties, shall be submitted to binding arbitration under the

International Chamber of Commerce, International Court of Arbitration. However, notwithstanding the foregoing, either prior to, during

or after the arbitration process, any Party to this Agreement may institute a suit in equity for a temporary injunction (a) to preserve the

status quo; (b) to enjoin a breach or threatened breach of this Agreement; (c) to obtain specific performance; (d) to compel the

arbitration or further its purposes and/or enforce a settlement or award or such arbitration; and/or (e) for any other equitable relief.

In the event that you have been provided with a translation of the English version of this Agreement, you agree that the

translation is being provided for your convenience only and that the English version of this Agreement will govern. Without limitation, if

there is any contradiction between what the English language version of this Agreement says and what a translation says, the English

language version shall take precedence.

INDEMNIFICATION

In the event of a claim against SKIDATA, its parent companies, subsidiaries, affiliates, other related entities and Authorized

Distributors and their respective, shareholders, members, directors, officers, employees, contractors, vendors, clients, manufacturers,

agents, attorneys and representatives (collectively, the “SKIDATA Parties”) by a third party relating, directly or indirectly, in whole or in

part, to your act or omission, you shall indemnify and hold the SKIDATA Parties harmless as to any claim or other liability for any act

or omission asserted against any of them. Your obligations under this section shall survive the termination of this Agreement.

MISCELLANEOUS

The Parties hereby acknowledge and agree that this Agreement is intended to be for the benefit of the SKIDATA Parties

(“Third Party Beneficiary”). In that regard, the Third Party Beneficiary shall have the same rights and remedies as those provided to

the signatories of this Agreement including, without limitation, the right to bring a suit at law or equity with respect to any remedy,

claim, liability, reimbursement and/or cause of action arising or relating to this Agreement.

You acknowledge that monetary relief would not be adequate remedy for your breach or threatened breach of this

Agreement. You therefore agree that in addition to other remedies available at law, in equity, or under this Agreement, SKIDATA shall

be entitled to obtain injunctive relief, without bond, to restrain such breach or threatened breach.

If this Agreement is breached by you, you agree to pay reasonable attorney fees and costs of the SKIDATA Parties, whether

or not resulting in institution of proceedings, directly or indirectly relating to the enforcement of this Agreement.

In the event of breach of this Agreement the breaching Party shall have Thirty (30) days to remedy said breach.

You acknowledge that this Agreement embodies the entire understanding between you and SKIDATA, and supersedes all

Page 5 of 5


prior agreements or understandings, written or oral. Neither this Agreement, nor its execution, has been induced by any reliance,

representation, stipulation, warranty or understanding of any kind other than those expressed herein. No course of dealing or failure by

either party to enforce any term hereof shall operate as a waiver. In the event any provision of this Agreement is deemed invalid the

balance of it shall remain in full force and effect. You covenant and agree to execute and deliver to SKIDATA any additional written

assurances and perform all further acts as may be requested by SKIDATA for the purpose of effectuating the intent of this Agreement.

This Agreement is binding on, and will inure to the benefit of, the named signatories and their respective legal representatives, heirs,

successors in interest and assigns. SKIDATA may freely assign its rights and obligations and/or subcontract or otherwise delegate

some or all of its obligations hereunder without advance notice to you. You may not assign or delegate any of your rights or obligations

under this Agreement except as otherwise provided herein. Any assignment in violation hereof shall be null and void. This Agreement is

not intended to be for the benefit of, and shall not be enforceable by any unaffiliated third party, except as may be specifically provided

herein. The recitals set forth above and the documents referred hereto are incorporated by reference.

You acknowledge that you have read this Agreement carefully, that you understand all of its terms, that you have had the

opportunity to review and discuss this Agreement with private independent legal counsel of your choosing, have not in any manner

relied upon SKIDATA’s legal counsel for legal advice, and are fully satisfied that you have read the Agreement thoroughly, and

acknowledge that it is in your best interest to enter into it. You also acknowledge having asked any questions desired and clarified the

meaning of all terms, if any, the meaning of which you are not sure.