JP2013109553A - Program white list distribution device and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a mechanism related to an optimum white list management method in a malware analysis detection system.SOLUTION: A white list distribution device 110 for creating and returning a white list with a high probability of being included in a client terminal on the basis of a suspicious file transmitted from a user on the client terminal has a known non-malware DB 241 in which known non-malware files are registered, and optimizes a white list to be distributed to each client terminal using the type of the client terminal and a relation DB 242 of correlation between packages or the like by creating the white list on the basis of the known non-malware DB 241.

Description

  The present invention relates to a technique for filtering known non-malware using a white list as a countermeasure against malware infection.

  Malware is a type of computer program that, when executed in a computer terminal, performs activities harmful to the user, such as file deletion and information leakage. A terminal on which malware is executed is generally called a malware-infected terminal. Today, thousands to tens of thousands of new types of malware appear every day, and the establishment of anti-malware measures has become a major social problem.

  As a countermeasure against malware infection, a black list method by pattern file matching is generally used in each client terminal, and many anti-virus software are currently distributed in the market.

  However, many anti-virus software uses a blacklist method, which makes it difficult to detect new types of malware. As a countermeasure against a new type of malware, there is a malware analysis server that analyzes the behavior of a program in detail using a dedicated computer environment as in Patent Document 1 to determine whether it is malware or not.

  Since analysis by the malware analysis server takes time, it is inefficient to analyze all the files in the client terminal. For this reason, the client terminal holds a white list that is a list of known non-malware, and only a program that is not on the white list is analyzed by the malware analysis server.

  As a problem in whitelist filtering, it is inefficient to maintain a large-scale whitelist in a client terminal in terms of search time and storage capacity. For this reason, in Patent Document 2, when a file to be analyzed is found in a client terminal, an inquiry for file matching is made to a whitelist distribution server holding a large-scale whitelist, and the whitelist distribution server Only the files that are not retained are analyzed by the malware analysis server. If the file is held in the server, it is registered in the white list on the client terminal side, and no further inquiry is generated.

JP 2009-37545 A JP 2010-198054 A

  However, this method has a problem that the processing load of the client terminal / whitelist distribution server increases because communication with the whitelist distribution server occurs each time a new file is discovered. Further, when a user uses a plurality of types of client terminals, even if the user uses the same application or program package at each terminal, a collation inquiry is performed for each client terminal, which is inefficient.

  An object of the present invention is to provide a program whitelist distribution apparatus and method that enables efficient filtering of known non-malware and enables efficient operation of a malware analysis system.

  When receiving a request from a client terminal, the whitelist distribution server determines the type of client terminal (PC, mobile terminal), the correlation between packages (which application and which application are often used the same), etc. Based on the above information, a file list that is highly likely to exist in the client terminal of the inquiry source is created and distributed as a white list to each client terminal.

  According to the present invention, efficient filtering of known non-malware becomes possible, and efficient operation of a malware analysis system becomes possible.

It is a figure which shows the structure of the white list optimization system concerning this embodiment. It is a figure which shows the main physical structures of a white list delivery server. It is a figure which shows the functional structure of a white list delivery server, and the relationship with each physical apparatus. It is a figure which shows the main physical structures of a fixed terminal and a mobile terminal. It is a figure which shows the functional structure of a fixed terminal and a mobile terminal, and the relationship with each physical apparatus. It is a figure which shows the example of the record in non-malware file DB. It is a figure which shows the example of the record in package correlation DB. It is a figure which shows the example of the record in user management DB. It is a figure which shows the example of the record in local white list DB. It is a flowchart of the process in a white list construction part. It is a flowchart of the process in a white list delivery part. It is a flowchart of the process in a false positive file transmission part. It is a flowchart of the process in a white list request | requirement part.

  Embodiments will be described below in detail with reference to the accompanying drawings. In the description, an information processing device, a host, and a terminal are used as synonymous terms.

  FIG. 1 is a diagram showing a configuration of a whitelist optimization system 10 according to the present embodiment. As shown in FIG. 1, the whitelist optimization system 10 includes a whitelist distribution server 110, a fixed terminal 120, a mobile terminal 130, and a network 100. The network 100 includes a WAN (Wide Area Network), the Internet, and the like in addition to a relatively small network managed by an organizational unit such as a company or an educational institution such as a LAN (Local Area Network).

  The fixed terminal 120 includes a desktop type or notebook PC type terminal used in an office or home such as a company or an educational institution, and the mobile terminal 130 includes a tablet PC, a smartphone, a portable terminal, or the like other than the fixed terminal.

  FIG. 2 is a diagram illustrating a main physical configuration of the white list distribution server 110. As shown in FIG. 2, the white list distribution server 110 physically includes a main device 110 and an input / output device 230. The input / output device 230 includes a display device such as a display and an input device such as a keyboard. The input / output device 230 displays a user instruction or a result of processing performed by a CPU (Central Processing Unit) 210 of the main body device 110 described later. indicate.

  Note that the input device and the output device of the input / output device 230 may actually be separate, but the processing performed by each of these devices is not a major part, and thus these are collectively shown as the input / output device 230. ing. In the following description, the result of processing performed by the CPU 210 is described on the assumption that the input / output device 230 is displayed. However, for example, it may be displayed on another device connected via the network 100.

  The main device 110 includes a CPU 210, a memory 220, a storage device 240, an interface 250, and a bus 260.

  The CPU 210 includes an arithmetic device such as a processor, and controls the execution of the white list distribution program 221 that distributes the white list and the operation of each device included in the main body device 110. The CPU 210 has a clock for posting a clock inside.

  The memory 220 includes a storage medium such as a RAM (Random Access Memory) and a ROM (Read Only Memory). A white list distribution program 221 is stored in advance in the ROM. Then, the program 221 is executed by the CPU 210 to distribute the white list. Specific functions executed by the CPU 210 will be described later.

  The storage device 240 is composed of an HDD (Hard Disk Drive) or the like, and stores a non-malware file DB 241, a package correlation DB 242, and a user management DB 243. The non-malware file DB 241 stores information on so-called non-malware file names, hash values, and packages containing files that have been confirmed not to be malware. In the package correlation DB 242, for one two packages, when one package is installed on the client terminal, the ratio of the other package installed is shown. The user management DB 243 stores packages installed in client terminals held by each user. Specific contents of these DBs will be described later.

  The interface 250 includes a NIC (Network Interface Card) or the like, and mediates communication from the fixed terminal 120 and the mobile terminal 130 to the main device 110.

  The bus 260 connects each device included in the main device 110 and exchanges various data between these devices.

  FIG. 3 is a diagram illustrating a functional configuration of the main device 110 illustrated in FIG. 2 and a relationship with each physical device. As shown in FIG. 3, the CPU 210 includes a white list construction unit 310 and a white list distribution unit 320. The functions of these units are realized by the execution of the white list distribution program 221 by the CPU 210.

  The white list construction unit 310 acquires a false positive file (a suspicious file that may be malware) from the fixed terminal 120 or the mobile terminal 130 and confirms whether or not the file is registered in the non-malware file DB 241. If registered, the package information including the file is registered in the user management DB 243. Further, a whitelist is added to files in a package including a file acquired from a user and files included in a package that is likely to exist in the client terminal in which the package is stored with reference to the package correlation DB 242 Delivered as a message.

  The white list distribution unit 320 receives a white list distribution request from the fixed terminal 120 or the mobile terminal 130, acquires a package to be distributed from the user management DB 243, and includes a file included in the package from the non-malware file DB 241. Deliver additional messages.

  FIG. 4 is a diagram illustrating main physical configurations of the fixed terminal 120 and the mobile terminal 130. As shown in FIG. 4, the fixed terminal 120 and the mobile terminal 130 are physically configured to include main body devices 120 and 130 and an input / output device 430. The input / output device 430 includes a display device such as a display and an input device such as a keyboard. The input / output device 430 includes a user instruction or a result of processing performed by a CPU (Central Processing Unit) 410 of the main body devices 120 and 130 described later. Etc. are displayed.

  Note that the input device and output device of the input / output device 430 may actually be separate, but the processing performed by each of these devices is not a major part, so they are collectively shown as the input / output device 430. ing. In the following description, the result of processing performed by the CPU 410 is described on the assumption that it is displayed on the input / output device 430. However, it may be displayed on another device connected by the network 100, for example.

  The main body devices 120 and 130 include a CPU 410, a memory 420, a storage device 440, an interface 450, and a bus 460.

  The CPU 410 includes an arithmetic device such as a processor, and controls the execution of a false positive file transmission program 421 that transmits a false positive file and the operation of each device included in the main body devices 120 and 130. The CPU 410 has a clock for posting a clock inside.

  The memory 420 includes a storage medium such as a RAM (Random Access Memory) and a ROM (Read Only Memory). The ROM stores a false positive file transmission program 421 in advance. The program 421 is executed by the CPU 410 to transmit a false positive file. Specific functions executed by the CPU 410 will be described later.

  The storage device 440 includes an HDD (Hard Disk Drive) or the like, and stores a local white list DB 441. Specific contents of this DB will be described later.

  The interface 450 includes a NIC (Network Interface Card) or the like, and mediates communication from the whitelist distribution server 110 to the fixed terminal 120 and the mobile terminal 130.

  The bus 460 connects the devices included in the main body devices 120 and 130 and exchanges various data between these devices.

  FIG. 5 is a diagram illustrating a functional configuration of the fixed terminal 120 and the mobile terminal 130 and a relationship with each physical device. As shown in FIG. 5, the CPU 410 includes a false positive file transmission unit 510 and a white list request unit 520. The functions of these units are realized by the execution of the false positive file transmission program 221 by the CPU 410. The false positive file transmission unit 510 confirms whether the false positive file detected from the detection results in the main body terminals 120 and 130 is registered in the local whitelist DB 441, and if not registered, transmits the false positive file to the whitelist distribution server 110. . The white list request unit 520 adds the white list addition message received from the white list distribution server 110 to the local white list DB 441.

  FIG. 6 is a diagram illustrating an example of records in the non-malware file DB 241. Each record records information about one known non-malware. The file name 601 indicates the file name, the package 602 indicates the package including the file, and the type 603 indicates the type of the terminal in which the file is installed (in FIG. 6, either a fixed terminal or a mobile terminal). A hash value 604 indicates a hash value of the file data.

  In general, each package 602 has a different file structure depending on the type of terminal used. For this reason, even if the fixed terminal and the mobile terminal use the same package 602, the files installed in each terminal are different. In the example of FIG. 6, File-A, File-B, and File-C belong to the same package, Pack-X. Of these, File-A and File-B are installed when Pack-X is used in a fixed terminal. On the other hand, File-C is installed when Pack-X is used in a mobile terminal.

  When registering a record in the non-malware file DB 241, information on a file that is determined to be non-malware provided by an external organization such as a security vendor is used.

  FIG. 7 is a diagram illustrating an example of records in the package correlation DB 242. Package (1) 701 and package (2) 702 are correlated packages, and correlation value 703 indicates the correlation between each package (1) 701 and package (2) 702. The higher the correlation value 703, the higher the possibility that the package (2) 702 is installed in the package in which the package (1) 701 is installed. The value of the correlation value 703 takes a range from 0.0 to 1.0.

  In the example of FIG. 7, the package (1) 701 is Pack-X and Pack-Y, the package (2) 702 is Pack-Y and Pack-Z, and the correlation values 703 are 0.9, 0.5, and 0.3.

  When the package names described in the package (1) 701 and the package (2) 702 are interchanged, the correlation value 703 may be the same or different. For example, in the example of FIG. 7, when the value of the package (1) 701 is Pack-X and the value of the package (2) 702 is Pack-Y, the correlation value 703 is 0.9, but the package (1) 701 When the value of Package-Y is Pack-Y and the value of Package (2) 702 is Pack-X, the correlation value 703 is 0.1.

  Registration of the correlation value 703 is performed by the administrator of the white list distribution server 110.

  FIG. 8 is a diagram illustrating an example of records in the user management DB 243. A user 801 indicates a name for uniquely identifying the user, and a package 802 indicates a list of packages used by the user. In the example of FIG. 8, the users 801: S and 801: T use Pack-X and Pack-Y. User 801: U uses Pack-Z.

  FIG. 9 is a diagram illustrating an example of a record in the local white list DB 441. A file path 901 indicates a file path indicating a storage destination of the non-malware file in the client terminal, and a hash value 902 indicates a hash value of the file data. In the example of FIG. 9, the file path 901 is C: \ Program \ a.exe and the hash value 902 is xxxx, the file path 901 is C: \ temp \ b.exe, and the hash value 902 is yyyy. There is a record. The file path 901 and the hash value 902 are registered based on a white list addition message from the white list distribution server 110.

  FIG. 10 is a flowchart of processing in the white list construction unit 310. The white list construction unit 310 receives a user name, a terminal type, and a false positive file from the fixed terminal 120 and the mobile terminal 130 (step 31001). Here, it is assumed that S is received as the user name and File-A is received as the fixed terminal false positive file as the terminal type.

  Next, it is confirmed whether or not the received file, that is, the acquired false positive file is registered in the non-malware file DB 241 (step 31002). If the false positive file is not registered in the non-malware file DB 241, the process ends (step 31002: NO). On the other hand, when the false positive file is registered in the non-malware file DB 241, the processing is continued (step 31003: YES). Since File-A is registered in the non-malware file DB of FIG. 6, the processing continues.

  Next, a package including a false positive file is acquired from the non-malware file DB 241 (step 31003). Here, it is assumed that Pack-X is acquired as a package including File-A. Next, the non-malware file DB 241 acquires a file that is included in the package acquired in step 31003 and whose type is the same as the received type information (step 31004). Here, File-B, which is included in Pack-X and whose type is a fixed terminal, is acquired.

  Next, a package whose correlation with the package acquired in step 310003 is greater than or equal to a threshold is acquired from the package correlation DB 242 (step 31005). The threshold value is arbitrarily set by the administrator. Here, it is assumed that the threshold value is 0.8 and Pack-Y is acquired as a package having a high correlation with Pack-X. Next, a file that is included in the package acquired in step 31005 and whose type is the same as the received type information is acquired (step 31006). Here, File-D, which is included in Pack-Y and whose type is a fixed terminal, is acquired.

  Next, a package for each user is set in the user registration DB 243 (step 31007). Here, Pack-X and Pack-Y are set as the packages of user S.

  Finally, the received file and the file name and hash value acquired in step 31004 and step 31006 are returned to the client terminal as a white list addition message (step 31008). Here, the file names and hash values of File-A, File-B, and File-D are returned as a white list addition message.

  FIG. 11 is a flowchart of processing in the white list distribution unit 320. The white list distribution unit 320 receives a white list distribution request from the fixed terminal 120 and the mobile terminal 130 (step 32001). Here, it is assumed that the user S receives a distribution request whose type is a mobile terminal.

  Next, the package of the user who has been distributed is acquired from the user registration DB 243 (step 32002). Here, it is assumed that the package, Pack-X, and Pack-Y of the user S are acquired.

  Next, a file that is included in the package acquired in step 32002 and whose type matches the distribution request is acquired from the non-malware file DB (step 32003). Here, it is assumed that File-C is acquired as a file that is included in Pack-X or Pack-Y and whose type is a mobile terminal.

  Finally, a white list notification message including the file name and hash value of the file acquired in step 32003 is transmitted to the requesting client terminal, and the process ends (step 32004). Here, a white list addition message including the file name and hash value of File-C is transmitted to the mobile terminal of user S.

  FIG. 12 is a flowchart of processing in the false positive file transmission unit 510 in the client terminal. The false positive file transmission unit 510 searches the client terminal 130 and detects a false positive file (step 51001).

  Next, it is confirmed whether a false positive file is registered in the local white list DB 441 (step 51002). If the false positive file has already been registered in the local whitelist DB 441, the process ends (step 51002: YES). On the other hand, if the false positive file is not registered in the local whitelist DB 441, the processing is continued (step 51002: NO).

  Next, the file path, hash value, and type of the false positive file are transmitted to the white list distribution server 110 (step 51003).

  Next, a white list addition message is received from the white list distribution server 110 (step 51004). Finally, the file name and hash value in the white list addition message received in step 51004 are added to the local white list DB 441, and the process ends (step 51005).

  FIG. 13 is a flowchart of processing in the white list request unit 520. The white list request unit 520 makes a white list distribution request to the white list distribution server 110 (step 52001).

  Next, a white list addition message is received from the white list distribution server 110 (step 52002). Finally, the white list is added to the local white list DB 441 based on the white list addition message received in step 52002, and the process is terminated (step 52003).

10: White list optimization system, 110: White list is a new server, 120: Fixed terminal, 130: Mobile terminal, 100: Network

Claims (11)

Based on the false positive file transmitted from the user on the client terminal, the white list distribution device that creates and returns a white list with high accuracy included in the client terminal,
A known non-malware DB in which known non-malware files are registered;
A white list distribution apparatus comprising: a white list construction unit that creates the white list list based on the known non-malware DB.   2. The white list according to claim 1, wherein a package of the known non-malware file is registered in the known non-malware DB, and the white list construction unit creates the white list based on the package. List distribution device.   The whitelist distribution apparatus according to claim 2, wherein the whitelist construction unit includes a file included in the same package as the false positive file in the whitelist.   Between two types of packages, when one package exists in the client terminal, the package correlation DB holds a possibility that the other package exists in the client terminal as a correlation value, and 4. The white list distribution device according to claim 3, wherein the white list construction unit creates the white list based on the package correlation DB.   5. The white list distribution according to claim 4, wherein the white list construction unit includes, in the white list, a file included in a package having a correlation value with a package including the false positive file equal to or greater than a predetermined value. apparatus.   In the known non-malware DB, a type of a terminal on which the known non-malware file is installed is registered, and the white list construction unit constructs the white list based on the type. The white list distribution device according to claim 5.   The whitelist distribution apparatus according to claim 6, wherein the whitelist construction unit includes a file whose type is the same as the type of the client terminal that has transmitted the false positive file in the whitelist.   The white list construction unit registers a list of packages including the false positive file, a list of packages having a correlation value with the package equal to or greater than a predetermined value, and a correspondence between the users in a user management DB. The white list distribution device according to claim 7.   9. The white list distribution apparatus according to claim 8, further comprising a white list distribution unit that receives a white list distribution request from the client terminal and creates and distributes the white list corresponding to the client terminal.   The white list distribution unit acquires a package owned by the user included in the white list distribution request from the user management DB, and among the files in the package included in the known non-malware DB, the white list 10. The white list distribution device according to claim 9, wherein a file having the same type as that included in the distribution request is distributed as the white list. Using the information processing apparatus, based on the false positive file transmitted from the user on the client terminal, a whitelist distribution method for creating and returning a whitelist list with high accuracy included in the client terminal is:
Holds a known non-malware DB with registered packages of known non-malware files,
White list construction means for creating the white list list by including in the white list a file included in the same package as the false positive file based on the package of the known non-malware DB. Whitelist delivery method to do.

Images