1. Field of the Invention
The present invention relates generally to storage systems and information systems that store data.
2. Description of Related Art
Most companies or organizations have a certain amount of confidential data stored in their information systems. In general, it is difficult to control data flow in information systems because it is very easy for users with authorized access to copy and distribute electronic data. As a result, confidential information contained within electronic data is likely to be distributed to many places inside and outside of organizations. Such situations can cause both unintentional information leakage and also provide the opportunity for intentional misappropriation of confidential information.
To prevent information leakage and protect privacy information, many different regulations have been established in recent years. Companies and organizations need to be compliant to such regulations. To meet compliance and achieve internal control, many companies and organizations have strict security policies or rules for their employees. However, it is often difficult to enforce these policies and rules over an entire organization, especially in large organizations with many employees and a number of different divisions, groups, databases, and the like. Thus, it is not easy for those in charge of enforcing these rule and policies to detect violations when they take place. As a result, confidential data is likely to be scattered around inside organizations in spite of rules and policies intended to prevent this. Accordingly, it would be desirable to have an automated system in place that detects when a leakage of protected information has occurred, that is able to notify those in charge of the leakage, and that is also able to take corrective measures.
Additionally, it is known in the prior art to conduct de-duplication on data for reducing the amount of data stored in a storage system. For example, U.S. Pat. No. 7,065,619, to Zhu et al., entitled “Efficient Data Storage System”, filed Dec. 20, 2002, the disclosure of which is incorporated herein by reference, teaches de-duplication operations using a summary in a low latency memory. However, the prior art does not teach or suggest an information leakage detection technique that leverages a data de-duplication functionality.
The invention detects possible information leakage in an information system, such as, for example, unauthorized information sharing among several different divisions or groups of an organization that use a consolidated storage system. The invention is further able to notify security monitoring services of an information leakage and/or take corrective action when the storage system detects an information leakage. These and other features and advantages of the present invention will become apparent to those of ordinary skill in the art in view of the following detailed description of the preferred embodiments.
The accompanying drawings, in conjunction with the general description given above, and the detailed description of the preferred embodiments given below, serve to illustrate and explain the principles of the preferred embodiments of the best mode of the invention presently contemplated.
In the following detailed description of the invention, reference is made to the accompanying drawings which form a part of the disclosure, and, in which are shown by way of illustration, and not of limitation, specific embodiments by which the invention may be practiced. In the drawings, like numerals describe substantially similar components throughout the several views. Further, the drawings, the foregoing discussion, and following description are exemplary and explanatory only, and are not intended to limit the scope of the invention or this application in any manner.
The information leakage system of the invention may be applied in numerous different types of information systems, such as storage systems including NAS (network attached storage) systems, DAS (direct access storage) systems, block-based storage systems, CAS (content addressed storage) systems and other types of storage systems including those using a LAN (Local Area Network), a SAN (Storage Area Network) or other internal or external network types for communicating information. In some embodiments, the information leakage detection system of this invention detects information leakage by having the storage system determine the owners of data stored in the storage system. A host computer that primarily stores data in the storage system can become an owner of the data. An administrator is able to change the owner of the data and add one or more other host computers or host groups as owners of the data using a management interface of the storage system. In some embodiments, when the storage system receives data from a host computer, the storage system checks whether the host computer is the owner of the data. If the host computer is not the owner of the data, the storage system executes a specified or predetermined action. The storage system can execute several kinds of actions, including sending a notification of an information leakage to an administrator at a management computer. Further, an administrator can configure the actions for each type of data. The system can be used with both file-based data and block-based data. In other embodiments, the storage system is also able to check the owners of data asynchronously. Under the asynchronous technique, the storage system scans its file system periodically, finds new files that have been stored since the last scan, and determines the ownership of the new files.
Thus, the invention enables a storage system to detect and notify a management host when new data is stored in the storage system that has the same content as existing data previously stored in the storage system, whether or not the new data has the same file name or data identifier as the existing data. In some embodiments, hash values are calculated for the new data and compared with hash values calculated for the existing data to quickly determine whether the content of the new data is the same as the content for the existing data. The storage system is then able to determine if the owner of the new data is registered as an owner of the existing data, and identify an information leakage occurrence when the ownership does not correlate.
The invention enables an administrator or monitoring agent to be notified of any suspicious or unauthorized file sharing or data leakage within the storage system. This unauthorized sharing often occurs through attachments to e-mails, use of mobile storage mediums, such as USB flash memory, or the like. The invention may be used in a storage system in addition to other security measures, such as access control software that prevents an unauthorized user from accessing certain files, volumes or partitions within the storage system. Thus, the present invention is able to fill a gap in security protection, and is able to detect instances in which data is shared by means other than direct unauthorized access to the original files. The invention is able to detect that this sharing took place even though unauthorized access to the confidential data never occurred. When such unauthorized information sharing takes place, and the shared data is stored back into the storage system, even under a different name, the invention is able to detect this and take an action. The invention is able to perform this detection function synchronously, as the data is attempted to be stored to the storage system, or asynchronously, after the data has already been stored.
Storage system 1 includes a controller 16 that includes at least one CPU (central processing unit) 10, at least one memory 11, and two Ethernet interfaces 12 and 14 that are used for connecting to LAN 40 and management network 41, respectively. Storage controller controls input/output (I/O) operations to one or more storage devices 17. Storage devices 17 are hard disk drives in the preferred embodiment, but in other embodiments may be solid state memory devices, optical devices, tape devices, or the like. One or more of storage devices 17 may be logically configured to create one or more logical volumes 13. For example, each logical volume 13 may be composed from portions of a plurality of physical storage devices 17 arranged in a RAID (redundant array of independent disks) array, such that data stored to a logical block address (LBA) in the volume 13 is physically stored to the storage devices 17, as is known in the art. Further, in the case of the storage of file data, file systems or portions thereof may be created on the volumes 13 to enable storage of file-based data.
Each host computer 2 includes at least one CPU 20, at least one memory 21, and at least one Ethernet interface 22 to enable connection to LAN 40. Additionally, each monitoring computer 3 includes at least one CPU 30, at least one memory 31, and at least one Ethernet interface 32, or the like, to enable connection of management computer 3 to management network 41. Each host computer 2 may be designated as belonging to one or more host groups, as described further below.
Software Architecture
Storage system 1 can implement both a synchronous and an asynchronous way to detect information leakage. In the case of the synchronous method of leakage detection, storage system 1 carries out a process to detect information leakage in synchronization with a process for receiving files from the host computers 2. In this embodiment, service program 50 performs not only network file system services, but also performs the process to detect information leakage synchronously. When service program 50 receives a file from a host computer 2, service program 50 checks whether the same file has already been stored within storage system 1 by another host computer 2. Service program 50 is also able to check whether the same file has already been registered for another host computer by the administrator. If the same file was already stored or registered, service program 50 executes an action, as described below. In these embodiments, service program 50 uses hash values calculated for each file to compare files, although other comparison means, such as algorithms other than hash calculations, direct comparison, or the like, may also be used. Typical hash algorithms that can be used with the invention include MDX (Message Digest algorithm) and SHA (Secure Hash Algorithm), but the invention is hot limited to any particular hashing algorithm.
Asynchronous detection program 51 is applied in the case in which asynchronous detection is carried out. Thus, under the asynchronous detection process, storage system 1 executes asynchronous detection program 51 to detect information leakage separately from the process carried out by the service program 50. In this embodiment, asynchronous detection program 51 periodically checks whether there is any new file stored within storage system 1, and checks whether the same file was already stored within storage system 1. If the same data content has already been stored, then asynchronous detection program 51 executes a specified action as described further below. Asynchronous detection program 51 uses hash values of files to compare files in the preferred embodiments, but could use algorithms other than hash, or other comparison means.
Host group definition table 52 holds group definition information of host computers. When storage system 1 performs the process to detect information leakage, it can group multiple host computers together using host groups 4, as also illustrated in
Action definition table 53 holds definitions of actions that are executed by service program 50 or asynchronous detection program 51 when they detect information leakage. There could be many kinds of actions such as logging, mail, SNMP Trap, or the like. Administrators can configure this table via management service program 57.
Host table 54 holds hash values of existing files and host groups that are registered as owners of the existing files. Using this table, service program 50 and asynchronous detection program 51 checks whether a certain new file is already stored within the storage system as an existing file. It is also possible to check the owners of the existing files using this table. Host groups listed for each hash value of the files in this table are owners of the existing files. The first host group that stored the file usually becomes the owner of the file. However, administrators can configure this table via management service program 57 to add or remove owners of files, as is described further below.
File table 55 holds hash values of files and identifications of files (such as names of files, names of file-paths, or so). Multiple identifications could indicate the same file.
Action table 56 holds hash values of files and identifications of actions. When service program 50 and asynchronous detection program 51 detect information leakage, they execute actions indicated by the identifications. Actual actions are defined within action definition table 53-56.
Management service program 57 provides administrators with a graphic management interface for managing storage system 1. Using this interface, administrators can execute various kinds of management operations, including detection of information leakage. For example, administrators can view or configure host group definitions, action definitions, and the like.
Host computer 2 includes an operating system (OS) 60 and a network file system client program 61. OS 60 is software used to provide interfaces of hardware control to application software and enable file system access. Client program 61 enables host computer 2 to utilize the file system that is exported by service program 50.
Software on the monitoring computer 3 includes an OS 70 and a security event monitoring program 71. OS 70 is software used to provide interfaces of hardware control to application software. Security event monitoring program 71 receives messages from service program 50 and asynchronous detection program 51 when these programs execute actions. For example, these programs can send some kind of messages to security event monitoring program 71 to provide notification of the occurrence of information leakage.
Data Structures
Host computers 2 and storage system 1 communicate with each other via LAN using a network file system service protocol (such as CIFS, NFS, or the like). Host computers 2 issue requests using a network file system service command unit 90, and then host computers 2 are able to transmit data to the storage system or receive data from the storage system.
Management window 93 of
Process Flows
Step 1000: Service program 50 receives network file system service command unit 90 from a host computer 2.
Step 1001: Service program 50 checks whether the command is a Read command. If the command is a Read command then the process goes to Step 1004; otherwise, the process goes to Step 1002.
Step 1002: If the command is not a Read command, service program 50 checks whether the command is a Write command. If the command is a Write command, the process goes to Step 1005; otherwise, the process goes to Step 1003.
Step 1003: The command is neither a Read command, nor a Write command, so since the service program 50 executes commands other than Read and Write commands, the command is executed and the process goes on to receive and check the next command.
Step 1004: Service program 50 refers to file table 55. If file table 55 includes a name of a file that was requested by the host computer, service program 50 sends data that corresponds to the data requested by the host computer.
Step 1005: The command was determined to be a Write command, so the service program 50 executes a process to detect information leakage, as described in detail below with respect to
Step 1100: Service program 50 receives data from host computer 2.
Step 1101: Service program 50 determines the host group of the host computer that sent the file to storage system 1 using host group definition table 52.
Step 1102: Service program 50 calculates a hash value for the file received in Step 1101.
Step 1103: Service program 50 refers to host table 54 and file table 55.
Step 1104: Service program 50 checks whether the hash value calculated in Step 1102 is the same as any hash values already registered on host table 54. If the hash value is already registered on the host table 54, then the process goes to Step 1109. Otherwise, if the hash value is not registered on the host table 54, the process goes to Step 1105.
Step 1105: When the hash value is not already registered on the host table 54, service program 50 next checks whether the file path of the file is already registered for another hash value on file table 55. If the file path of the file is already registered for the other hash vale on the table then the process goes to Step 1115. Otherwise, when the file path also is not registered, then the process goes to Step 1106.
Step 1106: Service program 50 registers the hash value calculated in Step 1102 and the host group determined in Step 1101 on host table 54, since the process assumes that the data of the file received in step 1101 is not already saved in the storage system and that the host that saved the file is the authorized owner. Accordingly, this step registers the file as being owned by the host group of the host computer that sent the Write request. Thus, the first host group to save a new file to the storage system is usually presumed to be the owner of the file.
Step 1107: Service program 50 registers the hash value of the file and the file path of the file on file table 55.
Step 1108: Service program 50 registers the hash value of the file and a default action on action table 56.
Step 1109: Service program 50 stores the file within storage system 1.
Step 1110: When the hash value calculated in Step 1102 is the same as a hash value that is already registered in host table 54, service program 50 checks whether the host group of the host computer that sent the file (as identified in Step 1101) is already registered for the hash value on host table 54. If the host group is already registered for the hash value on the table then the process goes to Step 1111. Otherwise, if the host group is not registered for that hash value, then information leakage is assumed, and the process goes to Step 1113 to execute an action.
Step 1111: Service program 50 checks whether the file path of the file is already registered for the hash value on file table 55. If the file path of the file is already registered for the hash value on the table, then the process goes to Step 1114. Otherwise, if the file path is not already registered for the hash value, the process goes to Step 1112.
Step 1112: Service program 50 registers the file path of the file for the hash value on file table 55.
Step 1113: Service program 50 executes the process to execute actions, as detailed in
Step 1114: Service program 50 discards the file data, since the same data is already stored in another location in the storage system. Further, a direct comparison of the data (e.g., bit-to-bit, or the like) may be conducted here or earlier in order to ensure that the data already stored on the storage system is exactly the same as the data to be discarded before the data is actually discarded. This can eliminate the slim possibility of having matching hash codes for different actual data.
Step 1115: When the hash value is not registered, but the file path is registered for a different hash value, service program 50 removes the entry that includes the file path and the different hash value from file table 55. Then, service program 50 registers the new entry that includes the new hash value that was calculated in Step 1102 and the file path that was found in Step 1105 on file table 55. However, it should be noted that service program 50 does not remove other entries in the file table 55 when the hash value includes any other file paths that correspond to the hash value. For example, when there are multiple instances of an identical file stored in the storage system, it is desirable only to store one actual instance of the data of the file to reduce the overall amount of data stored in the storage system 1. Thus, multiple file paths (i.e., file IDs) might be linked to the stored data represented by the hash value. When a host computer modifies an existing file, storage system 1 receives new file data for the existing file path. The storage system stores the new file data and also registers the existing file path with a new hash value as a new entry for the new file data. Then, the storage system removes the old entry for the file path that included the old hash value. However, as previously explained above with respect to
Step 1116: Service program 50 registers the new entry on host table 54 in an entry that includes the new hash value determined in Step 1102 and the host group that was determined in Step 1101.
Step 1117: Service program 50 registers the new entry that includes the new hash value and default Action on Action Table 56.
Step 1118: Service program 50 stores the file that was received in Step 1100 as a new file within the storage system.
Step 1200: Service program 50 refers to action table 56 and identifies an Action ID 231 for the hash value of the file. Then, service program 50 refers to the Action ID 240 within action definition table 53 to determine the type of action to take.
Step 1201: Service program 50 checks whether the Action ID 240 indicates logging. If the Action ID indicates logging then the process goes to Step 1202; otherwise, the process goes to Step 1203.
Step 1202: Service program 50 creates a log data and sends the log data to the destination 242 that is defined for the Action ID 240 within action definition table 53.
Step 1203: Service program 50 checks whether the Action ID 240 indicates sending e-mail. If the Action ID 240 indicates sending e-mail then the process goes to Step 1204; otherwise the process goes to Step 1205.
Step 1204: Service program 50 creates an e-mail message and sends the e-mail message to the destination 242 that is defined for the Action ID within action definition table 53.
Step 1205: Service program 50 checks whether the Action ID 240 indicates SNMP. If the Action ID indicates SNMP then proceed to Step 1206 otherwise proceed to Step 1207.
Step 1206: Service program 50 creates a SNMP Trap message and sends it to the destination 242 that is defined for the Action ID within action definition table 53.
Step 1207: Service program 50 executes actions other than logging, mail, and SNMP.
Step 1300: An administrator opens a management window 93 to display a registration table 250.
Step 1301: Management service program 57 retrieves file information from file table 55, host information from host table 54, and action information from action table 56 for each hash value in registration table 250.
Step 1302: Management service program 57 displays the retrieved information to the administrator in registration table 250.
Step 1303: The administrator activates the Add New Host button 254, and then management service program 57 opens the second management window 94 to display the Add New Host table 260. The administrator chooses a new host group and activates the Select button 261.
Step 1304: Management service program 57 registers the selected host group on host table 54.
Step 1305: To change an action, the administrator activates the Change Action button 255, and then management service program 57 displays a third management window (not shown in
Step 1306: Management service program 57 updates action table 56.
Step 1400: Asynchronous detection program 51 scans the storage system's file system which is maintained by the storage control software 49 to find any new or updated files that have been stored in storage system 1 since the last scan was performed.
Step 1401: Asynchronous detection program 51 determines whether there is any new file or updated file was found in Step 1400. If a new file or updated file is found, then the process goes to Step 1402. Otherwise, if no new or updated files were found, the process goes back to Step 1400 to check the file system during the next time period. For example, Step 1400 might be performed on an hourly basis, daily basis, etc., depending on the particular storage environment.
Step 1402: When a new or updated file is found, asynchronous detection program 51 checks an identification of the host computer that owns the file using meta data 110 of the file, and checks the host group of the host computer using host group definition table 52.
Step 1403: Asynchronous detection program 51 calculates a hash value of the file.
Step 1404: Asynchronous detection program 51 refers to host table 54 for determination as to whether the calculated hash value for the file is already registered.
Step 1405: Asynchronous detection program 51 checks whether the calculated hash value is already registered on host table 54. If the hash value is already registered on the table 54, then the process goes to Step 1410; otherwise, the process goes to Step 1406.
Step 1406: If the hash value is not registered on the host table, the asynchronous detection program 51 checks whether the file path of the file is already registered for another hash value on file table 55. If the file path of the file is already registered for the other hash vale on the table then the process goes to Step 1415; otherwise the process goes to Step 1407.
Step 1407: When the hash value is not registered on the host table or the file table, asynchronous detection program 51 registers the hash value calculated in step 1403 and the host group determined in Step 1402 on host table 54.
Step 1408: Asynchronous detection program 51 registers the hash value of the file and the file path of the file on file table 55.
Step 1409: Asynchronous detection program 51 registers the hash value of the file and a default action on action table 56.
Step 1410: When the hash value calculated in Step 1403 is already registered in host table 54, asynchronous detection program 51 goes to Step 1410 to check whether the host computer determined in Step 1402 is already registered for the hash value on host table 54. If the host computer is already registered for the hash value on host table 54, then the process goes to Step 1411; otherwise, the file is determined to be information leakage, and the process goes to Step 1413 for carrying out an action, as described above with respect to
Step 1411: Asynchronous detection program 51 checks whether the file path of the file is already registered for the hash value on file table 55. If the file path of the file is already registered for the hash value on the file table 55 then the process goes to Step 1414; otherwise, the process goes to Step 1412.
Step 1412: Asynchronous detection program 51 registers the file path of the file for the hash value on file table 55.
Step 1413: Asynchronous detection program 51 determines that the file is an information leak and executes the process to execute actions, as described above with respect to
Step 1414: Asynchronous detection program 51 discards the file data. Further, a direct comparison (e.g., bit-to-bit, or the like) of the data may be conducted here or earlier in order to ensure that the data already stored on the storage system is exactly the same as the data to be discarded before the data is actually discarded. This can eliminate the slim possibility of having matching hash codes for different actual data.
Step 1415: When the hash value calculated in Step 1403 is not registered, but the file path is registered, asynchronous detection program 51 removes the entry that includes the file path and the other hash value from file table 55. However, asynchronous detection program 51 keeps entries that include other file paths that are related to the hash value if any. Then, asynchronous detection program 51 registers on file table 55 the new entry that includes the new hash value that was calculated in Step 1403 and the file path that was found in Step 1406. However, it should be noted that service program 50 does not remove other entries in the file table 55 when the hash value includes any other file paths that are corresponded to the hash value. For example, when there are multiple instances of an identical file stored in the storage system, it is desirable only to store one actual instance of the data of the file to reduce the overall amount of data stored in the storage system 1. Thus, multiple file paths (i.e., file IDs) might be linked to the stored data represented by the hash value, as described above with respect to
Step 1416: Asynchronous detection program 51 registers on host table 54 the new entry that includes the new hash value determined in Step 1403 and the host group that was determined in Step 1402.
Step 1417: Asynchronous detection program 51 registers the new entry that includes the new hash value and a default action on action table 56.
The above described invention can also be used in storage system 1 for detecting information leakage not only in file data but also in block data, such as data stored using SCSI or other block-type protocols. The second embodiments of the invention illustrate an example of how the invention may be applied in a block-based system. As large parts of the second embodiments are the same as those described above for the first embodiments, only the differences need be described below.
Storage system 1 also includes a detection handling program 59 that is invoked by I/O dispatch program 58 to perform the process to detect information leakage in synchronization with the process to handle SCSI Write requests from host computers 2. When detection handling program 59 receives write/update data from host computer 2, detection handling program 59 checks whether the same data is already stored within storage system 1 by another host computer 2. Detection handling program 59 also checks whether the same data was already registered for another host computer 2 by the administrator. If the same data was already stored or registered, detection handling program 59 executes an action, as described below. Detection handling program 59 uses hash values of data to compare data, as in the first embodiment, but could also or alternatively use other algorithms or comparison methods other than hash values.
As with the first embodiments, host table 54 is included for holding hash values of data and host groups that are registered as owners of data. Using host table 54, detection handling program 59 checks whether a certain data chunk is already stored within storage system 1. Detection handling program 59 also checks the owners of the data using this table. Host groups listed for each hash value of the data in this table are owners of the data. The first host group that stores new data is usually presumed to be the owner of the data. However, administrators can also configure this table via management service program 57 as was described for the first embodiments.
Action table 56 holds hash values of data and identifications of actions as with the first embodiments. When detection handling program 59 detects information leakage, it executes actions indicated by the action identifications 231. Actual actions are defined within action definition table 53, as in the first embodiments. The second embodiments do not include a file table 55, since the second embodiments are used in block-based storage environments, rather than file-based.
Step 2000: I/O dispatch program 58 receives a SCSI command unit from a host computer 2.
Step 2001: I/O dispatch program 58 checks the operation code 300 to determine whether the command is a Read command. If the command is for a Read command, then the process goes to Step 2004; otherwise, the process goes to Step 2002.
Step 2002: I/O dispatch program 58 checks whether the command is a Write command. If the command is a Write command then the process goes to Step 2005; otherwise, the process goes to Step 2003.
Step 2003: I/O dispatch program 58 also executes commands other than Read and Write commands, so if the command is not a Read or Write command, then one of the other commands, as identified in operation code 300, is executed.
Step 2004: When the command is a Read command, I/O dispatch program 58 responds by sending data that corresponds to the data requested by the host computer in the Read command.
Step 2005: When the command is a Write command, I/O dispatch program 58 invokes detection handling program 59, according to the process set forth in
Step 2100: Detection handling program 59 receives the SCSI write data.
Step 2101: Detection handling program 59 checks the host group 4 of the host computer 2 that sent the data to storage system 1 using host group definition table 52.
Step 2102: Detection handling program 59 calculates a hash value for the newly-received data.
Step 2103: Detection handling program 59 refers to host table 54.
Step 2104: Detection handling program 59 checks whether the hash value calculated in Step 2102 is already registered on host table 54. If the hash value is already registered on host table 54, then the process goes to Step 2108; otherwise, the process goes to Step 2105.
Step 2105: Detection handling program 59 registers the hash value calculated in Step 2102 and the host group ID obtained in step 2102 on host table 54.
Step 2106: Detection handling program registers the hash value of the data and a default action on action table 56.
Step 2107: Detection handling program 59 stores the data within storage system.
Step 2108: If the hash value calculated in Step 2102 is a registered hash, detection handling program 59 checks whether the host computer is already registered for the hash value on host table 54. If the host computer that sent the Write command is already registered for the hash value on the table, then the process goes to Step 2110. Otherwise, the data is not registered and is assumed to be information leakage, so the process goes to Step 2109.
Step 2109: The data is assumed to be information leakage, and the detection handling program 59 executes the process to execute actions, as described above with reference to
Step 2110: Detection handling program 59 discards the data, since it is already stored in the storage system. Because hash values may in rare instances be the same for different data, an additional comparison of the new data with the data already stored in the storage system may be conducted either at this point, or in Step 2104. This will ensure that the discarded data is actually already stored in the storage system. As discussed above, the comparison may be conducted as a bit-to-bit comparison, byte-to-byte, or through another type of algorithm, and may be conducted by software or hardware. Further, the management of the de-duplication of the data in the storage system can be conducted as taught by the Zhu patent, which was incorporated herein by reference above. Accordingly, the details do not need to be repeated here.
Thus, it may be seen that the invention is useful for storage systems and host computers that are connected to storage systems to detect information leakage. The storage system can check the owners of data synchronously, such as at the time the data is stored, or asynchronously. The invention provides a mechanism that detects possible information leakage, especially unauthorized information sharing among several divisions of organization that use a consolidated storage system. The invention can also provide a mechanism that notifies a security monitoring service of information leakage when storage system detects information leakage. Additionally, the invention is able to facilitate the use of de-duplication in a storage system, and is compatible for use in a Contents Addressed Storage (CAS) system in which data is stored according to the content of the data itself, whereby a unique address is created for each chunk of data based upon a hash value calculated from the content of the data. For example, US Pat. Appl. Pub. No. 2002/0042796A1 to Tomohiro Igakura, entitled “File Managing System”, the disclosure of which is incorporated herein by reference in its entirety, discusses a system in which hash values are used to determine file IDs for files according to the content of the files.
Further, while specific embodiments have been illustrated and described in this specification, those of ordinary skill in the art appreciate that any arrangement that is calculated to achieve the same purpose may be substituted for the specific embodiments disclosed. This disclosure is intended to cover any and all adaptations or variations of the present invention, and it is to be understood that the above description has been made in an illustrative fashion, and not a restrictive one. Accordingly, the scope of the invention should properly be determined with reference to the appended claims, along with the full range of equivalents to which such claims are entitled.