Middlebury, VT Walk-in Helpdesk: Open 8:00 am - Midnight EST
Monterey, CA Walk-in Helpdesk: Open 9:00am - 5:00pm PST

Overview

In accordance with Payment Card Industry Data Security Standards (PCI DSS) V3.2 requirements, Middlebury has established this formal PCI Written Information Security Policy (PCI WISP). The PCI WISP specifically applies to payment card applications supported by the dedicated Payment Tech network, computing, and storage infrastructure, as explained in the section 3, Scope. This comprehensive policy document is to be implemented immediately along with all relevant and applicable standards, procedures and practices.

Purpose

This PCI WISP is designed to provide Middlebury with a documented and formalized written information security policy in accordance with Requirement 12.1 of the PCI DSS V3.2. This policy ensures Middlebury is complying with the PCI DSS V3.2 requirements. Compliance with the stated policy and separate supporting standards, procedures and guidelines helps ensure the safety and security of the Middlebury PCI system components within the cardholder data environment and any other environments deemed applicable.

Scope

This PCI WISP encompasses all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications. Examples of system components include but are not limited to the following:

  • Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE.
  • Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.
  • Network components including but not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances.
  • Server types including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).
  • Applications including all purchased and custom applications, including internal and external (for example, Internet) applications.
  • Any other component or device located within or connected to the CDE.

Management

Middlebury's Information Technology Services department is responsible for the management and annual evaluation of this policy. ITS and/or the Middlebury PCI Compliance Team may modify this policy from time to time provided that all modifications are consistent with the current PCI DSS. This PCI WISP will be published in the College Handbook and annual notification will be sent to staff. Failure to comply with the terms of this policy may result in disciplinary actions and could also limit a department’s payment card acceptance privileges.

Build and Maintain a Secure Network and Systems

Req 1.1.1 Formal Process for Testing and Approval of All Network Connections and Changes to Network Configurations

Middlebury will maintain a formal process for testing and approving all network connections, along with changes to network configurations as outlined in the Req 1.1.1 Formal Process for Testing and Approval of All Network Connections and Changes to Network Configurations standard operating procedure.

Req 1.1.2 – 1.1.3 Current Network Diagram with All Connections to Cardholder Data, Including Wireless Networks

Middlebury will maintain a current network diagram in adherence to below requirements:

  • A current network diagram exists and that it identifies and documents all connections between the cardholder data environment and other networks, including any wireless networks.
  • A current cardholder data flow diagram exists that identifies and documents all flows of cardholder data across all Payment Tech systems and networks.
  • Appropriate personnel are responsible for keeping all relevant network diagrams current and accurate.

Req 1.1.4 Firewall Requirements

Middlebury will maintain firewall configuration standards in adherence to below requirements:

  • Firewall configuration standards include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone.
  • The PCI Payment Tech network diagrams for the associated cardholder data environment (CDE) are to be consistent with the firewall configuration standards, which requires an illustrative drawing on the diagrams of the logical and/or physical positioning of the firewalls within the PCI Payment Tech network topology.
  • Authorized personnel are to regularly review network configuration documentation for the purposes of verifying that firewalls are in place at each Internet connection and between any DMZ and the internal network zone.

Req 1.1.5 Description of Groups, Roles and Responsibilities for Logical Management of Network Components

Middlebury will maintain a description of groups, roles and responsibilities for logical management of network components in adherence to below requirements:

  • Firewall and router configuration standards include a description of groups, roles and responsibilities for logical management of network components.
  • All personnel responsible for the logical management of network components are to be identified, with all contact information listed accordingly. This contact information must include, but is not limited to, the following: (1) name of responsible party and title, (2) contact email, (3) contact phone number, (4) name of group or division within the organization and (5) roles and responsibilities for individual.

Req 1.1.6 Documentation and Business Justification for Use of All Services, Protocols and Ports Allowed

Middlebury will maintain firewall and router configuration standards in adherence to below requirements:

  • Firewall and router configurations and/or configuration standards are to include a documented list of services, protocols and ports used and a business justification for why they are being used.
  • For all services, protocols and ports used, a brief description is to be given as to the function of each.
  • Any insecure services, protocols and ports used are to be identified, and the business justification for why they are being used must be given.

Req 1.1.7 Requirements to Review Firewall and Router Rules Sets at least Every Six (6) Months

Middlebury will maintain firewall and router rules sets in adherence to below requirements:

  • Review firewall and router rules sets every six (6) months.
  • Review firewall and router rules sets more frequently, if compelled by business and technical needs.
  • Provide a detailed description of each firewall and router appliance, date of review, discussion of changes made, if any, and the name and title of the individual reviewing the rules sets.

Req 1.2 – 1.2.3 Firewall and Router Configurations

Middlebury will maintain firewall and router configuration standards in adherence to below requirements:

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

    Note: An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.
     

  • Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.
  • Secure and synchronize router configuration files.
  • Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.

Req 1.3.1 – 1.3.8 DMZ Configuration and Internet Access to the Cardholder Data Environment

Middlebury will maintain DMZ configuration and Internet access to the cardholder data environment standards in adherence to below requirements:

  • Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
  • Limit inbound Internet traffic to IP addresses within the DMZ. Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.
  • Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network. (For example, block traffic originating from the Internet with an internal source address.)
  • Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
  • Implement stateful inspection, also known as dynamic packet filtering. (That is, only “established” connections are allowed into the network.)
  • Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.
  • Do not disclose private IP addresses and routing information to unauthorized parties.

    Note: Methods to obscure IP addressing may include, but are not limited to: Network Address Translation (NAT) Placing servers containing cardholder data behind proxy servers/firewalls, Removal or filtering of route advertisements for private networks that employ registered addressing, Internal use of RFC1918 address space instead of registered addresses.

Req 1.4 Personal Firewall Software

Middlebury will maintain Personal Firewall standards in adherence to below requirements:

  • Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network. Firewall configurations include:
    • Specific configuration settings are defined for personal firewall software.
    • Personal firewall software is actively running.
    • Personal firewall software is not alterable by regular users of mobile and/or employee-owned devices.
    • Administrators may disable the personal firewall software on their management laptops and other mobile management devices, as necessary, but only only when appropriate business needs arise, and only temporarily. Firewalls protecting administrator's laptops must be re-enabled as soon as possible, and the purposes for the temporary exception must be documented.

Req 2.1 – 2.1.1 Changing of Vendor Supplied Default Settings

Middlebury will change vendor default settings for all system components and wireless environments in adherence to below requirements:

  • Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocol (SNMP) community strings, etc.).
  • For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.

Req 2.2 – 2.2.4 Configuration Standards for All System Components

Middlebury will maintain configuration standards for all system components that address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Sources of industry-accepted system hardening standards may include, but are not limited to:

  • Center for Internet Security (CIS)
  • International Organization for Standardization (ISO)
  • SysAdmin Audit Network Security (SANS) Institute
  • National Institute of Standards Technology (NIST).
  • Vendor-specific tools and checklists, along with general setup and hardening procedures

When configuring system components within the cardholder environment, the following conditions must apply:

  • Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.) Note: Where virtualization technologies are in use, implement only one primary function per virtual system component
  • Enable only necessary services, protocols, daemons, etc., as required for the function of the system.
  • Implement additional security features for any required services, protocols, or daemons that are considered to be insecure—for example, use secured technologies such as SSH, SFTP, TLS, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.
    Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. Effective immediately, new implementations must not use SSL or early TLS. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30, 2016.
  • Configure system security parameters to prevent misuse.

Req 2.3 Non-Console Administrative Access

Middlebury will encrypt all Non-console Administrative Access using strong cryptography using technologies such as:

  • Secure Shell (SSH)
  • Virtual Private Network (VPN)
  • Transport Layer Security (TLS)

Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. Effective immediately, new implementations must not use SSL or early TLS. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30, 2016

Req 2.4 Inventory of System Components

Middlebury will maintain a current inventory of System Components considered in-scope for the cardholder data environment in adherence to the PCI DSS, including a description of the function/use for each.

Protect Cardholder Data

Req 3.1 - 3.3 Protect Stored Cardholder Data 

Middlebury maintains a PCI Policy for Accepting Credit Card and eCommerce Payments and a Record Retention Policy to address data retention and disposal of cardholder data. Middlebury does not store cardholder data upon completion of the authorization process. Middlebury does not electronically store cardholder data.

3.1 A quarterly process for identifying and securely deleting stored cardholder data is maintained in the Information Security - Auditing and Penetration Test - Standard Operating Procedures (SOP).

3.2.1 Middlebury does not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. Incoming transactions data sources including, but not limited to, will not store full track data:

  • All logs (for example, transaction, history, debugging, error)
  • History files
  • Trace files
  • Several database schemas
  • Database contents

If the PCI Compliance Team identifies a business need to store SAD/PAN, Middlebury will implement and maintain a process specifically addressing the following requirements:

  • Sensitive Authentication Data (SAD) Storage 
  • Primary Account Number (PAN) - Masking & Displaying the PAN Digits
  • Primary Account Number (PAN) System Protection
  • Disk Encryption 
  • Protection of Keys used for Encryption of Cardholder Data 
  • Key Management

Req 3.6 Key Management

Middlebury will maintain key-management processes and procedures for cryptographic keys used for encryption of cardholder data and system components that utilize key-management functions. The key-management processes and procedures with include the following:

  • Generation of strong cryptographic keys
  • Secure cryptographic key distribution
  • Secure cryptographic key storage
  • Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).
  • Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised. 

Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key-encryption key). Archived cryptographic keys should only be used for decryption/verification purposes.

  • If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.

Note: Examples of manual key-management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.

  • Prevention of unauthorized substitution of cryptographic keys.
  • Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities.

Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.

Req 4.1 Strong Cryptography and Protocols

Middlebury will employ Strong Cryptography and Protocols to protect card holder data during transmission over open and/or public networks, in adherence to below requirements:

  • Use strong cryptography and security protocols (TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public network. 
  • Ensure that:
    • Only trusted keys and/or certificates are accepted
    • the protocol is implemented to use only secure configurations; does not support insecure versions/configurations.
    • the proper encryption strength is implemented for the encryption methodology in use.
    • Only newer versions of TLS are enabled when cardholder data is transmitted or received (see Req 2.2 – 2.2.4 Configuration Standards for All System Components, for additional details).
  • Comprehensively document all locations where cardholder data is transmitted or received over open, public networks.
  • Regarding wireless transmissions, configure, examine, and confirm system settings and all necessary configurations for system components to ensure that industry best practices are used to implement strong encryption for authentication and transmission and that Weak encryption is not used as a security control for authentication or transmission.

Req 4.2 Unencrypted Primary Account Numbers (PAN)

Middlebury will ensure Unencrypted Primary Account Numbers (PAN) are not sent via end-user messaging technologies in adherence to below requirements:

  • Primary Account Numbers (PAN) will not be sent via unencrypted email.
  • Primary Account Numbers (PAN) will not be sent via an instant messaging protocol.
  • Primary Account Numbers (PAN) will not be sent via a chat protocol or forum sessions.
  • If for any reason, Primary Account Numbers (PAN) must be sent via end-user messaging technologies, they are to be sent using strong encryption, rendering the PAN unreadable.

Maintain a Vulnerability Management Program

Req 5.2 Antivirus

Middlebury will maintain a process for Antivirus in adherence to below requirements:

  • Antivirus software must be utilized for all computer and system components (any network component, server or application included in or connected to the cardholder data environment that is commonly affected by malicious software) within the cardholder environment.
  • For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.
  • The antivirus software utilized must be the most current version available.
  • The antivirus software must be active, must be scheduled to perform virus checks at regular intervals and must have its virus definition and all other associated software files kept current.
  • The antivirus software must be enabled for automatic updates.
  • The antivirus software must be configured to perform periodic scans.
  • The anti-virus solution must be configured to generate audit logs which are to be retained for one year, per PCI DSS Requirement 10.7
  • Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.
  • No user shall disable or tamper with the configuration of antivirus software installed on their respective computer.
  • Employees who attach workstations to the PCI Payment Tech network are responsible for ensuring that those workstations are running antivirus software and that a current virus signature is installed.

Req 6.1 - 6.2 Security Patch Management Installation

Middlebury will maintain a Patch and Vulnerability Management Program in adherence to below requirements

The Patch and Vulnerability Management Program will incorporate following initiatives:

  • A description of Groups, Roles and Responsibilities of the team responsible for patch management.
  • Comprehensive inventory of all system components directly associated with the cardholder environment.
  • Subscribing to industry-leading security sources, additional supporting resources for vulnerability announcements and other security patch management alerts and issues.
  • Procedures for establishing a risk ranking regarding security patch management. This will include but is not limited to (1) the significance of the threat, (2) the existence and overall threat of the exploitation and (3) the risks involved in applying security patch management procedures (its effect on other systems, resources available and resource constraints).
  • Procedures for the deployment, distribution and implementation of patches and other related security-hardening procedures.
  • Procedures for verifying successful implementation of patches and other related security-hardening procedures.
  • Installation of applicable critical vendor-supplied security patches within one month of release.
  • Installation of all applicable vendor-supplied security patches within an appropriate time frame (for example, within three months).

Req 6.3 Software Development Life Cycle

Middlebury does not develop payment-card handling applications. Should the institution, after careful consideration of the inherent risk and liability issues, opt to develop payment-card handling applications in the future, the institution will adopt a PCI DSS compliant Software Development Life Cycle.

Req 6.4 Change Control

Middlebury will maintain a Change Control process in adherence to the below requirements:

  • Establishment of change control:
    • initiation, implementation and authorization directives
    • lifecycle
    • minimum reporting criteria for change control documentation
  • Follow change control processes and procedures for all changes to system components. The processes must include the following:
    • Separate development/test environments from production environments, and enforce the separation with access controls.
    • Separation of duties between development/test and production environments
    • Production data (live PANs) are not used for testing or development
    • Removal of test data and accounts before production systems become active
  • Change control procedures for the implementation of security patches and software modifications must include the following:
    • Documentation of impact.
    • Documented change approval by authorized parties.
    • Functionality testing to verify that the change does not adversely impact the security of the system.
    • Back-out procedures.

Req 6.5 – 6.5.10 Software Development Secure Coding Guidelines and Training

Middlebury does not develop payment-card handling applications. Should the institution, after careful consideration of the inherent risk and liability issues, opt to develop payment-card handling applications in the future, the institution will adopt a PCI DSS compliant Software Development Secure Coding Guidelines and appropriate Training processes.

Implement Strong Access Control Measures

Req 7.1 – 7.3 Data Control & Access Control

Middlebury will maintain Data Control & Access Control processes in adherence to the below requirements:

  • Limit access to system components and cardholder data to only those individuals whose job requires such access.
  • Access needs are to be defined for each respective role, specifically:
    • System components and data resources that each role needs to access for their job function.
    • Level of privilege required for accessing resources.
  • Access rights for privileged users are restricted to the least privileges necessary to perform job responsibilities.
  • Privileges are assigned to individuals based on job classification and function, such as Role-Based Access Control (RBAC).
  • An authorization form is required for all access, which must specify required privileges, and must be signed by management.
  • Access controls are implemented via an automated access control system.
  • Access control systems:
    • are in place on all system components.
    • are configured to enforce privileges assigned to individuals based on job classification and function.
    • have a default Deny All setting.

Req 8.1 – 8.4 Unique ID & Authentication Methods

Middlebury will maintain Unique ID & Authentication processes in adherence to the below requirements:

  • All users are assigned a unique ID before allowing them to access system components or cardholder data.
  • Authorized personnel are to control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
  • Terminated users are to have their access immediately revoked.
  • Inactive user accounts are to be disabled and/or removed within 90 days.
  • Authorized personnel are to manage IDs used by vendors to access, support, or maintain system components via remote access as follows:
    • Enable vendor access only during the time period needed and disabled when not in use.
    • Actively monitored when in use by all appropriate means.
  • The following best practices are to be implemented regarding accepts attempts and system idle time:
    • Limit repeated access attempts by locking out the user ID after not more than six attempts.
    • Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
    • If a session has been idle for more than 15 minutes, require the user to reauthenticate to re-activate the terminal or session.
  • All users are to be assigned a unique ID for access to system components or cardholder data and must also utilize one of the following methods for authentication: 
    • (1) Something that is known, such as a password or passphrase. 
    • (2) Something you have, such as a token device, smart card, dynamically generated unique identifier, etc. 
    • (3) Something you are, such as biometrics (palm and fingerprint readers, iris recognition, etc.).
  • Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.
  • Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys.
  • Passwords/phrases must meet the following conditions in accordance with PCI DSS mandates:
    • A minimum length of at least seven characters:
    • Contain both numeric and alphabetic characters.
    • The passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.
    • Passwords/passphrases changed at least once every 90 days.
    • Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.
    • Set passwords/phrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.
  • Incorporate two-factor authentication for remote access (network-level access originating from outside the PCI Payment Tech network) to the PCI Payment Tech network by employees, administrators and third parties.

Req 8.5 – 8.6 Shared, Group, Generic, and Other Authentication Methods

Middlebury will maintain Shared, Group, Generic and Other Authentication processes in adherence to the below requirements:
 

  • Ensure that system administrators understand that group and shared IDs and/or passwords or other authentication methods are not distributed, even if requested.
  • Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
    • Generic user IDs are disabled or removed.
    • Shared user IDs do not exist for system administration and other critical functions.
    • Shared and generic user IDs are not used to administer any system components.
  • Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:
    • Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
    • Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.

Req 8.7 Database Access & Configuration Settings

Middlebury will maintain Database Access & Configuration Settings processes in adherence to the below requirements:

  • All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:
    • All user access to, user queries of, and user actions on databases are through programmatic methods.
    • Only database administrators have the ability to directly access or query databases.
    • Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

Req 9.1 Physical Security

Middlebury will maintain security measures, which includes all necessary physical security controls, such as those related to the safety and security of Middlebury’s PCI Payment Tech network system components. This requires the use of data centers that are secured and monitored at all times and whereby only authorized personnel have physical access to the specified system components. Thus, "secured" and "monitored" implies that the facility has in place the following physical security and environmental security controls:

  • Constructed in a manner allowing for adequate protection of all system components. 
  • Security alarms that are active during non-business hours, with alarm notifications directly answered by Public Safety. 
  • The use of cages, cabinets, or other designated, secured areas for securing the specified system components. 
  • Access control mechanisms consisting of traditional lock and key, and/or electronic access control systems (ACS), such as badge readers. 
  • Furthermore, all electronic access control mechanisms are to record all activity and produce log reports that are retained for a minimum of 90 days. 
  • Appropriate fire detection and suppression elements, along with fire extinguishers placed in mission critical areas. 
  • Appropriate power protection devices for ensuring a continued, balanced load of power to the specified system resource, thus mitigating power surges and spikes.

Req 9.2 – 9.4 Personnel and Visitor Access

Middlebury will ensure Personnel and Visitor access in adherence to the below requirements:

Verification of Identity

The identity of all individuals accessing facilities and locations transmitting, processing, and/or storing cardholder data must be verified prior to their entrance. All unknown individuals must present their identification to access the facility , and all visitors must provide evidence of their identity and be approved by a Middlebury employee prior to being granted access to the facility. Visitors are to be accompanied at all times.

Visitors are required to sign in, obtain and wear a specially assigned Visitor badge. The visitor badge may not be granted access privileges to areas which transmit, process, and/or store cardholder data, unless specifically authorized by management. Visitor badges are to be returned to the front desk or receptionist at the end of business day. The employee which is authorizing their presence is responsible for ensuring that the visitor wears the badge at all times, and returns, adhering to this policy. Employees should feel empowered by management and trained to ask any individuals who are not wearing a visitor badge as to their purpose in the building. Visitors are authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained.

Visitor Logs

Logs are to be recorded and retained for the visitor’s entrance into the facility. The logs are to record the person’s name, company, purpose, employee visiting/authorizing the visit, and date and time. The logs are retained for a minimum of 90 days in the PCI Documentation Reference Sheet and Documentation folder.

Req 9.5 – 9.7.1 Media Storage, Distribution and Classification

Middlebury does not store payment card data in either electronic or written format. The Middlebury PCI Policy for Accepting Credit Card and eCommerce Payments addresses Storage and Distribution (Transmitting). If the PCI Compliance Team determines a business need to store Media (payment card data), in adherence to the below requirements, processes will be developed:

  • Controls for physically securing all media (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes) are to be in place for protecting cardholder data.
  • Media backups are to be stored in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location’s security at least annually.
  • All media is to be Classified as “Extremely Sensitive Data” per the Data Classification Policy.
  • All media is to be sent by secured courier or other delivery method, so that it can be accurately tracked.
  • Management is to approve any and all media that is moved from a secured area (including when media is distributed to individuals).
  • Strict control is to be maintained over the storage and accessibility of media.
  • Inventory logs of all media are to be maintained, with media inventory procedures undertaken at least annually.

Req 9.8 Media Destruction

Middlebury maintains a PCI Policy for Accepting Credit Card and eCommerce Payments addressing Media Destruction in adherence to the below requirements:

  • Once the maximum retention period (Middlebury’s retention period is zero) has been allotted for cardholder data, it must be removed from all electronic media, and any hardcopy edition must be disposed of accordingly.
  • Cardholder data on electronic media is to be rendered unrecoverable so that cardholder data cannot be reconstructed, such as utilizing a secure wipe program in accordance with industry-accepted standards for secure deletion or otherwise physically destroying the media such as degaussing. Thus, configure, examine, and confirm system settings and all necessary configurations for system components to ensure that cardholder data on electronic media is rendered unrecoverable.

Regularly Monitor and Test Networks

Req 10.1 - 10.3.6 Audit Trails and Logging

Middlebury will configure comprehensive auditing and logging on all in-scope system components to ensure that:

  • Audit trails link all access to system components to individual users
  • Automatic auditing is configured sufficient to reconstruct the following events:
    • All individual user accesses to cardholder data
    • All actions take 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—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges.
    • Initialization, stopping, or pausing of the audit logs
    • Creation and deletion of system level objects
  • Automatic auditing mechanisms record, at a minimum: 
    • user identification, 
    • type of event, 
    • date and time, 
    • success or failure, 
    • origination of event, 
    • identity or name of affected data, system component, or resource.

Req 10.4 Time-Synchronization Technology

Middlebury will maintain Time-Synchronization Technology processes in adherence to the below requirements:

  • Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. Note: One example of time synchronization technology is Network Time Protocol (NTP).
  • Critical systems have the correct and consistent time.
  • Time data is protected.
  • Time settings are received from industry-accepted time sources.

Req 10.5 Securing of Audit Trails

Middlebury will maintain a process for securing audit trails in adherence to the below requirements:

  • Only individuals with a job-related need can view audit trail files. 
  • Current audit trail files are to be protected at all times from unauthorized modifications via access control mechanisms, physical segregation and/or network segregation.
  • Audit trail files are to be promptly backed up to a centralized log server or media that is difficult to alter.
  • Logs for external-facing technologies are to be written onto a secure, centralized, internal log server or media.
  • Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts.

Req 10.6 Security Logs & Events

Middlebury will maintain Security Operations processes in adherence to the below requirements:

  • Daily review, either manually or via a log tool, for the purposes of identifying anomalies or suspicious activity on the following components:
    • Logs of all system components that store, process, or transmit CHD and/or SAD
    • Logs of all critical system components
    • Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)
  • Periodic review of logs for all other system components based on Middlebury’s policies and risk management strategy, as determined by Middlebury’s annual risk assessment.
  • Follow up on any exceptions and anomalies identified during the review process.
  • All audit trail history files are to be retained for at least one year, with a minimum of three months immediately available for analysis.

Req 10.7 Audit Trail History

Middlebury will retain audit trail history in adherence to the following guidelines:

  • Audit trail history will be retained for a period of at least one year.
  • A minimum of three months of audit trail history will be immediately available for analysis, i.e. available online.

Req 11.1 Wireless Security & Access Points

Middlebury does not employ wireless networking (Wi-Fi) for legacy, non-P2PE payment card applications. Mobile payment processing solutions are only supported on P2PE or cellular networks.

The Req 11.1 Unauthorized Wireless Access Point Protection process describes the methods Middlebury uses to police its Payment Tech network to ensure that unauthorized wireless access points are not attached to it, including Incident Response procedures to be followed if an unauthorized wireless access point is detected.

Req 11.2 – 11.2.3 Vulnerability Scans

Middlebury’s Patch and Vulnerability Management Program describes vulnerability scanning processes in adherence to the below requirements:

  • Run internal and external network vulnerability scans at least quarterly and after any significant change in the PCI Payment Tech network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
  • Perform quarterly internal vulnerability scans and rescans as needed, until all “high-risk” vulnerabilities (as identified in Requirement 6.1) are resolved. 
  • Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.
  • Review the results of each quarterly scan and rescan to verify that the ASV Program Guide requirements for a passing scan have been met (for example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic failures).
  • Review the scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV).
  • Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.
  • Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

Req 11.3 – 11.3.4 Penetration Testing

Middlebury will maintain Penetration Testing procedures (Information Security - Auditing and Penetration Test - Standard Operating Procedures (SOP)) in adherence to the below requirements:

  • Implement a methodology for penetration testing that includes the following:
    • Is based on industry-accepted penetration testing approaches.
    • Includes coverage for the entire CDE perimeter and critical systems.
    • Includes testing from both inside and outside the PCI Payment Tech network.
    • Includes testing to validate any segmentation and scope-reduction controls.
    • Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5.
    • Defines network-layer penetration tests to include components that support network functions as well as operating systems.
    • Includes review and consideration of threats and vulnerabilities experienced in the last 12 months.
    • Specifies retention of penetration testing results and remediation activities results.
  • Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification.
  • Ensure that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
  • Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections.
  • If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.

Req 11.4 – 11.5.1 Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), Change Detection Software (CDS)

Middlebury will maintain Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), Change Detection Software (CDS) processes in adherence to the below requirements:

  • Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. 
  • Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.
  • Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.
  • Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. Note: For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change-detection mechanisms such as file-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).
  • Implement a process to respond to any alerts generated by the change-detection solution.

Maintain an Information Security Policy

Req 12.2 Risk Assessment

Middlebury conducts risk assessments of in-scope applications and systems, following processes outlined in the Req 12.2 Annual Risk Assessment Program, which adheres to the following requirements:

  • Is performed at least annually and upon significant changes to the environment (For example, acquisition, merger, relocation, etc.).
  • Identifies critical assets, threats, and vulnerabilities, and
  • Results in a formal, documented analysis of risk. Examples of risk-assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.

Req 12.3 Usage for Critical Employee-Facing Technologies

Middlebury grants access to critical employee-facing technologies in the Payment Tech environment contingent upon compliance with the following requirements

  • Identify critical technologies in use.
  • Explicit consent from authorized parties is required to use the technologies.
  • All technology use must be authenticated with user ID and password or other authentication item (for example, token).
  • A list of all devices and personnel authorized to use the devices will be maintained.
  • All devices will be labeled with information that can be correlated to owner, contact information and purpose.
  • The only acceptable use of devices within the Payment Tech environment is to support Middlebury’s payment card applications. All other, non-business uses are strictly prohibited. Require acceptable uses for the technology.
  • Require acceptable network locations for the technology.
  • Critical-Employee facing technologies may only be accessed at approved locations listed in the PCI Asset Inventory.
  • Payment card transactions may only be completed using the list of Middlebury approved application maintained in the PCI Asset Inventory. 
  • Remote Access sessions will be configured to automatically disconnect after 15 minutes of inactivity. 
  • Remote access technologies used by vendors and business partners will only be activated when needed by vendors and business partners, and will be immediately deactivated after use.
  • Copying, moving or storage of cardholder data onto local hard drives and removable electronic media when accessing such data via remote access technologies, is explicitly prohibited, unless explicitly authorized for a defined business need

Req 12.4 – 12.5.5 Information Security Responsibilities

The following functional areas and roles are responsible for security operations, administration, and governance of the Payment Tech environment. Managers may delegate operational tasks to appropriately trained individuals, but are ultimately responsible for the assigned work.

Information Security Management and Governance ITS ISI - Director

Establish, document, and distribute security policies and procedures.

PCI Compliance Team
ITS ISI - InfoSec Workgroup Manager

Monitor and analyze security alerts and information, and distribute to appropriate personnel.

ITS ISI - InfoSec Workgroup Manager
ITS ISI - CSNS Workgroup Manager
ITS US - Help Desk Manager - Service Requests

Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations. ITS ISI - InfoSec Workgroup Manager
Administer user accounts, including additions, deletions, and modifications.

ITS ISI - InfoSec Workgroup Manager
ITS ISI - CSNS Workgroup Manager

Monitor and control all access to data.

ITS ISI - InfoSec Workgroup Manager
ITS ISI - CSNS Workgroup Manager

Req 12.6 Formal Security Awareness Program

Middlebury will maintain a formal Security Awareness Program in adherence to the below requirements:

All persons with physical and logical access to Middlebury’s environment, whether employees, third-parties, service providers, contractors, temporary employees, and/or other staff members, must be trained on their role in protecting Middlebury from threats to help safeguard Middlebury’s finances, operations, and brand name.

Upon hire and at least annually, all users connected to Middlebury’s cardholder data environment (in any way), are to complete the Security Awareness Training program. The computer based training program consists of a Security Awareness Video, the PCI Policy, and a PCI Policy Confidentiality Statement to be electronically signed by all agents.

Upon hire and at least annually, MDRP’s in departments with card present processing hardware, are to complete a training on physical inspection and skimming prevention hosted by Information Security.
All agents of the College must read and electronically sign the Confidentiality agreement in agreement with Middlebury’s terms and conditions and acknowledgment of their role in safeguarding Middlebury’s environment on an annual basis.

In addition to the above, those who have admin or privileged access (ITS staff) or roles with systems which transmit, process, and store cardholder data must receive additional technical training to further reinforce and supplement their knowledge of security practices. ITS staff are required to read the Middlebury PCI WISP and acknowledge their role in safeguarding Middlebury’s environment, by electronically signing the ITS version of the PCI Training and Confidentiality Agreement upon hire and on an annual basis.

Attendance logs for those who attend Security Awareness and Physical Inspection-Skimming Prevention training, provided upon hire and annually, must be kept by Information Security and provided to the PCI Compliance Team.

Req 12.8 Management of Service Providers

Service Providers (third parties) are contractually required to adhere to the PCI DSS requirements. Due diligence must be exercised before engaging with any service providers that may affect or have a relationship or function associated with Middlebury‘s cardholder data environment. The written agreement shall include an acknowledgement by the service providers of their responsibility for securing cardholder data and breach liability language, see Data Privacy and Breach Notification.

Note: This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities.

Each Merchant Department must obtain the appropriate PCI Compliance documentation, from Service Providers, on an annual basis (prior to expiration date of the current documentation). The MDRP is responsible for sending the updated PCI Compliance documentation to the PCI Compliance Team upon receipt from the Service Provider.
Information Technology Services is responsible for obtaining the appropriate PCI Compliance documentation from managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities.

  • Service Providers must provide either an SAQD-Service Provider AOC or an On-Site Assessment AOC for Service Providers. AOC’s must note specific requirements Service Provider is attesting to.
  • Service Providers must provide a current quarterly vulnerability scan from their ASV.
  • Verify Payment Applications are validated on the PA DSS List of Validated Payment Applications.

The PCI Compliance Team will maintain a collective, current and accurate list of Service Providers with the following information:

  • Service Provider Name
  • Service being provided - description
  • PCI Validation Required
  • Validation Date
  • Expiration Date
  • Assessor
  • Functional Area
  • MDRP Responsible

Req 12.10 Incident Response Plan

Middlebury will maintain an Incident Response Plan in adherence to the below requirements:

  • Includes, at a minimum, roles, responsibilities and communication strategies in the event of a compromise, including, also at a minimum, notification of the payment brands.
  • Includes specific incident response, business recovery and continuity procedures and data backup processes.
  • Includes legal requirements for reporting any compromises to the cardholder data environment.
  • Includes coverage and response mechanisms for all critical system components and all other IT resources deemed critical by Middlebury.
  • Includes reference or inclusion of incident response procedures from the payment brands.
  • Is to be tested annually.
  • Designated personnel are available for 24/7 incident response and monitoring coverage for any evidence of unauthorized activity, detection of unauthorized wireless access points, critical Intrusion Detection Systems (IDS) alerts and/or reports of unauthorized critical system or content file changes.
  • Staff with responsibilities for security breach responses are periodically trained.
  • Monitoring and responding to alerts from security systems including detection of unauthorized wireless access points constitute an important component of the Incident Response plan.
  • Processes are in place to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments as needed.

Glossary and References

Key Terms and Phrases

Access Control: Mechanisms that limit availability of information or information-processing resources only to authorized persons or applications

Breach: Any payment card data exposed by negligence or malice constitutes a reportable breach

Cardholder Data: The Primary Account Number (PAN) may also appear in the form of the full PAN, plus any of the following; Cardholder name, Expiration date, Service code

Card Verification Code or Value: Data element on a card's magnetic stripe that uses a secure cryptographic process to protect data integrity on the stripe and reveals any alteration or counterfeiting (referred to as CAV, CVC, CVV or CSC, depending on payment card)

  • CAV – Card Authentication Value (JCB payment cards)
  • CVC – Card Validation Code (MasterCard payment cards)
  • CVV – Card Verification Value (Visa and Discover payment cards)
  • CSC – Card Security Code (American Express)

Data: Pieces of information from which intelligible information is derived. Data are a collection of information or facts usually gathered as the result of experience, observation, experiment or processes within a computer system or premises. Data may consist of numbers, words or images, particularly as measurements or observations of a set of variables. They are often viewed as the lowest level of abstraction from which information and knowledge are derived.

Database: Structured format for organizing and maintaining easily retrievable information. Simple database examples are tables and spreadsheets.

Degaussing: Also called disk degaussing, it is the process or technique that demagnetizes the disk so that all data stored on the disk are permanently destroyed.

Disk Encryption: Technique or technology (either software or hardware) for encrypting all stored data on a device (e.g., hard disk, flash drive). Alternatively, File-Level Encryption or Column-Level Database Encryption is used to encrypt contents of specific files or columns.

Encryption: Process of converting information into a form only intelligible to holders of a specific cryptographic key. The use of encryption protects information between the encryption process and the decryption process (the inverse of encryption) against unauthorized disclosure.

Full Magnetic Stripe Data: Also referred to as track data. Data encoded in the magnetic stripe or chip is used for authorization during payment transactions. It can be the magnetic stripe image on a chip or the data on the Track 1 and/or Track 2 portion of the magnetic stripe. Entities are prohibited from retaining full magnetic stripe data after obtaining transaction authorization.

Managed Service Providers: A managed services provider (MSP) is most often an information technology (IT) services provider that manages and assumes responsibility for providing a defined set of services to its clients either proactively or as the MSP (not the client) determines that services are needed. Managed Services can include, but are not limited to: Backup, Data Recovery, Storage, Security, Network Management, Management Information Systems, Systems Management and Data Management. 

Media: refers to all paper and electronic media containing cardholder data.

Onsite Personnel: “Onsite personnel” refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entity’s premises.

Primary Account Number (PAN): Acronym for primary account number and also referred to as account number. Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account. 

Removable Electronic Media: Media that store digitized data and can be easily removed and/or transported from one computer system to another. Examples of removable electronic media include CD-ROM, DVD-ROM, USB flash drives and removable hard drives.

Sanitization: Process for deleting sensitive data from a file, device or system or for rendering data useless if accessed in an attack

Secure Wipe: Also called secure delete, this is a program utility used to delete specific files permanently from a computer system.

Sensitive Areas: Examples include corporate database server rooms, back-office rooms at retail locations that store cardholder data, and storage areas for large quantities of cardholder data. 

Sensitive Authentication Data: Security-related information (card validation codes/values, full magnetic stripe data, PINs and PIN blocks) used to authenticate cardholders, appearing in plain-text or otherwise unprotected form

Service Code: Three- or four-digit value in magnetic stripe that follows the expiration date of the payment card on the track data. It is used for various things such as defining service attributes, differentiating between international and national interchange or identifying usage restrictions.

Service Provider: Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities.

System Components: Any network component, server or application included in or connected to the cardholder data environment

Visitor: A “visitor” refers to a vendor, guest of any onsite personnel, service workers, or anyone who needs to enter the facility for a short duration, usually not more than one day.

References

Information Technology Services
Davis Family Library 202
Middlebury, VT 05753

helpdesk@middlebury.edu
(802) 443-2200