Information processing system

Abstract

To reduce time and labor of a manager etc. related to maintenance of a white list.SOLUTION: An information processing system includes a server device 20 holding a list 20G used in execution control of a white list or black list type application, and a client terminal device 10 which acquires the list 20G and performs execution control of an application, wherein the server device 20 updates the list 20G on the basis of vulnerability information acquired from a disclosed vulnerability information database, or a behavior detection result of a process acquired from a client terminal device 10 to which the list 20G is transmitted.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an information processing system that controls application execution using a whitelist or blacklist method. [Background technology]

[0002] Conventionally, whitelist-based application control has been able to prevent damage caused by dangerous applications such as malware by whitelisting applications that have been confirmed to be safe and allowing only applications on the list to operate.

[0003] It creates a whitelist based on the hash value of the application file and controls the launch of applications based on this, thereby preventing the execution of unknown processes, including malware. [Prior art documents] [Patent documents]

[0004] Patent Document 1: JP 2021-51634 A Summary of the Invention [Problem to be solved by the invention]

[0005] However, since applications registered on the whitelist remain on the list and are generally allowed to launch, if a vulnerability is discovered in an application that was not problematic when it was registered on the whitelist, continuing to allow it to run could put it at risk of being exploited and becoming a target of a cyber attack. For this reason, administrators have had to regularly maintain the whitelist. [Means for solving the problem]

[0006] In view of the above, the information processing system of the present invention comprises: An information processing system including a server device that holds a list used in controlling the execution of a whitelist or blacklist type application, and a client terminal device that acquires the list and controls the execution of the application, The server device is characterized in that it updates the list based on vulnerability information obtained from a publicly available vulnerability information database or process behavior detection results obtained from a client terminal device to which the list is sent. [Effects of the Invention]

[0007] According to the present invention, it is possible to reduce the work of an administrator and the like involved in maintaining a list used in controlling the execution of an application. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a system configuration diagram of an information processing system according to a first embodiment. [Figure 2] An example of a 10G whitelist. [Figure 3] An example of a 20G whitelist. [Figure 4] An example of vulnerability information 50. [Figure 5] 4 is a flowchart of processing in the client terminal device 10. [Figure 6] Flowchart of processing in the server device 20 [Figure 7] 10 is a flowchart of another process in the server device 20. [Figure 8] FIG. 10 is a system configuration diagram of an information processing system according to a second embodiment. [Figure 9] 10 is a flowchart of another process in the client terminal device 10. [Figure 10] An example of vulnerable process information. [Figure 11] 10 is a flowchart of another process in the server device 20. [Figure 12] 10 is an example of a whitelist 10G stored on a client terminal 10. [Figure 13] 10 shows an example of a whitelist 20G stored on the server device 20. [Figure 14] Flowchart of other processing in the client terminal device 10 [Figure 15] 10 is a flowchart of another process in the server device 20. [Figure 16] 10 is a flowchart of another process in the server device 20. [Figure 17] An example of a confirmation dialog. DETAILED DESCRIPTION OF THE INVENTION

[0009] [Embodiment 1] <System configuration diagram> First, the configuration of an information processing system according to this embodiment will be described with reference to the system configuration diagram of Fig. 1. As shown in Fig. 1, the information processing system according to this embodiment has computers, i.e., information processing devices 10, each of which is connected to a network 30 such as a LAN or the Internet. Hereinafter, the information processing devices 10 will be referred to as client terminal devices. Note that there may be multiple client terminal devices 10. Furthermore, the client terminal device 10 may be any device that is capable of executing the processes described below as being performed by an information processing device such as a PC or mobile terminal device.

[0010] In addition, in this embodiment, the explanation will be given on the assumption that there are a plurality of client terminal devices 10, each of which is connected via a network 30.

[0011] <Client terminal device> In the client terminal device 10, the arithmetic unit 10C is a microprocessor (CPU). The arithmetic unit 10C starts an operating system (OS) stored in the storage device 10B in accordance with a boot program such as BIOS stored in the ROM included in the memory 10E, and then starts various programs in accordance with the OS or user operations. This storage device 10B stores computer programs and data for causing the arithmetic unit 10C to execute the OS and various processes performed by this device, which will be described later. These computer programs include a client program 10F.

[0012] The computer programs and data stored in the storage device 10B are loaded into the RAM included in the memory 10E as appropriate under the control of the arithmetic device 10C, and are then processed by the arithmetic device 10C. The OS may be, for example, Windows (registered trademark), MacOS (registered trademark), Linux (registered trademark), iOS (registered trademark), Android (registered trademark), or the like.

[0013] The storage device 10B is a hard disk drive (HDD) or a solid state drive (SSD), and stores the OS as well as the client program 10F running on the client terminal device 10. The I / O device 10A is an input / output interface (I / F) for connecting to a pointing device (such as a mouse) or a keyboard, or a display incorporating a touch panel. The keyboard may be a software keyboard. The I / O device 10A may also be a voice-based input unit including a microphone, which recognizes the operator's voice input using a voice recognition function and transmits the recognized voice to the arithmetic device 10C. The I / O device 10A also functions as a user interface (UI) for displaying information.

[0014] The network I / F 10D is an interface with the network 30 and is a communication circuit for communicating with other information processing devices (for example, the server device 20, etc.). The computing device 10C may, for example, download part or all of the information in the whitelist 20G from the server device 20, or may send a request packet to an external site on the Internet, via the network I / F 10D.

[0015] The client program 10F is a program for monitoring and controlling the start of programs in the client terminal device 10, etc.

[0016] For example, when an arbitrary program is attempted to be launched on the client terminal device 10, the device has the function of calculating information to identify the program (such as a hash value) and comparing it with information in the whitelist 10G to determine whether or not the program can be launched and to control it.

[0017] The whitelist 10G is data that lists programs that may be started under whitelist control, and is held in the client terminal device 10.

[0018] Figure 2 is an example of a 10G whitelist. In Figure 2, programs registered as whitelisted are registered. This figure shows examples of the program name, hash value (a value calculated using an algorithm such as SHA-2 based on the binary of the program file), and digital signature added to the program file.

[0019] Note that the information shown in FIG. 2 is merely an example and does not limit the information to be recorded, and information not shown in FIG. 2 may be recorded.

[0020] <Server device> In the server device 20, the arithmetic device 20C is a microprocessor (CPU). The arithmetic device 20C starts an operating system (OS) stored in the storage device 20B in accordance with a boot program such as BIOS stored in the ROM included in the memory 20E, and then starts various programs in accordance with the OS or user operations. This storage device 20B stores computer programs and data for causing the arithmetic device 20C to execute the OS and various processes to be performed by this device, which will be described later. These computer programs include a server program 20F.

[0021] The server program 20F is a program for managing data, programs, etc. of the server device 20, and has functions such as recording data received from the client terminal device 10 in the memory device 20B and calculating arbitrary data in the calculation device 20C.

[0022] The computer programs and data stored in the storage device 20B are loaded into the RAM of the memory 20E as appropriate under the control of the arithmetic device 20C, and are then processed by the arithmetic device 20C. The OS may be, for example, Windows (registered trademark), MacOS (registered trademark), Linux (registered trademark), iOS (registered trademark), Android (registered trademark), or the like.

[0023] The storage device 20B is a hard disk drive (HDD) or a solid state drive (SSD), and stores the OS as well as the server program 20F running on the server device 20. The I / O device 20A is an input / output interface (I / F) for connecting to a pointing device (such as a mouse) or a keyboard, or a display incorporating a touch panel. The keyboard may be a software keyboard. The I / O device 20A may also be a voice-based input unit including a microphone, which recognizes the operator's voice input using a voice recognition function and transmits the recognized voice to the arithmetic device 20C. The I / O device 20A also functions as a user interface (UI) for displaying information.

[0024] The network I / F 20D is an interface with the network 30 and is a communication circuit for communicating with other information processing devices (for example, the client terminal device 10, etc.). The arithmetic device 20C processes a download request for data such as a whitelist from the network I / F 10D of the client terminal device 10, for example, via the network I / F 20D.

[0025] The server program 20F also has a function of acquiring vulnerability information related to applications from a vulnerability database 50 on the Internet, comparing product information such as the product name and manufacturer contained in the vulnerability information with the same information recorded on the whitelist 20G, and determining whether a vulnerable process is registered on the whitelist 20G. At the same time, the server program 20F has a function of deleting a process determined to be vulnerable from the whitelist 20G.

[0026] In this embodiment, publicly available vulnerability information such as CVE is searched for, and related applications are extracted from the vulnerability information hits (the trigger for acquiring information may be a timer, such as once a day, or the process may be triggered by a notification from an external service that issues an emergency alert when new vulnerability information is published).

[0027] As will be explained in detail later, the whitelist is checked to see if any applications with vulnerabilities are included. If it is confirmed that a vulnerable application is registered on the whitelist, the application is removed from the whitelist (or a suggestion is displayed that allows the administrator to choose whether to remove the application).

[0028] This allows whitelist updates to be performed without burdening administrators, and can prevent cyberattacks caused by applications in which new vulnerabilities are discovered while the whitelist is in operation.

[0029] Figure 4 shows an example of a vulnerability database 50 based on vulnerability information. This figure shows an example that includes information such as vulnerability number, product name (application name), manufacturer, and process version. Note that the information shown in Figure 4 is merely an example and does not limit the information to be recorded; information not shown in Figure 4 may also be recorded.

[0030] The whitelist 20G is data that lists programs (processes) that may be started under whitelist control, and is held in the server device 20.

[0031] Figure 3 is an example of whitelist 20G. In Figure 3, programs registered as whitelists are registered. This figure shows examples of program names, hash values, digital signatures added to program files, manufacturers, product names, and versions.

[0032] Note that the information shown in FIG. 3 is merely an example and does not limit the information to be recorded, and information not shown in FIG. 3 may be recorded.

[0033] Comparing Figure 2, which shows the whitelist 10G on the client terminal device 10 side, with Figure 3, which shows the whitelist 20G on the server device 20 side, we see that the whitelist 20G on the server device 20 side encompasses the whitelist 10G on the client terminal device 10 side, which means that only the information necessary for control on the client 10 side is passed on to avoid unnecessary use of network bandwidth due to communication. However, this is just one example, and the information passed on is not limited to this; all of the information on the whitelist 20G held by the server device 20 may be passed on.

[0034] The processing flow is described below.

[0035] <Whitelist download process> In order to control the start of processes using a whitelist on the client terminal device 10, it is first necessary to prepare a whitelist 10G on the client terminal device 10.

[0036] FIG. 7 is a flowchart showing the flow of processing performed by the server device 20 when the client terminal device 10 transmits a download request for a whitelist to the server device 20.

[0037] First, the server program 20F receives a download request for a whitelist from the client terminal device 10 via the network 30 and the network I / F 20D (S-701).

[0038] The timing at which the client terminal device 10 issues a download request for the whitelist may be any timing, such as when the user logs in to the client terminal device 10, or at regular time intervals, such as every five minutes.

[0039] Next, the server program 20F converts the whitelist 20G into a format to be passed to the client terminal device 10 (S-702).

[0040] The format to be passed to the client terminal device 10 refers to selecting only the minimum amount of data required to control the startup of a process in the client terminal device 10 from the whitelist 20G, as described below, and converting it into a whitelist format that contains only that data. For example, if only a "hash value" and a "signer name" are used for control, only the relevant two types of data are selected from the whitelist 20G and converted into a whitelist format that contains only those two types of data. Note that the converted format is essentially the same as the whitelist 10G in the client terminal device 10.

[0041] Finally, the server program 20F transmits the converted whitelist to the client terminal device 10 via the network 30 and the network I / F 20D.

[0042] By this process, the whitelist 10G is placed in the client terminal device 10.

[0043] <Process startup control processing on client terminal device> FIG. 5 is a flowchart showing the flow of processing in the client terminal device 10.

[0044] First, when the client terminal device 10 is started, the client program 10F is started and monitors the start of a process on the terminal (S-501).

[0045] Next, when the start of a process is detected (S-502), the client program 10F calculates the hash of the process (S-503). A commonly known algorithm such as SHA-2 is used to calculate the hash.

[0046] Once the hash is calculated, check whether the record with that hash value is registered in the whitelist (S-504).

[0047] By identifying processes by hash, it is possible to identify different process entities even if they have the same process name, and this makes it possible to prevent the process from starting even if an attacker attempts to replace an existing application process with malware.

[0048] If it is registered, the client program 10F allows the process to be started (S-507).

[0049] If it is not registered, the client program 10F acquires the digital signature attached to the process (S-505).

[0050] Next, the client program 10F checks whether a record having the same signer name as the acquired signer name is registered on the whitelist 10G (S-506).

[0051] If it is registered, the client program 10F allows the process to be started (S-507).

[0052] If the process is not registered, the client program 10F prohibits the process from starting (S-508).

[0053] By performing such processing, the client terminal device 10 is only allowed to launch processes registered in the whitelist 10G, thereby suppressing the activity of malware and other programs not included in the whitelist 10G and ensuring security.

[0054] In the above flowchart, the "hash value" and "signer name" of the whitelist 10G are used to determine whether to allow or prohibit launch, but the types and number of elements used for the determination are not limited to this. For example, the determination may include whether the "process name" matches, or the determination may be made based on the hash value alone.

[0055] <Updating the whitelist or suggestion processing on the server device> As described above, the client terminal device 10 uses the whitelist to control the start of processes, while the server device 20 updates the whitelist to be passed to the client terminal device 10 based on vulnerability information.

[0056] FIG. 6 is a flowchart showing the flow of processing in the server device 20.

[0057] First, the server program 20F acquires vulnerability information from the vulnerability database 50 on the Internet via the network 30 and the network I / F 20D (S-601).

[0058] The timing for processing S-601 can be set to a predetermined time and performed periodically, such as once a day, or it can be triggered by a notification from an external service that notifies users when new vulnerability information is registered.

[0059] Next, the server program 20F acquires the data of the whitelist 20G (S-602).

[0060] Next, the server program 20F determines whether or not the process corresponding to the product in the vulnerability information is registered in the whitelist 20G.

[0061] First, the server program 20F searches the whitelist 20G using the "product name" as a key (S-603).

[0062] For example, if vulnerability information like that shown in Figure 4 is obtained and the whitelist 20G is as shown in Figure 3, it will be found that vulnerabilities exist in two products, "Notepad" and "PC Health Check," and that products with the same names are also registered in the whitelist.

[0063] Next, the server program 20F checks whether the "version" of the corresponding whitelist matches the vulnerability information (S-604).

[0064] Here, it can be seen that "Notepad" is the version that has the vulnerability. Furthermore, for "PC Health Check," different versions of the same product are registered on the whitelist, but only version "12.0.8" of them has the vulnerability. Therefore, since the vulnerable product is registered on whitelist 20G and it is determined that it is dangerous to allow the product to start as is, server program 20F deletes the records of "Notepad" and "PC Health Check" with version "12.0.8" from whitelist 20G. Alternatively, it notifies the administrator that a vulnerable process is registered on the whitelist (S-605).

[0065] In S-605, if you prioritize eliminating the hassle of updating the whitelist, you can set it to delete processes automatically. Alternatively, if you adhere to a policy that requires administrators to update the whitelist, you can avoid automatic deletion and set it to notify the administrator, allowing the administrator to manually delete the process from Whitelist 20G. Even in this case, the administrator only needs to check the processes for which they received this notification, reducing the maintenance effort.

[0066] As a result, the "PC Health Check" for the non-vulnerable version "13.0.1" will continue to be allowed to launch, minimizing the impact on business operations compared to measures that prohibit execution on a product-by-product basis.

[0067] This series of processes deletes the record of the specific version of the vulnerable product from the whitelist 20G, prohibiting its activation on the client terminal device 10 and preventing attacks that exploit the vulnerability.

[0068] [Embodiment 2] In the first embodiment, vulnerability information was obtained from an online vulnerability database, and the whitelist was updated based on that information. However, there is generally a time lag of several days to several months between when a vulnerability is actually confirmed and when it is registered. Therefore, this embodiment is intended to block attacks that exploit vulnerabilities during that period (generally called zero-day attacks). Generally, antivirus software uses a technology that detects malware by performing pattern matching based on virus definition files. However, there is also known a technology (called a behavior detection or heuristic type) that monitors the behavior of applications (processes) and, if the behavior of an attack that exploits a vulnerability is detected, forcibly terminates the process in question to block the attack.

[0069] By using this technology to monitor process behavior and detecting an actual attack that exploits a vulnerability, the process can be removed from the whitelist, preventing zero-day attacks.

[0070] The configuration of the information processing system according to this embodiment will be described using the system configuration diagram in Fig. 8. Note that since the second embodiment is based on the configuration of the first embodiment, only the differences will be described, and the same components will be designated by the same reference numerals and their description will be omitted.

[0071] [Configuration differences] In this embodiment, a behavior detection unit 10H is installed in the client terminal device 10. The behavior detection unit 10H has a function of monitoring whether a process running on the client terminal device 10 has been attacked by exploiting a vulnerability.

[0072] <Behavior detection on client terminal devices> FIG. 9 is a flowchart of a process for monitoring whether an attack exploiting a vulnerability has been carried out on the client terminal device 10. In FIG.

[0073] When the client terminal device 10 is started, the behavior detection unit 10H is also started at the same time to monitor the behavior of the processes on the client terminal device 10 (S-901).

[0074] When the behavior detection unit 10H detects an attack that exploits a vulnerability, the behavior detection unit 10H notifies the client program 10F that a vulnerability attack has occurred and provides information about the attack (such as the attack pattern) (S-902, S-903). Examples of methods for detecting attacks that exploit vulnerabilities include static heuristic methods, which predict behavior by reading process code, dynamic heuristic methods, which execute processes in a virtual environment and detect their behavior, or a combination of these. Alternatively, there are methods that manage abnormal process behavior characteristics as big data and detect malicious behavior based on the characteristics analyzed using machine learning. However, these are just examples, and other behavior detection methods may also be used.

[0075] When client program 10F receives the notification, it first forcibly terminates the process in question to prevent attacks that exploit the vulnerability (S-904).

[0076] Next, the client program 10F collects information (hash values, etc.) about the attacked process, that is, the vulnerable process (S-905).

[0077] After collecting the relevant information, the client program 10F transmits the collected information to the server device 20 via the network 30 and the network I / F 20D (S-906).

[0078] Figure 10 is an example of information about vulnerable processes sent by S-906. Here, the name of the attacked process, its hash value, and the attack pattern are recorded. This information is an example, so the type and amount of information recorded is not limited to this.

[0079] Through the above processing, it is possible to detect an attack that exploits a vulnerability and transmit information about a vulnerable process to the server device 20.

[0080] <Whitelist update process on the server device> Next, the process performed when the server device 20 receives the information transmitted from the client terminal device 10 in step S-906 will be described with reference to the flowchart of FIG.

[0081] First, the server program 20F receives information about vulnerable processes from the client terminal device 10 via the network 30 and the network I / F 20D (S-1101).

[0082] Next, the server program 20F searches the whitelist 20G using the hash value included in the information received in S-1101 as a key, and extracts matching records (S-1102).

[0083] At this point, it is known that a vulnerability exists in a single process included in a certain product, but since vulnerabilities generally exist on a product version basis, there is a risk that all processes of the same product and version may contain the vulnerability. Therefore, simply deleting only the relevant process from the whitelist is not sufficient as a vulnerability countermeasure (in the first embodiment, this point can be said to be covered because the process of deleting processes of the same product and version from the list is performed).

[0084] Therefore, in this embodiment, the following process is performed to delete all processes of the same product and the same version.

[0085] Note that the following describes the process of deleting when both the product name and version match, but the deletion conditions are not limited to this; for example, a condition can be set to delete the product regardless of the version if the product name matches (if it is the same product).

[0086] The server program 20F extracts the "product name" and "version" from the corresponding record (S-1103).

[0087] Next, the server program 20F searches the whitelist 20G for a record with the same product name (S-1104).

[0088] Next, the server program 20F searches the relevant records for a record that matches the vulnerable version (S-1105).

[0089] If a corresponding record exists, delete the record, or notify the administrator that a vulnerable process has been registered on the whitelist (S-1106).

[0090] This allows vulnerable products to be excluded from the whitelist on a version-by-version basis, and even if a zero-day attack occurs before the vulnerability database is updated, the whitelist can be updated immediately, making it possible to prevent zero-day attacks on other PCs that use the same list.

[0091] The server program 20F may be configured to search the whitelist 20G using the hash value included in the information received at S-1101 as a key, and delete only the matching records.

[0092] [Embodiment 3] In the first and second embodiments, when a vulnerability is found in a certain process, two types of processing have been described: either deleting the process from the whitelist, or notifying an administrator or the like of the vulnerability and urging them to delete it manually.

[0093] If the latter option is selected, the relevant process will be able to run on the client device between the time the vulnerability is detected and the time the administrator removes it from the whitelist, which could result in security issues.

[0094] Therefore, in this embodiment, in consideration of the occurrence of the above-mentioned problems, a "risk flag" indicating the risk that a process is vulnerable is set on the whitelist. If the client terminal launches a process with a risk flag indicating "risk," the client terminal notifies the user of the risk and issues a warning. At the same time, the user is prompted to choose whether or not to launch the process anyway. This ensures security while maintaining convenience for the client terminal until the administrator performs whitelist maintenance. In this case, the process may be instructed to be automatically executed when the administrator selects not to remove it from the whitelist, or a notification may be sent to a user who attempts to run the process with the "risk" flag set when the administrator selects to remove it from the whitelist.

[0095] <Configuration of this embodiment> In this embodiment, the overall system configuration is the same as in the first or second embodiment, so a description thereof will be omitted and only the differences will be described.

[0096] Fig. 12 is a diagram showing an example of a whitelist 10G stored on the client terminal 10 in this embodiment. Fig. 13 is a diagram showing an example of a whitelist 20G stored on the server device 20 in this embodiment.

[0097] As mentioned above, the "risk flag" is a flag that indicates the risk of a vulnerability in the process. As shown in Figures 12 and 13, the risk flag exists in both the whitelist 10G in the client terminal device 10 and the whitelist 20G in the server device 20, and is therefore added as an item to be downloaded when the whitelist is downloaded.

[0098] Both Figures 12 and 13 are Figures 2 and 3 to which a "risk flag" has been added, and the roles other than the "risk flag" are the same as those described in embodiments 1 and 2, so their explanation will be omitted here.

[0099] <Process startup control processing on client terminal device> The processing in this embodiment will be described below. Fig. 14 is a flowchart showing the processing flow in the client terminal device 10. As described above, this embodiment is based on the first and second embodiments, and therefore S-1401 to S-1406 in Fig. 14 are the same as S-501 to S506 in Fig. 5, and therefore description thereof will be omitted.

[0100] In the first and second embodiments, if a record with a matching hash value or signer name is found in the whitelist, the application is allowed to start up as is, but in this embodiment, processing using a "risk flag" follows.

[0101] The client program 10F checks the "risk flag" on the corresponding record in the whitelist 10G to see if there is any risk (S-1407).

[0102] If there is no risk, the client program 10F allows the process to be started (S-1408).

[0103] If there is a risk, the client program 10F displays a confirmation dialog on the screen of the client terminal device 10, prompting the user to select whether or not to start the process even though there is a risk in the process (S-1409).

[0104] FIG. 17 shows an example of a confirmation dialog that is displayed when "kintai.exe" is launched on the client terminal device 10 when the whitelist 10G shown in FIG. 12 exists.

[0105] If you select "YES" in this dialog (Y in S-1410), the client program 10F will allow the process to start (S-1408).

[0106] If "NO" is selected in the dialog (N in S-1410), the client program 10F prohibits the start of the process in question (S-1411).

[0107] Although the processing based on the "risk flag" has been described above, the risk flag itself is generated on the server device 20 side. This processing will be described below.

[0108] <Updating the Whitelist on the Server Device (Based on the First Embodiment)> First, the processing described here is processing based on embodiment 1. Fig. 15 is a flowchart showing the flow of processing in the server device 20. As described above, the processing in Fig. 15 is based on the processing in embodiment 1 (Fig. 6), and therefore steps S-1501 to S-1504 are the same processing, and S-1505 is processing performed when the processing of "notifying the administrator that a vulnerable process has been registered on the whitelist" is selected in S-605.

[0109] In this embodiment, after the process of S-1505, the server program 20F sets the risk flag of the corresponding record on the whitelist 20G to "risky" (S-1506).

[0110] As a result, when an attempt is made to start a process of a vulnerable product on the client terminal device 10, the process shown in FIG. 14 is executed, and a warning can be issued to the user.

[0111] <Updating the Whitelist on the Server Device (Based on the Second Embodiment)> Next, the processing described here is processing based on embodiment 2. Fig. 16 is a flowchart showing the flow of processing in the server device 20. As mentioned above, the processing in Fig. 16 is based on the processing in embodiment 2 (Fig. 11), and therefore steps S-1601 to S-1605 are the same processing, and S-1606 is processing when the processing of "notifying the administrator that a vulnerable process has been registered on the whitelist" is selected in S-1106.

[0112] In this embodiment, after the process of S-1606, the server program 20F sets the risk flag of the corresponding record on the whitelist 20G to "risky" (S-1607).

[0113] As a result, when an attempt is made to start a process of a vulnerable product on the client terminal device 10, the process shown in FIG. 14 is executed, and a warning can be issued to the user.

[0114] In either case, the whitelist 20G of the server device 20 is updated when a vulnerable product process is detected in the client terminal device 10. Therefore, when the client terminal device 10 subsequently acquires whitelist information (S-701), the acquired whitelist 10G reflects the risk flag. Therefore, it is preferable for the client terminal device 10 to issue a whitelist download request at regular intervals, such as every five minutes. With this configuration, even if the server device 20 is waiting for confirmation from an administrator, processing based on the risk flag can be executed on a client terminal device other than the client terminal device that detected the vulnerability.

[0115] In summary, according to the present invention, it is possible to update white risks based on process information in which vulnerabilities are detected. Furthermore, various modifications can be applied to each of the above-described embodiments without departing from the spirit of the invention, and each embodiment can be used in appropriate combination. For example, all of the first to third embodiments can be applied simultaneously.

[0116] [Other embodiments] The present invention can also be realized by supplying a program that realizes one or more functions of the above-described embodiments to a system or device via a network or a storage medium, and having one or more processors in the computer of the system or device read and execute the program. It can also be realized by a circuit (e.g., ASIC) that realizes one or more functions.

[0117] Furthermore, although the above embodiment has been described as a whitelist-type application execution control, the same processing can also be applied to a blacklist-type execution control. That is, while the description has been given of a process in which a vulnerability has been detected being registered on a whitelist, in which case the process is deleted from the whitelist, in the case of a blacklist, the only difference is that the process in which a vulnerability has been detected is controlled to be registered on the blacklist; other processing is the same. [Explanation of symbols]

[0118] 10 Client terminal device 10F Client Program 10G Whitelist 10H Behavior detection unit 20 Server device 20F Server Program 20G Whitelist 30 Network

Claims

1. An information processing system including a server device that holds a list used in controlling the execution of a whitelist or blacklist type application, and a client terminal device that acquires the list and controls the execution of the application, An information processing system characterized in that the server device updates the list based on a vulnerability database obtained from publicly available vulnerability information or the results of process behavior detection obtained from a client terminal device to which the list is sent.

2. 2. The information processing system according to claim 1, wherein a hash value of the process is used to identify the process to be updated on the list.

3. The list includes a risk flag; 3. The information processing system according to claim 1, wherein when the risk flag is assigned to a process to be executed in the client terminal device, a user is notified of this.

4. A server device that stores a list used in controlling the execution of a whitelist or blacklist type application, The server device is characterized in that it notifies that the vulnerability information has been detected based on a vulnerability database obtained from publicly available vulnerability information, or vulnerability information based on the results of process behavior detection obtained from a client terminal device to which the list is sent.

Images