PCI-Secure Standard Software

Product Information: PCI-Secure Software Standard Vendor

Implementation Guide for Viking Terminal 2.00

Specifications

Version: 2.0

1. Introduction and Scope

1.1 Introduction

The PCI-Secure Software Standard Vendor Implementation Guide
provides guidelines for implementing the software on the Viking
Terminal 2.00.

1.2 Software Security Framework (SSF)

The Software Security Framework (SSF) ensures the secure payment
application on the Viking Terminal 2.00.

1.3 Software Vendor Implementation Guide – Distribution and

Updates

This guide includes information on the distribution and updates
of the Software Vendor Implementation Guide for the Viking Terminal
2.00.

2. Secure Payment Application

2.1 Application S/W

The secure payment application software ensures secure
communication with the payment host and ECR.

2.1.1 Payment Host communication TCP/IP parameter setup

This section provides instructions for setting up the TCP/IP
parameters for communication with the payment host.

2.1.2 ECR communication

This section provides instructions for communication with the
ECR (Electronic Cash Register).

2.1.3 Communication to host via ECR

This section explains how to establish communication with the
payment host using the ECR.

2.2 Supported terminal hardware(s)

The secure payment application supports the Viking Terminal 2.00
hardware.

2.3 Security Policies

This section outlines the security policies that should be
followed when using the secure payment application.

3. Secure Remote Software Update

3.1 Merchant Applicability

This section provides information on the applicability of secure
remote software updates for merchants.

3.2 Acceptable Use Policy

This section outlines the acceptable use policy for secure
remote software updates.

3.3 Personal Firewall

Instructions for configuring the personal firewall to allow
secure remote software updates are provided in this section.

3.4 Remote Update Procedures

This section explains the procedures for conducting secure
remote software updates.

4. Secure Deletion of Sensitive Data and Protection of Stored

Cardholder Data

4.1 Merchant Applicability

This section provides information on the applicability of secure
deletion of sensitive data and protection of stored cardholder data
for merchants.

4.2 Secure Delete Instructions

Instructions for securely deleting sensitive data are provided
in this section.

4.3 Locations of Stored Cardholder Data

This section lists the locations where cardholder data is stored
and provides guidance on protecting it.

4.4 Deferred Authorization Transaction

This section explains the procedures for handling deferred
authorization transactions securely.

4.5 Troubleshooting Procedures

Instructions for troubleshooting issues related to secure
deletion and protection of stored cardholder data are provided in
this section.

4.6 PAN locations – Displayed or Printed

This section identifies the locations where PAN (Primary Account
Number) is displayed or printed and provides guidance on securing
it.

4.7 Prompt files

Instructions for managing prompt files securely are provided in
this section.

4.8 Key management

This section explains the key management procedures for ensuring
the security of stored cardholder data.

4.9 ’24 HR’ Reboot

Instructions for performing a ’24 HR’ reboot to ensure system
security are provided in this section.

4.10 Whitelisting

This section provides information on whitelisting and its
importance in maintaining system security.

5. Authentication and Access Controls

This section covers authentication and access control measures
to ensure the security of the system.

Frequently Asked Questions (FAQ)

Q: What is the purpose of the PCI-Secure Software Standard

Vendor Implementation Guide?

A: The guide provides guidelines for implementing secure payment
application software on the Viking Terminal 2.00.

Q: Which terminal hardware is supported by the secure payment

application?

A: The secure payment application supports the Viking Terminal
2.00 hardware.

Q: How can I securely delete sensitive data?

A: Instructions for securely deleting sensitive data are
provided in section 4.2 of the guide.

Q: What is the importance of whitelisting?

A: Whitelisting plays a crucial role in maintaining system
security by allowing only approved applications to run.

This content is classified as Internal
Nets Denmark A/S:
PCI-Secure Software Standard Software Vendor Implementation Guide for Viking terminal 2.00
Version 2.0
PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00 1 1

Contents

1. Introduction and Scope ……………………………………………………………………. 3

1.1

Introduction …………………………………………………………………………………. 3

1.2

Software Security Framework (SSF)…………………………………………………. 3

1.3

Software Vendor Implementation Guide – Distribution and Updates …… 3

2. Secure Payment Application……………………………………………………………… 4

2.1

Application S/W ……………………………………………………………………………. 4

2.1.1 Payment Host communication TCP/IP parameter setup …………………….. 4

2.1.2 ECR communication………………………………………………………………………. 5

2.1.3 Communication to host via ECR………………………………………………………. 5

2.2

Supported terminal hardware(s) …………………………………………………….. 6

2.3

Security Policies ……………………………………………………………………………. 7

3. Secure Remote Software Update ………………………………………………………. 8

3.1

Merchant Applicability…………………………………………………………………… 8

3.2

Acceptable Use Policy ……………………………………………………………………. 8

3.3

Personal Firewall…………………………………………………………………………… 8

3.4

Remote Update Procedures …………………………………………………………… 8

4. Secure Deletion of Sensitive Data and Protection of Stored Cardholder Data9

4.1

Merchant Applicability…………………………………………………………………… 9

4.2

Secure Delete Instructions……………………………………………………………… 9

4.3

Locations of Stored Cardholder Data……………………………………………….. 9

4.4

Deferred Authorization Transaction ………………………………………………. 10

4.5

Troubleshooting Procedures ………………………………………………………… 10

4.6

PAN locations – Displayed or Printed ……………………………………………… 10

4.7

Prompt files ……………………………………………………………………………….. 11

4.8

Key management ………………………………………………………………………… 11

4.9

`24 HR’ Reboot ……………………………………………………………………………. 12

4.10 Whitelisting ………………………………………………………………………………… 12

5. Authentication and Access Controls …………………………………………………. 13

5.1

Access Control ……………………………………………………………………………. 13

5.2

Password Controls ………………………………………………………………………. 15

6. Logging ……………………………………………………………………………………….. 15

6.1

Merchant Applicability…………………………………………………………………. 15

6.2

Configure Log Settings …………………………………………………………………. 15

6.3

Central Logging …………………………………………………………………………… 15

6.3.1 Enable trace Logging on terminal ………………………………………………………… 15

6.3.2 Send trace Logs to host ……………………………………………………………………… 15

6.3.3 Remote trace logging…………………………………………………………………………. 16

6.3.4 Remote error logging…………………………………………………………………………. 16

7. Wireless Networks ………………………………………………………………………… 16

7.1

Merchant Applicability…………………………………………………………………. 16

7.2

Recommended Wireless Configurations ………………………………………… 16

8. Network Segmentation ………………………………………………………………….. 17

8.1

Merchant Applicability…………………………………………………………………. 17

9. Remote Access ……………………………………………………………………………… 17

9.1

Merchant Applicability…………………………………………………………………. 17

Transmission of Sensitive data …………………………………………………….. 17

10.1 Transmission of Sensitive data ……………………………………………………… 17

10.2 Sharing Sensitive data to other software ……………………………………….. 17

10.3 Email and Sensitive data ………………………………………………………………. 17

10.4 Non-Console Administrative Access ………………………………………………. 17

Viking Versioning Methodology……………………………………………………. 18

Instructions about Secure Installation of Patches and Updates. …………. 18

Viking Release Updates ………………………………………………………………. 19

Not-Applicable requirements ………………………………………………………. 19

PCI Secure Software Standard Requirements Reference …………………… 23

Glossary of Terms ………………………………………………………………………. 24

Document Control ……………………………………………………………………… 25

2

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

1. Introduction and Scope
1.1 Introduction
The purpose of this PCI-Secure Software Standard Software Vendor Implementation Guide is to provide stakeholders with clear and thorough guidance on the secure implementation, configuration, and operation of the Viking software. The guide instructs Merchants on how to implement Nets’ Viking application into their environment in a PCI Secure Software Standard compliant manner. Although, it is not intended to be a complete installation guide. Viking application, if installed according to the guidelines documented here, should facilitate, and support a merchant’s PCI compliance.
1.2 Software Security Framework (SSF)
The PCI Software Security Framework (SSF) is a collection of standards and programs for the secure design and development of payment application software. The SSF replaces the Payment Application Data Security Standard (PA- DSS) with modern requirements that support a broader array of payment software types, technologies, and development methodologies. It provides vendors with security standards like PCI Secure Software Standard for developing and maintaining payment software so that it protects payment transactions and data, minimizes vulnerabilities, and defends against attacks.
1.3 Software Vendor Implementation Guide – Distribution and Updates
This PCI Secure Software Standard Software Vendor Implementation Guide should be disseminated to all relevant application users including merchants. It should be updated at least annually and after changes in the software. The annual review and update should include new software changes as well as changes in the Secure Software Standard.
Nets publishes information on the listed website if there are any updates in the implementation guide.
Website: https://support.nets.eu/
For Example: Nets PCI-Secure Software Standard Software Vendor Implementation Guide will be distributed to all customers, resellers, and integrators. Customers, Resellers, and Integrators will be notified from reviews and updates.
Updates to the PCI-Secure Software Standard Software Vendor Implementation Guide can be obtained by contacting Nets directly, as well.
This PCI-Secure Software Standard Software Vendor Implementation Guide references both the PCI-Secure Software Standard and PCI requirements. The following versions were referenced in this guide.
· PCI-Secure-Software-Standard-v1_2_1

3

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

2. Secure Payment Application
2.1 Application S/W
The Viking payment applications do not use any external software or hardware not belonging to the Viking embedded application. All S/W executables belonging to the Viking payment application are digitally signed with Tetra signing kit provided by Ingenico.
· The terminal communicates with the Nets Host using TCP/IP, either via Ethernet, GPRS, Wi-Fi, or via the PC-LAN running the POS application. Also, the terminal can communicate with the host via mobile with Wi-Fi or GPRS connectivity.
Viking terminals manage all the communication using Ingenico link layer component. This component is an application loaded in the terminal. The Link Layer can manage several communications at the same time using different peripherals (modem and serial port for example).
It currently supports the following protocols:
· Physical: RS232, internal modem, external modem (via RS232), USB, Ethernet, Wi-Fi, Bluetooth, GSM, GPRS, 3G and 4G.
· Data Link: SDLC, PPP. · Network: IP. · Transport: TCP.
The terminal always takes the initiative for establishing the communication towards the Nets Host. There is no TCP/IP server S/W in the terminal, and the terminal S/W is never responding to incoming calls.
When integrated with a POS application on a PC, the terminal can be set up to communicate via the PC-LAN running the POS application using RS232, USB, or Bluetooth. Still all functionality of the payment application is running in the terminal S/W.
The application protocol (and applied encryption) is transparent and independent of the type of communication.
2.2 Payment Host communication TCP/IP parameter setup

4

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

2.3 ECR communication
· RS232 Serial · USB Connection · TCP/IP parameter setup, also known as ECR over IP
· Host/ECR communication options in Viking Payment Application

· Nets Cloud ECR (Connect@Cloud) parameters configuration
2.4 Communication to host via ECR

Note: Refer “2.1.1- Payment Host communication TCP/IP parameter setup” for country specific TCP/IP ports.

5

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

2.5 Supported terminal hardware(s)
Viking payment application is supported on variety of PTS (PIN transaction security) validated Ingenico devices. The list of terminal hardware along with their PTS approval number is given below.

Tetra Terminal Types

Terminal hardware
Lane 3000

PTS

PTS approval

version number

5.x

4-30310

PTS Hardware Version
LAN30EA LAN30AA

Desk 3500

5.x

4-20321

DES35BB

Move 3500

5.x

4-20320

MOV35BB MOV35BC MOV35BQ MOV35BR

Link2500
Link2500 Self4000

4.x

4-30230

5.x

4-30326

5.x

4-30393

LIN25BA LIN25JA
LIN25BA LIN25JA SEL40BA

PTS Firmware Version
820547v01.xx 820561v01.xx 820376v01.xx 820376v02.xx 820549v01.xx 820555v01.xx 820556v01.xx 820565v01.xx 820547v01.xx 820376v01.xx 820376v02.xx 820547v01.xx 820549v01.xx 820555v01.xx 820556v01.xx 820565v01.xx 820547v01.xx 820565v01.xx 820548v02.xx 820555v01.xx 820556v01.xx 820547v01.xx
820547v01.xx
820547v01.xx

6

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

2.6 Security Policies
Viking payment application adheres to all the applicable security policies specified by Ingenico. For general information, these are the links to the security policies for different Tetra terminals:

Terminal Type
Link2500 (v4)

Security Policy document Link/2500 PCI PTS Security Policy (pcisecuritystandards.org)

Link2500 (v5)

PCI PTS Security Policy (pcisecuritystandards.org)

Desk3500

https://listings.pcisecuritystandards.org/ptsdocs/4-20321ICO- OPE-04972-ENV12_PCI_PTS_Security_Policy_Desk_3200_Desk_3500-1650663092.33407.pdf

Move3500

https://listings.pcisecuritystandards.org/ptsdocs/4-20320ICO- OPE-04848-ENV11_PCI_PTS_Security_Policy_Move_3500-1647635765.37606.pdf

Lane3000

https://listings.pcisecuritystandards.org/ptsdocs/4-30310SP_ICO- OPE-04818-ENV16_PCI_PTS_Security_Policy_Lane_3000-1648830172.34526.pdf

Self4000

Self/4000 PCI PTS Security Policy (pcisecuritystandards.org)

7

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

3. Secure Remote Software Update
3.1 Merchant Applicability
Nets securely delivers Viking payment application updates remotely. These updates occur on the same communication channel as the secure payment transactions, and the merchant is not required to make any changes to this communication path for compliance.
For general information, merchants should develop an acceptable use policy for critical employee-facing technologies, per the guidelines below for VPN, or other high-speed connections, updates are received through a firewall or personal firewall.
3.2 Acceptable Use Policy
The merchant should develop usage policies for critical employee-facing technologies, like modems and wireless devices. These usage policies should include:
· Explicit management approval for use. · Authentication for use. · A list of all devices and personnel with access. · Labelling the devices with owner. · Contact information and purpose. · Acceptable uses of the technology. · Acceptable network locations for the technologies. · A list of company approved products. · Allowing use of modems for vendors only when needed and deactivation after use. · Prohibition of storage of cardholder data onto local media when remotely connected.
3.3 Personal Firewall
Any “always-on” connections from a computer to a VPN or other high-speed connection should be secured by using a personal firewall product. The firewall is configured by the organization to meet specific standards and not alterable by the employee.
3.4 Remote Update Procedures
There are two ways to trigger the terminal to contact the Nets software center for updates:
1. Either manually via a menu option in the terminal (swipe merchant card, select menu 8 “Software”, 1 “Fetch software”), or Host initiated.
2. Using the Host initiated method; the terminal automatically receives a command from the Host after it has performed a financial transaction. The command tells the terminal to contact the Nets software centre to check for updates.
After a successful software update, a terminal with a built-in printer will print a receipt with information on the new version.
Terminal integrators, partners and/or Nets technical support team will have the responsibility of informing merchants of the update, including the link to the updated implementation guide and the release notes.
In addition to receipt after software update, Viking payment application can be also validated via Terminal Info on pressing `F3′ key on the terminal.

8

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

4. Secure Deletion of Sensitive Data and Protection of Stored Cardholder Data

4.1 Merchant Applicability
Viking payment application does not store any magnetic stripe data, card validation values or codes, PINs or PIN block data, cryptographic key material, or cryptograms from its previous versions.
To be PCI compliant, a merchant must have a data-retention policy which defines how long cardholder data will be kept. Viking payment application does retain cardholder data and/or sensitive authentication data of the very last transaction and in case if there are offline or deferred authorization transactions while adhering to the PCI-Secure Software Standard compliance at the same time, hence it can be exempt from the merchant’s cardholder data- retention policy.
4.2 Secure Delete Instructions
The terminal does not store sensitive authentication data; full track2, CVC, CVV or PIN, neither before nor after authorization; except for Deferred Authorization transactions in which case encrypted sensitive authentication data (full track2 data) is stored until authorization is done. Post authorization the data is deleted securely.
Any instance of prohibited historical data that exists in a terminal will be automatically deleted securely when the terminal Viking payment application is upgraded. Deletion of prohibited historical data and data that is past retention policy will happen automatically.
4.3 Locations of Stored Cardholder Data
Cardholder data is stored in the Flash DFS (Data File System) of the terminal. The data is not directly accessible by the merchant.

Data Store (file, table, etc.)

Cardholder Data Elements stored (PAN, expiry, any elements of SAD)

How data store is secured (for example, encryption, access controls, truncation, etc.)

File: trans.rsd

PAN, Expiry Date, Service Code

PAN: Encrypted 3DES-DUKPT (112 bits)

File: storefwd.rsd PAN, Expiry Date, Service Code

PAN: Encrypted 3DES-DUKPT (112 bits)

File: transoff.rsd PAN, Expiry Date, Service Code

PAN: Encrypted 3DES-DUKPT (112 bits)

File: transorr.rsd Truncated PAN

Truncated (First 6, Last 4)

File: offlrep.dat

Truncated PAN

Truncated (First 6, Last 4)

File: defauth.rsd PAN, Expiry Date, Service Code

PAN: Encrypted 3DES-DUKPT (112 bits)

File: defauth.rsd Full track2 data

Full Track2 data: pre-Encrypted 3DES-DUKPT (112 bits)

9

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

4.4 Deferred Authorization Transaction
Deferred Authorization occurs when a merchant cannot complete an authorization at the time of the transaction with the cardholder due to connectivity, systems issues, or other limitations, and then later completes the authorization when it is able to do so.
That means that a deferred authorization occurs when an online authorization is performed after the card is no longer available. As the online authorization of deferred authorization transactions are delayed, the transactions will be stored on terminal until the transactions are successfully authorized later when network is available.
The transactions are stored and sent later to the host, like how the Offline transactions are stored as of today in Viking payment application.
Merchant can initiate the transaction as `Deferred Authorization’ from the Electronic Cash Register (ECR) or via terminal menu.
Deferred Authorization transactions can be uploaded to the Nets host by merchant using below options: 1. ECR – Admin command – Send offline (0x3138) 2. Terminal – Merchant ->2 EOT -> 2 sent to host
4.5 Troubleshooting Procedures
Nets support will not request sensitive authentication or cardholder data for troubleshooting purposes. Viking payment application is not capable of collecting or troubleshooting the sensitive data in any case.
4.6 PAN locations – Displayed or Printed
Masked PAN:
· Financial Transaction receipts: Masked PAN is always printed on the transaction receipt for both cardholder and merchant. The masked PAN in most of the cases is with * where first 6 digits and last 4 digits are in clear text.
· Transaction list report: Transaction list report shows the transactions performed in a session. Transaction details include Masked PAN, Card issuer name and the transaction amount.
· Last customer receipt: The copy of last customer receipt can be generated from terminal copy menu. The customer receipt contains the masked PAN as the original customer receipt. The given function is used in case if terminal fails to generate a customer receipt during the transaction for any reason.
Encrypted PAN:
· Offline transaction receipt: Retailer receipt version of offline transaction includes Triple DES 112-bit DUKPT encrypted cardholder data (PAN, Expiry date and Service code).
BAX: 71448400-714484 12/08/2022 10:39
Visa Contactless ****3439-0 107A47458AE773F3A84DF977 553E3D93FFFF9876543210E0 15F3 AID: A0000000031010 TVR: 0000000000 StoreID: 123461 Ref.: 000004 000000 KC3

10

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

Resp.: Y1 Session: 782

PURCHASE

NOK

12,00

APPROVED

RETAILER COPY

Confirmation:
Viking payment application always encrypts the cardholder data by default for offline transaction storage, transmission towards NETS host and to print encrypted card data on the retailer receipt for an offline transaction.
Also, to display or to print the card PAN, Viking payment application always masks the PAN digits with asterisk `*’ with First 6 + Last 4 digits in clear as default. The card number print format is controlled by terminal management system where print format can be changed by requesting through proper channel and by presenting a business legitimate need, however for Viking payment application, there isn’t any such case.
Example for masked PAN: PAN: 957852181428133823-2
Minimum info: **3823-2
Maximum info: 957852****3823-2
4.7 Prompt files
Viking payment application do not provide any separate prompt files.
Viking payment application requests for cardholder inputs through display prompts which are part of the messaging system within the signed Viking payment application.
Display prompts for PIN, amount, etc. are shown on the terminal, and cardholder inputs are awaited. The inputs received from cardholder are not stored.
4.8 Key management
For the Tetra range of terminal models, all security functionality is performed in a secure area of a PTS device protected from the payment application.
Encryption is performed within the secure area while decryption of the encrypted data can only be performed by the Nets Host systems. All key exchange between Nets host, Key/Inject tool (for Tetra terminals) and the PED are done in encrypted form.
Procedures for Key Management are implemented by Nets according to a DUKPT scheme using 3DES encryption.
All keys and key components used by Nets terminals are generated using approved random or pseudorandom processes. Keys and key components used by Nets terminals are generated by Nets key management system, which use approved Thales Payshield HSM units to generate cryptographic keys.

11

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

The key management is independent of the payment functionality. Loading a new application therefore does not require a change to the key functionality. The terminal key space will support around 2,097,152 transactions. When the key space is exhausted, Viking terminal stops working and shows an error message, and then the terminal must be replaced.
4.9 24 HR’ Reboot All Viking terminals are PCI-PTS 4.x and above and hence follows the compliance requirement that PCI-PTS 4.x terminal shall reboot minimum once every 24 hours to wipe the RAM and further secure terminal HW from being used to get hold of payment card data. Another benefit of the24hr’ re-boot cycle is that memory leaks will be mitigated and have less impact for the merchant (not that we should accept memory leak issues.
Merchant can set the reboot time from the terminal Menu option to Reboot Time’. The reboot time is set based on24hr’ clock and will take the format HH:MM.
The Reset mechanism is designed to ensure a terminal reset at least one time per 24 hours running. To fulfil this requirement a time slot, called the “reset interval” represented by Tmin and Tmax has been defined. This period represents the time interval where the reset is allowed. Depending on the business case, the “reset interval” is customized during the terminal installation phase. By design, this period cannot be shorter than 30 minutes. During this period, the reset occurs each day 5 minutes earlier (on T3) as explained by the diagram below:

4.10 Whitelisting
Whitelisting is a procedure to determine that the PANs listed as a whitelist are allowed to be shown in clear text. Viking uses 3 fields for determining the whitelisted PANs which are read from the configurations downloaded from the terminal management system.
When a Compliance flag’ in Nets host is set to Y, the information from the Nets Host or Terminal management system is downloaded to the terminal, when the terminal starts. This Compliance flag is being used for determining the whitelisted PANs which are read from the dataset. Track2ECR’ flag determines whether the Track2 data is allowed to be handled(sent/received) by the ECR for a specified issuer. Depending on the value of this flag, it is determined if the track2 data should be shown in local mode on ECR.
`Print format field’ determines how the PAN will be displayed. The cards in PCI scope will all have the print format set to display the PAN in truncated/masked form.

12

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

5. Authentication and Access Controls
5.1 Access Control
The Viking payment application does not have user accounts or corresponding passwords therefore, the Viking payment application is exempt from this requirement.
· ECR Integrated setup: It is not possible to access transaction types such as Refund, Deposit and Reversal from terminal menu to make these functions secure from getting misused. These are the transaction types where money flow occurs from merchant’s account to cardholder’s account. It is the merchant’s responsibility to ensure that ECR is used only by authorized users.
· Standalone setup: Merchant card access control is default enabled to access transaction types such as Refund, Deposit and Reversal from terminal menu to make these functions secure from getting misused. The Viking terminal is configured by default to secure the menu options, to prevent unauthorized access. The parameters to configure the menu security falls under Merchant Menu (accessible with a Merchant card) -> Parameters -> Security
Protect menu ­ Set to `Yes’ by default. Menu button on the terminal is protected using the Protect menu configuration. Menu can be accessed only by the Merchant using a merchant card.

13

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

Protect reversal ­ Set to Yes’ by default. Reversal of a transaction can only be done by the merchant using the merchant card to access the reversal menu. Protect reconciliation ­ Set toYes’ by default Option for Reconciliation can be accessed only by the merchant with the merchant card when this protection is set to true.
Protect Shortcut ­ Set to `Yes’ by default Shortcut menu with the options for viewing Terminal Info and option for updating Bluetooth parameters will be available to the merchant only when merchant card is swiped.

14

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

5.2 Password Controls
The Viking payment application does not have user accounts or corresponding passwords; therefore, the Viking application is exempt from this requirement.
6. Logging
6.1 Merchant Applicability
Currently, for Nets Viking payment application, there is no end-user, configurable PCI log settings.
6.2 Configure Log Settings
The Viking payment application does not have user accounts, so PCI compliant logging is not applicable. Even in the most verbose transaction logging the Viking payment application does not log any sensitive authentication data or cardholder data.
6.3 Central Logging
The terminal has a generic log mechanism. The mechanism also includes logging of creation and deletion of S/W executable.
S/W download activities are logged and can be transferred to Host manually via a menu-choice in the terminal or on request from host flagged in ordinary transaction traffic. If S/W download activation fails due to invalid digital signatures on the received files, the incident is logged and transferred to Host automatically and immediately.
6.4 6.3.1 Enable trace Logging on terminal
To enable trace logging:
1 Swipe Merchant card. 2 Then in the menu select “9 System menu”. 3 Then go to menu “2 System Log”. 4 Type in the technician code, which you can get by calling Nets Merchant Service support. 5 Select “8 Parameters”. 6 Then enable “Logging” to “Yes”.
6.5 6.3.2 Send trace Logs to host
To send trace logs:
1 Press Menu key on the terminal and then Swipe Merchant card. 2 Then in the main menu select “7 Operator menu”. 3 Then select “5 Send Trace Logs” to send trace logs to host.

15

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

6.6 6.3.3 Remote trace logging
A parameter is set in the Nets Host (PSP) which will enable/disable Terminal’s trace logging functionality remotely. Nets Host will send Trace enable/disable logging parameter to Terminal in Data set along with the scheduled time when Terminal will upload Trace logs. When terminal receives Trace parameter as enabled, it would start capturing Trace logs and at the scheduled time it will upload all trace logs and disable the logging functionality thereafter.
6.7 6.3.4 Remote error logging
Error logs are always enabled on the terminal. Like trace logging, a parameter is set in the Nets Host which will enable/disable Terminal’s error logging functionality remotely. Nets Host will send Trace enable/disable logging parameter to Terminal in Data set along with the scheduled time when Terminal will upload Error logs. When terminal receives Error logging parameter as enabled, it would start capturing Error logs and at the scheduled time it will upload all error logs and disable the logging functionality thereafter.
7. Wireless Networks
7.1 Merchant Applicability
Viking payment terminal – MOVE 3500 and Link2500 have the capability to connect with Wi-Fi network. Therefore, for Wireless to be implemented securely, consideration should be taken when installing and configuring the wireless network as detailed below.
7.2 Recommended Wireless Configurations
There are many considerations and steps to take when configuring wireless networks that are connected to the internal network.
At a minimum, the following settings and configurations must be in place:
· All wireless networks must be segmented using a firewall; if connections between the wireless network and the cardholder data environment are required the access must be controlled and secured by the firewall.
· Change the default SSID and disable SSID broadcast · Change default passwords both for wireless connections and wireless access points, this includes con-
sole access as well as SNMP community strings · Change any other security defaults provided or set by the vendor · Ensure that wireless access points are updated to the latest firmware · Only use WPA or WPA2 with strong keys, WEP is prohibited and must never be used · Change WPA/WPA2 keys at installation as well as on a regular basis and whenever a person with
knowledge of the keys leaves the company

16

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

8. Network Segmentation
8.1 Merchant Applicability
The Viking payment application is not a server-based payment application and resides on a terminal. For this reason, the payment application does not require any adjustment to meet this requirement. For the merchant’s general knowledge, credit card data cannot be stored on systems directly connected to the Internet. For example, web servers and database servers should not be installed on the same server. A demilitarized zone (DMZ) must be set up to segment the network so that only machines on the DMZ are Internet accessible.
9. Remote Access
9.1 Merchant Applicability
Viking payment application cannot be accessed remotely. Remote support only occurs between a Nets support staff member and the merchant over the phone or by Nets directly onsite with the merchant.
10.Transmission of Sensitive data
10.1 Transmission of Sensitive data
Viking payment application secures sensitive data and/or cardholder data in transit by using message-level encryption using 3DES-DUKPT (112 bits) for all transmission (including public networks). Security Protocols for IP communications from the Viking application to the Host is not required since message-level encryption is implemented using 3DES-DUKPT (112-bits) as described above. This encryption scheme ensures that even if transactions are intercepted, they cannot be modified or compromised in any way if 3DES-DUKPT (112-bits) remains considered as strong encryption. As per the DUKPT key management scheme, the 3DES key used is unique to each transaction.
10.2 Sharing Sensitive data to other software
The Viking payment application does not provide any logical interface(s)/APIs to enable the sharing of cleartext account data directly with other software. No sensitive data or cleartext account data is shared with other software through exposed APIs.
10.3 Email and Sensitive data
Viking payment application does not natively support the sending of email.
10.4 Non-Console Administrative Access
Viking does not support non-Console administrative access. However, for the merchant’s general knowledge, non-Console administrative access must use either SSH, VPN, or TLS for encryption of all non-console administrative access to servers in cardholder data environment. Telnet or other non- encrypted access methods must not be used.

17

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

11. Viking Versioning Methodology
The Nets versioning methodology consists of a two-part S/W version number: a.bb
where a’ will be incremented when high impact changes are done as per PCI- Secure Software Standard. a – major version (1 digit) bb’ will be incremented when low impact planned changes are done as per PCI- Secure Software Standard. bb – minor version (2 digits)
The Viking payment application S/W version number is shown like this on the terminal screen when the terminal is powered up: `abb’
· An update from e.g., 1.00 to 2.00 is a significant functional update. It may include changes with impact on security or PCI Secure Software Standard requirements.
· An update from e.g., 1.00 to 1.01 is a non-significant functional update. It may not include changes with impact on security or PCI Secure Software Standard requirements.
All changes are represented in sequential numeric order.
12. Instructions about Secure Installation of Patches and Updates.
Nets securely deliver remote payment applications updates. These updates occur on the same communication channel as the secure payment transactions, and the merchant is not required to make any changes to this communication path for compliance.
When there is a patch, Nets will update the patch version on Nets Host. Merchant would get the patches through automated S/W download request, or the merchant can also initiate a software download from the terminal menu.
For general information, merchants should develop an acceptable use policy for critical employee-facing technologies, per the guidelines below for VPN or other high-speed connections, updates are received through a firewall or personnel firewall.
The Nets host is available either via internet using secure access or via a closed network. With closed network, the network provider has a direct connection to our host environment offered from their network provider. The terminals are managed through Nets terminal management services. The terminal management service defines for example the region the terminal belongs to and the acquirer in use. Terminal management is also responsible for upgrading terminal software remotely over the network. Nets ensure that the software uploaded to the terminal has completed the required certifications.
Nets recommend check points to all its customers to ensure safe and secure payments as listed below: 1. Keep a list of all operational payment terminals and take pictures from all dimensions so you know what they are supposed to look like. 2. Look for obvious signs of tampering such as broken seals over access cover plates or screws, odd or different cabling or a new hardware device that you can’t recognize. 3. Protect your terminals from customer’s reach when not in use. Inspect your payment terminals on daily basis and other devices which can read payment cards. 4. You must check identity of repair personnel if you are expecting any payment terminal repairs. 5. Call Nets or your bank immediately if you suspect any unobvious activity. 6. If you believe that your POS device is vulnerable to theft, then there are service cradles and secure harnesses and tethers available to purchase commercially. It may be worth considering their use.

18

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

13.Viking Release Updates
The Viking software is released in the following release cycles (subject to changes):
· 2 major releases annually · 2 minor releases annually · Software patches, as and when required, (for e.g. due to any critical bug/vulnerability issue). If a
release is operational in field and some critical issue(s) are reported, then a software patch with the fix is expected to be released within one months’ time.
Merchants would be notified about the releases (major/minor/patch) through emails that would be directly sent to their respective email addresses. The email will also contain the major highlights of the release and release notes.
The merchants can also access the release notes which will be uploaded at:
Software release notes (nets.eu)
Viking Software releases are signed using Ingenico’s singing tool for Tetra terminals. Only signed software can be loaded onto the terminal.

14. Not-Applicable requirements
This section holds a list of requirements in the PCI-Secure Software Standard that has been assessed as `NotApplicable’ to the Viking payment application and the justification for this.

PCI Secure Software Standard
CO

Activity

Justification for being `Not-applicable’

5.3

Authentication methods (including session cre- Viking payment application runs on PCI approved PTS POI

dentials) are sufficiently strong and robust to device.

protect authentication credentials from being

forged, spoofed, leaked, guessed, or circum- Viking payment application does not offer local, non-console

vented.

or remote access, nor level of privileges, thus there is no au-

thentication credentials in the PTS POI device.

Viking payment application does not provide settings to manage or generate user IDs and does not provide any local, non-console or remote access to critical assets (even for debug purposes).

5.4

By default, all access to critical assets is re-

Viking payment application runs on PCI approved PTS POI

stricted to only those accounts and ser vices device.

that require such access.

Viking payment application does not provide settings to

manage or generate accounts or services.

7.3

All random numbers used by the software are Viking payment application does not use any RNG (random

generated using only approved random num- number generator) for its encryption functions.

ber generation (RNG) algorithms or libraries.

19

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

Approved RNG algorithms or libraries are those that meet industry standards for sufficient unpredictability (e.g., NIST Special Publication 800-22).

Viking payment application does not generate nor use any random numbers for cryptographic functions.

7.4

Random values have entropy that meets the Viking payment application does not use any RNG (random

minimum effective strength requirements of number generator) for its encryption functions.

the cryptographic primitives and keys that rely

on them.

Viking payment application does not generate nor use any

random numbers for cryptographic functions.

8.1

All access attempts and usage of critical assets Viking payment application runs on PCI approved PTS POI

is tracked and traceable to a unique individual. devices, where all critical asset handling happens, and the

PTS POI firmware ensure confidentiality and integrity of sen-

sitive data while stored within the PTS POI device.

Viking payment application’s sensitive function’s confidentiality, integrity and resiliency are protected and provided by the PTS POI firmware. The PTS POI firmware prevents any access to critical assets out of the terminal and relies on anti-tampering features.

Viking payment application does not offer local, non-console or remote access, nor level of privileges, thus there is no person or other systems with access to critical assets, only Viking payment application is able to handle critical assets

8.2

All activity is captured in sufficient and neces- Viking payment application runs on PCI approved PTS POI

sary detail to accurately describe what specific devices.

activities were performed, who performed

them, the time they were performed, and

Viking payment application does not offer local, non-console

which critical assets were impacted.

or remote access, nor level of privileges, thus there is no

person or other systems with access to critical assets, only

Viking payment application is able to handle critical assets.

· Viking payment application does not provide privilege modes of operation.

· There are no functions to disable encryption of sensitive data

· There are no functions for the decryption of sensitive data

· There are no functions for exporting sensitive data to other systems or processes

· There are no authentication features supported

Security controls and security functionality cannot be disabled nor deleted.

8.3

The software supports secure retention of de- Viking payment application runs on PCI approved PTS POI

tailed activity records.

devices.

20

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

8.4 B.1.3

Viking payment application does not offer local, non-console or remote access, nor level of privileges, thus there is no person or other systems with access to critical assets, only Viking payment application is able to handle critical assets.
· Viking payment application does not provide privilege modes of operation.
· There are no functions to disable encryption of sensitive data
· There are no functions for the decryption of sensitive data
· There are no functions for exporting sensitive data to other systems or processes
· There are no authentication features supported
Security controls and security functionality cannot be disabled nor deleted.

The software handles failures in activity-tracking mechanisms such that the integrity of existing activity records is preserved.

Viking payment application runs on PCI approved PTS POI devices.
Viking payment application does not offer local, non-console or remote access, nor level of privileges, thus there is no person or other systems with access to critical assets, only Viking application is able to handle critical assets.

· Viking payment application does not provide privilege modes of operation.

· There are no functions to disable encryption of sensitive data

· There are no functions for the decryption of sensitive data

· There are no functions for exporting sensitive data to other systems or processes

· There are no authentication features supported

· Security controls and security functionality cannot be disabled nor deleted.

The software vendor maintains documentation that describes all configurable options that can affect the security of sensitive data.

Viking payment application runs on PCI approved PTS POI devices.
Viking payment application does not provide any of the following to the end users:

· configurable option to access to sensitive data

21

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

B.2.4 B.2.9 B.5.1.5

· configurable option to modify mechanisms to protect sensitive data
· remote access to the application
· remote updates of the application
· configurable option to modify default settings of the application

The software uses only the random number generation function(s) included in the payment terminal’s PTS device evaluation for all cryptographic operations involving sensitive data or sensitive functions where random values are required and does not implement its own

Viking does not use any RNG (random number generator) for its encryption functions.
Viking application does not generate nor use any random numbers for cryptographic functions.

random number generation function(s).

The integrity of software prompt files is protected in accordance with Control Objective B.2.8.

All prompt displays on the Viking terminal are encoded in the application and no prompt files are present outside the application.
No prompt files outside the Viking payment application exist, all necessary information is generated by the application.

Implementation guidance includes instructions for stakeholders to cryptographically sign all prompt files.

All prompts display on the Viking terminal are encoded in the application and no prompt files are present outside the application.

No prompt files outside the Viking payment application exist, all necessary information is generated by the application

22

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

15. PCI Secure Software Standard Requirements Reference

Chapters in this document 2. Secure Payment Application

PCI Secure Software Standard Requirements
B.2.1 6.1 12.1 12.1.b

PCI DSS requirements
2.2.3

3. Secure Remote Software

11.1

Updates

11.2

12.1

1&12.3.9 2, 8, & 10

4. Secure Deletion of Sensitive Data and Protection of Stored Cardholder Data

3.2 3.4 3.5 A.2.1 A.2.3 B.1.2a

Authentication and Access Controls 5.1 5.2 5.3 5.4

3.2 3.2 3.1 3.3 3.4 3.5 3.6
8.1 & 8.2 8.1 & 8.2

Logging

3.6

10.1

8.1

10.5.3

8.3

Wireless Network

4.1

1.2.3 & 2.1.1 4.1.1 1.2.3, 2.1.1,4.1.1

Network Segmentation Remote Access Transmission of Cardholder Data

4.1c
B.1.3
A.2.1 A.2.3

1.3.7
8.3
4.1 4.2 2.3 8.3

Viking Versioning Methodology

11.2 12.1.b

Instructions for customers about 11.1

secure installation of patches and 11.2

updates.

12.1

23

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

16. Glossary of Terms

TERM Cardholder data
DUKPT
3DES Merchant SSF
PA-QSA

DEFINITION
Full magnetic stripe or the PAN plus any of the following: · Cardholder name · Expiration date · Service Code
Derived Unique Key Per Transaction (DUKPT) is a key management scheme in which for every transaction, a unique key is used which is derived from a fixed key. Therefore, if a derived key is compromised, future and past transaction data are still protected since the next or prior keys cannot be determined easily.
In cryptography, Triple DES (3DES or TDES), officially the Triple Data Encryption Algorithm (TDEA or Triple DEA), is a symmetric-key block cipher, which applies the DES cipher algorithm three times to each data block.
The end user and purchaser of the Viking product.
The PCI Software Security Framework (SSF) is a collection of standards and programs for the secure design and development of payment software. Security of payment software is a crucial part of the payment transaction flow and is essential to facilitate reliable and accurate payment transactions.
Payment Application Qualified Security Assessors. QSA company that provides services to payment application vendors to validate vendors’ payment applications.

SAD (Sensitive Authentication Data)

Security-related information (Card Validation Codes/Values, complete track data, PINs, and PIN Blocks) used to authenticate cardholders, appearing in plaintext or otherwise unprotected form. Disclosure, modification, or destruction of this information could compromise the security of a cryptographic device, information system, or cardholder information or could be used in a fraudulent transaction. Sensitive Authentication Data must never be stored when a transaction is finished.

Viking HSM

The software platform used by Nets for application development for the European market.
Hardware security module

24

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

17. Document Control
Document Author, Reviewers and Approvers

Description SSA Development Compliance Manager System Architect QA Product Owner Product Manager Engineering Director

Function Reviewer Author Reviewer & Approver Reviewer & Approver Reviewer & Approver Reviewer & Approver Manager Manager

Name Claudio Adami / Flavio Bonfiglio Sorans Aruna Panicker Arno Ekström Shamsher Singh Varun Shukla Arto Kangas Eero Kuusinen Taneli Valtonen

Summary of Changes

Version Number 1.0
1.0
1.1

Version Date 03-08-2022
15-09-2022
20-12-2022

Nature of Change

First Version for PCI-Secure Software Standard

Updated section 14 with the notapplicable control objectives with their justification

Updated sections 2.1.2 and 2.2

with Self4000.

Removed

Link2500 (PTS version 4.x) from the

supported terminal list

Change Author Aruna Panicker Aruna Panicker
Aruna Panicker

Reviewer

Date Approved

Shamsher Singh 18-08-22

Shamsher Singh 29-09-22

Shamsher Singh 23-12-22

1.1

05-01-2023 Updated section 2.2 with Link2500 Aruna Panicker Shamsher Singh 05-01-23

(pts v4) for continuing the support

for this terminal type.

1.2

20-03-2023 Updated section 2.1.1 with Latvian Aruna Panicker Shamsher Singh 21-04-23

and Lithuanian terminal profiles.

And 2.1.2 with BT-iOS communica-

tion type support

2.0

03-08-2023 Version release version updated to Aruna Panicker Shamsher Singh 13-09-23

2.00 in header/footers.

Updated section 2.2 with new

Move3500 hardware and firmware

versions. Updated section 11 for

`Viking Versioning Methodology’.

Updated section 1.3 with the latest

version of PCI SSS requirement

guide. Updated section 2.2 for sup-

ported terminals ­ removed unsup-

ported hardware versions from the

list.

2.0

16-11-2023 Visual (CVI) update

Leyla Avsar

Arno Ekström 16-11-23

25

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

Distribution List
Name Terminal Department Product Management

Function Development, Test, Project Management, Compliance Terminal Product Management Team, Compliance Manager ­ Product

Document Approvals
Name Arto Kangas

Function Product Owner

Document Review Plans
This document will be reviewed and updated, if necessary, as defined below:
· As required to correct or enhance information content · Following any organizational changes or restructuring · Following an annual review · Following exploitation of a vulnerability · Following new information / requirements regarding relevant vulnerabilities

26

PCI-Secure Software Standard Vendor Implementation Guide v2.0 for Viking Terminal 2.00

References

• Nets A/S - International website
• PCI Security Standards Council – Protect Payment Data with Industry-driven Security Standards, Training, and Programs
• Home
• Software release notes

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>