GENERATION APPARATUS, GENERATION METHOD, AND GENERATION PROGRAM
The generation device automatically generates IoA-based signatures from IoCs by extracting log information and constructing graph structure data, enhancing the detection of advanced cyberattacks.
Patent Information
- Application Number
- JP2024502298
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-02-22
- Publication Date
- 2025-03-18
- Estimated Expiration
- 2042-02-22
AI Technical Summary
Conventional technologies are unable to automatically generate IoA-based signatures from IoCs, limiting their effectiveness in detecting advanced cyberattacks.
A generation device that extracts log information, constructs graph structure data using time-series information, and generates IoA-based signatures based on this data, enabling automatic signature generation from IoCs.
Enables the automatic generation of IoA-based signatures from IoCs, improving the detection of advanced cyberattacks without requiring specialized knowledge of IoA-based signature description languages.
Smart Images

Figure 0007647994000001 
Figure 0007647994000002 
Figure 0007647994000003
Abstract
Description
[Technical field]
[0001] The present invention relates to a generation device, a generation method, and a generation program. [Background technology]
[0002] Cyber attacks remain a major threat to society. To combat this threat, companies are attempting to detect cyber attacks early by defining known indicators of compromise (IoCs) as signatures and comparing them with audit logs that record operations on terminals.
[0003] However, in recent years, attack techniques have also developed, and it has been pointed out that IoC-based signatures alone cannot detect advanced attacks. Although advanced attacks cannot be detected by IoC alone, it has been reported that they can be detected by associating IoCs and viewing them as attack actions (IoA: Indicator of Attack), and many new signatures focusing on IoA have been devised. While IoA-based signatures have the expressive power to detect advanced attacks, they require learning complex syntax to write signatures, making them less easy to use than IoC-based signatures.
[0004] Examples of IoC-based automatic signature generation technologies include EIGER and iACE (see, for example, Non-Patent Documents 1 and 2). Examples of technologies for extracting IoA information include TPDrill and EXTRACTOR (see, for example, Non-Patent Documents 3 and 4). Examples of IoA-based automatic signature generation technologies include ThreatRaptor (see, for example, Non-Patent Document 5). [Prior art documents] [Non-patent literature]
[0005] [Non-Patent Document 1] Y. Kurogome et al., “EIGER: Automated IOC Generation for Accurate and Interpretable Endpoint Malware Detection”, ACSAC 2019 [Non-Patent Document 2] X. Liao et al., “Acing the IOC Game: Toward Automatic Discovery and Analysis of Open-Source Cyber Threat Intelligence”, CCS 2016 [Non-Patent Document 3] G. Husari et al., “TTPDrill: Automatic and Accurate Extraction of Threat Actions from Unstructured Text of CTI Sources”, ACSAC 2017 [Non-Patent Document 4] K. Satvat et al., “EXTRACTOR: Extracting Attack Behavior from Threat Reports”, EuroS&P 2021 [Non-Patent Document 5] P. Gao et al., “Enabling Efficient Cyber Threat Hunting With Cyber Threat Intelligence”, ICDE 2021 Summary of the Invention [Problem to be solved by the invention]
[0006] However, conventional technologies have a problem in that they cannot automatically generate IoA-based signatures from IoCs. For example, IoC signature automatic generation technology automatically generates IoC-based signatures from known IoCs and threat reports, and does not target automatic generation of IoA-based signatures. In addition, IoA information extraction technology is a technology that tags and extracts information about IoAs from threat reports and extracts them in a graph structure, and does not target automatic generation of IoA-based signatures. In addition, existing IoA-based signature automatic generation technology only supports a function to automatically generate signatures from threat reports, and does not target automatic generation of signatures from trace information discovered by users.
[0007] The present invention has been made in consideration of the above, and aims to provide a generation device, a generation method, and a generation program that can automatically generate an IoA-based signature from an IoC. [Means for solving the problem]
[0008] In order to solve the above-mentioned problems and achieve the objective, the generation device of the present invention is characterized by having an extraction unit that extracts log information containing traces of intrusion from log information, a construction unit that constructs graph structure data indicating the sequence of attack actions using time series information contained in the log information extracted by the extraction unit, and a generation unit that generates a signature indicating traces of an attack based on the graph structure data constructed by the construction unit. Effect of the Invention
[0009] According to the present invention, it is possible to automatically generate an IoA-based signature from an IoC. [Brief description of the drawings]
[0010] [Figure 1] FIG. 1 is a block diagram illustrating the configuration of a generating device according to the present embodiment. [Diagram 2]FIG. 2 is a diagram illustrating an outline of the process performed by the audit log extracting unit. [Diagram 3] FIG. 3 is a diagram illustrating the details of the process performed by the audit log extracting unit. [Figure 4] FIG. 4 is a diagram illustrating the details of the process performed by the audit log extracting unit. [Diagram 5] FIG. 5 is a diagram illustrating the details of the process performed by the audit log extracting unit. [Figure 6] FIG. 6 is a diagram illustrating the details of the process performed by the audit log extracting unit. [Figure 7] FIG. 7 is a diagram illustrating the details of the process performed by the audit log extracting unit. [Figure 8] FIG. 8 is a diagram for explaining the notation of NFA (Nondeterministic Finite Automaton). [Figure 9] FIG. 9 is a diagram illustrating an outline of the process performed by the NFA construction unit. [Figure 10] FIG. 10 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 11] FIG. 11 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 12] FIG. 12 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 13] FIG. 13 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 14] FIG. 14 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 15] FIG. 15 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 16] FIG. 16 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 17] FIG. 17 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 18] FIG. 18 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 19] FIG. 19 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 20] FIG. 20 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 21] FIG. 21 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 22] FIG. 22 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 23] FIG. 23 is a diagram for explaining details of the processing by the NFA construction unit. [Figure 24] FIG. 24 is a diagram showing an outline of the process performed by the signature generating unit. [Diagram 25] FIG. 25 is a diagram for explaining details of the process performed by the signature generating unit. [Figure 26] FIG. 26 is a diagram for explaining details of the process performed by the signature generating unit. [Figure 27] FIG. 27 is a diagram for explaining details of the process performed by the signature generating unit. [Figure 28] FIG. 28 is a diagram for explaining details of the process performed by the signature generating unit. [Figure 29] FIG. 29 is a diagram for explaining details of the process performed by the signature generating unit. [Diagram 30] FIG. 30 is a diagram for explaining the notation of the ELL signature. [Diagram 31] FIG. 31 is a diagram illustrating an example of an ELL signature. [Diagram 32] FIG. 32 is a diagram illustrating an example of the audit log. [Diagram 33] FIG. 33 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Diagram 34] FIG. 34 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Diagram 35] FIG. 35 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Diagram 36]FIG. 36 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Figure 37] FIG. 37 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Figure 38] FIG. 38 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Figure 39] FIG. 39 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Diagram 40] FIG. 40 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Diagram 41] FIG. 41 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Diagram 42] FIG. 42 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Diagram 43] FIG. 43 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Diagram 44] FIG. 44 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Diagram 45] FIG. 45 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Diagram 46] FIG. 46 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Figure 47] FIG. 47 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Figure 48] FIG. 48 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Figure 49]FIG. 49 is a diagram illustrating an example of checking whether there is any trace of the IoA level in an audit log using ELL. [Figure 50] FIG. 50 is a flowchart illustrating an example of a processing procedure by the generating device. [Figure 51] FIG. 51 is a diagram illustrating a computer that executes a program. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0011] Hereinafter, embodiments of a generating device, a generating method, and a generating program according to the present application will be described in detail with reference to the accompanying drawings. The present invention is not limited to the embodiments described below.
[0012] [Configuration of the generator] FIG. 1 is a block diagram illustrating a configuration of a generating device according to the present embodiment. As illustrated in FIG. 1, the generating device 10 according to the present embodiment extracts audit logs on which traces (trace of intrusion (IoC)) are left from audit logs (log information). Then, the generating device 10 uses time-series information included in the extracted audit logs to construct graph structure data (NFA) indicating the sequence of attack actions. For example, the generating device 10 constructs an NFA indicating the positional relationship of the traces on the audit logs. Next, the generating device 10 generates an IoA-based signature (a signature indicating a trace of an attack) based on the constructed graph structure data.
[0013] The generating device 10, for example, enables a user to obtain an IoA-based signature that captures the traces and the behavior of an attack represented by the audit log by simply collecting audit logs and IoCs, without having to learn specialized knowledge or the syntax of an IoA-based signature description language. In addition, for example, the generating device 10 compares the audit logs with IoCs to extract traces of an attack that are actually left in the audit logs, and then regards the time-series information in the audit logs as the action sequence of the attack and expresses it in a graph structure called an NFA. Since it is widely known that an NFA can be converted into a regular expression, an existing conversion algorithm is used to convert the NFA into a regular expression, and finally the regular expression is rewritten into an IoA-based signature.
[0014] The generating device 10 of this embodiment includes an audit log extracting unit 11, an NFA constructing unit 12, and a signature generating unit 13. Each unit will be described below.
[0015] The audit log extraction unit 11 extracts log information containing traces of intrusion from the audit log. For example, the audit log extraction unit 11 searches for a character string corresponding to the trace of intrusion in event data included in the audit log, and extracts event data containing the character string corresponding to the trace of intrusion.
[0016] For example, as shown in Fig. 2, the audit log extraction unit 11 checks whether or not a trace is left in the audit log, and extracts a portion where a trace is left. Fig. 2 is a diagram showing an overview of the process performed by the audit log extraction unit.
[0017] Next, the details of the processing by the audit log extraction unit will be explained using Fig. 3 to Fig. 7. Fig. 3 to Fig. 7 are diagrams for explaining the details of the processing by the audit log extraction unit. As illustrated in Fig. 3, a simplified Windows (trademark) Event Log is used as the audit log as an example. Then, the audit log extraction unit 11 searches for traces in the audit log using regular expression matching or the like. For example, as illustrated in Fig. 4, the audit log extraction unit 11 first searches for the first trace "abc.doc".
[0018] Then, as shown in Fig. 5, the audit log extraction unit 11 searches for the next trace "mal.exe". Next, as shown in Fig. 6, the audit log extraction unit 11 searches for the last trace "def.doc". Then, after searching for all traces, as shown in Fig. 7, the audit log extraction unit 11 extracts only audit logs in which traces remain.
[0019] The NFA construction unit 12 constructs graph structure data indicating the action sequence of an attack, using time-series information included in the log information extracted by the audit log extraction unit 11. For example, the NFA construction unit 12 constructs an NFA as the graph structure data. Note that the definition of NFA here is a general one such as computation theory and automaton language theory. When expressing the NFA as a diagram, the notation in FIG. 8 is used. FIG. 8 is a diagram for explaining the notation of NFA.
[0020] As shown in Figure 9, the NFA construction unit 12 constructs an NFA representing the locational relationship of trace appearances from the audit log containing traces passed from the audit log extraction unit 11 in order to obtain information on the context between traces, information on repeated traces, and ambiguity information from the audit log containing traces.
[0021] Next, the details of the processing by the NFA construction unit 12 will be described with reference to Figs. 10 to 23. Figs. 10 to 23 are diagrams for explaining the details of the processing by the NFA construction unit. As illustrated in Fig. 10, the NFA construction unit 12 sets the NFA to an initial state (step 1). Then, as illustrated in Fig. 11, the NFA construction unit 12 selects the audit log in which the first trace remains (step 2). Then, as illustrated in Fig. 12, the NFA construction unit 12 performs processing to construct an NFA (step 3). In the example of Fig. 12, since there is no vertex corresponding to "mal.exe", the NFA construction unit 12 adds a vertex corresponding to "mal.exe" and records the vertex "p" as the vertex corresponding to "mal.exe".
[0022] Then, as illustrated in Fig. 13, the NFA construction unit 12 selects the audit log containing the next trace (step 4). Then, as illustrated in Fig. 14 and Fig. 15, the NFA construction unit 12 similarly performs steps 3 and 4. Then, as illustrated in Fig. 16, since a vertex corresponding to "mal.exe" exists, the NFA construction unit 12 adds an ε transition to the vertex corresponding to "mal.exe".
[0023] Then, as illustrated in Fig. 17, the NFA construction unit 12 selects the next audit log containing a trace (step 4). Then, as illustrated in Fig. 18 to Fig. 22, the NFA construction unit 12 repeats steps 3 and 4 until all audit logs containing traces have been selected. Then, as illustrated in Fig. 23, the NFA construction unit 12 selects all audit logs containing traces and repeats steps 3 and 4, completing the NFA construction process (step 5).
[0024] The signature generation unit 13 generates a signature indicating a trace of an attack based on the graph structure data constructed by the NFA construction unit 12. For example, the signature generation unit 13 generates a signature by converting the NFA constructed by the NFA construction unit 12 into a regular expression using an algorithm.
[0025] 24, the signature generation unit 13 generates a signature from an NFA that indicates the appearance positional relationship of a trace on an audit log. For example, the signature generation unit 13 converts the NFA passed from the NFA construction unit 12 into an IoA-based signature while applying an algorithm that converts a known NFA into a regular expression. There are various algorithms for converting an NFA into a regular expression, such as the State elimination method, and any algorithm may be applied.
[0026] Next, the details of the process by the signature generation unit 13 will be described with reference to Fig. 25 to Fig. 29. Fig. 25 to Fig. 29 are diagrams for explaining the details of the process by the signature generation unit. As illustrated in Fig. 25 and Fig. 26, the signature generation unit 13 replaces each label of the NFA with a terminal symbol (step 1).
[0027] Then, as shown in Fig. 27, the signature generation unit 13 regards the label as a character and converts the NFA into a regular expression by a predetermined method (step 2). Next, as shown in Fig. 28 and Fig. 29, the signature generation unit 13 adds a predetermined right-facing wavy arrow (see Fig. 28) before each terminal symbol of the IoA-based signature (step 3), and arranges the format (step 4). Through these steps, the signature generation unit 13 generates a signature.
[0028] The signature generating unit 13 outputs the generated signature. The generated signature is used to automatically detect attacks. The attack detection process may be performed by the generating device 10 or an external device. There are many languages for describing IoA-based signatures, such as TBQL (Temporal Behavior Query Language), τ-calculus, AIQL (Attack Investigation Query Language), SAQL (Streambased Anomaly Query Language), and ELL. In the following, a case where ELL is used as an example will be described. However, the IoA-based signature targeted by this embodiment is not limited to ELL, and may be any language that can express the context, repetition, and ambiguity between traces. ELL is a language that defines the behavior of an attack as a signature based on IoA for an audit log.
[0029] Here, the ELL signature will be explained. Figure 30 is a diagram explaining the notation of the ELL signature. "Signature" in Figure 30 is the name of the signature and is an arbitrary character string that is not empty.
[0030] Also, "e" in FIG. 30 is a pattern representing IoA, and the basic ones are as follows: The terminal symbol [K=v,...] describes IoC level information, where k represents a key (e.g., ProcessId, FileName, IPAddress) and v represents a value (e.g., 0x123, mal.doc, 192.0.2.1). Repeat * means the expression that matches e repeated 0 or more times The alternation e|e means to match either the first or the next e The optional e? means that the expression matching e occurs 0 or 1 time. Skip is e → (right-facing wavy arrow) e skips unnecessary audit logs from the first e to the next e
[0031] Here, an example of checking whether there is a trace of the IoA level in the audit log using ELL is shown. FIG. 31 is a diagram for explaining an example of an ELL signature. FIG. 32 is a diagram for explaining an example of an audit log. Using the ELL signature illustrated in FIG. 31 and the audit log illustrated in FIG. 32 as examples, an example of checking whether there is a trace of the IoA level in the audit log using ELL is explained. FIGS. 33 to 49 are diagrams for explaining an example of checking whether there is a trace of the IoA level in the audit log using ELL. In the following, a right-facing wavy arrow is simply written as "→".
[0032] As shown in Figure 33, the ELL signature has a signature name of MalSig, and the IoA level trace can be read as follows: after a pattern of an audit log containing a ProcessId of 0x123 followed by an audit log containing a FileName of mal.doc is repeated 0 or more times, an audit log containing an IPAddress of 192.0.2.4 may or may not appear.
[0033] As shown in Figure 34, the audit log is a simplified Windows Event Log defined in XML, with several EventData tags within an Event tag, and each EventData tag is information recorded as a result of a single action. In the following, information enclosed in EventData tags will be referred to as a log. For example, <eventdata> <data name="”ProcessId”"> 0xacc< / data> < / eventdata> is a log that records the appearance of 0acc as a process ID.
[0034] As shown in the example of Fig. 35, first →[ProcessId=0x123] is evaluated. This means that logs are skipped until a log that records information that ProcessId is 0x123. Then, as shown in Fig. 36, the first log is skipped because ProcessId is not 0x123.
[0035] And because the next line is a log with a ProcessId of 0x123, the corresponding log was found, as shown in Figure 37, so it moves to the next log. Next, as shown in Figure 38, →[FileName=mal.doc] is evaluated. This means that logs will be skipped until the information that FileName is mal.doc is recorded. Then, as shown in Figure 39, the log currently being viewed already records mal.doc, so there is no skip and it moves to the next log.
[0036] Then, as shown in Figure 40, next (→[ProcessId=0x123]→[FileName=mal.doc]) * is evaluated. * The pattern enclosed in will be matched first from the log you are currently viewing, so in this case * Check the pattern enclosed in again.
[0037] As shown in the example of Figure 41, →[ProcessId=0x123] is evaluated again, and the process is the same as the first time. Since the log currently being viewed already records 0x123, there is no skip and the process moves to the next log. Then, as shown in the example of Figure 42, →[FileName=mal.doc] is evaluated again, and the process is the same as the first time. Since the log currently being viewed already records mal.doc, there is no skip and the process moves to the next log.
[0038] Next, as shown in Figure 43, (→[ProcessId=0x123]→[FileName=mal.doc]) * is evaluated. Here, * The pattern enclosed in will not match any log after the one currently being viewed, so it will not be repeated.
[0039] Next, as shown in the example in Figure 44, →[IPAddress=192.0.2.4]? is evaluated. The log you are currently viewing records an IPAddress, but since its value is different from 192.0.2.7, it does not match [IPAddress=192.0.2.4]. However, since [IPAddress=192.0.2.4] is enclosed in ?, it does not have to match [IPAddress=192.0.2.4].
[0040] Then, evaluation of the ELL signature is completed, as shown in the example of Figure 45. Since matching did not fail, it can be seen that the behavior defined by the signature was present in the audit log. Next, a case will be described where the behavior defined by the ELL signature is not present in the audit log, as shown in the example of Figure 46. For this ELL signature, somewhere in the audit log there is a log that records information such that ProcessId is 0x111, or there is a log that records information such that FileName is failure.pptx.
[0041] As shown in the example in Figure 47, first, (→[ProcessId=0x111]|[FileName=failure.pptx]) is evaluated. As a result, as shown in the example in Figure 48, all logs are checked but there is no log with a ProcessId of 0x111, so all logs are skipped. As shown in the example in Figure 49, since this match fails, the match of this ELL signature itself also fails. Therefore, it can be seen that this audit log does not contain any behavior defined by this ELL signature.
[0042] [Processing procedure of the generating device] Next, an example of a processing procedure of a process executed by the generating device 10 will be described with reference to Fig. 50. Fig. 50 is a flowchart showing an example of a processing procedure by the generating device.
[0043] 50, the audit log extraction unit 11 of the generating device 10 extracts audit logs in which traces are left (step S101). Then, the NFA construction unit 12 constructs an NFA that represents the appearance positional relationship of the traces on the audit log (step S102). After that, the signature generating unit 13 generates signatures of the NFAs (step S103).
[0044] [Effects of the embodiment] In this manner, the generating device 10 according to the present embodiment extracts log information in which a trace of an intrusion is left from the log information, constructs graph structure data indicating the sequence of attack actions using time series information included in the extracted log information, and generates a signature indicating the trace of an attack based on the constructed graph structure data. This allows the generating device 10 to automatically generate an IoA-based signature from an IoC.
[0045] That is, the generating device 10 automatically generates an IoA-based signature from an IoC. Therefore, for example, a worker or an operator can automatically generate a signature from an IoC of the system that he or she has discovered, and therefore it is possible to detect unknown attacks (attacks that have not been recognized as threats).
[0046] In addition, with the generation device 10, a user can simply collect IoC-level attack traces and audit logs to obtain an IoA-based signature that captures the attack behavior represented by the traces and audit logs, without having to learn specialized knowledge or the syntax of the IoA-based signature description language.
[0047] [System configuration, etc.] Each component of each device shown in the figures according to the above embodiment is a functional concept, and does not necessarily have to be physically configured as shown in the figures. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figures, and all or a part of them can be functionally or physically distributed and integrated in any unit according to various loads, usage conditions, etc. Furthermore, each processing function performed by each device can be realized in whole or in any part by a CPU and a program analyzed and executed by the CPU, or can be realized as hardware using wired logic.
[0048] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by a known method. In addition, the information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed arbitrarily unless otherwise specified.
[0049] 〔program〕 It is also possible to create a program in which the processing executed by the generating device 10 described in the above embodiment is written in a language executable by a computer. In this case, the same effect as in the above embodiment can be obtained by the computer executing the program. Furthermore, such a program may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read and executed by a computer to realize the same processing as in the above embodiment.
[0050] Fig. 51 is a diagram showing a computer that executes a program. As shown in Fig. 51, a computer 1000 includes, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070, and these components are connected by a bus 1080.
[0051] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012, as exemplified in FIG. 51. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090, as exemplified in FIG. 51. The disk drive interface 1040 is connected to a disk drive 1100, as exemplified in FIG. 51. For example, a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, as exemplified in FIG. 51. The video adapter 1060 is connected to a display 1130, as exemplified in FIG. 51.
[0052] 51, the hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the above programs are stored in the hard disk drive 1090, for example, as program modules in which instructions to be executed by the computer 1000 are written.
[0053] Furthermore, the various data described in the above embodiment are stored as program data, for example, in the memory 1010 or the hard disk drive 1090. Then, the CPU 1020 reads out the program module 1093 and the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary, and executes various processing procedures.
[0054] Note that the program module 1093 and program data 1094 relating to the program are not limited to being stored in the hard disk drive 1090, and may be stored in, for example, a removable storage medium and read by the CPU 1020 via a disk drive or the like. Alternatively, the program module 1093 and program data 1094 relating to the program may be stored in another computer connected via a network (such as a local area network (LAN) or wide area network (WAN)) and read by the CPU 1020 via the network interface 1070.
[0055] Although the embodiment to which the invention made by the present inventor is applied has been described above, the present invention is not limited by the description and drawings which form a part of the disclosure of the present invention according to the present embodiment. In other words, other embodiments, examples, operation techniques, etc. made by those skilled in the art based on the present embodiment are all included in the scope of the present invention. [Explanation of symbols]
[0056] 10 Generator 11 Audit Log Extraction Unit 12 NFA Construction Department 13 Signature Generation Unit
Claims
1. an extraction unit that extracts log information containing traces of intrusion from the log information; a construction unit that constructs graph structure data indicating an action sequence of an attack using time-series information included in the log information extracted by the extraction unit; a generation unit that generates a signature indicating an attack trace based on the graph structure data constructed by the construction unit; A generating device comprising:
2. The generating device according to claim 1, characterized in that the extraction unit searches for a character string corresponding to the trace of intrusion in event data included in the log information, and extracts event data including a character string corresponding to the trace of intrusion.
3. The generating device according to claim 1 , wherein the constructing unit constructs an NFA as the graph structure data.
4. The generating device according to claim 3 , wherein the generating unit generates a signature by converting the NFA constructed by the constructing unit into a regular expression using an algorithm.
5. A generation method performed by a generation device, comprising: an extraction step of extracting log information containing traces of intrusion from the log information; a construction step of constructing graph structure data showing an action sequence of an attack by using time series information included in the log information extracted by the extraction step; A generation step of generating a signature indicating a trace of an attack based on the graph structure data constructed by the construction step; A method of generating the same, comprising:
6. An extraction step of extracting log information containing traces of intrusion from the log information; a construction step of constructing graph structure data showing an action sequence of an attack by using time series information included in the log information extracted by the extraction step; A generation step of generating a signature indicating an attack trace based on the graph structure data constructed by the construction step; A generating program that causes a computer to execute the above.
Citation Information
Patent Citations
Semantically-aware network intrusion signature generator
US20060212942A1
Information processing device and information processing program
WO2020075333A1