I'm looking for a "tamper proof" way, if there is such a thing, to monitor what a developer/engineer does on a given system.

To expand a bit more about this, we have several systems that run a Ruby on Rails technology stack with Ubuntu Docker containers on K8S, and for our PCI compliance, we require a monitoring solution that allows us to basically track what a developer/engineer does on a system from the point where an SSH session is established until the session is terminated.

Ideally, we'd like to see:

  • Loggin in
  • Any commands used in the SSH session
  • Any commands/code executed with irb or rails console
  • These logs send to Cloudwatch
  • Inability to disable this monitoring

I was originally thinking about a simple shell overwrite for the above commands to simply track every command going on, and rely on the shell history to see what has been happening, but that obviously doesn't pass the "tamper proof" requirement, as anyone with SSH access would be able to bypass that.

I'm thinking more about some OS level monitoring to either watch the processes directly we know that will be used for working with the PCI sensitive information, or just monitor all tty trafic/interaction.

What I'm looking for is best-practises, reading material or recommendations on what's the accepted/recommended way for setting up a system like this.

  • Which specific PCI DSS requirement do you want to meet when you say ... "for our PCI compliance, we require a monitoring solution that allows us to basically track what a developer/engineer does on a system" Commented Jul 11, 2020 at 7:51
  • Secure SLC to ensure that only people have access to the processes that need it, are monitored in their behavior and that our software and infrastructure is up to date. Commented Jul 12, 2020 at 8:11
  • I'm sorry, I probably didn't ask that very well. There isn't a specific requirement in PCI DSS for "tamper proof monitoring", which is why I was wondering which requirement you were trying to meet. Was it something in Requirement 10 (Logging) or Requirement 6 (eg dev access to live). Commented Jul 13, 2020 at 16:22
  • It would probably fall under the dev access to live. Since we're dealing with Payment data, we need to monitor what a dev does when he's allowed to SSH into one of the machines, including the running of any Ruby code, hence why I have the requirements listed as such. Hope it makes more sense? Commented Jul 14, 2020 at 7:53
  • OK. So I'll assume you want to use this 'tamper-proof monitoring' as a compensating control for requirement 6.4.2 "Separation of duties between development/test and production environments" and answer accordingly. Commented Jul 15, 2020 at 8:20

1 Answer 1


Tamper proof monitoring may be used as a compensating control to meet requirement 6.4.2 in respect of separation of duties between Dev/Test/Prod environments. Remember that DSS was written pre-DevOps :-)

Typically the way most entities do this type of monitoring is via a jump host, so the dev connects to the jump host and from the jump host then connects to the Prod environment. The jump host records the screen and all keystrokes. The dev's rights on the jump host can be very restricted. I don't know of any FOSS systems that do this but look at commercial Privileged Access Management (PAM) systems.

NB: Whether a compensating control is sufficient for your environment is a discussion between you, your QSA and sometimes your acquiring bank.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .