告警日志关联方法及装置与流程

1.本发明涉及通信技术领域，尤其是涉及一种告警日志关联方法及装置。


背景技术：

2.入侵攻击过程由多个阶段/多个攻击点构成，往往包含多个告警数据，但是当前各种入侵告警系统通常是基于规则判断单次行为是否触发告警，生成的告警上报数据都是独立的，由于单个告警无法刻画完整入侵攻击过程，用户需要手动反复对比才能将相关联的告警放在一起，排查和回溯成本极高。攻击告警检测过程中，同一告警可能命中多个检测策略，不合理的规则会触发大量告警误报，依次排查告警费时费力，还可能错过真正的攻击告警。
3.传统的告警日志关联方式主要包括：通过时间段切片关联减少告警数量，该方式可能导致大量误关联。通过向量相似计算关联，该方式计算量较大关联可解释性差。通过逐级匹配 知识库的方式比较关联，该方式计算量较大。通过规则比对方式匹配关联，该方式可扩展性和计算量较大。通过先构建网络安全事件图，再将网络安全事件图划分为多个告警簇，之后提取每个告警簇对应的统计特征和拓扑结构特征来关联不同告警，该方式计算量较大且难以做到实时关联。基于自建的图数据库生成对应的关联事件，包括进程维度和时间维度的关联逻辑，但所需存储成本较高。
4.因此，传统的告警日志关联方式存在以下问题：（1）计算量大、实时性不够：涉及逐级匹配或者向量相似度计算，计算量和存储资源占用较大；计算量大决定了关联很难做到实时关联，多数是批处理任务计算，单纯的时间段划分（比如按小时切分）后计算关联容易把真实关联的攻击划分在不同的攻击事件中，关联实时性也不够。
5.（2）关联维度单一：涉及按照时间切片、比对近似度或者按照规则逐级匹配，与真实关联需要考虑时间范围和（进程）访问关系的情形不符。
6.（3）关联不够准确：仅考虑了关联的概率，容易出现误关联。
7.（4）可扩展性差：对于新增告警类型，需要对应新增规则或者向量计算方式，无法建立统一通用的关联算法。


技术实现要素：

8.有鉴于此，本发明的目的在于提供一种告警日志关联方法及装置，以高效完成多种告警日志的实时关联，准确灵活且可拓展性好。
9.第一方面，本发明实施例提供了一种告警日志关联方法，所述方法包括：获取每个攻击告警日志对应的实体元素；基于实体元素间的访问关系，将每个所述攻击告警日志对应的实体元素组成相应的第一进程树；其中，所述第一进程树中的节点表征实体元素，所述第一进程树中节点间的连线表征实体元素间的访问关系；按照预设关联规则，将获取到的全部第一进程树关联成一个或多个攻击事件；其中，所述预设关联规则包括进程维度规则
和时间维度规则。
10.第二方面，本发明实施例还提供一种告警日志关联装置，所述装置包括：实体元素获取模块，用于获取每个攻击告警日志对应的实体元素；攻击图生成模块，用于基于实体元素间的访问关系，将每个所述攻击告警日志对应的实体元素组成相应的第一进程树；其中，所述第一进程树中的节点表征实体元素，所述第一进程树中节点间的连线表征实体元素间的访问关系；关联模块，用于按照预设关联规则，将获取到的全部第一进程树关联成一个或多个攻击事件；其中，所述预设关联规则包括进程维度规则和时间维度规则。
11.本发明实施例提供的一种告警日志关联方法及装置，先获取每个攻击告警日志对应的实体元素；再基于实体元素间的访问关系，将每个攻击告警日志对应的实体元素组成相应的第一进程树；之后按照预设关联规则（包括进程维度规则和时间维度规则），将获取到的全部第一进程树关联成一个或多个攻击事件。采用上述技术，可以高效完成多种告警日志的实时关联，准确灵活且可拓展性好。
12.本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
13.为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
14.为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
15.图1为本发明实施例中一种告警日志关联方法的流程示意图；图2为本发明实施例中系统整体工作流程示例图；图3为本发明实施例中一种detect树的示例图；图4为本发明实施例中补全不完整detect树的示例图；图5为本发明实施例中用四元组标记网络访问关系的示例图；图6为本发明实施例中标记ip地址访问关系、网址访问关系、文件访问关系的示例图；图7为本发明实施例中本发明实施例中标记文件扫描关系的示例图；图8为本发明实施例中按照进程维度规则进行关联的示例图；图9为本发明实施例中一种虚表结构的示例图；图10为本发明实施例中入图流程示例图；图11为本发明实施例中进程维度关联流程示例图；图12为本发明实施例中一个预设白名单的代码实现示例图；图13为本发明实施例中进程维度关联的示例图；图14为本发明实施例中时间维度关联的示例图；图15为本发明实施例中一种告警日志关联装置的结构示意图。
具体实施方式
16.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合实施例对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
17.目前，传统的告警日志关联方式存在以下问题：（1）计算量大、实时性不够：涉及逐级匹配或者向量相似度计算，计算量和存储资源占用较大；计算量大决定了关联很难做到实时关联，多数是批处理任务计算，单纯的时间段划分（比如按小时切分）后计算关联容易把真实关联的攻击划分在不同的攻击事件中，关联实时性也不够。
18.（2）关联维度单一：涉及按照时间切片、比对近似度或者按照规则逐级匹配，与真实关联需要考虑时间范围和（进程）访问关系的情形不符。
19.（3）关联不够准确：仅考虑了关联的概率，容易出现误关联。
20.（4）可扩展性差：对于新增告警类型，需要对应新增规则或者向量计算方式，无法建立统一通用的关联算法。
21.基于此，本发明实施提供的一种告警日志关联方法及装置，可以高效完成多种告警日志的实时关联，准确灵活且可拓展性好。
22.为便于对本实施例进行理解，首先对本发明实施例所公开的一种告警日志关联方法进行详细介绍，参见图1所示的一种告警日志关联方法的流程示意图，该方法可以包括以下步骤：步骤s102，获取每个攻击告警日志对应的实体元素。
23.其中，上述实体元素可以包括：主机、ip地址、进程、文件、网址、容器等。
24.步骤s104，基于实体元素间的访问关系，将每个攻击告警日志对应的实体元素组成相应的第一进程树；其中，第一进程树中的节点表征实体元素，第一进程树中节点间的连线表征实体元素间的访问关系。
25.上述访问关系可以为进程访问关系、网络访问关系、ip地址访问关系、网址访问关系、文件访问关系等，具体可根据实际情况自定义，对此不进行限定。
26.步骤s106，按照预设关联规则，将获取到的全部第一进程树关联成一个或多个攻击事件；其中，预设关联规则包括进程维度规则和时间维度规则。
27.在将每个攻击告警日志对应的实体元素（如ip地址、进程、文件、网址等）组成相应的第一进程树后，可按照预设关联规则，从进程维度和时间维度将具有关联关系的第一进程树关联成同一个攻击事件。
28.本发明实施例提供的一种告警日志关联方法，先获取每个攻击告警日志对应的实体元素；再基于实体元素间的访问关系，将每个攻击告警日志对应的实体元素组成相应的第一进程树；之后按照预设关联规则（包括进程维度规则和时间维度规则），将获取到的全部第一进程树关联成一个或多个攻击事件。采用上述技术，可以高效完成多种告警日志的实时关联，准确灵活且可拓展性好。
29.作为一种可能的实施方式，上述步骤s102（即获取每个攻击告警日志对应的实体元素）之后，上述告警日志关联方法还可以包括以下操作方式：基于预设的攻击图存储模
型，将获取到的每个攻击告警日志对应的实体元素和实体元素间的关系存储为攻击图。基于此，上述步骤s106（即按照预设关联规则，将获取到的全部第一进程树关联成一个或多个攻击事件）可以包括以下操作方式：对于新得到的每个第一进程树，均按照预设关联规则，将该第一进程树与攻击图中已有的第一进程树关联，并用该第一进程树的关联结果更新攻击图。
30.为了便于操作，在实时获取攻击告警日志的过程中，每新获取到一个攻击告警日志，便将新获取到的该攻击告警日志作为当前攻击告警日志，并通过预先构建的攻击图存储模型将当前攻击告警日志对应的实体元素和实体元素间的关系以攻击图的形式呈现出来并进行存储。在攻击图存储模型中，攻击图包括点和边，每个点可唯一表征一个实体元素（也即第一进程树中的一个节点），每条边（即两点间的连线）可表征一个实体元素间的关系（如访问关系、父子关系等）。在得到当前攻击告警日志对应的当前第一进程树后，按照预设关联规则，将当前第一进程树与历史攻击告警日志对应的历史第一进程树（即攻击图中已有的第一进程树）关联，从而通过预先构建的攻击图存储模型将关联结果写入到攻击图中以实现攻击图的更新，更新后的攻击图包含了当前第一进程树以及当前第一进程树与历史第一进程树之间的关联关系。
31.作为一种可能的实施方式，上述步骤s106（即按照预设关联规则，将获取到的全部第一进程树关联成一个或多个攻击事件）可以包括以下操作方式：按照进程维度规则确定每个第一进程树中的关联点，并将关联点相同的第一进程树关联成同一个子事件，得到一个或多个子事件；其中，关联点为第一进程树中表征攻击开始的节点；按照时间维度规则，将一个或多个子事件聚合成一个或多个攻击事件。
32.作为一种可能的实施方式，上述按照进程维度规则确定每个第一进程树中的关联点的步骤，可以包括以下操作方式：对于每个第一进程树，将该第一进程树与一个或多个预设攻击路径进行匹配；如果匹配成功，则将匹配最长的预设攻击路径的最末端节点作为该第一进程树中的关联点；如果匹配失败，则基于预设节点白名单，沿从根节点到子节点的顺序遍历该第一进程树，并将该第一进程树中首次遍历到的不在预设节点白名单中的节点作为该第一进程树中的关联点。
33.预设攻击路径通常为由多个节点连接而成的树形结构（与第一进程树的结构类似），可先预先定义一个黑名单并将一个或多个预设攻击路径保存在该黑名单中；对于某个第一进程树，可将该第一进程树分别与该黑名单中的每个预设攻击路径进行匹配；如果该第一进程树与一个或多个预设攻击路径匹配，则判定匹配成功；如果匹配多个预设路径，则将匹配最长的预设路径的末端节点确定为关联点；如果该黑名单中没有与该第一进程树匹配的预设攻击路径，则判定匹配失败，可沿从根节点到子节点的顺序遍历该第一进程树，并按照遍历顺序依次判断该第一进程树中的节点是否在预设节点白名单中，直至从该第一进程树中首次遍历到不在预设节点白名单中的节点时停止遍历，并将此时该第一进程树中不在预设节点白名单中的节点确定为关联点。
34.采用上述操作方式，能够进一步提高关联点确定的准确性和效率。
35.作为一种可能的实施方式，上述告警日志关联方法可以包括以下操作方式：（11）如果该第一进程树中的关联点不在攻击图中，将该关联点作为一个新的关联点，在攻击图中将该第一进程树关联在一个新的子事件中。
36.对于得到的当前第一进程树来说，在得到该第一进程树中遍历到的不在预设节点白名单中的节点后，如果攻击图中不存在该节点，则可将该节点视为一个新的关联点，并建立一个新的子事件，之后在攻击图中将该第一进程树关联在建立的新的子事件中。
37.（12）如果该第一进程树满足预设条件，在攻击图中将该第一进程树关联在一个新的子事件中；其中，预设条件包括子事件中节点的数量和子事件的时间信息。
38.子事件的时间信息可以包括子事件中每个第一进程树的保存时刻。例如，预先设置节点数量阈值（如100个节点、200个节点等）和多个不同的时间范围（如24个小时、48个小时等）；对于当前第一进程树来说，在需要将当前第一进程树关联在攻击图中已有的一个子事件中时，如果关联后该子事件的时间信息在该时间范围内且关联后该子事件中节点的数量不超过该节点数量阈值，则可在攻击图中将当前第一进程树关联在该子事件中；如果关联后该第一进程树所在的子事件的时间信息已经在该时间范围外和/或关联后该子事件中节点的数量已经超过该节点数量阈值，则可建立一个新的子事件，并在攻击图中将当前第一进程树关联在建立的新的子事件中。该操作方式可以避免出现过长时间的关联和过多节点的关联，从而提高了关联结果的呈现效果。
39.作为一种可能的实施方式，上述按照时间维度规则，将一个或多个子事件聚合成一个或多个攻击事件的步骤，可以包括以下操作方式：基于预设的多个不同时间范围和每个子事件的时间信息，将时间信息与同一时间范围对应的子事件聚合成同一个攻击事件，得到一个或多个攻击事件。
40.例如，预先设置多个不同的时间范围（如1天、2天等），可将时间信息在同一时间范围内的子事件聚合成一个攻击事件，这样便得到了一个或多个攻击事件。
41.由于在真实攻击过程中，短时间内的告警大概率是同一次攻击触发的，因而上述聚合子事件的方式可以体现真实攻击过程的时间关联，避免出现过长时间的关联和过多节点的关联，从而提高了关联结果的呈现效果。
42.作为一种可能的实施方式，上述步骤s102（即获取每个攻击告警日志对应的实体元素获取每个攻击告警日志对应的实体元素）之后，上述告警日志关联方法还可以包括以下操作方式：（21）基于预设的多个不同虚表结构，分别确定每个访问关系的类型。
43.攻击告警日志通常包含一种或多种虚表，由于不同访问关系类型会使虚表的组合方式不同，而虚表的不同组合方式会形成不同的虚表结构，因而可根据虚表结构判断攻击告警日志的访问关系类型。
44.（22）基于确定的每个访问关系的类型，分别为每个访问关系对应分配相应的类型标识。
45.上述类型标识用于表征访问关系的类型，对于某个访问关系，可根据该类型标识唯一确定该访问关系的类型。例如，对于每个网络访问关系，均为该网络访问关系分配相应的四元组作为该网络访问关系的类型标识；其中，四元组包括源ip地址、源端口、目标端口和目标ip地址，源端口通常是与源进程对应的，目标端口通常是与目标进程对应的。上述为访问关系分配类型标识的方式可以提高不同类型访问关系在攻击图中的辨识度，以便攻击图的查询。
46.采用上述（21）和（22）的操作方式，可以提高攻击图查询的效率。
47.作为一种可能的实施方式，上述按照进程维度规则确定每个第一进程树中的关联点，并将关联点相同的第一进程树关联成同一个子事件，得到一个或多个子事件的步骤之后，上述告警日志关联方法还可以包括以下操作方式：对于关联成同一子事件的每个第一进程树，均用该子事件的子事件标识表征该第一进程树与该子事件间的关联关系。采用该操作方式，可以存储历史进程树已有的关联关系和标记不同子事件的关联点，从而提高攻击图查询的效率。
48.作为一种可能的实施方式，上述按照时间维度规则，将一个或多个子事件聚合成一个多个攻击事件的步骤之后，上述告警日志关联方法还可以包括以下操作方式：对于聚合成同一个攻击事件的每个子事件，均用该事件的事件标识表征该子事件与该事件间的聚合关系。采用该操作方式，可以存储历史进程树已有的关联关系和标记不同事件对应包含的子事件，从而提高攻击图查询的效率。
49.针对攻击告警日志为文件扫描告警日志的情形，无法获取到攻击告警日志对应的进程，即攻击告警日志对应的实体元素不包括进程；基于此，上述告警日志关联方法还可以包括以下操作方式：基于目标实体元素间的扫描关系，将具有相同目标实体元素的攻击告警日志关联成同一个攻击事件。
50.上述目标实体元素可以为主机、ip地址、文件、容器等，具体可根据实际情况自定义，对此不进行限定。
51.由于文件扫描告警并无法找到相应的进程，因而可将具有相同目标实体元素的文件扫描告警日志视为具有关联关系的文件扫描告警日志，并将具有关联关系的文件扫描告警日志关联成同一个攻击事件，从而实现文件扫描告警日志的关联。例如，攻击告警日志对应的实体元素包括主机、ip地址和文件，可基于文件间的扫描关系，将具有相同文件的攻击告警日志关联成同一个攻击事件。采用该操作方式可以为文件扫描告警日志的关联提供切实可行的操作方式，从而高效完成文件扫描告警日志的实时关联，准确灵活且可拓展性好，进一步提高了上述告警日志关联方法对不同应用场景的普适性。
52.为了便于理解，以某一具体应用实例为例对上述告警日志关联方法进行示例性描述如下：为了便于上述告警日志关联方法的实施，可预先搭建一个系统，参见图2所示，系统架构主要包括依次连接的主机、服务端和关联引擎（图2中虚线框内部分）；其中，主机部署在客户端上，主机所采用的操作系统可采用linux、windows等，具体可根据需求自行选择，对此不进行限定。系统整体工作流程主要包括以下步骤：步骤1，通过主机的agent采集器负责采集告警消息（图2中为detect消息），并按照约定格式将采集到的detect消息上传至服务端。
53.步骤2，通过服务端对detect消息进行中间处理（包括判断和转换的处理过程），并将中间处理后的detect消息转发至关联引擎。
54.步骤3，通过关联引擎将服务端转发的detect消息转换成相应的detect树（如上述第一进程树），并进行detect树的入图和关联。
55.其中，关联引擎整体由入图部分和关联部分组成。通过关联引擎的入图部分基于输入的detect树构建攻击图和将输入的detect树发送给关联引擎的关联部分，同时将每个detect树对应在攻击图中的构图信息（如树结构、图结构分类等）同步给关联部分当前处理
后的detect树；在此基础上，通过关联引擎的关联部分对输入的detect树进行进程维度关联，即将相应的detect进程树归并成子事件（subincident）；通过关联引擎的关联部分对子事件进行时间维度关联，即将子事件聚合成事件（incident）；此外，关联引擎还可将进程维度关联过程中产生的incident关系写入到攻击图中以实现攻击图的实时更新，以及在进程维度关联过程中查询攻击图以确定相应的incident关联信息。
56.步骤4，通过关联引擎采用分段传输的方式将每个事件对应的incident消息输出至服务器；其中，每个incident消息包含所对应事件的全部相关信息（如树结构、图结构分类、上述事件标识、上述子事件标识等）。
57.由于上述时间维度关联可能会产生较大的树结构，对kakfa等分布式消息系统的消息传输限制和前端的渲染展示都有影响。因此输出时每次输出的是更新或新建的subincident，每个subincident标记对应的incident。
58.步骤5，通过服务端接收关联引擎输出的incident消息，并对incident消息进行归并和通过前端进行事件的渲染展示。
59.为了便于上述步骤1至步骤5的实施，可预先构建上述攻击图存储模型，表1示出了攻击图中点的含义，表2示出了攻击图中边（即两点间的关系）的含义。
60.表1 攻击图中点的含义列表
名称说明ipip地址agent主机process进程dns网址connect四元组（源ip-源端口-目标端口-目标ip）来唯一标记一次网络访问关系file文件路径detect上报的原始告警每个原始告警入图后表示为一颗detect进程树subincident关联后的子事件树每个subincident按照进程维度聚合多个detect进程树incident关联产生的事件每个incident按照时间维度聚合多个subincident树
表2 攻击图中边的含义列表
每个原始告警日志在攻击图中会被表示为一个detect树（如上述第一进程树），根据不同实体元素和不同告警类型，可将点间的关系划分为多种类型的图关系。通过detect_point和detect_endpoint分别标记当前告警（detect）的作用源（一般是进程、文件等）和作用对象（一般是进程、网址、ip地址、文件等）。
61.示例性地，例如图3，当前告警为包含进程动作的告警（比如恶意命令执行），该告
警携带完整的进程树信息，图3中表现为一个多级的detect树，该告警所涉及的实体元素包括主机、该主机对应的ip地址、作为该进程树根节点的父进程（即进程1）和该父进程的子进程（即进程2），当前告警的作用源和作用对象均为进程2。
62.在极少部分场景下，比如无法获取完整进程树的情形，例如图4，现有攻击图中已有一个完整进程树（即告警1），此时新上报一个告警2，但该告警2只能获取到父子两级进程（即进程2和进程4），此时可使用host_process（即主机到进程）标记主机与进程2间的关系，从而得到一个不完整的进程树（即告警2）。针对这种进程动作上报进程树不完整的情况，在将告警日志进行关联前可先查询当前不完整进程树中的节点是否还存在上级节点，之后用现有攻击图中的进程树关系对当前不完整的进程树进行补全，例如图4，可用告警1中进程1与进程2间的父子关系对告警2进行补全，即：使用process_root（即主机到进程树根节点）标记主机与进程1间的关系，使用process_create（即父子进程关系）标记进程1与进程2间的关系，从而实现对告警2的补全。其它带不完整进程树的告警，均可按照类似的补全方式对不完整detect树进行补全。
63.示例性地，例如图5，网络访问关系刻画了两个主机之间的访问关系，此时可引入一个四元组[源ip地址-源端口-目标端口-目标ip地址]作为中间元素来唯一标记一次网络访问关系，源端口与源进程对应，目标端口与目标进程对应。每个主机的端口对应一个进程，图5中可用一个四元组[ip地址1-端口2-端口4-ip地址2] 作为中间元素来唯一标记一次网络连接，端口2与进程2对应，端口4与进程4对应，分别在每个实体元素与四元组间建立相应的边，图5中的虚线部分为另一个主机上的detect树。通过构建四元组并建立实体元素与四元组间相应边的操作方式，可以完成多主机间访问关系的自动关联。此外，容器之间的网络访问关系也可采用类似的操作方式，对此不再赘述。
[0064]
示例性地，可将ip地址访问关系、网址访问关系和文件访问关系均挂在进程树的末端。例如图6，可用ip_access（即进程到ip访问）标记一次ip地址访问关系，可用dns_access （即进程到外网url）标记一次网址访问关系（也即dns访问关系），可用file_access（即进程到文件访问/执行）标记一次文件访问关系。
[0065]
示例性地，对于部分场景，比如文件扫描告警的情形，上报告警不带进程树，因而无法获取到相应的进程，此时可直接获取相应的文件，并对相应的告警（即detect树）进行退化处理，即将具有相同文件的主机（或容器）关联成detect树。例如图7，可用has_file（即主机到文件）标记一次文件扫描关系，从而将主机、该主机对应的ip（即ip地址）和该主机所具有的文件（即文件路径）组成一个detect树。
[0066]
示例性地，为了记录不同告警间的关联关系，在采用上述detect树表征每个告警（即detect）对应实体元素间关系的基础上，还可引入辅助实体来表征告警间的关联关系。例如，可按照上述进程维度规则将一个或多个detect树关联成一个子事件（subincident），并分别在每个detect树与subincident间建立相应的边；按照上述时间维度规则将一个或多个subincident聚合成一个攻击事件（incident），并分别在每个subincident与incident间建立相应的边。例如图8，按照上述进程维度规则将告警1关联成一个子事件（即子事件1），并用subincident_detect（即子事件指向告警）标记告警1与子事件1间的关联关系，以及用subincident_root（即关联点关系）标记告警1的关联点进程2与子事件1间的关联关系；之后按照上述时间维度规则将子事件1聚合成一个攻击事件（即事件），并用
subincident_incident（即子事件指向事件）标记子事件1与该事件间的关联关系。
[0067]
示例性地，如图9所示，detect中details包含多种虚表（进程树(process_tree)/网络访问(process_open_sockets)/文件扫描(file)/脚本执行(script )等），可根据实际上报的不同虚表组合判断对应的图结构分类。比如，只包含虚表进程树(process_tree)则判定为进程进程访问关系；同时包含虚表进程树(process_tree)/网络访问(process_open_sockets)则判定为网络访问关系；只包含虚表文件扫描(file)则判定为文件扫描关系等等。
[0068]
示例性地，由于上报的告警(detect)记录主机（或容器）的各种行为逻辑依赖关系，不同detect最终对应在攻击图中的点和边各不相同，因此，为了避免每新来一个detect便需要定义该detect的入图流程（即生成攻击图的流程）及点边构成，可参考上述攻击图存储模型预先将detect按照不同的结构分为不同的图结构分类，每个图结构分类与一种关系类型（如进程访问关系、网络访问关系、ip地址访问关系、网址地址访问关系、文件访问关系、文件扫描关系等）对应，相同图结构分类的入图流程及点边构成相同；之后将每个图结构分类的标签（即类型标识）与边之间的映射关系写入到相应的配置文件中。基于此，例如图10，上述关联引擎的入图部分可按照以下操作方式执行入图流程：接收服务器以json格式（或者其他格式）发送的每个detect（即detect树）；基于预设的多个不同虚表结构，分别判断每个detect的图结构分类；分别解析每个detect的图结构分类各自所对应的配置文件，以获取相应图结构分类的标签与边之间的映射关系；按照配置构建相应的图结构分类；将接收到的detect树处理成攻击图并写入图数据库，同时将关联过程中产生的incident消息同步至kafka。
[0069]
示例性地，上述虚表结构实际上可以为一种虚表或者为多种虚表的组合，每种虚表对应具有相应的配置参数。例如图10，detect的details中包含多种虚表，如进程树(process_tree)、网络访问(process_open_sockets)、文件扫描(files)等，可根据实际上报的detect中不同虚表的组合判断对应的图结构分类。比如，如果detect的details中只包含进程树(process_tree)这一个虚表，则判定detect的图结构分类与进程访问关系对应；如果detect的details中包含进程树(process_tree)和网络访问(process_open_sockets)这两个虚表，则判定detect的图结构分类与网络访问关系对应；如果detect的details中只包含文件扫描(files)这一个虚表，则判定detect的图结构分类与文件扫描关系对应；如果detect的details中只包含进程树(process_tree)和ip访问(ip_access)这两个虚表，则判定detect的图结构分类与ip访问关系对应；如果detect的details中只包含进程树(process_tree)和dns访问(dns_events)这两个虚表，则判定detect的图结构分类与dns访问关系对应；如果detect的details中只包含进程树(process_tree)和文件访问(process_open_files)这两个虚表，则判定detect的图结构分类与文件访问关系对应。
[0070]
上述入图流程主要是为了把上报的告警转换成对应的图结构分类加入到攻击图中，后续告警只要满足约定的虚表格式和组合，即可自动被转换成对应图结构分类加入到攻击图中，因而上述入图流程的可扩展性较强。
[0071]
为了便于上述关联引擎的关联部分对detect树依次进行进程维度关联和时间维度关联，可预先定义一种图关联算法，从而通过该图关联算法先将detect树归并成subincident再将subincident归并成incident。
[0072]
告警的关联需要精准控制关联过程，从而能够真正体现一次攻击过程。比如linux主机上的进程树都是从根进程出发的，不能将全部进程归并到一个进程树上，可将不同的bash入口或ssh登录入口划分在不同的关联事件中；另外不同的攻击过程和攻击用户产生的进程树需要尽量归并到不同的subincident中。
[0073]
示例性地，可预先定义detect的关联点确定规则，之后将关联点确定规则写入到相应的配置文件中。例如图11，对于需要进行入图流程的detect，根据该detect的图结构分类判断如何处理该detect；解析相应的配置文件，以获取关联点确定规则；对于不同的图结构分类，按照关联点确定规则计算detect的关联点；从当前图数据库中查找subincident_root对应的subincident，如果查找成功，将该detect关联到已有subincident（也即用subincident_detect标记该detect对应的detect树与从当前图数据库中查找到的subincident间的关联关系），如果查找失败，新建subincident对应关系，并用subincident_root指向当前关联点（也即用subincident_root标记关联点与subincident间的关联关系）。
[0074]
示例性地，可预先定义detect的关联点确定规则包括依次进行的以下三个规则：（一）兜底规则。例如，预先设置一个节点数量阈值和多个不同的时间区间；对于某个subincident，如果该subincident中每个detect树的保存时刻均在一个时间区间内且该subincident中节点的数量不超过该节点数量阈值，则不切分该subincident；如果该subincident中每个detect树的保存时刻已经在任何一个时间区间外和/或该subincident中节点的数量已经超过该节点数量阈值，则可将该subincident切分成多个新的subincident，即：使该subincident中保存时刻在同一个时间区间内的detect树关联成一个新的subincident，和/或使该subincident中节点数量之和不超过该节点数量阈值的detect树关联成一个新的subincident。上述兜底规则可以避免单个subincident中节点数量过大，避免出现过长时间的关联和过多节点的关联，从而提高了关联结果的呈现效果。
[0075]
（二）黑名单规则。预置常见的攻击路径；将当前detect树中的每个节点依次与预置的攻击路径匹配，如果匹配成功，则将当前detect树中能够匹配的最后一个节点（即最末端节点）作为关联点。例如，黑名单规则包括规则1（即完全匹配规则）和规则2（即正则匹配规则），detect树为进程链"systemd"-》"sshd"-》"sshd"-》"bash"-》"my-service"-》"nginx"-》"php-fpm"，同时使用规则1和规则2将该进程链与预置的攻击路径进行匹配；规则1的操作方式为：遍历该进程链，比对完整的进程名，匹配的进程为"systemd"、"sshd"、"sshd"、"bash"和"my-service"，由于最后一个匹配进程为my-service，因此规则1计算出来的关联点是my-service；规则2的操作方式为：遍历该进程链，按照正常规则顺序比对进程名，进程名的正则表达式分别为"systemd"、"(sshd):2"、"(bash):n"、"/.*service.*/"和"*"，其中，"(sshd):2"表示匹配一条路径上连续的2个名为sshd的进程，“/正则表达式/”表示匹配任意满足正则表达式的进程，“*”表示匹配任意进程，最后一个匹配进程为nginx，因此规则2计算出来的关联点是nginx；对比规则1的匹配结果和规则2的匹配结果，由于规则2对应的匹配路径更长，因此最终计算出的关联点是nginx。
[0076]
（三）白名单规则。在上述黑名单规则计算不出关联点，即当前detect树中没有节点与预置的攻击路径匹配时，则沿从根节点到子节点的顺序遍历该detect树，并按照遍历顺序依次判断该detect树中的节点是否在预设的白名单中，之后将从该detect树中首次遍
历到的不在该白名单中的节点作为该的关联点。例如图12，图12示出了一个预设白名单的代码实现，即白名单进程的代码实现为构造hashmap；对于一个进程链（此时的detect树），按照白名单规则从父进程到子进程遍历该进程链，将遍历到的第一个非白名单进程设为关联点。白名单规则通常可以用于过滤常见的系统进程（根进程），从而提高了关联点的确定效率高。
[0077]
现有detect关联方案通常是直接按照进程树进行归并，但这样的复杂度较高，对于n个节点个数为m的detect树的关联，每次新进入的detect树都需要和之前已有的detect树全部比对，关联的复杂度为o(m^n)，关联效率较低。
[0078]
本文引入关联点作为detect树上代表攻击开始的节点。借助图数据库，本发明实施例中进程维度关联的关联算法如下：每个detect树入图（即加入到攻击图中）时，按照关联点确定规则计算对应的关联点（比如图13中空心短箭头标记的bash进程节点）；每个子事件只有唯一关联点，在攻击图中使用subincident_root（即关联点关系）标记关联点；对于计算出的关联点，在攻击图中按照关联点关系查找对应标记的子事件；查找成功则自动和之前的子事件关联，即创建subincident_detect关系（也即创建子事件指向告警的关系），查找失败则新建子事件并使用subincident_root（即关联点关系）标记当前子事件的关联点，便于后续detect树入图的查找关联。该算法的核心在于：关联点相同的不同detect树在图数据库里表现为同一个图节点，将告警关联的过程转换为遍历detect树以按照关联点确定规则计算对应关联点的过程，告警关联的开销即为关联点计算的开销。
[0079]
参见图13所示，攻击图中已有子事件，用subincident_detect（即子事件指向告警）标记告警1和告警2这两个告警，使用subincident_root（即关联点关系）标记当前关联点（即bash进程）；此时对于新上报的告警4，先遍历进程链计算对应的关联点，计算出关联点也是bash进程，再用bash进程查询攻击图，发现攻击图中子事件已经通过subincident_root关系（即关联点关系）指向了bash进程，可用subincident_detect（即子事件指向告警）标记子事件和告警4的关系，即建立子事件与告警4之间的关联。对于n个节点个数为m的detect树的关联，每次新进入的detect树只需要计算自己的关联点并将计算出的关联点和攻击图中已有的关联点进行对比即可，关联成本仅为按照关联点确定规则计算关联点，每次关联的复杂度为o(m)，计算量大大降低。相比于现有detect关联方案中每次新进入的detect树均需要和之前的n-1个detect树一一比对的方式，当前关联方案中每次新进入的detect树只需要计算出对应的关联点并在攻击图中查找关联点即可，不再需要遍历比对之前的全部detect树。
[0080]
示例性地，在对告警进行进程维度关联后，还需要进行时间维度关联。通过时间维度关联在进程维度关联的基础上把一定时间范围的上报detect聚合起来，为了确保关联准确性，优先按照detect树的逻辑关联。
[0081]
参见图14所示，先按照进程维度规则将告警1聚合（即关联）成子事件1，将告警2聚合（即关联）成子事件2，将告警3聚合（即关联）成子事件3；然后根据每个子事件的保存起始时间(即第一个进入的detect树的保存时间)，按照时间维度规则将子事件1、子事件2和子事件3聚合成同一个事件。
[0082]
采用时间维度关联的方式，可以保证已经归并到之前子事件中的告警不会归并到当前时间范围的子事件中。时间维度聚合可使用配置参数控制时间跨度大小（也即时间范
围大小，支持精确到毫秒，如2天），防止时间跨度过大可能产生过大的子事件，从而降低数据传输成本和提高前端展示效率。
[0083]
基于上述告警日志关联方法，本发明实施例还提供一种告警日志关联装置，参见图15所示，该装置可以包括以下模块：实体元素获取模块1502，用于获取每个攻击告警日志对应的实体元素。
[0084]
攻击图生成模块1504，用于基于实体元素间的访问关系，将每个所述攻击告警日志对应的实体元素组成相应的第一进程树；其中，所述第一进程树中的节点表征实体元素，所述第一进程树中节点间的连线表征实体元素间的访问关系。
[0085]
关联模块1506，用于按照预设关联规则，将获取到的全部第一进程树关联成一个或多个攻击事件；其中，所述预设关联规则包括进程维度规则和时间维度规则。
[0086]
本发明实施例提供的一种告警日志关联装置，先获取每个攻击告警日志对应的实体元素；再基于实体元素间的访问关系，将每个攻击告警日志对应的实体元素组成相应的第一进程树；之后按照预设关联规则（包括进程维度规则和时间维度规则），将获取到的全部第一进程树关联成一个或多个攻击事件。采用上述技术，可以高效完成多种告警日志的实时关联，准确灵活且可拓展性好。
[0087]
参见图15所示，该装置还可以包括：入图模块1508，用于基于预设的攻击图存储模型，将获取到的每个攻击告警日志对应的实体元素和实体元素间的关系存储为攻击图。
[0088]
基于此，上述关联模块1506还可以用于：对于新得到的每个第一进程树，均按照预设关联规则，将该第一进程树与所述攻击图中已有的第一进程树关联，并用该第一进程树的关联结果更新所述攻击图。
[0089]
上述关联模块1506还可以用于：按照进程维度规则确定每个第一进程树中的关联点，并将关联点相同的第一进程树关联成同一个子事件，得到一个或多个子事件；其中，关联点为第一进程树中表征攻击开始的节点；按照时间维度规则，将所述一个或多个子事件聚合成一个或多个攻击事件。
[0090]
上述关联模块1506还可以用于：对于每个第一进程树，将该第一进程树与一个或多个预设攻击路径进行匹配；如果匹配成功，则将匹配最长的预设攻击路径的末端节点作为该第一进程树中的关联点；如果匹配失败，则基于预设节点白名单，沿从根节点到子节点的顺序遍历该第一进程树，并将该第一进程树中首次遍历到的不在预设节点白名单中的节点作为该第一进程树中的关联点。
[0091]
上述关联模块1506还可以用于：如果该第一进程树中的关联点不在所述攻击图中，将该关联点作为一个新的关联点，在所述攻击图中将该第一进程树关联在一个新的子事件中；如果该第一进程树满足预设条件，在所述攻击图中将该第一进程树关联在一个新的子事件中；其中，所述预设条件包括子事件中节点的数量和子事件的时间信息。
[0092]
上述关联模块1506还可以用于：基于预设的多个不同时间范围和每个子事件的时间信息，将时间信息与同一时间范围对应的子事件聚合成同一个攻击事件，得到一个或多个攻击事件。
[0093]
参见图15所示，该装置还可以包括：确定模块1510，用于基于预设的多个不同虚表结构，分别确定每个访问关系的类
型。
[0094]
第一标识模块1512，用于基于确定的每个访问关系的类型，分别为每个访问关系对应分配相应的类型标识。
[0095]
上述第一标识模块1512还可以用于：对于每个网络访问关系，均为该网络访问关系分配相应的四元组作为该网络访问关系的类型标识；其中，所述四元组包括源ip地址、源端口、目标端口和目标ip地址。
[0096]
参见图15所示，该装置还可以包括：第二标识模块1514，用于对于关联成同一子事件的每个第一进程树，均用该子事件的子事件标识表征该第一进程树与该子事件间的关联关系。
[0097]
第三标识模块1516，用于对于聚合成同一个攻击事件的每个子事件，均用该事件的事件标识表征该子事件与该事件间的聚合关系。
[0098]
上述攻击告警日志可以为文件扫描告警日志，此时攻击告警日志对应的实体元素不包括进程；基于此，上述关联模块1506还可以用于：基于目标实体元素间的扫描关系，将具有相同目标实体元素的攻击告警日志关联成同一个攻击事件。
[0099]
本发明实施例所提供的告警日志关联装置，其实现原理及产生的技术效果和前述告警日志关联方法实施例相同，为简要描述，告警日志关联装置实施例部分未提及之处，可参考前述告警日志关联方法实施例中相应内容。
[0100]
除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对步骤、数字表达式和数值并不限制本发明的范围。
[0101]
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器（rom，read-only memory）、随机存取存储器（ram，random access memory）、磁碟或者光盘等各种可以存储程序代码的介质。
[0102]
最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。