0

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!

Improve this question

1 Answer 1

Reset to default
3

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)
Improve this answer
3
  • Don't forget the software review process for the custom Java service.
    – Ryder
    Commented May 22, 2016 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
    Commented May 22, 2016 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
    Commented May 23, 2016 at 18:31

You must log in to answer this question.

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