The PCI DSS is a continuous and ever-changing cybersecurity standard that just underwent another release (PCI v3.2.1). At SRA, we have assisted numerous clients on PCI-related projects, from scope reduction and validation to gap assessments to QSA audit certifications. PCI is still open to interpretation and can be difficult to keep up with when making long-term strategic plans. Requirements are typically updated in 3-year cycles, but technology, industry trends, and threats change fast. We will likely see incremental updates occurring more regularly to PCI requirements to keep them relevant.
Clients consistently reach out to us regarding three PCI requirement areas for guidance and best practice. Below we will explore how SRA approaches these trouble areas.
SSLv3/TLS 1.0
Description:
As of June 30, 2018, merchants and service providers cannot use SSLv3 and TLS 1.0 as these protocols are no longer sufficient for secure communication. PCI will require a minimum of TLS 1.1, and highly recommends TLS 1.2 to meet this new standard and prevent known exploits; use of SSLv3 and TLS 1.0 must be eliminated completely.
Relevant PCI Requirements:
2.2.3, 2.3, 2.4, 4.1, Appendix A2
Guidance:
Upgrading from early TLS and SSLv3 to TLS 1.1 and above is straightforward from a technology perspective, but establishing proper change control and upgrade windows is not always as straightforward. We recommend that organizations utilize a phased implementation for upgrading to TLS 1.2 to avoid large-scale impacts. Clients typically develop multi-stage project plans to update to stronger protocols beginning with the most business-critical web applications. Tracking assets, understanding backup procedures, and mapping network connections will be vital in understanding the scope and potential impact of these upgrades. Without knowledge of the environment, it will become difficult to properly implement the new TLS requirements on all applicable systems.
Charter/Internal Steering Committee
Description:
As of January 31, 2018, service providers must formally establish PCI roles and responsibilities in the form of a PCI DSS charter.
Relevant PCI Requirements:
12.4.1
Guidance:
We recommend clients to establish PCI roles and responsibilities for critical stakeholders including business operations, IT, network operations, security, legal, HR, and procurement. Additionally, it is imperative to create documentation with PCI in mind to develop concrete approaches for securing payment data. This includes developing or updating policies and procedures to incorporate PCI requirements. As your PCI program matures, establish a PCI Steering Committee to oversee compliance initiatives and liaise with the business. Executive management will be an integral part of assigning responsibilities by establishing a PCI DSS Charter. Some items to include in a PCI DSS Charter are the project objectives, a list of stakeholders, designated roles and responsibilities to maintain PCI DSS compliance, and milestones and target dates. See below for a PCI DSS Charter sample template.
Reviewing Vendor Responsibilities
Description:
Merchants and service providers must establish and communicate vendor roles and responsibilities. Further, periodic reviews must be conducted to ensure vendors are compliant with PCI DSS as well as adhering to established business contracts.
Relevant PCI Requirements:
2.5, 12.1, 12.3, 12.4, 12.8, 12.9, 12.11
Guidance:
Each of our clients that successfully certified for PCI DSS Compliance have strong vendor management processes in place. These programs entail documenting clear roles and responsibilities for the organization and vendors within contracts as well as vetting vendors on a consistent basis. It is important to verify that external vendors or service providers themselves are PCI compliant. If leveraging a service provider for PCI activities, request an Attestation of Compliance (AOC) and review contract agreements at least annually. Maintaining an internal RACI matrix will help track roles and responsibilities and maintaining a spreadsheet or inventory of vendors will support due diligence activities. Contracts with PCI related service providers should include language to specify Information Security responsibilities and vendors should acknowledge and agree to their responsibilities prior to formally signing a contract. An example of PCI-related language is below:
- If Supplier processes, transmits, accesses, or stores payment card data in rendering services to [organization], then Supplier (and related applicable third parties) shall demonstrate ongoing PCI Data Security Standard (PCI DSS) and/or Payment Application Data Security Standard (PA-DSS) compliance as a Service Provider annually by furnishing to [organization] its then-current authorized Attestation of Compliance (AOC) developed by a certified PCI Qualified Security Assessor. Supplier shall comply with all applicable federal, state, and local statutes and regulations governing Supplier’s use, transmission, storage, and destruction of Data.
PCI changes can be difficult and are fluid, but they are not impossible to deal with. Developing a strategic approach will pave a way forward in preparing for the next set of inevitable updates.
Resources
- Lifecycle for Changes to PCI DSS and PA-DSS
- Migrating from SSL and Early TLS
- How to create your PCI DSS charter
- Getting started with your PCI DSS Charter
- PCI DSS Program Charter – DRAFT.docx
Adam specializes in security assessments and audits, primarily PCI DSS. Adam has experience leading PCI scope validation and strategy engagements, performing data risk assessments, and conducting various security framework readiness assessments. He also has experience in leading vulnerability management projects and SWIFT CSP readiness assessments.
In addition to extensive experience with PCI DSS controls and remediation strategies, Adam has experience with additional frameworks such as NIST CSF and ISO 27001.
Adam has worked on projects in multiple industries but most notably healthcare organizations, insurance, and financial services institutions.
Adam’s range of skills is his strength; he can use his broad range of experiences to jump into any project and assist the client with any issue they may have.
Dakota specializes in cybersecurity risk assessments and GRC tools development. He is well versed in NIST CSF, HIPAA, H24, and manufacturing and lab security. He also has experience in Microsoft Office 365 and using Excel based data analysis in executive level metrics.
Dakota has worked closely with multiple clients’ executives including the development of a vulnerability management program as well as a three-year enterprise security roadmap.
During one of his most recent projects, Dakota created a controls matrix from scratch and some of his templates are now being used as a standard across SRA. Dakota has a bachelor’s degree in Information Technology and a master’s degree in Health Informatics.