A client in the retail industry has a network with point-of-sale (POS) terminals that connect to a POS Server. Additionally, most of the Windows workstations in non-sales areas also connect to the same server. This is because the POS software is only one module of a larger legacy application that runs everything for the company (inventory, purchasing, accounting, etc.).
According to our PCI auditor (QSA), any system that connects directly to the card holder data environment is considered in scope (not just the systems that store, process or transmits CC data).
The problem is how to limit the scope so that the hundreds of Windows stations that do not have anything to do with CC data are not in-scope for PCI DSS.
This diagram shows how the POS and Windows stations currently connect to the server:
This diagram shows how they connect with a Bastion host implemented:
The Windows WS uses Putty or similar to SSH to the Bastion host using password based authentication. The login script or custom shell on the Bastion host auto-SSHes to the POS Server using key-based authentication and the user gets into the business application transparently (the user never gets a shell or ability to break out to shell).
But what does that really accomplish in terms of improved security?
Without a Bastion Host: If the Windows WS is compromised and they get the login password to the POS server, they can SSH to it, but they still only get into the business application with no shell access.
With a Bastion Host: If the Windows WS is compromised and they get the login password to the Bastion server, they can SSH to it, but they still only get into the business application with no shell access.
I don't see that the Bastion host provides a whole lot of extra security in this scenario.
Feedback and/or suggestions on this would be appreciated.