PCI DSS Compliance Considerations

Introduction

This Application Note provides guidance for configuration and assessment of Advantech cellular routers within the cardholder data environment for reaching PCI DSS compliance.

The Payment Card Industry Data Security Standard (PCI DSS) comprises a minimum set of requirements for protecting account data. It applies to merchants and other entities that store, process, and/or transmit cardholder data.

The cardholder data environment is comprised of people, processes, and technology that handle cardholder data or sensitive authentication data. System components include network devices (both wired and wireless), servers, computing devices, and applications. Virtualization components, such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors, are also considered system components within PCI DSS.

Tips

The PCI DSS standard comes in multiple versions. This document applies to PCI DSS Version 3.2.1 (May 2018) and will be updated once a new PCI DSS version is released.

The PCI DSS defines 12 high-level requirements and numerous sub-requirements. The following sections provide considerations for all first-level sub-requirements (e.g., 1.1, 1.2, etc.).

Requirements Considerations

#1 Install and maintain a firewall configuration to protect cardholder data

1.1 Establish and implement firewall and router configuration standards

Inspect the Security Guidelines, which include recommendations for secure configuration and operation.

The entire router configuration is contained in a single file, enabling identification of all configuration changes. For example, integration with the Zabbix monitoring system allows detection of unauthorized configuration changes.

The router provides stateful firewall functionality. The configuration enables two roles:

Admin, who can configure the router;
User, who can review the configuration.

The NetFlow/IPFIX Router App enables you to observe the actual traffic flows and validate network diagrams.

1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment

The router acts as a conduit between two security zones: WAN (untrusted) and LAN (trusted). The firewall has a specific configuration for each zone.

Wi-Fi clients should be authorized using WPA2, possibly with a RADIUS server. Ethernet devices can be authorized using the 802.1X Authenticator Router App.

Firewall filtering is disabled by default. In the router configuration you should:

Enable filtering of incoming packets to deny WAN traffic from entering the LAN;
Enable filtering of forwarded packets to deny traffic routing between WAN, LAN, and Wi‑Fi networks;
Enable filtering of locally destined packets to deny traffic toward router services.

Tips

Customized configurations can use different defaults. Consult your dealer if you need the firewall enabled by default, or if you require other custom settings.

The router configuration is persistent and can be centrally managed and auto‑updated (e.g., using WA/DMP).

1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment

The router can be installed on one segment boundary. By filtering forwarded packets, you can limit traffic flow to/from specific addresses only; established connections are then allowed in any direction.

Multiple routers and firewalls are needed to implement a Demilitarized Zone (DMZ).

Reverse Path Filtering (/proc/sys/net/ipv4/conf/default/rp_filter) can be used to prevent IP address spoofing (for example, by blocking traffic originating from the Internet with an internal source address).

Network Address Translation (NAT) toward the WAN is used by default so that internal IP addresses are never revealed.

The router itself does not store payload data (i.e. cardholder data); even the NetFlow/IPFIX Router App does not store the packet content.

1.4–1.5 Not Applicable

These PCI DSS requirements address documentation or process aspects that are not relevant to technical equipment such as cellular routers.

#2 Do not use vendor-supplied defaults for system passwords and other security parameters

2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network

The Security Guidelines recommend changing default passwords and SNMP community strings. There are no accounts other than “root” and no default secrets in the Wi‑Fi configuration.

2.2 Develop configuration standards for all system components

Ensure that these standards address all known security vulnerabilities and are consistent with industry‑accepted system hardening standards.

The Security Guidelines include a Hardening Guide and recommendations covering known vulnerabilities. This document is periodically updated and reviewed to meet industry best practices.

By default, no network‑facing services or protocols are enabled; each must be explicitly activated.

Insecure services such as Telnet, FTP, and older TLS versions are provided only for compatibility with legacy systems and must be disabled in the PCI environment.

2.3 Encrypt all non‑console administrative access using strong cryptography

Telnet and plain HTTP must be disabled in favor of secure alternatives. SSH and HTTPS are used with TLS 1.2 and strong encryption as specified by NIST SP 800‑57.

2.4 Maintain an inventory of system components that are in scope for PCI DSS

Remote monitoring systems such as Zabbix can help maintain an accurate system inventory.

2.5–2.6 Not Applicable

These requirements pertain to process aspects not relevant to technical equipment such as cellular routers.

#3 Protect stored cardholder data

3.1–3.4 Not Applicable

These requirements apply to cardholder data storage, whereas the router does not store any cardholder data. Even the NetFlow/IPFIX Router App does not store the packet content.

3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse

Although the router does not store cardholder data, cryptographic keys may be used to protect the transmission of cardholder data across unprotected networks (see Requirement 4).

On platforms without a hardware security module (e.g. TPM), private keys are stored in the router configuration and protected only by the root password.

When performing a configuration backup, specify an encryption password to protect the keys from disclosure.

Changes to cryptographic keys are reported via system logging (syslog). Remote monitoring systems such as Zabbix can detect key modifications.

3.6 Fully document and implement all key‑management processes and procedures

The SCEP Client Router App enables:

Automated generation of strong cryptographic keys;
X.509 certificate enrollment and renewal using a standard Public Key Infrastructure (PKI), for example, OpenXPKI (https://www.openxpki.org);
Download of a Certificate Revocation List (CRL).

3.7 Not Applicable

This requirement addresses documentation aspects not relevant to cellular routers.

#4 Encrypt transmission of cardholder data across open, public networks

4.1 Use strong cryptography and security protocols

The router supports the following cryptographic protections:

Private APN in the cellular network, authenticated by the SIM card;
WPA2–AES encryption for Wi‑Fi communication;
VPN (IPsec, OpenVPN) based on pre‑shared secrets or X.509 certificates for network traffic;
TLS 1.2 for securing SSH and HTTPS administration.

The supported cipher suites meet the NIST SP 800‑57 requirements for cryptographic strength through 2030.

4.2 Never send unprotected PANs via end‑user messaging technologies

No user data are transmitted via messaging technologies. SMS is used solely for status reporting and limited remote control (e.g., reboot, WAN connection/disconnection).

4.3 Not Applicable

This requirement pertains to documentation aspects not relevant to cellular routers.

#5 Protect all systems against malware and regularly update anti‑virus software or programs

5.1–5.4 Not Applicable

The router runs a custom Linux distribution that is not accessible to regular users. Only the administrator (root) can make configuration changes.

Remote monitoring systems such as Zabbix can monitor system integrity and alert on configuration modifications.

#6 Develop and maintain secure systems and applications

6.1 Establish a process to identify security vulnerabilities

We proactively search for security deficiencies in our products, monitor public vulnerability databases (e.g., NVD), and conduct thorough penetration testing. Our Product Security Incident Response Team (PSIRT) complies with FIRST recommendations for Level 1.

A list of vulnerabilities in our products is available through the Engineering Portal: https://icr.advantech.com/download/security-notifications.

6.2 Ensure that all system components and software are protected from known vulnerabilities

Firmware updates with security patches are released at least four times a year. This includes fixes for vulnerabilities with a CVSS score > 6.5, with critical issues addressed on an ad‑hoc basis.

6.3 Develop internal and external software applications securely

Firmware is developed according to industry best practices. Every code contribution undergoes peer review to ensure that no test provisions remain in the firmware.

6.4 Follow change control processes and procedures

Firmware development is strictly version‑controlled. Before releasing new firmware, the following actions are performed:

Thorough functional and performance testing is conducted;
Release notes describe all changes made, including fixed security vulnerabilities;
Product documentation is updated.

v3 routers can recover from a failed upgrade by reverting to the previous firmware if the new version fails to boot.

6.5 Address common coding vulnerabilities

Every release undergoes automated penetration testing for known vulnerabilities, and manual penetration tests are conducted at least once a year by an independent organization.

Internal coding standards include the SEI CERT C Coding Standard. Developers receive annual security training on prevalent security flaws.

6.6–6.7 Not Applicable

These PCI DSS requirements are related to public-facing websites and operational procedures and thus not relevant to technical equipment such as cellular routers.

#7 Restrict access to cardholder data by business need to know

7.1 Limit access to system components and cardholder data

Access to the router is limited to authorized personnel only. The configuration supports two roles:

Admin, who can configure the router;
User, who can review the configuration.

For LAN or Wi‑Fi access, 802.1X or WPA2‑Enterprise authentication can restrict device access.

The MAC address filtering provided by the Layer 2 Firewall (L2FW) Router App may also be used.

7.2 Establish an access control system that defaults to “deny all”

Without explicit authorization, access is prohibited. Router access can be managed via TACACS+ or a RADIUS server. User roles may be assigned based on the RADIUS Service-Type attribute.

7.3 Not Applicable

This requirement addresses documentation aspects not relevant to cellular routers.

#8 Identify and authenticate access to system components

8.1 Define and implement user identification management policies

Users connect to the router with a unique username and password.

All administrative actions are logged to syslog, and remote monitoring can detect unauthorized changes.

After three unsuccessful login attempts, Web admin access is locked for 60 minutes.

SSH, Web (HTTP), Telnet, and FTP sessions (if enabled) are terminated after a period of inactivity.

8.2 Ensure proper user-authentication management

User passwords or passphrases are used (empty passwords are not allowed). The /etc/settings.policy file defines a complexity policy, including minimal length and character requirements.

Users are prompted to change the default password (highlighted in red); remote access cannot be enabled without changing the default password.

The user passwords are not stored in the router; only SHA-1 hashes are used. The TLS 1.2 (HTTPS, SSH) is used to protect the password during authentication exchange.

8.3 Two‑Factor Authentication for Remote Access

The router is not intended as an entry point for network‑level access from outside the network; therefore, two‑factor authentication is neither needed nor supported.

8.4 Document and communicate authentication policies

Guidelines for selecting secure passwords are provided in the Security Guidelines, based on NIST SP 800‑63B.

8.5 Do not use group, shared, or generic credentials

The use of group credentials is discouraged in the Security Guidelines.

8.6–8.8 Not Applicable

These PCI DSS requirements describe requirements for authentication using security tokens, requirements for a database and documentation related requirements that are not relevant to cellular routers.

#9 Restrict physical access to cardholder data

9.1 Use appropriate facility entry controls

The router must be installed in a physically secure environment.

As an additional protection measure, a remote monitoring system such as Zabbix can be used to detect additional devices connected to a USB port.

9.2–9.9 Not Applicable

These requirements pertain to onsite personnel security aspects not relevant to cellular routers.

#10 Track and monitor all access to network resources and cardholder data

10.1 Implement audit trails linking access to individual users

The system log (syslog) records login events, including usernames and source IP addresses.

10.2 Implement automated audit trails

The syslog captures significant events, including:

Modifications to router configuration;
Unsuccessful login attempts;
User administration actions;
Enabling/disabling of router services (including the syslog service);
Installation and removal of router apps.

10.3 Record detailed audit trail entries

Each syslog record includes:

The software type (facility) that generated the message;
A severity level (e.g., Error (3), Warning (4), or Notice (5));
A timestamp;
The originating process;
A textual message.