3、安全数据与指标：常见安全数据源（日志、流量、告警、漏洞）、关键安全指标（事件数、威胁等级、攻击频率）、数据采集与预处理
时间序列安全趋势分析的本质，是从历史安全数据中提取时间维度上的规律、异常与演化方向。任何趋势判断的可靠性，都取决于底层数据的完整度、准确度与一致性。如果数据源覆盖不全、指标口径混乱或预处理粗糙，后续无论采用多么先进的统计模型或机器学习算法，其输出都难以支撑有效的安全决策。本章聚焦安全数据分析的“原材料”环节，系统梳理常见安全数据源的种类与特点、关键安全指标的定义与计算口径，以及从原始数据到可用时间序列的采集与预处理流程。
3.1 常见安全数据源：四类核心数据的特征与价值
3.1.1 日志数据：安全分析的基础原材料
日志数据是安全时间序列分析中最基础、覆盖面最广的数据源。它记录了系统、应用和安全设备在运行过程中产生的离散事件。从时间序列分析的角度看，日志数据具有以下核心特征：
- 高基数性：日志类型繁多，包括操作系统日志（Windows Event Log、Linux Syslog）、应用日志（Web服务器访问日志、数据库日志）、安全设备日志（防火墙、IDS/IPS、WAF）等。
- 时间敏感性：每条日志都带有时间戳，是构建时间序列的基本时间锚点。
- 非结构化程度高：不同来源的日志格式差异大，需要解析和标准化处理。
在实际安全运营中，日志数据通常通过Syslog、SNMP Trap、文件采集（如Logstash、Fluentd）或云服务API等方式汇聚到SIEM或日志管理平台。对于时间序列分析而言，日志数据最直接的用途是统计单位时间内的日志量变化、特定事件类型的出现频次，以及异常事件的时间分布规律。
3.1.2 流量数据：网络行为的客观镜像
流量数据反映的是网络实体之间的实际通信行为，相比日志数据，它更客观、更难被主机侧篡改。常见的流量数据形态包括：
- NetFlow/sFlow/IPFIX：流记录数据，包含源IP、目的IP、端口、协议、字节数、包数、时间戳等元数据，适合做宏观流量趋势分析。
- PCAP（全包捕获）：完整的原始数据包，包含载荷内容，分析精度高但存储成本大，通常只在关键链路或短时间窗口内启用。
- DNS日志/HTTP日志：由网络设备或代理服务器生成，对检测C2通信、数据外泄等行为有独特价值。
在时间序列分析中，流量数据常用于识别带宽占用异常、端口扫描行为的时间规律、以及特定协议（如DNS、HTTPS）的流量周期性波动。
3.1.3 告警数据：安全设备的研判输出
告警数据是IDS/IPS、SIEM、EDR等安全设备或平台对原始日志和流量进行分析后输出的“研判结论”。告警数据通常包含：告警名称、严重级别（Critical/High/Medium/Low）、源/目的IP、发生时间、命中规则或检测模型等字段。
告警数据的时间序列分析价值在于：
- 统计告警总量的时间分布，发现告警风暴或异常沉寂。
- 按威胁等级拆分告警序列，观察高危告警的演变趋势。
- 分析特定告警类型的周期性规律，如每周一上午的扫描告警高峰。
3.1.4 漏洞数据：安全态势的静态基线
漏洞数据描述的是资产中存在的安全弱点，包括漏洞编号（CVE）、CVSS评分、漏洞类型、受影响资产、可利用性、是否已修复等信息。与前三类数据不同，漏洞数据的变化频率较低，通常以天或周为粒度更新。
在时间序列分析中，漏洞数据主要用于：
- 跟踪“未修复漏洞数量”随时间的变化趋势，评估修复效率。
- 分析高危漏洞的暴露时长（从发现到修复的时间窗口）。
- 将漏洞数据与告警/攻击事件关联，判断漏洞是否被实际利用。
| 数据源类型 | 典型来源 | 时间粒度 | 主要分析价值 | 采集成本 |
|---|---|---|---|---|
| 日志数据 | OS、应用、防火墙、WAF | 秒~分钟 | 事件计数、异常检测、合规审计 | 中（需解析） |
| 流量数据 | NetFlow、PCAP、DNS | 分钟~小时 | 网络行为基线、C2检测、横向移动 | 高（存储大） |
| 告警数据 | IDS/IPS、SIEM、EDR | 分钟~小时 | 威胁等级趋势、告警降噪、响应效率 | 低（已结构化） |
| 漏洞数据 | 扫描器、CVE库、资产库 | 天~周 | 暴露面变化、修复进度、风险基线 | 低（定期扫描） |
3.2 关键安全指标：从原始数据到可量化的时间序列
3.2.1 事件数（Event Count）
事件数是最基础的安全指标，指在特定时间窗口内发生的安全相关事件总量。根据分析目的不同，事件数可以细分为：
- 原始日志事件数：所有采集到的日志条数，反映系统整体活动水平。
- 安全告警事件数：经过安全设备检测后产生的告警数量，反映安全检测系统的“关注度”。
- 确认安全事件数：经过安全分析师研判确认的真实攻击事件数量，是衡量安全运营效果的核心指标。
在时间序列分析中，事件数通常按固定时间窗口（如5分钟、1小时、1天）进行聚合计数，形成等间隔的时间序列。事件数的突然上升可能意味着扫描、蠕虫传播或DDoS攻击；事件数的持续下降则可能暗示检测规则失效或攻击者已绕过监控。
3.2.2 威胁等级（Threat Severity）
威胁等级是对安全事件严重程度的量化评估。常见做法是采用类似CVSS的评分体系，或使用四级分类（严重、高危、中危、低危）。在时间序列分析中，威胁等级通常不是单独作为一个序列，而是作为事件数的“加权维度”使用。
常用的处理方式包括：
- 加权事件数：将不同等级的事件赋予不同权重（如严重=10、高危=7、中危=4、低危=1），计算加权和作为综合风险序列。
- 等级分布序列：分别统计各等级事件数，形成多维时间序列，观察高危事件占比的变化趋势。
- 最高等级序列：每个时间窗口内取最高威胁等级，用于监控“最坏情况”的演变。
3.2.3 攻击频率（Attack Frequency）
攻击频率描述单位时间内攻击行为发生的次数。与事件数不同，攻击频率更强调“攻击行为”的语义，通常需要对原始告警进行攻击阶段归并（如将同一IP在短时间内对同一目标的多次扫描归并为一次攻击行为）。
攻击频率的计算方法：
- 定义攻击行为粒度：按源IP、目的IP、攻击类型、时间窗口（如10分钟）进行聚合，将满足条件的多条告警归并为一次攻击。
- 统计频次：在更大的时间窗口（如1小时、1天）内统计攻击行为的总次数。
- 计算频率指标：攻击次数/时间单位，例如“次/小时”“次/天”。
攻击频率的时间序列分析可以揭示：攻击者是否在特定时间段（如深夜、周末）集中发起攻击；新型攻击工具是否导致攻击频率的阶跃式上升；以及防御措施部署后攻击频率是否显著下降。
3.3 数据采集与预处理：构建高质量时间序列的关键步骤
3.3.1 数据采集架构与策略
安全数据的采集需要兼顾实时性、完整性和可靠性。常见的采集架构包括：
- Agent方式：在服务器或终端上安装采集Agent，主动推送日志或指标数据。适合主机侧日志和EDR数据。
- Syslog/SNMP Trap：网络设备和安全设备通过标准协议主动发送日志。适合防火墙、路由器、IDS等设备。
- API拉取：通过云平台或安全产品的API定期拉取数据。适合SaaS安全服务、云WAF、云防火墙等。
- 流量镜像（TAP/SPAN）：通过交换机端口镜像或分光器获取原始流量。适合流量分析场景。
在时间序列分析场景中，采集策略需要关注两个关键参数：采集粒度（多久采集一次）和传输延迟（数据产生到可被分析的时间差）。对于实时监控场景，建议采集延迟控制在1分钟以内；对于趋势分析场景，可以接受5-15分钟的延迟。
3.3.2 数据清洗与标准化
原始安全数据往往存在格式不统一、字段缺失、时间戳漂移、重复记录等问题。预处理阶段的核心任务包括：
- 格式解析：将不同来源的日志解析为统一的JSON或表格结构，提取关键字段（时间、源IP、目的IP、事件类型、严重级别等）。
- 时间戳规范化：统一时区（建议使用UTC存储，展示时转换为本地时区），校正时钟偏移，处理时间戳缺失的记录。
- 去重：消除因网络重传、采集重复等原因产生的重复日志或告警。
- 缺失值处理：对于缺失的字段，根据上下文填充（如缺失的严重级别按默认值处理）或直接丢弃。
- IP地址标准化：统一IP格式（IPv4/IPv6），去除端口号等干扰信息。
3.3.3 时间窗口聚合与降采样
原始安全数据通常是事件级别的，粒度太细，直接进行时间序列分析会面临数据量过大、噪声过多的问题。因此需要按固定时间窗口进行聚合（Aggregation），将事件数据转换为等间隔的时序数据。
常见的聚合方式包括：
| 聚合窗口 | 适用场景 | 典型指标 | 数据量估算（万级EPS） |
|---|---|---|---|
| 1分钟 | 实时监控、告警触发 | 事件数、告警数 | 1440条/天/指标 |
| 5分钟 | 日常运营分析 | 事件数、攻击频率 | 288条/天/指标 |
| 1小时 | 趋势分析、周报 | 加权风险值、等级分布 | 24条/天/指标 |
| 1天 | 长期趋势、月度报告 | 漏洞修复数、事件总量 | 1条/天/指标 |
聚合时需要注意：对于计数类指标（如事件数），使用SUM或COUNT；对于等级类指标，使用MAX或加权平均；对于频率类指标，使用SUM后除以时间窗口长度。
3.3.4 案例拆解：某企业SOC的告警趋势分析数据管道
背景与约束：某中型企业SOC（安全运营中心）需要建立一套告警趋势分析系统，用于每日早会展示前24小时的安全态势。该企业部署了防火墙、IDS、EDR和WAF四类安全设备，日均产生原始日志约8000万条，告警约5000条。安全团队仅有2名数据分析师，无专职数据工程师。
初始现象与目标：此前SOC使用Excel手工统计告警量，每天耗时2小时且无法发现小时级别的异常波动。目标是将告警趋势分析自动化，实现小时级粒度的时间序列展示，并识别出“告警量异常突增”的时间点。
关键输入数据：
- 防火墙日志：Syslog格式，包含时间、源/目的IP、端口、动作（允许/拒绝）。
- IDS告警：通过SIEM API拉取，JSON格式，包含时间、告警名称、严重级别、源/目的IP。
- EDR事件：Agent推送，包含进程、文件、网络连接等字段。
- WAF日志：HTTP访问日志，包含请求URL、状态码、拦截规则ID。
分析判断过程：团队首先梳理了四类数据源的时间戳格式，发现防火墙日志使用本地时间（UTC+8），而IDS告警使用UTC时间，存在8小时偏差。此外，EDR事件存在约5%的重复推送。团队决定统一转换为UTC时间存储，并在聚合前进行去重。
实际操作步骤：
- 使用Logstash配置四类数据源的采集管道，统一输出为JSON格式到Elasticsearch。
- 编写预处理脚本：时间戳统一转为UTC、去除重复告警（基于告警ID+时间窗口去重）、将严重级别映射为数值（严重=4、高危=3、中危=2、低危=1）。
- 使用Kibana创建聚合可视化：按1小时窗口统计总告警数、高危及以上告警数、加权风险值（SUM(严重级别数值×告警数)）。
- 设置异常检测规则：当某小时告警数超过过去7天同小时均值的3倍标准差时，触发告警通知。
结果对比：系统上线后，SOC分析师每天节省约1.5小时的报表整理时间。上线第一周即发现周三凌晨2点-3点存在告警突增（正常50条/小时，突增至400条/小时），经排查为内部扫描器误配置导致，而非真实攻击。
风险与代价：初期数据管道不稳定，出现过Logstash消费积压导致数据延迟30分钟的情况。团队增加了Kafka消息队列作为缓冲，并设置了数据延迟监控。
复盘经验：时间戳统一是安全数据预处理中最容易出错但影响最大的环节；告警去重必须基于业务语义（同一攻击行为的多次告警应归并），而非简单按告警ID去重。