简介这份PDF文献面向网络安全从业者、安全态势感知研究人员及高校网络空间安全专业师生系统梳理攻击者画像在攻击检测与防御中的定位与实现路径帮助读者理解如何从攻击行为中识别意图、预测威胁并辅助溯源决策。资源为单份PDF文档压缩包约1008KB内容完整收录论文正文、摘要、关键词及参考文献便于直接阅读与引用。文中围绕攻击者画像的作用、研究现状与关键技术展开重点阐述威胁情报、机器学习与网络行为画像三大方向并延伸至数据来源分类、情报共享模式、聚类与深度学习在行为关联中的应用以及多源信息融合、动态画像更新等未来趋势。目前已有290人学习适合需要撰写相关论文、搭建安全分析框架或补充理论依据的读者参考。1. 攻击者画像落地前先把这份 2018 年的技术底稿读薄很多人第一次接触攻击者画像是从 SIEM 告警里一条“同一源 IP 在 10 分钟内换了 7 个 User-Agent”开始的。你盯着屏幕知道这不对劲但说不清对方是谁、想干什么、下一步会打哪。这份《网络安全中攻击者画像的关键技术研究》就是在这种场景下值得翻出来的一篇底稿——它不教你怎么点按钮而是把画像这件事拆成数据来源、AI 结合、表示方式三条主线告诉你为什么大多数溯源只停在 IP 定位就卡住了。作者王祖俪2018 年发表于《信息技术与信息化》第 8 期全文围绕态势感知中的态势理解模块展开。它适合两类人一是做安全运营、威胁情报、态势感知的工程师想搞清楚画像的技术骨架二是刚转网络安全方向、被“机器学习安全”这个词组绕晕的学习者需要一份不堆公式、能把关键问题讲明白的参考。读完你至少能判断自己手里的日志和情报够不够撑起一个画像缺的是数据、算法还是表示结构。2. 攻击者画像的数据来源三类情报源怎么分、怎么用2.1 为什么只靠内部日志做不出画像原文把画像分成“本地画像”和“网络行为画像”两种。本地画像看的是攻击者所用机器的硬件物理特征网络行为画像看的是攻击手法、偏好、工具、背景和目的。问题在于企业内部能拿到的绝大多数数据就是日志——防火墙日志、WAF 日志、EDR 告警、系统审计记录。这些日志能告诉你“发生了什么”但很难告诉你“谁干的、为什么干”。作者在 3.1 节里点得很直接以往画像困难一个重要原因就是参与分析的数据太少。日志是单维的攻击者换个跳板、改个工具指纹日志之间的关联就断了。所以画像的第一步不是上算法而是把数据来源从“只有日志”扩展到三类情报源。这个判断放到今天依然成立很多团队画像做不起来不是模型不行是输入太薄。2.2 三类情报源的划分与采集边界原文明确给出三类数据来源我按落地时的采集方式整理成下表情报源类型典型内容采集方式更新频率内部情报源资产信息、漏洞扫描结果、安全设备告警、各类安全日志对接 CMDB、漏扫平台、SIEM实时到小时级公开情报源公开社工库、DNS 库、常见僵尸网络 IP 信息订阅公开 feed、定期拉取天级到周级供应商商业源安全组织/厂商的漏洞通告、病毒报警、威胁通知采购情报服务、API 对接小时级到天级这张表的关键不在分类本身而在采集边界。内部情报源是你唯一能拿到全量原始数据的地方但格式最乱公开情报源覆盖广但噪声大、时效参差商业源质量相对高但字段定义各家不同。原文特别提到“各种设备厂商的数据格式不同发布平台不同使得威胁情报目前不能很好地进行共享”这是 2018 年的判断放到现在的多源异构环境里依然是主要摩擦点。2.3 情报共享的三种模式与统一分级平台原文把情报共享分成内部共享、平行共享、国际共享三种模式。内部共享是各部门通过情报流通、发布机制交换平行共享是互联网公司、安全公司、研究机构在互信基础上以产业联盟方式交换国际共享则涉及跨国犯罪等场景的协作。对一线工程师来说前两种是真正能落地的。作者给出的结论是建立统一分级共享的数据分享平台是攻击者画像实现的基础。这句话翻译成工程语言就是——你得先有一个能归一化字段、能打标签分级、能控制访问权限的情报中台否则三类数据源接进来也是一盘散沙。常见做法是先用 STIX/TAXII 这类结构化格式做一层转换把 IP、域名、文件哈希、攻击手法等字段对齐再按敏感级别打标。这一步不做后面的机器学习和表示方式都无从谈起。提示如果团队目前只有 SIEM建议先把内部情报源里的资产和漏洞数据接进来让告警能关联到具体资产和已知漏洞画像的“本地”维度才有基础。3. 机器学习与画像结合聚类、相似性分析和攻击预测怎么落3.1 为什么画像需要无监督学习原文 3.2 节的核心判断是大数据时代靠增加分析人员数量来应对数据量不可行可行的方法是运用人工智能通过智能算法对原始数据做预处理降低分析人员压力辅助判断。在画像场景里机器学习主要干三件事——对用户行为建立关联、对攻击者按偏好做相似性分析、根据数据归纳攻击模式进行监测和预测。这里有个容易被忽略的点攻击者画像的相似性操作原文说“可以从大数据中用户聚类衍生而来”。也就是说你不是先有标签再分类而是先聚类发现群体再给群体打语义标签。这决定了画像在起步阶段更适合用无监督方法而不是一上来就做有监督分类。因为攻击样本标注成本极高且攻击手法变化快昨天标好的正样本今天可能就失效了。3.2 用聚类做攻击群体划分的最小可跑示例下面这段代码演示的是最基础的思路把攻击事件按行为特征向量化用 KMeans 做聚类再输出每个簇的特征均值供人工打标签。特征可以来自日志聚合比如单位时间请求数、独立目标数、UA 更换频率、非工作时段占比等。import numpy as np from sklearn.cluster import KMeans from sklearn.preprocessing import StandardScaler # 假设已从日志聚合出攻击事件特征矩阵 # 每行一个源实体列依次为 # [请求频率, 独立目标数, UA更换次数, 非工作时段占比, 平均请求间隔秒] X np.array([ [120, 45, 8, 0.85, 0.5], [15, 3, 1, 0.10, 12.0], [200, 80, 15, 0.90, 0.3], [10, 2, 0, 0.05, 30.0], [130, 50, 9, 0.80, 0.6], [12, 4, 1, 0.15, 15.0], ]) # 标准化频率和间隔量纲差异大不标准化会让频率主导距离 scaler StandardScaler() X_scaled scaler.fit_transform(X) # 聚成 2 类实际项目里用肘部法或轮廓系数选 k kmeans KMeans(n_clusters2, random_state42, n_init10) labels kmeans.fit_predict(X_scaled) # 输出每个簇的原始特征均值用于人工判断簇的语义 for cluster_id in range(2): cluster_data X[labels cluster_id] print(f簇 {cluster_id} 样本数: {len(cluster_data)}) print(f 平均请求频率: {cluster_data[:, 0].mean():.1f}) print(f 平均独立目标数: {cluster_data[:, 1].mean():.1f}) print(f 平均UA更换次数: {cluster_data[:, 2].mean():.1f}) print(f 非工作时段占比: {cluster_data[:, 3].mean():.2f})逻辑说明先标准化是因为请求频率和请求间隔量纲差两个数量级不处理的话距离计算会被频率主导。KMeans 的n_init10表示用 10 次不同初始化取最优避免陷入局部最优。输出簇均值而不是直接输出标签是因为聚类结果本身没有语义需要人根据均值判断“这是扫描器还是人工渗透”。参数上n_clusters是唯一需要调的实际项目里建议先用肘部法看拐点再用轮廓系数验证簇内紧密度。3.3 从聚类到攻击预测的衔接原文提到“在攻击预测中通过自主学习根据数据归纳出黑客的攻击模式进行监测和预测能识别攻击者的行为并预知起可能的攻击目的”。从工程角度看聚类只是第一步后面要接的是序列模式挖掘或分类模型。常见做法是把同一攻击者实体的行为按时间排序提取行为序列用 n-gram 或 LSTM 学下一步动作的概率分布。但这一步的前提是实体身份能跨会话关联否则序列是断的。这里有个现实约束原文写于 2018 年当时深度学习在安全领域的落地案例还不多。今天做画像特征工程仍然比模型选型更决定上限。你把 UA 更换频率、请求间隔方差、目标端口分布这些特征做扎实比换一个更深的网络更有效。这也是原文强调“对原始数据进行预处理”的原因——预处理的质量直接决定画像的可用性。4. 画像的表示方式四元组结构比标签更耐用4.1 标签表示法为什么不够用原文第 4 节指出以往通常采用标签形式表示画像但在进一步使用上存在问题。标签的问题在于它是扁平的——你给一个攻击者打上“扫描器”“来自某地区”“偏好某端口”这些标签之间没有关系机器无法推理。比如你知道“攻击类型1”和“目标金融”但标签本身不告诉你这两者之间的映射规则下次遇到新数据就没法自动归类。作者提出的替代方案是基于知识的表示方式每条经验按变量、方法、规则、约束四元组存放。这个结构看起来简单但它把画像从“一堆标签”变成了“可推理的知识库”。4.2 四元组的字段定义与实例按原文的解释四个字段的含义如下变量数据的信息如攻击者 IP、所属范围、攻击发起时间、常见攻击手法约束变量取值的范围限制如攻击时间在 [0-24]攻击目标类型为 {金融、政府、学校、企业}方法改变变量值的函数如攻击时长 结束时间 - 发起时间规则IF A then B 形式的判断如 IF 攻击类型为 1 Then 攻击类型为金融类网站或系统把这四元组落到一个具体攻击者实体上可以组织成下面的结构{ attacker_id: entity_001, variables: { src_ip_range: 10.0.0.0/8, attack_time: 02:30, common_technique: sql_injection, target_type: 1 }, constraints: { attack_time: [0, 24], target_type: [金融, 政府, 学校, 企业] }, methods: { attack_duration: end_time - start_time }, rules: [ {if: target_type 1, then: target_category 金融类网站或系统}, {if: common_technique sql_injection, then: risk_level high} ] }逻辑说明variables存原始观测值constraints定义合法取值范围用于校验数据质量methods存派生计算逻辑避免每次查询都重算rules存推理规则让画像能被机器直接用于归类。参数上constraints的取值集合需要随业务更新比如新增“医疗”目标类型时要同步改规则否则新类型会被规则漏掉。4.3 表示方式对反馈机制的影响原文提到“对于信息的反馈机制也有助于画像信息的不断完善”。四元组结构天然支持反馈——当分析人员发现某条规则误判直接改rules里的条件即可不需要重新训练模型。这是它比纯标签或纯向量表示更耐用的地方。但代价是维护成本高规则多了会冲突需要一套优先级机制。常见做法是给规则打优先级冲突时高优先级覆盖低优先级并记录每次规则变更的审计日志。注意四元组里的rules不要写成硬编码的 if-else 堆砌建议用规则引擎或至少用配置文件管理否则半年后没人敢改。5. 避坑与排查画像项目最容易翻车的五个地方5.1 数据源接了一堆字段对不上现象三类情报源都接了但内部日志的“源 IP”是字符串商业情报的“IP”是整数公开 feed 的“IP”带端口关联时大量匹配失败。原因没有做字段归一化。原文提到“各种设备厂商的数据格式不同”这是根因。解决在入库前加一层 ETL统一 IP 为无端口字符串、时间统一为 UTC 时间戳、攻击手法映射到统一分类字典。这一步不做后面所有分析都是错的。5.2 聚类结果每次跑都不一样现象同样的数据两次 KMeans 跑出来的簇划分不同分析人员无法复现结论。原因KMeans 对初始化敏感且没有固定随机种子。另外特征没标准化时量纲大的列会主导距离。解决固定random_state设置n_init为 10 以上先做StandardScaler。如果数据量大改用 MiniBatchKMeans 并固定种子。5.3 画像标签打完后没人用现象画像做出来了但运营团队还是按老流程看告警画像结果躺在数据库里。原因表示方式没有嵌入现有工作流。标签是给人看的但运营需要的是“这条告警对应的攻击者属于哪个群体、历史行为是什么”。解决把四元组结构里的rules输出成 API让 SIEM 在告警时直接调用返回攻击者群体标签和历史手法。画像只有嵌入决策链路才有价值。5.4 规则冲突导致误判现象同一个攻击者被两条规则同时命中一条判为“金融类”一条判为“政府类”输出结果不稳定。原因规则没有优先级且条件有重叠。解决给每条规则加priority字段冲突时取高优先级同时定期做规则覆盖测试用历史数据回放检查冲突率。5.5 把 IP 定位当成画像的全部现象团队花大量精力做 IP 溯源但攻击者用跳板后画像就断了其他维度信息完全没采集。原因原文明确指出传统溯源方法“都只是定位于攻击者的 IP对于攻击者的其他信息知之甚少”。这是方向性错误。解决把 IP 定位降级为画像的一个维度重点补行为特征、工具指纹、时间模式、目标偏好这些不依赖 IP 的维度。IP 会变行为模式相对稳定。6. 把四元组规则引擎跑起来一个可验证的最小闭环原文的四元组表示方式最大的价值是让画像从“静态标签”变成“可推理结构”。但光有结构不够得能跑。我一般会用一个最小闭环来验证输入一条攻击事件经过约束校验、方法计算、规则推理输出画像标签和风险等级。下面这段代码把第 4 章的结构变成可执行逻辑。# 定义约束变量合法范围 CONSTRAINTS { attack_time: lambda x: 0 x 24, target_type: lambda x: x in [1, 2, 3, 4], } # 定义方法派生变量计算 def calc_attack_duration(start, end): return end - start # 定义规则按优先级排序高优先级在前 RULES [ {priority: 10, if: lambda v: v.get(target_type) 1, then: (target_category, 金融类网站或系统)}, {priority: 10, if: lambda v: v.get(common_technique) sql_injection, then: (risk_level, high)}, {priority: 5, if: lambda v: v.get(attack_time, 12) 6, then: (time_pattern, 非工作时段)}, ] def profile_event(event): # 第一步约束校验 for var, checker in CONSTRAINTS.items(): if var in event and not checker(event[var]): return {error: f变量 {var} 超出约束范围: {event[var]}} # 第二步方法计算 if start_time in event and end_time in event: event[attack_duration] calc_attack_duration( event[start_time], event[end_time]) # 第三步规则推理按优先级取首个命中 result {} for rule in sorted(RULES, keylambda r: -r[priority]): if rule[if](event): key, value rule[then] if key not in result: # 高优先级先写入不被覆盖 result[key] value return result # 测试 event {attack_time: 2, target_type: 1, common_technique: sql_injection, start_time: 100, end_time: 160} print(profile_event(event)) # 输出: {target_category: 金融类网站或系统, risk_level: high, time_pattern: 非工作时段}逻辑说明约束校验放在最前面保证脏数据不进入推理方法计算把派生变量写回事件字典供规则使用规则按priority降序排列if key not in result保证高优先级结果不被低优先级覆盖。参数上CONSTRAINTS和RULES都应该外置成配置文件改规则不用改代码。验证方法是构造边界事件——比如attack_time25应该报约束错误target_type1且common_techniquesql_injection应该同时命中两条高优先级规则且不冲突。这套闭环跑通后你可以把它接到 SIEM 的告警管道里每条告警触发一次profile_event输出的画像标签写回告警上下文。运营人员看到的就不再是孤立的 IP 和端口而是“金融类目标、SQL 注入手法、非工作时段活动、高风险”的组合描述。从那以后我每次做画像表示都强制先用四元组把规则和约束写清楚再考虑要不要上模型——因为规则跑不通的地方模型大概率也跑不通。希望帮到你。本文还有配套的精品资源点击获取