1 Reply Latest reply: Jun 16, 2017 3:29 PM by kiles@tdstickets.com RSS

Are bastion hosts and sudo passwords required for PCI DSS 3.2 Compliance

kiles@tdstickets.com Novice

During a recent PCI DSS 3.2 audit the QSA made a couple of observations and also required remediation for the following ...

  1. Access via SSH to the CDE must go through a bastion host so that the devices used by administrators to access the environment can remain out of scope.
  2. When using SUDO to elevate privileges a password must be typed manually. The use of NOPASSWD in the sudoers file should not be used for that admin group (wheel in our case).


I'm having a difficult time justifying the above in relationship to actually being more secure. While I may comply to satisfy the QSA I do so with trepidation.


A little background ...

  • All SSH access to the CDE is done through OpenVPN (on the firewall) using public keys and passphrases. Two-factor authentication is also required (Google Auth) to establish the VPN connection.
  • All user accounts in the CDE (only three) do NOT have passwords. The SSH daemon is configured to NOT allow password authentication.
  • SUDO is configured to allow the wheel group (CentOS 7) the ability to sudo without a password (because a password does not exist for users in the wheel group).
  • All servers in the CDE are hardened exactly the same using Ansible for Orchestration.
  • Splunk collects all logs from all servers.


Bastion Host: In my mind, a bastion host is old technology and does not offer any more security than going to each server directly. The bastion host then becomes a central point of attack. SSH Agents on the clients can easily be configured to proxy through the bastion host transparently so it would offer no additional security. Implementing a bastion host for the sole purpose of keeping our laptops out of scope seems trivial. In reality, the firewall that provides the OpenVPN server and that enforces two-factor authentication is hardened better than what I could do with a bastion host. The firewall insures that only properly authenticated VPN users can connect to SSH. The firewall also enforces session timeouts and also logs all access to the central log collector (along with each server being accessed).


SUDO: I know there are ways to configure sudo to escalate privileges using SSH keys instead of passwords but that seems like a lot of work to just accomplish the same thing as the NOPASSWD option. Typing a password to access sudo seems like a step backward and would allow a snooper or keylogger access (knowing that they would also need my private key and passphrase to even gain access).


It seems to me that adequate controls are in place to insure only authorized administrators have access and that what they do is logged centrally. The Firewall itself is like a bastion host and prevents anything malicious from leaking through to a CDE server (since SSH is the only protocol allowed).


Does anyone have any thoughts on this.

  • Re: Are bastion hosts and sudo passwords required for PCI DSS 3.2 Compliance
    kiles@tdstickets.com Novice

    Since I have no responses I will clarify one point from my own research - bastion host or jumpbox. The PCI DSS council spells this out pretty clearly at https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf. Following these guidelines does NOT mean that the administrator's devices are out of scope. It just means that the rest of the Corporate network remains out of scope. Now - technically the administrator's devices are not not connecting directly to servers in the CDE since an OpenVPN connection (plus 2-step token) is required to gain access to a server in the CDE via ssh. That VPN network is a completely isolated network.


    A shorter version of the PCI Council standard is paraphrased at https://www.coalfire.com/The-Coalfire-Blog/December-2016/PCI-Clarifies-Assessment-Scoping

    The relevant portion of that blog states ...


    Administrative systems (workstations, laptops, servers, mobile devices) are always in scope for PCI DSS regardless of the path or existence of bastion hosts used to access the CDE. In scope administrative systems can be considered as not extending scope to any other system residing on the same network as the administrative systems using the following guidelines:

    • Connections to the bastion host from out-of-scope networks and systems are restricted to designated personnel.
    • Administrative systems are unable to access the CDE directly, and must use the bastion host.
    • All PCI DSS requirements apply to the administrative systems.
    • The administrative systems must not store, process, and/or transmit CHD.
    • Access to the bastion host from the administrative systems are via different user accounts than those used to administer the CDE.
    • Access to the bastion host from administrative systems requires multi-factor authentication for individuals, and at least one of the multi-factor methods is independent of the administrative system (e.g. host-based certificates are not to be used for access to the bastion host).


    Now - one could argue that I am not connecting directly to the CDE via SSH since all of my packets go through a VPN on a totally separate network and that the credentials I use to establish that VPN connection are not the same as the ones I use to open a SSH connection to a server in the CDE. The connection to the VPN is logged centrally and alerted, the connection to the CDE server is logged centrally and alerted, and even the escalation of privileges via sudo is logged centrally and alerted. The problem is that the UTM device is not really a SSH jumpbox. Instead, it is a Unified Threat Management box.


    I would have about as much success convincing the QSA that the UTM is a bastion host as I did convincing him that my password is complex and changes every 30 seconds because of the 2-factor token. I'm still stymied by the SUDO issue though. Once I put passwords on those PCI servers then there are all kinds of ramifications with setting up PAM to insure password quality and expiration which is not required right now since there are no passwords (root being the exception but then password quality settings don't affect root on CentOS 7 and root can't gain access via SSH anyway).