US20030105979A1 - Network system enabling transmission control - Google Patents
Network system enabling transmission control Download PDFInfo
- Publication number
- US20030105979A1 US20030105979A1 US10/074,239 US7423902A US2003105979A1 US 20030105979 A1 US20030105979 A1 US 20030105979A1 US 7423902 A US7423902 A US 7423902A US 2003105979 A1 US2003105979 A1 US 2003105979A1
- Authority
- US
- United States
- Prior art keywords
- data
- file
- information
- transmission
- security level
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/214—Monitoring or handling of messages using selective forwarding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/105—Multiple levels of security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
Definitions
- the present invention relates to a technique for preventing the confidential information handled in an organization or the like from leaking outside.
- the electronic data handled in an organization or the like contain lots of confidential information.
- the word “confidential” is written in the documents intentionally to inform the viewers that the particular data are confidential.
- the confidential data are thus prevented from leaking outside by making the viewers conscious of the importance of leaking the data outside.
- the confidential data may be inadvertently or intentionally transmitted outside by mail.
- the server searches the mail contents using a keyword to check whether a preset keyword (“confidential”, for example) is contained in the mail. In the case where the keyword is not contained in the mail, the mails are transmitted as they are while in the case where the keyword is contained in the mail, the transmission is suspended.
- Some confidential information can be accessed only by executives of an organization.
- the information flow can be controlled to make the particular confidential information inaccessible from other than the executives by attaching a forcible access control function.
- U.S. Pat. No. 5,940,591 discloses a technique for realizing a multi-level security in the network environment.
- JP-A-8-204701 discloses a method of preventing the confidential information from leaking to third parties by transmitting the information in encrypted form.
- the system for preventing the information leakage based on the keyword search is effective for specified data formats, but not effective for other data formats and an image file containing no text information.
- U.S. Pat. No. 5,940,591 described above poses such problems as: (1) the access control is provided for each user but not for each file, and (2) the requirement for making inquiry at a security manager each time of transmission results in a heavy load.
- the present invention provides a technique for preventing the confidential information of an organization from being transmitted inadvertently by an employee in charge of data transmission.
- the invention further provides a system capable of using the technique described above with an arbitrary data format.
- the invention further provides a technique whereby the security level (“confidential” or “unclassified”) of data is maintained in the data transfer within an organization and is usable for an arbitrary data format.
- additional information indicating the attribute of the information proper (data body) is attached to the information proper (data body), and the transmission and receipt of the information proper are controlled using the particular additional information.
- a label (additional information) indicating the attribute is attached to each data body (information proper), so that the data with the label are handled within the organization.
- the attribute includes a security level (“confidential” or “unclassified”), for example.
- this label is checked by a transmission control program on a gateway server, which decides whether the data can be transmitted outside or not, and in the case where the data is transmissible outside, removes the label from the data and transmits the data body outside.
- the gateway server that has received a data body from outside attaches a label to the data body and transmits the data to the address in the organization.
- a label may not be attached directly on the data body but the security level information of each data may be written in another file.
- a label indicating the security level of the data body is attached by referring to the file and the labeled data is transmitted.
- a technique for preventing the illegal alteration or destruction of the label by the bug of an application program or a device driver or the operating error on the part of the user Specifically, a multi OS (operating system) control technique is used to execute two operating systems in such a manner that one operating system is made available for use by the user while the other operating system is exclusively used for label management.
- OS operating system
- the access to each data can be controlled by an access control list, and (2) since the access control list is located within each user terminal, no inquiry is required each time.
- FIG. 1 is a diagram showing the whole network system according to the invention.
- FIG. 2 is a diagram showing a label format.
- FIG. 3 is a flowchart for performing of opening a file.
- FIG. 4 is a diagram showing a process management list.
- FIG. 5 is a flowchart for performing the process of reading from a file.
- FIG. 6 is a flowchart for performing the process of writing into a file.
- FIG. 7 is a flowchart for performing the process of writing a file into removable media.
- FIG. 8 is a flowchart for performing the process of reading a file from removable media.
- FIG. 9 is a flowchart for performing the process of transmitting a file onto a network.
- FIG. 10 is a flowchart for performing the process of changing the security level.
- FIG. 11 is a flowchart for performing the process of checking the label at a gateway server.
- FIG. 12 is a diagram showing a format of a security level control list.
- FIG. 13 is a flowchart for performing the process of writing a file into removable media according to a second embodiment of the invention.
- FIG. 14 is a diagram showing a structure of a labeled file according to a third embodiment of the invention.
- FIG. 15 is a flowchart for performing the process of writing into a file according to the third embodiment of the invention.
- FIG. 16 is a flowchart for performing the process of receiving a file at a client terminal.
- FIG. 17 is a flowchart for performing the process of checking the label at a gateway server according to the third embodiment of the invention.
- FIG. 18 is a diagram showing a configuration of a client terminal of a network system according to this invention using two operating systems.
- a label indicating a security level is attached to the head of the data stored in a file.
- the information flow is controlled using this label information.
- the contents and the number of the security level and the number of level can be set freely for each system.
- the description that follows refers to two levels including “confidential” and “unclassified”.
- This label may or may not be attached to a file depending on the type of the file. No label is attached to the system file and the driver file, for example, while the label is attached to an application data file.
- the manner in which a file with no label attached thereto is determined in advance as a system policy. According to this embodiment, any files with no label attached thereto are handled as “unclassified” data at a client terminal.
- FIG. 1 shows an example of a configuration of the system according to this embodiment.
- At least one client terminal 101 , a gateway server 118 and a key management server 114 are connected to an in-house network 117 . Further, the gateway server 118 is connected to an external network 121 .
- the client terminal 101 includes a CPU 113 , a memory 102 , a magnetic disk 106 , a network I/F 112 and an external storage unit 122 .
- the memory 102 has loaded thereon a label management program 109 , a file system driver 104 , a disk driver 105 , a protocol driver 110 , a network adaptor driver 111 , an application program 103 and a security level change program 108 . Each of these programs is operated under the control of an operating system (OS).
- OS operating system
- a plurality of files 107 are stored in the magnetic disk 106 .
- the external storage unit 122 is a device for reading or writing data from or into the file 124 in removable storage media (hereinafter referred to as removable media) 123 .
- the external storage unit includes, for example, a floppy disk drive or a CD-ROM device.
- a transmission management program 119 and a receiving management program 120 are operating in the gateway server 118 .
- the key management server 114 includes key information 116 and has a key management program 115 operating therein.
- the client terminal 101 transmits a labeled file onto the network, and the gateway server 118 checks the label of the labeled file to determine whether the particular labeled file should be transmitted or not outside.
- Each program in each embodiment may be introduced into the memory 102 from the magnetic disk 106 , the removable media, or other servers connected to a network in or outside an organization.
- FIG. 2 shows an example of a label format according to this embodiment.
- the label is located at the head of the file 107 and has information of 32 bits (4 bytes). Of the 32 bits, the first two bits represents the version information 201 for the label format, the next three bits the security level 202 of the filed 107 , the following next three bits the settlor level 203 for setting the security level of the file 107 , and the remaining 24 bits the settlor ID 204 who has set the security level of the file 107 .
- the security level 202 includes “unclassified” and “confidential”, and the settlor level 203 includes, for example, “employee”, “group leader”, “section manager” and “department manager”.
- the format and the size of the label may be varied from one organization to another depending on the number of the security levels 202 , the size of the organization or other information to be added.
- the other information includes, for example, the term of validity of the label, the information on the person who has generated the file 107 and the access control information (the read-only information, etc.).
- the access can be controlled using various information other than the security level 202 .
- the label management program 109 is for managing the label of the file 107 .
- the label is removed and data (data body) other than the label is delivered to the application program 103 .
- the label management program 109 transmits the file 107 with the label.
- FIG. 3 is a flowchart for performing the process of opening the file 107 located on the magnetic disk 106 .
- “To open the file” is a pre-process making possible the operations including the reading of data in the file or the writing of data in the file.
- step 301 the application program 103 issues a request for opening the file 107 to the label management program 109 through the I/O manager of the operating system.
- the label management program 109 acquires the process ID of the application program 103 through the I/O manager.
- the process is a unit of executing a program managed by the operating system and the process ID is defined as an identifier of the process.
- step 303 the label management program 109 checks the security level 202 of the file 107 .
- the particular file 107 is determined as an “unclassified” file. Examples lacking the label are a system file and a driver file.
- step 304 the label management program 109 checks the security level of the application program 103 from the process ID.
- the label management program 109 checks the security level of the application program 103 by referring to the process management list 400 shown in FIG. 4. As of the time point when the file 107 is not yet opened by the application program 103 , the security level of the application program 103 is not yet set.
- the requirements for the security level (the security level of the process in execution) of the application program are as follows. Specifically, the application program 103 itself can handle files of various security levels. In the case where confidential files and unclassified files are handled at the same time, the confidential information may be written in an unclassified file (such as cut and paste). According to this embodiment, this risk is avoided by utilizing the security level of the process.
- FIG. 4 shows a process management list 400 .
- the first column shows the process ID 401 , the second column the security level 402 of the particular process (security level of the application program), the third column the name 403 of the file opened, and the fourth column the security level 404 of the particular file 107 .
- the process management list 400 is prepared and initialized by a label management program 109 at the time of loading the label management program 109 . Also, the label management list 400 is updated by the label management program 109 .
- step 305 the label management program 109 checks whether the security level 402 of the application program 103 has been set or not, and in the case where it has been set, the process proceeds to step 311 , otherwise the process is passed to step 306 .
- step 306 the label management program 109 adds the process ID of the application program 103 to the process management list 400 .
- step 307 the label management program 109 sets the process security level 402 of the application program 103 to the security level 202 of the file 107 .
- step 308 the label management program 109 adds the file name 403 and the security level 202 of the particular file 107 to the process management list 400 .
- step 309 the label management program 109 transmits a request to the file system driver 104 to pen the file 107 .
- step 310 the file is successfully opened.
- step 311 the label management program 109 checks whether the security level 402 of the application program 103 is coincident with the security level 202 of the file 107 . In the case where they are coincident, the process proceeds to step 308 , otherwise the process proceeds to step 312 .
- step 312 the label management program 109 displays a message for causing the user to determine whether the file 107 is really to be opened or not.
- step 313 the user decides whether the file 107 is opened or not. In the case where the user decides to open the file 107 , the process proceeds to step 314 , while in the case where the user decides not to open the file 107 , the process proceeds to step 315 .
- step 314 the label management program 109 checks whether the security level 402 of the application program 103 is higher than the security level 202 of the file 107 . In the case where the security level 402 of the application program 103 is higher, the process proceeds to step 308 , otherwise the process proceeds to step 307 .
- step 315 the label management program 109 transmits the open error message of the file 107 to the application program 103 .
- step 316 the file fails to be open.
- the application program 103 can always open the file 107 depending on the designation by the user.
- the process may proceed to step 315 thereby to forcibly reject the file open request.
- the user selects the security level 202 of the same file.
- the security level 202 of the file is set equal to the security level 402 of the application program 103 .
- the highest “confidential” level is desirably selected.
- FIG. 5 is a flowchart for performing the process of reading data from the file 107 according to this embodiment.
- the application program 103 reads the byte offset 0 ⁇ AB00 providing an address from the head of the file 107 , where 0 ⁇ indicates a hexadecimal notation.
- step 501 the application program 103 issues a request to read the data from the byte offset 0 ⁇ AB00 of the file 107 .
- the label management program 103 converts the byte offset 0 ⁇ AB00 to the actual byte offset 0 ⁇ AB04.
- the file 107 carries the information (label) of four bytes (32 bits) at the head of the file 107 . Since the application program 103 is not informed of the presence of the label, however, the byte offset which the application program 103 requests to read is required to be adjusted. As a result, according to this embodiment, a value obtained by adding four bytes, i.e. the byte length of the label information to the byte offset requested by the application program 103 constitutes the actual byte offset.
- step 503 the file system driver 104 converts the actual byte offset 0 ⁇ AB04 to the relative position on the magnetic disk 106 .
- step 504 the disk driver 105 converts the relative position of the magnetic disk 106 to a physical position and reads the data into the memory 102 .
- FIG. 6 is a flowchart for performing the process of writing the data in the file 107 according to this embodiment. As an example, an explanation will be made about a case in which the application program 103 writes into a specific byte offset 0 ⁇ AB00 of the file.
- step 601 the application program 103 issues a request to write the data in the byte offset 0 ⁇ AB00 of the file 107 .
- step 602 the label management program 109 checks the security level 402 of the application program 103 and the security level 202 of the file 107 .
- step 603 the label management program 109 checks whether the security level of the application program 103 is coincident with that of the file 107 . In the case where they are coincident with each other, the process proceeds to step 605 , otherwise the process proceeds to step 604 .
- step 605 the label management program 109 converts the byte offset 0 ⁇ AB00 to the actual byte offset 0 ⁇ AB04.
- the application program 103 reads the data of the file 107 as described above, a value obtained by adding four bytes to the byte offset requested by the application program 103 constitutes an actual byte offset.
- step 606 the file system driver 104 converts the actual byte offset 0 ⁇ AB04 to the relative position on the magnetic disk 106 .
- step 607 the disk driver 105 converts the relative position on the magnetic disk 106 to a physical position and transfers the data to the magnetic disk 106 .
- step 604 the label management program 109 changes the security level 202 of the file 107 to the security level 402 of the application program 103 , and further changes the settlor level 203 and the settlor ID 204 , followed by proceeding to step 605 .
- the security level 202 of the file 107 is changed to the security level 402 of the application program 103 forcibly in step 604 .
- a message may be displayed to permit the user to select the security level 202 of the file 107 .
- the external storage unit 122 is arranged at the client terminal 101 , so that the data can be transferred to another terminal using the removable media 123 .
- the information is liable to leak out through the removable media.
- the data in the removable media 123 is required to be protected from an illegal access from an external source.
- FIG. 7 is a flowchart for performing the process of writing the file 107 into the removable media 123 according to this embodiment.
- the application program 103 prepares a file 124 anew and the data of the file 107 is copied to the file 124 thus prepared.
- the security level of the file 124 is set by the application program 103 when the data is written in the file 124 .
- step 701 the application program 103 issues a request to write the data of the file 107 into the file 124 in the removable media 123 .
- step 702 the label management program 109 checks the security level 202 of the file 107 .
- step 703 whether the security level 202 of the file 107 is “confidential” or not is checked, and in the case where the security level 202 is “unclassified”, the process proceeds to step 704 , while in the case where the security level is “confidential”, the process proceeds to step 706 .
- the label management program 109 issues a request to write the data other than the label of the file 107 into the file 124 in the removable media 123 in step 704 .
- step 705 the write request is received by the file system driver 104 , and the data of the file 107 is transferred to the removable media 123 by the disk driver 105 .
- an encryption key and a decryption key are generated by the label management program 109 in step 706 .
- the encryption key and the decryption key may be identical to each other.
- step 707 the label management program 109 registers the decryption key in the key management server 114 and receives an identifier (ID number, for example) from the key management server 114 .
- ID number for example
- step 708 the label management program 109 encrypts the file 107 using the encryption key, and prepares an encryption file.
- the encryption file includes the ID number and the encrypted data. The ID number is added by the label management program 109 at the time of preparing the encryption file.
- step 709 the label management program 109 issues a request to write the data of the encryption file into the file 124 in the removable media 123 , and the process proceeds to step 705 .
- the label management program 109 transmits the ID number contained in the file 124 to the key management server 114 , and receives the encryption key from the key management server 114 .
- the label management program 109 encrypts the data using the encryption key thus received, and writes the encrypted data in the file 124 .
- FIG. 8 is a flowchart for performing the process of reading the data from the file 124 in the removable media 123 .
- step 801 the application program 103 issues a request to the label management program 109 to read the data from the file 124 in the removable media 123 .
- step 802 the label management program 109 issues a request to the file system driver 104 to read the data from the file 124 in the removable media 123 .
- step 803 the file system driver 104 receives the read request, and the disk driver 105 reads the data from the file 124 in the removable media 123 .
- step 804 the label management program 109 receives the data thus read out, and checks whether the particular data is encrypted or not.
- step 805 the process proceeds from step 805 to step 806 , while in the case where the data is encrypted, the process proceeds to step 807 .
- step 806 the label management program 109 delivers the data to the application program 103 .
- step 807 the label management program 109 reads the ID number of the file 124 .
- step 808 the label management program 109 transmits the ID number of the file 124 to the key management server 114 , and receives the decryption key for the file 124 .
- step 809 the label management program 109 decrypts the encrypted data using the decryption key, and the process proceeds to step 806 .
- the data for the communication between the client terminal 101 and the key management server 114 in step 808 may be encrypted.
- the label management program 109 attaches the label “unclassified” to the file 124 and stores it in the magnetic disk 106 .
- FIG. 9 is a flowchart for the application program 103 performing the process of transmitting the file to the network 117 .
- step 901 the application program 103 issues a request to transmit the file with a label.
- step 902 the label management program 109 acquires the security level 202 of the file 107 , and converts it to a request to transmit a labeled file.
- the application program 103 outputs an unlabeled file data as data to be transmitted, and therefore the label management program 109 converts it to a labeled file.
- step 903 the protocol driver 110 divides the labeled file into packets, and prepares a packet header.
- step 904 the network adapter driver 111 transmits the file 107 outside through a LAN controller.
- the security level change program 108 is for changing the security level 202 of the file 107 .
- FIG. 10 is a flowchart for performing the process of changing the “confidential” file 107 to an “unclassified” file.
- step 1001 the security level change program 108 issues a request to change the security level 202 of the file 107 from “confidential” to “unclassified”.
- step 1002 the label management program 109 acquires the settlor ID 204 by reading the label of the file 107 .
- step 1003 it is determined whether the settlor ID 204 acquired in step 1002 is coincident with the changer ID of the security level 202 . In the case of coincidence, the process proceeds to step 1004 , otherwise the process proceeds to step 1005 .
- step 1004 the label management program 109 changes the security level 202 of the file 107 to “unclassified”, while at the same time changing the settlor ID 204 and the settlor level 203 .
- step 1005 it is determined whether the changer of the security level 202 is authorized to change the security level 202 or not. If the answer is affirmative, the process proceeds to step 1004 , otherwise the process proceeds to step 1006 .
- step 1006 the label management program 109 delivers an error message to the security level change program 108 .
- the authorization to change the security level 202 means the authorization to change the security level 202 forcibly.
- This authorization can be set in such a manner that the change is possible in the case where the level granted an authorized person intending to change the security level 202 is higher than the settlor level 203 of the file 107 .
- the policy of the authorization to change the security level 202 may be set dividedly for each organization. The foregoing description concerns a case in which the security level 202 is changed from “confidential” to “unclassified”. Nevertheless, three or more security levels 202 , if any, can be reduced by a similar method.
- the security level change program 108 can also increase the security level 202 from the “unclassified” file 107 to the “confidential” file 107 . Taking into consideration that the information leakage can be prevented by increasing the security level 202 , an arrangement can be made so that every person can unconditionally perform the operation of increasing the security level 202 .
- the transmission management program 119 checks the label of the file 107 to be transmitted to the external network 121 by the client terminal 101 and determines whether the particular file 107 is to be transmitted or not.
- FIG. 11 is a flowchart for performing the process of checking the label.
- step 1201 the gateway server 118 receives the file 107 to be transmitted to the external network 121 from the in-house client terminal 101 .
- step 1202 the transmission management program 119 decides whether a label is attached to the file 107 or not.
- step 1203 proceeds from step 1203 to step 1204 , otherwise the process proceeds to step 1209 .
- step 1204 the transmission management program 119 checks the security level 202 of the file 107 .
- step 1205 the security level 202 of the file 107 is “unclassified”
- step 1206 the process proceeds to step 1211 .
- step 1206 the transmission management program 119 removes the label from the file 107 .
- step 1207 the transmission management program 119 transmits the file 107 outside.
- step 128 the file is transmitted successfully.
- step 1209 the transmission management program 119 determines that the file 107 is illegal data, and sends an error message to the transmitter terminal and the device used by the system manager.
- step 1210 the file transmission ends in failure.
- step 1211 the transmission management program 119 sends to the transmitter terminal a message to the effect that the security level 202 of the file 107 is “confidential”.
- step 1212 the file transmission ends in failure.
- step 1206 the label is removed in order to follow the policy that the label can be interpreted only for other systems and terminals to which the system according to this embodiment is introduced. According to this embodiment, therefore, although the label is removed when the file is transmitted outside, the label can otherwise be handled as long as other policies are followed.
- the label is removed after determining whether the data is to be transmitted to the external network 121 on the gateway server 118 . Therefore, the embodiment can be utilized transparently also for the external network 121 .
- the gateway server 118 is provided with a permitted transmittee list, so that the file 107 can be transmitted to any external transmittee described in the permitted transmittee list even in the case where the security level 202 is “confidential”.
- the transmission management program 119 encrypts the file 107 and transmits the file 107 without removing the label. Further, the transmission management program 119 records the transmitter, the transmittee and the transmission file in a log.
- the encryption key is registered in the key management server 114 in the same manner as in the case where the file 107 is written in the removable media.
- the file 107 transmitted this way has an ID number and the encryption data.
- the gateway server 118 receives the file 107 transmitted toward the client terminal 101 from the external network 121 .
- the receiving management program 120 attaches the “unclassified” label to the file 107 .
- the settlor ID 204 is set as the ID for the gateway server 118
- the settlor level 203 is set to the lowest level.
- the receiving management program 120 transmits the file 107 to the client terminal 101 .
- the receiving management program 120 may have the function of receiving the labeled file 107 . In such a case, the receiving management program 120 , after confirming that the label is attached, transmits the file 107 to the client terminal 101 .
- the authentication can be granted each other between terminals in the in-house network 117 (between the client terminals 101 or between a client terminal 101 and the gateway server 118 ).
- the authentication between the terminals ( 101 , 118 , 114 ) is carried out by each terminal referring to a list (the communication permission list) held by it, which describes the MAC (Media Access Control) addresses of the terminals with which communication is permitted by each terminal.
- Each terminal can thus be controlled to carry out the communication only with a party whose MAC address (or the IP address) is found in the communication permission list.
- the communication between terminals can be permitted based not on the authentication granted by each terminal but on the authentication determined by an authentication server provided for this purpose. In such a case, each terminal conducts communication with another terminal through the authentication server.
- the authentication between terminals may be granted using the public key encryption system.
- the authentication server may check the labels of all the files transmitted or received by the client terminal 101 in communication with the parties in or outside an organization.
- the file 107 may or may not be accessible depending on the title of an employee or the department of the organization to which the employee belongs. Even in such a case, the information flow can be controlled by the authentication server checking the labels.
- a second embodiment of the invention will be explained.
- a label indicating the security level 202 of the file 107 is attached to the file 107 .
- the information flow is controlled using a security level control list 1400 set in the client terminal 101 without attaching the label to the file 107 in the client terminal 101 , and in the case where the file 107 is sent out of the client terminal 101 , the label is attached to it.
- the format of the label attached to the file 107 sent out of the client terminal 101 is similar to that for the first embodiment.
- FIG. 12 shows the security level control list 1400 according to this embodiment.
- the first column represents a file name 1401
- the second column a security level 1402 of the file 107
- the third column a settlor level 1403 of the file 107
- the fourth column a settlor ID 1404 of the file 107 .
- the same process as in FIG. 6 is performed except for the byte offset processing.
- the label management program 109 checks to see whether the security level 402 of the application program 103 is coincident with the security level 202 of the file 107 , and in the case of incoincidence, sets the security level 202 of the file 107 forcibly to the security level 402 of the application program 103 , while in the case of coincidence, transmits the request to write into the file 107 to the file system driver 104 .
- FIG. 13 is a flowchart for performing the process of writing data into the file 107 of the removable media 123 .
- step 1501 the application program 103 issues a request to write the data of the file 107 into the file 124 in the removable media 123 .
- step 1502 the label management program 109 checks the security level 202 of the file 107 .
- step 1503 whether the security level 202 is “confidential” or not is confirmed, and in the case where the security level 202 is “unclassified”, the process proceeds to step 1504 . In the case where the security level 202 is “confidential”, on the other hand, the process proceeds to step 1506 .
- the label management program 109 issues a request to write the data of the file 107 into the file 124 in the removable media 123 of the file 107 in step 1504 .
- step 1505 the file system driver 104 receives the write request, and the disk driver 105 transfers the data of the file 107 to the removable media 123 .
- the label management program 109 prepares a labeled file 107 in step 1506 .
- step 1507 the label management program 109 generates an encryption key.
- step 1508 the label management program 109 registers the encryption key in the key management server 114 and receives an ID number from the server.
- step 1509 the label management program 109 encrypts the labeled file 107 using the encryption key thereby to prepare an encryption file.
- the encryption file includes an ID number and encrypted data. The ID number is added when the label management program 109 prepares the encryption file.
- step 1510 the label management program 109 issues a request to write the data of the labeled encryption file into the file 124 of the removable media 123 , and the process proceeds to step 1505 .
- the data is read from the file 124 in the removable media 123 in the same manner as in the first embodiment, as shown in FIG. 8. Also, in copying or transferring the file 123 on the removable media 123 to the magnetic disk 106 , the label management program 109 adds the file name 1401 , the security level 1402 , the settlor level 1403 and the settlor ID 1404 of the file 124 to the security level control list 1400 , and thus stores the file 124 in the magnetic disk 106 .
- step 901 the application program 103 issues a request to transmit the file 107 .
- a step is added for the label management program 109 to acquire the security level 202 of the file 107 and thereby to prepare a labeled file.
- the subsequent process is similar to that of the first embodiment, so that the process proceeds to step 902 , in which the label management program 109 converts the transmission request of the file 107 to the transmission request of the labeled file 107 .
- step 903 the protocol driver 110 divides the packet and prepares a packet header.
- step 904 the network adapter driver 111 transmits the file 107 outside through a LAN controller.
- the label management program 109 Upon generation of a request to delete the file 107 , the label management program 109 transmits a request to delete the file 107 to the file system driver 104 , and after receiving from the file system driver 104 a message to the effect that the file 107 has been successfully deleted, deletes the row of the file 107 from the security level control list 1400 .
- the label management program 109 Upon receipt of the file 107 from another client terminal 101 or the gateway server 118 , the label management program 109 checks the label attached to the head of the file 107 and registers the label information of the file 107 in the security level control list 1400 . After that, the label management program 109 delivers the file 107 to the application program 103 .
- the security level 202 of the file 107 is changed in such a manner that the label management program 109 receives a request to change the security level 202 of the file 107 from the security level change program 108 and then changes the security level control list 1400 .
- the processing flow shown in FIG. 10 is followed except that the security level control list 1400 is used.
- the security level 202 is set in the file 107 and thereby the information flow can be controlled in the network.
- an illegal act can be prevented in which a third party A alters a label illegally from the file 107 labeled “confidential” to a file labeled “unclassified”, and further sets the settlor ID to the ID of another person B to show as if B has changed the security level. In this way, should the file 107 labeled “confidential” leak outside, the innocent B is prevented from being persecuted for the act.
- FIG. 14 is a diagram showing a structure of the labeled file 107 used in this embodiment.
- the labeled file 107 includes a label 1701 at the head thereof, followed by a data hash value 1702 , a label signature 1703 , a file data 1704 and a link signature 1705 .
- the data hash value 1702 is that of the file data as of the time point when the settlor himself of the security level 202 prepares or corrects the file 107 or changes the security level 202 .
- the label signature 1703 is a digital signature attached by the settlor of the security level 202 for the label 1701 and the data hash value 1702 .
- the link signature 1705 is a digital signature attached by the person who has prepared or changed the file data 1704 for the label 1701 and the file data 1704 .
- the label signature 1703 guarantees the legitimacy of the label 1701
- the link signature 1705 guarantees the legitimacy of the file data 1704 and the legitimacy of the link between the file data 1704 and the label 1701 .
- the use of the label signature 1703 and the link signature 1705 is effective for the investigation as to where the responsibility lies for any information leakage which may occur, while at the same time suppressing the illegal information leakage as the evidence is left.
- a different confidential key for the signature is desirably held by each different user.
- This embodiment can be used as an extension of the first embodiment, in which case the file structure described above is used in and outside the client terminal 101 .
- the file structure is used outside the client terminal 101 , while the column of the data hash value 1702 , the label signature 1703 and the link signature 1705 is added to the security level control list 1400 within the client terminal 101 , thereby assuring the legitimacy of the label information.
- FIG. 15 is a flowchart for performing the process of writing data (file data 1704 ) into the file 107 according to this embodiment.
- step 1801 the application program 103 issues a request to write the data (file data 1704 ) into the file 107 .
- step 1802 the label management program 109 checks, with reference to the process management list 400 and the security level control list 1400 , whether the security level 402 of the application program 103 coincides with the security level 202 of the file 107 .
- step 1806 the process proceeds to step 1806 , otherwise the process proceeds to step 1804 .
- step 1804 the label management program 109 changes the security level 202 of the file 107 to the security level 402 of the application program 103 , and further changes the settlor level 203 and the settlor ID 204 .
- step 1805 the label management program 109 newly determines the data hash value 1702 , the label signature 1703 and the link signature 1705 , and then proceeds to step 1808 .
- the data hash value 1702 is that of the file data 1704 after the change, and the label signature 1703 and the link signature 1705 the signature of the party requesting to write into the file 107 .
- step 1806 the label management program 109 checks whether the settlor of the security level 202 of the file 107 coincides with the party requesting to write into the file 107 , and in case of coincidence, the process proceeds to step 1805 , otherwise the process proceeds to step 1807 .
- step 1807 the label management program 109 newly determines the link signature 1705 , which is the signature of the party requesting to write into the file 107 .
- step 1808 the label management program 109 issues a request to the file system driver 104 to write the newly acquired one of the data hash value 1702 , the label signature 1703 and the link signature 1705 together with the file data 1704 into the file 107 .
- step 1809 the file system driver transmits the data to be written into the particular file, to the disk driver, which in turn writes the data in the magnetic disk.
- the label management program 109 receives a file transmission request from the application program 103 . Then, the label management program 109 converts the file transmission request from the application program 103 to the transmission request for the labeled file 107 .
- the file structure transmitted from the client terminal 101 is identical to the structure shown in FIG. 14.
- FIG. 16 is a flowchart showing the process for performing the file receive operation at the client terminal 101 according to this embodiment.
- step 1901 the label management program 109 receives the labeled file 107 .
- step 1902 the label management program 109 checks the label 1701 of the labeled file 107 .
- the label management program 109 verifies the legitimacy of the label 1701 based on the label signature 1703 , and checks for the completeness of the file data 1704 and the legitimacy of the link between the file data 1704 and the label 1701 based on the link signature 1705 .
- step 1904 the process proceeds to step 1904 in the case where the result of the check in step 1902 shows that the label 1701 , the file data 1704 and the link between the file data 1704 and the label 1701 are correct, otherwise the process proceeds to step 1906 .
- step 1904 the label management program 109 adds the label information of the labeled file 107 to the security level control list 1400 .
- step 1905 the label management program 109 delivers the labeled file 107 to the application program 103 .
- step 1906 the label management program 109 transmits the label information of the labeled file 107 to the manager.
- step 1907 the label management program 109 sends an error message to the application program 103 .
- step 1001 the security level change program 108 issues a request to change the security level 202 of the labeled file 107 from “confidential” to “unclassified”.
- step 1002 the label management program 109 acquires the settlor ID 204 of the labeled file 107 from the security level control list 1400 according to this embodiment.
- step 1003 it is determined whether the settlor ID 204 acquired in step 1002 is coincident with the changer ID of the security level 202 . In the case of coincidence, the process proceeds to step 1004 , otherwise the process proceeds to step 1005 .
- step 1004 the label management program 109 changes the security level 202 of the labeled file 107 to “unclassified”, while at the same time changing the settlor ID 204 and the settlor level 203 .
- the label management program 109 further performs the process for newly acquiring the label signature 1703 and the link signature 1705 .
- step 1005 it is determined whether the changer of the security level 202 is authorized to change the security level 202 or not. In the case where the changer is so authorized, the process proceeds to step 1004 , otherwise the process proceeds to step 1006 .
- step 1006 the label management program 109 delivers an error message to the security level change program 108 .
- FIG. 17 is a flowchart for performing the process of checking the label 1701 at the gateway server 118 according to this embodiment.
- step 2101 the file 107 transmitted outside of the in-house client terminal 101 is received.
- step 2102 the transmission management program 119 checks whether the label 1701 for the file 107 is present or not.
- step 2103 the process proceeds from step 2103 to step 2104 in the presence of the label 1701 , otherwise the process proceeds to step 2111 .
- step 2104 the transmission management program 119 checks the security level 202 of the labeled file 107 .
- step 2105 the process proceeds to step 2106 if the security level 202 is “unclassified”, otherwise the process proceeds to step 2113 .
- step 2106 the transmission management program 119 checks whether the label 1701 is complete or not. In the process, the transmission management program 119 verifies the legitimacy of the label 1701 based on the label signature 1703 , and checks both the completeness of the file data 1704 and the legitimacy of the linkage between the file data 1704 and the label 1701 based on the link signature 1705 .
- step 2107 the process proceeds to step 2108 in the case where the check in step 2106 shows that the linkage is legitimate, otherwise the process proceeds to step 2115 .
- step 2108 the transmission management program 119 removes the label 1701 , the data hash value 1702 , the label signature 1703 and the link signature 1705 from the labeled file 107 .
- step 2109 the transmission management program 119 transmits the file 107 outside.
- step 2110 the file is transmitted successfully.
- step 2111 the transmission management program 119 determines that the file 107 is illegal data, and sends an error message to the transmitter terminal.
- step 2112 the file transmission ends in failure.
- step 2113 the transmission management program 119 sends to the transmitter terminal a message to the effect that the security level 202 of the labeled file 107 is not “unclassified”.
- step 2114 the file transmission ends in failure.
- transmission management program 119 sends to the transmitter terminal a message to the effect that the label of the labeled file 107 is illegal.
- step 2116 the file transmission ends in a failure.
- the transmission management program 119 may store all the contents of the transmitter information and the transmittee information and the transmission file (the file having the label 1701 , the data hash value 1702 , the label signature 1703 and the link signature 1705 ) in a log.
- the receiving management program 120 attaches the “unclassified” label to the file 107 and transmits the file 107 to the client terminal 101 .
- the label settlor ID 204 is set to the ID of the gateway server 118
- the settlor level 203 is set to the lowest level.
- the label signature 1703 and the link signature 1705 constitute the signature by the gateway server 118 .
- the receiving management program 120 may store in a log the transmitter information, the transmittee information of the file 107 and all the contents of the received file.
- Various application programs 103 operate on a general-purpose computer. Also, various devices are connected and therefore the device drivers for operating these devices are in operation. As a result, in the case where each of the embodiments described above is implemented with a general-purpose computer, a bug of the application program 103 or the device driver and the operating error of the user may cause a change or a deletion of the label information (the security level control list 1400 ), the label management program 109 and the process management list 400 . According to this embodiment, such an inconvenience can be avoided.
- FIG. 18 shows an example of a configuration of the client terminal 101 according to this embodiment.
- Two operating systems are working in the client terminal 101 , which has a memory area 2201 managed by the first operating system and a memory area 2202 managed by the second operating system. Further, a multi OS control programs 2204 for controlling the two operating systems are in operation. A multi OS control technique is disclosed in JP-A-11-149385.
- the memory area 2201 managed by the first operating system has loaded therein an application program 103 , a security level change program 108 , an I/O hook program 2203 , a file system driver 104 , a disk driver 105 , a protocol driver 110 and a network adapter driver 111 . Further, the first operating system manages the magnetic disk 106 and the network I/F 112 , and the file 107 is stored in the magnetic disk 106 .
- the label management program 109 and the process management list 400 are stored in the memory area 2202 managed by the second operating system. Also, the second operating system manages the magnetic disk 2205 , which has stored therein the security level control list 1400 .
- the I/O hook program 2203 hooks the request for access to the file 107 from the application program 103 or the security level change program 108 or the request for transmission/receiving of the file 107 . Further, the I/O hook program 2203 has the function of requesting the processing of the label management program 109 and the function of receiving the result of processing of the label management program 109 and delivering the result of the processing to the file system driver 104 or the protocol driver 110 . Specifically, the I/O hook program 2203 requests the processing of the label management program 109 utilizing the function of communication between the operating systems of a multi OS control programs 2204 . The function of communication between the operating systems is disclosed, for example, in JP-A-11-85546.
- the objects to be protected are managed by the second operating system, so that protection is possible from the change due to the bug of the application program 103 or the device driver operating on the first operating system or the operating error of the user.
- the transmission management program 119 of the gateway server 118 checks the label of the particular confidential file. In the case where the security level is “confidential”, the transmission management program 119 rejects the transmission outside and therefore the leakage of the confidential file can be prevented.
- the label management program 109 can attach a label “Untrusted” on an untrusted program (such as a program accompanying the mail) thereby to limit the files accessible.
- the “Untrusted” label is attached on a system file or a set information file of the kernel, so that in the case where the “Untrusted” program accesses a “Trusted” file, the label management program 109 limits the access.
- This function can be realized by the label management program 109 checking the program and the file label when the file is open. By use of this function, the effect that a computer virus has on the system can be minimized.
- communication can be carried out between the client terminal 101 and the gateway server 118 by use of a dedicated communication protocol.
- a label is attached on the header area of each packet, and the transmission management program 119 of the gateway server 118 checks the label in the header area of the packet thereby to determine whether the data can be transmitted or not.
- the transmission management program 119 removes the label and converts it into a general-purpose communication protocol (TCP/IP, etc.).
- the labeled file 107 is attached to the file attached to the electronic mail and transmitted, and the gateway server 121 checks the label of the file accompanying the mail, thereby making it possible to prevent the confidential file from leaking outside through electronic mail.
- the leakage can be prevented by checking, using the keyword search, to see whether any keyword against the policy is included or not.
- a security level is set for each client terminal 101 , and further an intermediate server is provided between the client terminals 101 on the one hand and between each client terminal 101 and each server on the other, so that the intermediate server may be equipped with the function of preventing the leakage of the information.
- the label need not be attached to the file 107 on the client terminal 101 .
- the intermediate server manages the security level of each client terminal 101 , and determines whether the file 107 transmitted by the client terminal 101 is allowed to be transmitted to another client terminal 101 or another department or group. No label is attached in the case where the intermediate server transmits the file 107 directly to the client terminal 101 , but the label is attached in the case where the file 107 is transmitted to the intermediate server of another department or group.
- the intermediate server checks the label of the file 107 received from another intermediate server, and when transmitting the file 107 to the client terminal 101 , removes the label.
- the intermediate server may be arranged for each department or group.
- the label management program 109 is not required to be incorporated in each client terminal 107 , thereby making it possible to save the labor and trouble for introducing the function of information leakage prevention.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Storage Device Security (AREA)
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
- The present invention relates to a technique for preventing the confidential information handled in an organization or the like from leaking outside.
- The electronic data handled in an organization or the like contain lots of confidential information. On these electronic data, the word “confidential” is written in the documents intentionally to inform the viewers that the particular data are confidential. The confidential data are thus prevented from leaking outside by making the viewers conscious of the importance of leaking the data outside. Sometimes, however, the confidential data may be inadvertently or intentionally transmitted outside by mail. To cope with this problem, the server searches the mail contents using a keyword to check whether a preset keyword (“confidential”, for example) is contained in the mail. In the case where the keyword is not contained in the mail, the mails are transmitted as they are while in the case where the keyword is contained in the mail, the transmission is suspended.
- Some confidential information can be accessed only by executives of an organization. In order to prevent the confidential information from being accessed by unauthorized personnel, the information flow can be controlled to make the particular confidential information inaccessible from other than the executives by attaching a forcible access control function.
- For detailed information on the forcible access control, refer to the reference (TCSEC) “Department of Defense Trusted Computer System Evaluation Criteria” DOD 5200.28-STD.
- On the other hand, U.S. Pat. No. 5,940,591 discloses a technique for realizing a multi-level security in the network environment.
- Also, JP-A-8-204701 discloses a method of preventing the confidential information from leaking to third parties by transmitting the information in encrypted form.
- The system for preventing the information leakage based on the keyword search is effective for specified data formats, but not effective for other data formats and an image file containing no text information.
- In a computer equipped with the mandatory access control function, the information flow can be controlled sufficiently as long as the data stay within the particular computer. Once the data transfers to another computer, however, the security level of the data, which is dependent on the transferee computer, cannot be easily guaranteed. Also, the computer having the mandatory access control function is often utilized for special applications and unable to be used for general-purpose applications. The use of such computer, therefore, hardly extends to unclassified companies and organization.
- U.S. Pat. No. 5,940,591 described above poses such problems as: (1) the access control is provided for each user but not for each file, and (2) the requirement for making inquiry at a security manager each time of transmission results in a heavy load.
- In the case where data are transmitted in encrypted form, on the other hand, the data are encrypted at an employee's terminal, and therefore the employee is required to be informed which data is confidential. As a result, the confidential data may be inadvertently transmitted without being encrypted.
- The present invention provides a technique for preventing the confidential information of an organization from being transmitted inadvertently by an employee in charge of data transmission.
- The invention further provides a system capable of using the technique described above with an arbitrary data format.
- The invention further provides a technique whereby the security level (“confidential” or “unclassified”) of data is maintained in the data transfer within an organization and is usable for an arbitrary data format.
- Specifically, additional information indicating the attribute of the information proper (data body) is attached to the information proper (data body), and the transmission and receipt of the information proper are controlled using the particular additional information.
- More specifically, a label (additional information) indicating the attribute is attached to each data body (information proper), so that the data with the label are handled within the organization. The attribute includes a security level (“confidential” or “unclassified”), for example. In the case where the data are transmitted outside, this label is checked by a transmission control program on a gateway server, which decides whether the data can be transmitted outside or not, and in the case where the data is transmissible outside, removes the label from the data and transmits the data body outside. On the other hand, the gateway server that has received a data body from outside attaches a label to the data body and transmits the data to the address in the organization.
- At a terminal used by a user, a label may not be attached directly on the data body but the security level information of each data may be written in another file. In the case where the data body is transmitted from a client terminal, a label indicating the security level of the data body is attached by referring to the file and the labeled data is transmitted.
- By attaching a signature to the label, the chance of illegal alteration of the label is reduced while at the same time making it possible to identify the party who has set the security level.
- According to the invention, there is also provided a technique for preventing the illegal alteration or destruction of the label by the bug of an application program or a device driver or the operating error on the part of the user. Specifically, a multi OS (operating system) control technique is used to execute two operating systems in such a manner that one operating system is made available for use by the user while the other operating system is exclusively used for label management.
- According to this invention, as compared with the US patent described above, (1) the access to each data can be controlled by an access control list, and (2) since the access control list is located within each user terminal, no inquiry is required each time.
- Other objects, features and advantages of the invention will become apparent from the following description of the embodiments of the invention taken in conjunction with the accompanying drawings.
- FIG. 1 is a diagram showing the whole network system according to the invention.
- FIG. 2 is a diagram showing a label format.
- FIG. 3 is a flowchart for performing of opening a file.
- FIG. 4 is a diagram showing a process management list.
- FIG. 5 is a flowchart for performing the process of reading from a file.
- FIG. 6 is a flowchart for performing the process of writing into a file.
- FIG. 7 is a flowchart for performing the process of writing a file into removable media.
- FIG. 8 is a flowchart for performing the process of reading a file from removable media.
- FIG. 9 is a flowchart for performing the process of transmitting a file onto a network.
- FIG. 10 is a flowchart for performing the process of changing the security level.
- FIG. 11 is a flowchart for performing the process of checking the label at a gateway server.
- FIG. 12 is a diagram showing a format of a security level control list.
- FIG. 13 is a flowchart for performing the process of writing a file into removable media according to a second embodiment of the invention.
- FIG. 14 is a diagram showing a structure of a labeled file according to a third embodiment of the invention.
- FIG. 15 is a flowchart for performing the process of writing into a file according to the third embodiment of the invention.
- FIG. 16 is a flowchart for performing the process of receiving a file at a client terminal.
- FIG. 17 is a flowchart for performing the process of checking the label at a gateway server according to the third embodiment of the invention.
- FIG. 18 is a diagram showing a configuration of a client terminal of a network system according to this invention using two operating systems.
- The disclosures of all articles and references, including patent documents, mentioned in the application are incorporated herein by reference for all purposes.
- (First Embodiment)
- A first embodiment of the invention will be explained. According to this embodiment, a label indicating a security level is attached to the head of the data stored in a file. The information flow is controlled using this label information. The contents and the number of the security level and the number of level can be set freely for each system. The description that follows refers to two levels including “confidential” and “unclassified”. This label may or may not be attached to a file depending on the type of the file. No label is attached to the system file and the driver file, for example, while the label is attached to an application data file. The manner in which a file with no label attached thereto is determined in advance as a system policy. According to this embodiment, any files with no label attached thereto are handled as “unclassified” data at a client terminal.
- FIG. 1 shows an example of a configuration of the system according to this embodiment. At least one
client terminal 101, agateway server 118 and akey management server 114 are connected to an in-house network 117. Further, thegateway server 118 is connected to anexternal network 121. Theclient terminal 101 includes aCPU 113, amemory 102, amagnetic disk 106, a network I/F 112 and anexternal storage unit 122. Thememory 102 has loaded thereon alabel management program 109, afile system driver 104, adisk driver 105, aprotocol driver 110, anetwork adaptor driver 111, anapplication program 103 and a securitylevel change program 108. Each of these programs is operated under the control of an operating system (OS). - A plurality of
files 107 are stored in themagnetic disk 106. Theexternal storage unit 122 is a device for reading or writing data from or into thefile 124 in removable storage media (hereinafter referred to as removable media) 123. The external storage unit includes, for example, a floppy disk drive or a CD-ROM device. Atransmission management program 119 and areceiving management program 120 are operating in thegateway server 118. Thekey management server 114 includeskey information 116 and has akey management program 115 operating therein. Theclient terminal 101 transmits a labeled file onto the network, and thegateway server 118 checks the label of the labeled file to determine whether the particular labeled file should be transmitted or not outside. - Each program in each embodiment may be introduced into the
memory 102 from themagnetic disk 106, the removable media, or other servers connected to a network in or outside an organization. - FIG. 2 shows an example of a label format according to this embodiment. The label is located at the head of the
file 107 and has information of 32 bits (4 bytes). Of the 32 bits, the first two bits represents theversion information 201 for the label format, the next three bits thesecurity level 202 of the filed 107, the following next three bits thesettlor level 203 for setting the security level of thefile 107, and the remaining 24 bits thesettlor ID 204 who has set the security level of thefile 107. Thesecurity level 202 includes “unclassified” and “confidential”, and thesettlor level 203 includes, for example, “employee”, “group leader”, “section manager” and “department manager”. The format and the size of the label may be varied from one organization to another depending on the number of thesecurity levels 202, the size of the organization or other information to be added. The other information includes, for example, the term of validity of the label, the information on the person who has generated thefile 107 and the access control information (the read-only information, etc.). The access can be controlled using various information other than thesecurity level 202. - The
label management program 109 is for managing the label of thefile 107. In the case where theapplication program 103 accesses thefile 107, the label is removed and data (data body) other than the label is delivered to theapplication program 103. In the case where theapplication program 103 transmits thefile 107 to the in-house network 117 through the network I/F 112, on the other hand, thelabel management program 109 transmits thefile 107 with the label. - FIG. 3 is a flowchart for performing the process of opening the
file 107 located on themagnetic disk 106. “To open the file” is a pre-process making possible the operations including the reading of data in the file or the writing of data in the file. - In
step 301, theapplication program 103 issues a request for opening thefile 107 to thelabel management program 109 through the I/O manager of the operating system. - In
step 302, thelabel management program 109 acquires the process ID of theapplication program 103 through the I/O manager. The process is a unit of executing a program managed by the operating system and the process ID is defined as an identifier of the process. - In
step 303, thelabel management program 109 checks thesecurity level 202 of thefile 107. In the case where no label is attached to thefile 107, theparticular file 107 is determined as an “unclassified” file. Examples lacking the label are a system file and a driver file. - In
step 304, thelabel management program 109 checks the security level of theapplication program 103 from the process ID. Thelabel management program 109 checks the security level of theapplication program 103 by referring to theprocess management list 400 shown in FIG. 4. As of the time point when thefile 107 is not yet opened by theapplication program 103, the security level of theapplication program 103 is not yet set. - The requirements for the security level (the security level of the process in execution) of the application program are as follows. Specifically, the
application program 103 itself can handle files of various security levels. In the case where confidential files and unclassified files are handled at the same time, the confidential information may be written in an unclassified file (such as cut and paste). According to this embodiment, this risk is avoided by utilizing the security level of the process. - FIG. 4 shows a
process management list 400. The first column shows theprocess ID 401, the second column thesecurity level 402 of the particular process (security level of the application program), the third column thename 403 of the file opened, and the fourth column thesecurity level 404 of theparticular file 107. Theprocess management list 400 is prepared and initialized by alabel management program 109 at the time of loading thelabel management program 109. Also, thelabel management list 400 is updated by thelabel management program 109. - In
step 305, thelabel management program 109 checks whether thesecurity level 402 of theapplication program 103 has been set or not, and in the case where it has been set, the process proceeds to step 311, otherwise the process is passed to step 306. - In
step 306, thelabel management program 109 adds the process ID of theapplication program 103 to theprocess management list 400. - In
step 307, thelabel management program 109 sets theprocess security level 402 of theapplication program 103 to thesecurity level 202 of thefile 107. - In
step 308, thelabel management program 109 adds thefile name 403 and thesecurity level 202 of theparticular file 107 to theprocess management list 400. - In
step 309, thelabel management program 109 transmits a request to thefile system driver 104 to pen thefile 107. - In
step 310, the file is successfully opened. - In
step 311, thelabel management program 109 checks whether thesecurity level 402 of theapplication program 103 is coincident with thesecurity level 202 of thefile 107. In the case where they are coincident, the process proceeds to step 308, otherwise the process proceeds to step 312. - In
step 312, thelabel management program 109 displays a message for causing the user to determine whether thefile 107 is really to be opened or not. - In
step 313, the user decides whether thefile 107 is opened or not. In the case where the user decides to open thefile 107, the process proceeds to step 314, while in the case where the user decides not to open thefile 107, the process proceeds to step 315. - In
step 314, thelabel management program 109 checks whether thesecurity level 402 of theapplication program 103 is higher than thesecurity level 202 of thefile 107. In the case where thesecurity level 402 of theapplication program 103 is higher, the process proceeds to step 308, otherwise the process proceeds to step 307. - In
step 315, thelabel management program 109 transmits the open error message of thefile 107 to theapplication program 103. - In
step 316, the file fails to be open. - According to this embodiment, the
application program 103 can always open thefile 107 depending on the designation by the user. In the case where thesecurity level 402 of theapplication program 103 is not coincident with thesecurity level 202 of thefile 107 instep 311 of FIG. 3, however, the process may proceed to step 315 thereby to forcibly reject the file open request. - Also, at the time of preparing a new file, the user selects the
security level 202 of the same file. In the standard setting, thesecurity level 202 of the file is set equal to thesecurity level 402 of theapplication program 103. In the case where thesecurity level 402 of theapplication program 103 is “not yet set”, on the other hand, the highest “confidential” level is desirably selected. - FIG. 5 is a flowchart for performing the process of reading data from the
file 107 according to this embodiment. In this case, an explanation will be made about a case in which theapplication program 103 reads the byte offset 0×AB00 providing an address from the head of thefile 107, where 0× indicates a hexadecimal notation. - In
step 501, theapplication program 103 issues a request to read the data from the byte offset 0×AB00 of thefile 107. - In
step 502, thelabel management program 103 converts the byte offset 0×AB00 to the actual byte offset 0×AB04. According to this embodiment, thefile 107 carries the information (label) of four bytes (32 bits) at the head of thefile 107. Since theapplication program 103 is not informed of the presence of the label, however, the byte offset which theapplication program 103 requests to read is required to be adjusted. As a result, according to this embodiment, a value obtained by adding four bytes, i.e. the byte length of the label information to the byte offset requested by theapplication program 103 constitutes the actual byte offset. - In
step 503, thefile system driver 104 converts the actual byte offset 0×AB04 to the relative position on themagnetic disk 106. - In
step 504, thedisk driver 105 converts the relative position of themagnetic disk 106 to a physical position and reads the data into thememory 102. - FIG. 6 is a flowchart for performing the process of writing the data in the
file 107 according to this embodiment. As an example, an explanation will be made about a case in which theapplication program 103 writes into a specific byte offset 0×AB00 of the file. - In
step 601, theapplication program 103 issues a request to write the data in the byte offset 0×AB00 of thefile 107. - In
step 602, thelabel management program 109 checks thesecurity level 402 of theapplication program 103 and thesecurity level 202 of thefile 107. - In
step 603, thelabel management program 109 checks whether the security level of theapplication program 103 is coincident with that of thefile 107. In the case where they are coincident with each other, the process proceeds to step 605, otherwise the process proceeds to step 604. - In
step 605, thelabel management program 109 converts the byte offset 0×AB00 to the actual byte offset 0×AB04. As in the case where theapplication program 103 reads the data of thefile 107 as described above, a value obtained by adding four bytes to the byte offset requested by theapplication program 103 constitutes an actual byte offset. - In
step 606, thefile system driver 104 converts the actual byte offset 0×AB04 to the relative position on themagnetic disk 106. - In
step 607, thedisk driver 105 converts the relative position on themagnetic disk 106 to a physical position and transfers the data to themagnetic disk 106. - In
step 604, thelabel management program 109 changes thesecurity level 202 of thefile 107 to thesecurity level 402 of theapplication program 103, and further changes thesettlor level 203 and thesettlor ID 204, followed by proceeding to step 605. According to this embodiment, thesecurity level 202 of thefile 107 is changed to thesecurity level 402 of theapplication program 103 forcibly instep 604. As an alternative, however, a message may be displayed to permit the user to select thesecurity level 202 of thefile 107. - According to this embodiment, the
external storage unit 122 is arranged at theclient terminal 101, so that the data can be transferred to another terminal using theremovable media 123. As a result, the information is liable to leak out through the removable media. Thus, the data in theremovable media 123 is required to be protected from an illegal access from an external source. - FIG. 7 is a flowchart for performing the process of writing the
file 107 into theremovable media 123 according to this embodiment. In this case, an explanation will be made about a case in which theapplication program 103 prepares afile 124 anew and the data of thefile 107 is copied to thefile 124 thus prepared. The security level of thefile 124 is set by theapplication program 103 when the data is written in thefile 124. - In
step 701, theapplication program 103 issues a request to write the data of thefile 107 into thefile 124 in theremovable media 123. - In
step 702, thelabel management program 109 checks thesecurity level 202 of thefile 107. - In
step 703, whether thesecurity level 202 of thefile 107 is “confidential” or not is checked, and in the case where thesecurity level 202 is “unclassified”, the process proceeds to step 704, while in the case where the security level is “confidential”, the process proceeds to step 706. - In the case where the
security level 202 is “unclassified”, thelabel management program 109 issues a request to write the data other than the label of thefile 107 into thefile 124 in theremovable media 123 instep 704. - In
step 705, the write request is received by thefile system driver 104, and the data of thefile 107 is transferred to theremovable media 123 by thedisk driver 105. - In the case where the
security level 202 is “confidential”, an encryption key and a decryption key are generated by thelabel management program 109 instep 706. The encryption key and the decryption key may be identical to each other. - In
step 707, thelabel management program 109 registers the decryption key in thekey management server 114 and receives an identifier (ID number, for example) from thekey management server 114. - In
step 708, thelabel management program 109 encrypts thefile 107 using the encryption key, and prepares an encryption file. The encryption file includes the ID number and the encrypted data. The ID number is added by thelabel management program 109 at the time of preparing the encryption file. - In
step 709, thelabel management program 109 issues a request to write the data of the encryption file into thefile 124 in theremovable media 123, and the process proceeds to step 705. - In the case where the encrypted data in the existing
file 124 is updated, thelabel management program 109 transmits the ID number contained in thefile 124 to thekey management server 114, and receives the encryption key from thekey management server 114. Thelabel management program 109 encrypts the data using the encryption key thus received, and writes the encrypted data in thefile 124. - FIG. 8 is a flowchart for performing the process of reading the data from the
file 124 in theremovable media 123. - In
step 801, theapplication program 103 issues a request to thelabel management program 109 to read the data from thefile 124 in theremovable media 123. - In
step 802, thelabel management program 109 issues a request to thefile system driver 104 to read the data from thefile 124 in theremovable media 123. - In
step 803, thefile system driver 104 receives the read request, and thedisk driver 105 reads the data from thefile 124 in theremovable media 123. - In
step 804, thelabel management program 109 receives the data thus read out, and checks whether the particular data is encrypted or not. - In the case where the data is not encrypted, the process proceeds from
step 805 to step 806, while in the case where the data is encrypted, the process proceeds to step 807. - In
step 806, thelabel management program 109 delivers the data to theapplication program 103. - In
step 807, thelabel management program 109 reads the ID number of thefile 124. - In
step 808, thelabel management program 109 transmits the ID number of thefile 124 to thekey management server 114, and receives the decryption key for thefile 124. - In
step 809, thelabel management program 109 decrypts the encrypted data using the decryption key, and the process proceeds to step 806. - The data for the communication between the
client terminal 101 and thekey management server 114 instep 808 may be encrypted. - In the case where the data of the
file 124 on theremovable media 123 is copied or transferred to thefile 107 of themagnetic disk 106 with no label attached to thefile 124, thelabel management program 109 attaches the label “unclassified” to thefile 124 and stores it in themagnetic disk 106. - FIG. 9 is a flowchart for the
application program 103 performing the process of transmitting the file to thenetwork 117. - In
step 901, theapplication program 103 issues a request to transmit the file with a label. - In
step 902, thelabel management program 109 acquires thesecurity level 202 of thefile 107, and converts it to a request to transmit a labeled file. Theapplication program 103 outputs an unlabeled file data as data to be transmitted, and therefore thelabel management program 109 converts it to a labeled file. - In
step 903, theprotocol driver 110 divides the labeled file into packets, and prepares a packet header. - In
step 904, thenetwork adapter driver 111 transmits thefile 107 outside through a LAN controller. - Now, the security
level change program 108 will be explained. The securitylevel change program 108 is for changing thesecurity level 202 of thefile 107. FIG. 10 is a flowchart for performing the process of changing the “confidential”file 107 to an “unclassified” file. - In
step 1001, the securitylevel change program 108 issues a request to change thesecurity level 202 of thefile 107 from “confidential” to “unclassified”. - In
step 1002, thelabel management program 109 acquires thesettlor ID 204 by reading the label of thefile 107. - In
step 1003, it is determined whether thesettlor ID 204 acquired instep 1002 is coincident with the changer ID of thesecurity level 202. In the case of coincidence, the process proceeds to step 1004, otherwise the process proceeds to step 1005. - In
step 1004, thelabel management program 109 changes thesecurity level 202 of thefile 107 to “unclassified”, while at the same time changing thesettlor ID 204 and thesettlor level 203. - In
step 1005, it is determined whether the changer of thesecurity level 202 is authorized to change thesecurity level 202 or not. If the answer is affirmative, the process proceeds to step 1004, otherwise the process proceeds to step 1006. - In
step 1006, thelabel management program 109 delivers an error message to the securitylevel change program 108. - In
step 1005, the authorization to change thesecurity level 202 means the authorization to change thesecurity level 202 forcibly. This authorization can be set in such a manner that the change is possible in the case where the level granted an authorized person intending to change thesecurity level 202 is higher than thesettlor level 203 of thefile 107. Also, it is possible to set the authorization in such a manner that even a person authorized to change thesecurity level 202 cannot change thesecurity level 202 of all thefiles 107 unconditionally but may or may not change it depending on thesettlor ID 204. Alternatively, the policy of the authorization to change thesecurity level 202 may be set dividedly for each organization. The foregoing description concerns a case in which thesecurity level 202 is changed from “confidential” to “unclassified”. Nevertheless, three ormore security levels 202, if any, can be reduced by a similar method. - The security
level change program 108 can also increase thesecurity level 202 from the “unclassified”file 107 to the “confidential”file 107. Taking into consideration that the information leakage can be prevented by increasing thesecurity level 202, an arrangement can be made so that every person can unconditionally perform the operation of increasing thesecurity level 202. - The
transmission management program 119 checks the label of thefile 107 to be transmitted to theexternal network 121 by theclient terminal 101 and determines whether theparticular file 107 is to be transmitted or not. FIG. 11 is a flowchart for performing the process of checking the label. - In
step 1201, thegateway server 118 receives thefile 107 to be transmitted to theexternal network 121 from the in-house client terminal 101. - In
step 1202, thetransmission management program 119 decides whether a label is attached to thefile 107 or not. - In the case where the label is so attached, the process proceeds from
step 1203 to step 1204, otherwise the process proceeds to step 1209. - In
step 1204, thetransmission management program 119 checks thesecurity level 202 of thefile 107. - In the case where the
security level 202 of thefile 107 is “unclassified”, the process proceeds fromstep 1205 to step 1206, otherwise the process proceeds to step 1211. - In
step 1206, thetransmission management program 119 removes the label from thefile 107. - In
step 1207, thetransmission management program 119 transmits thefile 107 outside. - In step128, the file is transmitted successfully.
- In
step 1209, thetransmission management program 119 determines that thefile 107 is illegal data, and sends an error message to the transmitter terminal and the device used by the system manager. - In
step 1210, the file transmission ends in failure. - In
step 1211, thetransmission management program 119 sends to the transmitter terminal a message to the effect that thesecurity level 202 of thefile 107 is “confidential”. - In
step 1212, the file transmission ends in failure. - In
step 1206, the label is removed in order to follow the policy that the label can be interpreted only for other systems and terminals to which the system according to this embodiment is introduced. According to this embodiment, therefore, although the label is removed when the file is transmitted outside, the label can otherwise be handled as long as other policies are followed. - Also, according to this embodiment, with regard to the data transmitted outside of an organization, the label is removed after determining whether the data is to be transmitted to the
external network 121 on thegateway server 118. Therefore, the embodiment can be utilized transparently also for theexternal network 121. - Also, the
gateway server 118 is provided with a permitted transmittee list, so that thefile 107 can be transmitted to any external transmittee described in the permitted transmittee list even in the case where thesecurity level 202 is “confidential”. In such a case, thetransmission management program 119 encrypts thefile 107 and transmits thefile 107 without removing the label. Further, thetransmission management program 119 records the transmitter, the transmittee and the transmission file in a log. The encryption key is registered in thekey management server 114 in the same manner as in the case where thefile 107 is written in the removable media. Thefile 107 transmitted this way has an ID number and the encryption data. - Now, an explanation will be given of the process performed in the case where the
gateway server 118 receives thefile 107 from theexternal network 121. - First, the
gateway server 118 receives thefile 107 transmitted toward theclient terminal 101 from theexternal network 121. - Then, the receiving
management program 120 attaches the “unclassified” label to thefile 107. Also, thesettlor ID 204 is set as the ID for thegateway server 118, and thesettlor level 203 is set to the lowest level. - After that, the receiving
management program 120 transmits thefile 107 to theclient terminal 101. - The
receiving management program 120 may have the function of receiving the labeledfile 107. In such a case, the receivingmanagement program 120, after confirming that the label is attached, transmits thefile 107 to theclient terminal 101. - The authentication can be granted each other between terminals in the in-house network117 (between the
client terminals 101 or between aclient terminal 101 and the gateway server 118). The authentication between the terminals (101, 118, 114) is carried out by each terminal referring to a list (the communication permission list) held by it, which describes the MAC (Media Access Control) addresses of the terminals with which communication is permitted by each terminal. Each terminal can thus be controlled to carry out the communication only with a party whose MAC address (or the IP address) is found in the communication permission list. Alternatively, the communication between terminals can be permitted based not on the authentication granted by each terminal but on the authentication determined by an authentication server provided for this purpose. In such a case, each terminal conducts communication with another terminal through the authentication server. Also, the authentication between terminals may be granted using the public key encryption system. - Further, the authentication server may check the labels of all the files transmitted or received by the
client terminal 101 in communication with the parties in or outside an organization. Within each organization, thefile 107 may or may not be accessible depending on the title of an employee or the department of the organization to which the employee belongs. Even in such a case, the information flow can be controlled by the authentication server checking the labels. - (Second Embodiment)
- A second embodiment of the invention will be explained. According to the first embodiment, a label indicating the
security level 202 of thefile 107 is attached to thefile 107. In the second embodiment, on the other hand, the information flow is controlled using a securitylevel control list 1400 set in theclient terminal 101 without attaching the label to thefile 107 in theclient terminal 101, and in the case where thefile 107 is sent out of theclient terminal 101, the label is attached to it. The format of the label attached to thefile 107 sent out of theclient terminal 101 is similar to that for the first embodiment. - FIG. 12 shows the security
level control list 1400 according to this embodiment. The first column represents afile name 1401, the second column asecurity level 1402 of thefile 107, the third column asettlor level 1403 of thefile 107, and the fourth column asettlor ID 1404 of thefile 107. - An explanation will be given of the manner in which the
application program 103 accesses thefile 107 in themagnetic disk 106 in this embodiment. Unlike in the first embodiment, thefile 107 according to this embodiment is not labeled, and therefore the byte offset requested by theapplication program 103 is not required to be processed. For reading from thefile 107, thelabel management program 109 delivers the byte offset requested by theapplication program 103, directly to thefile system driver 104. - For the operation of writing into the
file 107, on the other hand, the same process as in FIG. 6 is performed except for the byte offset processing. Specifically, in response to the request of theapplication program 103 to write into thefile 107, thelabel management program 109 checks to see whether thesecurity level 402 of theapplication program 103 is coincident with thesecurity level 202 of thefile 107, and in the case of incoincidence, sets thesecurity level 202 of thefile 107 forcibly to thesecurity level 402 of theapplication program 103, while in the case of coincidence, transmits the request to write into thefile 107 to thefile system driver 104. - FIG. 13 is a flowchart for performing the process of writing data into the
file 107 of theremovable media 123. - In
step 1501, theapplication program 103 issues a request to write the data of thefile 107 into thefile 124 in theremovable media 123. - In
step 1502, thelabel management program 109 checks thesecurity level 202 of thefile 107. - In
step 1503, whether thesecurity level 202 is “confidential” or not is confirmed, and in the case where thesecurity level 202 is “unclassified”, the process proceeds to step 1504. In the case where thesecurity level 202 is “confidential”, on the other hand, the process proceeds to step 1506. - In the case where the
security level 202 is “unclassified”, thelabel management program 109 issues a request to write the data of thefile 107 into thefile 124 in theremovable media 123 of thefile 107 instep 1504. - In
step 1505, thefile system driver 104 receives the write request, and thedisk driver 105 transfers the data of thefile 107 to theremovable media 123. - In the case where the
security level 202 is “confidential”, thelabel management program 109 prepares a labeledfile 107 instep 1506. - In
step 1507, thelabel management program 109 generates an encryption key. - In
step 1508, thelabel management program 109 registers the encryption key in thekey management server 114 and receives an ID number from the server. - In
step 1509, thelabel management program 109 encrypts the labeledfile 107 using the encryption key thereby to prepare an encryption file. The encryption file includes an ID number and encrypted data. The ID number is added when thelabel management program 109 prepares the encryption file. - In
step 1510, thelabel management program 109 issues a request to write the data of the labeled encryption file into thefile 124 of theremovable media 123, and the process proceeds to step 1505. - According to this embodiment, the data is read from the
file 124 in theremovable media 123 in the same manner as in the first embodiment, as shown in FIG. 8. Also, in copying or transferring thefile 123 on theremovable media 123 to themagnetic disk 106, thelabel management program 109 adds thefile name 1401, thesecurity level 1402, thesettlor level 1403 and thesettlor ID 1404 of thefile 124 to the securitylevel control list 1400, and thus stores thefile 124 in themagnetic disk 106. - Now, the process of transmitting the file at the
client terminal 101 according to this embodiment will be explained with reference to FIG. 9. - In
step 901, theapplication program 103 issues a request to transmit thefile 107. According to this embodiment, prior to proceeding to step 902, a step is added for thelabel management program 109 to acquire thesecurity level 202 of thefile 107 and thereby to prepare a labeled file. The subsequent process is similar to that of the first embodiment, so that the process proceeds to step 902, in which thelabel management program 109 converts the transmission request of thefile 107 to the transmission request of the labeledfile 107. - In
step 903, theprotocol driver 110 divides the packet and prepares a packet header. - In
step 904, thenetwork adapter driver 111 transmits thefile 107 outside through a LAN controller. - Upon generation of a request to delete the
file 107, thelabel management program 109 transmits a request to delete thefile 107 to thefile system driver 104, and after receiving from the file system driver 104 a message to the effect that thefile 107 has been successfully deleted, deletes the row of thefile 107 from the securitylevel control list 1400. - Upon receipt of the
file 107 from anotherclient terminal 101 or thegateway server 118, thelabel management program 109 checks the label attached to the head of thefile 107 and registers the label information of thefile 107 in the securitylevel control list 1400. After that, thelabel management program 109 delivers thefile 107 to theapplication program 103. - The
security level 202 of thefile 107 is changed in such a manner that thelabel management program 109 receives a request to change thesecurity level 202 of thefile 107 from the securitylevel change program 108 and then changes the securitylevel control list 1400. Specifically, the processing flow shown in FIG. 10 is followed except that the securitylevel control list 1400 is used. - According to the first or second embodiment, the
security level 202 is set in thefile 107 and thereby the information flow can be controlled in the network. - (Third Embodiment)
- Now, an explanation will be given of a third embodiment capable of guaranteeing the legitimacy of the label and preventing the illegal alteration of the label.
- According to this embodiment, it is possible to prevent the illegal act in which a third party alters a label illegally and thus hides a person who has actually altered the label. As a specific example, an illegal act can be prevented in which a third party A alters a label illegally from the
file 107 labeled “confidential” to a file labeled “unclassified”, and further sets the settlor ID to the ID of another person B to show as if B has changed the security level. In this way, should the file 107 labeled “confidential” leak outside, the innocent B is prevented from being persecuted for the act. - FIG. 14 is a diagram showing a structure of the labeled
file 107 used in this embodiment. The labeledfile 107 includes alabel 1701 at the head thereof, followed by adata hash value 1702, alabel signature 1703, afile data 1704 and alink signature 1705. - The
data hash value 1702 is that of the file data as of the time point when the settlor himself of thesecurity level 202 prepares or corrects thefile 107 or changes thesecurity level 202. Thelabel signature 1703 is a digital signature attached by the settlor of thesecurity level 202 for thelabel 1701 and thedata hash value 1702. Thelink signature 1705, on the other hand, is a digital signature attached by the person who has prepared or changed thefile data 1704 for thelabel 1701 and thefile data 1704. - The
label signature 1703 guarantees the legitimacy of thelabel 1701, while thelink signature 1705 guarantees the legitimacy of thefile data 1704 and the legitimacy of the link between thefile data 1704 and thelabel 1701. The use of thelabel signature 1703 and thelink signature 1705 is effective for the investigation as to where the responsibility lies for any information leakage which may occur, while at the same time suppressing the illegal information leakage as the evidence is left. A different confidential key for the signature is desirably held by each different user. - This embodiment can be used as an extension of the first embodiment, in which case the file structure described above is used in and outside the
client terminal 101. In the case where this embodiment is used as an extension of the second embodiment, on the other hand, the file structure is used outside theclient terminal 101, while the column of thedata hash value 1702, thelabel signature 1703 and thelink signature 1705 is added to the securitylevel control list 1400 within theclient terminal 101, thereby assuring the legitimacy of the label information. - Now, this embodiment will be explained as an extension of the second embodiment of the invention.
- FIG. 15 is a flowchart for performing the process of writing data (file data1704) into the
file 107 according to this embodiment. - In
step 1801, theapplication program 103 issues a request to write the data (file data 1704) into thefile 107. - In
step 1802, thelabel management program 109 checks, with reference to theprocess management list 400 and the securitylevel control list 1400, whether thesecurity level 402 of theapplication program 103 coincides with thesecurity level 202 of thefile 107. - In the case where the
security level 202 of theapplication program 103 coincides with that of thefile 107 instep 1803, the process proceeds to step 1806, otherwise the process proceeds to step 1804. - In
step 1804, thelabel management program 109 changes thesecurity level 202 of thefile 107 to thesecurity level 402 of theapplication program 103, and further changes thesettlor level 203 and thesettlor ID 204. Instep 1805, thelabel management program 109 newly determines thedata hash value 1702, thelabel signature 1703 and thelink signature 1705, and then proceeds to step 1808. Under this condition, thedata hash value 1702 is that of thefile data 1704 after the change, and thelabel signature 1703 and thelink signature 1705 the signature of the party requesting to write into thefile 107. - In
step 1806, thelabel management program 109 checks whether the settlor of thesecurity level 202 of thefile 107 coincides with the party requesting to write into thefile 107, and in case of coincidence, the process proceeds to step 1805, otherwise the process proceeds to step 1807. - In
step 1807, thelabel management program 109 newly determines thelink signature 1705, which is the signature of the party requesting to write into thefile 107. - In
step 1808, thelabel management program 109 issues a request to thefile system driver 104 to write the newly acquired one of thedata hash value 1702, thelabel signature 1703 and thelink signature 1705 together with thefile data 1704 into thefile 107. - In
step 1809, the file system driver transmits the data to be written into the particular file, to the disk driver, which in turn writes the data in the magnetic disk. - An explanation will be made about the process performed at the
client terminal 101 for transmitting the labeledfile 107. First, thelabel management program 109 receives a file transmission request from theapplication program 103. Then, thelabel management program 109 converts the file transmission request from theapplication program 103 to the transmission request for the labeledfile 107. Specifically, the file structure transmitted from theclient terminal 101 is identical to the structure shown in FIG. 14. - FIG. 16 is a flowchart showing the process for performing the file receive operation at the
client terminal 101 according to this embodiment. - In
step 1901, thelabel management program 109 receives the labeledfile 107. - In
step 1902, thelabel management program 109 checks thelabel 1701 of the labeledfile 107. In the process, thelabel management program 109 verifies the legitimacy of thelabel 1701 based on thelabel signature 1703, and checks for the completeness of thefile data 1704 and the legitimacy of the link between thefile data 1704 and thelabel 1701 based on thelink signature 1705. - From
step 1903, the process proceeds to step 1904 in the case where the result of the check instep 1902 shows that thelabel 1701, thefile data 1704 and the link between thefile data 1704 and thelabel 1701 are correct, otherwise the process proceeds to step 1906. - In
step 1904, thelabel management program 109 adds the label information of the labeledfile 107 to the securitylevel control list 1400. - In
step 1905, thelabel management program 109 delivers the labeledfile 107 to theapplication program 103. - In
step 1906, thelabel management program 109 transmits the label information of the labeledfile 107 to the manager. - In
step 1907, thelabel management program 109 sends an error message to theapplication program 103. - Now, the process performed for changing the “confidential” labeled
file 107 to an “unclassified” file according to this embodiment will be explained with reference to FIG. 10. - In
step 1001, the securitylevel change program 108 issues a request to change thesecurity level 202 of the labeledfile 107 from “confidential” to “unclassified”. - In
step 1002, thelabel management program 109 acquires thesettlor ID 204 of the labeledfile 107 from the securitylevel control list 1400 according to this embodiment. - In
step 1003, it is determined whether thesettlor ID 204 acquired instep 1002 is coincident with the changer ID of thesecurity level 202. In the case of coincidence, the process proceeds to step 1004, otherwise the process proceeds to step 1005. - In
step 1004, thelabel management program 109 changes thesecurity level 202 of the labeledfile 107 to “unclassified”, while at the same time changing thesettlor ID 204 and thesettlor level 203. According to this embodiment, thelabel management program 109 further performs the process for newly acquiring thelabel signature 1703 and thelink signature 1705. - The process including and subsequent to step1005 is similar to that of the first embodiment. In
step 1005, it is determined whether the changer of thesecurity level 202 is authorized to change thesecurity level 202 or not. In the case where the changer is so authorized, the process proceeds to step 1004, otherwise the process proceeds to step 1006. - In
step 1006, thelabel management program 109 delivers an error message to the securitylevel change program 108. - This embodiment is described above referring to a case in which the
security level 202 is changed from “confidential” to “unclassified”. Nevertheless, thesecurity level 202 can be reduced by the same method also in the case where thesecurity level 202 includes three levels. - FIG. 17 is a flowchart for performing the process of checking the
label 1701 at thegateway server 118 according to this embodiment. - In
step 2101, thefile 107 transmitted outside of the in-house client terminal 101 is received. - In
step 2102, thetransmission management program 119 checks whether thelabel 1701 for thefile 107 is present or not. - In
step 2103, the process proceeds fromstep 2103 to step 2104 in the presence of thelabel 1701, otherwise the process proceeds to step 2111. - In
step 2104, thetransmission management program 119 checks thesecurity level 202 of the labeledfile 107. - In
step 2105, the process proceeds to step 2106 if thesecurity level 202 is “unclassified”, otherwise the process proceeds to step 2113. - In
step 2106, thetransmission management program 119 checks whether thelabel 1701 is complete or not. In the process, thetransmission management program 119 verifies the legitimacy of thelabel 1701 based on thelabel signature 1703, and checks both the completeness of thefile data 1704 and the legitimacy of the linkage between thefile data 1704 and thelabel 1701 based on thelink signature 1705. - From
step 2107, the process proceeds to step 2108 in the case where the check instep 2106 shows that the linkage is legitimate, otherwise the process proceeds to step 2115. - In
step 2108, thetransmission management program 119 removes thelabel 1701, thedata hash value 1702, thelabel signature 1703 and thelink signature 1705 from the labeledfile 107. - In
step 2109, thetransmission management program 119 transmits thefile 107 outside. - In
step 2110, the file is transmitted successfully. - In
step 2111, thetransmission management program 119 determines that thefile 107 is illegal data, and sends an error message to the transmitter terminal. - In
step 2112, the file transmission ends in failure. - In
step 2113, thetransmission management program 119 sends to the transmitter terminal a message to the effect that thesecurity level 202 of the labeledfile 107 is not “unclassified”. - In
step 2114, the file transmission ends in failure. - In
step 2115,transmission management program 119 sends to the transmitter terminal a message to the effect that the label of the labeledfile 107 is illegal. - In
step 2116, the file transmission ends in a failure. - Also, the
transmission management program 119 may store all the contents of the transmitter information and the transmittee information and the transmission file (the file having thelabel 1701, thedata hash value 1702, thelabel signature 1703 and the link signature 1705) in a log. - According to this embodiment, in the case where the
gateway server 118 receives thefile 107 transmitted toward theclient terminal 101 from theexternal network 121, the receivingmanagement program 120 attaches the “unclassified” label to thefile 107 and transmits thefile 107 to theclient terminal 101. In this case, thelabel settlor ID 204 is set to the ID of thegateway server 118, and thesettlor level 203 is set to the lowest level. Also, thelabel signature 1703 and thelink signature 1705 constitute the signature by thegateway server 118. - Further, the receiving
management program 120 may store in a log the transmitter information, the transmittee information of thefile 107 and all the contents of the received file. - (Fourth Embodiment)
- A fourth embodiment of the invention will be explained.
-
Various application programs 103 operate on a general-purpose computer. Also, various devices are connected and therefore the device drivers for operating these devices are in operation. As a result, in the case where each of the embodiments described above is implemented with a general-purpose computer, a bug of theapplication program 103 or the device driver and the operating error of the user may cause a change or a deletion of the label information (the security level control list 1400), thelabel management program 109 and theprocess management list 400. According to this embodiment, such an inconvenience can be avoided. - FIG. 18 shows an example of a configuration of the
client terminal 101 according to this embodiment. By replacing this client terminal with theclient terminal 101 shown in FIG. 1 and using each of the embodiments described above, the aforementioned effect of this embodiment can be achieved. - Two operating systems are working in the
client terminal 101, which has amemory area 2201 managed by the first operating system and amemory area 2202 managed by the second operating system. Further, a multiOS control programs 2204 for controlling the two operating systems are in operation. A multi OS control technique is disclosed in JP-A-11-149385. - Also, the
memory area 2201 managed by the first operating system has loaded therein anapplication program 103, a securitylevel change program 108, an I/O hook program 2203, afile system driver 104, adisk driver 105, aprotocol driver 110 and anetwork adapter driver 111. Further, the first operating system manages themagnetic disk 106 and the network I/F 112, and thefile 107 is stored in themagnetic disk 106. - The
label management program 109 and theprocess management list 400 are stored in thememory area 2202 managed by the second operating system. Also, the second operating system manages themagnetic disk 2205, which has stored therein the securitylevel control list 1400. - The I/
O hook program 2203 hooks the request for access to thefile 107 from theapplication program 103 or the securitylevel change program 108 or the request for transmission/receiving of thefile 107. Further, the I/O hook program 2203 has the function of requesting the processing of thelabel management program 109 and the function of receiving the result of processing of thelabel management program 109 and delivering the result of the processing to thefile system driver 104 or theprotocol driver 110. Specifically, the I/O hook program 2203 requests the processing of thelabel management program 109 utilizing the function of communication between the operating systems of a multiOS control programs 2204. The function of communication between the operating systems is disclosed, for example, in JP-A-11-85546. - According to this embodiment, the objects to be protected (
label management program 109, theprocess management list 400 and the security level control list 1400) are managed by the second operating system, so that protection is possible from the change due to the bug of theapplication program 103 or the device driver operating on the first operating system or the operating error of the user. - (Miscellaneous)
- According to each of the embodiments described above, not only the leakage of the in-house confidential information is prevented but also the leakage of the confidential information which otherwise might be caused by the illegal intrusion through the
external network 121 can be prevented. In the case where an illegal intruder attempts to take away a confidential file from theclient terminal 101 through thegateway server 118, thetransmission management program 119 of thegateway server 118 checks the label of the particular confidential file. In the case where the security level is “confidential”, thetransmission management program 119 rejects the transmission outside and therefore the leakage of the confidential file can be prevented. - Also, the
label management program 109 can attach a label “Untrusted” on an untrusted program (such as a program accompanying the mail) thereby to limit the files accessible. - Specifically, the “Untrusted” label is attached on a system file or a set information file of the kernel, so that in the case where the “Untrusted” program accesses a “Trusted” file, the
label management program 109 limits the access. This function can be realized by thelabel management program 109 checking the program and the file label when the file is open. By use of this function, the effect that a computer virus has on the system can be minimized. - Also, communication can be carried out between the
client terminal 101 and thegateway server 118 by use of a dedicated communication protocol. As a result, a label is attached on the header area of each packet, and thetransmission management program 119 of thegateway server 118 checks the label in the header area of the packet thereby to determine whether the data can be transmitted or not. In the case where the dedicated communication protocol is used for transmission of data to theexternal network 121, thetransmission management program 119 removes the label and converts it into a general-purpose communication protocol (TCP/IP, etc.). - Also, the labeled
file 107 is attached to the file attached to the electronic mail and transmitted, and thegateway server 121 checks the label of the file accompanying the mail, thereby making it possible to prevent the confidential file from leaking outside through electronic mail. As for the text of the mail, the leakage can be prevented by checking, using the keyword search, to see whether any keyword against the policy is included or not. - Also, a security level is set for each
client terminal 101, and further an intermediate server is provided between theclient terminals 101 on the one hand and between eachclient terminal 101 and each server on the other, so that the intermediate server may be equipped with the function of preventing the leakage of the information. In this case, the label need not be attached to thefile 107 on theclient terminal 101. - In this case, the intermediate server manages the security level of each
client terminal 101, and determines whether thefile 107 transmitted by theclient terminal 101 is allowed to be transmitted to anotherclient terminal 101 or another department or group. No label is attached in the case where the intermediate server transmits thefile 107 directly to theclient terminal 101, but the label is attached in the case where thefile 107 is transmitted to the intermediate server of another department or group. The intermediate server checks the label of thefile 107 received from another intermediate server, and when transmitting thefile 107 to theclient terminal 101, removes the label. The intermediate server may be arranged for each department or group. - By doing so, the
label management program 109 is not required to be incorporated in eachclient terminal 107, thereby making it possible to save the labor and trouble for introducing the function of information leakage prevention. - Thus, there is provided a system capable of preventing the leakage of a confidential file having an arbitrary format.
- It should be further understood by those skilled in the art that the foregoing description has been made on embodiments of the invention and that various changes and modifications may be made in the invention without departing from the spirit of the invention and the scope of the appended claims.
Claims (17)
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001370824A JP4051924B2 (en) | 2001-12-05 | 2001-12-05 | Network system capable of transmission control |
JP2001-370824 | 2001-12-05 |
Publications (2)
Publication Number | Publication Date |
---|---|
US20030105979A1 true US20030105979A1 (en) | 2003-06-05 |
US7047407B2 US7047407B2 (en) | 2006-05-16 |
Family
ID=19179986
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/074,239 Expired - Fee Related US7047407B2 (en) | 2001-12-05 | 2002-02-14 | Network system enabling transmission control |
Country Status (3)
Country | Link |
---|---|
US (1) | US7047407B2 (en) |
EP (1) | EP1318645A3 (en) |
JP (1) | JP4051924B2 (en) |
Cited By (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050251689A1 (en) * | 2004-05-04 | 2005-11-10 | Wen-Chieh Lee | Computer system for playing encrypted multimedia data and method for the same |
US20060033947A1 (en) * | 2004-08-10 | 2006-02-16 | Brother Kogyo Kabushiki Kaisha | Printing control device, printing system, program product, and printing control method |
US20080034439A1 (en) * | 2006-08-01 | 2008-02-07 | Weifeng Chen | Access control method and a system for privacy protection |
US20080126799A1 (en) * | 2006-11-29 | 2008-05-29 | The Boeing Company | Content based routing with high assurance mls |
US20080301799A1 (en) * | 2007-05-31 | 2008-12-04 | The Boeing Company | Method and apparatus for reliable, high speed data transfers in a high assurance multiple level secure environment |
US20090070466A1 (en) * | 2007-09-06 | 2009-03-12 | Secureaxis Software, Llc | System and Method for Securely Managing Data in a Client-Server Application Environment |
US20090077626A1 (en) * | 2006-04-18 | 2009-03-19 | Aiebus France | Method and device for communication on a communication link between an aircraft and a ground station |
US20090086252A1 (en) * | 2007-10-01 | 2009-04-02 | Mcafee, Inc | Method and system for policy based monitoring and blocking of printing activities on local and network printers |
US7529932B1 (en) * | 2008-03-31 | 2009-05-05 | International Business Machines Corporation | Removable medium and system and method for writing data to same |
US20090232300A1 (en) * | 2008-03-14 | 2009-09-17 | Mcafee, Inc. | Securing data using integrated host-based data loss agent with encryption detection |
US20090303083A1 (en) * | 2006-03-08 | 2009-12-10 | Airbus France | Method and device for detecting attempts at intruding on a communication link between an aircraft and a ground station |
US20100180339A1 (en) * | 2007-05-18 | 2010-07-15 | Secure Keys Pty Limited | Security token and system and method for generating and decoding the security token |
US20120140022A1 (en) * | 2010-12-06 | 2012-06-07 | Yoshinaga Kato | Apparatus, system, and method of managing data transmission, and transmission management program |
GB2493597A (en) * | 2011-06-17 | 2013-02-13 | Boeing Co | Multiple Independent Levels of Security (MILS) host with plura stack offload engines |
US20130055359A1 (en) * | 2010-06-25 | 2013-02-28 | Nec Corporation | Secret information leakage prevention system, secret information leakage prevention method and secret information leakage prevention program |
US8590002B1 (en) * | 2006-11-29 | 2013-11-19 | Mcafee Inc. | System, method and computer program product for maintaining a confidentiality of data on a network |
US8621008B2 (en) | 2007-04-26 | 2013-12-31 | Mcafee, Inc. | System, method and computer program product for performing an action based on an aspect of an electronic mail message thread |
US8677508B2 (en) | 2010-01-13 | 2014-03-18 | Nec Corporation | Confidential information leakage prevention system, confidential information leakage prevention method and confidential information leakage prevention program |
US8713468B2 (en) | 2008-08-06 | 2014-04-29 | Mcafee, Inc. | System, method, and computer program product for determining whether an electronic mail message is compliant with an etiquette policy |
US20140373108A1 (en) | 2007-12-14 | 2014-12-18 | Microsoft Corporation | Collaborative authoring modes |
US20150012978A1 (en) * | 2012-10-31 | 2015-01-08 | Zonggui Ke | System and Method for Isolating Mobile Data |
US9215197B2 (en) | 2007-08-17 | 2015-12-15 | Mcafee, Inc. | System, method, and computer program product for preventing image-related data loss |
US20160087843A1 (en) * | 2014-09-23 | 2016-03-24 | Vmware, Inc. | Host profiles in a storage area network (san) architecture |
US20160085964A1 (en) * | 2002-06-06 | 2016-03-24 | Google Inc. | Methods and Systems for Implementing a Secure Application Execution Environment Using Derived User Accounts for Internet Content |
US20160197885A1 (en) * | 2015-01-01 | 2016-07-07 | Bank Of America Corporation | Technology-agnostic application for high confidence exchange of data between an enterprise and third parties |
US9465508B1 (en) * | 2012-06-13 | 2016-10-11 | Rockwell Collins, Inc. | High assurance classification disambiguation of user input on tactical display systems |
US9547635B2 (en) | 2007-11-09 | 2017-01-17 | Microsoft Technology Licensing, Llc | Collaborative authoring |
US9565196B1 (en) * | 2015-11-24 | 2017-02-07 | International Business Machines Corporation | Trust level modifier |
US9712541B1 (en) | 2013-08-19 | 2017-07-18 | The Boeing Company | Host-to-host communication in a multilevel secure network |
US9760862B2 (en) | 2008-04-28 | 2017-09-12 | Microsoft Technology Licensing, Llc | Conflict resolution |
CN108133148A (en) * | 2017-12-22 | 2018-06-08 | 北京明朝万达科技股份有限公司 | Data safety inspection method and system |
US10198587B2 (en) | 2007-09-05 | 2019-02-05 | Mcafee, Llc | System, method, and computer program product for preventing access to data with respect to a data access attempt associated with a remote data sharing session |
US10601904B2 (en) * | 2014-09-25 | 2020-03-24 | Kabushiki Kaisha Toshiba | Cooperation system |
US11202187B2 (en) * | 2019-03-13 | 2021-12-14 | Whelen Engineering Company, Inc. | System and method for operating stealth mode of emergency vehicle |
US20210390197A1 (en) * | 2019-09-25 | 2021-12-16 | Hitachi, Ltd. | Computer System, Data Control Method, and Storage Medium |
Families Citing this family (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7519984B2 (en) * | 2002-06-27 | 2009-04-14 | International Business Machines Corporation | Method and apparatus for handling files containing confidential or sensitive information |
JP4537022B2 (en) * | 2003-07-09 | 2010-09-01 | 株式会社日立製作所 | A data processing method, a storage area control method, and a data processing system that limit data arrangement. |
JP4998518B2 (en) * | 2003-09-30 | 2012-08-15 | 大日本印刷株式会社 | Information processing apparatus, information processing system, and program |
JP2005128996A (en) | 2003-09-30 | 2005-05-19 | Dainippon Printing Co Ltd | Information processing apparatus and system, and program |
JP2005209181A (en) * | 2003-12-25 | 2005-08-04 | Sorun Corp | File management system and management method |
JP4676779B2 (en) * | 2004-04-02 | 2011-04-27 | 株式会社リコー | Information processing device, resource management device, attribute change permission determination method, attribute change permission determination program, and recording medium |
JP2006048193A (en) * | 2004-08-02 | 2006-02-16 | Meta Protocol Kk | Network system and its document management method |
JP4539240B2 (en) * | 2004-09-01 | 2010-09-08 | 日本電気株式会社 | File management system and file management server |
US8776206B1 (en) * | 2004-10-18 | 2014-07-08 | Gtb Technologies, Inc. | Method, a system, and an apparatus for content security in computer networks |
JP2007013506A (en) * | 2005-06-29 | 2007-01-18 | N-Crypt Inc | Encryption processor, encryption method, decryption processor, decryption method and data structure |
JP4671340B2 (en) * | 2005-07-12 | 2011-04-13 | 株式会社日立ソリューションズ | How to save / read data from / to external storage media |
US7783896B2 (en) * | 2005-09-06 | 2010-08-24 | Research In Motion Limited | System and method for management of plaintext data in a mobile data processing device |
JP4489676B2 (en) | 2005-09-28 | 2010-06-23 | 富士通株式会社 | Communications system |
US8028908B2 (en) | 2006-05-01 | 2011-10-04 | Patrick Shomo | Systems and methods for the secure control of data within heterogeneous systems and networks |
TWI325113B (en) * | 2006-10-13 | 2010-05-21 | Data security device and the method thereof | |
JP4853240B2 (en) * | 2006-11-07 | 2012-01-11 | 富士ゼロックス株式会社 | Image processing system and program |
JP5142067B2 (en) * | 2006-11-14 | 2013-02-13 | 富士ゼロックス株式会社 | Document processing system, document processing apparatus, mail server, and program |
FR2914805A1 (en) * | 2007-04-03 | 2008-10-10 | Thales Sa | ARCHITECTURE OF AN OPEN LOCAL NETWORK AUDIO SERVICE SUPPORT BETWEEN IP USERS BELONGING TO CLOSED DOMAINS |
JP2008287609A (en) * | 2007-05-21 | 2008-11-27 | Oki Electric Ind Co Ltd | Mail management system |
JP5211557B2 (en) * | 2007-06-15 | 2013-06-12 | 富士通株式会社 | Web conference support program, recording medium recording the program, Web conference support device, and Web conference support method |
JP5011136B2 (en) * | 2008-01-21 | 2012-08-29 | 株式会社日立製作所 | Information leak detection system |
JP5130081B2 (en) * | 2008-02-29 | 2013-01-30 | 富士通フロンテック株式会社 | Control device and image data display method |
US8301588B2 (en) | 2008-03-07 | 2012-10-30 | Microsoft Corporation | Data storage for file updates |
US8825594B2 (en) * | 2008-05-08 | 2014-09-02 | Microsoft Corporation | Caching infrastructure |
US8429753B2 (en) * | 2008-05-08 | 2013-04-23 | Microsoft Corporation | Controlling access to documents using file locks |
WO2009147855A1 (en) * | 2008-06-03 | 2009-12-10 | 株式会社 日立製作所 | File management system |
US8132004B2 (en) * | 2008-06-12 | 2012-03-06 | The Boeing Company | Multiple independent levels of security containing multi-level security interface |
US8417666B2 (en) * | 2008-06-25 | 2013-04-09 | Microsoft Corporation | Structured coauthoring |
US20100131836A1 (en) * | 2008-11-24 | 2010-05-27 | Microsoft Corporation | User-authored notes on shared documents |
US8346768B2 (en) * | 2009-04-30 | 2013-01-01 | Microsoft Corporation | Fast merge support for legacy documents |
KR20110011797A (en) | 2009-07-29 | 2011-02-09 | 엘지전자 주식회사 | Apparatus and method of setting e-mail security |
US8458718B2 (en) | 2009-08-27 | 2013-06-04 | The Boeing Company | Statically partitioning into fixed and independent systems with fixed processing core |
US8479260B2 (en) | 2009-12-21 | 2013-07-02 | The Boeing Company | Multi-level security controls system |
US20120291106A1 (en) * | 2010-01-19 | 2012-11-15 | Nec Corporation | Confidential information leakage prevention system, confidential information leakage prevention method, and confidential information leakage prevention program |
US20110219424A1 (en) * | 2010-03-05 | 2011-09-08 | Microsoft Corporation | Information protection using zones |
US9838349B2 (en) | 2010-03-08 | 2017-12-05 | Microsoft Technology Licensing, Llc | Zone classification of electronic mail messages |
JP6705695B2 (en) * | 2016-05-19 | 2020-06-03 | 株式会社日立製作所 | File management system and method |
EP3923612A1 (en) * | 2020-06-09 | 2021-12-15 | Deutsche Telekom AG | Method and communication system for ensuring secure communication in a zero touch connectivity-environment |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5577209A (en) * | 1991-07-11 | 1996-11-19 | Itt Corporation | Apparatus and method for providing multi-level security for communication among computers and terminals on a network |
US5680452A (en) * | 1993-10-18 | 1997-10-21 | Tecsec Inc. | Distributed cryptographic object method |
US6317435B1 (en) * | 1999-03-08 | 2001-11-13 | Qualcomm Incorporated | Method and apparatus for maximizing the use of available capacity in a communication system |
US6772419B1 (en) * | 1997-09-12 | 2004-08-03 | Hitachi, Ltd. | Multi OS configuration system having an interrupt process program executes independently of operation of the multi OS |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08204701A (en) | 1995-01-26 | 1996-08-09 | Nippon Telegr & Teleph Corp <Ntt> | Electronic mail cipher communication system and cipher communication method |
US5802320A (en) | 1995-05-18 | 1998-09-01 | Sun Microsystems, Inc. | System for packet filtering of data packets at a computer network interface |
JP3831990B2 (en) | 1996-10-04 | 2006-10-11 | 株式会社日立製作所 | Communication data audit method and apparatus |
JP3546678B2 (en) | 1997-09-12 | 2004-07-28 | 株式会社日立製作所 | Multi-OS configuration method |
JPH1185546A (en) | 1997-09-12 | 1999-03-30 | Hitachi Ltd | Inter-process communicating method on heterogeneous os |
US6304973B1 (en) | 1998-08-06 | 2001-10-16 | Cryptek Secure Communications, Llc | Multi-level security network system |
-
2001
- 2001-12-05 JP JP2001370824A patent/JP4051924B2/en not_active Expired - Fee Related
-
2002
- 2002-02-14 US US10/074,239 patent/US7047407B2/en not_active Expired - Fee Related
- 2002-02-15 EP EP02003597A patent/EP1318645A3/en not_active Withdrawn
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5577209A (en) * | 1991-07-11 | 1996-11-19 | Itt Corporation | Apparatus and method for providing multi-level security for communication among computers and terminals on a network |
US5940591A (en) * | 1991-07-11 | 1999-08-17 | Itt Corporation | Apparatus and method for providing network security |
US5680452A (en) * | 1993-10-18 | 1997-10-21 | Tecsec Inc. | Distributed cryptographic object method |
US6772419B1 (en) * | 1997-09-12 | 2004-08-03 | Hitachi, Ltd. | Multi OS configuration system having an interrupt process program executes independently of operation of the multi OS |
US6317435B1 (en) * | 1999-03-08 | 2001-11-13 | Qualcomm Incorporated | Method and apparatus for maximizing the use of available capacity in a communication system |
Cited By (68)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10133864B2 (en) * | 2002-06-06 | 2018-11-20 | Google Llc | Methods and systems for implementing a secure application execution environment using derived user accounts for internet content |
US10922403B1 (en) * | 2002-06-06 | 2021-02-16 | Google Llc | Methods and systems for implementing a secure application execution environment using derived user accounts for internet content |
US20160085964A1 (en) * | 2002-06-06 | 2016-03-24 | Google Inc. | Methods and Systems for Implementing a Secure Application Execution Environment Using Derived User Accounts for Internet Content |
US20050251689A1 (en) * | 2004-05-04 | 2005-11-10 | Wen-Chieh Lee | Computer system for playing encrypted multimedia data and method for the same |
US20060033947A1 (en) * | 2004-08-10 | 2006-02-16 | Brother Kogyo Kabushiki Kaisha | Printing control device, printing system, program product, and printing control method |
US7768665B2 (en) * | 2004-08-10 | 2010-08-03 | Brother Kogyo Kabushiki Kaisha | Printing control device for processing a spool file and printing system, program product, and printing control method associated therewith |
US8350725B2 (en) * | 2006-03-08 | 2013-01-08 | Airbus Operations (S.A.S.) | Method and device for detecting attempts at intruding on a communication link between an aircraft and a ground station |
US20090303083A1 (en) * | 2006-03-08 | 2009-12-10 | Airbus France | Method and device for detecting attempts at intruding on a communication link between an aircraft and a ground station |
US20090077626A1 (en) * | 2006-04-18 | 2009-03-19 | Aiebus France | Method and device for communication on a communication link between an aircraft and a ground station |
US8856523B2 (en) * | 2006-04-18 | 2014-10-07 | Airbus Operations Sas | Method and device for communication on a communication link between an aircraft and a ground station |
US20080034439A1 (en) * | 2006-08-01 | 2008-02-07 | Weifeng Chen | Access control method and a system for privacy protection |
US8020213B2 (en) * | 2006-08-01 | 2011-09-13 | International Business Machines Corporation | Access control method and a system for privacy protection |
US8032924B2 (en) | 2006-08-01 | 2011-10-04 | International Business Machines Corporation | Access control method and a system for privacy protection |
US20090064343A1 (en) * | 2006-08-01 | 2009-03-05 | Weifeng Chen | Access control method and a system for privacy protection |
US20080126799A1 (en) * | 2006-11-29 | 2008-05-29 | The Boeing Company | Content based routing with high assurance mls |
US8590002B1 (en) * | 2006-11-29 | 2013-11-19 | Mcafee Inc. | System, method and computer program product for maintaining a confidentiality of data on a network |
US8250360B2 (en) * | 2006-11-29 | 2012-08-21 | The Boeing Company | Content based routing with high assurance MLS |
US8943158B2 (en) | 2007-04-26 | 2015-01-27 | Mcafee, Inc. | System, method and computer program product for performing an action based on an aspect of an electronic mail message thread |
US8621008B2 (en) | 2007-04-26 | 2013-12-31 | Mcafee, Inc. | System, method and computer program product for performing an action based on an aspect of an electronic mail message thread |
US20100180339A1 (en) * | 2007-05-18 | 2010-07-15 | Secure Keys Pty Limited | Security token and system and method for generating and decoding the security token |
US8752207B2 (en) * | 2007-05-18 | 2014-06-10 | Secure Keys Pty Limited | Security token and system and method for generating and decoding the security token |
US8024788B2 (en) * | 2007-05-31 | 2011-09-20 | The Boeing Company | Method and apparatus for reliable, high speed data transfers in a high assurance multiple level secure environment |
US20080301799A1 (en) * | 2007-05-31 | 2008-12-04 | The Boeing Company | Method and apparatus for reliable, high speed data transfers in a high assurance multiple level secure environment |
US10489606B2 (en) | 2007-08-17 | 2019-11-26 | Mcafee, Llc | System, method, and computer program product for preventing image-related data loss |
US9215197B2 (en) | 2007-08-17 | 2015-12-15 | Mcafee, Inc. | System, method, and computer program product for preventing image-related data loss |
US10198587B2 (en) | 2007-09-05 | 2019-02-05 | Mcafee, Llc | System, method, and computer program product for preventing access to data with respect to a data access attempt associated with a remote data sharing session |
US11645404B2 (en) | 2007-09-05 | 2023-05-09 | Mcafee, Llc | System, method, and computer program product for preventing access to data with respect to a data access attempt associated with a remote data sharing session |
US20090070466A1 (en) * | 2007-09-06 | 2009-03-12 | Secureaxis Software, Llc | System and Method for Securely Managing Data in a Client-Server Application Environment |
US8446607B2 (en) | 2007-10-01 | 2013-05-21 | Mcafee, Inc. | Method and system for policy based monitoring and blocking of printing activities on local and network printers |
US20090086252A1 (en) * | 2007-10-01 | 2009-04-02 | Mcafee, Inc | Method and system for policy based monitoring and blocking of printing activities on local and network printers |
US9547635B2 (en) | 2007-11-09 | 2017-01-17 | Microsoft Technology Licensing, Llc | Collaborative authoring |
US10394941B2 (en) | 2007-11-09 | 2019-08-27 | Microsoft Technology Licensing, Llc | Collaborative authoring |
US10057226B2 (en) | 2007-12-14 | 2018-08-21 | Microsoft Technology Licensing, Llc | Collaborative authoring modes |
US20140373108A1 (en) | 2007-12-14 | 2014-12-18 | Microsoft Corporation | Collaborative authoring modes |
US20090232300A1 (en) * | 2008-03-14 | 2009-09-17 | Mcafee, Inc. | Securing data using integrated host-based data loss agent with encryption detection |
US8893285B2 (en) | 2008-03-14 | 2014-11-18 | Mcafee, Inc. | Securing data using integrated host-based data loss agent with encryption detection |
US9843564B2 (en) | 2008-03-14 | 2017-12-12 | Mcafee, Inc. | Securing data using integrated host-based data loss agent with encryption detection |
US7529932B1 (en) * | 2008-03-31 | 2009-05-05 | International Business Machines Corporation | Removable medium and system and method for writing data to same |
US9760862B2 (en) | 2008-04-28 | 2017-09-12 | Microsoft Technology Licensing, Llc | Conflict resolution |
US9077684B1 (en) | 2008-08-06 | 2015-07-07 | Mcafee, Inc. | System, method, and computer program product for determining whether an electronic mail message is compliant with an etiquette policy |
US8713468B2 (en) | 2008-08-06 | 2014-04-29 | Mcafee, Inc. | System, method, and computer program product for determining whether an electronic mail message is compliant with an etiquette policy |
US9531656B2 (en) | 2008-08-06 | 2016-12-27 | Mcafee, Inc. | System, method, and computer program product for determining whether an electronic mail message is compliant with an etiquette policy |
US8677508B2 (en) | 2010-01-13 | 2014-03-18 | Nec Corporation | Confidential information leakage prevention system, confidential information leakage prevention method and confidential information leakage prevention program |
US9076011B2 (en) * | 2010-06-25 | 2015-07-07 | Nec Corporation | Secret information leakage prevention system, secret information leakage prevention method and secret information leakage prevention program |
US20130055359A1 (en) * | 2010-06-25 | 2013-02-28 | Nec Corporation | Secret information leakage prevention system, secret information leakage prevention method and secret information leakage prevention program |
US9197855B2 (en) | 2010-12-06 | 2015-11-24 | Ricoh Company, Ltd. | Apparatus, system, and method of managing data transmission, and transmission management program |
US8665312B2 (en) * | 2010-12-06 | 2014-03-04 | Ricoh Company, Ltd. | Apparatus, system, and method of managing data transmission, and transmission management program |
US20120140022A1 (en) * | 2010-12-06 | 2012-06-07 | Yoshinaga Kato | Apparatus, system, and method of managing data transmission, and transmission management program |
US8990560B2 (en) | 2011-06-17 | 2015-03-24 | The Boeing Company | Multiple independent levels of security (MILS) host to multilevel secure (MLS) offload communications unit |
GB2493597A (en) * | 2011-06-17 | 2013-02-13 | Boeing Co | Multiple Independent Levels of Security (MILS) host with plura stack offload engines |
GB2493597B (en) * | 2011-06-17 | 2013-09-04 | Boeing Co | Multiple independent levels of security (mils) host to multilevel secure (mls) offload communications unit |
US9465508B1 (en) * | 2012-06-13 | 2016-10-11 | Rockwell Collins, Inc. | High assurance classification disambiguation of user input on tactical display systems |
US9350736B2 (en) * | 2012-10-31 | 2016-05-24 | Bluedon Information Security Technology Corporation, Ltd. | System and method for isolating mobile data |
US20150012978A1 (en) * | 2012-10-31 | 2015-01-08 | Zonggui Ke | System and Method for Isolating Mobile Data |
US9712541B1 (en) | 2013-08-19 | 2017-07-18 | The Boeing Company | Host-to-host communication in a multilevel secure network |
US10038596B2 (en) * | 2014-09-23 | 2018-07-31 | Vmware, Inc. | Host profiles in a storage area network (SAN) architecture |
US20160087843A1 (en) * | 2014-09-23 | 2016-03-24 | Vmware, Inc. | Host profiles in a storage area network (san) architecture |
US10601904B2 (en) * | 2014-09-25 | 2020-03-24 | Kabushiki Kaisha Toshiba | Cooperation system |
US20160197885A1 (en) * | 2015-01-01 | 2016-07-07 | Bank Of America Corporation | Technology-agnostic application for high confidence exchange of data between an enterprise and third parties |
US9716692B2 (en) * | 2015-01-01 | 2017-07-25 | Bank Of America Corporation | Technology-agnostic application for high confidence exchange of data between an enterprise and third parties |
US9654514B1 (en) | 2015-11-24 | 2017-05-16 | International Business Machines Corporation | Trust level modifier |
US9565196B1 (en) * | 2015-11-24 | 2017-02-07 | International Business Machines Corporation | Trust level modifier |
US9635058B1 (en) | 2015-11-24 | 2017-04-25 | International Business Machines Corporation | Trust level modifier |
CN108133148A (en) * | 2017-12-22 | 2018-06-08 | 北京明朝万达科技股份有限公司 | Data safety inspection method and system |
US11202187B2 (en) * | 2019-03-13 | 2021-12-14 | Whelen Engineering Company, Inc. | System and method for operating stealth mode of emergency vehicle |
US20220103996A1 (en) * | 2019-03-13 | 2022-03-31 | Whelen Engineering Company, Inc. | System and method for operating stealth mode of emergency vehicle |
US20210390197A1 (en) * | 2019-09-25 | 2021-12-16 | Hitachi, Ltd. | Computer System, Data Control Method, and Storage Medium |
US12099621B2 (en) * | 2019-09-25 | 2024-09-24 | Hitachi, Ltd. | Computer system, data control method, and storage medium |
Also Published As
Publication number | Publication date |
---|---|
EP1318645A3 (en) | 2005-04-20 |
US7047407B2 (en) | 2006-05-16 |
JP4051924B2 (en) | 2008-02-27 |
JP2003173284A (en) | 2003-06-20 |
EP1318645A2 (en) | 2003-06-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7047407B2 (en) | Network system enabling transmission control | |
JP4667361B2 (en) | Adaptive transparent encryption | |
US7587749B2 (en) | Computer method and apparatus for managing data objects in a distributed context | |
US8213620B1 (en) | Method for managing cryptographic information | |
JP5270694B2 (en) | Client computer, server computer thereof, method and computer program for protecting confidential file | |
US9197668B2 (en) | Access control to files based on source information | |
KR100930018B1 (en) | Digital Information Security System, Kernel Driver Device, and Digital Information Security Method | |
US20170118214A1 (en) | Method and architecture for providing access to secured data from non-secured clients | |
US20030200459A1 (en) | Method and system for protecting documents while maintaining their editability | |
US20050273600A1 (en) | Method and system for file data access within a secure environment | |
US20030023559A1 (en) | Method for securing digital information and system therefor | |
US20100185852A1 (en) | Encryption and decryption method for shared encrypted file | |
CN110352413B (en) | Policy-based real-time data file access control method and system | |
US20030208686A1 (en) | Method of data protection | |
RU2463721C2 (en) | Method of sending electronic file | |
JP2003228519A (en) | Method and architecture for providing pervasive security for digital asset | |
KR20100039359A (en) | System and method of transparent aware data transformation at file system level | |
GB2371888A (en) | A printer device capable of decrypting digital document files and method of securely communicating electronic files over a network | |
US6272639B1 (en) | Mixed enclave operation in a computer network | |
JP4201556B2 (en) | Information processing method and access authority management method in center system | |
JPH09251426A (en) | File ciphering system and its control method, and cipher file reception system and its control method | |
US20050038790A1 (en) | Device and method for establishing a security policy in a distributed system | |
US20030033303A1 (en) | System and method for restricting access to secured data | |
JP2008160485A (en) | Document management system, document managing method, document management server, work terminal, and program | |
US20080059794A1 (en) | Method, apparatus and computer readable medium for secure conversion of confidential files |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HITACHI, LTD., JAPAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ITOH, SHINJI;MIYAZAKI, KUNIHIKO;ECHIZEN, ISAO;REEL/FRAME:013105/0121 Effective date: 20020610 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
REMI | Maintenance fee reminder mailed | ||
LAPS | Lapse for failure to pay maintenance fees | ||
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20140516 |