PCI ASV Program Guide 2.0 Changes, Impact to your organization

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "PCI ASV Program Guide 2.0 Changes, Impact to your organization"

Transcription

1 PCI ASV Program Guide 2.0 Changes, Impact to your organization Jesper Jurcenoks Director of Security Research and Chief Evangelist Critical Watch May 20, 2013

2 Conclusion... 3 Introduction and background... 3 Impact for Merchants and Service providers... 4 Impact for ASVs Document Change Summary... 4 Major changes to Whitelisting of ASV and Scan interference... 5 Overview of important changes Important New Rules on Scan Interference... 7 Details of Changes Notes... 27

3 Conclusion Easier Compliance for Merchants and Card Acquirers - An updated,, less rigid - rule set for scan interference and active blocking makes it easier for merchants and card acquirers to be compliant while staying safe. New requirements for the ASVs mandate changes to procedures. PCI SSC does not require that changes to the Scan Solution stemming from the new requirements be implemented at this time. The new PCI ASV Program Guide is effective immediately. Introduction and background PCI (Payment Card industry) is governed by a number of security standard created and maintained by the PCI Security Standards Council ( The PCI ASV Program Guide is the authoritative document on how ASVs must conduct the quarterly external scans required by PCI DSS 2.0 Requirement The program guide is intended to be updated on regular intervals, synchronized with technological developments and emerging threats. The PCI ASV program guide was last updated on March The ASV program guide is important because every merchant independent of merchant level must produce a passing ASV scans report every quarter in order to stay PCI compliant. PCI compliancec of the merchantm is determined by the card acquirer based on the findings of the report and the recommendation (Pass or Fail) made by the ASV.

4 Many of the changes in the new program guide can trace their original back to these three documents: Consensus Suggested improvements for ASV Program Guide 2.0, Jan 2011 o Initiative, Coordination and Editor : Jesper Jurcenoks i ASV: Fail on Blocked Scan? - a PCI Industry consensus document, Jan 2013 o Initiative, Coordination and Editor : Jesper Jurcenoks ii PCI DSS Requirement and Security Assessment Procedures, Version 2.0 o Published by PCI DSS Impact for Merchants and Service Providers The new rules make it safer and easier for merchants, card acquirers, hosting providers and other Scan Customers to pass an ASV scan. Some of the active defense mechanisms that had to whitelist ASV s originating IPs, no longer has to be changed. Previously active defense mechanisms required by PCI to pass PCI DSS 2.0 like Web-application firewalls, had to be disabled during ASV scans resulting in paradoxical scan failures. The Scan Customers now have additional options to resolve ASV scans that fail as inconclusive. Impact for ASVs Changes to procedures for handling inconclusive scans Minor changes to mandatory texts in reports Significant changes to how tools should detect scan interference New requirements effective immediately but changes to scan solutions not required. (see section Required Timeline for Implementation for details)) Required Timeline for Implementation Scan Customers:

5 Merchants, Card acquirers and other scan customers are free to start using the new rules at any time they want, the new rules are less stringent that the previous rules and transitioning to the new rules is optional and at the scan customer s discretion. ASVs: The changes in the requirements to the ASV fall into 3 categories: 1. Minor text changes to mandatory text in reports. Contents, and context wise the changes are not significant and considered optional at this time. e.g. leaving the mandatory text ad verbatim to the ASV program Guide v1.0 for the time being will not invalidate the scan solution under ASV Program Guide v ASV Needs to change procedures and training of ASV personnel, including Qualified ASV Engineers (QAE), for new escalation of inconclusive scans procedure. There is no set deadline; changes should be made using normal business priority as business demands. 3. Changes to the way the Scan solution detects active blocking and when it reports inconclusive scans. No specific deadline date for changes to scan solution, tools, or procedures. PCI SSC expects the individual ASV to prioritize these changes in coordination with their customers and implement accordingly. Document Change Summary The new PCI ASV Program Guide G is effective immediately (May 20 th 2013) This document provides a comprehensive overview of all the changes between PCI ASV Program Guide 1.0 released March 2010 and the ASV Program Guide 2.0 Released May 20 th, Major changes to Whitelisting of ASV and Scan interference 1. Critical protection that keeps scan customers compliant does not have to be disabled anymore during ASV Scans. a. Still allowed systems: Systems that only record but does not interfere with traffic b. Still prohibited systems: Systems the block perceived good traffic based on traffic trends, previous attack from same IP etc. c. New allowed systems: Systems that block packets with perceived malicious contents, but allows perceived good traffic pass, even right after malicious traffic from the same source

6 2. More options available to ASVs and Scan Customers to resolve Failing Scans. Including: a. Scan Interference dispute resolution procedures b. Ability to consolidate overlapping inconclusive scans to create a conclusive report c. Ability to perform part of scan behind Active defense mechanisms For details of changes, see section Important New Rules on Scan Interference. Overview of important changes 1. PCI promises more cooperation with PCI community in regards to evolving standards 2. No grace period before new rules are in effect 3. ASVs are now explicitly responsible for: Maintaining security and integrity of systems and tools used to perform scans 4. Scan Customers are now explicitly responsible for: Perform due diligence in the ASV selection process, per the scan customer s due-diligence processes, to obtain assurance as to the ASV s level of trust to perform scanning services and To the degree deemed appropriate by the scan customer, monitor Internet -facing systems, active protection systems, and network traffic during the scan, to assure an acceptable level of trust is maintained 5. Clarification: Scan customers cannot perform their own ASV scan, not even if the use the same scanning software that the ASV uses 6. Current ASV program fees are now moved to the PCI SSC program fee schedule 7. List of items for the scan customer to provide enhanced with Domains 8. ASV report additional components list now only required to list relinquished IP addresses for 1 additional scan (but can list them longer) 9. New text for Directory Browsing noten 10. New text for Remote Access noten 11. New text for POS System noten 12. A somewhat obscure requirement that severity levels must be easy to compare and rank has been removed

7 13. Only rescan of failed affected systems is now required and not rescan of the entire environment to obtain passing report 14. Clarification that Attestations must be made for each report 15. Changes to the Scan Customer Attestation Mandatory Text 16. Scan customer can now dispute the detection of scan interference 17. ASV is now required to investigate disputed inconclusive scans 18. Requirement that ASV should assess accuracy of compensating controls, changed to the achievable applicability 19. Clarification that ASVs can get decertified from failing to be complete annual recertification Important New Rules on Scan Interference Background: In the fall of 2012 two parallel efforts started to address problems regarding Whitelisting of ASV s IP addresses and problems around Scan interference: 1) an initiative by ASV Jesper Jurcenoks within the ASV community and 2) an initiative by Jody B. Lee from TSYS within the Payment processing community. In November 2012 the two initiatives where merged and together produced a consensus recommendation for PCI SSC called ASV: Fail on Blocked Scan a PCI Industry consensus document This document was the basis for a major rewrite on the PCI rules for Scan interference. 3. Critical protection that keeps scan customers compliant does not have to be disabled anymore a. Still allowed systems: Systems that only record but does not interfere with traffic b. Still prohibited systems: Systems that block perceived good traffic based on trends, previous attack from same IP etc. c. New allowed systems: Systems that block traffic with perceived malicious contents, but that allows perceived non-malicious traffic pass even right after malicious traffic from the same source 4. More options available to ASVs and scan customers to resolve failing scans, including: a. Scan interference dispute resolution procedures b. Ability to consolidate overlapping inconclusive scans to create a conclusive report c. Ability to perform part of scan from behind the active defense mechanisms

8 Updated Section - ASV Scan Interference If an ASV detects that an active protection system has blocked or filtered a scan, then the ASV is required to handle it in accordance with the Resolving Inconclusive Scans section of this document. In order to ensure that reliable scans can be conducted, the ASV scan solution must be allowed to perform scanning without interference from active protection systems, where active denotes security systems that dynamically modify their behavior based on information gathered from non-attack network traffic patterns. Non-attack traffic refers to potentially legitimate network traffic patterns that do not indicate malformed or malicious traffic, whereas attack traffic includes, for example, malicious network traffic patterns or patterns that match known attack signatures, malware, or packets exceeding the maximum permitted IP packet size. Examples of active protection systems that dynamically modify their behavior include, but are not limited to: Intrusion prevention systems (IPS) that drop non-malicious packets based on previous behavior from originating IP address (for example, blocking all traffic from the originating IP address for a period of time because it detected one or more systems being scanned from the same IP address) Web application firewalls (WAF) that block all traffic from an IP address based on the number of events exceeding a defined threshold (for example, more than three requests to a login page per second) Firewalls that shun/block an IP address upon detection of a port scan from that IP address Next generation firewalls (NGF) that shun/block IP address ranges because an attack was perceived based on previous network traffic patterns Quality of Service (QoS) devices that limit certain traffic based on traffic volume anomalies (for example, blocking DNS traffic because DNS traffic exceeded a defined threshold) Spam filters that blacklist a sending IP address based on certain previous SMTP command s originating from that address Such systems may react differently to an automated scanning solution than they would react to a targeted hacker attack, which could cause inaccuracies in the scan report.

9 Systems that consistently block attack traffic, while consistently allowing non -attack traffic to pass (even if the non-attack traffic follows attack traffic) typically do not cause ASV scan interference. Examples of these security systems (that do not dynamically modify their behavior, rather, they maintain consistent, static behavior based on rules or signatures) include, but are not limited to: Intrusion Detection Systems (IDS) that log events, track context or have a multifaceted approach to detecting attacks, but action is limited to alerting (there is no intervention) Web Application Firewalls (WAF) that detect and block SQL injections, but let non-attack traffic from the same source pass Intrusion Prevention Systems (IPS) that drop all occurrences of a certain attack, but let non-attack traffic from the same source pass Firewalls that are configured to always block certain ports, but always keep other ports open VPN servers that reject entities with invalid credentials but permit entities with valid credentials Antivirus software that blocks, quarantines, or deletes all known malware based on a database of defined signatures but permits all other perceived clean content Logging/monitoring systems, event and log aggregators, reporting engines Logging/monitoring systems, event and log aggregators, reporting engines. Being able to detect all vulnerabilities is part of the defense-in-depth approach of PCI DSS. If the scan cannot detect vulnerabilities on Internet -facing systems because the scan is blocked by an active protection system, those vulnerabilities will remain uncorrected and may be exploited by an attacker whose attack patterns don't trigger the active protection mechanism. All ASV scans must either be validated by the ASV to ensure they have not been blocked or filtered by an active protection system, or resolved in accordance with the Resolving Inconclusive Scans section of this document. Temporary configuration changes may need to be made by the scan customer to remove interference during a scan Due to the remote nature of external vulnerability scans and the need mentioned above to conduct a scan without interference from an active protection system, certain temporary

10 configuration changes to the scan customer s network devices may be necessary to obtain a scan that accurately assesses the scan customer s external security posture. Note that, per above, temporary configuration changes are not required for systems that consistently block attack traffic, while consistently allowing non -attack traffic to pass (even if the non-attack traffic follows directly after attack traffic). The changes in this section are considered temporary and are only required for the duration of the ASV scan, and only apply to external-facing IP addresses in scope for quarterly external vulnerability scans required by PCI DSS Requirement Scan customers are encouraged to work with the ASV to perform secure quarterly scans that do not unnecessarily expose the scan customer s network but also do not limit the final results of the scans as follows: o o o Agree on a time for the scan window each quarter to minimize how long changed configurations are in place. Conduct the scan during a maintenance window under the scan customer s standard change control processes, with full monitoring during the ASV scan. Configure the active protection systems to either: Monitor and log, but not to act against, the originating IP address(es) of the ASV, or Allow non-attack traffic to pass consistently (even if it comes right after attack traffic) Reapply the previous configurations as soon as the scan is complete Note: The intent of these temporary configuration changes is to ensure that an active protection system, such as an IPS reacting dynamically to traffic patterns, does not interfere with the ASV scan in a manner that would provide the ASV solution with a different view of the environment than the view an attacker would have. ASV scans tend to be noisy as they generate a lot of traffic in a short period of time. This is generally to ensure that a scan can be completed as quickly as possible. However, this type of approach can also lead to a high rate of reaction by active intrusion-prevention systems. An attacker will generally attempt to restrict the volume of their scans so they are stealthier and less likely to trigger a log event that may be noticed. Thus, the high-volume scans typically performed by ASVs are significantly more likely to trigger an active protection mechanism than those of an attacker. Temporary configuration changes do not require that the scan customer provide the ASV a higher level of network access. Rather, the scan customer must ensure that any triggers, such as volume-based or correlated IP address thresholds, are not activated by the ASV scan and the scan is allowed to complete. The intent is that the ASV be provided the same network level view as an actual attacker.

11 New Section - Resolving Inconclusive Scans For ASV scans that cannot be completed due to scan interference, the scan customer may work with the ASV to implement one or more of the following options until a complete scan is achieved. An inconclusive scan that is left unresolved must be reported by the ASV as a failed scan: 1. Scan customer makes proper temporary configuration changes to remove interference during a scan; the scan customer may seek help from a trusted security professional as needed to determine proper temporary configuration changes to be made. Scan customer then contacts ASV to initiate another scan 2. Scan customer provides the ASV with sufficient written supporting evidence to support their assertion that the scan was not actively blocked. Scan customer and ASV work together to resolve scanning issues and schedule additional scan(s), as necessary, in order for the scans to cover all ports on all applicable systems. Note that if the ASV agrees that a scan was not actively blocked, the ASV may determine that all ports on all applicable systems have been scanned and that additional scans are not necessary 3. Scan customer and ASV agree on a method that allows the lab-validated ASV scan solution to complete a scan of the external interface(s) of all hosts without interference. This method must be operated and managed by the ASV in accordance with all ASV Program requ irements. For example, a secure connection (such as an IPsec VPN tunnel) could be implemented between the n 1 (s The ASV scan solution must complete a full scan of all external interfaces of the in -scope system components, in accordance with all ASV Program requirements, in order for the scan to be considered complete. Note: Where resolution of inconclusive scans involves ASV personnel, the personnel must be ASV Security Engineers who have been qualified by PCI SSC as per Section 3.2, "ASV Staff Skills and Experience" in the document PCI DSS Validation Requirements for Approved Scanning Vendors (ASVs). If the scan cannot be completed due to scan interference, the ASV should record the scan result as a failure, and clearly describe the conditions resulting in an inconclusive scan in the report under Exceptions, False Positives, or Compensating Controls as noted in Appendix B: ASV Scan Report Executive Summary. Details of Changes.

12 Every change enumerated and explained. Color Legend: Important Change 19 Instances Traced back to Consensus Suggested improvements for ASV Program Guide 2.0, Jan Instances Traced back to ASV: Fail on Blocked Scan? - a PCI Industry consensus document, Jan Instances Traced back to PCI DSS Instances

13 PCI ASV Program 1.0 Old PCI ASV Program New Change Type Footer PCI DSS, v1.2 ASV Program guide Reference, V1.0 ASV Program Guide v2.0 Simplification of title Approved Scanning Vendor Program Guide Introduction PCI DSS Payment Card Industry Data Security Standard (PCI DSS) Clarification PCI DSS Requirement 11.2 PCI DSS Requirement Clarification The PCI SSC recommends, but does not require, that scan customers use the requirements for other vulnerability scanning required by PCI DSS Requirement 11.2, including internal vulnerability scanning, external scanning performed after a significant change to the network, and any external scanning performed in addition to the required quarterly external scans. The PCI SSC recommends, but does not require, that scan customers use this document for other vulnerability scanning required by PCI DSS Requirement 11.2, including internal vulnerability scanning, scanning performed after a significant change to the network or applications, and any scanning performed in addition to the required quarterly external scans/rescans. Clarification Updates to Documents and Security Requirements As such, PCI SSC will endeavor to update PCI DSS requirements every 24 months. As such, PCI SSC will update PCI DSS requirements according to PCI SSC s defined three-year lifecycle process. Update to PCI DSS s new 3-year lifecycle PCI SSC reserves the right to change, amend or withdraw PCI DSS requirements at any time and will endeavor to work closely with its community of Participating Organizations regarding such changes. ASVs must implement the requirements set forth in this document by no later than September 1, 2010 PCI SSC reserves the right to change, amend or withdraw PCI DSS and/or ASV requirements at any time and will work closely with its community of Participating Organizations regarding such changes. ASVs must implement the requirements set forth in this document effective immediately since no changes in this document require changes Right to change updated to include ASV Documentations Stronger Language promising corporation with Community Grace period reduced none from 6 months

14 Terminology ASV(Approved Scanning Vendor) refers to a data security firm that has been qualified and trained by the PCI SSC to use a vulnerability scanning solution to determine compliance of their customers with the external vulnerability scanning requirement of PCI DSS Requirement 11.2 About PCI SSC The ASV documents and the PCI DSS define a common security assessment framework that is recognized by all payment brands. Roles and Responsibilities The following defines the roles and responsibilities of the stakeholders in the payment application community. Approved Scanning Vendors ASVs are responsible for the following:. Providing a determination as to whether the scan customer s components have passed the scanning requirement Scan Customers Scan customers are responsible for the following: to the ASVs scanning solution. ASV (Approved Scanning Vendor) Refers to a company that has been approved by PCI SSC to conduct external vulnerability scanning services in accordance with PCI DSS Requirement Refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms. Scan interference Refers to interference including (but not limited to) active protection systems blocking, filtering, dropping or modifying network packets in response to scan traffic, such that the view of the environment would be changed and the ASV scanning solution would no longer see what an attacker would see. The ASV documents and the PCI DSS define a common security assessment framework that is recognized by the payment brands. The following defines the roles and responsibilities of the stakeholders in the payment community. ASVs are responsible for the following: Maintaining security and integrity of systems and tools used to perform scans Providing a determination as to whether the scan customer s components have met the scanning requirement Scan customers are responsible for the following: Changes to definition of ASV, Important to note that an ASV is no more required to be a Data Security Firm, only that they have to be approved by PCI SSC New Clearer Definition of Scan Interference Clarification to show that PCI SSC does not (yet) represent all Payment brands Clarification Stakeholders are not limited to payment application community New Responsibility added to ASV s meeting instead of passing a requirement is more correct English. Responsibility for trusting ASV is put on

15 Perform due diligence in the ASV selection process, per the scan customer s due-diligence processes, to obtain assurance as to the ASV s level of trust to perform scanning services customer, away from PCI SSC Configuring intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) so they do not interfere with the ASV s scan, as required by this document. See the section entitled Perform a Scan without Interference from IDS/IPS. Arranging with ASV to re-scan any non-compliant IP addresses to obtain a passing quarterly scan Scan Process Overview Vulnerability-scanning companies interested in providing PCI DSS vulnerability scans in conjunction with PCI DSS must comply with the requirements set forth in this document as well as the Validation Requirements for Approved Scanning Vendors (ASVs), and must successfully complete the PCI Security Scanning Vendor Testing and Approval Process. The main phases of the scanning process consist of: Scoping Scanning Dispute Resolution Reporting/remediation PCI DSS Requirement 11.2 To the degree deemed appropriate by the scan customer, monitor Internet -facing systems, active protection systems, and network traffic during the scan, to assure an acceptable level of trust is maintained Configuring active protection systems so they do not interfere with the ASV s scan, as required by this document. See the section entitled ASV Scan Interference. Arranging with ASV to re-scan any non-compliant systems to verify that all high severity and medium severity vulnerabilities have been resolved, to obtain a passing quarterly scan Vulnerability-scanning companies interested in providing vulnerability scanning services in accordance with PCI DSS must comply with the requirements set forth in this document as well as the Validation Requirements for Approved Scanning Vendors (ASVs), and must successfully complete the PCI Security Scanning Vendor Testing and Approval Process. The main phases of the scanning process consist of: Scoping Scanning Reporting/remediation Dispute Resolution Rescan (as needed) Final reporting Changed from the narrow IDS/IPS to broader Active Protection systems Clarification that high and Medium Severity vulnerabilities must be resolved to obtain a passing scan. Clarification of language A few more phases included in the overview. PCI DSS 1.0 verbiage PCI DSS 2.0 Verbiage All Direct quotes from PCI DSS updated to PCI

16 Can a merchant or service provider perform their own external vulnerability scanning? Only ASV scan solutions can be used to perform the PCI DSS quarterly external vulnerability scans required by PCI DSS Requirement 11.2, and an ASV scan solution must be run by the ASV. Some ASV scan solutions may, under the control and management of the ASV, be started remotely by a scan customer via an ASV s web portal to allow a scan customer to select the best times to scan their cardholder data environment. However, only an authorized ASV employee can be allowed to configure any settings (e.g., disable any vulnerability checks SQL injection, XSS checks) or modify the output of the scan. Merchants and service providers must use only PCI SSC Approved Scanning Vendors (ASVs) to perform the quarterly external vulnerability scans required by PCI DSS Requirement , and an ASV scan solution must be executed and managed by the ASV. Some ASV scan solutions may, while still under the control and management of the ASV, be started remotely by a scan customer (for example, via an ASV s web portal and/or ASV s scan solution) to allow a scan customer to select the best times to scan their cardholder data environment and define which of the customer s IP addresses are to be scanned. However, only an authorized ASV employee is permitted to configure any settings (for example, modify or disable any vulnerability checks, assign severity levels, alter scan parameters, etc ), or modify the output of the scan. Scanning Vendor Testing and Approval Process 2. The scanning vendor notifies PCI SSC at that the ASV company is ready to be tested. 3. The PCI SSC notifies the scanning vendor to schedule the test. 4. The scanning vendor submits the solution for testing to PCI SSC via the ASV Portal. a. The scanning vendor uses this portal to create the solution for testing. (PCI SSC provides instructions for the portal with Step 3 above.) Note: Scanning Vendor Testing via the ASV Test Bed is an annual process. 2. The scanning vendor notifies PCI SSC at that the scanning vendor is ready to be tested. 3. The PCI SSC notifies the scanning vendor to schedule the test, and provides the scanning vendor with instructions for the ASV Portal. 4. The scanning vendor submits a request for solution testing via the ASV Portal. Note: Scanning Vendor Testing via the ASV Test Bed is an annual requirement. DSS 2.0 Important clarification: Some Scan customers incorrectly believed that buying and installing the same scanning product that the ASV used would enable them to perform their own ASV scan. ASV scans have to be done by the ASV. Clarified confusing language Cleaning up the language for the procedure Clarification that Annual Vendor testing

17 is a requirement Fees will be charged for the various testing stages in accordance with the PCI ASV Compliance Test Agreement, Schedule 1. Fees will be charged for the various testing stages in accordance with the PCI SSC Programs Fee Schedule. Fees for Certification of the ASV is now removed from the Test Agreement and put in a separate Fee Schedule in the PCI SSC web-site (here) ASV Scan Scope Definition Note: Per the PCI DSS, System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Scan customers can use segmentation to reduce the scope of the ASV scanning. Note: In the context of PCI DSS, System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. System components also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desk tops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Scan customers may use segmentation to reduce the scope of the ASV scanning. System components enhanced specifically to include Virtual environments. Cardholder Data environment (CDE) has been expanded to include People and processes Changed can to may to emphasize optional measures to reduce scope. Scan Customers Provide Internetfacing IP Addresses and Domains Scan Customers Provide Internet-facing IP Addresses and Domains Any other public-facing domains or domain aliases Internet Service Providers and Hosting Providers This section applies to the scan customer s Internet service provider (ISP) or hosting provider (if used by scan customers to host their website). This section applies to the scan customer s Internet service provider (ISP) or hosting provider (if used by scan customers to host part or all of their CDE). List of items to be provided by the scan customer enhanced with Domains. Definition enhanced from Web-site to include all of CDE.

18 For ISPs, scan customers need to coordinate with them to allow the ASV scan to be performed without interference from IDS or IPS. For more details, see the section entitled Perform a Scan without Interference from IDS/IPS. For ISPs, scan customers need to coordinate with them to allow the ASV scan to be performed without interference from active protection systems. For more details, see the section entitled ASV Scan Interference. Updated wording to Reflect new policy on scan interference. For hosting providers and their shared hosting environments, it is common practice that a single server will host more than one website. In a shared hosting environment, the scan customer shares the server with the hosting provider s other customers. This could lead to the merchant s website being compromised through security weaknesses on other customers websites on the hosting provider s server. In a shared hosting environment, the scan customer shares the environment with the hosting provider s other customers. This could lead to the scan customer s environment being compromised through security weaknesses in other customers environments at the hosting provider. Components commonly hosted by thirdparty providers include but are not limited to DNS servers, and web servers, application servers, etc. Clarified definition of shared hosting environment. Note: If the hosting provider has all Internet-facing IP ranges AND all scan customers domains scanned as part of the hosting provider s own ASV scans, and provides proof to scan customers, the domains do not have to be included in the scan customers ASV scans. Note: If the hosting provider has all Internet -facing IP ranges AND all scan customers domains scanned as part of the hosting provider s own ASV scans, and provides proof of passing scans to scan customers, the domains do not have to be included in the scan customers ASV scans Clarification: it is not enough that the Hosting provide has an ASV Scan, it must be a passing ASV scan. ASVs Confirm Scope and List Additional Components Identified during Discovery Include any IP address or domain that was previously provided to the ASV that has been removed at the request of the customer. Include any IP address or domain previously provided to the ASV and still owned by the customer that has been removed at the request of the customer. o If the customer no longer owns or has custody of the IP address/domain, include Change to avoid list of IPs not scanned previously growing indefinitely.

19 ASV Scan Interference that IP address or domain for at least one additional quarter after it was removed from scope or released by the customer. In order to ensure that reliable scans can be conducted, the ASV scan solution must be allowed to perform scanning without interference from intrusion detection systems (IDSs) or intrusion prevention systems (IPSs.. If an ASV detects that an IDS/IPS has blocked or filtered a scan, then the ASV is required to fail the scan as inconclusive. All ASV scans must be validated by the ASV to ensure they have not been blocked or filtered by an IDS/IPS. If an ASV detects that an active protection system has blocked or filtered a scan, then the ASV is required to handle it in accordance with the Resolving Inconclusive Scans section of this document. The intent is that the ASV be provided the same network level view as an actual attacker. ASV Scan Solution Required Components Additionally, accurate operating system and service version identification can help scan customers in understanding their risks and prioritizing remediation activities. The ASV scanning solution should, where possible, determine the protocol and service/application version running on each open port. Since services may sometimes run on nonstandard ports, the ASV scanning solution should, where possible, not rely solely on a well- known port number to determine which protocol is running on a given port. Thus, the ASV scan tools must accommodate external load balancing scenarios to ensure that all IP addresses and ranges provided by the scan customer are successfully scanned. Additionally, accurate operating system and service version identification can help scan customers understand their risks and prioritize remediation activities. The ASV scanning solution should also, where possible, determine the protocol and service/application version running on each open port. Since services may sometimes run on non-standard ports, the ASV scanning solution should, where possible, not rely solely on a well - known port number to determine which protocol or service is running on a given port. Thus, the ASV scan solution must accommodate external load balancing scenarios to ensure that all IP addresses and ranges provided by the scan customer are successfully scanned. Major Rewrite See separate discussion of what this means to you. Fixing the language Fixing the language Clarification Changed ASV scan tool to the more encompassing ASV scan solution

20 Table 1: Required Components for PCI DSS Vulnerability Scanning Language cleanup Firewalls and routers, which control traffic between the company s network and external untrusted networks (for example, the Internet), have known vulnerabilities for which patches are released periodically. Malicious individuals exploit operating system vulnerabilities to get access to internal databases that potentially store cardholder data. Firewalls and routers, which control traffic between the company s network and external untrusted networks (for example, the Internet), have known vulnerabilities for which patches are periodically released. Malicious individuals exploit operating system vulnerabilities to gain access to applications and internal databases that potentially store, process or manage access to cardholder data. Language cleaned up and enhanced to be in line with PCI DSS 2.0 requirement. The ASV scanning solution must also be able to determine the version of the operating system and whether it is an older version no longer supported by the vendor, in which case it must be marked as an automatic failure by the ASV. Malicious individuals exploit vulnerabilities in these servers to get access to cardholder data. Web servers allow Internet users to view web pages, interact with web merchants, and make online web purchases. Note to scan customer: Browsing of directories on web servers can lead to information disclosure or potential exploit. Due to increased risk to the cardholder data environment, please 1) justify the business need for this configuration to the ASV, or 2) confirm that it is disabled. Please consult your ASV if you have questions about this Special Note. Application servers act as the interface between the web server and the backend databases and legacy systems. For example, when cardholders share account numbers with merchants or service providers, the application server provides the functionality to transport data in and out of the secured network. Malicious individuals exploit vulnerabilities in these servers and their scripts to get access to internal databases that potentially store credit card data. The ASV scanning solution must also be able to determine the version of the operating system and whether it is a version no longer supported by the vendor, in which case it must be marked as an automatic failure by the ASV. Malicious individuals exploit vulnerabilities in these servers to gain access to cardholder data. Web servers allow Internet users to view web pages, interact with web merchants, and conduct online web trans actions. Note to scan customer: Browsing of directories on web servers can lead to information disclosure or potential exploit. Due to increased risk to the cardholder data environment, 1) justify the business need for this configuration to the ASV, or 2) confirm that it is disabled. Consult your ASV if you have questions about this Special Note. Application servers act as the interface between the web server and other systems, such as back-end databases. For example, when cardholders s hare account numbers with merchants or service providers, the application server provides the functionality to trans port data in and out of the secured network. Malicious individuals exploit vulnerabilities in these servers and their scripts to gain access to applications or internal databases that potentially s tore, process or manage access to cardholder data. Clarification: Nonsupported OS is automatic failure even if it is not old Language cleanup Purchases replaced with broader Transactions. New note Text, removed please. Language Cleanup Language Cleanup

21 The ASV scanning solution must be able to detect the presence of an application server and/or web application servers and detect any known vulnerability and configuration issues. Built-in, or default accounts and passwords are commonly used by hardware and software vendors to allow the customer their first access to the product. The ASV scan solution must be able to detect the presence of application servers and/or web application servers and detect known vulnerabilities and configuration issues. Built-in, or default accounts and passwords, are com m only used by hardware and software vendors to allow the customer initial access to the product. Language Cleanup Language cleanup For testing and reporting on built-in or default accounts in routers, firewalls, operating systems, web servers, database servers, applications, POS systems, or other components, the ASV scan solution, must do the following: For testing and reporting on built-in or default accounts in routers, firewalls, operating system s, web servers, database servers, applications, pointof-sale (POS) systems, or other components, the ASV scan solution, must do the following: Clarified POS systems. DNS servers resolve Internet addresses by translating domain names into IP addresses. If DNS servers are vulnerable, malicious individuals can masquerade as a merchant s or service provider s web page and collect cardholder data. Web applications reside on application servers or web application servers (see above), and interface with the back-end databases and legacy systems. For example, when cardholders share account numbers with merchants, the web application may take the cardholder data from a customer to process and complete the transaction, and store the transactions results and cardholder data in a database, all as part of the customer s online purchase. DNS servers are used to locate resources on the Internet by resolving domain names to their respective IP address. If DNS servers are vulnerable, malicious individuals can masquerade as or redirect traffic from a merchant s or service provider s web page and collect cardholder data. Web applications typically res ide on web or application servers and interface with the back-end databases and other systems. Web applications may process or trans m it cardholder data as part of the customer s online trans action, or s tore such data in a database server. Clarification of what a DNS server does Clarification of Risks Language simplification and cleanup Malicious individuals frequently exploit application vulnerabilities to gain access to internal databases that potentially store cardholder data. Remote access software includes, but is not limited to: VPN (IPSec, PPTP, SSL), pcanywhere, VNC, Microsoft Terminal Server, remote web-based administration, ssh, Telnet. Malicious individuals frequently attempt to exploit web application vulnerabilities to gain access to applications or internal databases that m ay process, s tore, or manage access to cardholder data. Remote access software includes, but is not limited to: VPN (IPSec, PPTP, SSL), pcanywhere, VNC, Micros oft Term inal Server, remote web-based administration, SSH, and Telnet. Aligned language with PCI DSS 2.0 Clarification, remote access software is an and list not an or list Note to scan customer: Due to increased risk to the cardholder data environment Note to scan customer: Due to increased risk to the cardholder data Updated Note Text.

22 when remote access software is present, please 1) justify the business need for this software to the ASV and 2) confirm it is either implemented securely per Appendix C or disabled/ removed. Please consult your ASV if you have questions about this Special Note. Note to scan customer: Due to increased risk to the cardholder data environment when a point-of-sale system is visible on the Internet, please 1) confirm that this system needs to be visible on the Internet, that the system is implemented securely, and that original default passwords have been changed to complex passwords, or 2) confirm that the system has been reconfigured and is no longer visible to the Internet. Please consult your ASV if you have questions about this Special Note. Vulnerability Reporting To demonstrate compliance, a scan must not contain high-level vulnerabilities, or any vulnerability that indicate features or configurations that are in violation of PCI DSS. If these exist, the ASV must consult with the client to determine whether these are, in fact, PCI DSS violations and therefore warrant a noncompliant scan report. Vulnerability Categorization To assist customers in prioritizing the solution or mitigation of identified issues, ASVs must assign a severity level to each identified vulnerability or misconfiguration. environment when remote access software is present, 1) justify the business need for this software to the ASV and confirm it is implemented securely per Appendix D of the ASV Program Guide, or 2) confirm it is disabled/ removed. Consult your ASV if you have questions about this Special Note. Note to scan customer: Due to increased risk to the cardholder data environment when a point-of-sale system is visible on the Internet, 1) confirm that this system needs to be visible on the Internet, that the system is implemented securely, and that original default passwords have been changed to complex passwords, or 2) confirm that the system has been reconfigured and is no longer visible to the Internet. Consult your ASV if you have questions about this Special Note. To demonstrate compliance, a scan must not contain high or medium severity vulnerabilities, or any vulnerability that indicates features or configurations that are in violation of PCI DSS. If these exist, the ASV must consult with the scan customer to determine whether these are, in fact, PCI DSS violations and therefore warrant a noncompliant scan report. To assist customers in prioritizing the solution or mitigating identified issues, ASVs must assign a severity level to each identified vulnerability or misconfiguration, as defined in Table 2 in the next page. Removed 2 x please Appendix Reference updated to point to the correct appendix. Updated Note Text. Removed 2 x please Changed from high level or high or medium severity to be in line with rest of requirements. Changed client to scan customer to be in line with rest fo document. Cleaned up language and added reference to existing table on next page. The designation of each severity level must allow for an easy comparison between levels. Therefore, a severity ranking that is easy to understand must be [intentionally left blank] Requirement that the Severity ranking must be easy to understand

23 presented, with High Severity, Medium Severity, Low Severity. and easy to compare has been removed. Severity is to always be presented, easy or not. The National Vulnerability Database (NVD), which is maintained by the National Institute of Standards and Technology (NIST). The NVD contains details of known vulnerabilities based on the Common Vulnerabilities and Exposures (CVE) dictionary. The NVD has adopted the CVSS and publishes CVSS Base Scores for each vulnerability. ASVs should use the CVSS scores whenever they are available. Table 2: To achieve a passing scan, these vulnerabilities must be corrected and the environment must be re-scanned after the corrections (with a report that shows a passing scan). Organizations should take a risk-based approach to correct these types of vulnerabilities, starting with the most critical ones (rated 10.0), then those rated 9, followed by those rated 8, 7, etc., until all vulnerabilities rated 4.0 through 10.0 are corrected. The National Vulnerability Database, which is maintained by the National Institute of Standards and Technology ( NIST). The NVD contains details of known vulnerabilities based on the CVE dictionary. The NVD has adopted the CVSS and publishes CVSS Base Scores for each vulnerability. ASVs should us e the CVSS scores whenever they are available. To achieve a passing scan, these vulnerabilities must be corrected and the affected systems must be re- scanned after the corrections (with a report that shows a passing scan). Organizations should take a risk- based approach to correct these types of vulnerabilities, starting with the most critical (rated 10.0), then those rated 9, followed by those rated 8, 7, etc., until all vulnerabilities rated 4.0 through 10.0 are corrected. Redundant abbreviations moved to definitions section. Vulnerability Severity Levels Based on the NVD and CVSS Scoring Important change only rescan of affected systems is now required and not the entire environment. Compliance Determination Overall and by Component Reports must indicate compliance determination at two levels: by component and for the overall customer level. Overall Compliance Determination For a customer to be considered compliant, all components within the customer s cardholder data environment must be compliant. Scan Reporting Table 2 above describes how an ASV scan solution categorizes vulnerabilities and demonstrates the types of vulnerabilities and Reports must indicate compliance determination at two levels: by component level, and for the overall customer level. For a scan customer to be considered compliant, all components within the customer s cardholder data environment must be compliant. Table 2 above describes how an ASV scan solution categorizes vulnerabilities and demonstrates the types of vulnerabilities and risks that Cleanup Language customer changed to scan customer for alignment with definitions in rest of document. Clarification of severity levels

24 risks that are considered highlevel. are considered high or medium severity. Generating, Reading, and Interpreting Scan Reports Attestation of Scan Compliance content, please see Appendix A: ASV Scan Report Attestation of Scan Compliance for required template. Attestation of Scan Compliance content, see Appendix A: ASV Scan Report Attestation of Scan Compliance for required template. Removed a please to signify that the Report template is mandatory 2. ASV Scan Report Executive Summary This lists vulnerabilities by components (IP address) and shows whether each IP address scanned received a passing score and met the scan validation requirement. Executive Summary content Please see Appendix B: ASV Scan Report Executive Summary for required template, which includes the following. Scan Customer and ASV Attestations This section lists vulnerabilities by components (IP address) and shows whether each IP address scanned received a passing score and met the scan validation requirement. Executive Summary content See Appendix B: ASV Scan Report Executive Summary for required template, which includes the following: Clarification Removed a please to signify that the Report template is mandatory These attestations (once completed by the scan customer and ASV) are included on the Attestation of Scan Compliance cover sheet. Acknowledgement that scan results only indicate whether scanned systems are compliant with the external vulnerability scan requirement (PCI DSS 11.2) and are not an indication of overall compliance with any other PCI DSS requirements. Reviews and corrects connectivity issues between scanner and scan customer Scan Customer Attestation Mandatory text this scan result does not represent (Scan customer name) s my overall compliance status with PCI DSS These attestations (once completed by the scan customer and ASV) are included on the Attestation of Scan Compliance cover sheet. ASVs may not use the same Attestion of Scan Compliance for multiple quarters. The scan customer attestation must be generated each quarter for the scan identified in the Scan Report, and must be completed before each Scan Report is finalized. Acknowledgement that scan results only indicate whether scanned systems are compliant with the external quarterly vulnerability scan requirement (PCI DSS ) and are not an indication of overall compliance with any other PCI DSS requirements. Reviews and corrects connectivity issues between the scan solution and scan customer this scan result does not represent (Scan customer name) s overall compliance status with PCI DSS Clarification that Attestations must be made for each report. Clarification Cleaned up Language Removed an extraneous my from the mandatory text

Payment Card Industry (PCI) Data Security Standard Approved Scanning Vendors

Payment Card Industry (PCI) Data Security Standard Approved Scanning Vendors Payment Card Industry (PCI) Data Security Standard Approved Scanning Vendors Program Guide Version 2.0 May 2013 Document Changes Date Version Description February 11, 2010 1.0 May 2013 2.0 Approved Scanning

More information

Payment Card Industry (PCI) Approved Scanning Vendors. Program Guide Reference 1.0 PCI DSS Version 1.2

Payment Card Industry (PCI) Approved Scanning Vendors. Program Guide Reference 1.0 PCI DSS Version 1.2 Payment Card Industry (PCI) Approved Scanning Vendors Program Guide Reference 1.0 PCI DSS Version 1.2 March 2010 Document Changes Date Version Description February 11, 2010 1.0 ASV Program Guide Reference

More information

Payment Card Industry (PCI) Data Security Standard

Payment Card Industry (PCI) Data Security Standard Payment Card Industry (PCI) Data Security Standard Security Scanning Procedures Version 1.1 Release: September 2006 Table of Contents Purpose...1 Introduction...1 Scope of PCI Security Scanning...1 Scanning

More information

Payment Card Industry (PCI) Data Security Standard

Payment Card Industry (PCI) Data Security Standard Payment Card Industry (PCI) Data Security Standard Technical and Operational Requirements for Approved Scanning Vendors (ASVs) Version 1.1 Release: September 2006 Table of Contents Introduction...1-1 Naming

More information

Payment Card Industry (PCI) Executive Report 08/04/2014

Payment Card Industry (PCI) Executive Report 08/04/2014 Payment Card Industry (PCI) Executive Report 08/04/2014 ASV Scan Report Attestation of Scan Compliance Scan Customer Information Approved Scanning Vendor Information Company: A.B. Yazamut Company: Qualys

More information

Payment Card Industry (PCI) Executive Report 10/27/2015

Payment Card Industry (PCI) Executive Report 10/27/2015 Payment Card Industry (PCI) Executive Report 10/27/2015 ASV Scan Report Attestation of Scan Compliance Scan Customer Information Approved Scanning Vendor Information Company: Rural Computer Consultants

More information

Case 2:13-cv-01887-ES-JAD Document 282-2 Filed 12/09/15 Page 1 of 116 PageID: 4879. Appendix A

Case 2:13-cv-01887-ES-JAD Document 282-2 Filed 12/09/15 Page 1 of 116 PageID: 4879. Appendix A Case 2:13-cv-01887-ES-JAD Document 282-2 Filed 12/09/15 Page 1 of 116 PageID: 4879 Appendix A Case 2:13-cv-01887-ES-JAD Document 282-2 Filed 12/09/15 Page 2 of 116 PageID: 4880 Payment Card Industry (PCI)

More information

PCI Security Scan Procedures. Version 1.0 December 2004

PCI Security Scan Procedures. Version 1.0 December 2004 PCI Security Scan Procedures Version 1.0 December 2004 Disclaimer The Payment Card Industry (PCI) is to be used as a guideline for all entities that store, process, or transmit Visa cardholder data conducting

More information

ARE YOU REALLY PCI DSS COMPLIANT? Case Studies of PCI DSS Failure! Jeff Foresman, PCI-QSA, CISSP Partner PONDURANCE

ARE YOU REALLY PCI DSS COMPLIANT? Case Studies of PCI DSS Failure! Jeff Foresman, PCI-QSA, CISSP Partner PONDURANCE ARE YOU REALLY PCI DSS COMPLIANT? Case Studies of PCI DSS Failure! Jeff Foresman, PCI-QSA, CISSP Partner PONDURANCE AGENDA PCI DSS Basics Case Studies of PCI DSS Failure! Common Problems with PCI DSS Compliance

More information

Nessus Enterprise Cloud User Guide. October 2, 2014 (Revision 9)

Nessus Enterprise Cloud User Guide. October 2, 2014 (Revision 9) Nessus Enterprise Cloud User Guide October 2, 2014 (Revision 9) Table of Contents Introduction... 3 Nessus Enterprise Cloud... 3 Subscription and Activation... 3 Multi Scanner Support... 4 Customer Scanning

More information

INFORMATION SUPPLEMENT. Migrating from SSL and Early TLS. Version 1.0 Date: April 2015 Author: PCI Security Standards Council

INFORMATION SUPPLEMENT. Migrating from SSL and Early TLS. Version 1.0 Date: April 2015 Author: PCI Security Standards Council Version 1.0 Date: Author: PCI Security Standards Council Executive Summary The time to migrate is now. For over 20 years Secure Sockets Layer (SSL) has been in the market as one of the most widely-used

More information

Nessus Perimeter Service User Guide (HTML5 Interface) March 18, 2014 (Revision 9)

Nessus Perimeter Service User Guide (HTML5 Interface) March 18, 2014 (Revision 9) Nessus Perimeter Service User Guide (HTML5 Interface) March 18, 2014 (Revision 9) Table of Contents Introduction... 3 Nessus Perimeter Service... 3 Subscription and Activation... 3 Multi Scanner Support...

More information

Top Three POS System Vulnerabilities Identified to Promote Data Security Awareness

Top Three POS System Vulnerabilities Identified to Promote Data Security Awareness CISP BULLETIN Top Three POS System Vulnerabilities Identified to Promote Data Security Awareness November 21, 2006 To support compliance with the Cardholder Information Security Program (CISP), Visa USA

More information

PCI Compliance - A Realistic Approach. Harshul Joshi, CISM, CISA, CISSP Director, Information Technology CBIZ MHM hjoshi@cbiz.com

PCI Compliance - A Realistic Approach. Harshul Joshi, CISM, CISA, CISSP Director, Information Technology CBIZ MHM hjoshi@cbiz.com PCI Compliance - A Realistic Approach Harshul Joshi, CISM, CISA, CISSP Director, Information Technology CBIZ MHM hjoshi@cbiz.com What What is PCI A global forum launched in September 2006 for ongoing enhancement

More information

Payment Card Industry (PCI) Data Security Standard. Summary of Changes from PCI DSS Version 2.0 to 3.0

Payment Card Industry (PCI) Data Security Standard. Summary of Changes from PCI DSS Version 2.0 to 3.0 Payment Card Industry (PCI) Data Security Standard Summary of s from Version 2.0 to 3.0 November 2013 Introduction This document provides a summary of changes from v2.0 to v3.0. Table 1 provides an overview

More information

Achieving PCI-Compliance through Cyberoam

Achieving PCI-Compliance through Cyberoam White paper Achieving PCI-Compliance through Cyberoam The Payment Card Industry (PCI) Data Security Standard (DSS) aims to assure cardholders that their card details are safe and secure when their debit

More information

GFI White Paper PCI-DSS compliance and GFI Software products

GFI White Paper PCI-DSS compliance and GFI Software products White Paper PCI-DSS compliance and Software products The Payment Card Industry Data Standard () compliance is a set of specific security standards developed by the payment brands* to help promote the adoption

More information

Payment Card Industry (PCI) Data Security Standard ROC Reporting Instructions for PCI DSS v2.0

Payment Card Industry (PCI) Data Security Standard ROC Reporting Instructions for PCI DSS v2.0 Payment Card Industry (PCI) Data Security Standard ROC Reporting Instructions for PCI DSS v2.0 September 2011 Changes Date September 2011 Version Description 1.0 To introduce PCI DSS ROC Reporting Instructions

More information

PCI DSS 3.0 : THE CHANGES AND HOW THEY WILL EFFECT YOUR BUSINESS

PCI DSS 3.0 : THE CHANGES AND HOW THEY WILL EFFECT YOUR BUSINESS PCI DSS 3.0 : THE CHANGES AND HOW THEY WILL EFFECT YOUR BUSINESS CIVICA Conference 22 January 2015 WELCOME AND AGENDA Change is here! PCI-DSS 3.0 is mandatory starting January 1, 2015 Goals of the session

More information

Breach Findings for Large Merchants. 28 January 2015 Glen Jones Cyber Intelligence and Investigation Lester Chan Payment System Security

Breach Findings for Large Merchants. 28 January 2015 Glen Jones Cyber Intelligence and Investigation Lester Chan Payment System Security Breach Findings for Large Merchants 28 January 2015 Glen Jones Cyber Intelligence and Investigation Lester Chan Payment System Security Disclaimer The information or recommendations contained herein are

More information

REDSEAL NETWORKS SOLUTION BRIEF. Proactive Network Intelligence Solutions For PCI DSS Compliance

REDSEAL NETWORKS SOLUTION BRIEF. Proactive Network Intelligence Solutions For PCI DSS Compliance REDSEAL NETWORKS SOLUTION BRIEF Proactive Network Intelligence Solutions For PCI DSS Compliance Overview PCI DSS has become a global requirement for all entities handling cardholder data. A company processing,

More information

PCI DSS Reporting WHITEPAPER

PCI DSS Reporting WHITEPAPER WHITEPAPER PCI DSS Reporting CONTENTS Executive Summary 2 Latest Patches not Installed 3 Vulnerability Dashboard 4 Web Application Protection 5 Users Logging into Sensitive Servers 6 Failed Login Attempts

More information

IBM. Vulnerability scanning and best practices

IBM. Vulnerability scanning and best practices IBM Vulnerability scanning and best practices ii Vulnerability scanning and best practices Contents Vulnerability scanning strategy and best practices.............. 1 Scan types............... 2 Scan duration

More information

LogRhythm and PCI Compliance

LogRhythm and PCI Compliance LogRhythm and PCI Compliance The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent

More information

Don Roeber Vice President, PCI Compliance Manager. Lisa Tedeschi Assistant Vice President, Compliance Officer

Don Roeber Vice President, PCI Compliance Manager. Lisa Tedeschi Assistant Vice President, Compliance Officer Complying with the PCI DSS All the Moving Parts Don Roeber Vice President, PCI Compliance Manager Lisa Tedeschi Assistant Vice President, Compliance Officer Types of Risk Operational Risk Normal fraud

More information

Payment Card Industry (PCI) Data Security Standard. Summary of Changes from PCI DSS Version 1.2.1 to 2.0

Payment Card Industry (PCI) Data Security Standard. Summary of Changes from PCI DSS Version 1.2.1 to 2.0 Payment Card Industry (PCI) Data Security Standard Summary of s from PCI DSS Version 1.2.1 to 2.0 October 2010 General General Throughout Removed specific references to the Glossary as references are generally

More information

March 2012 www.tufin.com

March 2012 www.tufin.com SecureTrack Supporting Compliance with PCI DSS 2.0 March 2012 www.tufin.com Table of Contents Introduction... 3 The Importance of Network Security Operations... 3 Supporting PCI DSS with Automated Solutions...

More information

Application Reviews and Web Application Firewalls Clarified. Information Supplement: PCI Data Security Standard (PCI DSS) Requirement:

Application Reviews and Web Application Firewalls Clarified. Information Supplement: PCI Data Security Standard (PCI DSS) Requirement: Standard: Version: Date: Requirement: Author: PCI Data Security Standard (PCI DSS) 1.2 October 2008 6.6 PCI Security Standards Council Information Supplement: Application Reviews and Web Application Firewalls

More information

ANNEXURE-1 TO THE TENDER ENQUIRY NO.: DPS/AMPU/MIC/1896. Network Security Software Nessus- Technical Details

ANNEXURE-1 TO THE TENDER ENQUIRY NO.: DPS/AMPU/MIC/1896. Network Security Software Nessus- Technical Details Sub: Supply, Installation, setup and testing of Tenable Network Security Nessus vulnerability scanner professional version 6 or latest for scanning the LAN, VLAN, VPN and IPs with 3 years License/Subscription

More information

PCI DSS 3.0 Changes Bill Franklin Executive IT Auditor bfranklin@compassitc.com January 23, 2014

PCI DSS 3.0 Changes Bill Franklin Executive IT Auditor bfranklin@compassitc.com January 23, 2014 PCI DSS 3.0 Changes Bill Franklin Executive IT Auditor bfranklin@compassitc.com January 23, 2014 Agenda Introduction PCI DSS 3.0 Changes What Can I Do to Prepare? When Do I Need to be Compliant? Questions

More information

Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified

Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified Standard: Data Security Standard (DSS) Requirement: 6.6 Date: February 2008 Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified Release date: 2008-04-15 General PCI

More information

Best Practices for PCI DSS V3.0 Network Security Compliance

Best Practices for PCI DSS V3.0 Network Security Compliance Best Practices for PCI DSS V3.0 Network Security Compliance January 2015 www.tufin.com Table of Contents Preparing for PCI DSS V3.0 Audit... 3 Protecting Cardholder Data with PCI DSS... 3 Complying with

More information

AUTOMATING AUDITS AND ENSURING CONTINUOUS COMPLIANCE WITH ALGOSEC

AUTOMATING AUDITS AND ENSURING CONTINUOUS COMPLIANCE WITH ALGOSEC AUTOMATING AUDITS AND ENSURING CONTINUOUS COMPLIANCE WITH ALGOSEC MANAGE SECURITY AT THE SPEED OF BUSINESS AlgoSec Whitepaper Simplifying PCI-DSS Audits and Ensuring Continuous Compliance with AlgoSec

More information

ADDING NETWORK INTELLIGENCE TO VULNERABILITY MANAGEMENT

ADDING NETWORK INTELLIGENCE TO VULNERABILITY MANAGEMENT ADDING NETWORK INTELLIGENCE INTRODUCTION Vulnerability management is crucial to network security. Not only are known vulnerabilities propagating dramatically, but so is their severity and complexity. Organizations

More information

Why Is Compliance with PCI DSS Important?

Why Is Compliance with PCI DSS Important? Why Is Compliance with PCI DSS Important? The members of PCI Security Standards Council (American Express, Discover, JCB, MasterCard, and Visa) continually monitor cases of account data compromise. These

More information

Global Partner Management Notice

Global Partner Management Notice Global Partner Management Notice Subject: Critical Vulnerabilities Identified to Alert Payment System Participants of Data Compromise Trends Dated: May 4, 2009 Announcement: To support compliance with

More information

Bottom line you must be compliant. It s the law. If you aren t compliant, you are leaving yourself open to fines, lawsuits and potentially closure.

Bottom line you must be compliant. It s the law. If you aren t compliant, you are leaving yourself open to fines, lawsuits and potentially closure. Payment Card Industry Security Standards Over the past years, a series of new rules and regulations regarding consumer safety and identify theft have been enacted by both the government and the PCI Security

More information

Online Compliance Program for PCI

Online Compliance Program for PCI Appendix F Online Compliance Program for PCI Service Description for PCI Compliance Monitors 1. General Introduction... 3 2. Online Compliance Program... 4 2.1 Introduction... 4 2.2 Portal Access... 4

More information

Information Security Services. Achieving PCI compliance with Dell SecureWorks security services

Information Security Services. Achieving PCI compliance with Dell SecureWorks security services Information Security Services Achieving PCI compliance with Dell SecureWorks security services Executive summary In October 2010, the Payment Card Industry (PCI) issued the new Data Security Standard (DSS)

More information

CORE Security and the Payment Card Industry Data Security Standard (PCI DSS)

CORE Security and the Payment Card Industry Data Security Standard (PCI DSS) CORE Security and the Payment Card Industry Data Security Standard (PCI DSS) Addressing the PCI DSS with Predictive Security Intelligence Solutions from CORE Security CORE Security +1 617.399-6980 info@coresecurity.com

More information

74% 96 Action Items. Compliance

74% 96 Action Items. Compliance Compliance Report PCI DSS 2.0 Generated by Check Point Compliance Blade, on July 02, 2013 11:12 AM 1 74% Compliance 96 Action Items Upcoming 0 items About PCI DSS 2.0 PCI-DSS is a legal obligation mandated

More information

State of Minnesota. Office of Enterprise Technology (OET) Enterprise Vulnerability Management Security Standard

State of Minnesota. Office of Enterprise Technology (OET) Enterprise Vulnerability Management Security Standard State of Minnesota Office of Enterprise Technology (OET) Enterprise Vulnerability Management Security Standard Approval: Enterprise Security Office (ESO) Standard Version 1.00 Gopal Khanna

More information

Becoming PCI Compliant

Becoming PCI Compliant Becoming PCI Compliant Jason Brown - brownj52@michigan.gov Enterprise Security Architect Enterprise Architecture Department of Technology, Management and Budget State of Michigan @jasonbrown17 History

More information

Session 2: Self Assessment Questionnaire

Session 2: Self Assessment Questionnaire Session 2: Self Assessment Questionnaire and Network Scans Kurt Hagerman CISSP, QSA Director of IT Governance and Compliance Services Agenda Session 1: An Overview of the Payment Card Industry Session

More information

Cautela Labs Cloud Agile. Secured. Threat Management Security Solutions at Work

Cautela Labs Cloud Agile. Secured. Threat Management Security Solutions at Work Cautela Labs Cloud Agile. Secured. Threat Management Security Solutions at Work Security concerns and dangers come both from internal means as well as external. In order to enhance your security posture

More information

CHEAT SHEET: PCI DSS 3.1 COMPLIANCE

CHEAT SHEET: PCI DSS 3.1 COMPLIANCE CHEAT SHEET: PCI DSS 3.1 COMPLIANCE WHAT IS PCI DSS? Payment Card Industry Data Security Standard Information security standard for organizations that handle data for debit, credit, prepaid, e-purse, ATM,

More information

CONTENTS. PCI DSS Compliance Guide

CONTENTS. PCI DSS Compliance Guide CONTENTS PCI DSS COMPLIANCE FOR YOUR WEBSITE BUILD AND MAINTAIN A SECURE NETWORK AND SYSTEMS Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 2: Do not

More information

A Decision Maker s Guide to Securing an IT Infrastructure

A Decision Maker s Guide to Securing an IT Infrastructure A Decision Maker s Guide to Securing an IT Infrastructure A Rackspace White Paper Spring 2010 Summary With so many malicious attacks taking place now, securing an IT infrastructure is vital. The purpose

More information

Payment Card Industry (PCI) Data Security Standard. Requirements and Security Assessment Procedures. Version 3.1 April 2015

Payment Card Industry (PCI) Data Security Standard. Requirements and Security Assessment Procedures. Version 3.1 April 2015 Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.1 April 2015 Document Changes Date Version Description Pages October 2008 1.2 July 2009 1.2.1

More information

PCI Requirements Coverage Summary Table

PCI Requirements Coverage Summary Table StillSecure PCI Complete Managed PCI Compliance Solution PCI Requirements Coverage Summary Table December 2011 Table of Contents Introduction... 2 Coverage assumptions for PCI Complete deployments... 2

More information

UNDERSTANDING PCI 3.0 AND HOW TO REDUCE YOUR SCOPE

UNDERSTANDING PCI 3.0 AND HOW TO REDUCE YOUR SCOPE UNDERSTANDING PCI 3.0 AND HOW TO REDUCE YOUR SCOPE April 30 th, 2014 Sean Mathena CISSP, CISA, QSA Trustwave Managing Consultant WELCOME AND AGENDA PCI-DSS 3.0 Review the high-level areas that have changed

More information

NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS

NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS Scope and Applicability: These Network and Certificate System Security Requirements (Requirements) apply to all publicly trusted Certification Authorities

More information

PCI DSS Requirements - Security Controls and Processes

PCI DSS Requirements - Security Controls and Processes 1. Build and maintain a secure network 1.1 Establish firewall and router configuration standards that formalize testing whenever configurations change; that identify all connections to cardholder data

More information

Software Vulnerability Assessment

Software Vulnerability Assessment Software Vulnerability Assessment Setup Guide Contents: About Software Vulnerability Assessment Setting Up and Running a Vulnerability Scan Manage Ongoing Vulnerability Scans Perform Regularly Scheduled

More information

Penetration Testing Report Client: Business Solutions June 15 th 2015

Penetration Testing Report Client: Business Solutions June 15 th 2015 Penetration Testing Report Client: Business Solutions June 15 th 2015 Acumen Innovations 80 S.W 8 th St Suite 2000 Miami, FL 33130 United States of America Tel: 1-888-995-7803 Email: info@acumen-innovations.com

More information

NSFOCUS Web Application Firewall White Paper

NSFOCUS Web Application Firewall White Paper White Paper NSFOCUS Web Application Firewall White Paper By NSFOCUS White Paper - 2014 NSFOCUS NSFOCUS is the trademark of NSFOCUS Information Technology Co., Ltd. NSFOCUS enjoys all copyrights with respect

More information

PCI COMPLIANCE REQUIREMENTS COMPLIANCE CALENDAR

PCI COMPLIANCE REQUIREMENTS COMPLIANCE CALENDAR PCI COMPLIANCE REQUIREMENTS COMPLIANCE CALENDAR AUTHOR: UDIT PATHAK SENIOR SECURITY ANALYST udit.pathak@niiconsulting.com Public Network Intelligence India 1 Contents 1. Background... 3 2. PCI Compliance

More information

Payment Card Industry (PCI) Data Security Standard. Requirements and Security Assessment Procedures. Version 3.0 November 2013

Payment Card Industry (PCI) Data Security Standard. Requirements and Security Assessment Procedures. Version 3.0 November 2013 Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.0 November 2013 Document Changes Date Version Description Pages October 2008 1.2 July 2009 1.2.1

More information

NETASQ & PCI DSS. Is NETASQ compatible with PCI DSS? NG Firewall version 9

NETASQ & PCI DSS. Is NETASQ compatible with PCI DSS? NG Firewall version 9 NETASQ & PCI DSS Is NETASQ compatible with PCI DSS? We have often been asked this question. Unfortunately, even the best firewall is but an element in the process of PCI DSS certification. This document

More information

Payment Card Industry (PCI) Data Security Standard

Payment Card Industry (PCI) Data Security Standard Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 2.0 October 2010 Document Changes Date Version Description Pages October 2008 July 2009 October

More information

SolarWinds Security Information Management in the Payment Card Industry: Using SolarWinds Log & Event Manager (LEM) to Meet PCI Requirements

SolarWinds Security Information Management in the Payment Card Industry: Using SolarWinds Log & Event Manager (LEM) to Meet PCI Requirements SolarWinds Security Information Management in the Payment Card Industry: Using SolarWinds Log & Event Manager (LEM) to Meet PCI Requirements SolarWinds Security Information Management in the Payment Card

More information

Cyber - Security and Investigations. Ingrid Beierly August 18, 2008

Cyber - Security and Investigations. Ingrid Beierly August 18, 2008 Cyber - Security and Investigations Ingrid Beierly August 18, 2008 Agenda Visa Cyber - Security and Investigations Today s Targets Recent Attack Patterns Hacking Statistics (removed) Top Merchant Vulnerabilities

More information

PCI Requirements Coverage Summary Table

PCI Requirements Coverage Summary Table StillSecure PCI Complete Managed PCI Compliance Solution PCI Requirements Coverage Summary Table January 2013 Table of Contents Introduction... 2 Coverage assumptions for PCI Complete deployments... 2

More information

PCI Compliance. Top 10 Questions & Answers

PCI Compliance. Top 10 Questions & Answers PCI Compliance Top 10 Questions & Answers 1. What is PCI Compliance and PCI DSS? 2. Who needs to follow the PCI Data Security Standard? 3. What happens if I don t comply? 4. What are the basic requirements

More information

FAQ S: TRUSTWAVE TRUSTKEEPER PCI MANAGER

FAQ S: TRUSTWAVE TRUSTKEEPER PCI MANAGER FAQ S: TRUSTWAVE TRUSTKEEPER PCI MANAGER SAQ FAQ S Q: Should I complete the PCI Wizard or should I go straight to the PCI Forms? A: The PCI Wizard has been designed to simplify the self-assessment requirement

More information

Top Five Data Security Trends Impacting Franchise Operators. Payment System Risk September 29, 2009

Top Five Data Security Trends Impacting Franchise Operators. Payment System Risk September 29, 2009 Top Five Data Security Trends Impacting Franchise Operators Payment System Risk September 29, 2009 Top Five Data Security Trends Agenda Data Security Environment Compromise Overview and Attack Methods

More information

FISMA / NIST 800-53 REVISION 3 COMPLIANCE

FISMA / NIST 800-53 REVISION 3 COMPLIANCE Mandated by the Federal Information Security Management Act (FISMA) of 2002, the National Institute of Standards and Technology (NIST) created special publication 800-53 to provide guidelines on security

More information

The Payment Card Industry (PCI) Data Security Standards (DSS) v1.2 Requirements:

The Payment Card Industry (PCI) Data Security Standards (DSS) v1.2 Requirements: Compliance Brief The Payment Card Industry (PCI) Data Security Standards (DSS) v1.2 Requirements: Using Server Isolation and Encryption as a Regulatory Compliance Solution and IT Best Practice Introduction

More information

Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire

Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire Instructions and Guidelines Version 1.1 February 2008 Table of Contents About this Document... 1 PCI Data Security Standard

More information

FINAL DoIT 04.01.2013- v.8 APPLICATION SECURITY PROCEDURE

FINAL DoIT 04.01.2013- v.8 APPLICATION SECURITY PROCEDURE Purpose: This procedure identifies what is required to ensure the development of a secure application. Procedure: The five basic areas covered by this document include: Standards for Privacy and Security

More information

PCI v2.0 Compliance for Wireless LAN

PCI v2.0 Compliance for Wireless LAN PCI v2.0 Compliance for Wireless LAN November 2011 This white paper describes how to build PCI v2.0 compliant wireless LAN using Meraki. Copyright 2011 Meraki, Inc. All rights reserved. Trademarks Meraki

More information

Continuous compliance through good governance

Continuous compliance through good governance PCI DSS Compliance: A step into the payment ecosystem and Nets compliance program Continuous compliance through good governance Who are the PCI SSC? The Payment Card Industry Security Standard Council

More information

PCI Compliance Top 10 Questions and Answers

PCI Compliance Top 10 Questions and Answers Where every interaction matters. PCI Compliance Top 10 Questions and Answers White Paper October 2013 By: Peer 1 Hosting Product Team www.peer1.com Contents What is PCI Compliance and PCI DSS? 3 Who needs

More information

PCI Assessments 3.0 What Will the Future Bring? Matt Halbleib, SecurityMetrics

PCI Assessments 3.0 What Will the Future Bring? Matt Halbleib, SecurityMetrics PCI Assessments 3.0 What Will the Future Bring? Matt Halbleib, SecurityMetrics About Us Matt Halbleib CISSP, QSA, PA-QSA Manager PCI-DSS assessments With SecurityMetrics for 6+ years SecurityMetrics Security

More information

PCI DSS Policies Outline. PCI DSS Policies. All Rights Reserved. ecfirst. 2010. Page 1 of 7 www.ecfirst.com

PCI DSS Policies Outline. PCI DSS Policies. All Rights Reserved. ecfirst. 2010. Page 1 of 7 www.ecfirst.com Policy/Procedure Description PCI DSS Policies Install and Maintain a Firewall Configuration to Protect Cardholder Data Establish Firewall and Router Configuration Standards Build a Firewall Configuration

More information

Protecting the Palace: Cardholder Data Environments, PCI Standards and Wireless Security for Ecommerce Ecosystems

Protecting the Palace: Cardholder Data Environments, PCI Standards and Wireless Security for Ecommerce Ecosystems Page 1 of 5 Protecting the Palace: Cardholder Data Environments, PCI Standards and Wireless Security for Ecommerce Ecosystems In July the Payment Card Industry Security Standards Council (PCI SSC) published

More information

PCI PA - DSS. Point ipos Implementation Guide. Version 1.01. VeriFone Vx820 using the Point ipos Payment Core

PCI PA - DSS. Point ipos Implementation Guide. Version 1.01. VeriFone Vx820 using the Point ipos Payment Core PCI PA - DSS Point ipos Implementation Guide VeriFone Vx820 using the Point ipos Payment Core Version 1.01 POINT TRANSACTION SYSTEMS AB Box 92031, 120 06 Stockholm, Tel. +46 8 566 287 00 www.point.se Page

More information

New PCI Standards Enhance Security of Cardholder Data

New PCI Standards Enhance Security of Cardholder Data December 2013 New PCI Standards Enhance Security of Cardholder Data By Angela K. Hipsher, CISA, QSA, Jeff A. Palgon, CPA, CISSP, QSA, and Craig D. Sullivan, CPA, CISA, QSA Payment cards a favorite target

More information

Effective Threat Management. Building a complete lifecycle to manage enterprise threats.

Effective Threat Management. Building a complete lifecycle to manage enterprise threats. Effective Threat Management Building a complete lifecycle to manage enterprise threats. Threat Management Lifecycle Assimilation of Operational Security Disciplines into an Interdependent System of Proactive

More information

Kenna Platform Security. A technical overview of the comprehensive security measures Kenna uses to protect your data

Kenna Platform Security. A technical overview of the comprehensive security measures Kenna uses to protect your data Kenna Platform Security A technical overview of the comprehensive security measures Kenna uses to protect your data V2.0, JULY 2015 Multiple Layers of Protection Overview Password Salted-Hash Thank you

More information

PCI DSS v3.0 Vulnerability & Penetration Testing

PCI DSS v3.0 Vulnerability & Penetration Testing 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

More information

Beef O Brady's. Security Review. Powered by

Beef O Brady's. Security Review. Powered by Beef O Brady's Security Review Powered by Why install a Business Class Firewall? Allows proper segmentation of Trusted and Untrusted computer networks (PCI Requirement) Restrict inbound and outbound traffic

More information

Minnesota State Colleges and Universities System Procedures Chapter 5 Administration. Guideline 5.23.1.10 Payment Card Industry Technical Requirements

Minnesota State Colleges and Universities System Procedures Chapter 5 Administration. Guideline 5.23.1.10 Payment Card Industry Technical Requirements Minnesota State Colleges and Universities System Procedures Chapter 5 Administration Payment Card Industry Technical s Part 1. Purpose. This guideline emphasizes many of the minimum technical requirements

More information

TOP 10 WAYS TO ADDRESS PCI DSS COMPLIANCE. ebook Series

TOP 10 WAYS TO ADDRESS PCI DSS COMPLIANCE. ebook Series TOP 10 WAYS TO ADDRESS PCI DSS COMPLIANCE ebook Series 2 Headlines have been written, fines have been issued and companies around the world have been challenged to find the resources, time and capital

More information

Administrative Improvements. Administrative Improvements. Scoping Guidance. Clarifications for Segmentation

Administrative Improvements. Administrative Improvements. Scoping Guidance. Clarifications for Segmentation The PCI DSS Lifecycle 1 The PCI DSS follows a three-year lifecycle PCI DSS 3.0 will be released in November 2013 Optional (but recommended) in 2014; Required in 2015 PCI SSC Community Meeting Update: PCI

More information

Application Security. Standard PCI. 26 novembre 2008 1

Application Security. Standard PCI. 26 novembre 2008 1 Application Security Standard PCI 26 novembre 2008 1 Risky Behavior A survey of businesses in the U.S. and Europe reveals activities that may put cardholder data at risk. 81% store payment card numbers

More information

Managing Vulnerabilities For PCI Compliance

Managing Vulnerabilities For PCI Compliance Managing Vulnerabilities For PCI Compliance Christopher S. Harper Vice President of Technical Services, Secure Enterprise Computing, Inc. June 2012 NOTE CONCERNING INTELLECTUAL PROPERTY AND SOLUTIONS OF

More information

Using Automated, Detailed Configuration and Change Reporting to Achieve and Maintain PCI Compliance Part 4

Using Automated, Detailed Configuration and Change Reporting to Achieve and Maintain PCI Compliance Part 4 WHITEPAPER Using Automated, Detailed Configuration and Change Reporting to Achieve and Maintain PCI Compliance Part 4 An in-depth look at Payment Card Industry Data Security Standard Requirements 10, 11,

More information

Where every interaction matters.

Where every interaction matters. Where every interaction matters. Peer 1 Vigilant Web Application Firewall Powered by Alert Logic The Open Web Application Security Project (OWASP) Top Ten Web Security Risks and Countermeasures White Paper

More information

Critical Security Controls

Critical Security Controls Critical Security Controls Session 2: The Critical Controls v1.0 Chris Beal Chief Security Architect MCNC chris.beal@mcnc.org @mcncsecurity on Twitter The Critical Security Controls The Critical Security

More information

Payment Card Industry (PCI) Executive Report. Pukka Software

Payment Card Industry (PCI) Executive Report. Pukka Software Payment Card Industry (PCI) Executive Report For Pukka Software Primary Contact: Brian Ghidinelli none Los Gatos, California United States of America 415.462.5603 Payment Card Industry (PCI) Executive

More information

PCI PA - DSS. Point BKX Implementation Guide. Version 2.01. Atos Xenta, Atos Xenteo and Atos Yomani using the Point BKX Payment Core

PCI PA - DSS. Point BKX Implementation Guide. Version 2.01. Atos Xenta, Atos Xenteo and Atos Yomani using the Point BKX Payment Core PCI PA - DSS Point BKX Implementation Guide Atos Xenta, Atos Xenteo and Atos Yomani using the Point BKX Payment Core Version 2.01 POINT TRANSACTION SYSTEMS AB Box 92031, 120 06 Stockholm, Tel. +46 8 566

More information

CS 356 Lecture 25 and 26 Operating System Security. Spring 2013

CS 356 Lecture 25 and 26 Operating System Security. Spring 2013 CS 356 Lecture 25 and 26 Operating System Security Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access Control

More information

Sample Statement of Work

Sample Statement of Work Sample Statement of Work Customer name Brad Miller brad@solidborder.com Fishnet Security Sample Statement of Work: Customer Name Scope of Work Engagement Objectives Customer, TX ( Customer or Client )

More information

Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire C-VT and Attestation of Compliance

Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire C-VT and Attestation of Compliance Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire C-VT and Attestation of Compliance Merchants with Web-Based Virtual Payment Terminals No Electronic Cardholder Data Storage

More information

Windows Remote Access

Windows Remote Access Windows Remote Access A newsletter for IT Professionals Education Sector Updates Issue 1 I. Background of Remote Desktop for Windows Remote Desktop Protocol (RDP) is a proprietary protocol developed by

More information

TRIPWIRE PURECLOUD. TRIPWIRE PureCloud USER GUIDE

TRIPWIRE PURECLOUD. TRIPWIRE PureCloud USER GUIDE TRIPWIRE PURECLOUD TRIPWIRE PureCloud USER GUIDE 2001-2015 Tripwire, Inc. All rights reserved. Tripwire and ncircle are registered trademarks of Tripwire, Inc. Other brand or product names may be trademarks

More information

White Paper. Guide to PCI Application Security Compliance for Merchants and Service Providers

White Paper. Guide to PCI Application Security Compliance for Merchants and Service Providers White Paper Guide to PCI Application Security Compliance for Merchants and Service Providers Contents Overview... 3 I. The PCI DSS Requirements... 3 II. Compliance and Validation Requirements... 4 III.

More information

Tenable Addendum to VMware Product Applicability Guide. for. Payment Card Industry Data Security Standard (PCI DSS) version 3.0

Tenable Addendum to VMware Product Applicability Guide. for. Payment Card Industry Data Security Standard (PCI DSS) version 3.0 Tenable Product Applicability Guide For Payment Card Industry (PCI) Partner Addendum VMware Compliance Reference Architecture Framework to VMware Product Applicability Guide for Payment Card Industry Data

More information

North Carolina Office of the State Controller Technology Meeting

North Carolina Office of the State Controller Technology Meeting PCI DSS Security Awareness Training North Carolina Office of the State Controller Technology Meeting April 30, 2014 agio.com A Note on Our New Name Secure Enterprise Computing was acquired as the Security

More information