PCI Information Security

Introduction

The Payment Card Industry (PCI) Security Standards Council, an organization composed of the major credit card companies, has developed data security standards to ensure that credit card transactions are reliable and secure. Organizations that choose to accept credit card transactions as a form of payment are contractually required to follow the standards set forth by the PCI Security Standards Council. Failure to comply can result in more stringent requirements for compliance, fines, and/or suspension of credit card processing services.

The standards created include:

• Controls for handling and restricting credit card information
• Computer and Internet security
• Reporting of a breach of credit card information

The credit card industry requires compliance with these standards in order for a merchant to accept credit card payments. Many departments and merchants on campus process credit card transactions in the course of daily business. As such, it is the intent of Ohio University (OHIO) through this procedure to protect the privacy of our customers and maintain compliance with Payment Card Industry Data Security Standards (PCI DSS).

This manual defines all policies and procedures required for compliance with the Payment Card Industry Data Security Standard (PCI DSS). These policies apply to all employees, systems and networks involved with credit card processing which includes the transmission, storage and/or processing of credit card numbers at Ohio University.

All employees involved in the Card Processing Environment (CPE) must read, understand, and agree to abide by all policies in this manual. Any changes to the policies herein must be approved and disseminated by OHIO PCI DSS Compliance Committee.  The OHIO PCI DSS Compliance Committee is comprised of employees from the Office of the Bursar and the OIT Security Office.

These policies may be updated at any time and must be reviewed annually for changes.

Not all components of the requirements listed in this document are directly applicable to the individual OHIO merchants but are required to be attained by OHIO as a whole. Questions regarding this procedure should be directed to the OHIO PCI DSS Compliance Committee.

OHIO PCI DSS – General PCI DSS Procedure

Introduction

The following procedures are for use by departments accepting credit cards as a form of payment in conducting official business at Ohio University (OHIO). OHIO accepts credit card payments as a convenience to its customers. Departments that have been approved to do so may accept Visa, MasterCard, Discover, American Express, debit cards with a Visa or MasterCard logo, and pin-based debit. Departments accepting credit cards at OHIO are required to follow strict procedures to protect customers' credit card data. Furthermore, these directives provide guidance to maximize compliance with the Payment Card Industry Data Security Standards (PCI DSS) and ensure appropriate integration with the university’s financial and other systems.

To be approved to accept credit cards, departments must contact the Office of the Bursar to discuss credit card processing options. The Office of the Bursar must be included prior to purchasing credit card applications. Depending on the determined credit card processing type, a merchant ID may need to be established.

It is the procedure of Ohio University that only departments who have been approved may accept payment for goods or services via credit card. University departments will be held liable for all penalties resulting from noncompliance with this procedure.

PROCESSING TYPES

Type	Description
Point of Sale (POS)	Definition: The location where a credit card transaction occurs through a terminal or register. Applicable Parties: Determined by a high frequency of business traditionally transacted through POS (register) devices, bank-owned desktop terminals and/or computers.
eCommerce	Definition: The buying and selling of products or services over the Internet. Applicable Partie s:Determined by a medium to high frequency of business traditionally transacted through web-based software. Transactions could occur through the centralized university provider or decentralized (department specific) OHIO-owned software. Any e-commerce transactions at the University must be processed using the university’s preferred provider unless an exception is approved by the Office of the Bursar.
Third Party	Definition: Credit card transactions processed through an external party to OHIO. Software may or may not be owned by OHIO. Applicable Parties: Determined by a medium to high frequency of business traditionally transacted through POS (register) devices and/or computers.
Bursar	Definition: Credit card information is collected by OHIO departments and processed through the Office of the Bursar. Applicable Parties: Determined by low frequency of business manually collected by the departments and processed by the Office of the Bursar.

ANNUAL ASSESSMENT

Each department accepting credit cards must have an annual Self- Assessment Questionnaire (SAQ) completed. The SAQ will be completed by the OHIO PCI DSS Compliance Committee with assistance from the department as needed. The applicable processing type will determine the SAQ to be completed.

SAQ Type	Description
A	Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants..
A-EP	E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.  Applicable only to e-commerce channels.
B	Imprint-only merchants with no electronic cardholder data storage, and/or standalone, dial-out terminal merchants with no electronic cardholder data storage. Not applicable to e-commerce channels.
B-IP	Standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage. Not applicable to e-commerce channels.
C-VT	Merchants using only web-based virtual terminals, no electronic cardholder data storage
C	Merchants with payment application systems connected to the Internet, no electronic cardholder data storage
P2PE-HW	Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-commerce channels.
D	All other merchants not included in descriptions for SAQ types A through C above, and all service providers defined by a payment brand as eligible to complete an SAQ.

DEFINITIONS

MERCHANT ID - An account number from the university’s merchant bank that allows a department to accept credit-card payments. The merchant ID allows a company to receive and process credit card transactions and transfers money from the buyer’s (customer) account to the seller’s (University) account.

PCI DSS COMPLIANCE - The Payment Card Industry Data Security Standard (PCI DSS) is a widely accepted set of policies and procedures intended to optimize the security of credit, debit and cash card transactions and protect cardholders against misuse of their personal information. The PCI DSS was created jointly in 2004 by four major credit-card companies: Visa, MasterCard, Discover and American Express. Ohio University is contractually obligated to comply with the PCI DSS.

SELF ASSESSMENT QUESTIONNAIRE (SAQ) – A validation tool to help merchants validate their compliance with PCI-DSS.

CARDHOLDER DATA - Full magnetic stripe or the PAN plus any of the following:

• Cardholder name
• Expiration date
• Service Code

OHIO PCI DSS - User Authentication and Access

Purpose

This outlines the authentication and access control requirements when accessing sensitive card data.

Scope

This applies to all users in the (Card Processing Environment) CPE at OHIO.

Procedure

• Identification
  • Ensure proper user identification and authorization.
  • User accounts must use a unique identifier, no group or shared accounts are permitted
  • Verify user identity prior to making any changes including additions, deletions or modifications.
  • Users must annually acknowledge understanding of the account procedure and procedures. Accounts must conform to the following parameters.
  • First time passwords must be unique and changed upon first use
  • Passwords must change every 90 days
  • Do not use group or shared passwords
  • Passwords must be strong and in accordance with University Credentials procedure #91.004
  • Passwords cannot be the same as the last 15 used
  • Accounts must utilize at least a 30 minute lockout when failure attempts exceed 6.
  • Passwords must be rendered unreadable and utilize strong cryptography on any storage system.
  • System access must be logged. Success and failure access to all system data must be logged and retained for at least 1-year. Logs must be kept online and available for 90 days.
  • Vendor accounts must only be enabled during the time that they are needed.
  • Automatic disconnect of sessions for access technologies after fifteen minutes of inactivity. This varies by system but should not exceed ninety minutes. 
  • Perform applicable background checks on potential employees who have access to systems, networks, or cardholder data in accordance with OHIO’s procedure on performing background checks and local law. If employees have access to one card number at a time to facilitate a transaction, such as store cashiers in a supervised setting, background checks are not required by PCI DSS. However, OHIO’s procedure regarding background checks on employees must be followed.
• Access
  • Restrict access to data on a “need to know” basis.
  • Authorization must be completed on a form signed by management defining access.
  • An automated access control system must be in place.
• Removal
  • A process must exist to promptly disable and remove accounts upon notice that an account is no longer needed.   
  • User Accounts must be reviewed; inactive accounts shall be retired at least every 90 days.

Enforcement

Any employee found to have violated this may be subject to disciplinary action by their administrative unit, the department, or the university.

OHIO PCI DSS – IT

Introduction

Ohio University provides information technology resources to support the academic, administrative, educational, research, and service missions of its appropriately affiliated members within the margins of institutional priorities and financial capabilities. The information technology resources provide for the University, a conduit for free and open forum for the expression of ideas mindful of the university core values. In order to protect the confidentiality, integrity, and availability of information technology resources for intended purposes, the following procedure has been developed. The scope of this procedure is to encompass all information technology devices owned by the university, any device obtaining connectivity to the university network, and all university relevant data on these devices.

Procedure

• All usage of information technology resources is to be consistent with all other relevant policies at OHIO.
• Users must be aware of and comply with all Federal, State, local, and other applicable laws, contracts, regulations, and licenses.
• Use of information technology to access resources other than those supporting the academic, administrative, educational, research and service missions of the University or for more than limited social purposes is prohibited.
• All users must only access or attempt to access information technology resources that they are authorized to use and then only in a manner and to the extent authorized.   A list of personnel authorized to use the devices and the technologies will be recorded and reviewed annually.
• Attempting to circumvent information technology security systems is prohibited.
• Disruption of university authorized activities is prohibited.
• Use of information technology to conduct reconnaissance, vulnerability assessments, or similar activity by unauthorized personnel is prohibited.
• Users are required to protect the confidentiality, integrity, and availability of information technology.
• Anonymous use, impersonation, or use of pseudonyms on an information technology resource to escape accountability is prohibited.
• The use of any unlicensed spectrum space is prohibited on any OHIO owned or OHIO-occupied property, unless it is part of the wireless services being deployed by the University.
• PCI Incident Response plan will follow Ohio University Incident Response Plan.  The incident response and business continuity plans must be documented, reviewed, and tested annually. Analysis of the results will be documented.

Responsibilities

University Responsibilities

• Provide and coordinate information technology resources to allow completion of duties as assigned in support of the academic, administrative, educational, research, and service missions, within the margins of institutional priorities and financial capabilities.
• Communicate, review, update, and enforce policies to protect information technology resources.
• Take reasonable measures to mitigate security threats.

User Responsibilities

• Read, agree to, and abide by all University policies and procedure updates.
• Practice safe computing when using information technology resources.
• Notify university officials upon discovery that an assigned information technology resource has been accessed, attempted to be accessed, or is vulnerable to access by unauthorized users.
• Users are responsible for activity resulting from their assigned information technology resources.

Security and Privacy Statement

OHIO respects the privacy of all information technology users. The University does not routinely monitor the content of material but does reserve the right to access and review all aspects of its information technology infrastructure to investigate performance or system problems, search for harmful programs, or upon reasonable cause, to determine if a user is violating a procedure, State or Federal law. OHIO monitors, keeps, and audits detailed records of information technology usage; traces may be recorded routinely for trouble shooting, performance monitoring, security purposes, auditing, recovery from system failure, etc.; or in response to a complaint, in order to protect the university's and others' equipment, software, and data from unauthorized use or tampering. Extraordinary record keeping, traces and special techniques may be used in response to technical problems or complaints, or for violation of law, procedure or regulations, but only on approval by university administrators specifically authorized to give such approval. In addition to the privacy of individuals being respected under normal circumstances, the privacy of those involved in a complaint will be respected and the University will limit special record keeping in order to do so, where feasible. Information will be released in accordance with law. Users should be aware that while the university implements various security controls to protect information technology resources, protection of data from unauthorized individuals cannot be guaranteed.

Enforcement and Sanctions

Individuals or entities in violation of the OHIO Information Technology Procedure will be referred to the appropriate disciplinary authority for review. Access privileges may be suspended without prior notice if it is determined that a procedure violation is causing a current or imminent threat to the confidentiality, integrity, or availability of information technology resources.

Definition of Terms

Information Technology Resources

All aspects associated with management and processing of information. This includes facilities, technologies, and data used for university processing, transfer, storage, and communications. Examples of these resources include, but are not limited to, computers, networking equipment, telecommunications equipment, electronic mail, electronic information sources, network bandwidth, wireless devices, video communications, IP telephony, University assigned accounts, voice mail, passwords, access controls, storage media, documentation, personal digital assistants.

Safe Computing

Using information technology in a secure manner consistent with its intended purpose. Examples of security measures to be taken include, but are not limited to, the use of strong passwords that are not easily guessable, are changed regularly and are kept private; the application of all relevant security patches in a timely manner; maintenance of up-to-date virus definitions; backup and protection of important/critical data; security of passwords; protection of data and files.

OHIO PCI DSS - Physical Security Procedure

Purpose

This procedure outlines the physical constraints required to protect data and facilities in the CPE.

Scope

This procedure applies to all faculty, staff, students, contractors, consultants, temporary, and other workers at OHIO including all personnel affiliated with third parties. This procedure applies to all data and facilities involved in the CPE at OHIO.

Procedure

• Access - All equipment that is involved in the CPE must be maintained in a secure environment. Only personnel involved in the CPE should be allowed access to the data center.
• The data center must limit access via badging, lock, or some other management approved security. Logs (electronic or paper) of ingress and egress to the center must be maintained.
• Authorized Personnel must be badged or easily distinguished from the public.
• Visitors are required to be accompanied at all times by authorized personnel with access rights to the data center. 
• Restrict access to physical network jacks, wireless access points, and routers. Unless in use, switch and router ports will be disabled.
• System and audit logs showing access to this data must be retained for at least 1-year. 90 days must be kept online and available for 90 days.
• Security
  • All sensitive and credit card data must be kept secure at all times. The use of man-traps, cameras, and electronic controls are authorized to protect the facility.
  • Review of logs and camera systems shall be completed on a monthly basis.
• Merchants/department must physically secure all paper and electronic media that contains cardholder data. “Working documents” may be locked in a cabinet during the day but must be returned to a safe or approved storage facility at the end of the day.  Refer to the OHIO PCI DSS – Data Retention and Disposal section for additional information.
• Fax machines, POS devices, and other equipment used by merchants/departments for processing cardholder data must be in a secure cabinet, area, or safe when not in use.

Enforcement

Any employee found to have violated this procedure may be subject to disciplinary action by their administrative unit, the department, or the university.

OHIO PCI DSS Card Processing Environment Hardware

Purpose

To establish a baseline security configuration procedure for all payment Card Processing Environments (CPE) owned, operated, or managed by OHIO. All CPEs will remain compliant with the PCI DSS.

Scope

This procedure applies to all networks, systems and devices/workstations used in the OHIO CPEs.

Procedure

• Documentation
  • Configurations of the network and systems involved in the CPE will be approved and documented. Details shall include names, addressing, data flow, and separation from non-CPE traffic. Standards shall address all known security vulnerabilities and are consistent with accepted industry hardening standards.
  • Roles and responsibilities for logical management of network components shall be identified and documented. Roles include but not limited to: Security Admin, Network Admin, Approval admin, etc.
  • All services, protocols and ports allowed must be documented with a business need for use, and documentation must be provided for use of insecure protocols such as FTP, TFTP, Telnet, etc. including security measures afforded for their use.
• General Configuration rules:
  • If SNMP is to be used, community strings will be changed from default values.

  • System clocks on all equipment must be synchronized to a centralized time source.

  • All remote console access shall be encrypted using standard strong encryption techniques.

  • Configuration changes must be submitted to an authority for approval. Any changes must; be documented and dated, tested, and include rollback procedure.

  • Document all process and procedures defining discovery of new security vulnerabilities and update defined configuration standards accordingly. =

• Firewalls - CPE networks will have a hardware based stateful packet inspection firewall installed at all Internet connections and between any non-CPE internal network or DMZ. Firewalls will be configured:
  • To deny all incoming traffic and will have exceptions based upon the specific business requirements of the CPE
  • To deny all outgoing traffic and will have exceptions based upon the specific business requirements of the CPE.
  • To have default vendor passwords changed prior to being installed on the network
  • To disallow any direct traffic between the CPE and Internet.
  • To allow management access from authorized workstations only specified by IP address.
  • Logging will be enabled and will log all incoming and outgoing connections. Logs will be maintained in a separate location on a separate logging device. Logs must be available for at least one year.
  • All CPE Firewall rule sets will be reviewed at least biannually.
  • Reviews must be documented and dated.
  • Running and startup configurations must be synchronized.
• Network Equipment
  • All networking equipment (switches, routers, IDS/IPS, etc.) will have default vendor passwords changed prior to being installed on the network.
  • All connections to the CPE will be fully documented.
  • At no time will there be an active port that is not connected to a CPE device. All requests for changes to the CPE must be documented and approved.
  • All devices will have logging enabled. Logs will be maintained in a separate location on a separate logging device. Logs must be available for at least 1 year.
• CPE Servers and Workstations
  • Servers and Workstations connected to the CPE will be installed and configured according to security best practices.
  • Software installations will be limited to approved software necessary for the operations of the CPE.
  • Unnecessary protocols and services will be uninstalled or made non-functional.
  • A host-based firewall will be in operation and will deny all incoming traffic by default and will have exceptions for critical business functions only.
  • File integrity monitoring software must be in place and set up properly on all critical systems within the CPE.
  • Local Administrator and Guest accounts will be disabled.
  • Idle sessions shall require re-input of password to re-enable session.
  • Access to the system BIOS will be protected via a password mechanism where available.
  • Antivirus software will be installed, running, current and capable of providing audit logs at all times on all CPE machines that are currently susceptible to such compromises.
  • Servers participating in the CPE will have their security logs forwarded to a server external to the CPE.
  • Operating system patches will be installed within 1 month of release.
• Vulnerability Assessments
  • Vulnerability scans will be completed quarterly on all systems in the CPE. All vulnerabilities will be addressed immediately. 
  • External and internal penetration tests shall be completed annually and after any significant change to the infrastructure.
  • Change Request Procedure
  • A written request for a configuration change must come from an authorized individual. The request will include a description, the business reason, a start and end date, and a rollback procedure.
  • The IT Administrator will review the change and determine the scope of work involved.
  • The Manager will review the change and approve or deny the change in whole or in part.
• Device/terminal inspection and inventory
  • Devices that capture payment card data via direct physical interaction with the card must be inspected regularly to detect tampering and substitution.
  • Maintain an up-to-date list of all devices that includes make, model, location, serial number or other method to uniquely identify a device.
  • Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device). Document the regular inspections.
  • Train all personnel to be aware of attempted tampering or device replacement.

Enforcement

Any employee found to have violated this procedure may be subject to disciplinary action by the (Department or University).

OHIO PCI DSS - Software Development Procedure

Purpose

This procedure outlines the security and requirements for any development of payment application software or Web based applications that transmit, process or store credit card information.

Scope

This procedure applies to all faculty, staff, students, contractors, consultants, temporary, and other workers at OHIO, including all personnel affiliated with third parties. This procedure applies to all networks and data in the CPE at OHIO.

Procedure

• Development Environment - Any software development must be done on a separate development / test infrastructure. It is strictly prohibited to develop or change production software on production systems without following the approved “Change Control Procedure”.

  • Production data may not be used in any development without being sanitized and all identifying sensitive data removed

  • Test data, (IDs, accounts, data, etc) must be removed prior to system being put into production.

  • Development staff and production staff must maintain a strict separation of duties.

  • Display of credit card information within an application must be masked in accordance with the PCI DSS. Only the first 6 digits and the last 4 may be displayed.

  • A separate code review by an impartial group or automated software will be completed prior to software being placed in the production environment.

  • Strict adherence to industry “best practices” and secure coding practices need to be adhered to in all aspects of the development of applications. For a definition of best practices, refer to  http://owasp.org ,  http://csrc.nist.gov/

• Development Lifecycle
  • All Web based applications will be scanned for vulnerabilities by a 3rd party on an annual basis or when significant changes have been made.
  • When applications are no longer needed, they must be securely removed, and all data destroyed or rendered unreadable. Backups of the system and development software must also be securely deleted / removed.
  • System change control procedures must be implemented and logged.
  • A rollback procedure must be documented and approved prior to any system change.

Enforcement

Any employee found to have violated this procedure may be subject to disciplinary action by their administrative unit, the department, or the university.

OHIO PCI DSS - Data Collection, Retention, and Disposal

Purpose

This procedure outlines the collection, storage and disposal procedure for all confidential or sensitive data, when no longer needed for card processing requirements. Data must be removed from OHIO systems using an approved method documented in this procedure. This requirement includes all CPE data stored in systems, temporary files or contained on storage media and paper documents.

Scope

This procedure applies to all faculty, staff, students, contractors, consultants, temporary, and other workers at OHIO, including all personnel affiliated with third parties. This procedure applies to all CPE data in the OHIO network.

Procedure

• Collection
  • Credit card information can be collected in person, by telephone, by mail, or via secure university approved internet application.
  • Credit card information cannot be collected via email or text message.
• Storage
  • The following credit card information is permitted to be stored as long as there is a business need. Written justification must be provided documenting the business need for retention. (Refer to chart in PCI DSS “Applicability Information”.) All data must be protected as described in all sections of the PCI DSS.
    • Primary Account Number (PAN)
    • Cardholder name
    • Service Code
    • Expiration Date
  • Data that is not permitted to be stored includes the following: (exception to this is in “pre-authorization” see 1.3
    • Full Magnetic Stripe (Track 1 or 2 data)
    • CVV2, CVC2, CID, CAV2
    • PIN / PIN Block
  • Pre-authorization Data including track, CVV2, and PIN information, will be retained only until completion of the authorization of a transaction. Storage of cardholder authorization data post-authorization is forbidden.
  • System and audit logs showing access to this data must be retained for at least 13 months. Logs must be kept online and available for 90 days.
  • For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. Where there is an authorized business need, the usage policies must require the data be protected and documented in accordance with all applicable PCI DSS Requirements.
  • When storing paper records containing credit card numbers, all but the last four digits is to be redacted immediately upon processing a transaction.  Redact the full card number by cross-cut shredding upon processing a transaction, while retaining any portion of the document that supports the sale. Paper records must be stored in a locked room or cabinet to which only authorized employees are permitted access. An authorized employee in this instance is one permitted to process credit card data.
• Disposal
  • All sensitive and credit card data must be destroyed when it is no longer required by legal, contractual, or business need. For transaction records, the transaction receipt retention date is 13 months from the processing date.
  • Techniques for disposal data on media is as follows:
  • Hard disks: must be overwritten by an NSA approved method, smashed, pulverized, or otherwise destroyed.
  • Floppy disks: must be shredded.
  • Optical media (CD’s, DVD’s, Blue Ray, etc.) must be shredded.
  • Other magnetic media, (USB Drives, storage cards, etc.) must be overwritten by an approved method, or otherwise destroyed.
  • Paper: must be cross-cut shredded. If utilizing the services of a third party for record destruction, obtain document proof of the destruction.

Enforcement

Any employee found to have violated this procedure may be subject to disciplinary action by their administrative unit, the department, or the university.

OHIO PCI DSS - Logging Controls Procedure

Purpose

This procedure outlines the process for logging all actions that occur in the CPE.  Type and scale of logging, appropriate storage, encryption, and disposal of logs is to be adhered to remain compliant with the PCI DSS.

Scope

This procedure applies to all faculty, staff, students, contractors, consultants, temporary, and other workers at OHIO including all personnel affiliated with third parties. This procedure applies to all CPE data and systems in the OHIO network.

Procedure

Logging is to be done to the level of detail to assist in the reconstruction of any event that takes place in the CPE. Therefore, a secure environment for log acquisition and storage is to be in place.

• Events to be logged.
  • The following events shall be logged.
    • User access to any cardholder data
    • Date & Time
    • Type of event
    • Origination
    • Identity of affected data, system, or resource.
    • Administrative access to any system that contains cardholder data and specific access of data.
    • All authentication attempts, (pass or fail)
    • Creation or deletion of system level objects
    • Configuration changes
    • Access and changes to root or kernel system files
    • Access and changes to log files
• Storage
  • All logs must be stored.
    • Logs should not be stored on the same system that the events take place, (authentication of users on a domain controller for example). Logs should be written off to a separate robust system that has its own specific security parameters on the internal LAN.
    • Limit access to logs to authorized personnel.
    • Logs shall be dated on a daily basis.
    • A file integrity monitoring software shall be installed to monitor all access and changes to log files.
    • Logs shall be retained for at least 1 year.
    • Audits must be conducted to verify the viability of logs.
    • Logs must be reviewed daily. It is permitted to incorporate software for this purpose. The appropriate triggers and alerts must be set up and tested regularly.

Enforcement

Any employee found to have violated this procedure may be subject to disciplinary action by their administrative unit, the department, or the university.

OHIO PCI DSS - Backup Control Procedure

Purpose

This procedure outlines the control of all backup subsystems and the data therein involved in the CPE. Storage, identification, transport, isolation, encryption and disposal of media utilized in the backup systems.

Scope

This procedure applies to all systems, data and affiliated third parties encompassing the CPE in the OHIO network.

Procedure

• Storage
  • The backup subsystem must be identified as part of the CPE. Cardholder data on the subsystem must be rendered unreadable and unable to be reconstructed through un-approved means. Backups of sensitive data must be completed on a regular basis. Data should be checked regularly for restoration applicability.
  • Pre-authorization Data including track, CVV2, and PIN information, will be retained only until completion of the authorization of a transaction. Storage of cardholder authorization data post-authorization is forbidden.
  • System and audit logs showing access to this data must be retained for at least 1 year. 90 days must be kept online and available for 90 days.
• Control
  • All media with sensitive data must be marked as confidential and strict control must be maintained in storage and accessibility of the media.
  • Media must be stored in a secure location approved by management. This location must have limited accessibility to only those that need access. All access to the location must be logged. Security of facility must be reviewed annually.
  • All media couriers and transport mechanisms must be certified by the Office of the Bursar.
  • Any media sent outside the control of the Information Technology facility must be positively logged in and out. A record must be maintained of all media in storage and use as well as its whereabouts.
• Disposal
  • All media that is no longer needed or has reached end-of-life must be destroyed or rendered unreadable so that no data may be extracted. Information on acceptable destruction techniques is detailed in the OHIO PCI DSS - Data Retention and Disposal procedure.

Enforcement

Any employee found to have violated this procedure may be subject to disciplinary action by their administrative unit, the department, or the university.

OHIO PCI DSS - Shared Data – Service Provider Procedure

Purpose

This procedure outlines the operating and contractual procedure for sharing all confidential or sensitive data with a 3rd party.

Scope

This procedure applies to all faculty, staff, students, contractors, consultants, temporary, and other workers at OHIO including all personnel affiliated with third parties. This procedure applies to all CPE data in the OHIO network.

Procedure

Third parties, with whom cardholder data is shared, are contractually required to adhere to the PCI DSS requirements and to acknowledge that they are responsible for the security of the cardholder data which they process. Only the minimum amount of data needed to complete the transaction will be shared with a 3rd party. All interaction must be documented and logged.

Enforcement

Any employee found to have violated this procedure may be subject to disciplinary action by their administrative unit, the department, or the university.

OHIO PCI DSS - Wireless Usage Procedure

Purpose

This procedure outlines the requirements for using wireless communications to transmit sensitive credit card information. These requirements are outlined in the PCI DSS Requirement 4.

Scope

This procedure applies to all faculty, staff, students, contractors, consultants, temporary, and other workers at OHIO including all personnel affiliated with third parties. This procedure applies to all CPE data in the OHIO network. This applies to all wireless technologies used to transmit data to include but not limited to: IEEE 802.11 wireless, GSM and GPRS.

Procedure

• Usage
  • Communications must utilize industry standard best practices to implement strong encryption for authentication and transmission.
    • WPA2 is the standard encryption and the only standard authorized.
    • WEP and WPA shall not be permitted.
• Encryption
  • Strong encryption keys must be used for wireless communication. Encryption must follow the same process as those described in the encryption procedure.
• Wireless Accounting
  • Scanning must be completed quarterly to verify that no un-authorized wireless networks have been installed in the CPE. If scanning is not feasible, a Wireless Intrusion Detection / Protection system may be used.

Enforcement

Any employee found to have violated this procedure may be subject to disciplinary action by their administrative unit, the department, or the university.

OHIO PCI DSS – Remote Access Procedure

Purpose

This procedure explains Ohio University’s official position on how the organization restricts remote access to the Cardholder Data Environment (CDE).

Scope

This procedure applies to the people, process, and technology involved with accessing and/or governing remote access to the Cardholder Data Environment (CDE). 

Procedure

All use of portable computing devices, such as remote computers, laptops, workstations, or mobile devices, regardless of whether they are employee owned or company owned are prohibited from remotely connecting directly to the Cardholder Data Environment (CDE) at all times.  Any remote access to the Cardholder Data Environment (CDE) must go through an approved gateway with specific standards that will meet or exceed PCI DSS requirements.

Requirements

User must be a part of the PCI VPN Group

User must utilize two-factor authentication to access the remote service.

Remote service must be configured and managed in a manner that complies with all PCI Data Security Standard requirements and must receive explicit approval from OIT Security prior to use.

Enforcement

Any employee found to have violated this procedure may be subject to disciplinary action by their administrative unit, the department, or the university.

OHIO PCI DSS - Risk Assessment

Purpose

This procedure helps an organization to identify and understand the potential risks to their cardholder data environment. By understanding these risks, an organization can prioritize risk mitigation efforts to address the most critical risks first. Organizations can also implement threat reducing controls more effectively, for example, by choosing a technology or solution that best addresses identified risks.

Scope

This procedure applies to all card holder data environments.

Procedure

Risk assessments exercises must be performed annually or if there are any major changes in the environment, such as new system component installations, changes in network topology, firewall rule modifications, or product upgrade. The assessments must be documented and reviewed by the Information Security Office.    

OHIO PCI DSS - Encryption

Purpose

All confidential or sensitive electronic data within the OHIO CPE must be protected by approved encryption techniques. This procedure applies to the management of encryption keys and application of their use.

Scope

This procedure applies to all faculty, staff, students, contractors, consultants, temporary, and other workers at OHIO including all personnel affiliated with third parties. This procedure applies to all CPE data in the OHIO network.

Procedure

• Encryption Keys
  • Only Strong encryption can be utilized to protect sensitive data. These methods are defined by the PCI DSS;
    • 3DES
    • AES
    • Proprietary Vendor encryption providing it is approved in the PA-DSS
    • SSL
    • IPSEC
  • Encryption keys must protected in the following manner:
    • Have dual custodianship with the fewest number of custodians.
    • Clear text images of the keys must be kept locked in a tamper proof manner and in the fewest possible locations and forms.
  • System and audit logs showing access to this data must be retained for at least 1 year. 90 days must be kept online and available for 90 days.
• Documentation
  • All process and procedures for the generation, use and destruction of cryptographic keys must be fully documented.
  • Require key custodians to acknowledge and accept responsibilities of their role as such by use of a formal signature.
• Use
  • All protected data whether at rest or online, must be rendered unreadable. Techniques such as encryption, truncation, 1-way hashing, tokenization, etc
  • If disk encryption is used as opposed table or file encryption, tables in databases holding sensitive information must be protected using techniques listed above.
  • All data exchanged between systems and third parties must be done utilizing these strong encryption techniques.
  • Keys must be rotated at a minimum of 1-year intervals
• Destruction 
  • Old keys must be destroyed when no longer used, or confidence in the keys integrity may have become compromised.

Enforcement

Any employee found to have violated this procedure may be subject to disciplinary action by their administrative unit, the department, or the university.

OHIO PCI DSS - Awareness Program

Purpose

Implement a formal security awareness program to make all personnel aware of the importance of cardholder data security.

Scope

Training is required for any employee or contractor who interacts with the card holder environment or supports a secure payment card infrastructure.  Employee roles and responsibilities are defined as follows.

Chief Information Officer and Information Security Manager

The Chief Information Officer is responsible for coordinating and overseeing Ohio University’s compliance regarding the confidentiality, integrity, and security of its information assets. The Information Security Manager works closely with the Chief Information Officer and other Ohio University managers and staff involved in securing the university’s information assets to enforce established policies, identify areas of concern, and implement appropriate changes as needed.

OIT Infrastructure Team 

The OIT Infrastructure Team works with department system managers, administrators and users to develop security policies, standards and procedures to help protect the assets of Ohio University.

Human Resources The Human Resources Department will, when requested by the department, perform background checks including pre-employment, criminal, and credit history on all potential employees who will have access to systems, networks, or data that contain credit card information. 

University Departments

• Departments are responsible for ensuring that reference checks are done on all classified, administrative, and professional employees hired.
• When necessary, Departments will request that Human Resources conduct background checks including pre-employment, criminal, and credit history on all potential employees who will have access to systems, networks, or data that contain credit card information.
• Departments will notify Human Resource when classified, administrative, and professional employees are terminated.  This will result in the employees’ access being terminated for all university systems in which an OHIO id and password are required.  Departments are responsible for terminative access to any payment systems administered by the department. 
• Departments are responsible for ensuring employees responsible for processing credit card payment complete Cash Handling and Credit Card Security Awareness Training upon hire and at least annually.

Procurement and Contract Services 
Procurement and Contract Services will ensure third parties, with whom cardholder data is shared, are contractually required to adhere to the PCI-DSS requirements and to acknowledge they are responsible for the security of the cardholder data which they process.

Office of the BursarThe Office of the Bursar will verify with Departments that all employees responsible for processing credit card payments complete Cash Handling and Credit Card Security Awareness Training upon hire and at least annually.  If training is not completed, then the department’s merchant number will be deactivated.

Users of Computing and Information ResourcesEach user of Ohio University computing and information resources must realize the fundamental importance of information resources and recognize their responsibility for safekeeping those resources. The following are specific responsibilities of all Ohio University information system users:

• Understand what the consequences of their actions are with regard to computing security practices and act accordingly.  Embrace the “Security is everyone’s responsibility” philosophy to assist Ohio University in meeting its business goals. 
• Maintain awareness of the contents of information security policies.

Procedure

Security training is a compliance requirement, and must be taken annually.