Archive for January 2nd, 2010

02
Jan
10

How Email Ends Up In-Scope And What To Do About It

Let us clarify this issue.  I am not talking about the occasional email that contains cardholder data.  Try as your organization might, a small percentage of customers are going to email their cardholder data to you no matter how often and how strictly you remind them not to do such things.  In the immortal words of the comedian Ron White, “You can’t fix stupid.”  The way to address these customer indiscretions is to immediately print them out and delete them from the email system so that you minimize the chance that they end up on the email system’s backups.  Once done with the print out, shred or redact it.

These occasional customer “brain farts” does not, in my humble opinion, place an organization’s email system in-scope.  If your QSA says that such occasional messages do place it in-scope, I would seriously push back on this issue.  The risk involved along with the randomness of occurrence does not warrant the time and resources to totally eradicate such problems.  However, your management needs to understand the risk this presents and agree to accept that risk.

With that said, there is nothing worse than telling a client that their email system is in-scope for PCI compliance.  Most of the time, they look like a deer caught in a car’s headlights.  They just stare at you like you just slapped them across their face or dumped a bucket of ice cold water on them.  So, just how does this happen?

Interestingly, the primary cause of an email system being in-scope is due to the fact that it is not segmented away from the ecommerce environment that processes, stores or transmits cardholder data.  Some of this is not due to improper implementation.  In a number of instances, this situation occurs because the ecommerce environment requires integrated access to the email system and putting a firewall between the two is not an option.

The second reason email ends up in-scope is that in almost every email system implementation, the email system has been extended to handle other forms of communication.  As a result, the email system becomes the communications hub of an organization.  The most common extension is the integration of a facsimile system.  These integrated facsimile solutions were a God send when they were introduced as they improved efficiency and accuracy in handling facsimile communications.  They allow facsimiles to be received and automatically delivered directly to either an individual’s or a team’s Inbox based on pre-defined rules.  However as any IT person will tell you, these facsimile solutions have ended up being a compliance nightmare when security and privacy requirements like PCI were introduced.

Another application that gets integrated with email is instant messaging (IM).  IM inside an organization is typically just as secure as internal email.  However, users typically want the ability to not only IM their fellow employees, they also want to IM customers and business partners.  It is the use of IM outside of the organization that creates the problem because the security measures available inside are not typically available through Yahoo, AOL and Microsoft.  Not that IM applications cannot be secured; it is just that they usually are not secured outside of an organization.

With all of these potential risks with email, what should an organization do to ensure PCI compliance?

  • Do whatever you can to get your email system out of scope.  The last thing you need is to have the email system in-scope.
  • Physically or logically segregate your organization’s email system from your cardholder data environment.  If it cannot be segregated, then implement separate email solutions for your cardholder data environment and the rest of your organization.
  • If you are using your email system for communicating cardholder data, stop that practice immediately and begin remediating your current email database and the backups of that database.
  • If you need to use facsimile for transmission of cardholder data, have those facsimiles delivered to secure devices, not through your integrated facsimile/email system.  Most printer and multi-function device manufacturers produce devices that can provide a secure facsimile delivery capability including encrypted storage of facsimile transmissions.  If you really need the automation capabilities, then implement a separate instance of email and facsimile solutions for this purpose.
  • Make sure that everyone in your organization understands the risks that email, instant messaging, facsimile and other forms of communication present to the cardholder data environment.  Train all personnel to never transmit cardholder data via any electronic communications.
  • If you are printing out electronic communications that contain cardholder data, make sure that you also have proper destruction or redaction procedures documented and implemented.  Periodically test those destruction and redaction procedures to ensure that they are operating as expected.
  • As best you can, restrict IM capability to only internal use.  If IM connectivity is required outside of your organization, implement it securely over an encrypted VPN link or other secure communications channels.
Advertisement



Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

January 2010
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031