Addressing the growing risk from insecure third party remote access

Addressing the growing risk from insecure third party remote access
By Judith Clark, QSA Consultant

In recent years, numerous security reports have identified an increasing trend for intrusions affecting Point of Sale (POS) environments to have involved insecure remote access from service providers and their networks.  As the ENISA points out, criminals are turning to network-based attacks against retailers’ POS infrastructure because attacks requiring physical access to POS systems (such as skimming) are not scalable.  Criminals look for poorly secured and easily exploited remote entry points into merchants’ POS systems.


As a result, industry experts recommend that all businesses ask the right questions of their third party management vendors about their security practices and cite strengthening authentication and limiting remote access into POS environments is essential.  The card brands too have recognised the POS remote access threat.  Alerts and guidance have been published to warn merchants of the risk associated with insecure remote access methods that may be enabled and used by their third party support providers, POS vendors, integrators or resellers.


On the back of this growing threat, the Payment Card Industry Security Standards Council (PCI SSC) has published new guidance on ‘Connected-to Service Providers’ to help both service providers and their customers (including merchants, other service providers and other entities that rely on and allow remote access by those third-parties) understand and securely manage their remote network connections.  The term ‘connected-to service providers’ refers to service providers with the ability to remotely access a customer system which is on the same network as, or has access to, the customer’s Cardholder Data Environment (CDE).


Types of service providers with remote access to customer systems can include those managing retailers’ logical and physical devices such as firewalls, routers and switches, those supporting and maintaining POS systems and applications running on them, as well as hosting or storage providers and IT support providers.  ‘Connected to service providers’ may include those with direct remote access to CDE systems and those using remote access to manage or support their customer’s PCI DSS controls (such as access control systems).  It can also include those service providers whose need for remote access to their customer is unrelated to payments processing or card data but whose access could impact the security of the customer CDE if it is improperly configured and compromised.  Whatever the reason, if not properly set-up and managed any third-party service providers’ remote access could be a route into, and can introduce risk to, the customer CDE and to payment card data.


Some of the risks here are:

  • Remote access services are ‘always on’ – this makes them easily discoverable to port scanning and acts as a starting point of exploit
  • Single factor authentication – which leaves remote access open to password guessing and brute force attacks
  • Unchanged vendor default passwords and common passwords
  • Outdated/unpatched applications and systems – leaving them susceptible to attack and easily exploitable due to their ‘known’ vulnerabilities
  • Incorrectly configured POS systems which have a public IP address making them directly accessible from the Internet.


Recommended measures to ensure that remote access granted to connected-to service providers, is not an easily exploitable route of access into a customer’s network or CDE include:

  • Exercising due diligence before engaging a service provider as per Requirement 12.8.3
    • Fully understanding the business need for remote access
    • Confirming that the service provider can support the customer’s security policies and processes
    • Confirming that the service provider, is or can be, PCI DSS compliant
    • Limiting service provider access to named individuals and limited access times,
    • Entering into written agreements with regards to the security of the CDE to ensure a consistent level of understanding between the customer and their service providers, in relation to their security responsibilities and fulfilment of applicable PCI DSS requirements
    • Questioning whether the service provider itself outsources functions to other service providers who will access the customer’s CDE.


  • For existing ‘connected-to service providers’
    • Ensuring that policies and procedures to manage the relationship between the customer and the service provider, including written agreements as to PCI DSS responsibilities
    • Implementing strong access control and identity access management measures as per Requirements 2.3, 7 and 8, ensuring that access is limited to only those necessary, for a limited time and access to other components is prevented
    • Implementing multi factor authentication for all remote access and ensure that:
      • Repeated attempts to access are locked out after six attempts
      • Set the lockout duration to a minimum of 30 minutes or until an administrator intervenes to re-enable the account
      • Ensure an idle timeout of no more than 15 minutes is set requiring re-authentication thereafter
    • Ensuring that all remote access is logged and that the logs are inspected daily
    • Consider only allowing access by specific request rather than ‘always-on’ remote access
    • Requesting the service provider enters into a written agreement, that they will ensure that all systems used to access the customer’s CDE will be kept up to date with software patches and anti virus, that systems will be securely configured, with appropriate access controls including multifactor authentication and that audit logging and monitoring controls are in place.
    • Requesting remediation activity following findings from penetration tests and vulnerability scanning and evidence of their remediation and subsequent re-testing.


All service providers that can access or connect to the customer’s CDE or have the ability to impact the security of the CDE are in scope and should comply with PCI DSS. Service providers can formally validate themselves against PCI DSS or can be included within the scope of their customer’s compliance assessment.  Customer’s must manage and monitor their service providers’ PCI DSS compliance.


For service providers who undergo their own annual self assessment of PCI DSS compliance, request a copy of their Attestation of Compliance (AoC) or relevant sections of the service provider’s redacted Report on Compliance (RoC) and ensure that the services detailed are those which are provided to the merchant.


In addition to the PCI DSS requirements that apply to the Connected-to Service Providers’ remote access connections, additional PCI DSS requirements may applicable depending on the type of service being provided.  Service providers and their customers should work together to identify and determine responsibility for fulfilment of those additional requirements. See ‘Use of Third-Party Service Providers / Outsourcing’ section of PCI DSS v3.2.


The PCI SSC has published additional resources to assist merchants and service providers with evidence and compliance requirements and in particular a number of FAQs on service provider relationships which can be found here:


Further, a Sysnet article detailing the requirement for service provider compliance. This article covers the requirements of PCI DSS as well as the service provider registration and reporting requirements with the Card Schemes (Visa Europe, Visa International, Mastercard and American Express).


If your organisation requires to reach out to your customers, then we can help. Our highly competitive customer engagement services are fully-scalable, on-demand and utilise the latest technology. Plus, our services are white-labelled so that your customers perceive that they are dealing directly with your organisation. For more information on how Sysnet’s Envoy services can assist your organisation, fill out the form below and we’ll be in touch.