Select Monthly Archives
- June 2019
- May 2019
- April 2019
- March 2019
- February 2019
- January 2019
- December 2018
- November 2018
- August 2018
- July 2018
- May 2018
- March 2018
- February 2018
- December 2017
- November 2017
- September 2017
- August 2017
- June 2017
- May 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- March 2016
- October 2015
- September 2015
- July 2015
- May 2015
- March 2015
- February 2015
- January 2015
- December 2014
- September 2014
- August 2014
- July 2014
- June 2014
- December 2013
- September 2012
Written By: Chip Ross June 14, 2019
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?
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.
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.
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.
- ES3.4_Production Network Segments
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.