Open Mobile Menu

Blog

In Part 1, we discussed:

  • The need for upper-management commitment
  • Definitions of Merchants and Service Providers
  • Who might be asking for proof of PCI compliance
  • Determination of Merchant or Service Provider level
  • Available PCI compliance validation options

In Part 2 , we discussed:

  • Business Organization
  • How cardholder data (CHD) is handled
  • Scope of the PCI assessment

In Part 3 , we discussed:

  • Allowing sufficient time for the assessment
  • Personnel responsibilities

In this article, we will discuss some ‘nuts and bolts’ of the PCI assessment process, how to handle changes in the environment, and how to handle operational issues.

How Am I Organizing and Handling Evidence?

  • Organization

    If there are tools in place (GRC tools, document repositories, internal Wiki sites, etc.), they should be utilized. If not, an access-controlled area of a file server will usually serve the purpose. It is recommended that a structure is created that reflects the assessment. It could be a trunk for the entire enterprise, with branches for each assessment, or it could be a single location. For full ROCs and larger SAQs, a separate location should be dedicated for each high-level PCI requirement, 1 through 12, the Appendices, Executive Summary, and Miscellaneous information.

    Organizing the information in this way allows for easy retrieval, and provides the ability to determine what was supplied in previous years.

  • Collection

    When evidence is requested, it should be clearly communicated how that evidence should be provided to the requestor. If possible, there should be a single resource that is assigned the responsibility of receiving the evidence, and placing it in the proper organizational container, based on the requirement it is supposed to be addressing.

  • Labeling

    All evidence should be labeled so that it can be easily related to a general or specific requirement. An easy way to do this is to add a prefix to each piece of submitted evidence. For example:
    • ES3.4_Production Network Segments
      • Note: ES is for the Executive Summary in the Report on Compliance template in this example
    • 1.1.7.b_Firewall Rule Review Results
    • 2.x_Windows Server Configuration Standard
    • 2.x_Linux Server Configuration Standard
    • 10.4_System Time Processes
    • 10.4.1.a_Screenshot showing time server external sources
    • A2.2_POS-POI Risk Mitigation and Migration Plan

    If possible, when requesting the evidence, supply the necessary prefix for the evidence to the personnel asked to obtain the evidence.

    There are occasions where the supplied evidence applies to multiple requirements. In our experience, the above labeling scheme still works, but the prefix may change year-to-year, depending on the meeting order. Retaining evidence lists, and examinations of previous assessment efforts provide a valuable cross-reference.

  • Submission

    When providing documentation to a QSA, it is important to ensure that confidential information is protected. QSA companies are required to ensure that evidence for PCI assessments are stored in an encrypted manner, and usually have methodologies by which documents can be securely uploaded to a repository.

    If possible, a single resource should be assigned the responsibility of providing evidence to the QSA.

  •  

Are There Changes to the Environment Which Must be Considered?


  • Prior to the assessment

    If this is not your first rodeo, these items should be revealed during your investigation of the environment, and how the organization handles CHD as discussed in Part 2 of this series. It may be a good idea to document these changes in the current scoping statement, so a historical record is maintained.

    Regardless of where, all changes to the environment should be documented, and communicated to all relevant personnel involved in PCI compliance activities, and to those with overall responsibility for PCI compliance.

  • During the assessment

    Any changes to environment during the assessment should be avoided if at all possible. It not possible, sufficient time, planning and communication is critical to avoid unnecessary re-work, and delays. If possible, define and document a timeline with clear milestones as to what is going to change, and when those changes will occur. Of course, clear communication with your QSA in the design phase is critical to avoid re-work and delays.

    Why is this important? For example, if there are servers that are going to be de-commissioned during the time of the assessment, it could be a waste of time to perform tasks such as selecting samples, requesting configuration exports, or reviewing network diagrams until after the changes are completed.

  • Significant change

    The PCI DSS has several areas that refer to ‘significant change’, and provides some examples in some cases. Because organizations differ widely, sometimes even within the same entity, it is impossible to define what is ‘significant’ for every organization. For an entity with thousands of virtual servers, they may have automated processes that constantly spin servers up or down, depending on need, so adding a server in this manner may not be ‘significant’. It could be very ‘significant’ if a small organization with only a single server adds another server.

    Whether something is ‘significant’ or not impacts vulnerability scanning, penetration testing, risk assessments, and ‘significant PCI changes’. What is ‘significant’ for one of these areas may not be ‘significant’ for the others. Actions that are required for ‘significant’ changes are also very different, and potentially costly and time-consuming.

    It is our recommendation that a ‘Significant Change Policy’ or other such equivalent document be created to define what is ‘significant’ for your organization. Without such definition, it is up to the QSA to determine what is ‘significant’ or not. Delays and additional costs could result if there is a difference of opinion between the organization and the QSA.

What Happens if There Is an Operational Issue?

It’s a basic tenet of compliance work: operational issues trump compliance validation efforts. Frequently, situations arise where personnel that are scheduled for an interview, or have been requested to supply evidence or perform remediation tasks are needed to address an operational issue. Usually, these sorts of occurrences are of short duration, and don’t result in undue delays.

Strategies to attempt to mitigate these sorts of delays may include defining backup personnel, or even back-filling these personnel in advance, to free them up for compliance activities. This is more difficult in smaller organizations.

Document and report any operational issues that may cause significant delays to those with overall responsibility for PCI compliance as soon as possible, to ensure that all possible efforts are employed to avoid additional costs.

How Can AppSec Consulting Help?

Our Qualified Security Assessors (QSAs) leverage AppSec Consulting’s proven methodologies. Their many years of security, IT, development, and PCI auditing experience ensures that whatever your goals, the outcome is exactly what you need and makes strategic sense for your business. Whether you’ve been asked by your bank “to comply with PCI”, or preparing for your first validation with a Report on Compliance (ROC), gearing up for annual re-validation, or would just like to know what the PCI DSS mean to your business, our team of experts are there to help.

More information can be found at www.appsecconsulting.com, or call us at 408-224-1110.

Chip Ross

Chip came up through the ranks of Information Technology, beginning as a contract Desktop Field Engineer in 1997. His career evolution included leading the Desktop Operations team at Northwest Airlines, including day-to-day work direction for a team of 14 packagers and maintaining communication with upper management regarding desktop operations. In 2006, he transitioned to Information Security and delivered compliant merchant RoCs for 2007 – 2010, including the year of the Northwest/Delta merger.

Chip moved to Carlson in 2010 and continued delivering compliant Service Provider and Merchant RoCs from 2010 – 2012 as a Carlson-sponsored ISA. During that time, Chip also conducted many assessments at Carlson hotel and restaurant franchisees, providing on-the-ground guidance to the smaller merchants that make up a large portion of Carlson’s organization. Chip joined United Health Group as a sponsored ISA in early 2013, to provide guidance, tracking and reporting on the PCI efforts for the various teams and business units there.

Drawing on his experience, leading, participating, tracking and reporting on many remediation projects, Chip helps clients achieve their compliance goals through scope reduction, process improvement, and strategic technology integration. Chip’s broad background and extensive PCI experience with large corporations enables him to be comfortable working with client personnel anywhere from the data center to the board room, ensuring that AppSec Consulting’s clients receive thorough, top-quality consultation and assistance.

read more articles by Chip Ross