Loading ...
Sorry, an error occurred while loading the content.
 

PCI Compliance

Expand Messages
  • Jonathan Tripathy
    Hi Folks, Any ideas on how to set up an SMTP Proxy Server to attain PCI Compliance? I literally need postfix to just pass through mail to our ISP s smtp
    Message 1 of 4 , Mar 18, 2010
      PCI Compliance

      Hi Folks,

      Any ideas on how to set up an "SMTP Proxy Server" to attain PCI Compliance? I literally need postfix to just pass through mail to our ISP's smtp server. We would then set outlook to use this local smtp proxy server.

      I'm not entirly sure if a "relay" server is good here, as how would that handle bounced mail??

      Thanks,

      Jonathan

    • Barney Desmond
      ... I work for a hosting company, we find it s usually an iterative process. This particular question hasn t come up yet (for an SMTP server), but it d go
      Message 2 of 4 , Mar 18, 2010
        On 18 March 2010 21:57, Jonathan Tripathy <jonnyt@...> wrote:
        > Any ideas on how to set up an "SMTP Proxy Server" to attain PCI Compliance?
        > I literally need postfix to just pass through mail to our ISP's smtp server.
        > We would then set outlook to use this local smtp proxy server.

        I work for a hosting company, we find it's usually an iterative
        process. This particular question hasn't come up yet (for an SMTP
        server), but it'd go something like this:

        1. Customer needs certification for a contract, so they hire a company
        to perform a PCI audit scan
        2. The scan finds "problems", so they come to us with the report,
        which says how to fix the problems
        3. We read the report, and find things like "server exposes its
        hostname in the greeting banner", or "server appears to allow the use
        of the VRFY command".
        4. We sigh, then go through the motions to "fix" the "problems".
        Sometimes the problem descriptions are hopelessly vague, like "this
        system /may/ be vulnerable to a known buffer overflow", and the system
        is fully patched and up to date. Can't do much about these, so we tell
        our customer to take it up with the auditor.
        5. Rinse and repeat until all perceived problems are fixed, and/or the
        customer stops hassling. :)

        So, my apologies that this doesn't really answer your question. If you
        need compliance certification then you'll need an audit anyway, at
        which point you find out what the requirements are.

        It's not trivial to simply look up the requirements, because...
        PCI-DSS doesn't actually cover specific implementation details. It's
        sufficiently vague (probably by design) so that'll it'll stay relevant
        as time goes on, and so that current best practices are followed. Have
        a look at the PCI spec, it's only half a meg in PDF:
        https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

        Page 4 is a summary of what you really need to know. Page 6 mentions
        segmentation to reduce the scope of what needs to comply - this is
        your best bet (if feasible) to sidestep compliance for your mail
        server. If you enjoy some light humour, we've elaborated on the
        aforementioned process a little:
        http://www.anchor.com.au/blog/2008/12/saas-security-scanning-as-a-service/

        > I'm not entirly sure if a "relay" server is good here, as how would that
        > handle bounced mail??

        Indeed, you want to avoid more relays if you can, both for
        administration and compliance reasons. Bounced mail isn't so bad, so
        long as there's a return path to the sender's mailbox. A naive example
        of how this might work:

        Sending: outlook -> workstation -> PCI-compliant relay -> ISP's SMTP
        server -> recipient
        *it bounces because the recipient's mailbox is full*
        Recipient -> MX lookup -> Your incoming SMTP server (maybe this is at
        your ISP) -> The sender's mailbox -> Picked up by outlook
      • J. Roeleveld
        ... ... Does this mean that the service-desk of companies are not compliant either? 1) Check in phonebook for number of VISA credit card service desk
        Message 3 of 4 , Mar 18, 2010
          On Thursday 18 March 2010 13:26:43 Barney Desmond wrote:
          > On 18 March 2010 21:57, Jonathan Tripathy <jonnyt@...> wrote:

          <snipped>

          > 3. We read the report, and find things like "server exposes its
          > hostname in the greeting banner", or "server appears to allow the use
          > of the VRFY command".

          Does this mean that the service-desk of companies are not compliant either?

          1) Check in phonebook for number of VISA credit card service desk
          2) Call listed number

          They then will answer with:
          "Hello, thank you for calling VISA credit card service desk, <insert name>
          speaking, how may I help you?"

          Me: Hi, can you please direct me to <insert other name here>

          How is this different from:

          **
          $ telnet mail.isp.com 25
          Trying 10.1.4.50...
          Connected to mail.isp.com.
          Escape character is '^]'.
          220 mailer.isp.com ESMTP Postfix
          MAIL TO <user>
          MAIL TO OK
          **
          I guessed the last 2 lines, but I think it shows what I mean? :)

          --
          Joost Roeleveld
        • Barney Desmond
          ... Hehe, in a way. Social engineering is thankfully(?) outside the scope of PCI-DSS compliance. ... Exactly! Disabling VRFY gains nothing because you can test
          Message 4 of 4 , Mar 18, 2010
            On 18 March 2010 23:59, J. Roeleveld <joost@...> wrote:
            > Does this mean that the service-desk of companies are not compliant either?

            Hehe, in a way. Social engineering is thankfully(?) outside the scope
            of PCI-DSS compliance.

            > 1) Check in phonebook for number of VISA credit card service desk
            > 2) Call listed number
            >
            > They then will answer with:
            > "Hello, thank you for calling VISA credit card service desk, <insert name>
            > speaking, how may I help you?"
            >
            > Me: Hi, can you please direct me to <insert other name here>
            >
            > How is this different from:
            >
            > **
            > $ telnet mail.isp.com 25
            > Trying 10.1.4.50...
            > Connected to mail.isp.com.
            > Escape character is '^]'.
            > 220 mailer.isp.com ESMTP Postfix
            > MAIL TO <user>
            > MAIL TO OK
            > **
            > I guessed the last 2 lines, but I think it shows what I mean? :)

            Exactly! Disabling VRFY gains nothing because you can test with RCPT
            TO instead. There will always be some debate about the value of this
            measure ("why not disable it if we can?" vs. "why *bother* if we don't
            have to?) - just ignore it and do whatever has to be done, there are
            better things to waste energy on.
          Your message has been successfully submitted and would be delivered to recipients shortly.