JP4978061B2 - Software update necessity judgment method - Google Patents

Description

  The present invention relates to a software update necessity determination method, and more particularly to a software update necessity determination method for determining whether or not software installed in devices constituting a predetermined network system is necessary.

  For example, in a network system, an update (update) is performed to correct a defect in software installed in a network device. The update is performed by installing an update file for an update distributed by a network device vendor or the like.

  FIG. 1 is a system configuration diagram of an example of a network system. The network system of FIG. 1 includes servers 1a and 1b and a router R1 installed in the center, a client 2 and a router R2 installed in a sales office, a wide area Ethernet (registered trademark) 3, and an INS network 4. It is configured.

  In the conventional network system, it is confirmed as follows whether the existing network system has a secure configuration. First, the user refers to the OS vulnerability information WEB published on the Internet by, for example, a network device provider vendor. The user confirms the vulnerability of the network device by comparing the OS version of each network device with the OS vulnerability information. The user checks whether the existing network system has a secure configuration based on the presence or absence of the vulnerability of the network device.

For example, Patent Document 1 describes a technique for comparing software update information published on the network with the configuration of a management target system and performing an update for a match.
JP 2002-268985 A

  However, some software needs to be combined and consistent with other software. If such software is easily updated, there is a problem that the network system may become inconsistent and the system may be down.

  For example, in a mission critical system that emphasizes reliability, system down must be avoided. Therefore, it may not be desirable to unconditionally install all update files distributed by network device provider vendors. Japanese Patent Application Laid-Open No. 11-161482 is intended to cope with such a case.

  Japanese Patent Application Laid-Open No. 11-161482 describes that information relating to software that has failed is stored, and updating is performed when the update file relates to software that has failed. In other words, by not updating software that has not failed on the host or the like on which the backbone system is operating, the software is not updated more than necessary.

  However, the content described in Japanese Patent Laid-Open No. 11-161482 has a problem that the update that should not be performed may not be performed because the software that has not failed is not updated.

  The present invention has been made in view of the above points, and an object of the present invention is to provide a software update necessity determination method capable of appropriately determining whether software update is necessary or not while considering the reliability of a network system.

In order to solve the above-described problem, the present invention provides a software update necessity determination method for a computer for determining whether or not software installed in a device constituting a predetermined network system is necessary, wherein the computer includes the device A storage step of acquiring information relating to software installed in the computer and information relating to vulnerability of the software and storing the information in a storage device; information relating to software installed in the device stored in the storage device by the computer; Based on the information on the vulnerability of the software, a selection step of selecting the vulnerable software among the software installed in the device, and determining that the software with a track record of use among the selected software needs to be updated A determination step, wherein the determination step , Those that have passed since been used at the end of said selected software more than a predetermined time period, wherein the update at that time is determined to be unnecessary.

  The information regarding the software installed in the device may include identification information and usage history information of the software.

  In addition, what applied the component, expression, or arbitrary combination of the component of this invention to a method, an apparatus, a system, a computer program, a recording medium, a data structure, etc. is also effective as an aspect of this invention.

  As described above, according to the present invention, it is possible to provide a software update necessity determination method capable of appropriately determining whether or not software update is necessary while considering the reliability of the network system.

  Next, the best mode for carrying out the present invention will be described based on the following embodiments with reference to the drawings. First, in order to facilitate understanding of the present invention, an example of determining whether or not the software installed in the routers R1 and R2 among the devices constituting the network system in FIG. The network system shown in FIG. 2 confirms whether the configuration is secure and notifies the customer of the confirmation result, thereby realizing the operation of the secure network system.

  FIG. 2 is a block diagram of an embodiment of a network system according to the present invention. The network shown in FIG. 2 includes business servers 10a and 10b, a client 11, routers R1, R2, 19 and 20, a wide area Ethernet (registered trademark) 14, an INS network 15, a security client 16, and a router R1. The vulnerability information 17 of the router R2, the vulnerability information 18 of the router R2, and the Internet 21 are included.

  In the network system of FIG. 2, business servers 10a and 10b, routers R1 and 19 and a security client 16 are installed on the center side. A client 11 and a router R2 are installed on the sales office side. In addition, various servers (not shown) and a router 20 for realizing a Web site (vendor site WEB) are installed on the vendor side that provides the routers R1 and R2. In the vendor site WEB, the vulnerability information 17 of the router R1 and the vulnerability information 18 of the router R2 are registered so that they can be referred to. The security client 16 refers to the vendor site WEB (OS vulnerability information WEB), and performs the following process when an OS vulnerability occurs in the routers R1 and R2.

  First, the security client 16 transmits an OS version acquisition patrol packet to the routers R1 and R2. The OS version acquisition patrol packet can be realized by using an existing information acquisition command as described later.

  Next, the security client 16 sets the OS version acquired by the OS version acquisition patrol packet in a network system map described later. In this network system map, various pieces of information (OS version, access date, etc.) for determining whether or not software installed in the device needs to be updated are set for each device constituting the network system.

  The security client 16 includes the vulnerability OS version of the vulnerability information 17 of the router R1 and the vulnerability information 18 of the router R2 registered in the OS vulnerability information WEB, and the OS version of the router R1 and the router R2 set in the network system map. To determine whether or not the vulnerability is dealt with.

  If at least one of the router R1 and the router R2 does not cope with the vulnerability, the security client 16 further refers to the access date and time of the router R1 and the router R2 set in the network system map, An OS vulnerability non-compliant message / recommended version notification is sent to the customer. Note that the security client 16 considers the software to be used if the predetermined period has not elapsed since the set access date and time. Further, if the access date and time is not set or if a predetermined period has elapsed from the set access date and time, the security client 16 regards the software as having no usage record.

  The OS vulnerability non-corresponding message / recommended version notification includes information for identifying a device that is not compatible with the vulnerability, and a recommended version that represents the OS version for which the device is not vulnerable. As described above, in the network system of FIG. 2, the OS vulnerability non-compliant message / recommended version notification is sent to the customer only for the software that has been used for a predetermined period among the software that has not been dealt with by the vulnerability. Can do.

  That is, in the network system of FIG. 2, even if the software is not vulnerably dealt with, the OS vulnerability non-compliant message / recommended version notification of the software that has been deemed not to be used should not be sent to the customer. By doing so, we avoid dealing with software vulnerabilities more than necessary. As a result, the network system of FIG. 2 can appropriately determine whether or not software update is necessary while considering the reliability of the network system.

  Next, the hardware configuration of the security client 16 will be described with reference to FIG. FIG. 3 is a hardware configuration diagram of an example of the security client. The security client 16 includes an input device 31, an output device 32, a drive device 33, an auxiliary storage device 34, a memory device 35, an arithmetic processing device 36, and an interface device 37 that are connected to each other via a bus B. The

  The input device 31 includes a keyboard and a mouse, and is used for inputting various signals. The output device 32 includes a display device and is used to display various windows, data, and the like. The interface device 37 includes a modem, a router, a LAN card, and the like, and is used for connecting to various networks.

  The software update necessity determination program according to the present invention is at least a part of various programs for controlling the security client 16. The software update necessity determination program is provided by, for example, distribution of the recording medium 38 or downloading from various networks.

  The recording medium 38 on which the software update necessity determination program is recorded is a recording medium on which information is optically, electrically or magnetically recorded, such as a CD-ROM, flexible disk, magneto-optical disk, ROM, flash memory, etc. Various types of recording media such as a semiconductor memory that electrically records information can be used.

  When the recording medium 38 on which the software update necessity determination program is recorded is set in the drive device 33, the software update necessity determination program is installed from the recording medium 38 to the auxiliary storage device 34 via the drive device 33. Software update necessity determination programs downloaded from various networks are installed in the auxiliary storage device 34 via the interface device 37.

  The security client 16 stores the installed software update necessity determination program and also stores necessary files, data, and the like. The memory device 35 reads and stores a software update necessity determination program from the auxiliary storage device 34 when the computer is activated. The arithmetic processing unit 36 implements various processes as described later according to a software update necessity determination program stored in the memory device 35.

  Next, a software configuration diagram of the security client 16 will be described with reference to FIG. FIG. 4 is a software configuration diagram of an example of the security client.

  4 includes a configuration / vulnerability confirmation tool 41, an operation information acquisition tool 42, a vulnerability confirmation tool 43, a proposal template DB 44, a vulnerability information developer DB 45, a network system map DB 46, and a vulnerability information DB 47. It is configured as follows. Here, processing of the configuration / vulnerability confirmation tool 41, the operation information acquisition tool 42, and the vulnerability confirmation tool 43 will be described with reference to the drawings.

  FIG. 5 is a diagram for explaining the processing of the configuration / vulnerability confirmation tool. First, an outline proposal configuration of the network system shown in FIG. 2 is determined, and an estimate of each device is generated. The estimate 51 is an example of the estimate of the router R1. For example, the estimate 51 includes a model name, a module, a version, a use command, a memory size, and a price / Cost.

  In step S1, the configuration / vulnerability confirmation tool 41 searches for an optimal combination of network systems based on the estimation of each device, the proposal template DB 44, and the vulnerability information developer DB 45. The proposal template DB 44 represents the configuration of a network system that has been verified in advance. The vulnerability information developer DB 45 represents vulnerability / BUG information and used commands for each OS version.

  In step S2, the configuration / vulnerability checking tool 41 obtains the product detailed information of the corresponding combination, and creates a network system configuration map representing the configuration of the network system device and the software installed in each device. . In step S3, based on the network system configuration map, software installation to each device and setting of an information acquisition command are performed.

  Based on the processing results of steps S1 to S3, a network system map DB 46 as shown in FIG. 6 is created. FIG. 6 is a configuration diagram of an example of the network system map DB. The network system map DB 46 shown in FIG. 6 includes model name / ip address, version, installation date / time, start date / time, access date / time, function, use command, and information acquisition command. The network system map DB 46 of FIG. 6 represents an example in which each device is unused immediately after installation. If unused, “0000/00/00/00” is set as the access date.

  FIG. 7 is a diagram for explaining processing of the operation information acquisition tool. The operation information acquisition tool 42 acquires the IP address of each device set in the network system map DB 46 and reads the information acquisition command, and acquires the access date and time of each device by issuing the information acquisition command to each device. The access date and time is set in the network system map DB 46. In the network system map DB 46 of FIG. 7, the access date and time of the used device is set.

  FIG. 8 is a diagram for explaining processing of the vulnerability confirmation tool. In step S21, the vulnerability check tool 43 compares the network system map DB 46 with the vulnerability information DB 47 in which the vulnerability information of each device is registered. Here, the router R1 and the router R2 will be described as an example. In the vulnerability information DB 47, a vulnerability version range and a recommended version are set for each device and use command.

  Proceeding to step S22, the vulnerability checking tool 43 determines that the version of software that does not correspond to the software installed in the router R1 and router R2 based on the comparison result between the network system map DB 46 and the vulnerability information DB 47. It is determined whether or not it is included.

  Specifically, the vulnerability check tool 43 has a version that is not addressed when the version of software installed in the router R1 and the router R2 is included in the vulnerability version range of the vulnerability information DB 47. It is determined that the software is included, and when it is included in the recommended version of the vulnerability information DB 47, it is determined that the version of the software corresponding to the vulnerability is included.

  If the vulnerability checking tool 43 determines that the software installed in the router R1 and the router R2 includes a version of software that is not compatible with the vulnerability, the process proceeds to step S23, and the version of software that is not compatible with the vulnerability. It is determined whether or not the used commands match.

  If the vulnerability checking tool 43 determines that the use commands of the version of software that does not correspond to the vulnerability match, the process proceeds to step S24, and the access date and time of the version of software that does not correspond to the vulnerability is displayed in the network system map. It is determined whether or not it is set in the DB 46.

  If the vulnerability checking tool 43 determines that the access date and time of the version of the software that is not compatible with the vulnerability is set in the network system map DB 46, the process proceeds to step S25, where the access of the version of the software that is not compatible with the vulnerability is performed. Whether there is no access for a predetermined period (for example, two years) is determined according to the date and time.

  If the vulnerability checking tool 43 determines that the version of the software that has not been dealt with is not accessed for two years, the process proceeds to step S26, and the recommended version of the vulnerability information DB 47 is downloaded. In step S27, the vulnerability check tool 43 notifies the customer of a vulnerability non-correspondence message / recommended version notification to the customer.

  If it is determined in step S22 that the router R1 and router R2 do not contain a version of software that does not support vulnerability, the use command of the version of software that does not support vulnerability matches in step S23. If it is determined that the access date and time of the version of the software that is not compatible with vulnerability is not set in the network system map DB 46 in step S24, the version of software that is not compatible with vulnerability is determined in step S25. If there is no access for two years, a notice of non-applicability is sent to the customer indicating that there is no version of software that has not been addressed for vulnerability.

  As described above, the vulnerability check tool 43 obtains the access date and time of the device not corresponding to the vulnerability from the network system map DB 46, selects the device that has been used among the devices not compatible with the vulnerability, and described above. Vulnerability unsupported messages / recommended version notifications can be sent to customers.

  For example, in the case of the network system map DB 46 and the vulnerability information DB 47 in FIG. 8, the vulnerability check tool 43 performs processing in steps S21 to S27, and the vulnerability corresponding to the device “router R1, router R2” and the use command “IPv6 / RIP”. Non-gender compatible message / recommended version notification can be made to the customer.

  Hereinafter, another configuration of the network system according to the present invention will be described. FIG. 9 is a flowchart showing a process for registering vulnerable information on the vendor side. On the vendor side, a vulnerability information registration client 100, a WEB server 101, an AP server 102, and a DB server 103 are installed.

  In step S100, the vulnerability information registration client 100 makes a vulnerability registration request for the router R1. In step S101, the WEB server 101 performs servlet (sorting) based on the vulnerability registration request of the router R1, and performs the model call of the router R1. In step S102, the AP server 102 makes a vulnerability search request for the router R1 based on the model Call of the router R1.

  In step S103, the DB server 103 searches the vulnerability information DB 104 for vulnerability information of the router R1. Proceeding to steps S104 to S107, the DB server 103 notifies the vulnerability information registration client 100 of the search result. The vulnerability information registration client 100 outputs a vulnerability information update screen based on the search result.

  In step S108, the vulnerability version range, recommended version, and use (function) command are set in the vulnerability information registration client 100. In step S109, the WEB server 101 performs vulnerability information update APL Call. In step S110, the AP server 102 requests the vulnerability information DB 104 to be updated based on the vulnerability information update APL Call. In step S111, the DB server 103 updates the vulnerability information DB 104 based on the update request for the vulnerability information DB 104.

  Proceeding to steps S112 to S115, the DB server 103 notifies the vulnerability information registration client 100 of the update result. The vulnerability information registration client 100 displays the update result. As shown in FIG. 9, the vendor's vulnerability information can be registered in the vulnerability information DB 104 on the vendor side.

  FIG. 10 is a flowchart showing processing for notifying vulnerability information from the vendor side to the center side. On the vendor side, a WEB server 101, an AP server 102, a DB server 103, and a vulnerability information notification client 110 are installed.

  In step S200, the vulnerability information notification client 110 makes a vulnerability notification confirmation request to the user using the router R1. In step S201, the WEB server 101 performs servlet (sorting) based on the vulnerability notification confirmation request to the user who uses the router R1, and performs User Call of the router R1.

  In step S202, the AP server 102 issues a search request for users who are using the router R1 based on the User Call of the router R1. In step S203, the DB server 103 searches the R1 user DB 111 shown in FIG.

  FIG. 11 is a configuration diagram of an example of the R1 user DB. The R1 user DB 111 includes a user name of a user who uses the router R1, a notification method for the user, an e-mail address, and a Web address. The DB server 103 searches the R1 user DB 111 for the user name, notification method, e-mail address, and Web address.

  In steps S204 to S207, the DB server 103 notifies the vulnerability information notification client 110 of the search result. The vulnerability information notification client 110 outputs a notification user confirmation screen based on the search result.

  In step S208, the vulnerability information notification client 110 makes a vulnerability information notification request to the user using the router R1. In step S209, the WEB server 101 designates the user name “Tsuda” and performs a notification APL Call.

  In step S210, the AP server 102 makes a vulnerability information search request based on the notification APL Call. In step S211, the DB server 103 searches the vulnerability information DB 104 for vulnerability information of the router R1. In step S212, the DB server 103 notifies the search result to the AP server 102.

  In step S213, the AP server 102 sets the vulnerability information of the router R1 as a search result to e-mail, and sets the e-mail address searched from the R1 user DB 111 as a destination. In step S214, the AP server 102 transmits e-mail. Proceeding to steps S215 to S217, the AP server 102 notifies the vulnerability information notification client 110 of the result. The vulnerability information notification client 110 displays the vulnerability notification result.

  Further, the WEB server 101 proceeds to step S218 following step S216, specifies the next user name “Oota”, and performs a notification APL Call. In step S219, the AP server 102 sets the Web address searched from the R1 user DB 111 as e-mail, and sets the e-mail address searched from the R1 user DB 111 as a destination.

  In step S220, the AP server 102 transmits e-mail. Proceeding to steps S221 to S223, the AP server 102 notifies the vulnerability information notification client 110 of the result. The vulnerability information notification client 110 displays the vulnerability notification result. As shown in FIG. 10, on the vendor side, vulnerability information of a device such as the router R1 can be notified to a user who uses the router R1 by the push mail method, the WEB download method, or the timer type WEB download method.

  FIG. 12 is a flowchart showing a process of acquiring the version of software installed in the router R1 and the router R2 by the OS version acquisition patrol packet. The security client 16, WEB server 120, AP server 121, and DB server 122 are installed on the center side.

  In step S300, the security client 16 makes a network system map creation request. In step S301, the WEB server 120 performs a servlet (distribution) based on the network system map creation request, and activates the APL for all network accesses.

  In step S302, the AP server 121 acquires the IP address of each device included in the network system using the snmp command. In step S303, the AP server 121 acquires the version of each device such as the router R1, the router R2, etc. using the snmp command based on the acquired IP address. In step S304, the AP server 121 notifies the DB server 122 of the acquired version of each device, and makes a network system map DB update request.

  In step S 305, the DB server 122 updates the network system map DB 46 based on the version of each device received from the AP server 121. Proceeding to steps S306 to S308, the DB server 122 notifies the WEB server 120 of the update result of the network system map DB 46. The WEB server 120 sends a network system map creation completion notification to the security client 16. In step S309, the security client 16 receives a network system map creation completion notification. As shown in FIG. 12, the version of software installed in each device can be acquired for each device constituting the network system.

  FIG. 13 is a flowchart showing processing for acquiring vulnerability information. As described above, the security client 16 receives an e-mail of the Push mail method or the WEB download method from each vendor site WEB. In the case of the Push mail method, the security client 16 performs steps S400 to S408. In the case of the WEB download method, the security client 16 performs the processes of steps S410 to S418.

  If it is determined in step S400 that the push mail method is used, the security client 16 makes a vulnerability information update request. In step S401, the WEB server 120 performs a servlet (sorting) based on the vulnerability information update request, and activates a Push-type APL.

  In step S402, the AP server 121 acquires vulnerability information of the DATA part of the e-mail. In step S403, the AP server 121 notifies the DB server 122 of the acquired vulnerability information and makes a vulnerability information DB update request. In step S404, the DB server 122 updates the vulnerability information DB 47 based on the vulnerability information of each device received from the AP server 121. Proceeding to steps S405 to S408, the DB server 122 notifies the WEB server 120 of the update result of the vulnerability information DB 47. The WEB server 120 notifies the security client 16 that the vulnerability information DB 47 has been updated.

  If it is determined in step S410 that the WEB download method is used, the security client 16 makes a vulnerability information update request. In step S411, the WEB server 120 performs a servlet (sorting) based on the vulnerability information update request, and starts a web-type or timer-type APL.

  In step S412, the AP server 121 downloads the vulnerability information in the web address of the e-mail DATA part or the vulnerability information in the vendor web address pre-registered in the vendor web address DB 130 as shown in FIG. To do. FIG. 14 is a configuration diagram of an example of the vendor web address DB.

  In the vendor web address DB 130, a vulnerability Web address that is a download destination of the vulnerability version range and a recommended OS Web address that is a download destination of the recommended version are registered in advance for each device. In addition, since the process of step S413-S418 is the same as the process of step S403-S408, description is abbreviate | omitted. As shown in FIG. 13, the vulnerability information of each device can be acquired for each device constituting the network system.

  FIG. 15 is a flowchart showing processing for confirming vulnerability information. As described above, the security client 16 receives an e-mail of the Push mail method or the WEB download method from each vendor site WEB. Then, after performing the push mail method or the web download method as described above with reference to FIG. 13, the process proceeds to step S500.

  In step S500, the security client 16 makes a vulnerability check request. In step S501, the WEB server 120 performs a servlet (sorting) based on the vulnerability confirmation request, and activates the APL for vulnerability confirmation.

  In step S502, the AP server 121 makes a vulnerability information DB search request. In step S503, the DB server 122 searches the vulnerability information DB 47 based on the vulnerability information DB search request for each device received from the AP server 121. Proceeding to steps S504 to S505, the search result of the vulnerability information DB 47 is notified from the DB server 122 to the AP server 121.

  In step S506, the AP server 121 makes a network system map DB search request. In step S507, the DB server 122 searches the network system map DB 46 based on the network system map DB search request received from the AP server 121. Proceeding to steps S508 to S509, the search result of the network system map DB 46 is notified from the DB server 122 to the AP server 121.

  In step S510, the AP server 121 compares the search result of the vulnerability information DB 47 notified from the DB server 122 with the search result of the network system map DB 46. In step S511, the AP server 121 determines whether or not the software installed in the routers R1 and R2 needs to be updated, obtains a recommended version, and sets a comparison result.

  Proceeding to steps S512 to S514, the AP server 121 notifies the security client 16 of the comparison result. Based on the notified comparison result, the security client 16 displays a completion message as shown in FIG. As shown in FIG. 15, the vulnerability information DB 47 and the network system map DB 46 can be compared to determine whether the software installed in the routers R1 and R2 needs to be updated. 8 is equivalent to step S510, and step S27 in FIG. 8 is equivalent to step S512 to step S514.

The present invention may have the following configurations as described below.
(Appendix 1)
A computer software update necessity determination method for determining whether or not to update software installed in devices constituting a predetermined network system,
A storage step in which the computer acquires information about software installed in the device and information about vulnerability of the software and stores the information in a storage device;
Selection that the computer selects the vulnerable software among the software installed on the device based on the information on the software installed in the device and the information on the vulnerability of the software stored in the storage device Steps,
A determination step for determining whether or not software update is necessary, the step of determining that it is necessary to update software that has been used in the selected software.
(Appendix 2)
2. The software update necessity determination method according to claim 1, wherein the determination step determines that the update of a predetermined period of time or more after the last use of the selected software is unnecessary.
(Appendix 3)
The software update necessity determination method according to appendix 1 or 2, wherein the information about the software installed in the device includes identification information and usage history information of the software.
(Appendix 4)
The software update necessity determination method according to any one of supplementary notes 1 to 3, further comprising a notification step of notifying a user of a determination result in the determination step.
(Appendix 5)
A software update necessity determination program executed in a computer for determining whether or not software installed in devices constituting a predetermined network system is necessary,
The computer includes a storage device and an arithmetic processing unit,
A storage step of causing the arithmetic processing device to acquire information about software installed in the device and information about vulnerability of the software and store the information in the storage device;
A selection step of selecting a vulnerable one of the software installed in the device based on the information on the software installed in the device stored in the storage device and the information on the vulnerability of the software;
A software update necessity determination program for executing a determination step of determining that software having a track record of use among the selected software needs to be updated.
(Appendix 6)
A software update necessity determination device that determines whether or not software installed in a device constituting a predetermined network system needs to be updated,
Information acquisition and storage means for acquiring information on software installed in the device and information on vulnerability of the software and storing the information in a storage device;
Software selection means for selecting the vulnerable software among the software installed in the device based on the information on the software installed in the device stored in the storage device and the information on the vulnerability of the software;
A software update necessity determination apparatus, comprising: an update determination unit that determines that software having a track record of use among the selected software is required to be updated.

  The present invention is not limited to the specifically disclosed embodiments, and various modifications and changes can be made without departing from the scope of the claims.

It is a system configuration diagram of an example of a network system. It is a block diagram of one Example of the network system by this invention. It is a hardware block diagram of an example of a security client. It is a software block diagram of an example of a security client. It is a figure for demonstrating the process of a structure / vulnerability confirmation tool. It is a block diagram of an example of network system map DB. It is a figure for demonstrating the process of an operation information acquisition tool. It is a figure for demonstrating the process of a vulnerability confirmation tool. It is the flowchart which showed the process which registers vulnerability information on the vendor side. It is the flowchart which showed the process which notifies vulnerability information from the vendor side to the center side. It is a block diagram of an example of R1 user DB. It is the flowchart which showed the process which acquires the version of the software mounted in router R1, router R2 by the patrol packet for OS version acquisition. It is the flowchart which showed the process which acquires vulnerability information. It is a block diagram of an example of a vendor web address DB. It is the flowchart which showed the process which confirms vulnerability information.

Explanation of symbols

1a, 1b server 2, 11 client 3, 14 Wide area Ethernet (registered trademark)
4,15 INS network 10a, 10b Business server 16 Security client 17, 18 Vulnerability information 19, 20, R1, R2 Router 21 Internet 31 Input device 32 Output device 33 Drive device 34 Auxiliary storage device 35 Memory device 36 Arithmetic processing device 37 Interface device 38 Recording medium 41 Configuration / vulnerability confirmation tool 42 Operation information acquisition tool 43 Vulnerability confirmation tool 44 Proposed template 45 Vulnerability information developer DB
46 Network System Map DB
47 Vulnerability Information DB

Claims (2)

A computer software update necessity determination method for determining whether or not to update software installed in devices constituting a predetermined network system,
A storage step in which the computer acquires information about software installed in the device and information about vulnerability of the software and stores the information in a storage device;
Selection that the computer selects the vulnerable software among the software installed on the device based on the information on the software installed in the device and the information on the vulnerability of the software stored in the storage device Steps,
A determination step of determining that updating of software with a track record of use among the selected software is necessary;
Have
The determination step, the last used are those older than a predetermined period after the software update necessity determination method characterized in that the update at that time is determined to be unnecessary among said selected software.   2. The software update necessity determination method according to claim 1, wherein the information about the software installed in the device includes identification information and usage history information of the software.

Images