PCI Compliance Policy

1        INTRODUCTION AND SCOPE

1.1       Introduction

This document explains Val K Consulting LLC’s information security requirements for all employees. Val K Consulting LLC’s management has committed to these policies to protect information utilized by Val K Consulting LLC in attaining its business goals. All employees are required to adhere to the policies described in this document.

 

1.2       Regulatory Compliance

The Payment Card Industry Data Security Standard (PCI DSS) Program is a mandated set of security standards that were created by the major credit card companies to offer merchants and service providers a complete, unified approach to safeguarding credit cardholder information for all credit card brands.

 

In September of 2006, a group of five leading payment brands including American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International jointly announced the formation of the PCI Security Standards Council, an independent council established to manage the ongoing evolution of the PCI standard. Concurrent with the announcement, the council released version 1.1 of the PCI standard.

 

The PCI Data Security Standard requirements apply to all payment card network members, merchants and service providers that store, process or transmit cardholder data. The requirements apply to all methods of credit card processing, from manual to computerized; the most comprehensive and demanding of which apply to e-commerce websites, and retail POS systems that process credit cards over the internet.

 

During normal course of compliance and reporting activities Val K Consulting LLC will ensure that proper scoping of compliant PCI operations and reporting are in effect.

 

1.3       Scope of Compliance

This Information Security Policy applies to all “system components.” System components are defined as any network component, server, or application that is included in or connected to the company’s information environment. The company information environment is that part of the network that possesses company information. For example, the following types of systems would be in scope for compliance within any environment:

 

  • Systems storing company information (e.g. databases, PC’s used by accounting for generating reports)
  • Systems processing company information (e.g. web servers, application servers, etc.)
  • Network devices transporting or directing company information traffic (e.g. border router, DMZ firewall, intranet firewall, etc.)
  • Devices that create media containing company information (e.g. fax machine, printer, backup tape silo)
  • Support systems (e.g. Active Directory, PC’s performing support functions such as system administration, etc.)

 

2        POLICY ROLES AND RESPONSIBILITIES

2.1       Policy Applicability

All employees, contractors, vendors and third-parties that use, maintain or handle Val K Consulting LLC information assets must follow this policy.

 

2.2       Role of Chief Technical Officer

The Chief Technical Officer is responsible for coordinating and overseeing Val K Consulting LLC’s compliance with policies and procedures regarding the confidentiality, integrity and security of its information assets.

 

The Chief Technical Officer will work closely with the other Val K Consulting LLC managers and staff involved in securing the company’s information assets to enforce established policies, identify areas of concern, and implement appropriate changes as needed. Specific responsibilities of the Chief Technical Officer include:

 

  • Make high-level decisions pertaining to the information security policies and their content. Approve exceptions to these policies in advance on a case-by-case basis.
  • On an annual basis, coordinate a formal risk assessment to identify new threats and vulnerabilities and identify appropriate controls to mitigate any new risks.
  • At least annually review the Information Security policies and procedures to maintain adequacy in light of emergent business requirements or security threats.
  • Make sure that third parties, with whom company information is shared, are contractually required to adhere to the PCI DSS requirements and to acknowledge that they are responsible for the security of the company information which they process.

 

2.5       Users

Each user of Val K Consulting LLC computing and information resources must realize the fundamental importance of information resources and recognize their responsibility for the safekeeping of those resources. Users must guard against abuses that disrupt or threaten the viability of all systems. The following are specific responsibilities of all Val K Consulting LLC 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 Val K Consulting LLC in meeting its business goals.
  • Maintain awareness of the contents of the information security policies.
  • Classify confidential and sensitive information that is received unclassified. Limit the distribution of this information accordingly.

 

2.6       Role Assignment

Val K Consulting LLC uses role-based access control (RBAC) to restrict data resource access to unauthorized subjects. All personnel are assigned appropriate roles before they can exercise permissions and access data resources. Each role is connected to data resource access needs and a level of privilege as defined in Appendix Q2.

Roles are based on individual personnel’s job classification and function. All privileged user IDs are granted the least privilege necessary to perform job responsibilities. The security team is responsible for assigning roles with corresponding level of privilege and provides documented approval for each role in appendix Q1.

 

4        DATA CLASSIFICATION AND CONTROL POLICY

4.1       Policy Applicability

All data stored and accessed on Val K Consulting LLC information systems, whether managed by employees or by a third party, must follow this policy. Policy exemptions will be permitted only if approved in advance and in writing by the COO.

 

4.2       Data Classification

4.2.1      Introduction

All data stored on Val K Consulting LLC computing resources must be assigned a classification level by the information owner or creator. This level is used to determine which users are permitted to access the data.

 

4.2.2     Val K Consulting LLC Internal Information Categories

Confidential - applies to the most sensitive business information which is intended strictly for use within Val K Consulting LLC. Unauthorized disclosure could seriously and adversely impact the company, stockholders, business partners, and/or its customers.

Confidential information includes:

  • Passwords
  • Encryption keys
  • Cardholder information
  • Bank account information
  • Intellectual property

 

Sensitive - Applies to less sensitive business information, which is intended for use within Val K Consulting LLC. Unauthorized disclosure could adversely impact the company, its stockholders, its business partners, and/or its customers.

Sensitive information includes:

  • Internal market research
  • Audit reports, etc.

 

Private - Applies to personal information, which is intended for use within Val K Consulting LLC.

  • Unauthorized disclosure could adversely impact the company and/or its employees.
  • Examples of Private information include: policies and procedures, procedure metrics, human resources information, etc.

 

Public - Applies to all other information which does not clearly fit into any of the above three classifications. Unauthorized disclosure isn’t expected to seriously or adversely impact the company. Any release of this information must be authorized by the COO or CEO. Public information includes:

 

PCI Data – The class of credit card and transaction data identified for protection under the Payment Card Industry (PCI) Data Security Standard (DSS). Two types of data are defined: Cardholder Data which may be stored after transaction authorization and Sensitive Authentication Data which may not be stored after transaction authorization.

  • Card Holder Data – Applies to credit card data taken as payment for services. Data elements as specified in the PCI DSS version 3.2 are
    • Primary Account Number (PAN)
    • Card holder Name
    • Service Code
    • Expiration Date
  • Sensitive Authentication Data – Applies to credit card data required for authentication and processing of credit card transactions as specified in the PCI DSS version 3.2 are
    • Full Track Data
    • CAV2/CVC2/CVV2/CID
    • PIN/PIN Block

 

4.3       Data Access

All confidential or sensitive data must be protected via access controls to ensure that data is not improperly disclosed, modified, deleted or rendered unavailable. The access controls must track all access to such data and identify who and when the data was accessed .

 

4.4       Physical Security

Hard copy materials and electronic media containing sensitive or confidential information must be protected by appropriate physical access controls.

  • Cameras must be used to monitor server closets and data centers where systems reside that store sensitive, confidential, and cardholder data. The data collected must be stored for at least 3 months unless otherwise restricted by law.
  • Appropriate facility controls must be used to limit and monitor physical access to systems that store confidential or sensitive data.
  • Visitor logs and physical audit trails of access to these systems must be collected and kept at least 3 months unless otherwise restricted by law.
  • Physical access must be restricted to publicly accessible network jacks, wireless access points and handheld devices.

4.5       User Authentication

4.5.1      Users

Each user’s access privileges shall be authorized according to business need. User access authority to computer resources shall be provided only when necessary to perform tasks related to Val K Consulting LLC business.

 

The use of non-authenticated (e.g., no password) User IDs or User IDs not associated with a single identified user are prohibited. Shared or group user IDs are never permitted for user-level access. Every user must use a unique user account and a personal secret password for access to Val K Consulting LLC information systems and networks. Systems and applications must authenticate using a password or token entry.

 

All users must acknowledge understanding of the Val K Consulting LLC Information Security Policies by reading and signing the Val K Consulting LLC Security Acknowledgment and Acceptable Use Policy (Appendix A) prior to being allowed to access Val K Consulting LLC information systems and networks.

4.5.2      Systems

Each computer system shall have an automated or procedural access control process. The process requires the following:

 

  • Generic user IDs or passwords are disabled or removed.
  • User ID’s shall consist of at least 7 characters.
  • User ID’s will be unique for each user.
  • Authenticate every system account and application account with a password.
  • Require all passwords/passphrases to be at least 7 characters in length.
  • Require complex passwords, consisting of both numeric and alphabetic characters.
  • Require that new passwords cannot be the same as the four previously used passwords.
  • Lock out user ID after not more than six invalid logon attempts.
  • Require that once a user ID is locked out, it remains locked for at least 30 minutes or until the System Administrator enables the user ID.
  • Require system/session idle time out of 15 minutes.
  • Require passwords to be reset at least every ninety (90) days.
  • Remove/disable inactive user accounts at least every ninety (90) days.

The requirements above are for authenticating all system users.

 

4.6       Account and Access Management

4.6.1      Information Security Team Responsibilities

The Information Security Team will approve access authorization according to the role and responsibilities of information system users. Each request for access must contain written and/or electronic evidence of approval by the Information Security Team.

 

Information Security, in conjunction with business unit management, will determine the default access levels that will be granted per a user’s role (see section 2.6). The Information Security Team will perform a bi-annual audit of computer resource authorizations to confirm that access privileges are appropriate. The audit will consist of validating access rights for sample user populations.

The Information Security Team must collect additional approvals for all access that is not associated with a defined access role. Extension authorizations for contractor accounts must go through the Information Security Team to provide an audit trail. An Emergency ID will be established when access is needed to diagnose and/or correct a problem.

 

  • The request to create the Emergency ID must be made via the Information Security Team, which will notify the appropriate system administration team.
  • The requestor must inform the Information Security Team upon completion of the work so that the ID can be disabled.
  • The Information Security Team will ensure that the Emergency ID Request Form is completed as soon as practical (the completion of this form should NOT delay providing access). The completed form must be filed by the Information Security Team

 

4.6.2      System Administrator Responsibilities

Account creation requests must specify access either explicitly or via a “role” that has been mapped to the required access. New accounts created by mirroring existing user accounts must be audited against the explicit request or roles for appropriate access rights. If a user requests a password reset via phone, email, web or other non-face-to-face method, that user’s identity must be verified before the password is reset.

 

Access should be removed immediately upon notification that access is no longer required. Written procedures must be in place to ensure that access privileges of terminated or transferred users are revoked as soon as possible. Whenever possible users who are on leave-of-absence or extended disability should be suspended from the system.

 

User IDs shall be disabled after sixty (60) days of inactivity. After an additional thirty (30) days, disabled user IDs must be purged. These requirements may not apply to certain specialized accounts (e.g., NT Admin, root). In those instances, the System Administrator must provide a written waiver to the Information Security Team and document the compensating controls around access to the accounts.

 

All computer resources capable of displaying a custom sign-on or similar message must display the following message as part of the login process:

This system is for the use of authorized users only. Individuals using this computer system without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. In the course of monitoring individuals improperly using this system, or in the course of system maintenance, the activities of authorized users may also be monitored.

 

Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials.

 

  • System Administrators must enable audit logs to record user and administrative activities. Audit logs must be archived for a minimum of one year with (90) days available for on-line viewing.
  • Passwords set by System Administrators must be changed by the user immediately upon the user’s next login. System Administrators must set initial passwords that are unique and compliant with the password rules.
  • System Administrators must validate the identity of the user before performing a password reset. Business units must create local policies for positively validating user identities.
  • Contractor accounts must have Information Security Team approval and must automatically expire at the end of the contract date. Extensions must be requested through the Information Security Team. System Administrators must monitor these accounts carefully while they are in use.
  • Access must be immediately revoked for terminated users and for user access that is no longer required.
  • Vendor accounts used for remote maintenance must only be enabled during the time that access is needed.
  • Ensure that all systems and especially access to any databases containing cardholder information is authenticated (e.g., users, applications, administrators, etc.).

 

5        DATA RETENTION AND DISPOSAL POLICY

5.1       Policy Applicability

All data deemed sensitive or confidential by the Information Security Team, which is stored on Val K Consulting LLC networks and systems must follow this policy. Exemptions from this policy will be permitted only if approved in advance and in writing by the Chief Technical Officer.

 

5.2       Retention Requirements

All sensitive and confidential data, regardless of storage location, will be retained only as long as required for legal, regulatory and business requirements. The specific retention length will be established by the Data Owner under advisement form the General Counsel.

 

5.2.1      Sample Data Types and Data Retention

 

Data Type Data Retention Period
Confidential 10 years
Sensitive 7 years
Private 5 years
Public 3 years
PCI Data (Card Holder Data) 18 months
PCI Data (Sensitive Authentication Data)*

 

Never stored beyond authorization of

payment transaction

*As a special case, cardholder data used for single transactions may be kept for up to 120 days. Cardholder data utilized for recurring transactions will be retained for the lifetime of the customer’s account with %Company%. Once a customer’s account is disabled or terminated, all of the cardholder data for that merchant must be purged within 120 days of the termination using an approved destruction method. Sensitive Authentication 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. Business units will create local policies for retention of all other company information. All system and network audit logs must be retained for one year with 90 days minimum kept available for online use.

 

5.3       Disposal Requirements

All confidential or sensitive electronic data, when no longer needed for legal, regulatory or business requirements must be removed from Val K Consulting LLC systems using an approved method documented in this policy. This requirement includes all data stored in systems, temporary files or contained on storage media.

 

5.4       Disposal Process

A programmatic (automatic) process will be executed on cardholder information systems nightly to remove all sensitive and confidential data that exceeds business retention requirements. Other applicable data stored in files and directories where the containing media will be reused must be deleted securely by a “wiping” utility approved by the Information Security Department.

 

Media containing confidential or sensitive data that should no longer be retained must be disposed of in a secure and safe manner as noted below:

 

  • Hard disks: sanitize (7-pass binary wipe), degauss or shred platter.
  • Floppy disks: disintegrate, incinerate, pulverize, shred or melt.
  • Tape media: degauss, shred, incinerate, pulverize or melt.
  • USB “thumb” drives, smart cards, and digital media: incinerate, pulverize or melt.
  • Optical disks (CDs and DVDs): destroy optical surface, incinerate, pulverize, shred or melt.
  • RSA Encryption Keys: keys must be revoked and the revoked key published to any online key repositories where the previously valid key is stored.
  • Before computer or communications equipment can be sent to a vendor for trade-in, servicing or disposal, all confidential or sensitive information must be destroyed or concealed according to the approved methods in this policy.
  • Removable computer storage media such as floppy, optical disks or magnetic tapes may not be donated to charity or otherwise recycled.
  • Outsourced destruction of media containing confidential or sensitive information must use a bonded Disposal Vendor that provides a “Certificate of Destruction”.
  • Storage containers used for materials that are to be destroyed must be secured. For example, “to-be-shredded” containers could have a lock preventing access to their content, or physically prevent access to the inside of the container by following the measures in section 6.2.

 

6        PAPER AND ELECTRONIC MEDIA POLICIES

6.1       Policy Applicability

All employees handling hardcopy or electronic media must follow this policy. Exemptions from this policy will be permitted only if approved in advance and in writing by the Chief Operating Officer.

 

6.2       Storage

6.2.2      Hardcopy Media

Hard copy materials containing sensitive or confidential information (e.g., paper receipts, paper reports, faxes, etc.) are subject to the following storage guidelines:

 

  • At no time are printed reports containing confidential or sensitive information to be removed from any Val K Consulting LLC secure office environment.
  • At no time is printed material containing confidential or sensitive information to be removed from any Val K Consulting LLC data center or computer room without prior authorization from the Information Security Team.
  • Printed reports containing consumer confidential or sensitive data are to be physically retained, stored or archived only within secure %Company% office environments, and only for the minimum time deemed necessary for their use.
  • All hardcopy material containing confidential or sensitive information should be clearly labeled as such.
  • All confidential or sensitive hardcopy media must be stored in a secure and locked container (e.g. locker, cabinet, desk, storage bin) which has been approved by the Information Security Team.
  • Confidential or sensitive hardcopy material is never to be stored in unlocked or insecure containers or open workspaces.

 

6.2.3      Electronic Media

Electronic media containing sensitive or confidential information (e.g., CD, DVD, floppy disk, hard disk, tape, etc.) is subject to the following storage guidelines:

 

  • Confidential or sensitive information must never be copied onto removable media without authorization from the Information Security Team.
  • At no time is electronic media containing confidential or sensitive information to be removed from any Val K Consulting LLC secure office environment with the exception of computer system backups.
  • At no time is electronic media containing confidential or sensitive information to be removed from any Val K Consulting LLC data center or computer room without prior authorization from the Information Security Team.
  • Electronic media containing consumer confidential or sensitive data are to be physically retained, stored or archived only within secure Val K Consulting LLC office environments, and only for the minimum time deemed necessary for their use.
  • All electronic media containing confidential or sensitive information should be clearly labeled as such.
  • All removable, confidential or sensitive electronic media must be stored securely.
  • All media must be sent or delivered by a secured courier or other delivery methods that that can be accurately tracked and that have been approved by the Information Security Team.

 

6.4       Destruction

All hardcopy shred bins must remain locked at all times (until shredding). Employees should make every effort to immediately cross-cut shred any printed material containing confidential or sensitive information.

 

Electronic media must be destroyed as outlined in the Data Retention and Disposal Policy.

 

7        FIREWALL AND ROUTER SECURITY ADMINISTRATION POLICY

7.1       Policy Applicability

All firewalls and routers on Val K Consulting LLC networks, whether managed by employees or by third parties, must follow this policy. Exemptions from this policy will be permitted only if approved in advance and in writing by the Chief Technical Officer.

 

7.2       Device Management Responsibilities

Management of all Val K Consulting LLC firewalls and routers shall be a combined effort of the System Administrator, the Network Operations Center and the Information Security Team. The following subsections detail the responsibilities for these groups.

7.3       Firewall and Router Configuration Changes

Because firewalls and routers support critical Val K Consulting LLC information systems activities they are considered to be production systems.

All firewall and router changes must be approved by the Information Security Team and must be adequately tested following production standards as defined in the Change Control Policy. These changes include, but are not limited to:

 

  • Rule additions, deletions, and modifications.
  • Software or system modifications.
  • Software or system upgrades, patches, or hot-fixes.

 

7.4       Allowed Services

Every port, protocol and service that is not specifically permitted by this policy, with supporting documents issued by the Information Security Team, must be blocked by Val K Consulting LLC firewalls. The list of currently approved ports, protocols and services, with justifications, is listed in Appendix E, Permitted Network Services and Protocols.

 

For guidance on services, protocols, or ports considered to be insecure, refer to industry standards and guidance (e.g., NIST, ENISA, OWASP, etc.).

 

7.5       Allowed Network Connection Paths and Configuration Requirements

All Internet-based inbound traffic is only permitted into a firewall segmented demilitarized zone (DMZ) network. In all cases, this traffic should be limited to only ports necessary for Val K Consulting LLC’s business requirements. Perimeter routers should not be configured with a route to internal address space with the exception of the DMZ. Internal IP addresses must be hidden utilizing Network Address Translation (NAT) or Port Address Translation (PAT). Anti-spoofing technologies must be configured on perimeter devices, denying or rejecting all traffic with a:

 

  • Source IP address matching internally allocated or %Company% owned address space.
  • Source IP address matching RFC 1918 address space.
  • Destination IP address matching RFC 1918 address space.

 

Outbound traffic from internal production systems must only be allowed to the Val K Consulting LLC DMZ network. Additionally, this traffic should be restricted to only required protocols and services.

 

Databases must be located on an internal network, which is segmented from the Val K Consulting LLC DMZ network. Inbound connections to internal production payment systems, and originating from Val K Consulting LLC wireless networks, are not permitted. The use of a stateful packet inspection firewall must be utilized for Internet and wireless segmentation to only allow established connections into or out of each particular network segment. VLAN's with compliant ACL’s may be used for cardholder environment segmentation so long as the VLAN switch is compliant with PCI and hardened to prevent all currently identified switch exploits (e.g. ARP cache flood). If VLAN’s are used for segmenting all requirements for firewalls apply (e.g. deny all but business necessary traffic, change control, etc).

 

7.6       Configuration Review

At least every six months, the Information Security Team must thoroughly review each firewall rule set and record results of the review. The review must include the removal, when merited, of unused or unnecessary access paths. All proposed changes identified as a result of this review must go through the current change control process prior to implementation.

 

7.7       Personal Firewalls

All mobile and/or employee-owned computers with direct connectivity to the Internet (e.g., laptops used by employees) that are used to access the Val K Consulting LLC network must have personal firewall software (or equivalent functionality) installed and activated. All such software must be configured to actively run and have a non-user alterable configuration as dictated by the Information Security Team.

 

8        SYSTEM CONFIGURATION POLICY

8.1       Policy Applicability

All servers and network devices on Val K Consulting LLC networks, whether managed by employees or by third parties, must be built and deployed in accordance with this policy. Exemptions from this policy will be permitted only if approved in advance and in writing by the Chief Technical Officer.

 

8.2       System Build and Deployment

 

8.2.2      System Configuration Standards

All systems, prior to deployment in the production environment must conform to the

System Configuration Standards. A valid business justification and risk assessment must exist for all deviations from Val K Consulting LLC published configuration standards. Deviations require written approval by the Information Security Team and must be noted on the System Configuration Record for the system.

 

8.2.3      System Configuration Records

A System Configuration Record a model form is shown illustrating the minimum data to be captured electronically or on hard copy. This form must be updated with any future modifications to system configurations.

 

8.2.4      System Configuration Process

All new system deployments will follow the following high level procedure:

  1. Install operating system.
  2. Update all operating system software per vendor recommendations.
  3. Configure operating system parameters and secure the system according to the system configuration build documentation described in Appendix F (A model form is shown illustrating the minimum data to be captured electronically or on hard copy. Install applications and software:
    1. Install system specific applications and software according to System Configuration Record (if this is a replacement for an existing system).
    2. Install applications and software necessary for the systems purpose.
    3. Configure Network Time Protocol (NTP).
  4. Update all application software per vendor recommendations.
  5. Configure application parameters according to build document (application hardening).
  6. Enable logging per Logging Controls (Section 16).
  7. For systems containing confidential or sensitive information deploy file integrity monitoring (FIM) software to alert personnel to unauthorized modification of critical system or content files. Configure FIM to perform critical file comparisons at least weekly.
  8. Complete system specific System Configuration Record and maintain on file.

 

8.2.5      Standard Software

The following list must be considered standard installed software on all applicable systems. A valid business justification and risk assessment must exist for all deviations from Val K Consulting LLC published configuration standards. Any such deviations require written approval by the Information Security Team, and noted on the System Configuration Record for the system (see below).

 

  • File servers, mail servers, and Windows-based systems
  • Anti-Virus software
  • Critical production systems
  • File Integrity software
  • Notebooks/Laptops
  • Personal Firewall software
  • VPN Client software
  • PGP Desktop with Whole Disk Encryption enabled

 

8.2.6      Network Time Protocol (NTP)

With the exception of the internal Val K Consulting LLC NTP server(s), all Val K Consulting LLC production systems must be configured to use one of the internal NTP servers to maintain time synchronization with other systems in the environment. The internal Val K Consulting LLC NTP server(s) will be configured to request time updates from the Internet site time.nist.gov. Client systems able to retrieve time settings from the NTP server will be limited through Access Control Lists (ACL). Access to time data is restricted to only personnel with a business need to access the data. The NTP system will at all times be running the latest available version of the software. Changes to time settings are logged, monitored, and reviewed.

8.2.7      Credit Card Information Processing Application

All Val K Consulting LLC applications, dealing with the processing or retrieval of cardholder information, must be configured in a manner which masks or truncates displayed PAN so that the first six and last four digits are the maximum number of digits to be displayed. If the application is designed for a specific purpose in which the full PAN must be displayed, approval must be given by the Information Security Team during the Requirements Phase as described in Section 13 Software Development Policy. In all cases displaying full or masked PANs must be limited to the fewest number of users possible and only personnel with a legitimate business need can see more than first six/last four digits of the PAN.

 

8.2.8      Credit Card Storage Applications

All Val K Consulting LLC applications, dealing with the storage of cardholder information, must be configured in a manner which does not retain prohibited cardholder data, such as full track data, card-validation codes, card not present values, pins or pin blocks. Storage devices on a network must be on an internal network segregated from the DMZ. All access to networked storage devices must have its authentication and communication encrypted. The PAN must be rendered unreadable through one of the following:

  • Strong one-way hash functions (hashed indexes) with salts
  • Truncation
  • Index tokens and pads (pads must be securely stored)
  • Strong cryptography with associated key management processes and procedures

 

8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.

8.2.9      Change Detection

Change-detection solutions such as file-integrity monitoring (FIM) software are installed on all critical systems that contain sensitive data. The Change-detection solution must monitor all user activity on critical systems. Reporting and alerting tools are enabled in order to automatically alert key personnel when changes to critical files have been made (ex. System executables, application executables, configuration files, content files, log and audit files). The software is configured to perform critical file comparisons at least weekly. Alarms from the Change-detection solution are continuously reviewed to determine if incident response actions need to be taken. If unauthorized changes have been done to systems containing confidential or sensitive information, the security team is immediately notified and the incident response measures in section 14 are performed.

 

9        ANTI-VIRUS POLICY

9.1       Software Configuration

All applicable systems must be configured with Information Security Team approved anti-virus/anti-spyware/anti-adware software. The software must be configured to be actively running, perform periodic scans, log anti-virus events with routing to a central logging solution, and end users must not be able to configure or disable the software.

 

9.2       Signature Updates

All systems with anti-virus software must be configured to update virus signatures on at least a daily basis.

 

9.3       Software Logging

Anti-virus software must alert the Information Security Team in real-time of the detection of a virus. The Information Security Team will determine what steps to take based on the Incident Response Policy. Retention of Anti-Virus software logs will be in accordance with the Data Retention and Disposal Policy.

 

9.4       Systems not commonly affected by malware

All Val K Consulting LLC systems that is not commonly targeted by malware (ex. mainframes, mid-range computers (such as AS/400) and similar systems) are annually evaluated to confirm if any anti-virus software implementation is necessary. This is done by monitoring vendor security notices and anti-virus news groups (for example) to learn about evolving malware that is relevant to Val K Consulting LLC’s systems.

 

10    BACKUP POLICY

10.1    Location

The backup media for each system is relocated to a secure off-site storage area.

The off-site storage location must be visited annually by management or a member of the Information Security Team to confirm that it is physically secure and fireproof.

 

10.2    Transport

Offline storage media utilized for archival or back-up purposes must be handled and retained in a secured environment such that only Val K Consulting LLC personnel and contracted storage facility personnel have access to the archival media. All media couriers and transport mechanisms must be certified by the Information Security Team.

 

Positive log-out and log-in of archive media will take place during all archive media transfers. All media that is transferred from one location to another should be logged as being transferred, by whom, where, and was it properly received, with signature from management. The Backup Media Transfer Log is located in Appendix H (A model form is shown illustrating the minimum data to be captured electronically or on hard copy. All media containing confidential or sensitive data must be classified and identifiable as such prior to transfer as detailed in the Data Classification and Control Policy.

 

10.3    Audit

All media used will be classified as confidential or sensitive and assigned a unique tracking number or similar feature that uniquely identifies the media. All media must be registered with the Information Security Team for tracking prior to use. Quarterly inventories of all stored media will take place. The Information Security Team will compare their list of in-use media with records at the storage facility using the Media Inventory Log (Appendix D A model form is shown illustrating the minimum data to be captured electronically or on hard copy.

 

10.4     Media Destruction

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 Data Retention and Disposal policy.

 

11    ENCRYPTION POLICY

11.1    Policy Applicability

This policy documents encryption standards that must be applied to all applicable mechanisms and systems on Val K Consulting LLC networks, whether managed by employees or by third parties. This policy also applies to the management of encryption keys, which may be shared with customers to exchange confidential information. Documentation provided to customers who have a need to exchange encryption keys with Val K Consulting LLC must include these guidelines. Exemptions from this policy will be permitted only if approved in advance and in writing by the Chief Technical Officer.

 

11.2    Encryption Key Management

Keys must be generated, accessed, distributed and stored in a controlled and secured manner.

 

11.2.1   Key Access

Access to encryption key components will only be granted to those custodians specifically requiring access due to job function. All access may only be granted by the Chief Technical Officer and those requiring access must have so noted on their Authorization Request Form (Appendix B - A model form is shown illustrating the minimum data to be captured electronically or on hard copy. Additionally, these users must sign the Encryption Key Custodianship Form (Appendix I) A model form is shown illustrating the minimum data to be captured electronically or on hard copy. These forms will be held in the employee’s Human Resources file.

 

11.2.2    Split Knowledge and Dual Control

Two custodians authorized by the Information Security Team, are required to collaborate to perform any symmetric key action (such as key generation or loading the key). Additionally, no single custodian may know or have access to all pieces of a symmetric data encryption key. The separation of public and private encryption keys satisfies the concept of split knowledge and dual control.

 

PCI Requirements Reference:

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

 

11.2.3    Key Generation

  • Only strong encryption keys are to be used. Creation of encryption keys must be accomplished using a random or pseudo-random number generation algorithm.

 

Generating encryption keys must be accomplished by two custodians authorized by the Information Security Team. Each custodian will generate one clear text piece that will be used to create the encryption key. To prevent unauthorized substitution of keys physical and logical access to the key generating procedures and mechanisms must be secured.

 

11.2.4    Key Distribution

Only custodians authorized by the Information Security Team are allowed to retrieve key components from secure storage or distribute keys. Custodians must document all such actions in the Encryption Key Management Log (Appendix J) A model form is shown illustrating the minimum data to be captured electronically or on hard copy. The encryption keys must be placed in secure packaging prior to being returned to storage.

 

11.2.5    Key Storage

All secret and private keys used to encrypt/decrypt cardholder data must be stored encrypted and in the fewest possible locations. Secret and private keys must be stored in one (or more) of the following three ways:

  1. Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key within applicable applications.
  2. Within a secure cryptographic device such as a HSM.
  3. As at least two full-length key components or key shares, in accordance with an industry-accepted method.

Clear-text backups of encryption key components must be stored separately in tamper-evident packaging in a secure location.

 

11.2.6    Key Changes and Destruction

An encryption key change is the process of generating a new key, decrypting the current production data and re-encrypting the confidential data with the new key. All data encryption keys must be changed after reaching the end of their cryptoperiod or when circumstances dictate a change to maintain encryption or key integrity. The following dictates when a key change is required:

 

  • End of cryptoperiod: Keys must be changed after having reached the end of their respective cryptoperiod. Considerations for defining the cryptoperiod include the strength of the underlying algorithm, size or length of the key, risk of key compromise, sensitivity of the data being encrypted and industry best practices and guidelines (for example, NIST Special Publication 800-57).
  • Suspicious Activity: This change is driven by any activity related to the key process, which raises concern regarding the security of the existing key.
  • Resource Change: Keys must be changed if a resource with knowledge of the keys terminates employment or assumes a new job role that no longer requires access to an encryption process.
  • Technical Requirement: Keys must be changed if the key in place has become questionable due to a technical issue such as corruption or instability.
  • Encryption keys no longer in service are to be disposed of in accordance with the process outlined in the Data Retention and Disposal Policy.

 

11.3    Transmission over Un-Trusted Networks

Confidential and sensitive information must be encrypted during transmission over networks in which is it easy and common for the data to be intercepted, modified or diverted. Examples of strong encryption that is acceptable are:

  • Transport Layer Security (TLS version 1.2)
  • Internet Protocol Security (IPSec)

Examples of insecure protocols are FTP, Telnet, POP3, IMAP, and SNMP v1 and v2.

 

Where SSL and early TLS (version 1.0 and sometimes 1.1, depending on use and implementation) is used, Val K Consulting LLC will need to comply with the additional requirements in Appendix A2 in the PCI DSS.

 

11.3.1   Email Transmission of Confidential Information

Confidential and sensitive information is never to be sent unencrypted through email. Employees, with a valid business justification, must be issued email encryption software by the Information Security Team.

 

11.4     Non-console and Remote Administrative Access

All non-console (including remote) administrative access is encrypted using strong cryptography as referred to in the PCI DSS, using industry-recognized protocols with appropriate key strengths and key management (clarified in section 11.3). Clear-text protocols such as HTTP and Telnet are not permitted to be used when encrypting non-console access. The system is configured to invoke strong cryptography before any administrator’s password is requested.

 

12    CRITICAL TECHNOLOGIES USAGE POLICY

 

12.3    Authentication

User authentication mechanisms, where possible, must be integrated into the current Val K Consulting LLC authentication systems. All device use must be authenticated at minimum with username and password or other authentication item (for example, token). Under no circumstances may the user authentication requirements be less strict than currently defined policies and procedures (e.g., complex passwords, password change interval, etc.).

All remote access (including general users, administrators, and vendors (for support or maintenance)) to the Val K Consulting LLC network using these technologies must be authenticated via a strong multi-factor authentication scheme approved by the Information Security Team.

 

All non-console and remote administrative access to the Val K Consulting LLC CDE must be authenticated via a strong multi-factor authentication scheme approved by the Information Security Team.

 

12.8    Approved Products

Only Information Security Team approved devices may be deployed into the Val K Consulting LLC network.

 

12.9    Session Disconnect

All remote-access technologies must be configured to automatically disconnect sessions after thirty (30) minutes of inactivity.

 

12.10  Vendor Connections

Dial-in modems, systems and accounts used solely for the purpose of vendor maintenance and support must remain disconnected and/or disabled until required. Activating these remotes access paths requires approval from the Information Security Team or established problem management procedures and they must be disabled immediately after use.

 

12.11   Credit Card Data Access

If any credit card data is available through remote dial-in modem connections special precautions must be taken. The following are prohibited:

  • Storage of the company information onto local hard drives, floppy disks, and other media is prohibited.
  • Cut, paste, and print functions of remote PCs is prohibited for the duration of the connection.

 

13    SOFTWARE DEVELOPMENT POLICY

13.1    Development Environment

A test/development environment, separate from the production environment, must be used to test all new software. If the network has network connectivity with the production Val K Consulting LLC network, access controls must be in place to enforce the separation.

 

Production cardholder data will not be used for testing and development purposes without being sanitized. Test personnel should make every effort to use mock data only for testing on non-production systems and software. If it is determined that production card holder data must be used in testing, the Security Council must review and approve the business justification, the testing window will have as short a duration as possible, all PCI controls must be enforced on the systems under test, and the Security Council must be notified of test results, and verification that production data has been scrubbed after close of testing window.

 

All test data, custom application accounts, usernames and passwords must be removed at the conclusion of testing, and in all cases before software becomes active. All code promotion to the production environment will be accomplished by the System Administrators. Under no circumstances will the Development Department have full time read/write access to production applications or data. Under emergency situations developers may assist in troubleshooting utilizing an Emergency ID described in section 2.3 Information Security Team Responsibilities.

 

13.2    Secure Software Development Procedures

13.2.1   Development Life-Cycle

Internal and 3rd party development of proprietary software must utilize industry recognized best practices for software development such as described at http://cwe.mitre.org/top25/ . Security checks and control measures must be considered throughout the development life-cycle.

 

The high level overview of the security measures taking place within each phase of the Val K Consulting LLC development process are as follows:

 

  • Requirements Analysis – developers should determine whether application requirements are inherently insecure.
  • Design – application components must be planned in a manner consistent with data and network security.
  • Development – developers must consider all application vulnerabilities (i.e.: memory bound issues, privilege and access bypass, etc.).
  • QA Implementation - implementation must not compromise security controls already in place, or introduce new vulnerabilities.
  • QA Testing - in addition to functional and efficiency testing, all security features of the application must be tested.
  • Documentation – all application feature and implementation documentation must include direction on proper security configurations.
  • Production Implementation – implementation must not compromise security controls already in place, or introduce new vulnerabilities.
  • Production Testing – in addition to functional and efficiency testing, all security features of the application must be tested.
  • Maintenance – all future application maintenance should not compromise security controls already in place, or introduce new vulnerabilities.
  • Code changes – all future code changes must be reviewed by individuals other than the originating author. The reviewer must have adequate knowledge about code-review techniques and secure coding practices.

 

13.2.2    Web-based Applications

In addition to the Development Life-Cycle security measures that take place throughout the application development life-cycle, special care should be given to Val K Consulting LLC’s applications that are web-based. All Val K Consulting LLC’s developers will receive training on secure coding practices at least annually. All development must be done taking the OWASP guidelines into account, located at http://www.owasp.org. Specifically, the following vulnerabilities must be considered and checked for during the Code Review and Testing phases:

  • Unvalidated Input
  • Malicious Use of User IDs
  • Malicious Use of Account Credentials and Session Cookies
  • Broken authentication and session management
  • Cross-Site Request Forgery (CSRF)
  • Cross-Site Scripting
  • Buffer Overflows
  • SQL Injection and other Command Injection Flaws
  • Error Handling Flaws
  • Insecure cryptographic storage
  • Denial of Service
  • Insecure Configuration Management
  • Insecure Direct Object references
  • All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).

 

Annually, and whenever significant modifications have taken place, all web-based applications will be put through an application-specific penetration test. All custom code is to be reviewed by an organization that specializes in application security or an application layer firewall in front of web-facing applications.

 

13.2.3    Credit Card Informational and Processing Applications

All Val K Consulting LLC proprietary or custom applications dealing with the processing or retrieval of cardholder information must be configured in a manner, which masks or truncates the displayed PAN. If the PAN is to be masked only the first 6 and last 4 digits may remain displayed. If the application is designed for a specific purpose in which the full PAN must be displayed, approval must be given by the Information Security Team. All the roles defined in Appendix Q2, that need access to displays of more than the first 6 and last 4 digits (includes full PAN), are listed in Appendix Q3 together with a business justification. All roles not specifically authorized in Appendix Q3 may only see masked PANs.

 

14    INCIDENT RESPONSE PLAN AND PROCEDURES

14.1    Incident Identification

Employees must be aware of their responsibilities in detecting security incidents to facilitate the incident response plan and procedures. All employees have the responsibility to assist in the incident response procedures within their particular areas of responsibility. Some examples of security incidents that an employee might recognize in their day-to-day activities include, but are not limited to:

  • Theft, damage, or unauthorized access (e.g., unauthorized logins, papers missing from their desk, broken locks, missing log files, alert from security guard, video evidence of a break-in or unscheduled/unauthorized physical entry)
  • Fraud – Inaccurate information within databases, logs, files or paper records
  • Abnormal system behavior (e.g., unscheduled system reboot, unexpected messages, abnormal errors in system log files or on terminals)
  • Security event notifications (e.g., file integrity alerts, intrusion detection alarms, physical security alarms such as fire alarms, environmental alarms, natural disaster alerts)
  • Addition of unauthorized devices (such as skimming devices, unauthorized wireless access points, unknown “free” USB-sticks)

 

All employees, regardless of job responsibilities, should be aware of the potential incident identifiers and who to notify in these situations. In all cases, every employee should report incidents per the instructions under 14.2 Incident Reporting unless they are assigned other activities within the incident response plan.

 

14.2    Reporting and Incident Declaration Procedures

The Information Security Team should be notified immediately of any suspected or real security incidents involving Val K Consulting LLC computing assets, particularly any critical system. If it is unclear as to whether a situation should be considered a security incident, the Information Security Team should be contacted to evaluate the situation. With the exception of steps outlined below, it is imperative that any investigative or corrective action be taken only by Information Security Team personnel or under the oversight of Information Security Team personnel, to assure the integrity of the incident investigation and recovery process. When faced with a potential situation you should do the following:

 

  • If the incident involves a compromised computer system.
  • Do not alter the state of the computer system.
  • The computer system should remain on and all currently running computer programs left as is. Do not shutdown the computer or restart the computer.
  • Immediately disconnect the computer from the network by removing the network cable from the back of the computer.
  • Reporting the security incident.
  • Contact the Information Security Team to report any suspected or actual incidents.
  • No one should communicate with anyone outside of their supervisor(s) or the
  • Information Security Team about any details or generalities surrounding any suspected or actual incident. All communications with law enforcement or the public will be coordinated by the Information Security Team.
  • Document any information you know while waiting for the Information Security Team to respond to the incident. This must include date, time, and the nature of the incident, if known. Any information you can provide will aid in responding in an appropriate manner.

 

14.3    Incident Severity Classification

The Information Security Team will first attempt to determine if the security incident justifies a formal incident response.

 

In cases where a security incident does not require an incident response the situation will be forwarded to the appropriate area of IT to ensure that all technology support services required are rendered. The following descriptions should be used to determine what response the Information Security Department will take.

  • Level 1 - One instance of potentially unfriendly activity (e.g., finger, unauthorized telnet, port scan, corrected virus detection, unexpected performance peak, etc.).
  • Level 2 - One instance of a clear attempt to obtain unauthorized information or access (e.g., attempted download of secure password files, attempt to access restricted areas, single computer successful virus infection on a non-critical system, unauthorized vulnerability scan, etc.) or a second Level 1 attack.
  • Level 3 - Serious attempt or actual breach of security (e.g., multi-pronged attack, denial of service attempt, virus infection of a critical system or the network, successful buffer/stack overflow, successful unauthorized access to sensitive or critical data or systems, broken lock, stolen papers, etc.) or a second Level 2 attack.
  • Any Level 1 type incident occurring against systems storing sensitive or confidential data or originating from unauthorized internal systems is classified as a Level 2.

 

14.4    Incident Response

14.4.1   Typical Response

Responses can include or proceed through the following stages: identification, severity classification, containment, eradication, recovery and root cause analysis resulting in improvement of security controls. The following actions should be taken by the Information Security Department once an incident has been identified and classified.

 

14.4.1.1  Level 1

Contain and Monitor

  1. If possible, record the user, IP address and domain of intruder.
  2. Utilize approved technology controls to temporarily or permanently block the intruder’s access.
  3. Maintain vigilance for future break-in attempts from this user or IP address.

 

14.4.1.2  Level 2

Contain, Monitor and Warn

  1. Collect and protect information associated with the intrusion.
  2. Utilize approved technology controls to temporarily or permanently block the intruder’s access.
  3. Research the origin of the connection.
  4. Contact ISP and ask for more information regarding the attempt and intruder.
  5. Research potential risks related to intrusion method attempted and re-evaluate for higher classification and incident containment, eradication, and recovery as described for Level 3 incident classifications.
  6. Upon identification, inform malicious user of our knowledge of their actions and warn of future recriminations if attempt is repeated. If an employee is the malicious user management should work with Human Resources to address the Acceptable Use violation appropriately.

 

14.4.1.3  Level 3

Contain, Eradicate, Recover and perform Root Cause Analysis

  1. If the incident involved credit card systems, the Acquirer and applicable card associations must be notified. See section 14.4.2 for more details.
  2. Contain the intrusion and decide what action to take. Consider unplugging the network cables, applying highly restrictive ACL’s, deactivating or isolating the switch port, deactivating the user ID, terminating the user’s session/change password etc.
  3. Collect and protect information associated with the intrusion via offline methods. In the event that forensic investigation is required the Information Security Team will work with legal and management to identify appropriate forensic specialists.
  4. Notify management of the situation and maintain notification of progress at each following step.
  5. Eliminate the intruder's means of access and any related vulnerabilities.
  6. Research the origin of the connection.
  7. Contact ISP and ask for more information regarding attempt and intruder, reminding them of their responsibility to assist in this regard.
  8. Research potential risks related to or damage caused by intrusion method used.

 

14.4.2   Credit Card Compromise – Special Response

For any incidents involving potential compromises of credit card information, the Information Security Team will use the following procedure:

  1. Contain and limit the exposure. Conduct a thorough investigation of the suspected or confirmed loss or theft of account information within 24 hours of the compromise. To facilitate the investigation:
    1. Log all actions taken (e.g., bound notebook, video camera, etc).
    2. Utilize chain of custody techniques during all transfers of equipment and information related to the incident.
    3. Do not access or alter compromised systems (e.g., do not log on or change passwords; do not log in as ROOT).
    4. Do not turn off the compromised machine. Instead, isolate compromised systems from the network (e.g., unplug the network cable, deactivate switch port, isolate to contained environment e.g. isolated VLAN). Utilize Disaster Recovery / Business continuity procedures to recover business processes.
    5. Preserve logs and electronic evidence.
    6. If using a wireless network, change SSID on the AP and other machines that may be using this connection (with the exception of any systems believed to be compromised).
    7. Be on high alert and monitor all cardholder information systems.
  2. Alert all necessary parties. Be sure to notify:
    1. Internal or External Incident Response or Forensics Team, if they are not already involved
    2. Merchant bank
    3. S. Secret Service (if PCI payment data is compromised)
  3. Follow appropriate procedures for each card association which %Company% utilizes for credit card services.

 

Visa

Provide the compromised Visa accounts to Visa Fraud Control Group within ten (10) business days. For assistance, contact (650) 432-2978. Account numbers must be securely sent to Visa as instructed by the Visa Fraud Control Group. It is critical that all potentially compromised accounts are provided. Visa will distribute the compromised Visa account numbers to issuers and ensure the confidentiality of entity and non-public information. See Visa’s “What to do if Compromised” documentation for additional activities that must be performed. That documentation can be found at https://usa.visa.com/dam/VCOM/download/merchants/cisp-what-to-do-if-compromised.pdf

 

MasterCard

Contact your merchant bank for specific details on what to do following a compromise. Details on the merchant bank (aka. the acquirer) can be found in the Merchant Manual at http://www.mastercard.com/us/wce/PDF/12999_MERC-Entire_Manual.pdf.

 

American Express

Contact your relationship manager or call the support line at 1-800-528-4800 for further guidance.

 

Discover Card

Contact your relationship manager or call the support line at 1-800-347-3083 for further guidance.

 

14.4.3    Root Cause Analysis and Lessons Learned

Not more than one week following the incident, members of the Information Security Team and all affected parties will meet to review the results of the investigation conducted under step 1, Section 14.4.3 of this document to determine the root cause of the compromise and evaluate the effectiveness of the Incident Response Plan. Review other security controls to determine their appropriateness for the current risks. Any identified areas in which the plan, policy or security control can be made more effective or efficient, must be updated accordingly.

To become PCI compliant, start here:

HTTPS://WWW.24SOLUTIONS.COM/EN/COMPLIANCE/PCI-DSS/FREE-POLICY-TEMPLATE-FOR-PCI-DSS/