Abstract:
The present invention relates to a method, a system, and an apparatus for protecting data in a computer network. A device is placed on a network edge in such a way, that all outgoing data has to pass through it. Separately, a set of protected files that are not allowed to leave the network is defined. The device checks the passing data for the presence of the data from the defined set (protected data). If a threshold amount of the protected data is present, the device interrupts the connection or takes another appropriate action.

Description:
This application is a continuation-in-part of U.S. patent application Ser. No. 10/968,218 filed Oct. 10, 2004 entitled “Method, A System, and An Apparatus for Content Security in Computer Networks”. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to the field of the computer network security. 
     Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all rights whatsoever. 
     2. Background Art 
     Security is an important concern in computer networks. Networks are protected from illegal entry via security measures such as firewalls, passwords, dongles, physical keys, isolation, biometrics, and other measures.  FIG. 1  illustrates an example of prior art security in a network configuration. A Protective Device  102  resides between an Internal Network  101  and an Outside Network  103 . There are multiple methods of content filtering, designed to protect the inside network (or a single computer) from entering of harmful data from the outside network. For example, it is done by cataloguing allowed and banned URLs, web sites, web domains or through real time scan for forbidden words or through blocking certain IP addresses and ports. The example of  FIG. 1  is typical of prior art security schemes in that it is principally designed to limit entry to the network. However, there are fewer methods to prevent exits from a protected network in the form of data leaks. This is unfortunate, because a significant threat in networking is the leaking of confidential materials out of the network. Some methods of protection include recognizing predefined keywords in the outbound data and recognizing simple patterns, such as a 16-digit credit card numbers. When such identifiers are recognized and when such outbound data has not been authorized, the data transmission may be stopped. These prior art methods are inadequate for the task of providing security against data leakage. 
     SUMMARY OF THE INVENTION 
     The present invention relates to a method, a system, and an apparatus for protecting data in a computer network. A device is placed on a network edge in such a way that all outgoing data has to pass through it. Separately, a set of protected files, data from which is not allowed to leave the network, is defined. A set of rules is defined as well. A set of allowed files or files, excluded from consideration, may be defined as well. The device checks the passing data for the presence of the data from the defined set (protected data). If a threshold amount of the protected data is present, the device interrupts the connection or takes another appropriate action. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWING 
         FIG. 1  illustrates a prior art network system. 
         FIG. 2  illustrates a network system according to the invention. 
         FIG. 3  is a flow diagram illustrating the operation of an Inspection Device according to the invention. 
         FIG. 4  illustrates an alternate network system of the invention. 
         FIG. 5  is a flow diagram illustrating operation of the invention of  FIG. 4 . 
         FIG. 6  is a flow diagram illustrating an embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     In the following description, numerous specific details are set forth to provide a more thorough description of embodiments of the invention. It is apparent, however, to one skilled in the art, that the invention may be practiced without these specific details. In other instances, well known features have not been described in detail so as not to obscure the invention. 
       FIG. 2  illustrates a network configuration according to the invention. An Inspection Device  202  is connected to a Protected Network  201  in such a way that it is able to inspect all the outbound traffic from the Protected Network  201  to the Outside Network  205 . An Importing Device  203  is connected to the Protected Network  201  as well, and a Storage device  204  is set up in such a way that it is connected to both Inspection Device  202  and Importing Device  203 . 
     The Inspection Device  202  typically comprises a computer or other networking device, with a CPU, RAM and networking means. Nevertheless, the Inspection Device  202  may comprise multiple physical devices. For example, it may comprise a Layer 4 switch and a computer connected to it. 
     The Importing Device  203  may comprise a stand alone computer or other networking device with a CPU, RAM. The Importing Device  203  and the Inspection Device  202  may be combined into one physical device. 
     Storage device  204  may comprise a stand alone device in the network or be combined with the Inspection Device  202  and/or the Importing Device  203 . The Storage device  204  may comprise a relational database, such as MySQL. 
     Importing Device operation 
     The function of the Importing Device  203  is to import the data that needs to be protected, process it and to store the results of this processing in the Storage device  204 . In one embodiment of the invention the data objects being imported are referred to as files, although not only operating system files may be imported. A system administrator, operating the system, selects the protected data using one of the multiple methods, including:
         Specifying Universal Resource Identificators (URIs);   selecting folders and single files on one or multiple computers in the network;   specifying an email account to listen to;   creating database queries to execute to obtain the data; or   any combination of the methods above.       

     For further discussion in an example embodiment, assume that the protected data is provided as files and folders. The Importing Device  203  inspects the data and imports each file into the Storage device  204 . Importing may be done in many ways, including:
         copying all the data from the file to the storage;   creating a search index of the imported data in the storage;   creating a signature of the file, comprising one digital digest on the full file;   creating a signature of the file, comprising multiple digital digests, computed on different sequences of the file;   manual copying of some data through a clipboard; or   any combination of the methods above.       

     One embodiment of the digital digest computation is MD5 on the data, although other algorithms may be used as well without departing from the scope of the present invention. 
     The Importing Device  203  may operate manually or automatically. In the automatic mode, the Importing Device would monitor the selected files and folders and re-import files when they change or are added. Each file may carry additional attributes, such as secrecy level, IP addresses and protocols that control its ability to be exported, etc. Further, data that is always allowed may be imported similarly. 
     Inspection Device Operation 
     The function of the Inspection Device  202  is to monitor the outbound traffic for the presence of the protected data. It does that using the Storage device  204 . If the amount of the protected data, being transferred in a stream exceeds a predetermined threshold (for example, the length of the data sequence coinciding with the data in the Storage exceeds 4096 bytes), a security breach is declared and a predefined action is taken by the Inspection Device  202 . Among the possible actions:
         log the security breach;   alert security personnel;   stop the transmission of the offending stream;   shut down the traffic between the protected network and outside world; or   any a combination of the above.       

     If the threshold amount of the protected data is not detected, the Inspection Device  202  allows the inspected data to be sent to the Outside Network  205 . 
     In one embodiment, the Inspection Device  202  should recognize the protected data at any location in the data stream. Moreover, it should recognize the protected data even if only a part of a protected file, starting with an arbitrary byte, is present. 
     The protected data may be modified prior to being sent out. In order to protect against some modifications, such as file format changes, the data should be normalized. The Importing Device  203  normalizes the data prior to storing it in the Storage device  204 , and the Inspection Device  202  normalizes the data prior to comparing it to the data in the storage. Normalization may include removing formatting information, converting the complex file formats to the text, etc. 
     In another example embodiment, assume that the criterion of the security breach is the presence of the continuous sequence of the protected data of the length L. Referring to  FIG. 3 , the following operations are executed by the Inspection Device  202  for each outbound data stream: 
     Read and retain all the available data (step  301 ). Normalize the read data (step  302 ). Search for the protected data in the normalized data (step  303 ). If threshold amount of the protected data (ATAPD) is found (check  304 ), recognize the situation as a security breach, interrupt the data stream and alert the Administrator (step  305 ), then go to End. Otherwise, forward all the original data, which is determined not to be a part of ATAPD, to its destination (step  306 ). At this time, there may remain a small buffer of unsent data. Wait for more incoming data for up to a predefined timeout (step  307 ). (In one embodiment, the recommended timeout is 500 ms). If the data arrived (check  308 ), go to step  301 . If this is the end of the data stream (check  309 ), go to the End. If no additional data had arrived until the timeout expired, forward the remaining data to its destination, while retaining the copy (step  310 ). 
     Further, when the timeout is concerned, the algorithm may distinguish between the situation when it can not determine whether some of the data in the end is part of ATAPD, and when it had determined that it is. In the former case the timeout is shorter, than in the latter. 
     Discovery of ATAPD 
     As explained above, the operation of the Inspection Device is discovery of the protected data (which is stored in the Storage) in the outbound data streams. In one embodiment, it is recommended to load the content of the Storage or significant part of it into RAM of the Inspection Device. There are multiple methods of search for ATAPD. 
     1) Full Search. Starting at each byte in the outbound data, compare the data with all the data in the Storage. 
     2) Indexed Search. The protected data is in the Storage and is indexed for search. At the intervals of L/2 or smaller, select a word or a phrase with the length of less than L/2 in the inspected data. Search for this word or phrase in the Storage. If found, compare the data on the both sides of the found byte sequence (i.e. before and after). If the total length of the coinciding sequence is larger, than L—there is ATAPD and a security breach is discovered. Otherwise, it is not. 
     3) A digital digest is computed on each imported file. If in time of inspection the structure of the data is known and beginning and the end of a possibly protected file are known, a digital digest is computed on the data from the beginning to the end. Then, the search for that digest is done in the storage. If it is found—there is ATAPD and a security breach is discovered. 
     4) In time of importing, each file is divided into parts with the length less than L, and a digital digest is computed on each part and saved into the database. (For example, the MD5 algorithm can be used for computing the digest). The digests are saved into the storage, and the protected data itself is not saved. In one embodiment, the division is done into parts of equal length L0, except for the remainder of the file of the length less than L0. For example, L=4096 and L0=128, in bytes. In this embodiment, in time of inspection, fragments of length L0 are selected in the normalized data with the distances of no more than L−L0 between them. The digests are computed on L0 bytes of the normalized data, starting with every byte of every fragment. Then, the algorithm searches each computed digest in the Storage. Let us assume that the digest, computed starting at position B0, is found in the Storage. The data between B0 and B0+L0 is considered equivalent to the protected data. Then, the algorithm computes the digests in the positions B0+L0, B0+2×L0, B0+3×L0 . . . and in the positions B0−L0, B0−2×L0, B0−3×L0 . . . and tries to find them in the Storage, adjacent one to another. This way, it determines the longest sequence between B0−C and B0+D, which is equivalent to the protected data. If its length is more than L-ATAPD is found and a security breach is discovered. 
     5) This embodiment uses a technique referred to herein as “orientation points.” For each octet of the data stream define the function F( ) such as CRC (Cyclic Redundancy Sum, 32 bit) over an octet sequence in that stream of length l=32, starting with this octet. Select as an orientation point (OP) every octet I0, that function F( ) can be computed on it and F( ) has a strict local minimum in the radius N, i.e. F(I0)&lt;F(x) for each octet x on the sequence [I0−N, I0+N], except for I0. N=1024. It should be noted that selection of the function F( ) and radius N may differ in different embodiments. In time of importing, OPs are computed on the data. Each file is divided into fragments between OPs, and a digest computed on each fragment and stored in the storage. In time of inspection, OPs are computed in the inspected data, and the digest is computed on each data fragment between OPs. Then, the search for that digest is done in the storage. If the digest is found in the Storage—the fragment is considered equivalent to a fragment of the protected data. If there are one or more consecutive fragments in the inspected data with equivalents in the Storage and their total length exceeds L-ATAPD is found and a security breach is discovered. 
     The invention is described in application to protecting the data in an internal network from leaking to outside network. It may be used to protect the inside network from harmful content, such as viruses, from the outside network. To practice the invention in this way, the places of the Protected Network  201  and Outside Network  205  are swapped; i.e. whole Internet is viewed as the Protected Network  201  and the internal network is considered as Outside Network  205 . 
     Additional Embodiment 
     Another embodiment of the invention is illustrated in  FIG. 4 . This embodiment may include an optional second importing device and includes an interface that permits an administrator to define security rules for the network and for network operation.  FIG. 4  illustrates a network configuration according to the alternate embodiment of the invention. 
     An Inspection Device  402  is connected to a Protected Network  401  in such a way that the outbound traffic from the Protected Network  401  to the Outside Network  405  comes through the Inspection Device  402 . A First Importing Device  403  and A Second Importing Device  406  are also connected to the Protected Network  401 . The system includes a Storage Device  404  that is coupled to Inspection Device  402 , First Importing Device  403 , and Second Importing Device  406 . An Administrator&#39;s Interface  407  is coupled to the Inspection Device  402 . 
     The Inspection Device  402  typically comprises a computer or other networking device, with a CPU, RAM and networking means. This is by way of example only. In other embodiments, the Inspection Device  402  may comprise multiple physical devices. For example, it may comprise a Layer 4 switch and an associated computer. 
     The First Importing Device  403  may comprise a stand-alone computer or other networking device (having appropriate processing and storage capabilities). In one embodiment, the First Importing Device  403  and the Inspection Device  402  may be combined into a single physical device. 
     The Second Importing Device  406  is optional. The Second Importing Device  406  may comprise a stand-alone computer or other networking device (having appropriate processing and storage capabilities). The Second Importing Device  406  and/or the First Importing Device and/or the Inspection Device  402  may be combined into one physical device. 
     Storage device  404  may comprise a stand-alone device with its own processing and memory capabilities in the network or be combined with the Inspection Device  402  and/or the First Importing Device  403 . The Storage device  404  may comprise a relational database, such as MySQL. 
     Alternately, Inspection Device  402 , First Importing Device  403 , Storage  404 , and Second Importing Device  406  may all be implemented as a single device. 
     The Administrator&#39;s Interface  407  is a computer program that an Administrator uses to specify rules for the Inspection Device  402 . It may run on Inspection Device  402  itself or on another computer. 
     First and Second Importing Device Operation 
     The function of the First Importing Device  403  is to import the data that needs to be protected, process it and to store the results of this processing in the Storage Device  404 . In one embodiment of the invention the data objects being imported are referred to as files, although not only operating system files may be imported. A system administrator, operating the system, selects the protected data using one of the multiple methods as described above with respect to Importing Device  202 . In an example embodiment, assume that the protected data is provided as files and folders. The First Importing Device  403  inspects the data and imports each file into the Storage Device  404 . Importing may be done using any of the methods described above with respect to Importing Device  202 . 
     The First Importing Device  403  may operate manually or automatically. In the automatic mode, the Importing Device would monitor the selected files and folders and re-import files when they change or new files are added. Each file may carry additional attributes, such as secrecy level, IP addresses and protocols that control its ability to be exported, etc. 
     There may be situations where documents in an organization may share common parts, such as a header, a disclaimer or a chapter. When unprotected documents share these parts with protected ones, they may trigger an alert, creating false positives. The function of the Second Importing Device  406  is to import excluded files. The content of the excluded files is eliminated from the consideration in the time of the inspection. The Second Importing Device  406  operates similarly to the First Importing Device  403 , but the imported files are saved into a database of excluded files. In an example embodiment, the following additional steps are implemented in the importing of the excluded files:
         a) identify the parts of the protected files in the database that match content of the excluded files;   b) remove the matching parts from the protected files in the database;   c) if the protected files are indexed, re-compute the indexes.       

     Inspection Device  402  Operation 
     The function of the Inspection Device  402  is to monitor the outbound traffic for the presence of the protected data. It does that using the Storage device  404 . If the amount of the protected data, being transferred in a stream exceeds a predetermined threshold (for example, the length of the data sequence coinciding with the protected data in the Storage exceeds 4096 bytes), a security breach is declared and a predefined action is taken by the Inspection Device  402 . Among the possible actions:
         log the security breach;   alert security personnel;   stop the transmission of the offending stream;   shut down the traffic from the computer involved;   shut down the traffic between the protected network and outside world; or   any combination of the above.       

     If the threshold amount of the protected data is not detected, the Inspection Device  402  allows the inspected data to be sent to the Outside Network  405 . 
     In the preferred embodiment, the Inspection Device  402  recognizes the protected data at any location in the data stream. Moreover, it recognizes the protected data even if only a part of a protected file, starting with an arbitrary byte, is present. 
     The protected data may be modified prior to being sent out. In order to protect against some modifications, such as file format changes, the data should be normalized. The Importing Device  403  normalizes the data prior to storing it in the Storage device  404 , and the Inspection Device  402  normalizes the data prior to comparing it to the data in the storage. Normalization may include removing formatting information, converting the complex file formats to the text, etc. 
     In another example embodiment, assume that the criterion of the security breach is the presence of the continuous sequence of the protected data of the length L. Referring to  FIG. 5 , the following operations are executed by the Inspection Device  402  for each outbound data stream: 
     Read and retain all the available data (step  501 ). Normalize the read data (step  502 ). Search for the protected data in the normalized data (step  503 ). If threshold amount of the protected data (ATAPD) is found (check  504 ), recognize the situation as a security breach, interrupt the data stream and alert the Administrator (step  505 ), then go to End. Otherwise, forward all the original data, which is determined not to be a part of ATAPD, to its destination (step  506 ). At this time, there may remain a small buffer of unsent data. Wait for more incoming data for up to a predefined timeout (step  507 ). (In one embodiment, the recommended timeout is 500 ms). If the data arrived (check  508 ), go to step  501 . If this is the end of the data stream (check  509 ), go to the End. If no additional data had arrived until the timeout expired, forward the remaining data to its destination, while retaining the copy (step  510 ). 
     Further, when the timeout is concerned, the algorithm may distinguish between the situation when it can not determine whether some of the data in the end is part of ATAPD, and when it had determined that it is. In the former case the timeout is shorter, than in the latter. 
     Strict Mode Embodiment 
     Another embodiment for Importing Device and Inspection Device operation is referred to as the Strict Mode. In Strict Mode operation, the Importing Device  403  imports files into a database of allowed files. 
     In the Inspection Device  402 , a length threshold is set. Data processing is done similarly to that described in conjunction with  FIG. 3 , but a security breach is declared only if the transmitted data does NOT match the data in the database. A threshold length is specified (which can optionally equal 0), and transmission of the data stream is allowed, if the length of the non-matching data does not exceed this threshold. 
     The operation of the Inspection Device  402  with respect to discovery of ATAPD and strict mode operation is similar to that described above for Inspection Device  202 . 
     Administrator&#39;s Interface 
     Effective management of the system for controlling data transfer should allow an administrator to specify and modify a number of rules. These rules may, for example, take form of a rules file in the Inspection Device  402  and are set using an Administrator&#39;s Interface  407 . The Administrator&#39;s Interface  407  may run as a program on a remote computer, possibly making use of a browser. It may be even a text editor on the Inspection Device  402 . 
     Each rule may include any of the following parameters of the computers, involved in the data transmission (i.e. the transmission source and the destination):
         IP address   Email address   Presence and the type of encryption   Direction of initial connect (inside out or outside in)   Time   Date   Application Level Protocol       

     Also it specifies for each transmission whether it should be inspected or not and what action should be taken, if a security breach is discovered. Below are examples of possible actions. 
     BREACH_LOG—log the breach to the security log, do not stop transmission; 
     BREACH_ALERT—same as BREACH_LOG, but immediately alert Administrator (typically using an email); 
     BREACH_BLOCK—stop current transmission and alert Administrator. If the email of the human originator of the transmission is known, he or she may be notified as well; 
     BREACH_BLOCK_EXT—same as BREACH_BLOCK, but prevent any transmission from the same IP or computer name for the pre-defined (typically 24 hours) period of time or until Administrator permits; 
     BREACH_BLOCK_NET—prevent any transmission from the network, except for the urgent notification to the Administrator. 
     Rules Protocol 
     In one embodiment of the invention, the rules set is comprised of object definitions and the rules themselves. Object definitions consist of transmission descriptions and object definitions precede the rules. In other words, the object is matched first and then the first rule for that object is applied. If no object/rule combination is matched, then the transmission is allowed and no action is taken. 
     For purposes of example, a sample object and rules structure in Backus-Naur Form is described below. The rules structure may be extended or changed.
         object=object-name boolean-expression-of(simple-object-name) [comment]   object-name=token   simple-object-name=token   comment=quoted string; human readable comment       

     Example of definition of Obj-X: 
     Obj-X obj1 AND obj2 AND ˜obj3 OR obj4 
     simple-object=simple-object-name 
     
       
         
               
               
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 “proto” protocol 
                   
                   
               
               
                   
                 [“src” address] 
                 ; 
                 always inside 
               
               
                   
                 [“dest” address] 
                 ; 
                 always outside 
               
               
                   
                 [“init” initialized] 
                 ; 
                 where connection comes from 
               
               
                   
                 [time] 
                 ; 
                 when appplies 
               
               
                   
                   
               
             
          
         
       
         
         
           
             protocol=“SMTP”|“POP”|“HTTP”|“FTP”|“other” 
             address=ip-address [/mask][:ports]|name[:ports]|spec-address 
             ports=number [−number]*[“,” number [−number]] 
             initialized=“INSIDE”|“OUTSIDE” 
             time=time-once|time-weekly|time-daily 
             time-once=asctime-date[−asctime-date]*[“,” asctime-date [−asctime-date]] 
             time-weekly=wktime[−wktime]*[“,” wktime [−wktime]] 
             time-daily=daytime[daytime]*[“,” daytime [−daytime]] 
             spec-address=smtp-sender|smtp-recipient|pop-recipient; special addresses—for application level protocol 
             smtp-sender=email-expression*[“,” email-expression] 
             smtp-recipient=email-expression*[“,” email-expression] 
             pop-recipient=email-expression*[“,” email-expression] 
             email-expression=token“@”token“.”token 
             token=1*CHAR 
             number=1*DIG 
           
         
       
    
     Time is based on RFC 2616 time:
         weektime=wkday time   daytime=time   asctime-date=wkday SP date3 SP time SP 4DIGIT       

     
       
         
               
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 date1 
                 = 2DIGIT SP month SP 4DIGIT 
               
               
                   
                   
                  ; day month year (e.g., 02 Jun 1982) 
               
               
                   
                 date2 
                 = 2DIGIT “-” month “-” 2DIGIT 
               
               
                   
                   
                  ; day-month-year (e.g., 02-Jun-82) 
               
               
                   
                 date3 
                 = month SP ( 2DIGIT | ( SP 1DIGIT )) 
               
               
                   
                   
                  ; month day (e.g., Jun 2) 
               
               
                   
                 time 
                 = 2DIGIT “:” 2DIGIT “:” 2DIGIT 
               
               
                   
                   
                  ; 00:00:00 - 23:59:59 
               
               
                   
                 wkday 
                 = “Mon” | “Tue” | “Wed” 
               
               
                   
                   
                 | “Thu” | “Fri” | “Sat” | “Sun” 
               
               
                   
                 weekday 
                 = “Monday” | “Tuesday” | “Wednesday” 
               
               
                   
                   
                 | “Thursday” | “Friday” | “Saturday” | “Sunday” 
               
               
                   
                 month 
                 = “Jan” | “Feb” | “Mar” | “Apr” 
               
               
                   
                   
                 | “May” | “Jun” | “Jul” | “Aug” 
               
               
                   
                   
                 | “Sep” | “Oct” | “Nov” | “Dec” 
               
               
                   
                   
               
             
          
         
       
         
         
           
             rule=rule-name object-names-list action 
             object-names-list=object-name*[“,” object-name] 
             action=“BREACH_LOG”|“BREACH_ALERT”|“BREACH_BLOCK”|“BREACH_BLOCK_EXT”|“BREACH_BLOCK_NET” 
           
         
       
    
     An action is taken only if a security breach is discovered. 
     Referring to  FIG. 6 , the following operations are executed by the Inspection Device  402  for each outbound data stream: Discover The beginning of the data stream is discovered at step  601 . At step  602 , the parameters of the datastream are determined, such as source IP address, destination IP address, direction (inside-out or outside-in), protocol type, source and destination email (for email protocols), presence of encryption etc. More data is read at step  603 . The data is tested for the security breach, as described above at step  604 . If the security breach is found at decision block  605  consult the rules. Considering the parameters, of the stream and the current date and time, try to find the correspondent object in the rules. If it is found (check  606 ), search for the rules for this object (step  607 ). If the rule is found (check  608 ), apply the action, stated in the rule (step  609 ). The action is to log the breach, or to alert the Administrator, or to block the stream, or to block the stream and all consequent streams from the same computer. If there is no correspondent object, or there is no rule for the found correspondent object—go back to step  603  and read more data. If there is end of stream (check  610 )—go to the End (for this stream). 
     Thus, a method, a system, and an apparatus for protecting data in a computer network are described in conjunction with one or more specific embodiments. The invention is defined by the following claims and their full scope and equivalents.