JP4624181B2 - Unauthorized access countermeasure control device and unauthorized access countermeasure control program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To detect unauthorized access in real time to take a proper defensive countermeasure without inducing performance reduction or development burden. <P>SOLUTION: An event monitoring part 4 always monitors a sign of unauthorized access in accordance with a set file K and notifies a after-mentioned software control part 6 about the showing of sign of unauthorized access when it shows. When notified by the event monitor part 4, the software control part 6 executes periodical executive software 7 by dynamic scheduling according to the set file A. The periodical executive software 7 detects unauthorized access on the basis of detailed processing of large computational complexity in accordance with control of the software control part 6. A countermeasure taking part 8 takes a defensive countermeasure against the detected unauthorized access in response to a request from the software control part 6. <P>COPYRIGHT: (C)2006,JPO&amp;NCIPI

Description

  The present invention relates to an unauthorized access countermeasure control apparatus and an unauthorized access countermeasure control program.

  There are two types of unauthorized access: when an attacker makes an attack from the inside of a terminal (hereinafter referred to as an internal attack), and when an attack is performed from outside the terminal (hereinafter referred to as an external attack). Conventionally, as a countermeasure against an internal attack, software of a format that inspects the occurrence of unauthorized access by regularly executing specific application software that is standard on an administrator or OS has been used. . Software that mainly targets unauthorized access detection that occurs inside a terminal, such as some antivirus software, file falsification detection software, and security policy monitoring software, is known. Hereinafter, such software is referred to as periodic execution type software.

  The periodic execution type software performs inspection after a certain time has elapsed since the occurrence of unauthorized access, and therefore, unauthorized access discovery is slow. Therefore, there is a problem that an attacker who performs unauthorized access can continue to cause damage to the system until the unauthorized access is detected and the administrator implements countermeasures.

For this reason, the required technical requirements are as follows.
Requirement 1 An internal attack can be detected in real time.
Requirement 2 In addition to detection, defense measures against attacks can be automatically implemented.

  As an existing countermeasure against an internal attack that satisfies the above requirements 1 and 2, for example, there is a technique for detecting access to a specific file within the OS and automatically changing an access control rule (for example, Patent Documents). 1).

  As a conventional technique, a technique for protecting a system after detecting unauthorized access has been proposed (see, for example, Technical Document 2). The function that protects these systems is called a countermeasure execution function. This countermeasure execution function extracts information necessary for performing defense from the warning generated by the above-described periodic execution software that detects unauthorized access, and executes the defense. In addition, these countermeasure execution functions are developed for each software in order to input a warning for unauthorized access detection software.

Conventionally, the setting for using the countermeasure execution function is a format for setting the countermeasure to be implemented for each warning generated by the periodic execution type software that detects unauthorized access. A technique for outputting a warning when it occurs has been proposed (see, for example, Patent Document 3).
JP 2004-126634 A JP 2001-57554 A JP 2003-233521 A

However, the prior art of Patent Document 1 has the following problems.
Introducing a detection method with a large amount of calculation for detecting unauthorized access within the OS leads to a large performance degradation, and thus a simple detection method must be relied upon. Accordingly, since unauthorized access can be detected in real time due to the technology in the OS, there is a problem with the types of attacks that can be detected. In addition, in order to detect when a new unauthorized access occurs, “Indication of unauthorized access (hereinafter referred to as signature) must be introduced. There is a problem that it takes.

Therefore, the following additional requirements are added.
Requirement 3 A complex detection algorithm can be introduced.
Requirement 4 The signature does not need to be developed independently.
Further, the conventional technique of Patent Document 2 has a problem that it takes a cost to develop a countermeasure execution function. Furthermore, in the prior art of Patent Document 3, it is necessary to make all settings related to defense in advance, so it is impossible to defend based on the situation at the time of the attack (the past attack history, the system situation at the time of the attack, etc.). There's a problem. Therefore, only a certain amount of defense is always performed, and effective defense is not achieved.

  The present invention has been made to solve the above problems, and its purpose is to detect unauthorized access in real time without incurring performance degradation or development burden, and to provide appropriate defense against unauthorized access. An object of the present invention is to provide an unauthorized access countermeasure control apparatus and an unauthorized access countermeasure control program capable of implementing countermeasures.

  In order to solve the above-described problem, the present invention is an unauthorized access countermeasure control apparatus in a computer system including a kernel space that is an OS space and an AP space that is an application space, and includes an indication of unauthorized access in the kernel space. An event monitoring unit that monitors an event executed by the OS based on a monitoring event definition table that defines an event to be, and notifies an AP space when an event that is a sign of unauthorized access occurs, An unauthorized access countermeasure control apparatus comprising: an unauthorized access detection unit that detects unauthorized access in an AP space; and a software control unit that receives the notification from the event monitoring unit and executes the unauthorized access detection unit. It is.

  In the above invention, the present invention includes a countermeasure execution unit that performs countermeasures against unauthorized access in the AP space, and the software control unit acquires a result of unauthorized access detection by the unauthorized access detection unit, and Based on the detection result, a countermeasure is specified, and the countermeasure implementation means is notified of the countermeasure.

  The present invention, in the above invention, further includes a countermeasure execution unit that executes a countermeasure against unauthorized access in the AP space, and the countermeasure execution unit causes the countermeasure execution unit to execute based on the notified countermeasure. It is characterized by that.

  According to the present invention, in the above-described invention, in the AP space, a change determination unit that determines whether or not a defense measure has been changed based on a history of unauthorized access, and unauthorized access based on a change in the defense measure by the change determination unit. Dynamic setting change means for dynamically changing countermeasure execution means to be executed, wherein the countermeasure execution means causes the countermeasure execution means to be executed based on a change by the dynamic setting change means. And

  In addition, the present invention is a program for taking countermeasures against unauthorized access in a computer system comprising a kernel space that is an OS space and an AP space that is an application space, and defines an event that is a sign of unauthorized access in the kernel space. Monitoring an event executed by the OS based on the monitoring event definition table, and notifying the AP space when an event that is a sign of unauthorized access occurs; and in the AP space, from the OS space The unauthorized access countermeasure control program is characterized by causing a computer to execute the unauthorized access detection process upon receiving the notification.

  According to the present invention, in a kernel space, an event executed by an OS is monitored by an event monitoring unit based on a monitoring event definition table that defines an event that is an indication of unauthorized access, and an event that is an indication of unauthorized access In the AP space, the software control unit receives a notification from the event monitoring unit and executes unauthorized access detection means for detecting the unauthorized access in the AP space. . Therefore, there is an advantage that unauthorized access can be detected in real time without incurring performance degradation or development burden.

  In addition, according to the present invention, in the AP space, there is provided countermeasure implementation means for taking countermeasures against unauthorized access, and the software control unit acquires the result of unauthorized access detection by the unauthorized access detection means, and obtains the result of unauthorized access detection. Based on the above, measures are identified and the measures are notified to the measure implementation means. Therefore, there is an advantage that appropriate defense measures can be taken against unauthorized access.

  According to the present invention, the AP space includes a countermeasure execution unit that executes a countermeasure against unauthorized access. The countermeasure execution unit executes the countermeasure execution unit based on the notified countermeasure. It has become. Therefore, the existing countermeasure execution function can be reused, and the cost of developing the countermeasure execution function can be reduced.

  Further, according to the present invention, in the AP space, a change determination unit that determines whether or not a defense measure has been changed based on a history of unauthorized access, and an execution for unauthorized access based on a change in the defense measure by the change determination unit Dynamic setting change means for dynamically changing the countermeasure execution means to be performed, and the countermeasure execution means is configured to execute the countermeasure execution means based on the change by the dynamic setting change means. Therefore, according to the situation at the time of unauthorized access occurrence, the defense to be implemented can be changed dynamically, and there is an advantage that effective defense can be realized compared with the case where all are set in advance .

  Hereinafter, an unauthorized access countermeasure control apparatus according to an embodiment of the present invention will be described with reference to the drawings.

A. Configuration of Embodiment FIG. 1 is a schematic block diagram showing a configuration of a computer system to which an unauthorized access countermeasure control apparatus according to this embodiment is applied. In the figure, a computer system 1 includes a kernel space 2 that is an OS and an AP space 3 that is an application. The kernel space 2 includes an event monitoring unit 4 and an event processing unit 5. The event monitoring unit 4 monitors the occurrence of an event for the system according to the setting file K. In particular, in this embodiment, a sign of unauthorized access is constantly monitored, and when a sign occurs, the software control unit 6 described later is notified. The event processing unit 5 executes processing corresponding to the (normal) event detected by the event monitoring unit 4. Performs processing corresponding to the (normal) event detected by the event monitoring unit 4.

  The AP space 3 includes a software control unit 6, periodic execution type software 7, and countermeasure execution unit 8. Upon receiving the notification from the event monitoring unit 4, the software control unit 6 dynamically schedules and executes the periodic execution type software 7 according to the setting file A, collects the results, and implements countermeasures according to the results. Requests part 8 to execute defense measures. The periodic execution type software 7 is a means for detecting unauthorized access, and detects unauthorized access based on detailed processing with a large amount of calculation in accordance with a dynamic schedule by the software control unit 6. Here, the periodic execution type is assumed, but the periodic execution type is not necessarily required. The countermeasure implementation unit 8 executes the defense countermeasures according to the request from the software control unit 6. Defensive measures include, for example, blocking communication by changing firewall filtering rules, blocking sessions, forensics function (obtaining detailed logs of processes that have performed unauthorized access), and preventing startup of attack processes (other than pre-defined processes) , Process lockout), account lockout, alert function to attackers (function intended to stop attacks by sending alerts to attackers), user arbitrary command execution, etc. Reference numerals 9-1 to 9-n denote external devices.

Here, the signs of unauthorized access assume the following.
(A) Writing / deleting OS and server programs to / from programs and setting files (b) Starting programs other than programs executed when the OS is started (c) Stopping daemon programs that are executed when the OS is started (D) Setting file allocated for each user (e) Other, write / erase of files defined by the administrator (f) Other, execution / stop of programs defined by the administrator

  Next, the setting file K described above will be described. The setting file K includes a monitoring event information table (EIT), a monitoring event table (ET), an exception event table (EET), and a prohibited event table (PET).

  Here, FIG. 2A shows a monitoring event information table (EIT), and FIG. 2B is a conceptual diagram showing a monitoring event table (ET). The monitoring event information table (EIT) is information for managing the type of event to be monitored. The event ID uniquely assigned to each event, each event name, and the monitoring target process (system) corresponding to the event Call) address. The monitoring event table (ET) is information for managing parameters of events to be monitored, and includes an event ID and a name of each monitoring target. A monitoring event is composed of a set of event types and parameters.

  FIG. 3A shows an exception event table (EET), and FIG. 3B is a conceptual diagram showing a prohibited event table (PET). The exception event table (EET) is information for managing an exception to be monitored, and includes an event ID, each exception target name, and an exception condition. For example, when a directory is designated as an ET event name, a file below the directory that is not to be monitored is described. The prohibited event table (PET) is information for designating what prohibits event execution, and includes an event ID, a name of each prohibited object, and a prohibited condition. For example, writing to a periodic execution type tool, erasing, etc. are described.

  Next, the setting file A described above will be described. The setting file A includes a common setting (CC), a monitoring event information table (EIT ′), a defense process information table (DIT), and a defense process table (DT).

  Here, FIG. 4A shows a common setting (CC), and FIG. 4B is a conceptual diagram showing a monitoring event information table (EIT ′). The common setting (CC) is information for managing information related to the periodic execution software, and includes the name of the periodic execution software, the path name to the periodic execution software, the options necessary for executing the periodic execution software, and the periodic execution software It consists of criteria (described with regular expressions) for determining unauthorized access from the execution result of. The monitoring event information table (EIT ') includes an event ID and each event name.

  Next, FIG. 5A shows a defense process information table (DIT), and FIG. 5B is a conceptual diagram showing a defense process table (DT). The defense process information table (DIT) is information for managing information related to the defense process, and includes a defense measure ID, a name of each defense measure, an address to the defense measure process, and a parameter type. The defense process table (DT) includes an event ID, a name of each monitoring target, and a defense measure ID.

B. Operation of Embodiment Next, the operation of the above-described embodiment will be described. Here, FIG. 6 is a block diagram showing a data flow for explaining the operation of the present embodiment. The event monitoring unit 4 monitors the occurrence of an event for the system according to the setting file K, and notifies the software control unit 6 when an indication of unauthorized access occurs (S1). The software control unit 6 causes the periodic execution type software 7 to be executed according to the event (S2). The periodic execution type software 7 detects unauthorized access based on detailed processing with a large amount of calculation according to the dynamic schedule by the software control unit 6. The software control unit 6 collects the results (S3), and requests the countermeasure implementation unit 8 to execute the defense measures according to the results (S4). The countermeasure implementation unit 8 executes the defense countermeasures according to the request from the software control unit 6 (S5).

  Next, the operation described above will be described in detail. Here, FIGS. 7 and 8 are flowcharts for explaining the operation of the event monitoring unit 4. In the event monitoring unit 4, when a program in the AP space 3 calls a system call (a request is issued), the event monitoring unit 4 has an event E executed by the OS and is necessary for executing the event. Parameter P is input. The event monitoring unit 4 first determines whether or not the event E matches the event name in the monitoring event information table (EIT) shown in FIG. 2A (Sa1). If there is no match, the process ends.

  On the other hand, if there is a match, the event ID (.E) of the matched entry is passed to the processing routine, and the process described in the “address to monitored process” of the matched entry is executed (Sa2). ). The detailed process of step Sa2 will be described later.

  Then, when it is determined in step Sa2 that no notification is given, the process is terminated. On the other hand, when the result of notification is obtained, the software control unit 6 is notified in the first format that takes the form of “monitor target name: pid = 123: uid = 12: event ID”, for example (Sa3 ). Then, the process ends.

  Next, the process of step Sa2 will be described. First, when the parameter P is different from the format of the monitoring target name in the monitoring event table (ET) shown in FIG. 2B, the parameter P is converted with reference to information in the OS (Sb1). For example, when the parameter P is a process ID, but the monitoring target name indicates a process name, conversion is performed.

  Next, with reference to the prohibited event table (PET) shown in FIG. 3B, it is checked whether there is an entry in which the event ID == E and the prohibited object name == P in the prohibited event table (PET). (Sb2). If there is an entry that satisfies the above condition, it is determined as an execution prohibition event, a value indicating that the event indicated by E or P has failed in the AP space is returned (Sb5), and the process is performed without notification. finish. On the other hand, if there is no entry that satisfies the above condition, the event ID == E and P == monitoring event of the monitoring event table (ET) are referred to by referring to the monitoring event table (ET) shown in FIG. It is checked whether there is an entry satisfying the monitoring target name in the table (ET) (Sb3). If there is no entry that satisfies the above condition, the process is terminated with no notification.

  On the other hand, when there is an entry that satisfies the above condition, the event ID == E and P == exception of the exception event table (EET) are referred to by referring to the exception event table (EET) shown in FIG. It is checked whether there is an entry that satisfies the exception target name in the event table (EET) (Sb4). If there is an entry that satisfies the above condition, the process is terminated without notification. In any case, the process indicated by the address to the monitoring target process of event ID == E in the monitoring event information table (EIT) is executed, and the result is returned to the AP space (Sb6).

  Next, the operation of the software control unit 6 will be described. Here, FIG. 9 is a flowchart for explaining the operation of the software control unit 6. A notification from the event monitoring unit is input to the software control unit 6. First, the software control unit 6 executes the periodic execution type software using the information of the common setting (CC) shown in FIG. 4A (Sc1). Next, the execution result of the periodic execution type software is collected (Sc2), and it is determined whether the collected result matches the unauthorized access determination criterion of the common setting (CC) (Sc3). And when it does not match unauthorized access judgment criteria, that is, when it is not unauthorized access, the process is terminated.

  On the other hand, if it matches the unauthorized access determination criteria, that is, unauthorized access, the monitoring event information table (EIT ′) shown in FIG. 4B and the defense processing table (DT) shown in FIG. , It is checked whether there is an entry in which the event ID == E in the monitoring event information table (EIT ′) and the monitoring target name == P in the defense processing table (DT) exist (Sc4). If there is no entry that satisfies the above condition, the process ends. On the other hand, if there is an entry that satisfies the above condition, the countermeasure implementation unit 8 is notified in a second format that takes the form of “monitoring target name: pid = 123: uid = 12: defensive countermeasure ID”, for example. (Sc5). Then, the process ends.

  Next, the operation of the countermeasure implementation unit 8 will be described. Here, FIG. 10 is a flowchart for explaining the operation of the countermeasure implementation unit 8. The countermeasure execution unit 8 receives a notification from the software control unit 6. The countermeasure implementation unit 8 searches for a location where the defense measure ID of the matched defense processing table (DT) == defense measure ID in the defense processing information table (DIT) shown in FIG. 5A (Sd1), and the matched location The process at “address to defense countermeasure process” is executed (Sd2). Then, the process ends.

C. Example A case where a user with a user ID (uid) 3 performs an attack using a process with a process ID (pid) = 2100 will be described.

  The attacker's action is to write to / bin / su so that it does not operate normally, and close the file (to the OS for writing execution, request (event), that is, "close file number to close" publish).

  Further, the process of the event monitoring unit 4 is as follows. In response to the writing, the event monitoring unit 4 receives an event. Next, it is checked whether or not “close” is in the event name of the monitoring event information table (EIT) (at the place of event ID == 2) (Sa1). The parameter for the event close in the monitoring event table (ET) is “file descriptor”, not a file name. Therefore, using the information in the OS, it is determined that / bin / su is a file to be closed (Sa2: Sb1).

  Then, a place where event ID == 2 in the prohibited event table (PET) and a monitored object name == / bin / su in the prohibited event table (PET) is searched (in this case, it cannot be found) ( Sb2). Next, a place where the event ID == 2 in the monitoring event table (ET) and the monitoring target name == / bin / su in the monitoring event table (ET) is searched (in the top entry) (Sb3). Also, a location where the event ID == 2 in the exception event table (EET) and the monitored object name == / bin / su in the exception event table (EET) is searched (in this case, it cannot be found) ( Sb4). Thereafter, the process (0xC0119922) indicated by the address to the monitoring target process of event ID == 2 in the monitoring event information table (EIT) is executed, and the result is returned to the AP space (Sb6). Then, the occurrence of the monitoring event is notified to the software control unit 6 in the first format, that is, in the format of “/ bin / su: pid = 2100: uid = 3: 2” (Sa3).

  The processing of the software control unit 6 is as follows. The notification from the event monitoring unit 4 is received, the periodic execution software is executed using the information of the common setting (CC) (Sc1), and the result is collected (Sc2). FIG. 11 is a diagram illustrating an example of a result when the periodic execution software is executed. In this example, the criterion for determining unauthorized access is “* [BAD]. In FIG. 11, since it is [BAD] at / bin / su, this matches the criterion for fraud. Next, it is checked whether the event ID (== 2) included in the notification from the event monitoring unit 4 is in the monitoring event information table (EIT ′) (in this case, the third entry Next, referring to the defense processing table (DT), the event ID is 2 and the monitoring target name is / bin / su, and a defense measure ID is obtained (0x00000001) (Sc4). Then, the countermeasure implementation unit 8 is notified in the second format, that is, in the format of “/ bin / su: pid = 2100: uid = 3: 0x00000001” (Sc ).

  Then, the countermeasure implementation unit 8 refers to the defense process information table (DIT) (Sd1), and executes the address to the defense process at the location where the defense measure ID is 0x00000001 (Sd2).

D. Application example 1
Next, FIG. 12 is a block diagram illustrating an application example 1 of the above-described embodiment. The application example 1 is characterized by controlling a plurality of periodic execution type software 7-1 to 7-n. This application example 1 prepares a plurality of software having similar purposes (for example, a plurality of virus detection software having different detection methods), and (a) the event monitoring unit 4 notifies the software control unit 6 of the event, (B) The periodic monitoring software 7-1 to 7-n can be executed. Alternatively, a plurality of pieces of software having different purposes (for example, virus detection software and security policy monitoring software) are prepared, and one of the periodic execution type software 7-1 to 7-n is executed according to the type of event. Thus, it is possible to cope with different types of unauthorized access at the same time. Furthermore, if the execution result of the periodic execution type software 7-1 determines unauthorized access, the periodic execution type software 7-2 is activated and further detailed inspection is performed to enhance the detection capability. Is possible.

E. Application example 2
Next, FIG. 13 is a block diagram illustrating an application example 2 of the above-described embodiment. The application example 2 is characterized in that, in addition to controlling a plurality of periodic execution type software 7-1 to 7-n, existing countermeasure execution software 9-1 to 9-n are also controlled. In this application example 2, it is possible for the periodic execution type software 7-1 to 7-n to execute the existing countermeasure execution software 9-1 to 9-n to obtain a function for preventing attacks such as unauthorized access. To do.

  Note that the countermeasure execution software 9-1 to 9-n is a program for the defense means against the attack described in the above-described requirement 2, that is, “because not only detection but also defense countermeasures against attacks can be automatically implemented”. It is. At the time of intrusion detection, it is used to reduce damage to the intrusion by not only detecting but also protecting against the intrusion. Examples of such defenses include changing firewall filtering rules and forcing attackers to log out.

  The countermeasure execution software 9-1 to 9-n receives the output from software that normally detects unauthorized access (hereinafter referred to as IDS (Intrusion Detection System)) and extracts necessary information to prevent attacks. Has the ability to implement means. Even if the warning is not input, it may be necessary to provide only necessary information as input. In this case, a program for extracting information necessary for the countermeasure execution program from a separate warning is required.

  The countermeasure execution software 9-1 to 9-n depend on the IDS output format and contents, and are therefore created independently for each software that detects unauthorized access. For this reason, the countermeasure execution software created for a certain IDS cannot be used for another IDS. Therefore, it is necessary to develop countermeasure execution software for each IDS, which is costly.

In particular, IDS and periodic execution type software (hereinafter referred to as periodic execution type IDS) does not detect when an intrusion occurs, and therefore is a countermeasure execution program developed for the purpose of protecting when an intrusion occurs. Is not suitable. For this reason, there are few countermeasure execution programs for the periodic execution IDS. Therefore, we would like to use an existing countermeasure execution program without developing a countermeasure execution program for each periodic execution type IDS. Therefore, the following requirements are born.
Requirement a: An arbitrary periodic execution type IDS can execute an existing countermeasure execution program.

In addition, since the periodic execution type IDS is often used for the purpose of detecting intrusion inside the host, for example, when an attack is performed via a network, the IP address of the attacking source host is included in the warning of the periodic execution type IDS. I can't. As described above, there may be a case where the information required by the countermeasure execution program is not included in the periodic execution type IDS warning. Therefore, the following requirements also arise.
Requirement b: When information not included in the periodic execution type IDS warning is required as an input of the intrusion prevention function, it can be automatically supplemented.

  That is, in the application example 2, not only the intrusion is detected in real time using the periodic execution type IDS but also an appropriate countermeasure is taken against unauthorized access using an existing countermeasure execution program. .

  In the application example 2, the software control unit 6 holds setting information and a table (DIT ′) illustrated in FIGS. 14 to 21. Hereinafter, the setting information and the table will be described. Each table is used when the software control unit 6 holds contents set in advance by the user as an internal structure.

  Common settings (CC'-1, CC'-2) shown in FIGS. 14 and 15A, 15B are common settings for realizing the second application example. Since the application example 2 uses a plurality of periodic execution type IDSs, the common setting (CC) shown in FIG. 4A is required by the number of the periodic execution type IDSs. Therefore, as shown in FIG. 14, the user sets one common setting (CC′−1) and the common setting (CC′−2) shown in FIGS. 15A and 15B to the number of periodic execution type IDSs. Just prepare.

  In the common setting (CC′-1) illustrated in FIG. 14, a periodic execution type IDS that is executed when a notification from the event monitoring unit 4 is received is designated. FIGS. 15A and 15B are common settings (CC′-2, Alert Format Definition: AFD) in which the user defines the difference information of the warning of the periodic execution type IDS, and FIG. Is an alert format definition table (AFDT) used to hold setting contents as an internal structure.

  The type of information included in the periodic execution type IDS warning and the regular expression for extracting the information are described in a format surrounded by “” (double quotations) ”. Up to three pairs of information types and regular expressions can be described by separating them with “| (pipe)”. When a plurality of pairs are described, matching is further performed on the matching result of the previous regular expression. The information type can describe the attack source / attack destination IP address, the attack source / attack destination port number, the attack source / attack destination MAC address, the user ID of the attacker, the time when the attack was performed, and the like.

  Next, FIGS. 17 to 20 are conceptual diagrams showing the defense setting tables (DT′-1, DT′-2). Similar to the common setting, since a plurality of periodic execution type IDSs are used in this example, the defense setting may be different for each periodic execution type IDS. Therefore, the defense setting table shown in FIG. Become. Therefore, the user has one defense processing table (DT′-1) shown in FIG. 17 and one definition (DT′-3, Response Execution Rule: RER) related to the intrusion prevention function shown in FIG. The setting information (DT'-2, Response Decision Rule: RDR, Exception Rule: EXR) of the intrusion prevention function that is executed when the notification from the event monitoring unit 4 shown in FIG. Prepare as many as you want.

  In the defense processing table (DT′-1) illustrated in FIG. 17, a periodic execution type IDS that is executed when a notification from the event monitoring unit 4 is received is designated. In RDR (Response Decision Rules) and EXR (Exception Rules) shown in FIGS. 18A and 18B, an intrusion prevention function to be executed when a warning is generated for each periodic execution type IDS is designated.

  FIGS. 19A and 19B are conceptual diagrams showing tables used when the software control unit 6 holds these settings as an internal structure. There are two such settings: RDT (Response Decision Table) that determines the intrusion prevention function to be executed, and EXT (Exception Table) that specifies the exception. The user designates a countermeasure execution program to be executed after “->” in the RDR. This number is the Response ID in FIG. 19 and is a numerical value assigned to each countermeasure execution program. In EXR, an RDR exception is specified after “->”. For example, if [3] is set, the rules up to the second RDR are skipped and excluded from matching. In these two rules, an asterisk can be described as "" * "-> [1]". In this case, all cases are matched and can be used as default rules. FIG. 20 is a conceptual diagram showing definition information (RER: Response Execution Rule) related to the intrusion prevention function.

  Next, FIG. 21 is a conceptual diagram showing a defense processing information table (DIT ′) that is a setting for each countermeasure execution program. In this application example 2, since the existing countermeasure execution program is used, the DIT shown in FIG. 5B is as shown in FIG. The defense processing information table DIT 'describes the ID for each intrusion prevention function, whether or not it is necessary to stop after execution, and the input format required for execution. FIG. 21 is a table RET (Response Execution Table) used by the software control unit 6 to hold the setting contents as an internal structure.

  Next, FIG. 22 is a conceptual diagram showing an information supplement table (SIT: Supplement Information Table) and an information supplement function (SF: Supplement Functions). In the structure shown in FIG. 22, when the software control unit 6 matches the rules in the EXT and RDT with the warning of the periodic execution type IDS, the information type required by the EXT and RDT is the warning of the periodic execution type IDS. It is a structure for automatically complementing when it is not inside.

  In the information complementation table (SIT) shown in FIG. 22, the vertical axis indicates information types to be supplemented, and the horizontal axis indicates information types necessary for complementation. The information complementing function (SF) fulfills the function of complementing, and is a set of programs whose names are obtained by connecting the vertical axis and the horizontal axis of the information complementing table (SIT) with underbars like PID_SIP. The software control unit 6 refers to the information completion table (SIT), and by sequentially browsing ● / × (can be complemented / impossible), the software control unit 6 can grasp what information is necessary to complement certain information. it can. Further, since the information in the warning can be known by referring to the warning format definition table (AFDT) shown in FIG. 16, it is possible to determine whether or not the supplement is possible by matching with the information supplement table SIT and using the information in the warning. It is. Further, it is possible to perform complementation by executing the information complementation function SF of “information name to be complemented_information name necessary for complementation” like “SIP_PID”.

  Next, the operation of the application example 2 will be described with reference to FIGS. 14, 16, 17, 19, 21, and 22. A description will be given based on the example described in the embodiment. The operation of the event monitoring unit 4 is the same as the above-described C.I. It is the same as that of an Example. Therefore, the description will be made from the point where the software control unit 6 receives the notification from the event monitoring unit 4 (Sa3 in FIG. 7). FIG. 23 is a flowchart for explaining the operation of the second application example.

  The software control unit 6 refers to the defense processing table (DT′-1) shown in FIG. 17 based on the event ID. Here, since event ID = 2, the first line corresponds. In the first line, since the ID of the periodic execution type IDS to be executed is “2”, when looking at the common setting (CC′−1) shown in FIG. 14 based on this value, / usr / sbin / rkhunter is It can be seen that this should be executed (Se1).

  Next, / usr / sbin / rkhunter is executed and the result is collected (Se2). Next, using the warning format definition table (AFDT) shown in FIG. 16, the RDT shown in FIG. 19A, and the EXT shown in FIG. 19B, it is determined whether the collected result is an unauthorized access (Se3). If it is not unauthorized access, the process is terminated. On the other hand, when the access is unauthorized, the countermeasure execution unit 8 is notified (Se4).

  Next, FIG. 24 is a flowchart for explaining an operation for determining a defense measure program to be executed in step Se4. The defense measure program is determined by first referring to EXT, then determining the reference start point of the RDT to be referenced (Sf1), and then determining the defense measure program (ID) to be executed with reference to the RDT. (Sf2).

  Next, FIG. 25 is a flowchart for explaining the operation when referring to the EXT and RDT. When referring to the EXT and RDT rules, the software control unit 6 sequentially searches the information included in the rules by referring to the AFDT for information types described in the rules (Sg1). . If the information type described in the rule does not exist in the warning, it is determined whether or not the information complement is possible with reference to the information complement table (SIT) shown in FIG. 22 (Sg2). Here, if information complementation is impossible, the process is terminated. On the other hand, if information supplementation is impossible, information is supplemented sequentially.

  On the other hand, if the information type described in the rule is present in the warning or can be complemented, matching is performed with the condition described in each rule (Sf3). If there is no matching rule, the process ends. On the other hand, if there is a matching rule, “monitoring target name: pid = attacker process ID: uid = attacker user ID: defense countermeasure ID: CC′−1 of the periodic execution type IDS The countermeasure execution unit 8 is notified in a third format of “ID: IDS warning”.

  In this example, first, the first line of EXT shown in FIG. 19B is referred to, but the SIP is also notified from the event monitoring unit 4 (Sa3 in FIG. 7) in FIG. Is not included in the notification). Therefore, referring to the information supplement table (SIT) shown in FIG. 22, it can be understood that a PID is sufficient to supplement SIP. Therefore, the SIP_PID program is executed to obtain SIP. FIG. 26 shows an example of SIP_PID. Thereafter, the obtained SIP and 192.168.8.0. [0-9] A matching process of {1, 3} is performed. In the case of matching, according to the rule, the reference start point of RDT is 4 (see FIG. 19B). In this case, since there is no fourth line in the RDT, the process ends. If there is no matching, the reference is made from the first line of the RDT. Here, the description will be continued assuming that there is no matching.

  Next, the software control unit 6 refers to the first line of the RDT shown in FIG. FILENAME described in the first line of the RDT is included in the notification shown in Sa3 in FIG. More precisely, it is matched with the definition of FILENAME in the warning format definition table (AFDT) shown in FIG. 16 to obtain / bin / su. Since / bin / su is described in the first line of the RDT, the software control unit 6 can consider that the first line of the RDT matches the warning of the periodic execution type IDS. Therefore, it is determined to execute defense countermeasure ID = 1 described in the matched rule. Therefore, a defense measure execution request is sent to the measure execution unit in a third format that takes the form “/ bin / su: pid = 123: uid = 12: 1: 2: warning shown in FIG. 11”.

  When receiving the notification, the countermeasure execution unit 8 refers to the defense processing information table (DIT ′) based on the defense countermeasure ID included in the notification. Here, since the defense measure ID = 1, RECOVER_FILE is executed.

  The countermeasure execution unit 8 refers to the command column in the column of the countermeasure countermeasure ID = 1. Since the one with $ at the head is regarded as a variable, it can be extracted from the received notification while referring to the warning format definition table (AFDT) of FIG. Here, since FILENAME is applicable, / bin / su is applied as $ FILENAME, and it is possible to implement a defense measure program.

  As shown in FIG. 13, the application example 2 has been described on the assumption of a plurality of periodic execution type IDSs, but it is not necessarily limited to the periodic execution type IDSs. When the constant monitoring IDS is used, the process may be started from step Se2 shown in FIG. At that time, the software control unit 6 assigns sockets, pipes, and file monitors for receiving warnings for each IDS, and uses these warning receiving resources and information set for each IDS in pairs. Become.

F. Application example 3
Next, FIG. 27 is a block diagram illustrating an application example 3 of the above-described embodiment. In the application example 3, in addition to controlling a plurality of periodic execution type / always monitoring type IDSs and existing countermeasure execution programs, a new function for dynamically changing a defense means to be implemented for a warning is provided. It is characterized by having.

Here, the following four points are assumed to dynamically change the defense means to be implemented against the warning, but the number is not necessarily limited to four.
(1) Intrusion prevention function switching-Switches the intrusion prevention function specified by RDR (Response Decision Rule). For example, the TCP attack is set to block connections, but in order to impose a heavy penalty on many attacking IP addresses, the firewall settings are changed and the function of denying access is executed one day. It is to be.

(2) Intrusion prevention function added-When executing the intrusion prevention function specified by RDR, other intrusion prevention functions are also executed. For example, when the local user falsifies the system configuration file many times, only the configuration file is restored, but the attacker is also forced to log out.

(3) Execution period extension-When executing a certain intrusion prevention function, the interface also stops when the time indicated by EXPIRED_TIME in FIG. 5 elapses, but extends the time. For example, this is used to extend the account lockout period.

(4) Execution with time restriction-A process for repeatedly executing a process for executing a certain intrusion prevention function from a certain time until a certain time elapses. For example, in order to deny access coming from a certain IP address from midnight to 6:00, the process of closing the firewall is repeated every day.

  As in the conventional technique (Patent Document 2) described above, there has been a technique for implementing a defensive means after detecting an intrusion by using a constantly monitoring IDS. In using such a technique, the user performs a setting of “protect a certain warning with a specific function” before starting the system. On the other hand, in a manual countermeasure, when an IDS warning is seen, a countermeasure is taken in consideration of the status of the system to be protected, intrusion actions, etc. that have occurred in the past. As an example of the system status of the protection target, “IDS warning shows that attack A was performed against the WWW server of one OS, but attack A was against the WWW server of another OS. Because this is done, this warning can be ignored. "

In addition, as an example of intrusion behavior that occurred in the past, “3.3.3.3/8 IP address is frequently attacked, so usually deal with only when there is an attack, For example, “Deny access to this address for a week”. As described above, in the conventional technology, there are matters that are not taken into consideration in manual countermeasures. For this reason, the conventional technology does not provide effective defense. Therefore, the following requirements occur.
Requirement A: Provide a function to dynamically change the protection measures to be implemented against warnings.

  As an example of such a technique, in Japanese Patent Laid-Open No. 2000-170727, the service provided by the host to be protected is automatically detected, and only the attack rules related to the provided service are incorporated into the IDS, thereby changing the IDS setting. Some reduce the amount of warning generated by IDS. In Japanese Patent Laid-Open No. 2003-66045, only the attack rules related to the port where the firewall is open are incorporated into the IDS, thereby changing the IDS setting and reducing the warning amount generated by the IDS. These techniques set IDS detection contents, and do not set defense contents.

In addition, these technologies rely on specific setting change criteria and are therefore scalable. The setting change criteria vary from those applying the analysis method to those of the manager's knowledge level described above, and therefore cannot be handled when different setting change criteria occur. Therefore, the following requirements are also born.
Requirement B: A user can change a plurality of arbitrary setting change criteria.

  Furthermore, these techniques change the attack rules read by the IDS. Since each IDS is usually developed independently, the IDS attack rule format differs for each IDS. Therefore, these existing technologies are realized in a format depending on a specific IDS.

Relying on a specific IDS is not a problem if all intrusions are detected with one IDS. However, for example, an IDS that monitors communication cannot normally monitor all intrusion activities with a single IDS so that encrypted communication cannot be monitored. Therefore, it is a normal operation mode to detect intrusion by combining a plurality of IDSs. Therefore, it is important that it can be realized by using an arbitrary IDS, and depending on a specific IDS is a problem. In addition, in the case of manual handling, knowledge obtained from an intrusion act detected by a certain IDS will be applied to other IDS. Therefore, it is important not only to be able to be realized using any IDS, but also to be possible to be realized in a format in which any IDS is combined. Therefore, the following requirements also arise.
Requirement C: The dynamic setting change function to be realized is applicable even when any IDS is used in combination.

When the dynamic setting change function is realized based on these requirements, the initial setting made by the user is rewritten (the setting corresponding to the method described so far is RDT and EXT shown in FIG. 18). ). It is assumed that rewriting these will change the initial settings performed by the user and cause confusion to the user later. Therefore, the following requirements also arise.
Requirement D: No change is made to the initial setting description made by the user.

  The application example 3 can detect an intrusion in real time using a periodic execution type IDS and can implement an appropriate defense measure against unauthorized access using an existing countermeasure execution program. Dynamic setting can be changed even in the combined format.

  In order to solve the above-described problem, the application example 3 is realized by the configuration shown in FIG. Compared with FIG. 13 showing the configuration of the application example 2, it has a plurality of change determination units 10-1, 10-2,. The change determination units 10-1, 10-2,..., 10-n may be arbitrary processing by the user. The dynamic setting change unit 10 manages these change determination units 10-1, 10-2,..., 10-n. Further, the application example 3 includes a defense history distribution table (DHDT) shown in FIG. 28 and a setting change transition diagram shown in FIG. 29 as dynamic setting change functions.

  First, the countermeasure implementation unit 8 receives a defense countermeasure execution request from the software control unit 6 and executes a countermeasure. After execution, it takes a form in which “: (colon)” is used to concatenate information used for countermeasure implementation and all information that can be complemented, such as “TIME: SIP: DIP: UID: PID:...” 4 is sent to the dynamic setting change unit 10. Henceforth, this 4th format is called defense history. The dynamic setting change unit 10 refers to the defense history distribution table (DHDT) shown in FIG. 28, and changes the received defense history according to the ID of the change determination unit described in the table. Assign to n.

  The change determination units 10-1 to 10-n that have received the defense history determine whether there is a need to change the settings based on an arbitrary determination criterion. When the need for change determination arises, the dynamic setting change unit 10 takes the form of “change target name: defense measure before change” in the fifth form, for example “UID = 12: RECOVER_FILE”. A setting change request is issued. This means “when RECOVER_FILE is performed for UID = 12, the setting is changed”. The dynamic setting change unit 10 determines the process after the setting change.

  The dynamic setting change unit 10 that has received the setting change request determines the content to be changed based on the transition diagram shown in FIG. Since it is assumed that there are a plurality of corresponding change determination units, the dynamic setting change unit so that the change determination units 10-1 to 10-n make conflicting setting changes and no contradiction occurs in the change contents. 10 is the format managed. In the above-described example, UID = 12 is set as a change target. In this case, a transition diagram is searched, and if UID = 12 already appears in the transition diagram, the setting change content is determined along the transition diagram. If UID = 12 does not appear in the transition diagram, the protection measure before the change is RECOVER_FILE, so that UID = 12 appears in the RECOVER_FILE column and the setting change content is determined by making the transition.

  After determining the setting change contents, the dynamic setting changing unit 10 takes the form of “name of change: defense measure before change: defense measure after change” such as “UID = 12: RECOVER_FILE: RECOVER_FILE, LOGOUT_FORCELY”. In the sixth format, a setting change request is made to the countermeasure implementation unit 8. When the countermeasure execution unit 8 that has received the setting change request receives a defense countermeasure execution request from the software control unit 6, the countermeasure execution unit 8 looks at these setting change requests to determine the necessity of changing the defense to be performed, and when necessary After making changes, implement defenses.

  It should be noted that the defense history distribution table (DHDT) shown in FIG. 28 and the transition diagram shown in FIG. 29 are described as setting contents by the user before the system is activated.

Next, a specific example of the application example 3 will be described. In the present embodiment, the following attacker is assumed.
(1) The password of the administrator authority (root) of a certain host is the same as the host name, the password is guessed by the attacker, and the attacker is allowed to log in with the administrator authority.

(2) The attacker rewrites the setting file (httpd.conf) of the WWW server and tries to go back to the home page published by the WWW server. However, the setting contents of the WWW server can be changed only at the time specified by the system operation policy. Therefore, with the technology described here, content changes outside the specified time are regarded as tampering and are automatically recovered. For this reason, the setting change by the attacker fails.

(3) When the attacker who tried changing the setting file of the WWW server several times noticed that the change failed, he decided to attack again later. So, this time, I'm trying to set up a back door, fearing that the root password will change.

  In response to such an attack, the change determination unit 10-i (i: 1 to n) that issues a request to “enhance the defense function to be implemented when an attack is performed by the same user within a certain period of time” is issued. An example of applying and preventing attacks is shown. FIG. 28 shows the change determination table at that time, and FIG. 29 is used for the transition diagram. In addition, in showing a flow, since the process of the software control part 6-countermeasure implementation part 8 was already described, it abbreviate | omits.

  The actual flow is as follows. Here, FIG. 30 is a flowchart for explaining the operation of the third application example. First, if the attacker is httpd. When tampering is performed on the conf, the tripwire detects the warning shown in FIGS. 31 and 32 according to the flowcharts shown in FIGS. 23 and 24 described above. In addition, the countermeasure execution unit 8 restores the falsified file. At this time, the countermeasure implementation unit 8 has a defense history in the form of “Thu May 1 20: 00: 30: 11 2005: tripwire: RECOVER_FILE: /usr/local/apache/conf/httpd.conf: 0: 1234. And sent to the dynamic setting changing unit (Sh1). It is assumed that “0” is a user ID and “11234” is a PID.

  The dynamic setting change unit 10 refers to the defense history distribution table and distributes the prevention history. In the above-described defense history example, since the first line in the table corresponds, the defense history is sent to the change history unit 1 (Sh2). Next, the change determination units 10-1 to 10-n determine whether or not a setting change is necessary (Sh3). In this case, since the attack has been performed only once, it is not necessary to change the setting, and the process is terminated.

  On the other hand, if an attacker makes httpdd. Since the defense history is accumulated in the change determination units 10-1 to 10-n while the conf is tampered with, the change determination unit 10-i determines that the setting needs to be changed. The setting change request is notified to the unit 10 in the format of “UID = 0: RECOVER_FILE” (Sh4).

  The dynamic setting changing unit 10 that has received the notification searches whether UID = 0 exists in the transition diagram (Sh5). In this case, since UID = 0 does not exist, an object having the attribute of UID = 0 is registered in the transition diagram (Sh6). Thereafter, the setting is changed along the transition diagram. In this case, in the transition diagram, not only RECOVER_FILE but also FORCE_LOGOUT is implemented. Therefore, the dynamic setting change unit 10 notifies the countermeasure implementation unit 8 in the format of “UID = 0: RECOVER_FILE: RECOVER_FILE, LOGOUT_FORCELY” (Sh7).

  Next, an attacker who has failed to falsify many times considers installing only a back door and attacking again at a later date. The backdoor to be created creates a new user “malicius” and changes the description of “malicius: x: UserID: GroupID ...” in / etc / passwd to “malicius: x: 0: 0. The ID and group ID are set to “0”. In other words, the user “malicius” has root authority, and even if the root password is changed, the user “malicous” has root authority, and thus can attack freely.

  This attack cannot be detected by a periodic execution type IDS that monitors only file changes such as tripwire. Therefore, although the use is limited, the rkhunter that determines that there is an attack is also detected by taking into account the changed contents of / etc / passwd. FIG. 33 and FIG. 34 show warnings output as detection results in accordance with the flowcharts shown in FIGS.

  The countermeasure implementation unit 8 tries to recover the file (RECOVER_FILE) because / etc / passwd has been falsified. However, since the setting change request described above has arrived from the dynamic setting change unit 10, not only RECOVER_FILE but also LOGOUT_FORCELY (forced logout of attacker) is executed.

As mentioned above, although the Example of this application example 3 was described, regarding the implementation content, it is not restricted to the matter mentioned above. Other possible implementation details are described below.
(1) In the application example 3, the dynamic setting change unit 10 distributes the change determination units 10-1 to 10-n every time receiving a defense history, but the distribution method is not particularly limited thereto. For example, distribution may be made after a certain number is accumulated.

(2) In the embodiment, the setting change target is singular (UID = 0). However, it is possible to specify the 192.168.2.1/24 equivalence range. Alternatively, a plurality of items may be specified together such as UID = 0 or UID = 10.

(3) In the embodiment, the change determination units 10-1 to 10-n exchange information with only the dynamic setting change unit 10, but for example, the defense sent from the software control unit 6 to the countermeasure execution unit 8 The change determination units 10-1 to 10-n may send the implementation request (third format) directly to the countermeasure implementation unit 8. Thereby, for example, the countermeasure execution unit 8 sends only the defense history to the change determination units 10-1 to 10-n via the dynamic setting change unit 10 without implementing the defense measures, and the change determination unit 10-1 In 10 to 10-n, it is possible to defend such as performing defense only after confirming the influence of the attack.

(4) In the application example 3, as the processing of the dynamic setting change unit 10, the setting change target is advanced along the transition diagram. However, for example, the setting change advanced along the transition diagram after a certain time has elapsed. For example, the object may be returned along the transition diagram.

  According to the above-described embodiment, it is possible to detect in real time an unauthorized access detected only after a lapse of a certain time, and a defense measure can be implemented. Detailed unauthorized access detection processing is performed by a third party application other than the OS and the user, so that even if a complicated detection means is applied, there is no significant performance degradation. In addition, since it is possible to use existing periodic monitoring type software, it is not necessary to independently develop signatures. In addition, since it can be applied to arbitrary periodic monitoring type software, it is versatile. In addition, the existing countermeasure execution function can be reused, and the cost for developing the countermeasure execution function can be reduced. Furthermore, the defense to be implemented can be dynamically changed in accordance with the situation at the time of unauthorized access occurrence, and effective defense is possible compared to the case where all are set in advance.

  The event monitoring unit 4, the software control unit 6, the periodic execution type software 7, and the countermeasure execution unit 8 are stored in a computer-readable recording medium in the form of a program, and the computer reads and executes the program. Thus, the above processing is performed. Here, the computer-readable recording medium means a magnetic disk, a magneto-optical disk, a CD-ROM, a DVD-ROM, a semiconductor memory, or the like. Alternatively, the computer program may be distributed to the computer via a communication line, and the computer that has received the distribution may execute the program.

It is a schematic block diagram which shows the structure of the computer system to which the unauthorized access countermeasure control apparatus by this embodiment is applied. It is a conceptual diagram which shows the monitoring event information table (EIT) and monitoring event table (ET) in the embodiment. It is a conceptual diagram which shows the exception event table (EET) and the prohibition event table (PET) in the embodiment. It is a conceptual diagram which shows the common setting (CC) and monitoring event information table (EIT ') in the embodiment. It is a conceptual diagram which shows the defense process information table (DIT) and defense process table (DT) in the embodiment. It is a block diagram which shows the data flow for demonstrating the operation | movement by this embodiment. 4 is a flowchart for explaining an operation of an event monitoring unit 4;・ 4 is a flowchart for explaining an operation of an event monitoring unit 4; 4 is a flowchart for explaining the operation of a software control unit 6. 5 is a flowchart for explaining the operation of a defense measure execution unit 8; It is a figure which shows an example of the execution result at the time of using "rootkithunter" as periodical execution software. It is a block diagram which shows the application example 1 of embodiment mentioned above. It is a block diagram which shows the application example 2 of embodiment mentioned above. It is a conceptual diagram which shows common setting (CC'-1). It is a conceptual diagram which shows common setting (CC'-2). It is a conceptual diagram which shows a warning format definition table (AFDT). It is a conceptual diagram which shows the defense process table (DT'-1). It is a conceptual diagram which shows the setting information (DT'-2) of an intrusion prevention function. It is a conceptual diagram which shows RDT and EXT. It is a conceptual diagram which shows the definition information (RER) regarding an intrusion prevention function. It is a conceptual diagram which shows the defense process information table (DIT '). It is a conceptual diagram which shows an information complementation table (SIT) and an information complementation function (SF). 10 is a flowchart for explaining the operation of application example 2; It is a flowchart for demonstrating the operation | movement for determining the defense countermeasure program to perform in step Se4. It is a flowchart for demonstrating the operation | movement at the time of referring EXT and RDT. It is a conceptual diagram which shows an example of an automatic information complementation function. It is a block diagram which shows the application example 3 of embodiment mentioned above. It is a key map showing a defense history distribution table (DHDT). It is a conceptual diagram which shows a setting change transition diagram. 14 is a flowchart for explaining an operation of the application example 3; It is a conceptual diagram which shows an example of the warning by tripwire. It is a conceptual diagram which shows an example of the warning by tripwire. It is a conceptual diagram which shows an example of the warning by rkhunter. It is a conceptual diagram which shows an example of the warning by rkhunter.

Explanation of symbols

4 Event monitoring unit (event monitoring means)
5 Event processing section 6 Software control section (software control means)
7,7-1 to 7-n Periodic execution type software (unauthorized access detection means, multiple unauthorized access detection means)
8. Countermeasure Implementation Department (Countermeasure implementation means)
9-1 to 9-n Countermeasure execution software (measure execution means)
10 Dynamic setting change section (dynamic setting change means)
10-1 to 10-n Change determination unit (change determination means)
K configuration file (monitoring event definition table)

Claims (5)

An unauthorized access countermeasure control apparatus in a computer system comprising a kernel space as an OS space and an AP space as an application space,
In the kernel space,
An event monitor that monitors an event executed by the OS based on a monitoring event definition table that defines an event that indicates an unauthorized access, and notifies the AP space when an event that indicates an unauthorized access occurs Part
In the AP space,
Unauthorized access detection means for detecting unauthorized access;
A software control unit that receives the notification from the event monitoring unit and executes the unauthorized access detection means;
An unauthorized access countermeasure control device comprising: In the AP space,
It has measures implementation means to take measures against unauthorized access,
The software control unit acquires a result of unauthorized access detection by the unauthorized access detection unit, specifies a countermeasure based on the unauthorized access detection result, and notifies the countermeasure implementation unit of the countermeasure. The unauthorized access countermeasure control device according to claim 1. In the AP space,
It has a measure execution means to execute defense measures against unauthorized access,
The unauthorized access countermeasure control apparatus according to claim 2, wherein the countermeasure execution unit causes the countermeasure execution unit to be executed based on the notified countermeasure. In the AP space,
A change determination means for determining whether or not a defense measure has been changed based on a history of unauthorized access;
Dynamic setting change means for dynamically changing countermeasure execution means to be executed against unauthorized access based on the change of defense measures by the change determination means,
4. The unauthorized access countermeasure control apparatus according to claim 3, wherein the countermeasure executing means causes the countermeasure executing means to be executed based on a change by the dynamic setting changing means. A program for preventing unauthorized access in a computer system comprising a kernel space that is an OS space and an AP space that is an application space,
In the kernel space,
A step of monitoring an event executed by the OS based on a monitoring event definition table that defines an event indicating an unauthorized access, and notifying the AP space when an event that indicates an unauthorized access occurs; and ,
In the AP space,
An unauthorized access countermeasure control program that causes a computer to execute a step of executing the unauthorized access detection process in response to a notification from the OS space.

Images