JP2009237807A - Vulnerability diagnosis conducting apparatus and diagnostic schedule generating program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To make an accurate diagnosis work plan, and to prevent delay in diagnosis work. <P>SOLUTION: A vulnerability diagnosis host has a diagnosis history DB which, in association with a host name for uniquely identifying a host for which vulnerability diagnosis has been conducted, stores vulnerability diagnosis history constituted of diagnosis items conducted to the host and diagnosis conducting time indicating time required for the diagnosis. Then, the vulnerability diagnosis host receives a scheduled date, when vulnerability diagnosis will be conducted and a host name as a diagnosis target on the scheduled date from a manager terminal which directs to conduct the vulnerability diagnosis; extracts the vulnerability diagnosis history, corresponding to the received host name from the diagnosis history DB; calculates the estimated diagnosis time required when the vulnerability diagnosis is conducted for the host based on the extracted vulnerability diagnosis history; and generates a diagnosis schedule for conducting vulnerability diagnosis for the host, based on the calculated estimated diagnosis time and the received scheduled date. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a vulnerability diagnosis execution apparatus and a diagnosis schedule creation program for performing vulnerability diagnosis on a host indicating various apparatuses targeted for vulnerability diagnosis.

  Conventionally, the diagnosis of vulnerabilities existing in various servers (for example, Web servers, mail servers, etc.) and communication devices (for example, routers, firewalls, etc.) used in the Internet or corporate intranets has been performed. .

  As a method for diagnosing this vulnerability, a local diagnosis method (refer to Patent Document 1) for logging in to a diagnosis target device and locally acquiring and diagnosing various information regarding settings, and a diagnosis target device via a network There is a remote diagnosis method (see Non-Patent Document 1) in which diagnosis is performed based on the contents of a response obtained by transmitting data from a host connected in (1).

  Since such methods need to be implemented at a specific timing, new vulnerabilities are discovered every day, and the contents of diagnostics and diagnostic programs corresponding to new vulnerabilities are frequently examined and regularly reviewed. Need to run diagnostics.

JP 2002-328896 A “Let's focus on the inherent vulnerabilities-Explain vulnerability diagnosis-”, Nikkei ITpro, security article “http://itpro.nikkeibp.co.jp/article/COLUMN/20060816/245784/”

  However, the above-described conventional techniques have a problem that an accurate diagnosis work plan cannot be made and a problem that a delay of the diagnosis work cannot be prevented.

  Specifically, the time from the start of the diagnostic program to the end of the diagnosis varies greatly depending on the hardware performance of the diagnosis target device and the software settings. However, there is nothing to depend on, and it is impossible to plan a uniform diagnosis work. In addition, as described above, there is only an experience to estimate the scheduled end time of work, so even if you try to complete diagnosis for multiple hosts within a specific period, due to delays in previous work, etc. It often happens that the working time is greatly shifted.

  Therefore, the present invention has been made to solve the above-described problems of the prior art, and it is possible to make an accurate diagnosis work plan and to prevent delay of the diagnosis work. It is an object of the present invention to provide a vulnerability diagnosis execution apparatus and a diagnosis schedule creation program.

  In order to solve the above-described problems and achieve the object, the present invention provides a vulnerability diagnosis execution device that performs vulnerability diagnosis on a host indicating various devices, and includes a host that has performed the vulnerability diagnosis. Corresponding to a host name uniquely identified, a diagnosis history storage means for storing a vulnerability diagnosis history composed of a diagnosis item performed on the host and a diagnosis execution time indicating a time required for the diagnosis, and the vulnerability An instruction receiving means for receiving a scheduled date and time for performing sex diagnosis and a host name to be diagnosed on the scheduled date and time from an administrator terminal that instructs execution of the vulnerability diagnosis, and a host received by the instruction receiving means A diagnosis history extraction means for extracting a vulnerability diagnosis history corresponding to a name from the diagnosis history storage means, and the host based on the vulnerability diagnosis history extracted by the diagnosis history extraction means Based on the predicted diagnosis time calculating means for calculating the predicted diagnosis time required when the vulnerability diagnosis is performed, the predicted diagnosis time calculated by the predicted diagnosis time calculating means, and the scheduled date and time received by the instruction receiving means And schedule creation means for creating a diagnosis schedule for performing vulnerability diagnosis on the host.

  According to the present invention, a vulnerability comprising a diagnosis item performed on the host and a diagnosis execution time indicating the time required for the diagnosis in association with a host name that uniquely identifies the host that has performed the vulnerability diagnosis. Sex diagnosis history is memorized, and the scheduled date and time for performing vulnerability diagnosis and the host name to be diagnosed at the scheduled date and time are received from the administrator terminal that instructs the execution of vulnerability diagnosis, and the received host name Corresponding vulnerability diagnosis history is extracted, and based on the extracted vulnerability diagnosis history, the predicted diagnosis time required for performing vulnerability diagnosis on the host is calculated, and the calculated predicted diagnosis time and accepted Based on the scheduled date and time, a diagnosis schedule for performing vulnerability diagnosis on the host is created, so it is possible to make an accurate diagnosis work plan and prevent delay of the diagnosis work. .

  Exemplary embodiments of a vulnerability diagnosis execution apparatus and a diagnosis schedule creation program according to the present invention will be described below in detail with reference to the accompanying drawings. In the following, the outline and features of the vulnerability diagnosis execution apparatus according to the present embodiment, the configuration of the vulnerability diagnosis execution apparatus and the flow of processing will be described in order, and finally various modifications to the present embodiment will be described.

[Vulnerability diagnosis host overview and features]
First, the outline and characteristics of the vulnerability diagnosis host according to the first embodiment will be described with reference to FIG. FIG. 1 is a system configuration diagram illustrating an overall configuration of a system including a vulnerability diagnosis host according to the first embodiment.

  As shown in FIG. 1, this system includes a vulnerability diagnosis host (corresponding to the “vulnerability diagnosis execution device” described in the claims) that performs vulnerability diagnosis on various devices via a network. The server includes a Web server, a FW (firewall), a mail server, and the like that are the target hosts (target devices) for vulnerability diagnosis.

  The vulnerability diagnosis performed by this vulnerability diagnosis host is a defect that can be used by a third party for hijacking of the system or leakage of confidential information in various devices in information systems such as computers and networks. Or a problem in the specification is not limited to a hardware bug, and a software bug or an OS bug can also be detected.

  In such a configuration, the vulnerability diagnosis host according to the first embodiment outlines that vulnerability diagnosis is performed on a host indicating various devices, and in particular, an accurate diagnosis work plan is made. The main feature is that it is possible to prevent the delay of the diagnostic work.

  Specifically explaining this main feature, the vulnerability diagnosis host associates the diagnosis item executed on the host and the time required for the diagnosis in association with the host name that uniquely identifies the host that has executed the vulnerability diagnosis. A diagnosis history DB for storing a vulnerability diagnosis result including a diagnosis execution time shown in FIG. As a specific example, the diagnosis history DB of the vulnerability diagnosis host is “1, Web server, 2007/1/10, 10:00:“ number, host name, start date / time, end date / time, execution time ”. 00, 2007/1/10, 10:00:20, 20s ”,“ 2, FW, 2007/2/25, 9:00:00, 2007/2/25, 9:00:40, 40s ” Remember.

  Here, “number” is a number that identifies each record, “host name” is an identifier that uniquely identifies the host that has performed vulnerability diagnosis, and “start date” is vulnerability diagnosis The `` end date '' indicates the date when the implemented vulnerability diagnosis was completed, and the `` implementation time '' is the time required for the vulnerability diagnosis. is there.

  Then, the vulnerability diagnosis host receives from the user the scheduled date and time for performing the vulnerability diagnosis and the host name to be diagnosed at the scheduled date and time (see (1) in FIG. 1). To give a specific example, the vulnerability diagnosis host receives the schedule creation instruction from the administrator terminal used by the administrator, and then the scheduled date and time for executing the vulnerability diagnosis is “2008/03/25, 12:00 : 00 ”and“ Web server, FW ”as the host name to be diagnosed at the scheduled date and time are received from the administrator terminal.

  Then, the vulnerability diagnosis host extracts a vulnerability diagnosis history corresponding to the accepted host name from the diagnosis history DB (see (2) in FIG. 1). Specifically, the vulnerability diagnosis host extracts “number 1 and number 3” as the vulnerability diagnosis history corresponding to the accepted host name “Web server” and also accepts the received host. “Number 2 and number 4 to number 6” are extracted as the vulnerability diagnosis result corresponding to the name “FW”.

  Then, the vulnerability diagnosis host calculates a predicted diagnosis time required when vulnerability diagnosis is performed on the host based on the extracted vulnerability diagnosis history (see (3) in FIG. 1). Specifically, in the above example, the vulnerability diagnosis host calculates, for example, the average of the “execution time” of the extracted vulnerability diagnosis history “number 1 (20 s) and number 3 (50 s)”, The calculated average value (= 35 s) is set as a predicted diagnosis time required when vulnerability diagnosis is performed on the host A. Similarly, the vulnerability diagnosis host may, for example, calculate the average of “execution time” of the extracted vulnerability diagnosis history “number 2 (40 s), number 4 (80 s), number 5 (30 s), number 6 (50 s)”. And the calculated average value (= 50 s) is used as the predicted diagnosis time required when vulnerability diagnosis is performed on the host B. Here, the case where the average value is used as the calculation of the predicted diagnosis time has been described. However, the present invention is not limited to this, and a summary of variance, standard deviation, skewness, kurtosis, median, etc. You may calculate using a statistic.

  Subsequently, the vulnerability diagnosis host creates a diagnosis schedule for performing vulnerability diagnosis on the host based on the calculated predicted diagnosis time and the accepted scheduled date and time (see (4) in FIG. 1). More specifically, the vulnerability diagnosis host calculates the predicted diagnosis time as “Web server, 35 s” and “FW, 50 s”, and the accepted scheduled execution date is “2008/03 / Since “25, 12:00:00”, a Web server having a short estimated execution time is executed from “2008/03/25, 12:00:00”, and then a schedule for executing FW is created. Specifically, the vulnerability diagnosis host indicates “Web server, 2008/03/25, 12:00:00, 2008/03/25, 12:“ host name, start date / time, end date / time, expected execution time ”. 00:35, 35s ”,“ FW, 2008/03/25, 12:00:36, 2008/03/25, 12:01:26, 50s ”. Note that here, the vulnerability diagnosis host has been described as creating a schedule for executing a host with a short expected execution time first, but the present invention is not limited to this, and is based on various factors. You can create a schedule.

  Then, the vulnerability diagnosis host notifies the administrator by outputting the created diagnosis schedule to a display unit such as a monitor. Here, the display method is not limited to this, and various notification methods that are generally used can be used, such as notification by mail or notification by voice.

  As described above, the vulnerability diagnosis host according to the first embodiment stores the past diagnosis results executed under various environments such as network delay as a history, and is necessary for the next diagnosis based on the history. As a result of being able to calculate the time predicted to be a schedule and create a schedule, it is possible to make an accurate diagnosis work plan as described above and prevent delays in diagnosis work It is.

[Vulnerability diagnosis host configuration]
Next, the configuration of the vulnerability diagnosis host shown in FIG. 1 will be described with reference to FIG. FIG. 2 is a block diagram illustrating the configuration of the vulnerability diagnosis host according to the first embodiment. As shown in FIG. 2, the vulnerability diagnosis host 10 includes a communication control I / F unit 11, a diagnosis history DB 12, a diagnosis schedule DB 13, a vulnerability diagnosis application 15, and a vulnerability diagnosis application manager 20. Is done.

  The communication control I / F unit 11 controls communication with various devices (hosts) connected to the network. Specifically, the communication control I / F unit 11 includes a plurality of ports connected to the respective hosts, accepts a schedule creation instruction from the administrator terminal, and outputs a schedule created on the administrator terminal. And control communication of vulnerability diagnosis applications executed for each host.

  The diagnosis history DB 12 is a vulnerability composed of a diagnosis item executed on the host in association with a host name that uniquely identifies the host that executed the vulnerability diagnosis, and a diagnosis execution time indicating a time required for the diagnosis. Store diagnostic history. As a specific example, as shown in FIG. 3, the diagnosis history DB 12 includes “host name, diagnosis ID, diagnosis item, diagnosis start date and time, diagnosis end date and time, pause date and time, restart date and time, diagnosis time” as “ AAA, 1, SSH, 2007/12/1, 10:00:00, 2007/12/1, 10:01:10,-,-, 70s "," AAA, 1, Web, 2007/12/1, 10:01:11, 2007/12/1, 10:01:30,-,-, 19s ". FIG. 3 is a diagram illustrating an example of information stored in the diagnosis history DB.

  Here, the “host name” is an identifier for uniquely identifying the host that has performed the vulnerability diagnosis, and the “diagnosis ID” is for identifying the vulnerability diagnosis performed at the same date and time. “Diagnosis item” identifies the item, protocol, and service for which vulnerability diagnosis was performed. “Diagnosis start date and time” indicates the date and time when vulnerability diagnosis was performed. Indicates the date and time when the implemented vulnerability diagnosis was completed. “Pause date and time” indicates the date and time when the vulnerability diagnosis was temporarily stopped. “Resume date and time” This indicates the date and time when the vulnerability diagnosis is temporarily stopped and then resumed, and the “diagnosis time” is the time required for the vulnerability diagnosis.

  The diagnosis schedule DB 13 stores a diagnosis schedule created by the vulnerability diagnosis application manager 20 described later. Specifically, as shown in FIG. 4, the diagnosis schedule DB 13 has “host name, diagnosis ID, diagnosis item, diagnosis start date (prediction), diagnosis end date (prediction), and expected diagnosis time” as “ AAA, 1, SSH, 2007/12/1, 10:00:00, 2007/12/1, 10:00:30, 30s "," AAA, 1, Web, 2007/12/1, 10:00: 31, 2007/12/1, 10:02:11, 40s ". FIG. 4 is a diagram illustrating an example of information stored in the diagnosis schedule DB.

  Here, the “host name” is an identifier that uniquely identifies the host that performs the vulnerability diagnosis, and the “diagnosis ID” identifies the vulnerability diagnosis that is performed at the same date and time. “Diagnosis item” identifies items, protocols, and services for which vulnerability diagnosis is performed, and “Diagnosis start date (expected)” indicates the date and time when vulnerability diagnosis is input from the administrator terminal. “Diagnosis end date and time (forecast)” indicates the date and time when the vulnerability diagnosis input from the administrator terminal ends, and “Expected diagnosis time” refers to the vulnerability diagnosis application described later. This is the time required for vulnerability diagnosis calculated by the manager 20.

  The vulnerability diagnosis application 15 performs remote diagnosis on the diagnosis target host. As a specific example, the vulnerability diagnosis application 15 performs various diagnoses according to the diagnosis schedule stored in the diagnosis schedule DB 13, notifies the vulnerability diagnosis application manager 20 described later of the diagnosis results, and The diagnosis result is stored in the diagnosis history DB 12. Specifically, the vulnerability diagnosis application 15 refers to the diagnosis schedule stored in the diagnosis schedule DB 13, and if there is a schedule that has reached the diagnosis start date (prediction), implements the diagnosis items of the schedule to the host Then, the diagnosis result is notified to the vulnerability diagnosis application manager described later, and the diagnosis result is stored in the diagnosis history DB 12. In this way, the vulnerability diagnosis application 15 can always refer to the diagnosis schedule stored in the diagnosis schedule DB 13 and sequentially execute the schedules that have reached the diagnosis start date and time (forecast). Only the schedule designated by the administrator based on the diagnosis schedule stored in the DB 13 can be executed.

  The vulnerability diagnosis application manager 20 is an application for creating a schedule for executing the vulnerability diagnosis application. Particularly, the vulnerability diagnosis application manager 20 includes a user interface unit 21, a vulnerability diagnosis application control unit 22, And a diagnosis history management unit 23.

  The user interface unit 21 is an interface for an administrator or the like to operate the vulnerability diagnosis application manager 20, and particularly those closely related to the present invention include a screen output function unit 21a, a data transfer processing unit 21b, Is provided.

  The screen output function unit 21a includes a monitor (or a display or a touch panel) and a speaker, and receives information necessary for diagnosis execution from the administrator terminal. As a specific example, the screen output function unit 21a outputs a screen for accepting “diagnosis content (item), diagnosis target host name (or IP address), diagnosis schedule”, etc. as information necessary for diagnosis execution. The information is received from the administrator terminal. In addition to the information described above, the screen output function unit 21a displays a screen that accepts information such as a priority order and a feasible time zone when performing diagnosis on a plurality of hosts, and displays the information on the administrator terminal. Can also be accepted.

  The screen output function unit 21a outputs information received from the administrator terminal to a data transfer processing unit 21b described later. Further, the screen output function unit 21a acquires a diagnosis schedule generated and stored by a diagnosis history management unit 23, which will be described later, from the diagnosis schedule DB 13 and displays it to the administrator, or an execution result executed by the vulnerability diagnosis application Is displayed on the administrator terminal.

  The data transfer processing unit 21b transfers various information input from an administrator terminal or the like to each functional unit. As a specific example, the data transfer processing unit 21b receives information “diagnosis content (item), diagnosis target host name (or IP address), diagnosis schedule received by the screen output function unit 21a. And the like are transferred to the vulnerability diagnosis application control unit 22 and the diagnosis history management unit 23 described later. Further, the data transfer processing unit 21b includes “diagnosis” among the information “diagnosis content (item), diagnosis target host name (or IP address), diagnosis schedule” necessary for the diagnosis execution received by the screen output function unit 21a. Information can also be distributed, such as “content (item), diagnosis target host name (or IP address)” is transferred to the history extraction unit 23b, and “diagnosis schedule” is output to the schedule planning unit 23d.

  The vulnerability diagnosis application control unit 22 executes the diagnosis schedule instructed from the administrator terminal in accordance with the diagnosis schedule generated by the diagnosis history management unit 23 described later and stored in the diagnosis schedule DB 13. 15 includes a format confirmation unit 22a, an activation control unit 22b, and a result acquisition unit 22c, which are particularly closely related to the present invention.

  The format confirmation unit 22a receives information “diagnosis content (item), diagnosis target host name (or IP address), diagnosis schedule”, and the like necessary for diagnosis execution from the user interface unit 21, and the received information is defined by the system. To check whether it conforms to the format, whether there is an excess or deficiency of information, or whether invalid parameters are mixed. If there is no problem with the inspected information, the format confirmation unit 22a transmits the information to the activation control unit 22b and the result acquisition unit 22c. In addition, when there is a problem in the inspected information, the format confirmation unit 22a notifies the administrator terminal of a notification that there is a problem, a screen that prompts correction of the problem part, and the like via the screen output function unit 21a. .

  The activation control unit 22b includes a conversion list that is a correspondence table for converting information necessary for diagnosis execution according to the type of the vulnerability diagnosis application 15, and among the information received from the format confirmation unit 22a, “diagnosis item” The host name (or IP address) to be diagnosed ”is changed to a format readable by the vulnerability diagnosis application 15 based on the conversion list. In addition, the activation control unit 22b activates, temporarily stops, resumes, stops, and the like of the vulnerability diagnosis application 15 according to the schedule specified by the administrator terminal. When the vulnerability diagnosis application 15 is activated, paused, resumed, or stopped, the activation control unit 22b transmits the date and time when the vulnerability diagnosis application 15 is generated to the diagnosis history management unit 23.

  In addition, as described above, the activation control unit 22b not only executes the vulnerability diagnosis application 15 according to the schedule specified by the administrator terminal based on the created schedule, but also according to only the created schedule. The sex diagnostic application 15 may be executed.

  The result acquisition unit 22c acquires the diagnosis result executed by the vulnerability diagnosis application 15, and displays and outputs the acquired diagnosis result on the administrator terminal via the user interface unit 21. The result acquisition unit 22c refers to the conversion list when acquiring the diagnosis result executed by the vulnerability diagnosis application 15, and based on the referred conversion list, from the data format readable by the system, the administrator Is converted into a readable data format, and the converted result is displayed and output to the administrator terminal via the user interface unit 21.

  The diagnosis history management unit 23 is a processing unit that stores the time required for the diagnosis performed by the vulnerability diagnosis application 15 in the diagnosis history DB 12 as a history and creates various data from the history, and is closely related to the present invention. Related items include a history storage unit 23a, a history extraction unit 23b, a diagnosis time prediction unit 23c, and a schedule plan unit 23d.

  The history storage unit 23 a accepts the execution result of the vulnerability diagnosis application 15 acquired by the result acquisition unit 22 c of the vulnerability diagnosis application control unit 22 and stores the execution result in the diagnosis history DB 12. Further, when storing the execution result in the diagnosis history DB 12, the history storage unit 23a assigns and stores a “diagnosis ID” that is a unique ID for each diagnosis. That is, since the same “diagnosis ID” is given to the diagnostic items executed in series in the same schedule, it is possible to recognize which diagnostic item was executed in which schedule.

  The history extraction unit 23b extracts the vulnerability diagnosis history corresponding to the host name received by the user interface unit 21 from the diagnosis history DB 12. More specifically, the history extraction unit 23b extracts all vulnerability diagnosis results corresponding to the host name “AAA” received by the user interface unit 21 from the diagnosis history DB 12, and the diagnosis time described later. It outputs to the prediction part 23c. Further, when the information received by the user interface unit 21 is “host name = AAA, diagnosis item = SSH”, the history extraction unit 23b uses the combination of “host name = AAA, diagnosis item = SSH”. Only the corresponding vulnerability diagnosis history is extracted from the diagnosis history DB 12 and output to the diagnosis time prediction unit 23c described later.

  Based on the extracted vulnerability diagnosis history, the diagnosis time prediction unit 23c calculates a predicted diagnosis time required when vulnerability diagnosis is performed on the host. Specifically, in the above example, when the diagnosis time prediction unit 23c receives the vulnerability diagnosis history corresponding to the host name “AAA”, the diagnosis time prediction unit 23c calculates the prediction diagnosis time from the diagnosis time of the received diagnosis result, It outputs to the schedule plan part 23d mentioned later. In addition, when receiving a plurality of pieces of information including “host name, diagnosis item”, the diagnosis time prediction unit 23c calculates a prediction diagnosis time for each diagnosis item and outputs it to the schedule planning unit 23d described later.

Here, an example of calculating the predicted time when the diagnosis time of the received diagnosis history is “x ₁ , x ₂ , x ₃ ,... X _n ” will be described. As a calculation method, for example, an average value obtained by the calculation formula shown in Formula (1) can be used as the predicted diagnosis time. In addition, when the average value calculated by Expression (1) is an arithmetic average, the variance value obtained using Expression (2) can be used as the predicted diagnosis time.

Also, the diagnosis times “x ₁ , x ₂ , x ₃ ,... X _n ” of the received diagnosis history are rearranged in ascending order, “x ₁ ^′ , x ₂ ^′ , x ₃ ^′ ,. _In the case of “ _n ^′ ”, the median value obtained by using Equation (3) can also be used as the predicted diagnosis time. Further, as shown in Expression (4), an average deviation obtained by dividing the median calculated in Expression (3) by “total number (n)” can also be used as the predicted diagnosis time.

  The schedule planning unit 23d creates a diagnosis schedule for performing vulnerability diagnosis on the host based on the calculated predicted diagnosis time and the accepted scheduled date and time. Specifically, the schedule planning unit 23d is received by the user interface unit 21 from the predicted diagnosis time calculated by the diagnosis time prediction unit 23c and the scheduled date and time received by the user interface unit 21. A diagnostic schedule is created and stored in the diagnostic schedule DB 13 (see FIG. 4) so that the diagnosis for the host is completed within the scheduled date and time (see FIG. 4), and the created diagnostic schedule is displayed on the administrator terminal via the user interface unit 21. To do.

  In addition, when the user interface unit 21 receives a diagnosis scheduled host and a diagnostic item in association with each other, the schedule planning unit 23d is based on the predicted diagnostic time for each diagnostic item calculated by the diagnostic time prediction unit 23c. Thus, a diagnostic schedule is created and stored in the diagnostic schedule DB 13 so that diagnostic items are sequentially executed, and the created diagnostic schedule is displayed and output to the administrator terminal via the user interface unit 21.

  Further, for example, the schedule planning unit 23 d can also create a schedule from the prediction diagnosis times calculated for the hosts received by the user interface unit 21, with the prediction diagnosis time being short. In addition, when the scheduled date / time is received for each host by the user interface unit 21, the schedule planning unit 23d can create a schedule by giving priority to the scheduled date / time closest to the current date / time. .

[Processing by vulnerability diagnosis host]
Next, processing performed by the vulnerability diagnosis host will be described with reference to FIG. FIG. 5 is a flowchart illustrating a flow of a diagnosis schedule creation process in the vulnerability diagnosis host according to the first embodiment.

  As shown in FIG. 5, when the vulnerability diagnosis host 10 receives host information to be diagnosed (Yes at step S101), the diagnosis history corresponding to the host included in the host information is extracted from the diagnosis history DB 12 ( Step S102).

  Specifically, the vulnerability diagnosis host 10 sets “AAA, Web, SSH, 12:00:00 to 12:50:00”, “BBB” as the host information “host name, diagnosis item, scheduled date and time” to be diagnosed. , 12:00:00 to 12:50:00 ”, the diagnosis history corresponding to each of“ host names: AAA, BBB ”included in the host information is extracted from the diagnosis history DB 12. .

  Subsequently, the vulnerability diagnosis host 10 calculates a predicted diagnosis time for each accepted host from the extracted diagnosis history (step S103). Specifically, the vulnerability diagnosis host 10 calculates the estimated diagnosis time for each accepted host “AAA, BBB” from the extracted diagnosis history using the summary statistics. At this time, if there is a diagnosis item designated by the administrator for each host, a predicted diagnosis time is calculated for each diagnosis item.

  Then, the vulnerability diagnosis host 10 creates a diagnosis schedule for performing vulnerability diagnosis for each host based on the calculated predicted diagnosis time and the accepted scheduled date and time (step S104). Specifically, the vulnerability diagnosis host 10 creates a diagnosis schedule and stores it in the diagnosis schedule DB 13 so that the diagnosis ends within the scheduled date and time from the calculated predicted diagnosis time and the accepted scheduled date and time. At the same time, the created diagnosis schedule is displayed and output on the administrator terminal.

[Effects of Example 1]
As described above, according to the first embodiment, the diagnosis item performed on the host in association with the host name that uniquely identifies the host that performed the vulnerability diagnosis, and the diagnosis execution time indicating the time required for the diagnosis, Vulnerabilities diagnosis history that consists of, and accepts and accepts the scheduled date and time of the vulnerability diagnosis and the host name to be diagnosed on the scheduled date and time from the administrator terminal that instructs the execution of the vulnerability diagnosis The vulnerability diagnosis history corresponding to the host name extracted is extracted, and based on the extracted vulnerability diagnosis history, the predicted diagnosis time required when performing a vulnerability diagnosis on the host is calculated, and the calculated predicted diagnosis time A diagnosis schedule for performing vulnerability diagnosis on the host is created based on the received scheduled date and time, so it is possible to create an accurate diagnosis work plan and prevent delay of the diagnosis work It is possible.

  In addition, according to the first embodiment, the predicted diagnosis time is calculated using the summary statistics with respect to the diagnosis execution time included in the extracted vulnerability diagnosis history. As a result, it is possible to save the past diagnosis results executed in the history as a history, calculate the time estimated to be necessary for the next diagnosis based on the history, and create a schedule, so that an accurate diagnosis work plan It is possible to stand up.

  Further, according to the first embodiment, the scheduled date and time, the host name, and further the diagnosis item are received from the administrator terminal, and the vulnerability diagnosis history associated with the accepted host name and the diagnosis item is received from the diagnosis history storage unit. Since extraction is performed, it is possible to calculate an expected diagnosis time for each diagnosis item. As a result, it is possible to make a more accurate diagnosis work plan, and it is possible to prevent delay of the diagnosis work.

  Further, according to the first embodiment, as the scheduled date and time, a scheduled diagnosis start time for starting diagnosis, a scheduled diagnosis end time for ending diagnosis, and a diagnosable time zone for each host are received from the administrator terminal and calculated. Since the diagnosis schedule is created so that the diagnosis is completed within the accepted diagnosis start time, diagnosis end time, and diagnosis possible time zone for each host from the predicted diagnosis time, the time during which diagnosis is possible is limited Even if it is, it is possible to create a diagnosis schedule so that the diagnosis is completed within a limited time.

  By the way, this apparatus can create a diagnostic schedule in consideration of various conditions other than the schedule creation example described in the first embodiment. In the second embodiment, various examples for creating a diagnosis schedule will be described.

  First, with reference to FIG. 6, a case will be described in which a diagnosis schedule is created by giving priority to the accepted scheduled date and time from the current date and time. FIG. 6 is a system configuration diagram illustrating an overall configuration of a system including the vulnerability diagnosis host according to the second embodiment.

  As shown in FIG. 6, as in the first embodiment, this system is a vulnerability diagnosis host that performs vulnerability diagnosis on various devices via a network, and a vulnerability diagnosis target host (target device). It consists of a Web server, FW (firewall), mail server, and the like.

  In addition, as in the first embodiment, this vulnerability diagnosis host indicates the diagnosis item performed on the host and the time required for the diagnosis in association with the host name that uniquely identifies the host that has performed the vulnerability diagnosis. A diagnosis history DB that stores vulnerability diagnosis results including diagnosis execution time is provided. As a specific example, the diagnosis history DB of the vulnerability diagnosis host is “1, Web server, 2007/1/10, 10:00:“ number, host name, start date / time, end date / time, execution time ”. 00, 2007/1/10, 10:00:20, 20s ”,“ 2, FW, 2007/2/25, 9:00:00, 2007/2/25, 9:00:40, 40s ” Remember.

  In such a configuration, the vulnerability diagnosis host receives from the user the scheduled date and time for performing the vulnerability diagnosis and the host name to be diagnosed at the scheduled date and time (see (1) in FIG. 6). To give a specific example, the vulnerability diagnosis host receives the schedule creation instruction sent from the administrator terminal used by the administrator, and then the scheduled date and time for performing the vulnerability diagnosis and the host name to be diagnosed. "Web server, 2008/03/25, 10: 00: 00-12: 00: 00" and "FW, 2008/03/25, 10: 00: 00: 00: 00: 50" Accept from.

  Then, as in the first embodiment, the vulnerability diagnosis host acquires “number 1 and number 3” as the vulnerability diagnosis result corresponding to the accepted host name “Web server”, and the accepted host name. “No. 2 and No. 4 to No. 6” are acquired as vulnerability diagnosis results corresponding to “FW” (see (2) in FIG. 6). Then, for example, the vulnerability diagnosis host calculates the average of the “execution time” of the acquired vulnerability diagnosis results “number 1 (20 s) and number 3 (50 s)”, and calculates the average value (= 35 s) Is the predicted diagnosis time required when vulnerability diagnosis is performed on host A (see (3) in FIG. 6). Similarly, the vulnerability diagnosis host, for example, obtains an average of “execution time” of the acquired vulnerability diagnosis results “number 2 (40 s), number 4 (80 s), number 5 (30 s), number 6 (50 s)”. And the calculated average value (= 50 s) is used as the predicted diagnosis time required when vulnerability diagnosis is performed on the host B.

  Unlike the first embodiment, the vulnerability diagnosis host has the calculated predicted diagnosis times “Web server, 35 s” and “FW, 50 s”, but the allowable execution time at each host is “Web server”. , 10:00:00 to 12:00:00 "and" FW, 10: 00: 00: 00 to 10:00:50 ", the schedule is created with priority on FW. That is, the vulnerability diagnosis host executes FW with a short allowable execution time, and then creates a schedule for executing the Web server (see (4) in FIG. 6). Specifically, the vulnerability diagnosis host is “FW, 2008/03/25, 10:00:00, 2008/03/25, 10:00” as “host name, start date / time, end date / time, expected execution time”. : 50, 50 s ”“ Web server, 2008/03/25, 10:00:51, 2008/03/25, 10:01:26, 35 s ”is created.

  In this way, this vulnerability diagnosis host creates a diagnosis schedule so that the diagnosis execution time is secured by giving priority to the host with the latest scheduled diagnosis end time received, so that all diagnosis ends as scheduled. Accurate diagnosis schedule can be created.

  In addition to the above, the vulnerability diagnosis host can receive, for example, the number of simultaneously executable hosts from the administrator, and create a schedule for executing the simultaneously executable hosts in parallel. By doing so, it is possible to create a diagnosis schedule without reducing the diagnosis time.

  In addition, for example, if a vulnerability diagnosis host receives a host whose scheduled end date is duplicated, it makes an inquiry (inquiry screen) to the administrator terminal as to which host has priority. A diagnostic schedule can also be created based on the results. If there is no response to the inquiry, the vulnerability diagnosis host can create a diagnosis schedule by giving priority to a host with a short estimated time required for sorting or diagnosis by host name. By doing so, the priority schedule can be selected every time the diagnosis is performed, and the diagnosis schedule can be created. As a result, the user's intention can be reflected and adapted to the system environment and processing status. It is possible to create a diagnostic schedule.

  In addition, for example, if there is a host (or diagnostic item) that is not in time for the scheduled end date in the created diagnostic schedule, the vulnerability diagnosis host can display an alert to the administrator. In this way, it is possible to notify the administrator that the vulnerability diagnosis is desired to end.

  In addition, the vulnerability diagnosis host can display and output the created diagnosis schedule on a screen, for example, receive recombination of the schedule by an administrator, and recreate a schedule reflecting the recombination. In this way, the priority schedule can be selected at the timing of diagnosis, so that the user's intention can be reflected and a diagnostic schedule adapted to the system environment and processing status can be created. It is.

  In addition, for example, the vulnerability diagnosis host receives a diagnosis item other than the host as a diagnosis target from the administrator, but when the diagnosis item associated with the host is not stored in the diagnosis history DB, The diagnosis item associated with the host may be acquired from the diagnosis history DB, and the predicted diagnosis time may be calculated. In addition, when the diagnosis item associated with another host is not stored in the diagnosis history DB, the vulnerability diagnosis host acquires all the diagnosis histories associated with the host and calculates the predicted diagnosis time. You may make it calculate. By doing so, it is possible to create a diagnosis schedule even for a new diagnosis item, and the convenience of the user is improved.

  Although the embodiments of the present invention have been described so far, the present invention may be implemented in various different forms other than the embodiments described above. Therefore, as shown below, (1) predicted time calculation method, (2) server separation, (3) target host, (4) system configuration, etc., (5) different embodiments will be described by being divided into programs. .

(1) Prediction time calculation method For example, in Example 1, although the example which calculates prediction time using an average, dispersion | distribution, a median, and a standard deviation was demonstrated as a summary statistic, this invention is limited to this. It can also be calculated by using skewness, kurtosis, etc. used for summary statistics. In addition to the summary statistics, for example, the diagnostic item can be weighted for each diagnostic item such that Web is important and SSH is not important, and the predicted time can be calculated using this weight.

(2) Server separation In the first and second embodiments, the vulnerability diagnosis host including the vulnerability diagnosis application is described as an example. However, the present invention is not limited to this, and the vulnerability diagnosis application is not limited to this. The vulnerability diagnosis host to be executed and the schedule creation apparatus to which the present invention is applied may be different from the chassis. Further, not only the vulnerability diagnosis via the network but also the local diagnosis diagnosed by the local connection can be similarly applied.

(3) Target Host In the first and second embodiments, the web server, FW, and mail server have been described as examples of vulnerability diagnosis target hosts. However, the present invention is not limited to this, and a router, A diagnosis schedule can be similarly created for network devices such as L3 switches and L2 switches and general-purpose computers such as mainframes.

(4) System configuration, etc. Also, among the processes described in the present embodiment, all or part of the processes (for example, schedule creation target host reception process) described as being automatically performed are manually performed. You can also. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters (for example, FIG. 1, FIG. 3, FIG. 4, FIG. It can be changed arbitrarily unless you want to.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each device is not limited to that shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various loads or usage conditions. It can be configured by integrating (for example, integrating the user interface unit and the vulnerability application control unit). Further, all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.

(5) Program The diagnosis schedule creation method described in the present embodiment can be realized by executing a prepared program on a computer such as a personal computer or a workstation. This program can be distributed via a network such as the Internet. The program can also be executed by being recorded on a computer-readable recording medium such as a hard disk, a flexible disk (FD), a CD-ROM, an MO, and a DVD and being read from the recording medium by the computer.

  As described above, the vulnerability diagnosis execution apparatus and the diagnosis schedule creation program according to the present invention are useful for performing vulnerability diagnosis on a host indicating various apparatuses targeted for vulnerability diagnosis. It is suitable for making an accurate diagnosis work plan and preventing delay of the diagnosis work.

1 is a system configuration diagram illustrating an overall configuration of a system including a vulnerability diagnosis host according to Embodiment 1. FIG. 3 is a block diagram illustrating a configuration of a vulnerability diagnosis host according to Embodiment 1. FIG. It is a figure which shows the example of the information memorize | stored in diagnostic history DB. It is a figure which shows the example of the information memorize | stored in diagnostic schedule DB. 7 is a flowchart illustrating a flow of a diagnosis schedule creation process in the vulnerability diagnosis host according to the first embodiment. It is a system configuration | structure figure which shows the whole structure of the system containing the vulnerability diagnosis host which concerns on Example 2. FIG.

Explanation of symbols

10 Vulnerability diagnosis host 11 Communication control I / F part 12 Diagnosis history DB
13 Diagnosis schedule DB
DESCRIPTION OF SYMBOLS 15 Vulnerability diagnosis application 20 Vulnerability diagnosis application manager 21 User interface part 21a Screen output function part 21b Data transfer process part 22 Vulnerability diagnosis application control part 22a Format confirmation part 22b Startup control part 22c Result acquisition part 22d Schedule plan part 23 Diagnosis History management unit 23a History storage unit 23b History extraction unit 23c Diagnosis time prediction unit 23d Schedule planning unit

Claims (10)

A vulnerability diagnosis execution device that performs vulnerability diagnosis on a host indicating various devices targeted for vulnerability diagnosis,
Corresponding to a host name that uniquely identifies the host that has performed the vulnerability diagnosis, a vulnerability diagnosis history including a diagnosis item performed on the host and a diagnosis execution time indicating a time required for the diagnosis is stored. Diagnostic history storage means,
An instruction receiving means for receiving a scheduled date and time for performing the vulnerability diagnosis and a host name to be diagnosed on the scheduled date and time from an administrator terminal that instructs execution of the vulnerability diagnosis;
A diagnosis history extracting means for extracting a vulnerability diagnosis history corresponding to the host name received by the instruction receiving means from the diagnosis history storage means;
Based on the vulnerability diagnosis history extracted by the diagnosis history extracting means, a predicted diagnosis time calculating means for calculating a predicted diagnosis time required when vulnerability diagnosis is performed on the host;
Schedule creation means for creating a diagnosis schedule for performing vulnerability diagnosis on the host based on the predicted diagnosis time calculated by the predicted diagnosis time calculation means and the scheduled date and time received by the instruction receiving means;
An apparatus for performing vulnerability diagnosis, comprising:   The predicted diagnosis time calculation means calculates the predicted diagnosis time using summary statistics for the diagnosis execution time included in the vulnerability diagnosis history extracted by the diagnosis history extraction means. The vulnerability diagnosis execution apparatus according to claim 1. The instruction accepting means accepts the scheduled date and time, a host name, and further the diagnostic item from the administrator terminal,
3. The diagnosis history extracting unit extracts a vulnerability diagnosis history associated with a host name and a diagnosis item received by the instruction receiving unit from the diagnosis history storage unit. The vulnerability diagnosis execution apparatus described.   The diagnosis history extraction unit is irrelevant to the host name when the vulnerability diagnosis result associated with the host name and the diagnosis item received by the instruction reception unit is not stored in the diagnosis history storage unit. 4. The vulnerability diagnosis execution apparatus according to claim 3, wherein a vulnerability diagnosis history corresponding to the diagnosis item is extracted from all vulnerability diagnosis histories stored in the diagnosis history storage means. The instruction receiving means receives from the administrator terminal, as the scheduled date and time, a scheduled diagnosis start time for starting diagnosis, a scheduled diagnosis end time for ending diagnosis, and a diagnosable time zone for each host,
The schedule creation means can perform diagnosis for each host between the predicted diagnosis time calculated by the predicted diagnosis time calculation means and the scheduled diagnosis start time received by the instruction receiving means until the scheduled diagnosis end time. The vulnerability diagnosis execution apparatus according to claim 3 or 4, wherein the diagnosis schedule is created so that diagnosis ends in a time zone.   The said schedule preparation means produces the said diagnosis schedule so that a diagnosis implementation time may be ensured preferentially to the host whose diagnosis end scheduled time received by the instruction reception means is prioritized. The vulnerability diagnosis execution apparatus described.   In the diagnosis schedule created by the schedule creation means, when there is a schedule that does not end at the scheduled diagnosis end time received by the instruction receiving means, an alarm indicating that there is a schedule that does not end at the scheduled diagnosis end time The vulnerability diagnosis execution apparatus according to claim 5 or 6, further comprising an alarm output means for transmitting a message to the manager terminal. The instruction receiving means receives the number of hosts that can be executed simultaneously from the administrator terminal,
The schedule creation means is vulnerable to the host based on the calculated predicted diagnosis time and the accepted scheduled date and time within the range of the number of simultaneously executable hosts accepted by the instruction acceptance means. The vulnerability diagnosis execution apparatus according to any one of claims 1 to 7, wherein a diagnosis schedule for performing diagnosis is created.   The diagnostic schedule created by the schedule creation means is displayed and output on a predetermined display unit, recombination of the diagnostic schedule created from the administrator terminal is accepted, and a new diagnostic schedule is recreated based on the accepted recombination The vulnerability diagnosis execution apparatus according to any one of claims 1 to 7, further comprising a schedule re-creation unit for performing the schedule re-creation. A diagnostic schedule creation program to be executed by a computer as a vulnerability diagnosis execution device for performing vulnerability diagnosis on a host indicating various devices,
Corresponding to a host name that uniquely identifies the host that has performed the vulnerability diagnosis, a vulnerability diagnosis history including a diagnosis item performed on the host and a diagnosis execution time indicating a time required for the diagnosis is stored. Diagnostic history storage means,
An instruction reception procedure for receiving a scheduled date and time for performing the vulnerability diagnosis and a host name to be diagnosed on the scheduled date and time from an administrator terminal that instructs execution of the vulnerability diagnosis;
A diagnosis history extraction procedure for extracting a vulnerability diagnosis history corresponding to the host name accepted by the instruction acceptance procedure from the diagnosis history storage means;
A predicted diagnosis time calculation procedure for calculating a predicted diagnosis time required when a vulnerability diagnosis is performed on the host based on the vulnerability diagnosis history extracted by the diagnosis history extraction procedure;
A schedule creation procedure for creating a diagnosis schedule for performing vulnerability diagnosis on the host based on the predicted diagnosis time calculated by the predicted diagnosis time calculation procedure and the scheduled date and time received by the instruction reception procedure;
A diagnostic schedule creation program for causing a computer to execute

Images