网络安全审计与日志监控体系

CH-01-02-050·约 18 分钟·计算机基础·更新 2026-08-10

老周是“安心便利店”连锁集团的总防损主管。去年店里丢了三次货，监控录像明明都在，可等警察来了，保安却说不清晚上十点到底谁进过仓库。问题出在哪？录像机一直在录，但没人整理、没人盯屏、出事了也不知道该查哪一段。于是老周下定决心，搭建一套完整的“电子眼 + 值班室 + 规章制度”体系：每家店装摄像头（采集日志）、录像按规矩存够天数（归档留存）、总部大屏把画面汇聚一处（SIEM平台）、值班员按巡查手册盯异常（检测规则）、发现可疑立刻拉警报（告警响应）、保险检查时有据可查（合规审计）、事后能按时间线回放复盘（追溯取证）。这套体系，就是网络安全领域的“安全审计与日志监控”。读完全文，你会理解从采集、分析到处置、合规的完整闭环，也会明白日志不是“存了就行”，而是要靠规则和平台真正“用起来”。

岗位关联

掌握这套日志监控闭环，能帮你从“出了事手忙脚乱”变成“发现前有预兆、发生时秒响应、事后全可溯”——这是安全工程师最核心的硬实力，也是运维与合规岗位的晋升加分项。

可视化演示
日志采集归档
SIEM平台
异常检测规则
告警与响应
合规审计要求
入侵追溯取证
日志分析技术
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

动态展示十进制数-6.5转换为IEEE754单精度浮点数表示的完整过程，直观呈现符号位、指数位和尾数位的编码原理。

本节配有交互动效（进入视口后自动加载，约 3KB）。

IEEE754单精度编码 - 十进制-6.5 符号位S=1（负数）阶码E=2+127=129=10000001 V=(-1)^S×1.M×2^(E-127) IEEE754标准

日志采集归档

老周的第一项工作，是给每家分店统一装摄像头：收银台上方一台、仓库门口一台、后门走廊一台。可他很快发现，各店录像机品牌不一，有的画质模糊，有的时间不准，有的录满了就自动覆盖旧画面。于是他统一了设备型号、校准了系统时间、设定录像保存三个月。这一步，对应的正是安全审计体系的“日志采集与归档”。

日志就是系统的“摄像头”，记录着谁在什么时间、从哪台机器、做了什么操作。操作系统、防火墙、数据库每天产生海量日志，必须先统一采集、标准化字段，后续分析才有意义。采集方式主要有代理采集（在主机上装 agent）和协议接收（如 syslog 推送到中央服务器）两类；标准化则是把各设备五花八门的字段格式统一成固定结构。

存储是容易被低估的环节。日志量大的企业每天产生 TB 级数据，必须提前估算容量、设计分层存储，并按合规要求确定留存周期，再配合轮转归档把老日志压缩沉降。

老周的录像带满了会轮转、旧带归档封存；日志同样如此——热数据放高速存储供实时检索，冷数据放低成本归档，既省开支又不丢证据。

S_{\text{total}} = n \times \bar{b} \times T \times 86400

这条公式用来估算“日志到底要占多少磁盘”，输入是每秒条数、单条大小和留存天数。

每秒日志条数 $n$所有接入设备每秒产生的日志总数，是存储估算的基础输入，等于各来源之和。
$n = \sum_{j=1}^{m} n_j$
单条日志平均体积 $\bar{b}$标准化后每条日志的平均字节数，字段越丰富体积越大。
$\bar{b} = \frac{1}{m}\sum_{j=1}^{m} b_j$
留存天数 $T$日志需保存的时间，等保合规场景通常要求不少于 180 天。
$T \geq 180 \ \text{天}$
秒换算系数 86400一天有 86400 秒，把“每秒字节”换算成“每天字节”。
$24 \times 3600 = 86400$

SIEM平台

光有各店录像还不够。老周在总部建了一面监控大屏，把所有分店的画面信号汇聚到同一个系统里，值班员不用再一台一台切换。这个“总控中心”，对应网络安全里的 SIEM 平台——Security Information and Event Management，安全信息与事件管理。

SIEM 的核心能力有三层：第一层是数据接入，把防火墙、服务器、数据库等各类日志归一化收进来；第二层是关联分析，把看似孤立的单个事件串联成完整的攻击链条，比如“先扫描端口、再尝试登录、最后外传数据”；第三层是态势呈现，通过仪表盘让安全团队一眼看清全网风险热度和趋势，同时接入外部威胁情报库辅助研判。

为了让机器评判风险高低，SIEM 常给不同事件打分再加权汇总，得到一个可比较的总风险值。

大屏上绿、黄、红三色仪表盘实时跳动，老周一抬头就能知道今天哪家店、哪个片区风险最高——这就是 SIEM 带给运营者的“上帝视角”。

R = \sum_{i=1}^{m} w_i \times s_i

这是 SIEM 里常见的“风险评分”模型：每个检测信号按严重程度打分，再用权重合成总分，超过阈值就升级处置。

指标得分 $s_i$单个安全事件按严重程度打出的分值，越高越危险，通常取值 1 到 5。
$s_i \in [1, 5]$
指标权重 $w_i$不同类型事件的权重，决定它对总分的贡献比例，所有权重归一化之和为 1。
$\sum_{i=1}^{m} w_i = 1$
加权总分 $R$把所有信号按权重合成一个总风险值，SOC 依据它决定是否升级处置。
$R = \sum_{i=1}^{m} w_i \times s_i$

异常检测规则

大屏有了，可值班保安不可能 24 小时目不转睛。老周于是发了一本《巡查手册》：每半小时看一眼库房门、收银台现金超过两千要留意、同一人深夜连续进仓库要报告。这些“人为盯梢的规则”，落到日志监控里就是异常检测规则。

构建规则的第一步是建立基线——先观察一段时间“正常长什么样”，比如平时每分钟登录失败平均 2 次；然后通过规则引擎设置阈值、频率和序列规则：登录失败超 5 次告警、1 分钟内扫 100 个端口告警、先登录后提权再外传的“三步走”命中即告警。更高级的做法是用统计模型自动评判离群程度，减少手工拍脑袋。

最常用的统计度量叫 Z 分数，它回答一个问题：眼前这个数值，偏离正常基线有多远？

手册是死的，人是活的——规则要根据季节、地段、营业时段持续调优，否则要么漏报真实风险，要么天天“狼来了”制造告警疲劳。

Z = \frac{x - \mu}{\sigma}

Z 分数衡量“当前值相对历史正常水平偏离了几个标准差”，绝对值越大越可疑，一般超过 3 就值得关注。

当前观测值 $x$某一时间窗口的实际数值，例如这一分钟内登录失败的次数。
$x = \text{当前窗口内的异常行为计数}$
基线均值 $\mu$历史正常行为的平均水平，由前 N 个窗口的观测值求平均得到。
$\mu = \frac{1}{N}\sum_{i=1}^{N} x_i$
标准差 $\sigma$历史数据的波动程度，波动越大基线越“宽容”。
$\sigma = \sqrt{\frac{1}{N}\sum_{i=1}^{N}(x_i-\mu)^2}$
偏离度 $Z$当前值离基线相差几个标准差，通常 $|Z|>3$ 判定为异常。
$Z = \frac{x-\mu}{\sigma}$

告警与响应

警报响了之后怎么办？老周定下三条铁律：红灯（疑似被盗现场）立即报警并疏散顾客，黄灯（可疑人员徘徊）呼叫巡逻保安到场确认，绿灯（误触警报）做好记录以便下次调低灵敏度。这套“分级响应”，正是告警与响应环节的精髓。

技术层面，告警要先分级：严重、高危、中危、低危四级，对应不同的响应时限和处置人员；再通过多渠道通知触达——短信、即时通讯、工单系统同步推送，确保不遗漏。随后进入处置流程闭环：确认 → 研判 → 处置 → 恢复 → 复盘，每一步都留痕。衡量响应效率的关键指标是平均确认时间，即从告警产生到分析师接手确认的耗时。

警情处置完还要复盘，就像老周每月开防损会，把本月所有警报翻出来核对哪些是误报、哪些漏了，再把《巡查手册》改得更准更细。

\bar{T}_{\text{确认}} = \frac{1}{N}\sum_{i=1}^{N}\left(t_{i}^{\text{确认}} - t_{i}^{\text{告警}}\right)

MTTA（平均确认时间）衡量“告警发出后多久被人真正处理”，数值越小说明响应越及时，是被 SOC 普遍追踪的核心指标。

告警发生时刻 $t_{i}^{\text{告警}}$第 i 条告警被规则引擎命中的时间戳。
$t_{i}^{\text{告警}} = \text{规则命中并生成告警的时刻}$
确认时刻 $t_{i}^{\text{确认}}$安全分析师完成研判、确认该告警有效或无效的时间戳。
$t_{i}^{\text{确认}} = \text{分析师完成研判确认的时刻}$
单条确认耗时 $T_i$两者相减，得到某次告警从发出到被接手的耗时。
$T_i = t_{i}^{\text{确认}} - t_{i}^{\text{告警}}$
平均确认时间 $\bar{T}_{\text{确认}}$对 N 条告警求平均，汇聚成团队响应效率的体检指标。
$\bar{T}_{\text{确认}} = \frac{1}{N}\sum_{i=1}^{N} T_i$

合规审计要求

总部的监控体系还要过保险公司和品牌方的检查：录像必须存够天数、进出仓库要登记签字、夜间值班记录要完整，否则不给续保。老周这才意识到，合规不是额外负担，而是整个体系能不能持续运转的“及格线”。

在网络安全领域，合规审计要求主要由等保（等级保护）等法规驱动：关键系统日志留存不少于 6 个月、审计记录不可篡改、系统管理员与审计员角色分离（三权分立）、对敏感操作的访问控制要严格、并定期生成审计报告上报。合规检查最看重的是“留痕”——每一笔操作都能追溯到人、时间、来源。

合规工作的量化指标是审计覆盖率，它回答“该管的到底管住了多少”。

老周后来发现，正是保险公司的检查倒逼他把“只录不看”的监控升级成了“用得上、对得上、拿得出”的证据链——合规要求，反而成了体系完善的最大推手。

C = \frac{N_{\text{已审计}}}{N_{\text{应审计}}} \times 100\%

审计覆盖率是合规检查的硬指标，等于“已纳入审计的对象数”除以“应纳入审计的对象总数”，接近 100% 才算达标。

应审计对象 $N_{\text{应审计}}$合规范围内必须纳入审计的关键资产与操作总数。
$N_{\text{应审计}} = \text{关键主机数} + \text{关键应用数}$
已审计对象 $N_{\text{已审计}}$真正接入日志、可完整回溯的对象数量。
$N_{\text{已审计}} = \text{日志完整可追溯的对象数}$
覆盖率 $C$两者比值再百分比化，合规检查要求其接近 100%。
$C = \frac{N_{\text{已审计}}}{N_{\text{应审计}}} \times 100\%$

入侵追溯取证

某天夜里，一家分店丢了一台 POS 机。老周第一次觉得这套体系值回了票价：他按时间线回放监控——晚上十点仓库门被推开、十点零三分电源被拔、十点零五分嫌疑人从后门离开；再锁定画面、把关键片段单独拷贝封存，最后根据漏洞加固了后门门锁。这就是入侵追溯取证的全过程。

技术层面，追溯的第一步是时间线重建：把分散在各设备里的日志按时间戳串成一条完整的事件链，还原攻击者的每一步动作；第二步是来源追踪：从受害主机反查 IP、账号、跳板机，画出攻击路径；第三步是证据固定：对日志文件做哈希校验、双人签字确认、存放到防篡改介质，保证证据在法庭或内部问责中有效。

在多信号并存的场景下，可以用概率叠加来综合研判——多个独立信号同时指向攻击时，整体可信度会显著上升。

证据链就像监控片段：单帧画面说服力有限，首尾完整、时间连续、来源清晰的一条链才有真正的效力——日志追溯的终点，永远是加固与改进。

P_{\text{攻击}} = 1 - \prod_{i=1}^{k}\left(1 - p_i\right)

这条公式把多个独立信号的“嫌疑概率”合成一个综合判断：信号越多越齐，判定为攻击的把握越大。

单信号概率 $p_i$第 i 个独立信号（如异常登录、可疑外连）判定为攻击的概率，介于 0 和 1 之间。
$p_i \in (0, 1)$
全部未命中概率 $P_{\text{放过}}$所有信号都不指向攻击时，事件被当作正常的可能性。
$P_{\text{放过}} = \prod_{i=1}^{k}\left(1 - p_i\right)$
至少一个命中 $P_{\text{攻击}}$取补集得到综合研判为攻击的概率，信号越多判定越可靠。
$P_{\text{攻击}} = 1 - P_{\text{放过}}$

日志分析技术

体系建好后，老周开始把看录像的窍门教给新人：先按时间快进锁定异常时段，再放大局部画面看细节；统计夜班进出频次找出规律；把收银数据和仓库开门记录放一起比对，揪出内鬼。这些“看录像的技巧”，就是日志分析技术。

第一类是关键字检索：用 grep 或索引系统在海量日志里快速定位特定 IP、账号或错误码，像在几百小时录像里精准跳转到某一段。第二类是聚合统计：按 IP、用户、时间窗口分组计数，发现“某个 IP 一小时内出现 500 次”这类聚集异常。第三类是关联规则挖掘：从大量历史日志中自动找出“A 出现时 B 也常出现”的强关联，沉淀为新检测规则。

关联规则的核心度量是置信度，它刻画了前件与后件之间的依赖强度。

掌握了这些分析技巧，老周从“会看录像”升级成“看得快、看得准”，日志也从沉默的磁带变成了会说话的证人——而这，正是安全审计与日志监控体系最迷人的地方。

\text{confidence}(A \to B) = \frac{\text{support}(A \cup B)}{\text{support}(A)}

置信度表示“日志里出现 A 时，B 也伴随出现的比例”，高置信度的规则可以直接转化为检测规则或调查线索。

共同支持度 $\text{support}(A \cup B)$A 与 B 同时出现在同一条日志/事件中的样本数。
$\text{support}(A \cup B) = \left|\{e : e \in E, A \in e, B \in e\}\right|$
前件支持度 $\text{support}(A)$A 单独出现的总样本数，作为分母做归一化。
$\text{support}(A) = \left|\{e : e \in E, A \in e\}\right|$
置信度两者之比，表示 A 发生时 B 伴随出现的条件概率估计值。
$\text{confidence}(A \to B) = \frac{\text{support}(A \cup B)}{\text{support}(A)}$

AI 应用场景

SOC 告警疲劳治理

阶段：异常检测与告警调优

解决的问题：某大型银行安全运营中心日均产生 3 万条告警，其中 95% 是误报，真实入侵信号被淹没在海量弹窗里。传统做法是堆人力逐条核查，效率极低且容易漏掉真攻击。引入基线与 Z 分数统计模型后，系统自动学习各业务系统的正常基线，只有偏离超过阈值的告警才升级给分析师，配合告警分级压降噪音。

具体案例：某股份制银行 SOC 将告警接入 SIEM 后，对登录日志按“每用户每分钟失败次数”建立基线，将暴力破解类告警准确性从 12% 提升到 78%，平均确认时间从 40 分钟降到 9 分钟，安全团队终于能把精力聚焦在真正的攻击上。

等保 2.0 合规审计自动化

阶段：合规检查与审计报告

解决的问题：传统等保测评需要人工登录各服务器导出日志、逐个核对留存天数与访问权限，一家中型企业要耗费两周，且容易漏项。通过脚本自动巡检“日志是否接入、留存是否满 180 天、审计员账号是否存在”等检查项，并按覆盖率公式计算得分、自动生成合规报告，把周期压缩到一天。

具体案例：某政务云平台每月自动对 300 台主机执行合规巡检，审计覆盖率从 62% 提升到 98%，三次等保测评一次通过，审计报告由系统自动留痕备查。

供应链攻击全链路溯源

阶段：事件响应与入侵追溯

解决的问题：某企业发现内部服务器异常外连，传统排查无法确定入口。通过 SIEM 关联分析和时间线重建，把第三方组件更新日志、防火墙会话日志、主机进程日志跨系统串联，回溯出攻击者经由某开源依赖的恶意更新包进入内网、横向移动到数据库的完整路径，并完成证据固定。

具体案例：某电商公司遭遇供应链投毒事件，安全团队用日志时间线还原了“更新触发 → 反弹 shell → 数据外传”三阶段攻击链，在一小时内定位受害主机并对全公司 200 台主机完成加固，避免了数据泄露升级。

Python 演示

python49 行

import refrom collections import defaultdict LOG_EXAMPLE = [    "Mar 10 08:01:12 srv-web sshd[123]: Failed password for root from 10.0.0.8 port 22",    "Mar 10 08:01:13 srv-web sshd[124]: Failed password for admin from 10.0.0.8 port 22",    "Mar 10 08:01:15 srv-web sshd[125]: Accepted password for ops from 192.168.1.20 port 22",    "Mar 10 08:01:16 srv-web sshd[126]: Failed password for root from 10.0.0.8 port 22",    "Mar 10 08:02:10 srv-db sshd[227]: Failed password for root from 10.0.0.9 port 22",    "Mar 10 08:02:12 srv-db sshd[228]: Failed password for root from 10.0.0.9 port 22",    "Mar 10 08:03:05 srv-web sshd[131]: Failed password for root from 10.0.0.8 port 22",] FAIL_RE = re.compile(r"Failed password")THRESHOLD = 3 def collect_logs():    return LOG_EXAMPLE[:] def detect_bruteforce(lines, threshold=THRESHOLD):    counter = defaultdict(int)    alerts = []    for line in lines:        if FAIL_RE.search(line):            ip = line.split("from ")[1].split()[0]            counter[ip] += 1            if counter[ip] == threshold:                alerts.append((ip, counter[ip]))    return alerts def write_audit_report(alerts):    with open("audit_report.txt", "w", encoding="utf-8") as f:        f.write("安全审计简报\n")        if alerts:            for ip, cnt in alerts:                f.write("告警: 疑似暴力破解 IP=%s 失败次数=%d\n" % (ip, cnt))        else:            f.write("未发现异常行为\n")    print("审计报告已生成: audit_report.txt") def main():    logs = collect_logs()    alerts = detect_bruteforce(logs)    for ip, cnt in alerts:        print("检测到异常: %s 失败登录 %d 次" % (ip, cnt))    write_audit_report(alerts) if __name__ == "__main__":    main()

目的：模拟一个最简日志监控引擎——读取登录日志，对相同来源 IP 的失败次数计数，达到阈值即判定为暴力破解并触发告警，最后输出审计报告。

FAIL_RE = re.compile(r"Failed password")预编译正则表达式，相当于给“摄像头”设定只看包含“登录失败”的画面，减少无效匹配开销。
detect_bruteforce(lines, threshold=THRESHOLD)对应“巡查手册里的频率规则”：同一 IP 失败次数到点即告警。
counter = defaultdict(int)准备一个按 IP 计数的本子，新 IP 自动从 0 开始，无需手动初始化。
ip = line.split("from ")[1].split()[0]从日志行中切出来源 IP，模拟日志解析与字段提取。
if counter[ip] == threshold:只在达到阈值的那一次触发告警，避免每次都弹窗造成告警疲劳。
write_audit_report(alerts)把结论落成文本文件，对应合规审计的“留痕”要求，报告可追溯、可备查。
if __name__ == "__main__":标准 Python 入口，保证脚本既能被导入也能直接运行。

常见误区

误区服务器开了日志、日志文件一直在变大，我就觉得安全审计已经做完了。反正出了事可以翻日志嘛。

正解日志只是“录像素材”，审计是“会看录像的人 + 规则 + 流程”。没有采集策略、字段标准化、检测规则和告警处置，日志就是一坨没人看的废数据。就像老周的店，监控一直录着但没人盯屏，丢了货照样抓瞎——素材在，可没人把它变成线索和证据。

为何常见：日志是看得见的显性资产，文件大小直观可见，容易让人误以为“存在即安全”，而忽略了后续的分析与治理环节。

误区公司买了昂贵的 SIEM 平台，就高枕无忧了，所有入侵都会自动报警、自动处置，安全团队可以撤掉一半。

正解SIEM 只是“总控大屏”，它的价值高度依赖接入的数据质量和规则水平。日志没接全、规则没调优、缺乏威胁情报支撑，大屏再漂亮也看不见死角。老周的大屏刚上线时也有三成画面是雪花——数据没打通，平台就是个空壳。

为何常见：厂商宣传往往强调“智能”与“自动”，弱化了“事在人为”的调优成本，导致采购方产生不切实际的预期。

误区恨不得每个可疑行为都弹窗，告警量越大说明监控越严密，安全团队越忙越说明系统在发挥作用。

正解告警泛滥必然导致“狼来了”效应——分析师看多了误报会麻木，真实攻击反而被当作又一条噪音忽略，这就是告警疲劳。好的体系恰恰是不断调优规则、压低误报率，让每条告警都值得被认真对待。

为何常见：把“检测灵敏度”和“安全水平”混为一谈，忽略了人的注意力是有限资源这一基本事实。

误区把日志永久保存、不做轮转，磁盘满了就加盘，觉得数据留得越全越保险。

正解日志存储有真实成本，海量冷数据还会拖慢检索速度。合理策略是按合规要求确定留存期（如等保要求的 180 天），热数据放高速存储支持实时分析，老日志压缩归档到低成本介质，超出周期的按策略清理。

为何常见：只看到“留着当证据”的好处，没算存储成本与检索性能的账，也没理解合规要求才是留存的真正依据。

面试题

Q1. 在搭建日志监控体系时，第一步通常应该做什么？

单选题 · easy

A.直接购买最贵的 SIEM 平台
B.梳理日志源并制定采集策略← 正确答案
C.编写一堆告警规则
D.删除历史日志腾出空间

答案：B。建设日志体系就像老周装监控，先得想清楚每个分店装几台、装在哪——对应梳理日志源和采集策略。跳过这一步直接买平台或写规则，就像买了大屏却没有摄像头接入，系统必然空转。

Q2. 下列哪一项最能描述 SIEM 的核心作用？

单选题 · easy

A.替代防火墙进行流量过滤
B.汇总多源日志并做关联分析← 正确答案
C.定期给系统打补丁
D.加密磁盘数据

答案：B。SIEM 相当于总部的监控大屏，把各分店画面汇聚一处并做联动研判。防火墙是门禁、补丁是修锁、加密是保险柜，它们和 SIEM 是不同的安全环节。

Q3. 下列属于常见异常行为检测手段的有哪些？

多选题 · mid

A.基于基线的统计偏差分析← 正确答案
B.阈值规则匹配← 正确答案
C.人工直接修改数据库字段
D.行为序列规则匹配← 正确答案

答案：ABD。基线与统计偏差（如 Z 分数）是检测偏离正常的行为，阈值规则是“失败超 5 次告警”这类硬标准，序列规则是“先扫描后登录再外传”的步骤链，三者都是常见检测手段。人工改数据库是违规操作，不是检测方法。

Q4. 告警疲劳是指什么？

单选题 · mid

A.系统完全不产生告警
B.大量误报导致真实告警被忽略← 正确答案
C.告警传输延时过长
D.数据库连接出现故障

答案：B。告警疲劳就像老周店里的报警器天天误响，保安渐渐不再当回事。当误报比例过高，真实入侵告警混在其中也会被当作噪音跳过，这是安全运营中最危险的隐性风险之一。

Q5. 按照等级保护合规要求，日志留存时间通常应达到多少？

单选题 · mid

A.30 天
B.3 个月
C.6 个月及以上← 正确答案
D.永久删除

答案：C。等保合规要求关键日志留存不少于 180 天，也就是 6 个月。这就像保险检查要求监控录像必须存够天数，太短无法追溯历史事件，过长又增加存储成本。

Q6. SIEM 关联分析的真正价值体现在哪些方面？

多选题 · hard

A.将孤立事件组合成完整攻击链← 正确答案
B.削减日志采集的总量
C.降低人工逐条分析的成本← 正确答案
D.完全消除所有误报

答案：AC。关联分析的价值在于把“东一条、西一条”的孤立日志串成故事，并减少人工大海捞针的成本。但它不减少日志采集量（采集由日志源决定），也不可能完全消除误报——任何检测体系都存在误差。

Q7. 日志归档的主要目的是什么？

单选题 · easy

A.节省服务器内存空间
B.满足留存要求并支持未来追溯← 正确答案
C.提高网络传输速度
D.加快数据库写入

答案：B。归档是把老日志压缩、转移到低成本存储并保留一段时间，目的和录像带封存一样——既满足合规留存，又能在未来需要时回溯取证。它跟内存、网速、写入性能没有直接关系。

Q8. 入侵事件追溯取证时，安全团队应该做哪些事？

多选题 · hard

A.按时间线重建攻击全过程← 正确答案
B.对关键日志做完整性校验← 正确答案
C.立即删除可疑日志避免泄露
D.追踪攻击来源 IP 与账号← 正确答案

答案：ABD。时间线重建还原“先干什么后干什么”，哈希校验保证证据没被篡改，来源追踪锁定攻击者入口，这三步构成完整证据链。删除日志恰恰是销毁证据，是取证的大忌。

Q9. 用 Z 分数做异常检测时，某事件计算得到 |Z| > 3，最合理的解读是？

单选题 · mid

A.该事件完全正常，无需理会
B.该事件偏离历史基线较远，值得重点研判← 正确答案
C.服务器必定已经宕机
D.日志文件发生了物理损坏

答案：B。Z 分数表示当前值偏离基线几个标准差，|Z|>3 意味着偏差较大，相当于老周发现某店夜间开门次数比平时高出好几倍——值得查，但不等于已确认出事，还需人工研判确认。

Q10. 在关联规则分析中，confidence(A→B) = 0.8 的正确含义是？

单选题 · extreme

A.日志中出现 A 时，B 有 80% 概率伴随出现← 正确答案
B.B 出现时 A 必然出现
C.系统有 80% 的概率正在被入侵
D.告警规则的误报率为 20%

答案：A。置信度是条件概率的估计，度量的是“前件出现后后件有多大概率跟着出现”，方向性明确——A 推出 B。它不表示反向关系（B 推 A），也和入侵概率、误报率没有直接对应关系。