I am building a credit card tokenization/payment-processing service. As these services need sit in pci-compliant environment, I find it hard to export the application metrics & logs. Anyone knows how is this usually handled?

For detail: I am writing the service in Java and using StatsD to record the application metrics. I want to export these metrics out of the PCI environment to graphite, as such I could monitor and set up alerts for the services.

Any ideas are welcomed!


You'll just have to follow your PCI procedures. You'll have to create a change that allows the statsd server to exist. A manager will have to review/ok the change.

It will cause a few dependent changes and activities:

  • add a new statsd server to the DMZ (network change, system change, system hardening, configuration standards)
  • add the statsd service and graphite service to the allowed services on the network
  • record the new server in your equipment overview
  • update the network diagrams
  • Allow selected servers to access the statsd service. Be sure to practice least privilege principle. (firewall change)
  • Allow the statsd service to (only) access the remote graphite service (firewall change)
  • If applicable, update procedures to add "allowing access to the statsd service" as a default configuration for new machines. Be sure to practice least privilege principle.
  • Consider wether this change constitutes a significant enough change to need a penetration test
  • Kick off an internal vulnerability scan which includes the statsd server
  • Alter the application to include statsd support (application change, code review)
  • Don't forget the software review process for the custom Java service. – Ryder May 22 '16 at 1:30
  • @NSSec got it! So essentially, I need deploy a statsD daemon inside DMZ and then make firewall change to allow the graphite service outside DMZ to be able to communicate with the statsD daemon inside the firewall? – Alfred May 22 '16 at 18:17
  • That's basically the technical part of things. You should also have your statsd implementation in your java application reviewed by a peer to make sure you're not sending PANs instead of timestamps :P. – NSSec May 23 '16 at 18:31

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.