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" Jul 11 '20 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. Jul 12 '20 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). Jul 13 '20 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? Jul 14 '20 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. Jul 15 '20 at 8:20

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.