WO2023162047A1 - 生成装置、生成方法および生成プログラム - Google Patents

生成装置、生成方法および生成プログラム Download PDF

Info

Publication number
WO2023162047A1
WO2023162047A1 PCT/JP2022/007419 JP2022007419W WO2023162047A1 WO 2023162047 A1 WO2023162047 A1 WO 2023162047A1 JP 2022007419 W JP2022007419 W JP 2022007419W WO 2023162047 A1 WO2023162047 A1 WO 2023162047A1
Authority
WO
WIPO (PCT)
Prior art keywords
generation
signature
traces
log information
unit
Prior art date
Application number
PCT/JP2022/007419
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/JP2022/007419 priority Critical patent/WO2023162047A1/ja
Publication of WO2023162047A1 publication Critical patent/WO2023162047A1/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 a generation device, a generation method, and a generation program.
  • IoC-based signatures have high expressiveness enough to detect advanced attacks, they are not as easy to use as compared to IoC-based signatures, because signature descriptions require a complicated syntax to be memorized.
  • IoC-based automatic signature generation technologies include EIGER and iACE (see, for example, Non-Patent Documents 1 and 2).
  • Techniques for extracting IoA information include, for example, TP Drill and EXTRACTOR (see Non-Patent Documents 3 and 4, for example).
  • ThreatRaptor see, for example, Non-Patent Document 5).
  • IoA-based signatures could not be automatically generated from IoC.
  • the IoC signature automatic generation technology automatically generates IoC-based signatures from known IoCs, threat reports, etc., and does not automatically generate IoA-based signatures.
  • IoA information extraction technology is a technology for tagging and extracting information related to IoA from threat reports and the like, or extracting it in a graph structure, and automatic generation of IoA-based signatures is out of scope.
  • existing IoA-based automatic signature generation technology only supports the function of automatically generating signatures from threat reports, and does not support the automatic generation of signatures from trace information discovered by users.
  • the present invention has been made in view of the above, and aims to provide a generation device, generation method, and generation program capable of automatically generating an IoA-based signature from an IoC.
  • the generation apparatus of the present invention includes an extraction unit for extracting log information in which traces of intrusion remain from log information, and log information extracted by the extraction unit.
  • a constructing unit that constructs graph structure data indicating the order of attack actions using the time-series information contained in , and a signature that indicates traces of an attack based on the graph structure data constructed by the constructing unit. and a generator.
  • FIG. 1 is a block diagram illustrating the configuration of the generation device of this embodiment.
  • FIG. 2 is a diagram illustrating an overview of processing by an audit log extraction unit;
  • FIG. 3 is a diagram for explaining details of processing by the audit log extraction unit.
  • FIG. 4 is a diagram illustrating details of processing by the audit log extraction unit.
  • FIG. 5 is a diagram illustrating details of processing by the audit log extraction unit.
  • FIG. 6 is a diagram illustrating details of processing by the audit log extraction unit.
  • FIG. 7 is a diagram illustrating details of processing by the audit log extraction unit.
  • FIG. 8 is a diagram explaining the notation of NFA (Nondeterministic Finite Automaton).
  • FIG. 9 is a diagram illustrating an overview of processing by the NFA construction unit.
  • FIG. 1 is a block diagram illustrating the configuration of the generation device of this embodiment.
  • FIG. 2 is a diagram illustrating an overview of processing by an audit log extraction unit
  • FIG. 3 is a diagram for explaining details of processing by the
  • FIG. 10 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 11 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 12 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 13 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 14 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 15 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 16 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 17 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 18 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 19 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 19 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 20 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 21 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 22 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 23 is a diagram illustrating details of processing by the NFA construction unit.
  • FIG. 24 is a diagram illustrating an overview of processing by a signature generation unit;
  • FIG. 25 is a diagram illustrating details of processing by the signature generation unit.
  • FIG. 26 is a diagram illustrating details of processing by the signature generation unit.
  • FIG. 27 is a diagram illustrating details of processing by the signature generation unit.
  • FIG. 28 is a diagram illustrating details of processing by the signature generation unit.
  • FIG. 29 is a diagram illustrating details of processing by the signature generation unit.
  • FIG. 29 is a diagram illustrating details of processing by the signature generation unit.
  • FIG. 30 is a diagram for explaining the ELL signature notation.
  • FIG. 31 is a diagram explaining an example of an ELL signature.
  • FIG. 32 is a diagram explaining an example of an audit log.
  • FIG. 33 is a diagram for explaining an example of checking whether or not there is an IoA level trace in an audit log using ELL.
  • FIG. 34 is a diagram illustrating an example of checking whether or not there is an IoA level trace in an audit log using ELL.
  • FIG. 35 is a diagram illustrating an example of checking whether or not there is an IoA level trace in an audit log using ELL.
  • FIG. 36 is a diagram illustrating an example of checking whether or not there is an IoA level trace in an audit log using ELL.
  • FIG. 37 is a diagram illustrating an example of checking whether or not there is an IoA level trace in the audit log using ELL.
  • FIG. 38 is a diagram for explaining an example of checking whether or not there is an IoA level trace in an audit log using ELL.
  • FIG. 39 is a diagram illustrating an example of checking whether or not there is an IoA level trace in an audit log using ELL.
  • FIG. 40 is a diagram illustrating an example of checking whether or not there is an IoA level trace in an audit log using ELL.
  • FIG. 41 is a diagram illustrating an example of checking whether or not there is an IoA level trace in an audit log using ELL.
  • FIG. 42 is a diagram illustrating an example of checking whether there is an IoA level trace in an audit log using ELL.
  • FIG. 43 is a diagram for explaining an example of checking whether or not there is an IoA level trace in an audit log using ELL.
  • FIG. 44 is a diagram illustrating an example of checking whether or not there is an IoA level trace in the audit log using ELL.
  • FIG. 45 is a diagram illustrating an example of checking whether or not there is an IoA level trace in the audit log using ELL.
  • FIG. 46 is a diagram illustrating an example of checking whether there is an IoA level trace in an audit log using ELL.
  • FIG. 47 is a diagram illustrating an example of checking whether or not there is an IoA level trace in the audit log using ELL.
  • FIG. 48 is a diagram illustrating an example of checking whether or not there is an IoA level trace in an audit log using ELL.
  • FIG. 44 is a diagram illustrating an example of checking whether or not there is an IoA level trace in the audit log using ELL.
  • FIG. 45 is a diagram illustrating an example of checking whether or not there is
  • FIG. 49 is a diagram illustrating an example of checking whether or not there is a trace of the IoA level in the audit log using ELL.
  • FIG. 50 is a flowchart illustrating an example of a processing procedure by the generating device;
  • FIG. 51 is a diagram showing a computer executing a program.
  • FIG. 1 is a block diagram illustrating the configuration of the generation device of this embodiment.
  • the generating device 10 of the present embodiment extracts audit logs in which traces (traces of intrusion (IoC)) are left from audit logs (log information). Then, the generation device 10 constructs graph structure data (NFA) indicating the action order of attacks using the time-series information included in the extracted audit log. For example, the generation device 10 constructs an NFA representing the appearance positional relationship of traces on the audit log. Next, the generation device 10 generates an IoA-based signature (a signature indicating traces of an attack) based on the constructed graph structure data.
  • IoA-based signature a signature indicating traces of an attack
  • the generation device 10 can generate an IoA-based signature that captures the attack behavior represented by the trace and audit log, without memorizing specialized knowledge or the syntax of the IoA-based signature description language, for example, just by collecting audit logs and IoC. so that it can be obtained. Also, for example, after the generation device 10 compares the audit log and the IoC and extracts traces of the attack actually left in the audit log, the chronological information of the audit log is regarded as the action order of the attack, which is called NFA. Represent with a graph structure. Since it is widely known that NFAs can be converted into regular expressions, existing conversion algorithms are used to convert NFAs into regular expressions, and finally, the regular expressions are rewritten into IoA-based signatures.
  • the generation device 10 of this embodiment has an audit log extraction unit 11 , an NFA construction unit 12 and a signature generation unit 13 . Each part will be described below.
  • the audit log extraction unit 11 extracts log information that leaves traces of intrusion from the audit log. For example, the audit log extraction unit 11 searches for a character string corresponding to traces of intrusion in event data included in the audit log, and extracts event data including character strings corresponding to traces of intrusion.
  • FIG. 2 is a diagram illustrating an overview of processing by an audit log extraction unit
  • FIG. 3 to 7 are diagrams for explaining the details of processing by the audit log extractor.
  • a simplified Windows (registered trademark) Event Log is used as an audit log.
  • the audit log extraction unit 11 searches for traces in the audit log by 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".
  • the audit log extraction unit 11 searches for the next trace "mal.exe”. Subsequently, as illustrated in FIG. 6, the audit log extraction unit 11 searches for the last trace "def.doc”. Then, as illustrated in FIG. 7, the audit log extracting unit 11 searches for all traces, and then extracts only audit logs in which traces remain.
  • the NFA construction unit 12 constructs graph structure data indicating the attack action order using time-series information included in the log information extracted by the audit log extraction unit 11 .
  • the NFA constructing unit 12 constructs an NFA as graph structure data.
  • the definition of NFA minimizes general ones such as computation theory and automaton language theory.
  • FIG. 8 is a diagram explaining the notation of NFA.
  • the NFA construction unit 12 obtains information on the sequential relationship between traces, information on traces that are repeatedly left, and information on ambiguity from audit logs in which traces are left.
  • An NFA representing the appearance positional relationship of traces is constructed from the passed audit log in which traces are left.
  • FIGS. 10 to 23 are diagrams for explaining the details of processing by the NFA construction unit.
  • the NFA construction unit 12 initializes the NFA (procedure 1).
  • the NFA construction unit 12 selects the audit log in which the leading trace is left (procedure 2).
  • the NFA construction unit 12 performs processing for constructing the NFA (procedure 3).
  • the NFA construction unit 12 adds a vertex corresponding to "mal.exe” and corresponds vertex "p" to "mal.exe”. Record it as the vertex that
  • the NFA construction unit 12 selects the audit log with the following trace left (procedure 4). Then, as exemplified in FIGS. 14 and 15, the NFA construction unit 12 similarly performs procedure 3 and procedure 4. FIG. Then, as illustrated in FIG. 16, the NFA construction unit 12 adds an ⁇ transition to the vertex corresponding to "mal.exe” because there is a vertex corresponding to "mal.exe”.
  • the NFA construction unit 12 selects the audit log with the following trace left (procedure 4). Then, as exemplified in FIGS. 18 to 22, the NFA construction unit 12 repeats procedures 3 and 4 until all audit logs with traces are selected. Then, as exemplified in FIG. 23 , the NFA construction unit 12 selects audit logs in which all traces are left, and repeats procedures 3 and 4 to complete the NFA construction process (procedure 5). .
  • the signature generation unit 13 generates signatures indicating traces of attacks based on the graph structure data constructed by the NFA construction unit 12. For example, the signature generation unit 13 converts the NFA constructed by the NFA construction unit 12 into a regular expression using an algorithm to generate a signature.
  • the signature generation unit 13 generates signatures from NFAs representing the appearance positional relationships of traces on the 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 for converting a known NFA into a regular expression. There are various algorithms for converting NFAs into regular expressions, such as the State elimination method, and any algorithm may be applied.
  • FIGS. 25 to 29 are diagrams for explaining the details of processing by the signature generation unit.
  • the signature generator 13 replaces each label of the NFA with a terminal symbol (procedure 1).
  • the signature generation unit 13 regards the label as characters and converts the NFA into a regular expression using a predetermined method (procedure 2). Subsequently, as illustrated in FIGS. 28 and 29, the signature generation unit 13 adds a predetermined right-pointing wavy arrow (see FIG. 28) before each terminal symbol of the IoA-based signature (step 3), and format (Step 4). The signature generation unit 13 generates a signature according to such a procedure.
  • the signature generation unit 13 outputs the generated signature.
  • the generated signatures are used to automatically detect attacks.
  • the attack detection process may be performed by the generation device 10 or by an external device.
  • IoA-based signatures such as TBQL (Temporal Behavior Query Language), ⁇ -calculus, AIQL (Attack Investigation Query Language), SAQL (Streambased Anomaly Query Language), ELL, etc. .
  • TBQL Temporal Behavior Query Language
  • AIQL Acttack Investigation Query Language
  • SAQL Streambased Anomaly Query Language
  • ELL etc.
  • a case of using ELL as an example will be described below.
  • the IoA-based signature targeted by this embodiment is not limited to ELL, and any signature that can express context, repetition, and ambiguity between traces may be used.
  • ELL is a language that defines attack behaviors as signatures on an IoA basis for audit logs.
  • FIG. 30 is a diagram for explaining the ELL signature notation.
  • Signature in FIG. 30 is the name of the signature and is any non-empty character string.
  • e in FIG. 30 is a pattern representing IoA, and the basic pattern is as follows.
  • the terminal symbols [K v, . , 192.0.2.1) a repetition e * means zero or more repetitions of the expression matching e the choice e
  • Skip is e ⁇ (rightward squiggly arrow) e skips unnecessary audit logs from the first e to the next e
  • FIG. 31 is a diagram explaining an example of an ELL signature.
  • FIG. 32 is a diagram explaining an example of an audit log. Using the ELL signature illustrated in FIG. 31 and the audit log illustrated in FIG. 32 as an example, an example of checking whether or not there is an IoA level trace in the audit log using ELL will be described.
  • FIGS. 33 to 49 are diagrams for explaining an example of checking whether or not there is an IoA level trace in the audit log using ELL. In addition, below, the rightward wavy line arrow is simply described as " ⁇ ".
  • the ELL signature has a signature name of MalSig
  • traces at the IoA level have a pattern in which an audit log with a ProcessId of 0x123 is followed by an audit log with a FileName of mal.doc. After zero or more iterations, it reads that the audit log may or may not appear with IPAddress containing 192.0.2.4.
  • the audit log is a simplified Windows Event Log defined in XML, with several EventData tags in the Event tags, and each EventData tag is information recorded by one action. is.
  • Information enclosed by EventData tags is hereinafter referred to as a log.
  • next line is a log with a ProcessId of 0x123, as shown in FIG. 37
  • the corresponding log can be found, so it is moved to the next log.
  • FIG. 39 since the log currently being viewed already records mal.doc, there is no skip and the next log is moved to.
  • the evaluation of the ELL signature is completed. Since the matching did not fail, we know that the behavior defined by the signature was present in the audit log.
  • FIG. 46 a case where no action defined by the ELL signature exists in the audit log will be described.
  • This ELL signature indicates that there is a log somewhere in the audit log that records information such as ProcessId 0x111, or FileName is failure. There is a log that records information such as pptx.
  • FIG. 50 is a flowchart illustrating an example of a processing procedure by the generating device
  • the audit log extraction unit 11 of the generation device 10 extracts an audit log that leaves traces (step S101). Then, the NFA constructing unit 12 constructs an NFA representing the appearance positional relationship of the traces on the audit log (step S102). Thereafter, the signature generator 13 generates signatures of NFAk and others (step S103).
  • the generation device 10 of the present embodiment extracts log information in which traces of intrusion remain from the log information, and uses time-series information included in the extracted log information to detect attacks. Then, based on the constructed graph structure data, signatures indicating traces of attacks are generated. Therefore, the generation device 10 can automatically generate an IoA-based signature from an IoC.
  • the generation device 10 automatically generates an IoA-based signature from the IoC. For this reason, for example, a worker or operator can automatically generate a signature from the discovered IoC of the own system, so unknown (not recognized as a threat) attacks can also be detected.
  • the user can simply collect IoC-level attack traces and audit logs without memorizing specialized knowledge or the syntax of the IoA-based signature description language. It is possible to obtain an IoA-based signature that captures the behavior of
  • each component of each device shown in the drawings according to the above embodiment is functionally conceptual, and does not necessarily need to be physically configured as shown in the drawing.
  • the specific form of distribution and integration of each device is not limited to the one shown in the figure, and all or part of them can be functionally or physically distributed and integrated in arbitrary units according to various loads and usage conditions. Can be integrated and configured.
  • each processing function performed by each device may be implemented in whole or in part by a CPU and a program analyzed and executed by the CPU, or implemented as hardware based on wired logic.
  • ⁇ program ⁇ It is also possible to create a program in which the processing executed by the generation device 10 described in the above embodiment is described in a computer-executable language. In this case, the same effects as those of the above embodiments can be obtained by having the computer execute the program. Further, such a program may be recorded in a computer-readable recording medium, and the program recorded in this recording medium may be read by a computer and executed to realize processing similar to that of the above embodiments.
  • FIG. 51 is a diagram showing a computer that executes a program.
  • computer 1000 includes, for example, memory 1010, CPU 1020, hard disk drive interface 1030, disk drive interface 1040, serial port interface 1050, video adapter 1060, and network interface 1070. , and these units are connected by a bus 1080 .
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012, as illustrated in FIG.
  • the ROM 1011 stores a boot program such as BIOS (Basic Input Output System).
  • Hard disk drive interface 1030 is connected to hard disk drive 1090 as illustrated in FIG.
  • Disk drive interface 1040 is connected to disk drive 1100 as illustrated in FIG.
  • a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100 .
  • the serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120, as illustrated in FIG.
  • Video adapter 1060 is connected to display 1130, for example, as illustrated in FIG.
  • the hard disk drive 1090 stores an OS 1091, application programs 1092, program modules 1093, and program data 1094, for example. That is, the above program is stored in, for example, the hard disk drive 1090 as a program module in which instructions to be executed by the computer 1000 are described.
  • the various data described in the above embodiments are stored as program data 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 various processing procedures.
  • program module 1093 and program data 1094 related to the program are not limited to being stored in the hard disk drive 1090, and may be stored in a removable storage medium, for example, and read out by the CPU 1020 via a disk drive or the like. .
  • the program module 1093 and program data 1094 related to the program are stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.), and via the network interface 1070 It may be read by CPU 1020 .
  • LAN Local Area Network
  • WAN Wide Area Network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

生成装置（１０）は、ログ情報から侵入の痕跡が残されているログ情報を抽出し、抽出したログ情報に含まれる時系列の情報を用いて、攻撃の行動順序を示すグラフ構造データを構築し、構築したグラフ構造データに基づいて、攻撃の痕跡を示すシグネチャを生成する。

Description

生成装置、生成方法および生成プログラム
　本発明は、生成装置、生成方法および生成プログラムに関する。
　従来、サイバー攻撃は依然として社会にとって大きな脅威である。企業では、この脅威に対抗すべく、既知の攻撃の痕跡（ＩｏＣ：Indicator　of　Compromise）をシグネチャとして定義し、端末上での動作を記録した監査ログと突合することで早期にサイバー攻撃の検知を試みている。
　ところが近年では攻撃技術も発展しており、ＩｏＣベースのシグネチャだけでは発展した攻撃を検知できないことが指摘されている。また発展した攻撃はＩｏＣだけでは検知できないものの、ＩｏＣを関連付け攻撃の行動（ＩｏＡ：Indicator　of　Attack）としてみると検知ができるとの報告もされており、ＩｏＡに着目した新たなシグネチャが多く考案されている。ＩｏＡベースのシグネチャは発展した攻撃を検知できるだけの高い表現力を持っている一方で、シグネチャの記述には複雑な構文を覚える必要がありＩｏＣベースのシグネチャと比べ利用が容易ではない。
　ＩｏＣベースのシグネチャ自動生成技術として、例えば、ＥＩＧＥＲおよびｉＡＣＥがある（例えば、非特許文献１、２参照）。また、ＩｏＡ情報を抽出する技術として、例えば、ＴＰＤｒｉｌｌおよびＥＸＴＲＡＣＴＯＲがある（例えば、非特許文献３、４参照）。また、ＩｏＡベースのシグネチャ自動生成技術として、例えば、ＴｈｒｅａｔＲａｐｔｏｒがある（例えば、非特許文献５参照）。
　しかしながら、従来の技術では、ＩｏＣからＩｏＡベースのシグネチャを自動で生成することができないという課題があった。例えば、ＩｏＣのシグネチャ自動生成技術は、既知のＩｏＣや脅威レポートなどからＩｏＣベースのシグネチャを自動で生成するものであり、ＩｏＡベースのシグネチャを自動生成することは対象外である。また、ＩｏＡ情報抽出技術は、脅威レポートなどからＩｏＡに関する情報をタグ付けした上で抽出したりグラフ構造で抽出したりする技術であり、ＩｏＡベースのシグネチャを自動生成することは対象外である。また、既存のＩｏＡベースのシグネチャ自動生成技術では、脅威レポートからシグネチャを自動で生成する機能しかサポートしておらず、ユーザが発見した痕跡情報からシグネチャを自動生成することは対象外である。
　本発明は、上記に鑑みてなされたものであって、ＩｏＣからＩｏＡベースのシグネチャを自動で生成することができる生成装置、生成方法および生成プログラムを提供することを目的とする。
　上述した課題を解決し、目的を達成するために、本発明の生成装置は、ログ情報から侵入の痕跡が残されているログ情報を抽出する抽出部と、前記抽出部によって抽出されたログ情報に含まれる時系列の情報を用いて、攻撃の行動順序を示すグラフ構造データを構築する構築部と、前記構築部によって構築されたグラフ構造データに基づいて、攻撃の痕跡を示すシグネチャを生成する生成部とを有することを特徴とする。
　本発明によれば、ＩｏＣからＩｏＡベースのシグネチャを自動で生成することが可能となる。
図１は、本実施形態の生成装置の構成を例示するブロック図である。 図２は、監査ログ抽出部による処理の概要を示す図である。 図３は、監査ログ抽出部による処理の詳細を説明する図である。 図４は、監査ログ抽出部による処理の詳細を説明する図である。 図５は、監査ログ抽出部による処理の詳細を説明する図である。 図６は、監査ログ抽出部による処理の詳細を説明する図である。 図７は、監査ログ抽出部による処理の詳細を説明する図である。 図８は、ＮＦＡ（Nondeterministic　Finite　Automaton）の表記について説明する図である。 図９は、ＮＦＡ構築部による処理の概要を示す図である。 図１０は、ＮＦＡ構築部による処理の詳細を説明する図である。 図１１は、ＮＦＡ構築部による処理の詳細を説明する図である。 図１２は、ＮＦＡ構築部による処理の詳細を説明する図である。 図１３は、ＮＦＡ構築部による処理の詳細を説明する図である。 図１４は、ＮＦＡ構築部による処理の詳細を説明する図である。 図１５は、ＮＦＡ構築部による処理の詳細を説明する図である。 図１６は、ＮＦＡ構築部による処理の詳細を説明する図である。 図１７は、ＮＦＡ構築部による処理の詳細を説明する図である。 図１８は、ＮＦＡ構築部による処理の詳細を説明する図である。 図１９は、ＮＦＡ構築部による処理の詳細を説明する図である。 図２０は、ＮＦＡ構築部による処理の詳細を説明する図である。 図２１は、ＮＦＡ構築部による処理の詳細を説明する図である。 図２２は、ＮＦＡ構築部による処理の詳細を説明する図である。 図２３は、ＮＦＡ構築部による処理の詳細を説明する図である。 図２４は、シグネチャ生成部による処理の概要を示す図である。 図２５は、シグネチャ生成部による処理の詳細を説明する図である。 図２６は、シグネチャ生成部による処理の詳細を説明する図である。 図２７は、シグネチャ生成部による処理の詳細を説明する図である。 図２８は、シグネチャ生成部による処理の詳細を説明する図である。 図２９は、シグネチャ生成部による処理の詳細を説明する図である。 図３０は、ＥＬＬシグネチャの記法について説明する図である。 図３１は、ＥＬＬシグネチャの一例について説明する図である。 図３２は、監査ログの一例について説明する図である。 図３３は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図３４は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図３５は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図３６は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図３７は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図３８は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図３９は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図４０は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図４１は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図４２は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図４３は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図４４は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図４５は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図４６は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図４７は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図４８は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図４９は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例について説明する図である。 図５０は、生成装置による処理手順の一例を示すフローチャートである。 図５１は、プログラムを実行するコンピュータを示す図である。
　以下に、本願に係る生成装置、生成方法および生成プログラムの実施の形態を図面に基づいて詳細に説明する。また、本発明は、以下に説明する実施の形態により限定されるものではない。
［生成装置の構成］
　図１は、本実施形態の生成装置の構成を例示するブロック図である。図１に例示するように、本実施形態の生成装置１０は、監査ログ（ログ情報）から痕跡（侵入の痕跡（ＩｏＣ））が残された監査ログを抽出する。そして、生成装置１０は、抽出した監査ログに含まれる時系列の情報を用いて、攻撃の行動順序を示すグラフ構造データ（ＮＦＡ）を構築する。例えば、生成装置１０は、監査ログ上の痕跡の出現位置関係を表すＮＦＡを構築する。続いて、生成装置１０は、構築したグラフ構造データに基づいて、ＩｏＡベースのシグネチャ（攻撃の痕跡を示すシグネチャ）を生成する。
　生成装置１０は、例えば、監査ログとＩｏＣを集めるだけで専門的な知識やＩｏＡベースのシグネチャ記述言語の構文を覚えることなく、その痕跡と監査ログが表す攻撃の振る舞いをとらえるＩｏＡベースのシグネチャを得ることができるようにするものである。また、例えば、生成装置１０は、監査ログとＩｏＣを突合し実際に監査ログに残された攻撃の痕跡を抽出した後、監査ログの持つ時系列の情報を攻撃の行動順序とみなし、ＮＦＡと呼ばれるグラフ構造で表現する。ＮＦＡは、正規表現に変換できることが広く知られているため、既存の変換アルゴリズムを用いてＮＦＡを正規表現に変換し、最後に正規表現をＩｏＡベースのシグネチャに書き換える。
　本実施形態の生成装置１０は、監査ログ抽出部１１、ＮＦＡ構築部１２およびシグネチャ生成部１３を有する。以下に、各部について説明する。
　監査ログ抽出部１１は、監査ログから侵入の痕跡が残されているログ情報を抽出する。例えば、監査ログ抽出部１１は、監査ログに含まれるイベントデータに侵入の痕跡に対応する文字列があるか検索し、侵入の痕跡に対応する文字列を含むイベントデータを抽出する。
　例えば、図２に例示するように、監査ログ抽出部１１は、監査ログ中に痕跡が残されているかどうかを確認し、痕跡が残されているような箇所を抽出する。図２は、監査ログ抽出部による処理の概要を示す図である。
　次に、図３～図７を用いて、監査ログ抽出部による処理の詳細を説明する。図３～図７は、監査ログ抽出部による処理の詳細を説明する図である。図３に例示するように、個々では例として、監査ログは簡略化したＷｉｎｄｏｗｓ（商標登録）　Ｅｖｅｎｔ　Ｌｏｇを用いる。そして、監査ログ抽出部１１は、正規表現マッチなどで監査ログ中の痕跡を検索する。例えば、図４に例示するように、監査ログ抽出部１１は、まず、最初の痕跡「abc.doc」について検索を行う。
　そして、図５に例示するように、監査ログ抽出部１１は、次の痕跡「mal.exe」について検索を行う。続いて、図６に例示するように、監査ログ抽出部１１は、最後の痕跡「def.doc」について検索を行う。そして、監査ログ抽出部１１は、図７に例示するように、全ての痕跡について検索を行った後、痕跡の残っていた監査ログのみを抽出する。
　ＮＦＡ構築部１２は、監査ログ抽出部１１によって抽出されたログ情報に含まれる時系列の情報を用いて、攻撃の行動順序を示すグラフ構造データを構築する。例えば、ＮＦＡ構築部１２は、グラフ構造データとして、ＮＦＡを構築する。なお、ここでは、ＮＦＡの定義は、計算理論とオートマトン言語理論など一般的なものを最小する。ＮＦＡを図としてあらわす際には、図８の表記を用いる。図８は、ＮＦＡの表記について説明する図である。
　図９に示すように、ＮＦＡ構築部１２は、痕跡の残された監査ログから痕跡間の前後関係や繰り返し残されている痕跡の情報、曖昧性の情報を得るため、監査ログ抽出部１１から渡された痕跡の残された監査ログから痕跡の出現位置関係を表すＮＦＡを構築する。
　次に、図１０～図２３を用いて、ＮＦＡ構築部１２による処理の詳細を説明する。図１０～図２３は、ＮＦＡ構築部による処理の詳細を説明する図である。図１０に例示するように、ＮＦＡ構築部１２は、ＮＦＡを初期状態とする（手順１）。そして、図１１に例示するように、ＮＦＡ構築部１２は、先頭の痕跡の残された監査ログを選択する（手順２）。そして、図１２に例示するように、ＮＦＡ構築部１２は、ＮＦＡを構築する処理を行う（手順３）。図１２の例では、ＮＦＡ構築部１２は、「mal.exe」と対応する頂点がないので、「mal.exe」と対応する頂点を追加し、頂点「ｐ」を「mal.exe」と対応する頂点として記録する。
　そして、図１３に例示するように、ＮＦＡ構築部１２は、次の痕跡の残された監査ログを選択する（手順４）。そして、図１４および図１５に例示するように、ＮＦＡ構築部１２は、同様に、手順３および手順４を行う。そして、図１６に例示するように、ＮＦＡ構築部１２は、「mal.exe」と対応する頂点が存在するので、「mal.exe」と対応する頂点にε遷移を追加する。
　そして、図１７に例示するように、ＮＦＡ構築部１２は、次の痕跡の残された監査ログを選択する（手順４）。そして、図１８～図２２に例示するように、ＮＦＡ構築部１２は、全ての痕跡の残された監査ログを選択するまで、手順３および手順４を繰り返し行う。そして、図２３に例示するように、ＮＦＡ構築部１２は、全ての痕跡の残された監査ログを選択して手順３および手順４を繰り返し行うと、ＮＦＡの構築処理を完了する（手順５）。
　シグネチャ生成部１３は、ＮＦＡ構築部１２によって構築されたグラフ構造データに基づいて、攻撃の痕跡を示すシグネチャを生成する。例えば、シグネチャ生成部１３は、ＮＦＡ構築部１２によって構築されたＮＦＡを正規表現に変換するアルゴリズムにより変換してシグネチャを生成する。
　例えば、図２４に例示するように、シグネチャ生成部１３は、監査ログ上の痕跡の出現位置関係を表すＮＦＡからシグネチャを生成する。例えば、シグネチャ生成部１３は、ＮＦＡ構築部１２から渡されたＮＦＡを、既知のＮＦＡから正規表現に変換するアルゴリズムを適用しつつＩｏＡベースのシグネチャに変換する。なお、ＮＦＡを正規表現に変換するアルゴリズムは様々なものがあり、例えば、State　elimination　methodなどがあり、どのアルゴリズムを適用してもよい。
　次に、図２５～図２９を用いて、シグネチャ生成部１３による処理の詳細を説明する。図２５～図２９は、シグネチャ生成部による処理の詳細を説明する図である。図２５および図２６に例示するように、シグネチャ生成部１３は、ＮＦＡの各ラベルを終端記号に置換する（手順１）。
　そして、図２７に例示するように、シグネチャ生成部１３は、ラベルを文字とみなし、所定の手法でＮＦＡを正規表現に変換する（手順２）。続いて、図２８および図２９に例示するように、シグネチャ生成部１３は、ＩｏＡベースのシグネチャ各端末記号の前に所定の右向きの波線矢印（図２８参照）を追加し（手順３）、フォーマットを整える（手順４）。このような手順により、シグネチャ生成部１３は、シグネチャを生成する。
　シグネチャ生成部１３は、生成したシグネチャを出力する。このように、生成されたシグネチャは、自動で攻撃を検知するために用いられる。なお、攻撃検知の処理は、生成装置１０が行ってもよいし、外部の装置がやってもよい。また、ＩｏＡベースのシグネチャを記述する言語は多々存在するが、例えば、ＴＢＱＬ（Temporal　Behavior　Query　Language）、τ-calculus、ＡＩＱＬ（Attack　Investigation　Query　Language）、ＳＡＱＬ（Streambased　Anomaly　Query　Language）、ＥＬＬなどがある。以下では、ＥＬＬを例に利用する場合について説明する。ただし、本実施形態が対象とするＩｏＡベースのシグネチャはＥＬＬに限定されず、痕跡間の前後関係、繰り返し、曖昧さを表現できるものであれば良い。ＥＬＬは、監査ログを対象にＩｏＡベースに攻撃の行動をシグネチャとして定義する言語である。
　ここで、ＥＬＬのシグネチャについて説明する。図３０は、ＥＬＬシグネチャの記法について説明する図である。図３０の「Ｓｉｇｎａｔｕｒｅ」は、シグネチャの名前であり空でない任意の文字列である。
　また、図３０の「ｅ」は、ＩｏＡを表すパターンであり、基本的なものは以下の通りである。
・終端記号［Ｋ＝ｖ、・・・］は、ＩｏＣレベルの情報を記述するものであり、ｋはキー（例えば、ＰｒｏｃｅｓｓＩｄ、ＦｉｌｅＮａｍｅ，ＩＰＡｄｄｒｅｓｓ）を、ｖはバリュー（例えば、０ｘ１２３，ｍａｌ.ｄｏｃ，１９２．０．２．１）を表す
・繰り返しｅ＊は、ｅにマッチする表現の０回以上の繰り返しを意味する
・選択ｅ｜ｅは、最初もしくは次のｅのいずれかにマッチすることを意味する
・オプションｅ？は、ｅにマッチする表現が０回もしくは１回出現することを意味する
・スキップはｅ→（右向きの波線矢印）ｅは、最初のｅから次のｅまで不要な監査ログをスキップする
　ここで、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例を示す。図３１は、ＥＬＬシグネチャの一例について説明する図である。図３２は、監査ログの一例について説明する図である。図３１に例示するＥＬＬシグネチャと、図３２に例示する監査ログとを例にして、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例ついて説明する。図３３～図４９は、ＥＬＬを用いた監査ログ中にＩｏＡレベルの痕跡がないかどうかの確認例ついて説明する図である。なお、以下では、右向きの波線矢印を単に「→」と記載する。
　図３３に示すように、ＥＬＬシグネチャは、シグネチャの名前がＭａｌＳｉｇであり、ＩｏＡレベルの痕跡としては、ＰｒｏｃｅｓｓＩｄが０ｘ１２３を含む監査ログの後にＦｉｌｅＮａｍｅがｍａｌ.ｄｏｃを含む監査ログが来るようなパターンが０回以上繰り返された後、ＩＰＡｄｄｒｅｓｓが１９２．０．２．４を含む監査ログが出現してもしなくても良いと、読める。
　また、図３４に示すように、監査ログは、簡略化したＷｉｎｄｏｗｓ　Ｅｖｅｎｔ　ＬｏｇがＸＭＬで定義されており、Ｅｖｅｎｔタグの中にＥｖｅｎｔＤａｔａタグがいくつかあり、ＥｖｅｎｔＤａｔａタグが１つの行動により記録された情報である。以降では、ＥｖｅｎｔＤａｔａタグで囲まれる情報をログと呼ぶ。例えば、＜ＥｖｅｎｔＤａｔａ＞＜Ｄａｔａ　Ｎａｍｅ＝”ＰｒｏｃｅｓｓＩｄ”＞０ｘａｃｃ＜／Ｄａｔａ＞＜／ＥｖｅｎｔＤａｔａ＞はプロセスＩＤとして０ａｃｃが出現したことを記録するログである。
　図３５に例示するように、まず→［ＰｒｏｃｅｓｓＩｄ＝０ｘ１２３］が評価される。これはＰｒｏｃｅｓｓＩｄが０ｘ１２３であるという情報を記録するログまでログをスキップすることを意味する。そして、図３６に示すように、最初のログはＰｒｏｃｅｓｓＩｄが０ｘ１２３でないので、スキップされる。
　そして、次の行がＰｒｏｃｅｓｓＩｄが０ｘ１２３のログであるため、図３７に示すように、該当のログを見つけることができたので、その次のログへ移動させる。次に、図３８に示すように、→［ＦｉｌｅＮａｍｅ＝ｍａｌ.ｄｏｃ］が評価される。これは、ＦｉｌｅＮａｍｅがｍａｌ.ｄｏｃであるという情報を記録するまでログをスキップすることを意味する。そして、図３９に示すように、今みているログがすでにｍａｌ.ｄｏｃを記録するものなのでスキップはなく次のログへ移動する。
　そして、図４０に例示するように、次に（→［ＰｒｏｃｅｓｓＩｄ＝０ｘ１２３］→［ＦｉｌｅＮａｍｅ＝ｍａｌ.ｄｏｃ］）＊が評価される。＊で囲まれるパターンは今見ているログから先にマッチするので、ここでは＊で囲まれるパターンの確認を再び行う。 
　図４１に例示するように、再び、→［ＰｒｏｃｅｓｓＩｄ＝０ｘ１２３］を評価するため、最初と同様に処理を行う。今見ているログが既に０ｘ１２３を記録するものなのでスキップはなく次のログへ移動する。そして、図４２に例示するように、再び→［ＦｉｌｅＮａｍｅ＝ｍａｌ.ｄｏｃ］を評価するため、最初と同様処理を行う。今見ているログが既にｍａｌ.ｄｏｃを記録するものなのでスキップはなく次のログへ移動する。
　続いて、図４３に例示するように、（→［ＰｒｏｃｅｓｓＩｄ＝０ｘ１２３］→［ＦｉｌｅＮａｍｅ＝ｍａｌ.ｄｏｃ］）＊が評価される。ここではもうすでに＊で囲まれるパターンは今見ているログ以降にマッチしないので繰り返し行わない。
　次に、図４４に例示するように、→［ＩＰＡｄｄｒｅｓｓ＝１９２．０．２．４］？が評価される。今見ているログはＩＰＡｄｄｒｅｓｓを記録しているが１９２．０．２．７とバリューが違うので［ＩＰＡｄｄｒｅｓｓ＝１９２．０．２．４］にはマッチしない。しかし、［ＩＰＡｄｄｒｅｓｓ＝１９２．０．２．４］は？で囲まれているため［ＩＰＡｄｄｒｅｓｓ＝１９２．０．２．４］にマッチしなくても良い。
　そして、図４５に例示するように、ＥＬＬシグネチャの評価が完了する。マッチングに失敗しなかったためシグネチャが定義する行動が監査ログ中に存在したことがわかる。次に、図４６に例示するように、監査ログ中にＥＬＬシグネチャの定義する行動が存在しない場合について説明する。このＥＬＬシグネチャは、監査ログのどこかに、ＰｒｏｃｅｓｓＩｄが０ｘ１１１であるような情報を記録したログが存在するか、ＦｉｌｅＮａｍｅがｆａｉｌｕｒｅ．ｐｐｔｘであるような情報を記録したログが存在する。
　図４７に例示するように、まず、（→［ＰｒｏｃｅｓｓＩｄ＝０ｘ１１１］｜［ＦｉｌｅＮａｍｅ＝ｆａｉｌｕｒｅ．ｐｐｔｘ］）を評価する。この結果、図４８に例示するように、ログを全て確認したがＰｒｏｃｅｓｓＩｄが０ｘ１１１であるようなものはなかったため全てのログをスキップする。図４９に例示するように、このマッチに失敗するため、このＥＬＬシグネチャのマッチ自体も失敗となる。そのため、この監査ログには、このＥＬＬシグネチャの定義する行動がないことがわかる。
［生成装置の処理手順］
　次に、図５０を用いて、生成装置１０が実行する処理の処理手順の一例について説明する。図５０は、生成装置による処理手順の一例を示すフローチャートである。
　図５０に例示するように、生成装置１０の監査ログ抽出部１１は、痕跡の残された監査ログを抽出する（ステップＳ１０１）。そして、ＮＦＡ構築部１２は、監査ログ上の痕跡の出現位置関係を表すＮＦＡを構築する（ステップＳ１０２）。その後、シグネチャ生成部１３は、ＮＦＡｋらのシグネチャを生成する（ステップＳ１０３）。
［実施の形態の効果］
　このように、実施形態に係る本実施形態の生成装置１０は、ログ情報から侵入の痕跡が残されているログ情報を抽出し、抽出したログ情報に含まれる時系列の情報を用いて、攻撃の行動順序を示すグラフ構造データを構築し、構築したグラフ構造データに基づいて、攻撃の痕跡を示すシグネチャを生成する。このため、生成装置１０では、ＩｏＣからＩｏＡベースのシグネチャを自動で生成することが可能となる。
　つまり、生成装置１０は、ＩｏＡベースのシグネチャをＩｏＣから自動で生成する。このため、例えば、作業者やオペレータ等が、発見した自システムのＩｏＣからシグネチャを自動生成することができるため、未知の（脅威と認定されていない）攻撃についても検知することが可能である。
　また、生成装置１０では、利用者がＩｏＣレベルの攻撃の痕跡と監査ログを集めるだけで、専門的な知識やＩｏＡベースのシグネチャ記述言語の構文を覚えることなく、その痕跡と監査ログを表す攻撃の振る舞いをとらえるＩｏＡベースのシグネチャを得ることが可能である。
〔システム構成等〕
　上記実施形態に係る図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のごとく構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
　また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
〔プログラム〕
　また、上記実施形態において説明した生成装置１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。
　図５１は、プログラムを実行するコンピュータを示す図である。図５１に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。
　メモリ１０１０は、図５１に例示するように、ＲＯＭ（Read　Only　Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図５１に例示するように、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、図５１に例示するように、ディスクドライブ１１００に接続される。例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、図５１に例示するように、例えば、マウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、図５１に例示するように、例えばディスプレイ１１３０に接続される。
　ここで、図５１に例示するように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記のプログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えば、ハードディスクドライブ１０９０に記憶される。
　また、上記実施形態で説明した各種データは、プログラムデータとして、例えば、メモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種処理手順を実行する。
　なお、プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local　Area　Network）、ＷＡＮ（Wide　Area　Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　以上、本発明者によってなされた発明を適用した実施形態について説明したが、本実施形態による本発明の開示の一部をなす記述および図面により本発明は限定されることはない。すなわち、本実施形態に基づいて当業者等によりなされる他の実施形態、実施例および運用技術等は全て本発明の範疇に含まれる。
　１０　生成装置
　１１　監査ログ抽出部
　１２　ＮＦＡ構築部
　１３　シグネチャ生成部

Claims (6)

  1. 　ログ情報から侵入の痕跡が残されているログ情報を抽出する抽出部と、
    　前記抽出部によって抽出されたログ情報に含まれる時系列の情報を用いて、攻撃の行動順序を示すグラフ構造データを構築する構築部と、
    　前記構築部によって構築されたグラフ構造データに基づいて、攻撃の痕跡を示すシグネチャを生成する生成部と
    　を有することを特徴とする生成装置。
  2. 　前記抽出部は、前記ログ情報に含まれるイベントデータに前記侵入の痕跡に対応する文字列があるか検索し、前記侵入の痕跡に対応する文字列を含むイベントデータを抽出することを特徴とする請求項１に記載の生成装置。
  3. 　前記構築部は、前記グラフ構造データとして、ＮＦＡを構築することを特徴とする請求項１に記載の生成装置。
  4. 　前記生成部は、前記構築部によって構築された前記ＮＦＡを正規表現に変換するアルゴリズムにより変換してシグネチャを生成することを特徴とする請求項３に記載の生成装置。
  5. 　生成装置によって実行される生成方法であって、
    　ログ情報から侵入の痕跡が残されているログ情報を抽出する抽出工程と、
    　前記抽出工程によって抽出されたログ情報に含まれる時系列の情報を用いて、攻撃の行動順序を示すグラフ構造データを構築する構築工程と、
    　前記構築工程によって構築されたグラフ構造データに基づいて、攻撃の痕跡を示すシグネチャを生成する生成工程と
    　を含むことを特徴とする生成方法。
  6. 　ログ情報から侵入の痕跡が残されているログ情報を抽出する抽出ステップと、
    　前記抽出ステップによって抽出されたログ情報に含まれる時系列の情報を用いて、攻撃の行動順序を示すグラフ構造データを構築する構築ステップと、
    　前記構築ステップによって構築されたグラフ構造データに基づいて、攻撃の痕跡を示すシグネチャを生成する生成ステップと
    　をコンピュータに実行させることを特徴とする生成プログラム。
     
PCT/JP2022/007419 2022-02-22 2022-02-22 生成装置、生成方法および生成プログラム WO2023162047A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/007419 WO2023162047A1 (ja) 2022-02-22 2022-02-22 生成装置、生成方法および生成プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/007419 WO2023162047A1 (ja) 2022-02-22 2022-02-22 生成装置、生成方法および生成プログラム

Publications (1)

Publication Number Publication Date
WO2023162047A1 true WO2023162047A1 (ja) 2023-08-31

Family

ID=87765186

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/007419 WO2023162047A1 (ja) 2022-02-22 2022-02-22 生成装置、生成方法および生成プログラム

Country Status (1)

Country Link
WO (1) WO2023162047A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060212942A1 (en) * 2005-03-21 2006-09-21 Barford Paul R Semantically-aware network intrusion signature generator
WO2020075333A1 (ja) * 2018-10-10 2020-04-16 日本電信電話株式会社 情報処理装置及び情報処理プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060212942A1 (en) * 2005-03-21 2006-09-21 Barford Paul R Semantically-aware network intrusion signature generator
WO2020075333A1 (ja) * 2018-10-10 2020-04-16 日本電信電話株式会社 情報処理装置及び情報処理プログラム

Similar Documents

Publication Publication Date Title
Lo et al. SMArTIC: Towards building an accurate, robust and scalable specification miner
US10679135B2 (en) Periodicity analysis on heterogeneous logs
JP6488009B2 (ja) 特徴的なサブトレースマイニングを使用する、経時的グラフにおける挙動クエリ構築のための方法及びシステム
CN113821804B (zh) 一种面向第三方组件及其安全风险的跨架构自动化检测方法与系统
NL2026782B1 (en) Method and system for determining affiliation of software to software families
CN111813960B (zh) 基于知识图谱的数据安全审计模型装置、方法及终端设备
NL2026909B1 (en) Method and system for determining affiliation of software to software families
Ekelhart et al. The SLOGERT framework for automated log knowledge graph construction
TW201310954A (zh) 跨站腳本攻擊產生方法
Makanju et al. Investigating event log analysis with minimum apriori information
CN117235745B (zh) 基于深度学习工控漏洞挖掘方法、系统、设备和存储介质
JP6984761B2 (ja) 情報処理装置及び情報処理プログラム
WO2023162047A1 (ja) 生成装置、生成方法および生成プログラム
AfzaliSeresht et al. An explainable intelligence model for security event analysis
Xu et al. Mining executable specifications of web applications from selenium ide tests
CN115587007A (zh) 基于RoBERTa的网络日志安全检测方法及系统
CN114969761A (zh) 一种基于lda主题特征的日志异常检测方法
JP7251649B2 (ja) グラフ関連付けシステムおよびグラフ関連付け方法
JP2018132787A (ja) ログ分析支援装置およびログ分析支援方法
Wrench et al. Detecting derivative malware samples using deobfuscation-assisted similarity analysis
Naukudkar et al. Enhancing performance of security log analysis using correlation-prediction technique
Ding et al. A Cyber-Attack Behavior Detection Model Based on Log Activity Graph
JP7421196B2 (ja) ログ生成システム、ログ生成方法およびログ生成プログラム
Adegbehingbe et al. Improved Decay Tolerant Inference of Previously Uninstalled Computer Applications
Boros et al. A Principled Approach to Enriching Security-related Data for Running Processes through Statistics and Natural Language Processing.

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: 22928578

Country of ref document: EP

Kind code of ref document: A1