Voice data leakage detection and prevention systems

An exemplary system for detecting and preventing voice data leakage may comprise one or more servers running a packet payload converter module, a transcript generator module, and a detection logic module. The packet payload converter module may receive VoIP packets, convert them to a digital audio file, and write the digital audio file to a media database. The transcript generator module may read the digital audio file from the media database, convert it to a text file, and write the text file to a transcript database. The detection logic module may read the text file from the transcript database, parse it into a plurality of keywords, determine whether the plurality of keywords contain one or more target keyword, and, if so, transmit a report to an events database.

CROSS REFERENCE TO RELATED PATENT APPLICATIONS

This patent application is related to U.S. patent application Ser. No. 13/331,710 entitled: “VOICE DATA LEAKAGE DETECTION AND PREVENTION” concurrently filed herewith and also assigned to Go Daddy Operating Company, LLC.

FIELD OF THE INVENTION

The present inventions generally relate to network security and, more particularly, systems and methods for detecting and preventing voice data leakage.

SUMMARY OF THE INVENTION

An example embodiment of a system for detecting and preventing voice data leakage may comprise one or more servers communicatively coupled to a network running a packet payload converter module, a transcript generator module, and a detection logic module. The packet payload converter module may be configured to receive a plurality of VoIP packets, convert the VoIP packets to a digital audio file, and write the digital audio file to a media database running on the one or more servers. The transcript generator module may be configured to read the digital audio file from the media database, convert the digital audio file to a text file, and write the text file to a transcript database running on the one or more servers. The detection logic module may be configured to read the text file from the transcript database, parse the text file into a plurality of keywords, determine whether the plurality of keywords contain one or more target keyword, and, if so, transmit a report to an events database running on the one or more server.

An example embodiment of a method of detecting and preventing voice data leakage may comprise the steps of receiving a plurality of VoIP packets, converting the VoIP packets to a digital audio file, converting the digital audio file to a text file, parsing the text file into a plurality of keywords, determining whether the plurality of keywords contains one or more target keywords, and, if so, generating a censored plurality of VoIP packets representing the conversation that excludes the one or more target keywords and transmitting the censored VoIP packets to a recipient.

The above features and advantages of the present inventions will be better understood from the following detailed description taken in conjunction with the accompanying drawings.

DETAILED DESCRIPTION

The present inventions will now be discussed in detail with regard to the attached drawing figures, which were briefly described above. In the following description, numerous specific details are set forth illustrating the Applicant's best mode for practicing the inventions and enabling one of ordinary skill in the art to make and use the inventions. It will be obvious, however, to one skilled in the art that the present inventions may be practiced without many of these specific details. In other instances, well-known machines, structures, and method steps have not been described in particular detail in order to avoid unnecessarily obscuring the present inventions. Unless otherwise indicated, like parts and method steps are referred to with like reference numerals.

Data Leak Prevention (DLP) is the practice identifying and tracking sensitive data in a network, ensuring that only authorized network users have access to such sensitive data, and minimizing the probability that such sensitive data is leaked beyond such authorized network users. As a non-limiting example, sensitive data may comprise any information that an organization should maintain securely, perhaps by obligation of law or policy. Examples of sensitive data may include personally-identifiable information, financial information, or medical records.

Presently-existing DLP systems and methods focus on identifying, monitoring, and protecting data as it is electronically stored (e.g., storage or “data at rest” DLP), transmitted (e.g., network or “data in motion” DLP), or processed (e.g., endpoint or “data in use” DLP). Such methodologies identify data leaks through content inspection and/or contextual analysis.

Applicant has determined, however, that presently-existing DLP systems and methods may be bypassed simply by transmitting sensitive information via telephone, thereby bypassing the electronic storage, transmission, and processing systems monitored by DLP methods. Presently-existing systems and methods therefore do not provide optimal means for detecting and preventing voice data leakage.

FIG. 1illustrates an embodiment of a system for detecting and preventing voice data leakage that may comprise one or more servers100communicatively coupled to a network101running a packet payload converter module110, a transcript generator module140, and a detection logic module170.

Servers100(and/or any other server described herein) may comprise any computer or program that provides services to other computers, programs, or users either in the same computer or over a computer network101. As non-limiting examples, the one of more server100could be application, communication, mail, database, proxy, fax, file, media, web, peer-to-peer, standalone, software, or hardware servers (i.e., server computers) and may use any server format known in the art or developed in the future (possibly a shared hosting server, a virtual dedicated hosting server, a dedicated hosting server, or any combination thereof).

Servers100may comprise a computer-readable storage media storing instructions that, when executed by a microprocessor, cause the server100to perform the steps for which it is configured. The computer-readable media may comprise any data storage medium capable of storing instructions for execution by a computing device. It may comprise, as non-limiting examples, magnetic, optical, semiconductor, paper, or any other data storage media, a database or other network storage device, hard disk drives, portable disks, CD-ROM, DVD, RAM, ROM, flash memory, and/or holographic data storage. The instructions may, as non-limiting examples, comprise software and/or scripts stored in the computer-readable media that may be stored locally in the server or, alternatively, in a highly-distributed format in a plurality of computer-readable media accessible via the network101, perhaps via a grid or cloud-computing environment.

The example embodiments illustrated herein place no limitation on network101configuration or connectivity. The network101may comprise any collection of links and nodes (e.g., multiple computers and/or other devices connected together) arranged so that information may be passed from one part of the network to another over multiple links and through various nodes. Thus, as non-limiting examples, the network101could comprise the Internet, the public switched telephone network, the global Telex network, computer networks (e.g., an intranet, an extranet, a local-area network, or a wide-area network), wired networks, wireless networks, or any combination thereof.

System components may be communicatively coupled to the network101via any method of network connection known in the art or developed in the future including, but not limited to wired, wireless, modem, dial-up, satellite, cable modem, Digital Subscriber Line (DSL), Asymmetric Digital Subscribers Line (ASDL), Virtual Private Network (VPN), Integrated Services Digital Network (ISDN), X.25, Ethernet, token ring, Fiber Distributed Data Interface (FDDI), IP over Asynchronous Transfer Mode (ATM), Infrared Data Association (IrDA), wireless, WAN technologies (T1, Frame Relay), Point-to-Point Protocol over Ethernet (PPPoE), and/or any combination thereof.

The packet payload converter module110may comprise software and/or scripts that may be stored in the memory of—and run on—at least one server computer101and may contain instructions that, when executed by the server computer's101microprocessor, cause the microprocessor to receive a plurality of Voice over Internet Protocol (VoIP) packets, convert the VoIP packets to a digital audio file120, and write the digital audio file120to a media database130running on the one or more server100.

The VoIP packets may comprise any Internet telephony format or type, perhaps (as illustrated inFIG. 1) one representing a conversation between Caller A and Caller B. The illustrated embodiments place no limitation on the type of VoIP-related communication that may be processed by the systems and methods illustrated herein. For example, any audio, video, and/or instant messaging communications transmitted in (or convertible to) packet format may be processed.

As a specific, non-limiting example, the VoIP packets may comprise the digital output of a VoIP Private Branch Exchange (PBX) within an organization, perhaps communicatively coupled to the network101or running on the server100. The VoIP PBX may receive an incoming call (e.g., from Caller B), perhaps from the Public Switched Telephone Network (PSTN). The PBX may convert the incoming call to Real-Time Transport Protocol (RTP) format (or any other format supported by VoIP or other Internet telephony protocols), which may comprise a standardized packet format for delivering audio over IP networks. Thus, the PBX may convert an incoming call into a plurality of data packets, perhaps in RTP format, that comprise a digital representation of a conversation between, for example, Caller A and Caller B. Each packet may comprise a header (e.g., source and destination IP address information) and a payload (e.g., digital audio data representing parts of the conversation).

The packet payload converter module110may receive the packets, perhaps directly from the PBX in real time, and convert them into a digital audio file120. As a non-limiting example, the packet payload converter module110may extract a plurality of digital audio data from the payloads of the RTP packets and reconstruct the conversation by writing the digital audio data extracted from numerous packets to one or more digital audio file120, which may comprise an digital reconstruction of the entire (or part of) the telephone conversation. The illustrated embodiments place no limitations on audio file types that may be used including, but not limited to those using uncompressed audio formats e.g., (WAV, AIFF, or AU), those using lossless compression (e.g., MPEG-4, M4A, or FLAC), and/or those using lossy compression (e.g., MP3).

The audio file120then may be written to a media database130, perhaps running on the server100. The media database130may store numerous digital audio files120, perhaps received from the packet payload converter module110. It (and/or any other database described herein) may comprise a local database, online database, desktop database, server-side database, relational database, hierarchical database, network database, object database, object-relational database, associative database, concept-oriented database, entity-attribute-value database, multi-dimensional database, semi-structured database, star schema database, XML database, file, collection of files, spreadsheet, or other means of data storage located on a computer, client, server, or any other storage device known in the art or developed in the future.

The transcript generator module140may be configured (e.g., programmed) to read the digital audio file120from the media database130, convert the digital audio file120to a text file150, and write the text file150to a transcript database160running on the one or more server100. The audio file120may be converted to a text file150by any known speech-to-text system or methodology including, but not limited to those provided by WAV to Text or DRAGON DICTATION (e.g., DRAGON NATURALLY SPEAKING). The transcript generator module140may generate the text file150itself or, alternatively, receive the text file150, from a web service responsive to transmitting the digital audio file120for conversion to the text file150. The transcript generator module140then may write the text file150to the transcript database150.

The detection logic module170may be configured (e.g., programmed) to read the text file150from the transcript database160and parse the text file150into a plurality of keywords. Parsing is the process of analyzing a sequence of tokens to determine its grammatical structure with respect to a given formal grammar. Parsing transforms input text into a data structure, such as the keywords used here. As a non-limiting example, if a text file150contains the following sentence: “John Doe's social security number is 123-45-6789,” the detection logic module may parse the sentence into, among others, the keywords “John Doe,” “social security number,” and/or “123-45-6789.”

The text file150may be parsed using any parsing methodology known in the art including, but not limited to, top-down parsing and/or bottom-up parsing. The parsing process also may include glyph or character substitution (i.e., identifying typographically improper characters and substituting characters that result in potentially-meaningful keywords). For example, the parsing process may replace the phrase “one one two” in a social security or credit card number to “112,” resulting in more effective keyword parsing because “112” is more legible and/or understandable in the social security or credit card number context than “one one two.”

The detection logic module170also may be configured (e.g., programmed) to determine whether the text file contains one or more target keyword175. As non-limiting examples, target keywords175may comprise any word, term, phrase, sentence, number, and/or set of characters. For example, the target keywords175may comprise a personally-identifiable information, a credit card number, a social security number, a bank account number, a customer information, a name, an address, a phone number, an organizational secret, a curse word, a trade secret, an illegal activity, an improper activity, a medical information, a financial, or an accounting information.

In one example embodiment, target keywords175may be received from a system administrator190, who may comprise an individual within an organization responsible for its DLP. As a non-limiting example, a system administrator190may access the illustrated system, perhaps via a client computer, and log into a control panel configured to allow the system administrator190to enter target keywords175that the illustrated system should search for.

If the detection logic module170locates a target keyword175in the text file150, it may transmit a report to an events database180, perhaps running on the one or more server100. As a non-limiting example, the report may comprise any data associated with the identified target keyword175including, but not limited to a source phone number, a destination phone number, an internet protocol address, a time, a keyword, an audio file, or the complete text file associated with said conversation from which the text file was generated.

In one example embodiment, a system administrator190may access the report stored in the events database180, perhaps via a client computer, and review its contents (that may include time or date information, the phone numbers of Callers A and B, the IP addresses of their telephones, and/or the located target keyword175), listen to an audio clip of the portion of the conversation containing the target keyword175, and/or read the text file.

FIG. 2abuilds upon the embodiment illustrated inFIG. 1and illustrates a system operated by an organization (e.g., a company, an educational or governmental institution, or any organization having a computer network storing, transmitting, or processing data) further comprising a censored communication generation module210configured (e.g., programmed) to generate a censored plurality of VoIP packets that excludes one or more VoIP packets corresponding to said one or more target keywords175. This may be accomplished by identifying those packets that carried data associated with the target keyword175and deleting those packets from the plurality of VoIP packets transmitted to the receiving caller.

For example, when the packet payload converter module110converts the incoming VoIP packets to a digital audio file120, it may retain in storage the original VoIP packets representing the conversation. The digital audio file120may include data (e.g., packet start and end markers for associated payload data) enabling the system to identify the packets associated with various sections of the digital audio file120. When the detection logic module170locates target keywords175in the text file150, the corresponding packets may be located and perhaps deleted. Alternatively, the censored communication generation module210may substitute “silent packets” (e.g., properly-addressed packets with no audio payload) for the packets corresponding to the target keywords175located in said text file. In such an embodiment, the recipient (e.g., Caller A or B) may receive an audio signal wherein the target keywords170are not represented (i.e., not heard by the recipient). The system may transmit the censored plurality of VoIP packets (e.g., without the packets corresponding to the located target keywords175) to a recipient, such as Caller A or B. This process may occur in real time, enabling live censoring of ongoing conversations.

FIG. 2aalso illustrates an event display portal200that may run on the server100and may be communicatively coupled to the events database200. This portal200may comprise a display webpage or website wherein the system administrator190(perhaps after being properly authenticated) may view incident reports stored in the events database180, listen to audio clips of the conversation (perhaps the portion containing the target keywords175), and review the text file150comprising a transcript of at least part of the conversation. The event display portal200also may be configured (e.g., via data fields or drop-down boxes on a webpage) to allow the system administrator190to enter target keywords175that the illustrated system should search for. The event display portal200also may allow the system administrator190to enter a time frame before and/or after any target keywords175he would like to have censored from the conversation (e.g., 2 seconds) to ensure any information related to a located target keyword is flagged or censored from the conversation.

FIG. 2billustrates a distributed system for detecting and preventing voice data leakage wherein system modules run on a server100coupled to the network101. In this illustrated embodiment, the organization may access the system via the network101, which may be offered by a third party, perhaps as a subscription service. In one embodiment, the system may be accessible to the organization via a web service running on the server100having an application programming interface (API) configured (e.g., programmed) to accomplish the above-described steps responsive to receiving a function call for such service. Such APIs may comprise any API type known in the art or developed in the future including, but not limited to, request-style, Berkeley Sockets, Transport Layer Interface (TLI), Representational State Transfer (REST), SOAP, Remote Procedure Calls (RPC), Standard Query Language (SQL), file transfer, message delivery, and/or any combination thereof.

FIG. 3illustrates a highly-distributed system for detecting and preventing voice data leakage. As illustrated, the embodiments described herein place no limitation on server100configurations or organization. Each module may run on the same server100, a different server100, or, alternatively, some modules may run on one server100while other modules run on another server100. Alternatively, each module may comprise a web service having an API configured (e.g., programmed) to accomplish the above-described steps responsive to receiving a function call for such service, perhaps from another module.

As a non-limiting example, the method illustrated inFIGS. 4-5may be performed by (at least) any central processing unit (CPU) in one or more computing devices or systems, such as a microprocessor running on a server100communicatively coupled to a network101(e.g., the Internet) and executing instructions stored (perhaps as scripts and/or software) in computer-readable media accessible to the CPU, such as a hard disk drive or solid-state memory on a server100. Example systems that may be used to perform the methods described herein are illustrated inFIGS. 1-3and described in detail above.

FIG. 4is a flow diagram illustrating a possible embodiment of a method of detecting and preventing voice data leakage that may comprise the steps of receiving a plurality of VoIP packets (Step400), converting the VoIP packets to a digital audio file120(Step410), converting the digital audio file120to a text file150(Step420), parsing the text file150into a plurality of keywords175(Step430), determining whether the plurality of keywords175contains one or more target keywords (Step440), and, if so, generating a censored plurality of VoIP packets representing the conversation that excludes the one or more target keywords (Step450) and transmitting the censored VoIP packets to a recipient (Step460). If the plurality of keywords175does not contain one or more target keywords, the VoIP packets may be transmitted to the recipient unaltered (Step470).

FIG. 5is a flow diagram illustrating a more detailed possible embodiment of a method of detecting and preventing voice data leakage, wherein Step410further comprises the steps of extracting digital audio data from VoIP packets (Step500) and converting the extracted digital audio data to a digital audio file120(Steps510and520). As a non-limiting example, the packet payload converter module110may extract the digital audio data from the VoIP packet payloads (Step500) and reconstruct the conversation by writing the extracted digital audio data to one or more digital audio file120(Steps510and520), which may comprise an digital reconstruction of the entire (or part of) the telephone conversation.

As further illustrated inFIG. 5, Step450further may comprise identifying the VoIP packets corresponding to each target keyword175located in the text file150(Step560) and deleting those packets from the original file (Step570). As a non-limiting example, steps450,560,570, and460may be accomplished by a censored communication generation module210configured (e.g., programmed) to generate a censored plurality of VoIP packets that excludes one or more VoIP packets corresponding to said one or more target keywords175. This may be accomplished by identifying those packets that carried data associated with the target keyword175and deleting those packets from the plurality of VoIP packets received by the packet payload converter module110.

For example, when the packet payload converter module110converts the incoming VoIP packets to a digital audio file120(Step410), it may retain in storage the original VoIP packets representing the conversation. The digital audio file120may include data (e.g., packet start and end markers for associated payload data) enabling the system to identify the packets associated with various sections of the digital audio file120. When the detection logic module170locates target keywords175in the text file150(Step440), the corresponding packets may be located and perhaps deleted (Steps560and570). The system then may transmit the censored plurality of VoIP packets (e.g., without the packets corresponding to the located target keywords175) to a recipient (Step460), such as Caller A or B. This process may occur in real time, enabling live censoring of ongoing conversations.

Alternatively, the censored communication generation module210may substitute “silent packets” (e.g., properly-addressed packets with no audio payload) for the packets corresponding to the target keywords175located in said text file. In such an embodiment the recipient (e.g., Caller A or B) may receive an audio signal wherein the target keywords170are not represented (i.e., not heard by the recipient).

The method illustrated inFIG. 5may further comprises the step of (if target keyord(s)175are located in the text file150) transmitting a report to an event database180. As described above, the report may comprise any data associated with the identified target keyword175including, but not limited to a source phone number, a destination phone number, an internet protocol address, a time, a keyword, an audio file, or the complete text file associated with said conversation from which the text file was generated.

In one example embodiment, a system administrator190may access the report stored in the events database180, perhaps via an event display portal200via his client computer, and review report contents (that may include time or date information, the phone numbers of Callers A and B, the IP addresses of their telephones, and/or the located target keyword175), listen to an audio clip of the portion of the conversation containing the target keyword175, and/or read the text file.

In one example use of the methods and systems described herein, a system administrator190(perhaps a call center MIS manager) may log into an embodiment of the above-described Voice Data Leakage Detection and Prevention System via a password-protected web-based event display portal200website running on his organization's server100accessible via the Internet. After the system administrator190is properly authenticated, the event display portal200may display data fields on a webpage in which the system administrator190may enter target keywords175that he would like monitored. For example, the system administrator190may want to be alerted when call center employees discuss customer credit card or social security numbers. In such an example, the system administrator190may enter the target keywords “credit card” and “social security” in the event display portal's200data fields. The event display portal200may also allow the system administrator190to enter a time frame before and/or after any target keywords175he would like to have censored from the conversation (e.g., 2 seconds) to ensure any information related to a located target keyword is flagged or censored from the conversation.

A call center employee (e.g., caller A inFIG. 2a) may subsequently receive a telephone call from a personal friend (e.g., caller B) who is not an employee of the organization, perhaps with the malicious intent of obtaining customer credit card and social security data to steal a customer's identity. As per known Internet telephony, caller B's incoming telephone phone call may be received by the organization's PBX device and converted to a stream of VoIP packets for transmission to caller A's telephone.

In this example, however, the packet payload converter module110of Voice Data Leakage Detection and Prevention System also receives the stream of VoIP packets from the PBX (Step400). As the conversation between callers A and B continues, the digital audio data from the incoming VoIP packet payloads may be extracted (Step500) and written to one or more digital audio files120(Step520) stored in the media database130(Step530). Packet header information (e.g., time, date, source and destination IP addresses and phone numbers) may also be stored, perhaps in correlation with the packet payload to allow for speedy reconstruction of the conversation in VoIP format.

The transcript generator module140may read the digital audio file (Step540) from the media database130(Step540) and generate a transcript of the conversation (e.g., one or more text files150) (Step420), which may be stored in the transcript database160(Step550). The detection logic module170then may read the transcript from the transcript database160and determine whether the terms “credit card” or “social security” (i.e., the target keywords175set by the system administrator190) are present in the transcript (Steps430and440).

If those target keywords are located (e.g., caller A says: “customer John Doe would be a good identity to steal, his credit card number is 1234 56789 1234 and his social security number is 123-45-6789”), the system may automatically censor the located target keywords175from the conversation by deleting the packets corresponding to the identified target keywords175from the stream of VoIP packets, or alternatively, substituting “silent” packets (having no audio data in their payload) for the deleted packets. Thus, continuing with the above example, caller B would hear the following sentence on his telephone: “customer John Doe would be a good identity to steal, his social security number is——————.”

Additionally, a report may be generated (Step575) and transmitted to the events database180(Step580). As described above, the report may comprise any data associated with the identified target keyword175including, but not limited to a source phone number, a destination phone number, an internet protocol address, a time, a keyword, an audio file, or the complete text file associated with said conversation from which the text file was generated. Such a report may be accessed by the system administrator190logging back into the event display portal200and perhaps clicking on a “reports” webpage.

In this example use, the systems and methods described herein prevented sensitive information from being leaked outside the organization and also allowed the system administrator190to identify the offending party to take any necessary corrective action.

Other embodiments and uses of the above inventions will be apparent to those having ordinary skill in the art upon consideration of the specification and practice of the inventions disclosed herein. The specification and examples given should be considered exemplary only, and it is contemplated that the appended claims will cover any other such embodiments or modifications as fall within the true scope of the inventions.

The Abstract accompanying this specification is provided to enable the United States Patent and Trademark Office and the public generally to determine quickly from a cursory inspection the nature and gist of the technical disclosure and in no way intended for defining, determining, or limiting the present inventions or any of its embodiments.