Reza,
Actually just encrypting a call recording which contains credit card
information, if the recording contains the CVC2 data is not enough
according the to the PCI Security Standards Council. You'll need to
fully read the PCI DSS 2.0 documents to make sure in your situation that
your in compliance. If you read the fine detail it is not allowed to
have both the credit card and CVC2 data stored together in any fashion,
including encryption.
That is why we developed and patented a process that scans the audio and
removes parts of the credit card digits from the recording. The only
ways to fully comply is to remove or not record enough of the credit
card and CVC2 data, where it could useful. A couple of methods is to
give the agents the ability to stop the recording during the credit card
process, or one neat trick is to get the client to not say the CVC2
digits, but to key them in with their phone and then intercept them ( if
inband ) and capture the CVC2 via an API ( can also do full credit card
but also but can be difficult for some callers). I have also seen
operations which have the agent transfer the person to a credit card
process, which then out of the recording stream, then return to the
agent upon completion.
Another technique that we use is to generate a unique 32 character
encryption key for every recording, and fragment the audio into multiple
files, stored across multiple servers. So without the private key, the
unique key, the location of the fragments and all fragments you can not
reconstruct the audio file.
Mike
On 09/17/2011 8:29 PM, Reza - Voipernetics wrote:
Thank you Duane and thank you Brian for the suggestions.
To advise: The requirement is **beyond** transfer of recordings.
The requirement is to *protect* sensitive data as originally outlined
in my first post, on the event the physical machine is compromised.
We have given much thought to this and not only are we enabling
hardware based encryption which some bios and hard-drives offer in
case the HD is stolen, but also we have a data self destruct option
after 3 failed login attempts in a 60 second period.
The ONLY part that is pending is to protect the sensitive data from
someone who may acquire physical access to the terminal.
As mentioned, the login data is critically important. Probably I
wasn't explicitly clear - though it should have been quite obvious
from the subject " Protecting & Encrypting PHP Codes in an Asterisk
Install. ". ** We also want to protect our PHP code ** as the
algorithm and logic of encrypting recorded calls are in the PHP files.
To be a little more explicit on what we are recording for the client:
Credit Card and Personal data -- which by law is required to be
protected.
Yes, I am being **extremely** paranoid, however with regards to
security, one cannot be paranoid enough, specially when it comes to CC
and personal data.
/*
Kind regards,
Reza.*/
--
*
*FOUNDER & SR. TELECOM ANALYST*
/VOIPERNETICS COMMUNICATIONS <http://www.voipernetics.com/>/*
NATION WIDE DIDS, SIP TRUNKS & VOIP 911.
PARTIAL / FULL VIRTUAL PRI - NO CONTRACTS!
HOSTED PBX & TERMINATION SERVICES.
TEL: 647-476-2067
--
Mike Ashton
CTO
Quality Track International
Work: +1 647 724 3500 x251
Cell: +1 416 527 4995
QTI CONFIDENTIAL AND PROPRIETARY INFORMATION
The contents of this material are confidential and proprietary to Quality Track
International, Inc.
and may not be reproduced, disclosed, distributed or used without the express
permission of an authorized representative of QTI.
Use for any purpose or in any manner other than that expressly authorized is
prohibited.
If you have received this communication in error, please immediately delete it
and all copies, and promptly notify the sender.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
