Credit Card Handling Procedures

Human Resources   Safety/Security   Research Compliance   Compliance   Privacy/Information Security   Business Operations   Intellectual Property


General Accounting | SBIR/STTR Program Participation | Supplemental Compensation Plan | Facilities Management/Planning | Purchasing | Public Affairs | Facility Identification | Serving Alcoholic Beverages | Travel and Reimbursement | State Vehicles | Reproducing Copyrighted Materials | Bank Card Processing | Student Training Agreement | Non-faculty Volunteers | Cash Handling | Fraud | Assigning Research Lab Space | Public Research Lab Space | International Health Education | Faculty Personnel Records | Cellular Phone | Off-campus Graphic Design and Related Printing | Off-campus Photography | Tax Exempt Financing and Tracking of Both Qualified Use and Non-Qualified Use of Research Space | Secondary Logos | Social Media

Bank Card Handling Procedures

Establishing the Ability to Accept Electronic Bank Card Payments:

  • Contact Associate Director Application Services (Lee Trant) for instructions on accepting electronic bank card payments i.e. via the web.

Establishing the Ability to Accept Bank Card Payments:

To establish the ability to accept bank card payments, departments should:

  • Send a written request for authorization to the Controller (Mike Hrncirik, zip 5080)
  • Contact Terry Lilla, the Finance Cashier Office, for bank contact and equipment options information.
  • Notify Susan Blum, Accounts Payable, that the department will be taking bank card payments and of the cost center to which monthly processing transactions will be charged.

Transmitting Bank Card Payment Receipts to the Finance Cashier and Retaining Bank Card Information

  • Bank card machine transactions should be closed out via automatic closing at least once per business day.
  • The bank card receipt report should be reconciled to the batch total of cash receipts.
  • A copy of the bank card receipt report should be transmitted to the Finance Cashier with the daily Cash Remittance Report.
  • Under no circumstances should bank card information be emailed out of the department.
  • Printed receipts should show only the last 4 digits of the bank card number.
  • Retain the original receipts from all transactions and any original, signed documentation in a secure location for a minimum of 7 years per university record retention guidelines.

Discontinuing the Acceptance of Bank Card Payments

To discontinue accepting bank card payments, departments should:

The Finance Cashier Office will work with the Controller in cancelling the account with the bank (otherwise monthly charges will continue to be assessed).

Personnel Training

  • Training of personnel who utilize the devices will be provided such that they are aware of attempted tampering or replacement of devices
  • A list of UNMC-approved products will be maintained by the Finance Cashier Office. No products except those on the approved list may be used.
  • No individual may directly access the cardholder electronic data card environment.
  • The Finance Cashier Office will maintain written agreements with service providers.

Technical Controls

Firewall

A specific area within the DMZ has been established for protection of the Cardholder Data Environment. This area has been established following the DMZ Information Security Procedures. In addition:

  • Firewall and route rule sets are audited every six (6) months by the Information Security Office.
  • The inbound and outbound firewall traffic rule set is established with a deny all, except for those rules specifically necessary to support the cardholder data environment. The rules are reviewed and approved by the Information Security Office prior to implementation by the network team.
  • The wireless networks are not allowed access to the Credit Card Data Environment.
  • Workstations are not allowed direct access to the credit card data environment.

The Network Manager provides oversight to ensure that the firewall rules adhere to this procedure.

Security Parameters

  • Configuration standards are followed for all system components impacting the cardholder data environment.

**Network configuration follows the ????DISA Security Technical Implementation Guides

    • Server configuration follows the current standard.???
  • All vendor supplied defaults for system passwords and other security parameters are changed prior to being placed in production.
  • Only necessary services, protocols, daemons will be enabled as required for the function of the system. Additional security features are implemented for any required services, protocols, or daemons that are considered insecure (i.e. SSH, S-FTP etc.).
  • Security system parameters will be configured to prevent misuse.
  • All unnecessary functionality such as scripts, drivers, features, subsystems, file systems and unnecessary web servers will be removed.
  • The Information Security Office will conduct annual training to verify that all individuals responsible for security parameters review the implementation of the parameters.

Encryption

  • All transmission of cardholder data across open, public networks shall be encrypted.

Maintain secure systems/Vulnerability Management/Patching

  • All components of the cardholder data environment will be scanned by the vulnerability management tool. The results of the scan are communicated to the owner of the system component who then remediates any identified vulnerabilities. The risk of the vulnerability is established by the vulnerability management tool based upon industry based best practices such as the CVSS base score.
  • Applications developed will be tested prior to release to production and follow the change control procedure.

Identity and access management

  • User accounts are limited to use by the development staff. No direct access to the cardholder data environment by end users is allowed.
  • User accounts used to manage the system have the password changed every 90 days.

Monitoring network resources

  • Audit capability is enabled to allow linking access to system components to each user.
  • The audit trail will allow reconstruction of the following events:
    • Individual user accesses to cardholder data
    • Actives taken by any individual with root or administrative privileges
    • Access to all audit trails
    • Invalid logical access attempts
    • Use of and changes to identification and authentication mechanisms
    • Initialization, stopping or pausing of the audit logs
    • Creation and deletion of system level objects.
  • The audit log will contain:
    • User identification
    • Type of event
    • Date and time
    • Success or failure indication
    • Origination of event
    • Identity or name of affected data, system component or resource
  • Log, monitor and review all changes to time settings
  • Secure audit trails so they cannot be altered
  • A review of log and security events for all systems components will be manage
  • Review the following daily:
    • All security events
    • Logs of all components that store, process, or transmit cardholder data.
    • Logs of all critical system components
    • Logs of all servers and systems components that perform security function
  • Review logs of all other system components based upon the risk assessment
  • Retain audit trail history for at least one year (3 monthly immediately available for analysis)

Security System Testing

  • Quarterly internal vulnerability scans and rescans will be performed by the Information Security Office
  • Vulnerability scans will be performed after any significant change
  • Internal penetration tests will be performed annually and after any significant infrastructure or application upgrade.
  • All exploitable vulnerabilities found will be remediated.
  • Utilize and monitor an intrusion prevention system
  • A change detection mechanism of ???configuration file integrity monitoring is implemented.


For additional information, see Bank Card Processing Policy.

This page maintained by dkp.

Last Review by Policy Owner: 06/30/14