E-Commerce

PCI DSS Web Redirection Services Standard

Last modified 12/9/2024

Purpose

The purpose of this standard is to establish secure and compliant guidelines for managing web redirection servers1. Web redirection servers route payment flow for extremely sensitive cardholder data (CHD) and are a prime target for attackers, as the processing of cardholder data creates a significant business-critical exposure, and compromised cardholder data is easily monetized by attackers.

By implementing this standard, the University seeks to ensure compliance with the Payment Card Industry (PCI) Data Security Standard (DSS) and mitigate risks posed by utilizing ECommerce transaction systems. This approach balances providing effective guidance for managing web redirection services while allowing University units freedom to maintain individual processes and procedures.

Scope

This standard applies to all University-managed web redirection systems and support teams as defined in Self Assessment Questionnaire (SAQ) A2. This standard exclusively applies to servers and support teams controlled by the Payment Card Industry Data Security Standard.

Standard

Web redirection servers and their support teams must maintain and follow documented configurations, processes, and/or procedures to meet the following criteria:

  1. Web redirection servers and their support teams must be compliant with the latest version of the PCI DSS SAQ A2 Standard.
  2. Support teams must maintain an up-to-date list of web redirection servers ("inventory"). The inventory should include server roles and descriptions, current patch levels, and personnel responsible for the asset.
  3. Servers shall utilize network segmentation to limit connectivity to only necessary Internet services and internal systems.
  4. Servers and their components must be maintained with a patch management process that results in the latest available and supported firmware and software versions. Critical or high-security patches/updates must be installed within one month of release.
  5. Vendor default accounts shall be disabled, removed, or utilized with a non-default password. Periodic review should be conducted to ensure defaults are not reintroduced with updates or other product changes.
  6. Support teams must identify and manage vulnerabilities using industry-recognized sources and alerts. Vulnerabilities must be classified using the latest version of the Common Vulnerability Scoring System (CVSS)4, and vulnerabilities with a CVSS score of 4.0 or higher severity must be resolved.
  7. Vulnerability scans are performed at least monthly and after any significant change by the University's Approved Scanner Vendor (ASV). PCI-failing vulnerabilities reported by the ASV are resolved. Rescans are performed as needed to obtain a quarterly passing scan.
  8. Servers must utilize a unique ID for each user before access to system components or cardholder data is allowed.
  9. Group, shared, generic accounts, or other shared user authentication credentials are disallowed.
  10. Access for terminated users must be immediately revoked. User access reviews shall be conducted periodically to verify only those who need access have access.
  11. All administrative user access to system components shall be authenticated via multifactor authentication using at least two of the following authentication factors: something you know, something you have, or something you are.6
  12. All non-administrative user access to system components shall be authenticated via at least one of the following authentication factors: something you know, something you have, or something you are.
  13. User access to system components using passwords/passphrases shall:
    1. Set to a unique value for first-time use and upon reset.
    2. Be forcibly changed immediately after the first use.
    3. Be a minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).
    4. Contain both numeric and alphabetic characters.
    5. Not be allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
    6. Passwords/passphrases are changed at least once every 90 days.
  14. A change- and tamper-detection mechanism is deployed to alert personnel to unauthorized modification of the URL of the payment capture page provided by the redirect service.

Exceptions

While this standard is intended to apply comprehensively, there may be instances where certain devices or support teams are unable to meet the full requirements. In such cases, exceptions must be formally requested and reviewed.

Requests for exceptions must be submitted to Payment Card Support3 through the university’s ticketing system or by emailing paymentcardsupport@ilstu.edu. Each request must include:

  • The information technology team and functional business units associated with the exception request
  • Device or process/procedure identifiers affected by the exception
  • A detailed use case explaining why the exception is necessary and what compensating security controls, if any, will be implemented

Payment Card Support, Information Security Office, and the E-Commerce Committee will mutually review all exception requests in accordance with the Information Security Program's exception management process. Approval will be granted only when it is determined that operational needs outweigh the security risks, and where appropriate compensating controls are in place to mitigate those risks. All approved exceptions will be documented, periodically reviewed, and may be subject to additional security monitoring.

Additional Information

Footnotes

The following information provides supporting information referenced in the other sections of this document:

  1. Payment card industry (PCI) definitions are maintained by the PCI Security Standards Council (SSC) at the PCI SSC website Glossary including Web Redirection Server, Payment Cards, Payment Card Industry Data Security Standard (PCI DSS), Point of Interaction (POI), Point-to-Point Encryption (P2PE), Self Assessment Questionnaire (SAQ), and more.
  2. SAQ A: The PCI SSC reporting tool used to document self-assessment results from an entity’s PCI DSS assessment - specific to ECommerce solutions. The A self-assessment document is maintained by the PCI SSC.
  3. Payment Card Support: The cross-functional support team for PCI DSS and payment card devices. You may contact a team member directly, submit a ticket to Payment Card Support, or email paymentcardsupport@ilstu.edu. 
  4. CVSS: The Common Vulnerability scoring system (CVSS), a qualitative measure of vulnerability severity with severities between low and critical
  5. Requirements 6.4.3 and 11.6.1 are out of SAQ A scope for the University when using Touchnet services per Touchnet documentation.
  6. Single-Use Tokens with a short lifetime created via multifactor authentication are considered multifactor authentication for the purposes of this standard.

Supporting References

The following information provides supporting references that informed the development of this standard:

https://policy.illinoisstate.edu/technology/9-8/

https://policy.illinoisstate.edu/fiscal/cashier/7-5-2/

https://policy.illinoisstate.edu/technology/9-2-2/

https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-A.pdf

https://www.pcisecuritystandards.org/glossary/


PCI DSS Guidance

Illinois State University complies with the PCI DSS framework to ensure our cybersecurity measures effectively meet compliance and mitigate risks associated with payment card processing. PCI DSS requirements relevant to this standard are documented here.

2.2.2 Vendor default accounts are managed as follows: If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6. If the vendor default account(s) will not be used, the account is removed or disabled.

6.3.1 Security vulnerabilities are identified and managed as follows: New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs). Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact. Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.

6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: Critical or high-security patches/updates are installed within one month of release.

6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: A method is implemented to confirm that each script is authorized. A method is implemented to assure the integrity of each script. An inventory of all scripts is maintained with written justification as to why each is necessary. 

8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.

8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows: Account use is prevented unless needed for an exceptional circumstance. Use is limited to the time needed for the exceptional circumstance. Business justification for use is documented. Use is explicitly approved by management. Individual user identity is confirmed before access to an account is granted. Every action taken is attributable to an individual user.

8.2.5 Access for terminated users is immediately revoked.

8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: 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 element.

8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows: Set to a unique value for first-time use and upon reset. Forced to be changed immediately after the first use.

8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters). Contain both numeric and alphabetic characters.

8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.

8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single factor authentication implementation) then either: Passwords/passphrases are changed at least once every 90 days, OR The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.

11.3.2 External vulnerability scans are performed as follows: At least once every three months. By PCI SSC Approved Scanning Vendor (ASV). Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met. Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.

11.3.2.1 External vulnerability scans are performed after any significant change as follows: Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved. Rescans are conducted as needed. Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).

11.6.1 A change- and tamper-detection mechanism is deployed as follows: To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser; The mechanism is configured to evaluate the received HTTP header and payment page; The mechanism is configured to evaluate the received HTTP header and payment page; The mechanism functions are performed as follows: At least once every seven days OR Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).