WO2022264239A1 - アラート検証装置、アラート検証方法及びアラート検証プログラム - Google Patents

アラート検証装置、アラート検証方法及びアラート検証プログラム Download PDF

Info

Publication number
WO2022264239A1
WO2022264239A1 PCT/JP2021/022590 JP2021022590W WO2022264239A1 WO 2022264239 A1 WO2022264239 A1 WO 2022264239A1 JP 2021022590 W JP2021022590 W JP 2021022590W WO 2022264239 A1 WO2022264239 A1 WO 2022264239A1
Authority
WO
WIPO (PCT)
Prior art keywords
attack
alert
communication data
unit
acquisition
Prior art date
Application number
PCT/JP2021/022590
Other languages
English (en)
French (fr)
Inventor
国雄 宮本
悠太 岩城
楊 鐘本
琴海 黒木
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2021/022590 priority Critical patent/WO2022264239A1/ja
Priority to JP2023528781A priority patent/JPWO2022264239A1/ja
Publication of WO2022264239A1 publication Critical patent/WO2022264239A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures

Definitions

  • the present invention relates to an alert verification device, an alert verification method, and an alert verification program.
  • Attack detection technologies include technologies such as WAF (Web Application Firewall) and NIDS (Network-based Intrusion Detection System). These are technologies that detect communications that match the features of pre-stored attack codes as attacks from network communications. However, although it is possible to detect attacks with these technologies, it is difficult to automatically determine whether or not the detected attack was successful. Success or failure will be revealed.
  • WAF Web Application Firewall
  • NIDS Network-based Intrusion Detection System
  • Stateful IDS defines the state transition when an attack succeeds, and detects that the attack has succeeded when the system performs the defined state transition
  • a method called correlation part product with vulnerability information that checks in advance whether the application and version targeted by the attack are being used, and if it is determined that they are being used, the attack is detected as successful. (see Alert Verification Determining the Success of Intrusion Attempts, DIMVA, 2004).
  • attack code emulation that detects that the attack has succeeded if the attack code is emulated and the same behavior is observed during execution (see On Emulation-Based Network Intrusion Detection Systems, RAID, 2014) ).
  • the following technology has been proposed as a conventional technology for determining whether an attack on a server by an attack code was successful.
  • One is to emulate an attack on the server according to the determined attack type, extract the characteristics that appear in the response when the server is successfully attacked, and extract the characteristics that appear in the response from the server. This is a technique for judging that an attack by an attack code has succeeded.
  • emulation of an attack to the server according to the attack type extracting the characteristics of the response when the attack is successful, and if at least one of the multiple responses after the attack request has the extracted characteristics , there is a technique for judging that an attack has succeeded.
  • the processes in these conventional techniques are executed, for example, as follows. First, it is determined whether the request is an attack. If the request is not an attack, it is determined that the success or failure of the attack cannot be determined. Also, if the request is an attack, an attack type determination process is performed to determine whether or not the attack type can be determined. If the attack type cannot be determined, it is determined that the success or failure of the attack cannot be determined. On the other hand, if the attack type can be determined, the attack code is analyzed, and the feature corresponding to the attack code is selected from the features appearing in the response. It is then determined whether the selected feature exists. If the selected feature does not exist, it is determined that the success or failure of the attack cannot be determined. On the other hand, if the selected feature exists, the feature inspection process is performed, it is determined whether or not the attack was successful, and the success or failure of the attack is notified according to the determination result.
  • a device that performs the attack success/failure determination process described above includes, for example, an attack detection unit, an attack type determination unit, an attack code analysis unit, a feature selection unit, and a feature inspection unit.
  • the attack detection unit detects whether the request is an attack.
  • the attack type determination unit uses a keyword list held in advance to determine the type of attack from the programming language of the attack code and the method of attack.
  • the attack code analysis unit prepares an emulator capable of executing the attack code according to the attack type using a keyword list and feature candidate DB held in advance, and executes the attack code with the emulator.
  • the feature selection unit uses a response DB storing information on responses and a feature DB storing information on features when an attack succeeds, and selects features unsuitable for handling as features when an attack succeeds from the obtained feature candidates. exclude.
  • the feature inspection unit uses the feature DB to inspect whether or not the communication or the like includes a feature output when the attack code obtained by the attack code analysis unit is executed. Such a technique for determining whether or not an attack code has successfully attacked a server is hereinafter referred to as an alert verification technique.
  • alert verification technology has the following problems. Packets of communications not detected as an attack are also parsed into HTTP requests or HTTP responses by the device implementing the alert verification technology. That is, in the apparatus implementing the alert verification technique, a communication packet is parsed into an HTTP request or HTTP response, and whether or not it is an attack communication is determined using information from an attack detection device such as WAF. As a result, the parsing processing load increases in a high-traffic environment, and the processing of the alert verification technology is greatly delayed. In this case, all communication packets are parsed into HTTP requests or HTTP responses, but communication that is the target of attack success/failure determination in the alert verification technology is communication that is determined to be an attack.
  • the present invention has been made in view of the above, and aims to reduce the processing load of attack determination processing by reducing the parsing processing of communication packets.
  • the receiving unit receives alerts sent from attack detection devices that detect attacks on monitored devices.
  • the generation unit generates acquisition conditions for communication data to be acquired based on the alert received by the reception unit.
  • the acquisition unit acquires the communication data that matches the acquisition condition generated by the generation unit from a packet capture device that holds data transmitted and received by the monitoring target device.
  • a success/failure determination unit determines success or failure of the attack based on the communication data acquired by the acquisition unit.
  • the parsing processing of communication packets can be reduced, and the processing load of attack determination processing can be reduced.
  • FIG. 1 is a schematic configuration diagram of a system in which an alert verification device is arranged.
  • FIG. 2 is a block diagram of the determination device according to the first embodiment.
  • FIG. 3 is a diagram showing an example of a keyword list classified by attack type.
  • FIG. 4 is a flowchart of attack success/failure determination processing by the determination device according to the first embodiment.
  • FIG. 5 is a diagram showing a second order attack in the second embodiment.
  • FIG. 6 is a diagram showing an attack spanning multiple sessions in the third embodiment.
  • FIG. 7 is a diagram showing a login bypass attack in the fourth embodiment.
  • FIG. 8 is a system configuration diagram according to the sixth embodiment.
  • FIG. 9 is a diagram illustrating an example of a computer that executes an alert verification program for attack success/failure determination processing.
  • alert verification device An embodiment of the alert verification device, alert verification method, and alert verification program disclosed in the present application will be described in detail below based on the drawings. Note that the alert verification device, alert verification method, and alert verification program disclosed in the present application are not limited to the following embodiments.
  • FIG. 1 is a schematic configuration diagram of a system in which an alert verification device is arranged.
  • a communication duplication device 2 and an attack detection device 3 are arranged on a communication path from the Internet to a Web server 1 .
  • a packet capture device 4 is connected to the communication duplication device 2 .
  • the alert verification device 10 is connected to the attack detection device 3 arranged on the communication path leading to the packet capture device 4 and the web server 1 .
  • Such a configuration in which the alert verification device 10 is connected to the attack detection device 3 through a path different from the path leading to the web server 1 is called a tap configuration.
  • a web application running on the web server 1 performs communication such as receiving requests, sending responses, and sending requests and receiving responses with PCs connected to the Internet. In the present embodiment, communication with respect to a web application will be described.
  • a request from the Internet to the Web server 1 may include an attack request.
  • the communication duplication device 2 duplicates the traffic to the web server 1.
  • the communication replication device 2 receives communication data transmitted and received between a PC or the like connected to the Internet and the Web server 1 and generates a replication.
  • the communication duplication device 2 then transmits the duplicated communication data to the packet capture device 4 .
  • the packet capture device 4 receives a copy of the communication data generated by the communication duplication device 2 and transmitted and received between a PC or the like connected to the Internet and the web server 1 . Then, the packet capture device 4 accumulates and holds the acquired communication data.
  • the attack detection device 3 is a device that has a function of detecting an attack request from network communication using technology such as WAF.
  • WAF Network Engineering Task Force
  • the attack detection device 3 receives an attack request sent from the Internet to the Web server 1 , it generates an alert indicating this attack request and sends it to the alert verification device 10 .
  • the alert includes, for example, the IP (Internet Protocol) address and port number of the source of the attack request, and the path part of the URL (Uniform Resource Locator).
  • the alert verification device 10 When an attack is detected, the alert verification device 10 receives an alert indicating attack detection from the attack detection device 3. The alert verification device 10 then acquires communication data associated with the alert from the packet capture device 4 . Then, the alert verification device 10 executes the attack code with an emulator corresponding to the attack type specified from the acquired communication data (for example, an attack type that exploits an OS (Operating System) command), and outputs the execution result to the Web server 1
  • the information output from is extracted as features output when an attack succeeds.
  • the alert verification device 10 inspects the response from the Web server 1, and determines that the attack was successful if the extracted feature is included in the response.
  • the alert verification device 10 when there is an attack request to the Web server 1, not only the response to the attack request, but also all subsequent responses that meet the predetermined conditions. may be subject to inspection.
  • the alert verification device 10 acquires from the packet capture device 4 the target communication data for attack success/failure determination, and suppresses the acquisition of other communication data, thereby reducing the processing load of parsing communication packets. .
  • FIG. 2 is a block diagram of the determination device according to the first embodiment.
  • the alert verification device 10 includes a storage unit 11, a communication data acquisition unit 121, an attack type determination unit 122, an attack code analysis unit 123, a feature selection unit 124, and a success/failure determination unit 125.
  • the storage unit 11 stores an attack type keyword list 111 , a feature candidate DB 112 , a request/response DB 113 and a feature DB 114 .
  • the attack type keyword list 111 is information indicating the keywords included in the attack code of each attack type for each attack type.
  • FIG. 3 is a diagram showing an example of a keyword list classified by attack type.
  • the attack type keyword list 111 is referred to when the attack type determination unit 122 determines the attack type from the keyword included in the attack code.
  • attack type is, for example, A. Attack type that exploits OS commands, B. Attack type that exploits program code, C. Attack type that abuses the SQL (Structured Query Language) command, which is a function of the DB (for example, SQL injection, etc.), D. Attack types that exploit HTTP (Hyper Text Transfer Protocol) responses (for example, XSS (Cross Site Scripting), Header Injection, etc.), E. Attacks that exploit file operations (for example, directory traversal) are classified into five types.
  • the above A. attack type the name of the OS command is used as a keyword.
  • the keyword is the named entity used in the programming language.
  • PHP Hypertext Preprocessor
  • PHP-specific functions such as print_r, var_dump, base64_decode, or PHP specific expressions ($_GET, $_POST, etc.) are keywords.
  • Other programming languages Java (registered trademark), Perl, Ruby, Python, etc.) are equivalent. Therefore, B. attack type, a keyword list 111 classified by attack type is held for each programming language. At this time, information on which programming language corresponds is held as a sub-attack type, as shown in FIG. 3, for example.
  • keywords are SQL command names (select, update, insert, drop, etc.) and characteristic expressions for DB access. For example, for MySQL, it is information_schema, @@version, mysql, and so on.
  • the keywords are named entities (alert, onclick, etc.) used in HTML (HyperText Markup Language) and Javascript (registered trademark).
  • E. In the attack type of the keyword is a named entity (../, etc.) used in a directory traversal attack.
  • the feature candidate DB 112 stores information (feature candidates) output from the emulator as a result of attack code emulation by the attack code analysis unit 123 .
  • the request/response DB 113 stores various requests to the Web server 1 and various responses from the Web server 1.
  • the request/response DB 113 may also store information that is referred to when the feature selection unit 124 excludes words (universal words) that frequently appear in normal responses from feature candidates. good.
  • the request/response DB 113 is created, for example, by acquiring responses in a test environment in which attacks are guaranteed not to come. Alternatively, it is created using a response corresponding to a request that was not detected by the attack detection device 3 .
  • the feature DB 114 stores the features output from the web server 1 when the attack code succeeds. Specifically, the feature DB 114 stores features selected by the feature selection unit 124 from feature candidates stored in the feature candidate DB 112 . The features stored in the feature DB 114 are referred to when the success/failure determination unit 125 determines whether or not the attack was successful based on the response from the Web server 1 .
  • the communication data acquisition unit 121 executes the following alert reception processing.
  • the communication data acquisition unit 121 receives an alert issued by the attack detection device 3 and executes an alert reception process of generating communication data acquisition conditions associated with the alert.
  • the communication data acquisition unit 121 executes communication data acquisition processing for acquiring communication data from the packet capture device 4 according to the generated acquisition conditions. More specifically, the communication data acquisition unit 121 has a reception unit 131 , a generation unit 132 and an acquisition unit 133 .
  • the reception unit 131 receives from the attack detection device 3 an alert notifying that the attack has been detected. That is, the receiving unit 131 receives an alert transmitted from the attack detection device 3 that detects an attack on the Web server 1, which is a monitoring target device, and generates an alert. The receiving unit 131 then outputs the received alert to the generating unit 132 .
  • the generation unit 132 receives the input of the alert issued by the attack detection device 3 from the reception unit 131 . Next, the generation unit 132 extracts from the alert information that can identify communication data associated with the alert. For example, the generation unit 132 extracts part or all of the IP address and port number of the source of the attack request and the path part of the URL included in the alert.
  • the generating unit 132 generates communication data acquisition conditions using information that can identify communication data linked to the alert. For example, the generation unit 132 uses part or all of the IP address and port number of the source of the attack request and the path part of the URL included in the alert to obtain communication data related to them. Generate acquisition conditions for After that, the generation unit 132 outputs the generated acquisition condition to the acquisition unit 133 . That is, the generation unit 132 generates acquisition conditions for communication data to be acquired based on the alert received by the reception unit 131 .
  • the acquisition unit 133 transmits the acquisition conditions generated by the generation unit 132 to the packet capture device 4, and requests acquisition of communication data that matches the acquisition conditions. Then, the acquisition unit 133 receives communication data that matches the transmitted acquisition condition from the packet capture device 4 . That is, the acquisition unit 133 acquires communication data that matches the acquisition conditions generated by the generation unit 132 from the packet capture device 4 that holds data transmitted and received by the Web server 1, which is the monitoring target device. After that, the acquisition unit 133 outputs communication data that matches the acquisition condition, that is, communication data linked to the alert to the attack type determination unit 122 .
  • the attack type determination unit 122 receives input of communication data associated with the alert from the acquisition unit 133 of the communication data acquisition unit 121. Then, the attack type determination unit 122 extracts the attack code included in the acquired communication data. After that, the attack type determination unit 122 uses the extracted attack code to determine the attack type.
  • the attack type determination unit 122 for example, attacks the Web server 1, which is considered to be particularly important. ⁇ E. It is determined which of the five attack types of the attack type of . Specifically, the attack type determination unit 122 determines whether the keyword included in the attack code matches with which attack type keyword shown in the attack type keyword list 111 .
  • the attack type determination unit 122 refers to the attack type keyword list 111, and if the attack code contains "cat", the attack code is classified as A. attack type (attack type that abuses OS commands). Further, if the attack code includes "print_r", the attack type determination unit 122 converts the attack code to B. attack type (attack type that exploits program code), and among them, it is determined that it is an attack type that uses php.
  • the attack type determination unit 122 determines the attack type according to predetermined conditions when the attack code matches keywords of a plurality of attack types shown in the attack type keyword list 111 . For example, the attack type determination unit 122 determines that the keyword appearing at the leftmost position in the first attack code is the attack type.
  • attack type determination unit 122 determines A. attack type.
  • the attack type determination unit 122 refers to the attack type keyword list 111 and determines that determination is not possible if the attack code does not match any attack type. After that, the attack type determination unit 122 notifies the attack code analysis unit 123 of the attack code included in the attack request and the attack type of the attack code.
  • the attack code analysis unit 123 performs dynamic analysis of the attack code using an emulator to extract features that appear in the response from the Web server 1 when the attack code is executed.
  • the attack code analysis unit 123 uses an emulator corresponding to the attack type of the attack code determined by the attack type determination unit 122 to emulate an attack on the Web server 1 by the attack code. Then, the attack code analysis unit 123 extracts the output that appears in the response to the attack in the emulation of the attack code as feature candidates that appear when the attack is successful.
  • the emulator corresponding to each attack type is created in advance by applying a debugger or an interpreter, for example, and the attack code analysis unit 123 selects the emulator corresponding to the attack type from the emulators created in advance. .
  • the attack code analysis unit 123 extracts the features that appear in the response to the request when the attack code is executed as follows.
  • the attack code analysis unit 123 executes the attack code as a command using an environment in which OS commands can be executed.
  • OS commands for example, Windows (registered trademark) command prompt, Linux (registered trademark) bash, or an emulator capable of emulating commands can be used.
  • the attack code analysis unit 123 causes the bash command to execute the command specified by the -c argument, such as "bash -c "cat /etc/passwd;”. Then, the attack code analysis unit 123 extracts the contents of the standard output and standard error output by command execution as feature candidates. For example, the attack code analysis unit 123 uses information such as standard output: "root:*:0:/bin/sh" and standard error output "none" for the attack code "cat /etc/passwd;” as feature candidates. Extract as
  • the attack code analysis unit 123 executes the attack code using an appropriate interpreter or emulator for the programming language.
  • the attack code analysis unit 123 sends the php interpreter with the -r argument, such as "php -r ”print('123456789');die();” Executes the specified code. Also, if the attack code is a python code, the attack code analysis unit 123 sends the code specified by the -c argument to the python interpreter, such as "python -c "import sys;print 123456789;sys.exit()". let it run.
  • the attack code analysis unit 123 After executing the code, the attack code analysis unit 123 extracts the contents of the standard output and standard error output as feature candidates. For example, in the case of php code, the attack code analysis unit 123 uses the information of standard output "123456789” and standard error output "none" as feature candidates for attack code "print('123456789');die();” Extract.
  • the attack code analysis unit 123 executes the attack code using a terminal or emulator capable of executing SQL statements against the DB.
  • the SQL statement (SQL command) inserted by the SQL injection attack is partial and cannot be executed as is. Therefore, the attack code analysis unit 123 shapes the SQL sentence. For example, the attack code analysis unit 123 changes the SQL sentence so that the SELECT clause appears at the beginning of the attack code by deleting the part before the SELECT clause etc. of the SQL sentence.
  • the keyword that the attack code analysis unit 123 adjusts so that it appears first among the phrases of the SQL statement may be phrases other than the SELECT phrase, such as update, delete, drop, etc., and these phrases are It is assumed that the keywords are given in the keyword list 111 classified by type.
  • the attack code analysis unit 123 extracts the contents of the standard output and standard error output from the execution of the formatted SQL statement as feature candidates. For example, the attack code analysis unit 123 formats the attack code "' union select 123456789-" into “select 123456789". Then, the attack code analysis unit 123 extracts the information of the standard output "123456789” and the standard error output "none” by executing the modified attack code as feature candidates.
  • the attack code analysis unit 123 extracts the attack code itself as a feature candidate because the attack code itself is sent to the client as a response due to the nature of the attack.
  • the attack code analysis unit 123 uses “ ⁇ script>alert(1) ⁇ /script>” as a feature candidate. Extract. Also, when the attack code is the Header Injection attack code " ⁇ r ⁇ nSet-Cookie:1234;”, the attack code analysis unit 123 extracts " ⁇ r ⁇ nSet-Cookie:1234;” as a feature candidate.
  • the attack code analysis unit 123 searches the OS for a file name that appears in the attack code, and extracts the content of the file with that file name as a feature candidate. do.
  • the attack code analysis unit 123 searches the OS for the file name appearing in the attack code. Extract the content "root:*:0:/bin/sh" as a feature candidate.
  • the attack code analysis unit 123 can perform emulation according to the attack type of the attack code, and extract feature candidates that are features when the attack by the attack code is successful. Then, the attack code analysis unit 123 stores the extracted feature candidates in the feature candidate DB 112 .
  • the feature selection unit 124 excludes inappropriate candidates as features from the feature candidates extracted by the attack code analysis unit 123 . Specifically, the feature selection unit 124 excludes feature candidates that are too universal and highly likely to be unusable for determining the success or failure of an attack from among the feature candidates stored in the feature candidate DB 112 .
  • the feature selection unit 124 excludes feature candidates with extremely short character string lengths, such as character string lengths of 2 or less, from feature candidates stored in the feature candidate DB 112 . Furthermore, the feature selection unit 124 excludes feature candidates of universal words that also appear in normal responses from the feature candidates. Then, the feature selection unit 124 stores the remaining feature candidates in the feature DB 114 as features when the attack is successful.
  • the feature selection unit 124 excludes feature candidates "1, 2" whose character string length is equal to or less than a predetermined value (eg, 2) from feature candidates "1, 2, title, page, 123456789". After that, the feature selection unit 124 excludes universal words from "title, page, 123456789", which excludes feature candidates whose character string length is equal to or less than a predetermined value.
  • a predetermined value eg, 2
  • universal words from "title, page, 123456789" which excludes feature candidates whose character string length is equal to or less than a predetermined value.
  • a universal term here is, for example, a term included in a response to a request that is not an attack. Therefore, the feature selection unit 124 refers to the request/response DB 113 and excludes feature candidates whose number of appearances in the request/response DB 113 is 1 or more among the feature candidates “title, page, 123456789”. Then, the feature selection unit 124 causes the feature DB 114 to store the feature candidates remaining as a result of the exclusion as features when an attack succeeds.
  • the response " ⁇ html> ⁇ title>My blog page ⁇ /title> ⁇ p>Hello world! Date: April 1, 2017 ⁇ /p> ⁇ /html>” is stored in the request/response DB 113. explained in case.
  • the feature selection unit 124 excludes the feature candidate "title, page” appearing in the response from among the feature candidates "title, page, 123456789". Then, the feature selection unit 124 causes the feature DB 114 to store the feature candidate "123456789" remaining as a result of exclusion as a feature at the time of successful attack.
  • the feature selection unit 124 uses the request/response DB 113 when excluding universal words from the feature candidate DB 112, but a list of universal words prepared in advance can also be used. good.
  • the feature selection unit 124 removes both feature candidates with extremely short character string lengths and feature candidates of universal words from the feature candidates extracted by the attack code analysis unit 123, as described above. may be performed, or only one of them may be performed.
  • the success/failure determination unit 125 refers to the feature DB 114 and determines whether or not the response from the web server 1 indicates the success of the attack. That is, the success/failure determination unit 125 determines that the attack was successful when the response includes the feature stored in the feature DB 114 . On the other hand, the success/failure determination unit 125 determines that the attack has failed when the response does not include the feature stored in the feature DB 114 . That is, the success/failure determination unit 125 determines success or failure of the attack based on the communication data acquired by the acquisition unit 133 . Then, the success/failure determination unit 125 outputs the result of the success/failure determination of the attack.
  • the success/failure determination unit 125 examines whether or not each of the plurality of responses corresponding to the plurality of requests to the Web server 1 after the attack request has the extracted feature. , it may be determined that the attack by the attack code was successful if it has the extracted features.
  • FIG. 4 is a flowchart of the attack success/failure determination process by the determination device according to the first embodiment. Next, the flow of attack success/failure determination processing by the alert verification device 10 according to the present embodiment will be described with reference to FIG.
  • the reception unit 131 of the communication data acquisition unit 121 receives an alert from the attack detection device 3 when the attack detection device 3 detects an attack on the Web server 1 .
  • the generation unit 132 of the communication data acquisition unit 121 generates communication data acquisition conditions from the alert acquired by the reception unit 131 (step S1).
  • the acquisition unit 133 of the communication data acquisition unit 121 acquires communication data that matches the acquisition condition generated by the generation unit 132 from the packet capture device 4 (step S2). After that, the acquisition unit 133 of the communication data acquisition unit 121 outputs the acquired communication data to the attack type determination unit 122 as communication data linked to the alert.
  • the attack type determination unit 122 refers to the attack type keyword list 111 to determine the attack type of the attack code included in the communication data acquired by the communication data acquisition unit 121 (step S3).
  • the attack type determination unit 122 determines whether the attack type can be determined based on the attack type determination result (step S4).
  • step S4 If the attack type can be determined (step S4: affirmative), the attack code analysis unit 123 emulates the attack code based on the attack type determined by the attack type determination unit 122. Then, the attack code analysis unit 123 performs attack code analysis processing for extracting information output as a result of the emulation as feature candidates for successful attack (step S5). After that, the attack code analysis unit 123 stores the extracted feature candidates in the feature candidate DB 112 .
  • the feature selection unit 124 selects feature candidates excluding feature candidates inappropriate as features from among the feature candidates stored in the feature candidate DB 112, as features to be used for determining the success or failure of an attack (step S6).
  • the feature selection unit 124 determines whether or not the feature exists according to the feature selection result (step S7). For example, if all feature candidates are excluded, the feature selection unit 124 determines that no feature exists.
  • the feature selection unit 124 causes the feature DB 114 to store the selected feature used to determine the success or failure of the attack.
  • the success/failure determination unit 125 determines whether or not the response from the Web server 1 includes the feature stored in the feature DB 114 (step S8).
  • the success/failure determination unit 125 determines whether or not the attack was successful by comparing the characteristics stored in the feature DB 114 with the response from the Web server 1, which is the target of determination of success or failure of the attack.
  • the success/failure determination unit 125 determines that the attack on the web server 1 was successful. Then, the success/failure determination unit 125 transmits a message to an external device (not shown) such as an administrator terminal to notify the administrator of the Web server 1 of the success of the attack on the Web server 1 (step S9). .
  • the success/failure determination unit 125 determines that the attack on the Web server 1 has failed. . Then, the success/failure determination unit 125 transmits a message notifying that the attack on the Web server 1 has failed to an external device (not shown) such as an administrator terminal, and notifies the administrator of the Web server 1 (step S10). .
  • step S4 negative
  • step S7 negative
  • the success/failure determination unit 125 notifies the administrator that the attack success/failure determination is not possible (step S11).
  • the alert verification device 10 receives an alert when an attack is detected by the attack detection device 3 such as a WAF, and generates communication data that satisfies an acquisition condition based on the received alert. Obtained from the packet capture device 4 that holds a copy of the communication data. Then, the alert verification device 10 determines the attack type using the communication data linked to the acquired alert, emulates the attack code, extracts characteristics of the response, and receives a response having the extracted characteristics from the Web server 1. If it is output, it is determined that the attack was successful. As a result, the alert verification device 10 can parse the communication data associated with the alert and determine the success or failure of the attack. can judge. Therefore, the alert verification device 10 can determine the success or failure of an attack on the Web server 1 while reducing the processing load of parsing communication packets without modifying an existing system, defining an attack, or collecting vulnerability information. becomes possible.
  • FIG. 5 is a diagram showing a second order attack in the second embodiment.
  • the attack detection device 3 such as WAF detects the attack request 201 in session #1, but does not determine the request as an attack in session #2.
  • the attack request 201 and the response 202 are the attacks intended by the attacker, but in the alert verification device 10 described in the first embodiment, the response 202 is not subject to the attack success/failure determination of the alert verification technology.
  • the communication data acquisition unit 121 generates a communication data acquisition condition from an alert, and acquires communication data that satisfies the generated acquisition condition from the packet capture device 4. In addition, the following processing is performed. I do. However, the communication data acquisition unit 121 may perform the following process instead of acquiring communication data that satisfies an acquisition condition for communication data generated from an alert.
  • the generating unit 132 identifies the session in which the attack was detected from the alert acquired by the receiving unit 131. Next, the generation unit 132 generates an acquisition condition using information that can identify the communication source and communication destination such as the IP address in the identified session. That is, the generation unit 132 generates the acquisition condition based on the information specifying the communication source or communication destination in the first session in which the alert is generated.
  • the acquisition unit 133 acquires communication data for a certain period of time from the alert generation according to the acquisition conditions generated by the generation unit 132 . That is, the acquisition unit 133 acquires communication data that matches the acquisition conditions for the first session and the second session after the first session from the packet capture device 4 .
  • the generator 132 identifies session #1 by the attack request 201 when the attack is detected from the alert. Then, the generation unit 132 stores information specifying the communication partner of the Web server 1, such as the IP address of the communication target device 5 in session #1. For example, the generation unit 132 stores “source IP address 192.168.0.1 and destination IP address 10.0.0.1” in session #1.
  • the acquisition unit 133 acquires communication data that matches the information specifying the communication target device 5 from the packet capture device 4 at regular intervals during a certain period of time after the alert is issued, and transmits the communication data to the attack type determination unit 122 .
  • the acquisition unit 133 sends an HTTP request of “source IP address 192.168.0.1 and destination IP address 10.0.0.1” from the packet capture device 4 at five-minute intervals for one hour and Get the HTTP response.
  • the communication data acquisition unit 121 may perform the above processing when the success/failure determination unit 125 determines that the attack on session #1 has failed.
  • the alert verification device 10 determines that the attack has failed in session #1 in which the attack request 201 has been detected, it can determine that the attack has succeeded based on the response 202 in session #2 in which the attack request has not been detected.
  • the alert verification device 10 acquires communication data with the attack communication target device 5 also for sessions subsequent to the session in which the attack was detected, and determines the success or failure of the attack. judge. As a result, it becomes possible to determine the success or failure of second-order attacks, and the security of the Web server 1 can be improved.
  • FIG. 6 is a diagram showing an attack spanning multiple sessions in the third embodiment.
  • Attacks on the Web server 1 include attacks spanning multiple sessions, such as blind SQL injection.
  • the attack detection device 3 may not detect the requests 211 and 212 as attack requests in either session #1 or #2.
  • the communications of sessions #1 and #2 may not be targeted for attack success/failure determination.
  • the communication data acquisition unit 121 generates a communication data acquisition condition from an alert, and acquires communication data that satisfies the generated acquisition condition from the packet capture device 4. In addition, the following processing is performed. I do. However, the communication data acquisition unit 121 may perform the following process instead of acquiring communication data that satisfies an acquisition condition for communication data generated from an alert.
  • the generation unit 132 generates an acquisition condition based on a predefined attack code. Then, the acquisition unit 133 acquires communication data corresponding to the acquisition condition generated by the generation unit 132 from the packet capture device 4 and transmits the communication data to the attack type determination unit 122 .
  • Generate acquisition conditions for The acquisition unit 133 acquires HTTP requests and HTTP responses that match a predefined regular expression from the packet capture device 4 and transmits them to the attack type determination unit 122 at regular intervals such as every five minutes.
  • the alert verification device 10 also targets sessions #1 and #2 in which the requests 211 and 212 are not detected as attacks by the attack detection device 3 as targets of the attack success/failure determination process. can be done. As a result, it is possible to determine the success or failure of an attack that spans multiple sessions, such as blind SQL injection, and the security of the Web server 1 can be improved.
  • FIG. 7 is a diagram showing a login bypass attack in the fourth embodiment.
  • Attacks on the Web server 1 include a login bypass attack in which a user logs in by bypassing authentication.
  • a login bypass attack in which a user logs in by bypassing authentication.
  • the information entered in the request 221 is attacking the login page, but is generally not attacking information.
  • the request 222 for accessing the page after login is not judged as an attack by the attack detection device 3 either. Therefore, if the login page is not specified, the alert verification device 10 described in the first embodiment may not determine the success or failure of an attack in some cases.
  • the communication data acquisition unit 121 generates a communication data acquisition condition from an alert, and acquires communication data that satisfies the generated acquisition condition from the packet capture device 4. In addition, the following processing is performed. I do. However, the communication data acquisition unit 121 may perform the following process instead of acquiring communication data that satisfies an acquisition condition for communication data generated from an alert.
  • the generation unit 132 generates an acquisition condition from the path part of the URL of the login page defined in advance. That is, the generation unit 132 generates the acquisition condition based on the information of the login page in the web server 1, which is the monitoring target device. Then, the acquisition unit 133 acquires communication data related to the login page from the packet capture device 4 according to the acquisition condition generated by the generation unit 132 and transmits the communication data to the attack type determination unit 122 .
  • the generation unit 132 receives a designation in advance of a path part (for example, /login.php) that is a candidate for a login page. Then, the generation unit 132 generates an acquisition condition for acquiring an HTTP request and an HTTP response including "/login.php" in the path part of the URL. Acquisition unit 133 acquires an HTTP request and an HTTP response including “/login.php” in the path part of the URL from packet capture device 4 according to the acquisition condition generated by generation unit 132 , and sends them to attack type determination unit 122 . Send.
  • a path part for example, /login.php
  • the generation unit 132 may acquire the information of the login page by the following method without receiving the designation of the path part of the URL of the login page in advance. For example, the generation unit 132 stores the path part of the URL that was determined to be the login page when the attack success/failure determination was performed using the communication data generated from the alert that satisfies the acquisition condition. Then, the generation unit 132 may generate the acquisition condition from the path part of the stored URL.
  • the alert verification device 10 can target communications in a login bypass attack, which is not detected as an attack by the attack detection device 3, for attack success/failure determination processing. As a result, it is possible to determine the success or failure of the login bypass attack, and the security of the Web server 1 can be improved.
  • the generation unit 132 of the communication data acquisition unit 121 generates acquisition conditions from predefined information, that is, information for extracting predefined specific communication data. Then, the acquisition unit 133 of the communication data acquisition unit 121 acquires communication data according to the acquisition conditions generated by the generation unit 132 from the packet capture device 4 and transmits the communication data to the attack type determination unit 122 .
  • the generation unit 132 selects the path part of the specific URL as "/example.html”. .html” information in advance. Then, the generation unit 132 generates an acquisition condition for acquiring an HTTP request and an HTTP response including "/example.html” in the path part of the URL.
  • the acquisition unit 133 acquires an HTTP request and an HTTP response including “/example.html” in the path part of the URL from the packet capture device 4 according to the acquisition condition generated by the generation unit 132 .
  • the alert verification device 10 acquires communication data based on information defined in advance. As a result, it becomes possible to determine the success or failure of an attack for a predefined specific HTTP request and HTTP response, and the security of the Web server 1 can be improved.
  • FIG. 8 is a system configuration diagram according to the sixth embodiment. As shown in FIG. 8, the system according to the present embodiment is provided with a load balancer 6, and a plurality of packet capture devices 4 are arranged. In the system according to the present embodiment, communication data acquisition processing is distributed.
  • a plurality of packet capture devices 4 are connected to the load balancer 6 .
  • the load balancer 6 receives a copy of communication data generated by the communication duplication device 2 and transmitted from the Internet to the Web server 1 . Then, the load balancer 6 distributes the copies of the communication data so that they are sent to the respective packet capture devices 4 approximately evenly.
  • Each packet capture device 4 receives a copy of communication data from the load balancer 6 . Then, the packet capture device 4 accumulates and stores the communication data acquired respectively.
  • the alert verification device 10 is connected to each of the multiple packet capture devices 4 .
  • the acquisition unit 133 of the communication data acquisition unit 121 in the alert verification device 10 specifies and acquires communication data that matches the acquisition condition of the data created based on the alert from among the communication data held by each packet capture device 4. . That is, the acquisition unit 133 acquires communication data from a plurality of packet capture devices 4 that distribute and hold communication data in communication performed by the Web server 1, which is a device to be monitored.
  • the system according to the present embodiment distributes and transmits replicated communication data to a plurality of packet capture devices 4 and stores them.
  • attack success/failure determination processing can be performed quickly in an environment where a large amount of traffic flows, and security can be improved even in the Web server 1 where a large amount of traffic flows.
  • HTTP requests and HTTP responses are used as examples of communications to be monitored for attack success/failure determination.
  • the alert verification device 10 may perform attack success/failure determination processing using another protocol such as FTP (File Transfer Protocol) as a monitoring target.
  • FTP File Transfer Protocol
  • each component of each device illustrated is functionally conceptual, and does not necessarily need to be physically configured as illustrated.
  • the specific form of distribution and integration of each device is not limited to the illustrated one, and all or part of them can be functionally or physically distributed or Can be integrated and configured.
  • all or any part of each processing function performed by each device is realized by a CPU (Central Processing Unit) and a program analyzed and executed by the CPU, or hardware by wired logic can be realized as
  • a tap configuration system was described as an example, but the system is not limited to this.
  • An in-line configuration may be adopted in which the web server 1 is directly connected to the web server 1 that is the target of attack success/failure determination.
  • the communication duplicating device 2 is arranged to copy communication data such as TAP. 4 may be connected, and the attack detection device 3 may copy the communication data and transmit it to the packet capture device 4 .
  • the information processing device can function as the alert verification device 10 by causing the information processing device to execute the program provided as package software or online software.
  • the information processing apparatus referred to here includes a desktop or notebook personal computer.
  • information processing devices include smart phones, mobile communication terminals such as mobile phones and PHSs (Personal Handyphone Systems), and PDAs (Personal Digital Assistants).
  • the alert verification device 10 may be implemented in a cloud server.
  • FIG. 9 is a diagram showing an example of a computer that executes an alert verification program for attack success/failure determination processing.
  • computer 1000 includes memory 1010, CPU 1020, hard disk drive interface 1030, disk drive interface 1040, serial port interface 1050, video adapter 1060, and network interface 1070, for example. These units are connected by a bus 1080 .
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012 .
  • the ROM 1011 stores a boot program such as BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • Hard disk drive interface 1030 is connected to hard disk drive 1090 .
  • a disk drive interface 1040 is connected to the disk drive 1100 .
  • a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100, for example.
  • a mouse 1110 and a keyboard 1120 are connected to the serial port interface 1050, for example.
  • a display 1130 is connected to the video adapter 1060 .
  • the hard disk drive 1090 stores, for example, an OS 1091, application programs 1092, program modules 1093, and program data 1094. That is, an alert verification program defining each process of the alert verification device 10 having functions equivalent to those of the alert verification device 10 is implemented as a program module 1093 in which computer-executable code is described. Program modules 1093 are stored, for example, on hard disk drive 1090 .
  • the hard disk drive 1090 stores a program module 1093 for executing processing similar to the functional configuration in the alert verification device 10 .
  • the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).
  • the setting data used in the processing of the above-described embodiment is stored as program data 1094 in the memory 1010 or the hard disk drive 1090, for example. Then, the CPU 1020 reads the program modules 1093 and program data 1094 stored in the memory 1010 and the hard disk drive 1090 to the RAM 1012 as necessary, and executes the processes of the above-described embodiments.
  • the program modules 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in a removable storage medium, for example, and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program modules 1093 and program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). Program modules 1093 and program data 1094 may then be read by CPU 1020 through network interface 1070 from other computers.
  • LAN Local Area Network
  • WAN Wide Area Network

Abstract

受信部（１３１）は、監視対象装置に対する攻撃を検知する攻撃検知機器（３）から送信されたアラートを受信する。生成部（１３２）は、受信部（１３１）により受信されたアラートを基に、取得する通信データの取得条件を生成する。取得部（１３３）は、監視対象装置により送受信されたデータを保持するパケットキャプチャ装置（４）から、生成部（１３２）により生成された取得条件にマッチする前記通信データを取得する。成否判定部（１２５）は、取得部（１３３）により取得された通信データを基に攻撃の成否を判定する。

Description

アラート検証装置、アラート検証方法及びアラート検証プログラム
　本発明は、アラート検証装置、アラート検証方法及びアラート検証プログラムに関する。
　Ｗｅｂアプリケーションは、多くのサービスで利用される一方で、不特定多数からアクセス可能である。そのため、Ｗｅｂアプリケーションは、攻撃にも晒されやすいという性質を有する。Ｗｅｂアプリケーションへの攻撃は、日々大量に発生しており、セキュリティ機器などによって検知される。
　攻撃検知技術としては、ＷＡＦ（Web　Application　Firewall）や、ＮＩＤＳ（Network-based　Intrusion　Detection　System）といった技術が存在する。これらは、事前に保持する攻撃コードの特徴とマッチングする通信をネットワーク通信の中から攻撃として検知する技術である。ただし、これらの技術では、攻撃を検知することは可能であるが、検知した攻撃が成功したか否かを自動で判定することは困難であり、大量のアラートを人手で調査することで攻撃の成否が判明する。
　そのため、攻撃の成否を検証する様々な技術が研究されている。例えば、ファイルアクセスやＤＢ（Data　Base）アクセスといったサーバ内の特徴などを用いる異常検知技術を応用して攻撃を検知し且つ異常を検知した際は攻撃が成功したことを示すＨＩＤＳ（Host-based　Intrusion　Detection　System）と呼ばれる技術がある。また、攻撃が成功した際の状態遷移を定義し、攻撃によってシステムが定義された状態遷移を行うと攻撃が成功したとして検知するStateful　ＩＤＳと呼ばれる技術がある（A　Stateful　Intrusion　Detection　System　for　World-WideWeb　Servers,　ACSAC,　2003、Enhancing　Byte-Level　Network　Intrusion　Detection　Signatures　with　Context,　CCS,　2003、Verify　Results　of　Network　Intrusion　Alerts　Using　Lightweight　Protocol　Analysis,　ACSAC,　2005参照）。また、攻撃が対処とするアプリケーション及びバーションが利用されているかを事前にチェックし、利用されていると判定した場合、攻撃が成功したとして検知する、脆弱性情報との相関部積と呼ばれる手法がある（Alert　Verification　Determining　the　Success　of　Intrusion　Attempts,　DIMVA,　2004参照）。さらに、攻撃コードのエミュレートを行い、実行時に同じ挙動を観測した場合、攻撃が成功してとして検知する攻撃コードのエミュレーションと呼ばれる技術がある（On　Emulation-Based　Network　Intrusion　Detection　Systems,　RAID,　2014参照）。
　また、攻撃コードによるサーバへの攻撃が成功したか否かを判定する従来技術として以下のような技術が提案されている。１つは、判定した攻撃タイプに応じてサーバへの攻撃のエミュレーションを実施してサーバへの攻撃に成功した場合にレスポンスに現れる特徴を抽出し、サーバからのレスポンスが抽出した特徴を有する場合に攻撃コードによる攻撃が成功したと判定する技術である。他にも、攻撃タイプに応じてサーバへの攻撃のエミュレーションを実施して攻撃が成功した場合のレスポンスの特徴を抽出し、攻撃リクエスト以降の複数のレスポンスのうち少なくとも１つが抽出した特徴を有する場合に、攻撃が成功したと判定する技術が存在する。
　これらの従来技術における処理は、例えば以下のように実行される。まず、リクエストは攻撃か否かが判定される。リクエストが攻撃でなければ、攻撃成否判定不能と判定される。また、リクエストが攻撃の場合、攻撃タイプの判定処理を行い、攻撃タイプが判定可能か否かの判定が行われる。攻撃タイプが判定不能であれば、攻撃成否判定不能と判定される。これに対して、攻撃タイプが判定可能の場合、攻撃コードの解析が行われ、レスポンスに表れる特徴の中からその攻撃コードに対応する特徴の選定処理が行われる。次に、選択された特徴が存在するか否かが判定される。選択された特徴が存在しなければ、攻撃成否判定不能と判定される。これに対して、選択された特徴が存在する場合、特徴の検査処理が行われ、攻撃が成功したか否かが判定され、判定結果により攻撃の成否が通知される。
　以上のような攻撃の成否判定処理を行う装置は、例えば、攻撃検知部、攻撃タイプ判定部、攻撃コード解析部、特徴選定部及び特徴検査部を備える。攻撃検知部は、リクエストが攻撃か否かの検知を行う。攻撃タイプ判定部は、予め保持するキーワードリストを用いて、攻撃コードのプログラミング言語や攻撃の手法から攻撃のタイプを判定する。攻撃コード解析部は、予め保持するキーワードリスト及び特徴候補ＤＢを用いて、攻撃タイプに応じて攻撃コードを実行できるエミュレータを用意し、そのエミュレータで攻撃コードを実行する。特徴選定部は、レスポンスの情報が格納されたレスポンスＤＢ及び攻撃成功時の特徴の情報を格納する特徴ＤＢを用いて、得られた特徴候補から攻撃成功時の特徴として扱うのにふさわしくない特徴を除外する。特徴検査部は、特徴ＤＢを用いて、攻撃コード解析部で得られた攻撃コードが実行された際に出力する特徴が通信などに含まれているか否かを検査する。このような、攻撃コードによるサーバへの攻撃が成功したか否かを判定する技術を以下では、アラート検証技術と呼ぶ。
国際公開第２０１９／０１３２６６号 国際公開第２０１９／２２５２１６号
　しかしながら、アラート検証技術には、以下のような問題が存在する。攻撃として検知されていない通信のパケットもアラート検証技術の実施装置でＨＴＴＰリクエスト又はＨＴＴＰレスポンスへのパース処理が行われる。すなわち、アラート検証技術の実施装置では、通信パケットをＨＴＴＰリクエスト又はＨＴＴＰレスポンスへのパース処理が行われ、攻撃通信であるか否かがＷＡＦなどの攻撃検知機器の情報を用いて判定される。そのため、大量トラフィック環境ではパース処理の負荷が大きくなり、アラート検証技術の処理が大幅に遅延する。この場合、全ての通信パケットが、ＨＴＴＰリクエスト又はＨＴＴＰレスポンスにパースされるが、アラート検証技術での攻撃成否判定の対象となる通信は、攻撃と判定された通信である。
　本発明は、上記に鑑みてなされたものであって、通信パケットのパース処理を軽減し、攻撃判定処理の処理負荷を低減することを目的とする。
　上述した課題を解決し、目的を達成するために、受信部は、監視対象装置に対する攻撃を検知する攻撃検知機器から送信されたアラートを受信する。生成部は、前記受信部により受信された前記アラートを基に、取得する通信データの取得条件を生成する。取得部は、前記監視対象装置により送受信されたデータを保持するパケットキャプチャ装置から、前記生成部により生成された前記取得条件にマッチする前記通信データを取得する。成否判定部は、前記取得部により取得された前記通信データを基に前記攻撃の成否を判定する。
　本発明によれば、通信パケットのパース処理を軽減し、攻撃判定処理の処理負荷を低減することができる。
図１は、アラート検証装置が配置されたシステムの概略構成図である。 図２は、第１の実施形態に係る判定装置のブロック図である。 図３は、攻撃タイプ別キーワードリストの一例を示す図である。 図４は、第１の実施形態に係る判定装置による攻撃成否の判定処理のフローチャートある。 図５は、第２の実施形態におけるセカンドオーダ攻撃を示す図である。 図６は、第３の実施形態における複数のセッションにまたがる攻撃を示す図である。 図７は、第４の実施形態におけるログインバイパス攻撃を示す図である。 図８は、第６の実施形態に係るシステム構成図である。 図９は、攻撃成否判定処理のためのアラート検証プログラムを実行するコンピュータの一例を示す図である。
　以下に、本願の開示するアラート検証装置、アラート検証方法及びアラート検証プログラムの一実施形態を図面に基づいて詳細に説明する。なお、以下の実施形態により本願の開示するアラート検証装置、アラート検証方法及びアラート検証プログラムが限定されるものではない。
［第１の実施形態］
［概要］
　図１は、アラート検証装置が配置されたシステムの概略構成図である。図１に示すように、インターネットからＷｅｂサーバ１に繋がる通信経路上に、通信複製機器２及び攻撃検知機器３が配置される。さらに、通信複製機器２には、パケットキャプチャ装置４が接続される。そして、アラート検証装置１０は、パケットキャプチャ装置４及びＷｅｂサーバ１に繋がる通信経路上に配置された攻撃検知機器３に接続される。このようにアラート検証装置１０がＷｅｂサーバ１に繋がる経路とは異なる経路で攻撃検知機器３に接続された構成は、タップ構成と呼ばれる。
　Ｗｅｂサーバ１で動作するＷｅｂアプリケーションは、インターネットに接続されたＰＣなどとの間でリクエストの受信及びレスポンスの送信、並びに、リクエストの送信及びレスポンスの受信といった通信を行う。本実施形態では、Ｗｅｂアプリケーションに対する通信について説明するが、以下の説明では、Ｗｅｂサーバ１で動作するＷｅｂアプリケーションに対する通信を単にＷｅｂサーバ１に対する通信と呼ぶ。Ｗｅｂサーバ１に対するインターネットからのリクエストには、攻撃リクエストが含まれる場合がある。
　通信複製機器２は、Ｗｅｂサーバ１へのトラフィックを複製する。言い換えれば、通信複製機器２は、インターネットに接続されたＰＣなどとＷｅｂサーバ１の間で送受信される通信データを受信して複製を生成する。そして、通信複製機器２は、複製した通信データをパケットキャプチャ装置４へ送信する。
　パケットキャプチャ装置４は、通信複製機器２で生成されたインターネットに接続されたＰＣなどとＷｅｂサーバ１との間で送受信される通信データの複製を受信する。そして、パケットキャプチャ装置４は、取得した通信データを蓄積して保持する。
　攻撃検知機器３は、例えばＷＡＦなどの技術を用いてネットワーク通信の中から攻撃リクエストを検知する機能を備えた装置である。攻撃検知機器３は、インターネットからＷｅｂサーバ１へ送信される攻撃リクエストを受信すると、この攻撃リクエストを示すアラートを生成してアラート検証装置１０へ送信する。アラートには、例えば、攻撃リクエストの送信元のＩＰ（Internet　Protocol）アドレスやポート番号及びＵＲＬ（Uniform　Resource　Locator）のパス部などが含まれる。
　アラート検証装置１０は、攻撃が検知された場合、攻撃検知を示すアラートを攻撃検知機器３から受信する。そして、アラート検証装置１０は、アラートと紐づく通信データをパケットキャプチャ装置４から取得する。そして、アラート検証装置１０は、取得した通信データから特定した攻撃タイプ（例えば、ＯＳ（Operating　System）コマンドを悪用する攻撃タイプ）に応じたエミュレータで攻撃コードを実行し、実行の結果をＷｅｂサーバ１から出力される情報を攻撃の成功時に出力される特徴として抽出する。
　その後、アラート検証装置１０は、Ｗｅｂサーバ１からのレスポンスを検査し、レスポンスに、抽出した特徴が含まれている場合、攻撃は成功したと判定する。ここで、アラート検証装置１０では、Ｗｅｂサーバ１に対する攻撃リクエストがあった際、抽出された特徴を攻撃リクエストに対するレスポンスだけでなく、それ以後のレスポンスであって、所定の条件に合致した全てのレスポンスを検査対象としてもよい。
　このように、アラート検証装置１０は、攻撃成否判定を行う対象とする通信データをパケットキャプチャ装置４から取得し、その他の通信データの取得を抑制することで、通信パケットのパース処理負荷を低減できる。
［判定装置の構成］
　図２は、第１の実施形態に係る判定装置のブロック図である。図２に示すように、本実施形態に係るアラート検証装置１０は、記憶部１１、通信データ取得部１２１、攻撃タイプ判定部１２２、攻撃コード解析部１２３、特徴選定部１２４及び成否判定部１２５を備える。記憶部１１は、攻撃タイプ別キーワードリスト１１１、特徴候補ＤＢ１１２、リクエスト・レスポンスＤＢ１１３及び特徴ＤＢ１１４を格納する。
　攻撃タイプ別キーワードリスト１１１は、攻撃タイプ毎に、各攻撃タイプの攻撃コードに含まれるキーワードを示した情報である。図３は、攻撃タイプ別キーワードリストの一例を示す図である。この攻撃タイプ別キーワードリスト１１１は、攻撃タイプ判定部１２２が、攻撃コードに含まれるキーワードから攻撃タイプを判定する際に参照される。
　なお、攻撃タイプは、例えば、Ａ．ＯＳコマンドを悪用する攻撃タイプ、Ｂ．プログラムコードを悪用する攻撃タイプ、Ｃ．ＤＢの機能であるＳＱＬ（Structured　Query　Language）コマンドを悪用する攻撃タイプ（例えば、ＳＱＬ　Injection等）、Ｄ．ＨＴＴＰ（Hyper　Text　Transfer　Protocol）レスポンスを悪用する攻撃タイプ（例えば、ＸＳＳ（Cross　Site　Scripting）、Header　Injection等）、Ｅ．ファイル操作を悪用する攻撃タイプ（例えば、ディレクトリトラバーサル等）の５つのタイプに分けられる。
　なお、図３に例示するように、上記のＡ．の攻撃タイプではＯＳコマンドの名前をキーワードとする。また、Ｂ．の攻撃タイプではプログラミング言語で利用する固有表現をキーワードとする。例えば、PHP（Hypertext　Preprocessor）であればprint_r、var_dump、base64_decode等のPHPに固有の関数あるいはPHPの固有表現等（$_GET、$_POST等）をキーワードとする。その他のプログラミング言語（Java（登録商標）、Perl、Ruby、Python等）においても同等である。そのため、Ｂ．の攻撃タイプではプログラミング言語毎に攻撃タイプ別キーワードリスト１１１を保持する。このとき、どのプログラミング言語に当たるかの情報は、例えば、図３に示すように、サブ攻撃タイプとして保持する。
　また、Ｃ．の攻撃タイプではＳＱＬコマンドの名前（select、update、insert、drop等）やＤＢアクセスの際の特徴的な表現をキーワードとする。例えば、ＭｙＳＱＬの場合、information_schema、@@version、mysql等である。さらに、Ｄ．の攻撃タイプではＨＴＭＬ（HyperText　Markup　Language）やJavascript（登録商標）で利用される固有表現（alert、onclick等）をキーワードとする。また、Ｅ．の攻撃タイプではディレクトリトラバーサル攻撃で利用される固有表現（../等）をキーワードとする。
　図２に戻って説明を続ける。特徴候補ＤＢ１１２は、攻撃コード解析部１２３よる攻撃コードのエミュレーションの結果、エミュレータから出力された情報（特徴候補）を記憶する。
　リクエスト・レスポンスＤＢ１１３は、Ｗｅｂサーバ１への様々なリクエスト及びＷｅｂサーバ１からの様々なレスポンスを記憶する。なお、このリクエスト・レスポンスＤＢ１１３は、特徴選定部１２４が、特徴候補から、通常のレスポンスに頻繁に登場する語（普遍的な語）を除外する際に参照されるための情報も記憶してもよい。この場合には、リクエスト・レスポンスＤＢ１１３は、例えば、攻撃が来ないことが保証されている試験環境でレスポンスを取得して作成される。あるいは、攻撃検知機器３で検知されなかったリクエストに対応するレスポンスを用いて作成される。
　特徴ＤＢ１１４は、攻撃コードによる攻撃の成功時にＷｅｂサーバ１から出力される特徴を記憶する。具体的には、特徴ＤＢ１１４は、特徴候補ＤＢ１１２に記憶される特徴候補の中から特徴選定部１２４により選定された特徴を記憶する。この特徴ＤＢ１１４に記憶される特徴は、成否判定部１２５が、Ｗｅｂサーバ１からのレスポンスに基づき、攻撃が成功したか否かを判定する際に参照される。
　通信データ取得部１２１は、以下に示すアラート受信処理を実行する。通信データ取得部１２１は、攻撃検知機器３により発行されたアラートを受信してそのアラートに紐づく通信データの取得条件を生成するアラート受信処理を実行する。次に、通信データ取得部１２１は、生成した取得条件に応じた通信データをパケットキャプチャ装置４から取得する通信データ取得処理を実行する。より詳しくは、通信データ取得部１２１は、受信部１３１、生成部１３２及び取得部１３３を有する。
　受信部１３１は、攻撃検知機器３によりＷｅｂサーバ１への攻撃が検知された場合、その攻撃検知を通知するアラートを攻撃検知機器３から受信する。すなわち、受信部１３１は、監視対象装置であるＷｅｂサーバ１に対する攻撃を検知してアラートを発生する攻撃検知機器３から送信されたアラートを受信する。そして、受信部１３１は、受信したアラートを生成部１３２へ出力する。
　生成部１３２は、攻撃検知機器３により発行されたアラートの入力を受信部１３１から受ける。次に、生成部１３２は、アラートに紐づく通信データを特定可能な情報をアラートから抽出する。例えば、生成部１３２は、アラートに含まれる、攻撃リクエストの送信元のＩＰアドレス及びポート番号、並びに、ＵＲＬのパス部などの一部もしくは全てを抽出する。
　次に、生成部１３２は、アラートに紐づく通信データを特定可能な情報を用いて通信データの取得条件を生成する。例えば、生成部１３２は、アラートに含まれる、攻撃リクエストの送信元のＩＰアドレス及びポート番号、並びに、ＵＲＬのパス部などの一部もしくは全てを使用して、それらに関連する通信データを取得するための取得条件を生成する。その後、生成部１３２は、生成した取得条件を取得部１３３へ出力する。すなわち、生成部１３２は、受信部１３１により受信されたアラートを基に、取得する通信データの取得条件を生成する。
　取得部１３３は、生成部１３２により生成された取得条件をパケットキャプチャ装置４に送信して、取得条件にマッチする通信データの取得要求を行う。そして、取得部１３３は、送信した取得条件にマッチする通信データをパケットキャプチャ装置４から受信する。すなわち、取得部１３３は、監視対象装置であるＷｅｂサーバ１により送受信されたデータを保持するパケットキャプチャ装置４から、生成部１３２により生成された取得条件にマッチする通信データを取得する。その後、取得部１３３は、取得条件にマッチする通信データ、すなわち、アラートに紐づく通信データを攻撃タイプ判定部１２２へ出力する。
　攻撃タイプ判定部１２２は、アラートに紐づく通信データの入力を通信データ取得部１２１の取得部１３３から受ける。そして、攻撃タイプ判定部１２２は、取得した通信データに含まれる攻撃コードを抽出する。その後、攻撃タイプ判定部１２２は、抽出した攻撃コードを用いて攻撃タイプの判定を行う。
　ここで、攻撃タイプ判定部１２２は、例えば、Ｗｅｂサーバ１に対する攻撃の中でも特に重要と思われる、上記のＡ．～Ｅ．の攻撃タイプの５つの攻撃タイプのいずれであるかを判定する。具体的には、攻撃タイプ判定部１２２は、攻撃コードに含まれるキーワードが、攻撃タイプ別キーワードリスト１１１に示されるどの攻撃タイプのキーワードとマッチするかにより判定を行う。
　例えば、攻撃タイプ判定部１２２は、攻撃タイプ別キーワードリスト１１１を参照して、攻撃コードに「cat」が含まれていれば、当該攻撃コードをＡ．の攻撃タイプ（ＯＳコマンドを悪用する攻撃タイプ）と判定する。また、攻撃タイプ判定部１２２は、攻撃コードに「print_r」が含まれていれば、当該攻撃コードをＢ．の攻撃タイプ（プログラムコードを悪用する攻撃タイプ）であり、その中でもphpを用いた攻撃タイプであると判定する。
　なお、攻撃タイプ判定部１２２は、攻撃コードが、攻撃タイプ別キーワードリスト１１１に示される複数の攻撃タイプのキーワードとマッチした場合、予め決められた条件にしたがって攻撃タイプの判定を行う。例えば、攻撃タイプ判定部１２２は、攻撃コードの最初にあたる攻撃コード内で最も左の位置に出現したキーワードの攻撃タイプであると判定する。
　一例を挙げると、攻撃コードが「;php　-e　“$i=123456789;var_dump($1)”;」の場合、攻撃タイプ別キーワードリスト１１１において、Ａ．の攻撃タイプのキーワードである「php」と、Ｂ．の攻撃タイプのキーワードである「var_dump」とが出現する。このような場合、攻撃タイプ判定部１２２は、上記の攻撃コードにおいて「php」の方が「var_dump」よりも初めに出現しているので、Ａ．の攻撃タイプと判定する。
　なお、攻撃タイプ判定部１２２は、攻撃タイプ別キーワードリスト１１１を参照して、攻撃コードがどの攻撃タイプともマッチしなかった場合は判定不可とする。その後、攻撃タイプ判定部１２２は、攻撃リクエストに含まれる攻撃コード及びその攻撃コードの攻撃タイプを攻撃コード解析部１２３に通知する。
　攻撃コード解析部１２３は、攻撃コードについてエミュレータを用いた動的解析を行うことにより、当該攻撃コードを実行した際にＷｅｂサーバ１からのレスポンスに現れる特徴を抽出する。
　具体的には、攻撃コード解析部１２３は、攻撃タイプ判定部１２２で判定された攻撃コードの攻撃タイプに応じたエミュレータを用いて、その攻撃コードによるＷｅｂサーバ１への攻撃のエミュレーションを実施する。そして、攻撃コード解析部１２３は、攻撃コードのエミュレーションにおいて攻撃に対するレスポンスに現れる出力を、攻撃の成功時に現れる特徴候補として抽出する。
　なお、上記の各攻撃タイプに応じたエミュレータは、例えば、デバッガやインタープリタを応用して事前に作成され、攻撃コード解析部１２３は、事前作成されたエミュレータから、攻撃タイプに応じたエミュレータを選択する。
　次に、攻撃コード解析部１２３は、例えば、以下のようにして攻撃コードを実行した際のリクエストに対するレスポンスに現れる特徴を抽出する。
　例えば、攻撃コードの攻撃タイプがＡ．ＯＳコマンドを悪用する攻撃タイプである場合、攻撃コード解析部１２３は、ＯＳコマンドを実行できる環境を用いて、当該攻撃コードをコマンドとして実行する。ＯＳコマンドを実行できる環境として、例えば、Windows（登録商標）のコマンドプロンプト、Linux（登録商標）のbash、あるいはコマンドをエミュレートできるエミュレータなどが利用可能である。
　一例を挙げると、攻撃コード解析部１２３は、「bash　-c　"cat　/etc/passwd;”」というように、bashコマンドに-c引数で指定したコマンドを実行させる。そして、攻撃コード解析部１２３は、コマンドの実行による標準出力、標準エラー出力の内容を特徴候補として抽出する。例えば、攻撃コード解析部１２３は、攻撃コード「cat　/etc/passwd;」に対し、標準出力：「root:*:0:/bin/sh　…」、標準エラー出力「なし」という情報を特徴候補として抽出する。
　また、例えば、攻撃コードの攻撃タイプが、Ｂ．プログラムコードを悪用する攻撃タイプである場合、攻撃コード解析部１２３は、プログラミング言語に対して適切なインタープリタあるいはエミュレータを用いて、当該攻撃コードを実行する。
　一例を挙げると、攻撃コードが、phpコードの場合、攻撃コード解析部１２３は、「php　-r　”print(‘123456789’);die();”」というように、phpインタープリタに-r引数で指定したコードを実行させる。また、攻撃コードがpythonコードの場合、攻撃コード解析部１２３は、「python　-c　“import　sys;print　123456789;sys.exit()”」というように、pythonインタープリタに-c引数で指定したコードを実行させる。
　そして、攻撃コード解析部１２３は、コードの実行後、標準出力、標準エラー出力の内容を特徴候補として抽出する。例えば、phpコードの場合、攻撃コード解析部１２３は、攻撃コード「print(‘123456789’);die();」に対し、標準出力「123456789」、標準エラー出力「なし」という情報を特徴候補として抽出する。
　また、攻撃コードの攻撃タイプが、Ｃ．ＳＱＬコマンドを悪用する攻撃タイプである場合、攻撃コード解析部１２３は、ＤＢに対してＳＱＬ文を実行できるターミナルあるいはエミュレータを用いて、攻撃コードを実行する。
　なお、ＳＱＬ　Injection攻撃によって挿入されるＳＱＬ文（ＳＱＬコマンド）は部分的なものであり、そのままでは実行できない。よって、攻撃コード解析部１２３は、ＳＱＬ文の整形を行う。例えば、攻撃コード解析部１２３は、ＳＱＬ文のSELECT句等より前の部分を消去することにより、ＳＱＬ文をSELECT句等が攻撃コードの最初に現れるように変更する。なお、攻撃コード解析部１２３が、ＳＱＬ文の句のうち、最初に現れるように調整するキーワードは、SELECT句以外の例えばupdate、delete、drop等の句であってもよく、これらの句は攻撃タイプ別キーワードリスト１１１で与えられているものとする。
　攻撃コード解析部１２３は、整形後のＳＱＬ文の実行による標準出力、標準エラー出力の内容を特徴候補として抽出する。例えば、攻撃コード解析部１２３は、攻撃コード「’　union　select　123456789　-」を「select　123456789」に整形する。そして、攻撃コード解析部１２３は、整形後の攻撃コードの実行による標準出力「123456789」、標準エラー出力「なし」という情報を特徴候補として抽出する。
　また、攻撃コードの攻撃タイプが、Ｄ．ＨＴＴＰレスポンスを悪用する攻撃タイプである場合、攻撃コード解析部１２３は、攻撃の性質上、攻撃コードそのものがレスポンスとしてクライアントに送られるため、攻撃コードそのものを特徴候補として抽出する。
　例えば、攻撃コードがXSSによる攻撃コード「<script>alert(1)</script>」である場合、攻撃コード解析部１２３は、「<script>alert(1)</script>」を特徴候補として抽出する。また、攻撃コードがHeader　Injectionによる攻撃コード「\r\nSet-Cookie:1234;」である場合、攻撃コード解析部１２３は、「\r\nSet-Cookie:1234;」を特徴候補として抽出する。
　また、攻撃コードの攻撃タイプが、Ｅ．ファイル操作を悪用する攻撃タイプ（例えば、ディレクトリトラバーサル等）である場合、攻撃コード解析部１２３は、攻撃コードに現れるファイル名をＯＳ内で検索し、そのファイル名のファイルの内容を特徴候補として抽出する。
　例えば、攻撃コードが「../../../../etc/passwd」である場合、攻撃コード解析部１２３は、ＯＳ内から検索された、当該攻撃コードに現れるファイル名のファイルの内容である「root:*:0:/bin/sh　…」を特徴候補として抽出する。
　このようにすることで、攻撃コード解析部１２３は、攻撃コードの攻撃タイプに応じたエミュレーションを実行し、当該攻撃コードによる攻撃の成功時の特徴である特徴候補を抽出することができる。そして、攻撃コード解析部１２３は、抽出した特徴候補を特徴候補ＤＢ１１２に記憶させる。
　特徴選定部１２４は、攻撃コード解析部１２３により抽出された特徴候補の中から、特徴としては不適切な候補を除外する。具体的には、特徴選定部１２４は、特徴候補ＤＢ１１２に記憶される特徴候補の中から、普遍的過ぎて攻撃の成否の判定に利用できない可能性の高い特徴候補を除外する。
　例えば、特徴選定部１２４は、特徴候補ＤＢ１１２に記憶される特徴候補のうち、文字列長が２以下といった文字列長が極端に短い特徴候補を除外する。さらに、特徴選定部１２４は、通常のレスポンスにも現れる普遍的な語の特徴候補を特徴候補から除外する。そして、特徴選定部１２４は、残った特徴候補を攻撃成功時の特徴として、特徴ＤＢ１１４に記憶させる。
　例えば、特徴選定部１２４は、特徴候補「1、2、title、page、123456789」の中から、文字列長が所定値（例えば、２）以下の特徴候補「1、2」を除外する。その後、特徴選定部１２４は、文字列長が所定値以下の特徴候補を除外した「title、page、123456789」から普遍的な語を除外する。
　ここでの普遍的な語は、例えば、攻撃でないリクエストに対するレスポンスに含まれる語であるものとする。したがって、特徴選定部１２４は、リクエスト・レスポンスＤＢ１１３を参照して、特徴候補「title、page、123456789」のうち、リクエスト・レスポンスＤＢ１１３における出現回数が１以上の特徴候補を除外する。そして、特徴選定部１２４は、除外の結果の残った特徴候補を攻撃成功時の特徴として、特徴ＤＢ１１４に記憶させる。
　一例として、リクエスト・レスポンスＤＢ１１３にレスポンス「<html><title>My　blog　page</title><p>Hello　world　!　Date　:　2017/4/1</p></html>」が記憶されている場合で説明する。この場合、特徴選定部１２４は、特徴候補「title、page、123456789」のうち、当該レスポンスに出現する特徴候補「title、page」を除外する。そして、特徴選定部１２４は、除外の結果の残った特徴候補「123456789」を攻撃成功時の特徴として、特徴ＤＢ１１４に記憶させる。
　ここで、本実施形態では、特徴選定部１２４は、特徴候補ＤＢ１１２から普遍的な語を除外する際、リクエスト・レスポンスＤＢ１１３を用いたが、予め用意された普遍的な語のリストを用いてもよい。また、特徴選定部１２４は、攻撃コード解析部１２３により抽出された特徴候補に対し、上記のように、文字列長が極端に短い特徴候補の除外及び普遍的な語の特徴候補の除外の双方を行ってもよいし、いずれか一方のみを行ってもよい。
　成否判定部１２５は、特徴ＤＢ１１４を参照して、Ｗｅｂサーバ１からのレスポンスが攻撃の成功を示すものか否かを判定する。つまり、成否判定部１２５は、レスポンスに、特徴ＤＢ１１４に記憶される特徴が含まれる場合、攻撃が成功したと判定する。一方、成否判定部１２５は、レスポンスに、特徴ＤＢ１１４に記憶される特徴が含まれない場合、攻撃は失敗したと判定する。すなわち、成否判定部１２５は、取得部１３３により取得された通信データを基に攻撃の成否を判定する。そして、成否判定部１２５は、攻撃の成否の判定結果を出力する。
　ここで、成否判定部１２５は、攻撃リクエスト以降のＷｅｂサーバ１への複数のリクエストにそれぞれ対応する複数のレスポンスが、抽出した特徴を有するかそれぞれ検査し、複数のレスポンスのうち少なくともいずれか一つが、抽出した特徴を有する場合、攻撃コードによる攻撃が成功したと判定してもよい。
［攻撃成否の判定処理の処理手順］
　図４は、第１の実施形態に係る判定装置による攻撃成否の判定処理のフローチャートである。次に、図４を参照して、本実施形態に係るアラート検証装置１０による攻撃成否の判定処理の流れを説明する。
　通信データ取得部１２１の受信部１３１は、攻撃検知機器３によりＷｅｂサーバ１への攻撃が検知された場合、攻撃検知機器３からアラートを受信する。通信データ取得部１２１の生成部１３２は、受信部１３１により取得されたアラートから通信データの取得条件を生成する（ステップＳ１）。
　次に、通信データ取得部１２１の取得部１３３は、生成部１３２により生成された取得条件とマッチする通信データをパケットキャプチャ装置４から取得する（ステップＳ２）。その後、通信データ取得部１２１の取得部１３３は、取得した通信データをアラートに紐づく通信データとして攻撃タイプ判定部１２２へ出力する。
　攻撃タイプ判定部１２２は、攻撃タイプ別キーワードリスト１１１を参照して、通信データ取得部１２１により取得された通信データに含まれる攻撃コードの攻撃タイプを判定する（ステップＳ３）。
　攻撃タイプ判定部１２２は、攻撃タイプの判定結果から、攻撃タイプが判定可能か否かを判定する（ステップＳ４）。
　攻撃タイプが判定可能な場合（ステップＳ４：肯定）、攻撃コード解析部１２３は、攻撃タイプ判定部１２２により判定された攻撃タイプに基づき、攻撃コードのエミュレーションを実行する。そして、攻撃コード解析部１２３は、エミュレーションの結果出力された情報を、攻撃成功時の特徴候補として抽出する攻撃コード解析処理を行う（ステップＳ５）。その後、攻撃コード解析部１２３は、抽出した特徴候補を特徴候補ＤＢ１１２に記憶させる。
　特徴選定部１２４は、特徴候補ＤＢ１１２に格納された特徴候補の中から、特徴としては不適切な特徴候補を除外した特徴候補を、攻撃の成否の判定に用いる特徴として選定する（ステップＳ６）。
　そして、特徴選定部１２４は、特徴の選定結果に応じて特徴が存在するか否かを判定する（ステップＳ７）。例えば、特徴候補が全て除外された場合は、特徴選定部１２４は、特徴が存在しないと判定することになる。
　特徴が存在する場合（ステップＳ７：肯定）、特徴選定部１２４は、選定した攻撃の成否の判定に用いる特徴を特徴ＤＢ１１４に記憶させる。成否判定部１２５は、Ｗｅｂサーバ１からのレスポンスに特徴ＤＢ１１４に記憶された特徴が含まれるか否かを判定する（ステップＳ８）。成否判定部１２５は、特徴ＤＢ１１４に記憶される特徴と、攻撃の成否の判定対象となるＷｅｂサーバ１からのレスポンスとを照合することにより、攻撃が成功したか否かを判定する。
　Ｗｅｂサーバ１からのレスポンスに特徴ＤＢ１１４に記憶された特徴が含まれている場合（ステップＳ８：肯定）、成否判定部１２５は、Ｗｅｂサーバ１への攻撃が成功したと判定する。そして、成否判定部１２５は、Ｗｅｂサーバ１への攻撃の成功を通知するメッセージを管理者端末などの外部装置（不図示）へ送信して、Ｗｅｂサーバ１の管理者に通知する（ステップＳ９）。
　これに対して、Ｗｅｂサーバ１からのレスポンスに特徴ＤＢ１１４に記憶された特徴が含まれていない場合（ステップＳ８：否定）、成否判定部１２５は、Ｗｅｂサーバ１への攻撃は失敗したと判定する。そして、成否判定部１２５は、Ｗｅｂサーバ１への攻撃の失敗を通知するメッセージを管理者端末などの外部装置（不図示）へ送信して、Ｗｅｂサーバ１の管理者に通知する（ステップＳ１０）。
　一方、攻撃タイプの判定不可能な場合（ステップＳ４：否定）又は特徴が存在しない場合（ステップＳ７：否定）、成否判定部１２５は、攻撃の成否判定は不可として、管理者に通知する（ステップＳ１１）。
［情報収集処理による効果］
　以上に説明したように、本実施形態に係るアラート検証装置１０は、ＷＡＦなどの攻撃検知機器３による攻撃検知時のアラートを受信して、受信したアラートから生成した取得条件を満たす通信データを、通信データの複製を保持するパケットキャプチャ装置４から取得する。そして、アラート検証装置１０は、取得したアラートに紐づく通信データを用いて攻撃タイプを判定し、攻撃コードをエミュレートしてレスポンスの特徴を抽出し、抽出した特徴を有するレスポンスがＷｅｂサーバ１から出力された場合、攻撃が成功したと判定する。これにより、アラート検証装置１０は、アラートに紐づく通信データのパースを行い攻撃の成否の判定ができるので、Ｗｅｂサーバ１に対する全ての通信データのパース処理に比べて少ないパース処理で攻撃の成否の判定ができる。したがって、アラート検証装置１０は、既存のシステムの改変や、攻撃の定義や脆弱性情報の収集を行うことなく、通信パケットのパース処理負荷を低減しつつ、Ｗｅｂサーバ１に対する攻撃の成否を判定することが可能となる。
［第２の実施形態］
　図５は、第２の実施形態におけるセカンドオーダ攻撃を示す図である。Ｗｅｂサーバ１への攻撃には、登録機能と参照機能をまたいで確認する必要のある脆弱性を対象とするセカンドオーダ攻撃が存在する。例えば、図５に示すようなセカンドオーダ攻撃を分析する場合について説明する。セッション＃１では、ＷＡＦ等の攻撃検知機器３は、攻撃リクエスト２０１が検知されるが、セッション＃２ではリクエストを攻撃と判定しないことが考えられる。この場合、攻撃リクエスト２０１とレスポンス２０２とが攻撃者が意図した攻撃であるが、第１の実施形態で説明したアラート検証装置１０では、レスポンス２０２がアラート検証技術の攻撃成否判定の対象とならないことがある。
　そこで、本実施形態に係る通信データ取得部１２１は、アラートから通信データの取得条件を生成して、生成した取得条件を満たす通信データをパケットキャプチャ装置４から取得する処理に加えて、以下の処理を行う。ただし、通信データ取得部１２１は、アラートから生成した通信データの取得条件を満たす通信データを取得する処理に変えて、以下の処理を行ってもよい。
　生成部１３２は、受信部１３１により取得されたアラートから、その攻撃が検知されたセッションを特定する。次に、生成部１３２は、特定したセッションにおけるＩＰアドレスなどの通信元や通信先を特定できる情報を利用して取得条件を生成する。すなわち、生成部１３２は、アラートが発生した第１セッションにおける通信元又は通信先を特定する情報を基に取得条件を生成する。
　取得部１３３は、生成部１３２により生成された取得条件に応じてアラート発生から一定時間の間の通信データを取得する。すなわち、取得部１３３は、第１セッション及び第１セッション以降の第２セッションについても取得条件にマッチする通信データをパケットキャプチャ装置４から取得する。
　例えば、攻撃リクエスト２０１による攻撃を検知して攻撃検知機器３がアラートを発行した場合、生成部１３２は、アラートから攻撃が検出された際の攻撃リクエスト２０１によるセッション＃１を特定する。そして、生成部１３２は、セッション＃１における通信対象装置５のＩＰアドレスなどのＷｅｂサーバ１の通信相手を特定する情報を記憶する。例えば、生成部１３２は、セッション＃１における「送信元ＩＰアドレス１９２．１６８．０．１及び送信先ＩＰアドレス１０．０．０．１」を記憶する。
　そして、取得部１３３は、アラート発生から一定時間の間に一定間隔でパケットキャプチャ装置４から通信対象装置５を特定する情報に一致する通信データを取得し、攻撃タイプ判定部１２２へ送信する。例えば、取得部１３３は、１時間の間、５分間隔でパケットキャプチャ装置４から「送信元ＩＰアドレス１９２．１６８．０．１及び送信先ＩＰアドレス１０．０．０．１」のＨＴＴＰリクエスト及びＨＴＴＰレスポンスを取得する。
　ここで、通信データ取得部１２１は、成否判定部１２５によりセッション＃１について攻撃失敗と判定された場合に以上の処理を行ってもよい。
　これにより、アラート検証装置１０は、攻撃リクエスト２０１が検知されたセッション＃１で攻撃失敗と判定した場合でも、攻撃リクエストが検知されないセッション＃２におけるレスポンス２０２により攻撃成功と判定することができる。
　以上に説明したように、本実施形態に係るアラート検証装置１０は、攻撃が検知されたセッション以降のセッションについても攻撃の通信対象装置５との間の通信データを取得して、攻撃の成否を判定する。これにより、セカンドオーダ攻撃についても攻撃の成否を判定することが可能となり、Ｗｅｂサーバ１のセキュリティを向上させることができる。
［第３実施形態］
　図６は、第３の実施形態における複数のセッションにまたがる攻撃を示す図である。Ｗｅｂサーバ１への攻撃には、ブラインドＳＱＬインジェクションなどの複数のセッションにまたがる攻撃が存在する。例えば、図６に示すような複数のセッションにまたがる攻撃を分析する場合について説明する。この場合、セッション＃１及び＃２のいずれにおいても、攻撃検知機器３は、リクエスト２１１及び２１２を攻撃リクエストとして検知しないことが考えられる。この場合、第１の実施形態で説明したアラート検証装置１０では、セッション＃１及び＃２の通信が攻撃成否判定の対象とならないことがある。
　そこで、本実施形態に係る通信データ取得部１２１は、アラートから通信データの取得条件を生成して、生成した取得条件を満たす通信データをパケットキャプチャ装置４から取得する処理に加えて、以下の処理を行う。ただし、通信データ取得部１２１は、アラートから生成した通信データの取得条件を満たす通信データを取得する処理に変えて、以下の処理を行ってもよい。
　生成部１３２は、事前に定義された攻撃コードを基に取得条件を生成する。そして、取得部１３３は、生成部１３２により生成された取得条件に応じた通信データをパケットキャプチャ装置４から取得して攻撃タイプ判定部１２２へ送信する。
　例えば、生成部１３２は、事前に定義された正規表現（例えば、"\d+=\d+”（\d+は数字が１文字以上続くことを表す）など）とマッチするＨＴＴＰリクエスト及びＨＴＴＰレスポンスを取得するための取得条件を生成する。取得部１３３は、５分間隔などの一定間隔で、事前に定義された正規表現とマッチするＨＴＴＰリクエスト及びＨＴＴＰレスポンスをパケットキャプチャ装置４から取得して攻撃タイプ判定部１２２へ送信する。
　以上に説明したように、本実施形態に係るアラート検証装置１０は、攻撃検知機器３によりリクエスト２１１及び２１２が攻撃と検知されないセッション＃１及び＃２についても、攻撃成否判定処理の対象とすることができる。これにより、ブラインドＳＱＬインジェクションなどの複数のセッションにまたがる攻撃についても攻撃の成否を判定することが可能となり、Ｗｅｂサーバ１のセキュリティを向上させることができる。
［第４の実施形態］
　図７は、第４の実施形態におけるログインバイパス攻撃を示す図である。Ｗｅｂサーバ１への攻撃には、認証をバイパスしてログインするログインバイパス攻撃が存在する。例えば、図７に示すようなログイン攻撃を分析する場合について説明する。この場合、リクエスト２２１で入力される情報はログインページにとっては攻撃となるが、一般的には攻撃とならない情報である。さらに、ログイン後のページにアクセスするためのリクエスト２２２も攻撃検知機器３では攻撃とは判定されない。そのため、ログインページを特定しておかなければ、第１の実施形態で説明したアラート検証装置１０では、通信が攻撃成否判定の対象とならないことがある。
　そこで、本実施形態に係る通信データ取得部１２１は、アラートから通信データの取得条件を生成して、生成した取得条件を満たす通信データをパケットキャプチャ装置４から取得する処理に加えて、以下の処理を行う。ただし、通信データ取得部１２１は、アラートから生成した通信データの取得条件を満たす通信データを取得する処理に変えて、以下の処理を行ってもよい。
　生成部１３２は、事前に定義されたログインページのＵＲＬのパス部などから取得条件を生成する。すなわち、生成部１３２は、監視対象装置であるＷｅｂサーバ１におけるログインページの情報を基に取得条件を生成する。そして、取得部１３３は、生成部１３２により生成された取得条件に応じて、ログインページに関連する通信データをパケットキャプチャ装置４から取得して攻撃タイプ判定部１２２へ送信する。
　例えば、生成部１３２は、事前にログインページの候補となるパス部（例えば、/login.php）などの指定を受ける。そして、生成部１３２は、ＵＲＬのパス部に”/login.php”を含むＨＴＴＰリクエスト及びＨＴＴＰレスポンスを取得するための取得条件を生成する。取得部１３３は、生成部１３２により生成された取得条件にしたがって、ＵＲＬのパス部に”/login.php”を含むＨＴＴＰリクエスト及びＨＴＴＰレスポンスをパケットキャプチャ装置４から取得して攻撃タイプ判定部１２２へ送信する。
　なお、生成部１３２は、事前にログインページのＵＲＬのパス部などの指定を受けずに、以下の方法でログインページの情報を取得してもよい。例えば、生成部１３２は、アラートから生成した取得条件を満たす通信データを用いて攻撃成否判定が行われた際に、ログインページであると判定できたＵＲＬのパス部などを記憶する。そして、生成部１３２は、記憶したＵＲＬのパス部などから取得条件を生成してもよい。
　以上に説明したように、本実施形態に係るアラート検証装置１０は、攻撃検知機器３により攻撃と検知されないログインバイパス攻撃における通信についても、攻撃成否判定処理の対象とすることができる。これにより、ログインバイパス攻撃についても攻撃の成否を判定することが可能となり、Ｗｅｂサーバ１のセキュリティを向上させることができる。
［第５の実施形態］
　次に、第５の実施形態ついて説明する。攻撃検知機器３のアラート情報を使用せず、事前に定義された特定のＨＴＴＰリクエスト及びＨＴＴＰレスポンス、すなわち、事前に定義された特定の通信データについて攻撃成否判定を行いたい場合が存在する。
　そこで、本実施形態に係る通信データ取得部１２１の生成部１３２は、事前に定義された情報、すなわち、事前に定義された特定の通信データを抽出するための情報から取得条件を生成する。そして、通信データ取得部１２１の取得部１３３は、生成部１３２により生成された取得条件に応じた通信データをパケットキャプチャ装置４から取得して攻撃タイプ判定部１２２へ送信する。
　例えば、特定のＵＲＬのパス部（例えば、/example.html）などへのアクセスをアラート検証技術の攻撃成否判定の対象としたい場合、生成部１３２は、特定のＵＲＬのパス部である”/example.html”の情報を事前に取得する。そして、生成部１３２は、ＵＲＬのパス部に”/example.html”を含むＨＴＴＰリクエスト及びＨＴＴＰレスポンスを取得するための取得条件を生成する。取得部１３３は、生成部１３２により生成された取得条件にしたがい、ＵＲＬのパス部に”/example.html”を含むＨＴＴＰリクエスト及びＨＴＴＰレスポンスをパケットキャプチャ装置４から取得する。
　以上に説明したように、本実施形態に係るアラート検証装置１０は、事前に定義された情報に基づいて通信データを取得する。これにより、事前に定義された特定のＨＴＴＰリクエスト及びＨＴＴＰレスポンスについて攻撃成否判定を行うことが可能となり、Ｗｅｂサーバ１のセキュリティを向上させることができる。
［第６の実施形態］
　図８は、第６の実施形態に係るシステム構成図である。本実施形態に係るシステムには、図８に示すように、負荷分散装置６が設けられ、複数のパケットキャプチャ装置４が複数配置される。本実施例に係るシステムでは、通信データの取得処理が分散して行われる。
　負荷分散装置６は、複数のパケットキャプチャ装置４が接続される。負荷分散装置６は、通信複製機器２で生成されたインターネットからＷｅｂサーバ１へ送信される通信データの複製を受信する。そして、負荷分散装置６は、各パケットキャプチャ装置４におおよそ均等に送られるように分散して通信データの複製を送信する。
　パケットキャプチャ装置４は、それぞれが負荷分散装置６から通信データの複製を受信する。そして、パケットキャプチャ装置４は、それぞれで取得した通信データを蓄積して保管する。
　アラート検証装置１０は、複数のパケットキャプチャ装置４のそれぞれと接続される。アラート検証装置１０における通信データ取得部１２１の取得部１３３は、アラートに基づいて作成したデータの取得条件とマッチする通信データを各パケットキャプチャ装置４が保持する通信データの中から特定して取得する。すなわち、取得部１３３は、監視対象装置であるＷｅｂサーバ１が行う通信における通信データを分散して保持する複数のパケットキャプチャ装置４から通信データを取得する。
　以上に説明したように、本実施形態に係るシステムは、複製された通信データを複数のパケットキャプチャ装置４に分散して送信し格納させる。これにより、より大量のトラフィックが流れる環境において迅速に攻撃成否判定処理を行うことができ、トラフィックが大量に流れるＷｅｂサーバ１であってもセキュリティを向上させることができる。
（変形例）
　以上の各実施例では、攻撃成否判定の監視対象とする通信をＨＴＴＰリクエスト及びＨＴＴＰレスポンスを例に説明したが、攻撃の成否を判定する情報を有する通信であれば特に制限はない。例えば、アラート検証装置１０は、ＦＴＰ（File　Transfer　Protocol）などの他のプロトコルを監視対象として攻撃成否判定処理を行ってもよい。
［システム構成等］
　図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散及び統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散又は統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部又は任意の一部が、ＣＰＵ（Central　Processing　Unit）及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
　また、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
　また、以上の各実施形態では、タップ構成のシステムを例に説明したが、これに限らず攻撃検知機器３とＷｅｂサーバ１との間にアラート検証装置１０が配置して、アラート検証装置１０が攻撃の成否の判定対象となるＷｅｂサーバ１に直接接続されるインライン構成を採用してもよい。また、以上の各実施例では、ＴＡＰなどの通信データをコピーするために通信複製機器２を配置したが、攻撃検知機器３が通信データの複製機能を有する場合、攻撃検知機器３にパケットキャプチャ装置４を接続し、攻撃検知機器３が、通信データを複製してパケットキャプチャ装置４に送信してもよい。
［プログラム］
　また、上記の実施形態で述べたアラート検証装置１０の機能を実現するプログラムを所望の情報処理装置（コンピュータ）にインストールすることによって実装できる。例えば、パッケージソフトウェアやオンラインソフトウェアとして提供される上記のプログラムを情報処理装置に実行させることにより、情報処理装置をアラート検証装置１０として機能させることができる。ここで言う情報処理装置には、デスクトップ型またはノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機やＰＨＳ（Personal　Handyphone　System）等の移動体通信端末、さらには、ＰＤＡ（Personal　Digital　Assistants）等がその範疇に含まれる。また、アラート検証装置１０を、クラウドサーバに実装してもよい。
　図９は、攻撃成否判定処理のためのアラート検証プログラムを実行するコンピュータの一例を示す図である。図９に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ（Read　Only　Memory）１０１１およびＲＡＭ（Random　Access　Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。
　ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、アラート検証装置１０と同等の機能を持つアラート検証装置１０の各処理を規定するアラート検証プログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、アラート検証装置１０における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid　State　Drive）により代替されてもよい。
　また、上述した実施形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０は、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した実施形態の処理を実行する。
　なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local　Area　Network）やＷＡＮ（Wide　Area　Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　１　Ｗｅｂサーバ
　２　通信複製機器
　３　攻撃検知機器
　４　パケットキャプチャ装置
　１０　アラート検証装置
　１１　記憶部
　１１１　攻撃タイプ別キーワードリスト
　１１２　特徴候補ＤＢ
　１１３　リクエスト・レスポンスＤＢ
　１１４　特徴ＤＢ
　１２１　通信データ取得部
　１２２　攻撃タイプ判定部
　１２３　攻撃コード解析部
　１２４　特徴選定部
　１２５　成否判定部

Claims (8)

  1. 　監視対象装置に対する攻撃を検知する攻撃検知機器から送信されたアラートを受信する受信部と、
    　前記受信部により受信された前記アラートを基に、取得する通信データの取得条件を生成する生成部と、
    　前記監視対象装置により送受信されたデータを保持するパケットキャプチャ装置から、前記生成部により生成された前記取得条件にマッチする前記通信データを取得する取得部と、
    　前記取得部により取得された前記通信データを基に前記攻撃の成否を判定する成否判定部と
    　を備えたことを特徴とするアラート検証装置。
  2. 　前記生成部は、前記アラートが発生した第１セッションにおける通信元又は通信先を特定する情報を基に前記取得条件を生成し、
    　前記取得部は、前記第１セッション及び第２セッション以降についても前記取得条件にマッチする通信データを前記パケットキャプチャ装置から取得する
    　ことを特徴とする請求項１に記載のアラート検証装置。
  3. 　前記生成部は、事前に定義された攻撃コードを基に前記取得条件を生成することを特徴とする請求項１又は２に記載のアラート検証装置。
  4. 　前記生成部は、前記監視対象装置におけるログインページの情報を基に前記取得条件を生成することを特徴とする請求項１～３のいずれか一つに記載のアラート検証装置。
  5. 　前記生成部は、事前に定義された特定の通信データを抽出するための情報を基に前記取得条件を生成することを特徴とする請求項１～４のいずれか一つに記載のアラート検証装置。
  6. 　前記取得部は、前記監視対象装置が行う通信における通信データを分散して受信してそれぞれで保持する複数のパケットキャプチャ装置から前記通信データを取得することを特徴とする請求項１～５のいずれか一つに記載のアラート検証装置。
  7. 　監視対象装置に対する攻撃を検知する攻撃検知機器から送信されたアラートを受信する受信工程と、
    　前記受信工程において受信された前記アラートを基に、取得する通信データの取得条件を生成する生成工程と、
    　前記監視対象装置により送受信されたデータを保持するデータを保持するパケットキャプチャ装置から、前記生成工程において生成された前記取得条件にマッチする前記通信データを取得する取得工程と
    　前記取得工程において取得された前記通信データを基に前記攻撃の成否を判定する成否判定工程と
    　を備えたことを特徴とするアラート検証方法。
  8. 　監視対象装置に対する攻撃を検知する攻撃検知機器から送信されたアラートを受信し、
    　受信した前記アラートを基に、取得する通信データの取得条件を生成し、
    　前記監視対象装置により送受信されたデータを保持するパケットキャプチャ装置から、生成した前記取得条件にマッチする前記通信データを取得し、
    　　取得した前記通信データを基に前記攻撃の成否を判定する
    　処理をコンピュータ実行させることを特徴とするアラート検証プログラム。
PCT/JP2021/022590 2021-06-14 2021-06-14 アラート検証装置、アラート検証方法及びアラート検証プログラム WO2022264239A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2021/022590 WO2022264239A1 (ja) 2021-06-14 2021-06-14 アラート検証装置、アラート検証方法及びアラート検証プログラム
JP2023528781A JPWO2022264239A1 (ja) 2021-06-14 2021-06-14

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/022590 WO2022264239A1 (ja) 2021-06-14 2021-06-14 アラート検証装置、アラート検証方法及びアラート検証プログラム

Publications (1)

Publication Number Publication Date
WO2022264239A1 true WO2022264239A1 (ja) 2022-12-22

Family

ID=84526872

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/022590 WO2022264239A1 (ja) 2021-06-14 2021-06-14 アラート検証装置、アラート検証方法及びアラート検証プログラム

Country Status (2)

Country Link
JP (1) JPWO2022264239A1 (ja)
WO (1) WO2022264239A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010152773A (ja) * 2008-12-26 2010-07-08 Mitsubishi Electric Corp 攻撃判定装置及び攻撃判定方法及びプログラム
WO2015189971A1 (ja) * 2014-06-13 2015-12-17 株式会社アルチザネットワークス パケットキャプチャ装置、パケットキャプチャ方法、およびパケットの再構築方法
WO2019013266A1 (ja) * 2017-07-12 2019-01-17 日本電信電話株式会社 判定装置、判定方法、および、判定プログラム
WO2019225216A1 (ja) * 2018-05-21 2019-11-28 日本電信電話株式会社 判定方法、判定装置および判定プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010152773A (ja) * 2008-12-26 2010-07-08 Mitsubishi Electric Corp 攻撃判定装置及び攻撃判定方法及びプログラム
WO2015189971A1 (ja) * 2014-06-13 2015-12-17 株式会社アルチザネットワークス パケットキャプチャ装置、パケットキャプチャ方法、およびパケットの再構築方法
WO2019013266A1 (ja) * 2017-07-12 2019-01-17 日本電信電話株式会社 判定装置、判定方法、および、判定プログラム
WO2019225216A1 (ja) * 2018-05-21 2019-11-28 日本電信電話株式会社 判定方法、判定装置および判定プログラム

Also Published As

Publication number Publication date
JPWO2022264239A1 (ja) 2022-12-22

Similar Documents

Publication Publication Date Title
Kirda et al. Noxes: a client-side solution for mitigating cross-site scripting attacks
JP2014504765A (ja) 悪意あるｐｄｆネットワークコンテンツを検出するシステムおよび方法
CN107896219B (zh) 一种网站脆弱性的检测方法、系统及相关装置
EP3637292B1 (en) Determination device, determination method, and determination program
CN110362994B (zh) 恶意文件的检测方法、设备和系统
AU2019273974B2 (en) Determination method, determination device and determination program
CN108351941B (zh) 分析装置、分析方法、以及计算机可读存储介质
JP5752642B2 (ja) 監視装置および監視方法
KR102396237B1 (ko) 사이버 위협 정보 처리 장치, 사이버 위협 정보 처리 방법 및 사이버 위협 정보 처리하는 프로그램을 저장하는 저장매체
US20230376587A1 (en) Online command injection attacks identification
WO2022264239A1 (ja) アラート検証装置、アラート検証方法及びアラート検証プログラム
Barhoom et al. A new server-side solution for detecting cross site scripting attack
JP6867552B2 (ja) 判定方法、判定装置および判定プログラム
KR20210076455A (ko) Xss 공격 검증 자동화 방법 및 그 장치
KR102396238B1 (ko) 사이버 위협 정보 처리 장치, 사이버 위협 정보 처리 방법 및 사이버 위협 정보 처리하는 프로그램을 저장하는 저장매체
KR102447279B1 (ko) 사이버 위협 정보 처리 장치, 사이버 위협 정보 처리 방법 및 사이버 위협 정보 처리하는 프로그램을 저장하는 저장매체
US20240054215A1 (en) Cyber threat information processing apparatus, cyber threat information processing method, and storage medium storing cyber threat information processing program
Caseirito Attacking web applications for dynamic discovering of vulnerabilities
Tudosi et al. Design and Implementation of an Automated Dynamic Rule System for Distributed Firewalls.
KR20240021676A (ko) 사이버 위협 정보 처리 장치, 사이버 위협 정보 처리 방법 및 사이버 위협 정보 처리하는 프로그램을 저장하는 저장매체
KR20240021677A (ko) 사이버 위협 정보 처리 장치, 사이버 위협 정보 처리 방법 및 사이버 위협 정보 처리하는 프로그램을 저장하는 컴퓨터 판독 가능한 저장매체
Afonso et al. A hybrid system for analysis and detection of web-based client-side malicious code
CN114116619A (zh) 文件删除漏洞的防御方法、系统和计算机设备
KR20240019738A (ko) 사이버 위협 정보 처리 장치, 사이버 위협 정보 처리방법 및 사이버 위협 정보 처리하는 프로그램을 저장하는 저장매체
Fink Automated XSS vulnerability detection through context aware fuzzing and dynamic analysis

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21945919

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023528781

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18570046

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE