安全运营中心(SOC)建设实战：从SIEM到威胁狩猎全流程指南

小新讲网安2026-08-15 13:18

**【合规声明】**本文内容仅供安全运营中心建设学习与研究使用，所有配置示例和查询语句均基于公开技术文档编写。在实际生产环境中部署时，请根据企业实际安全策略和合规要求进行调整，并确保获得相应授权。文中提及的商业产品仅作技术对比，不代表任何推荐立场。
**【提示】**本文是一篇超长篇SOC建设全流程指南，涵盖SIEM平台搭建、日志采集、告警规则开发、SOAR自动化编排、威胁情报集成、威胁狩猎等完整体系内容，建议收藏后分章节阅读。

一、SOC概述与建设规划

1.1 SOC定义与核心功能

安全运营中心（Security Operations Center，简称SOC）是企业安全防御体系的中枢神经，通过集中化的安全监控、威胁检测、事件分析、应急响应和恢复能力，实现对安全事件的7x24小时全天候运营管理。SOC不是一个简单的工具或平台，而是"人+流程+技术"三位一体的安全运营体系。

SOC的五大核心功能详解：

监控（Monitoring）：

7x24小时不间断监控企业全网安全态势，包括终端、网络、应用、云平台等所有IT资产。通过SIEM平台实时收集和分析安全日志，通过安全仪表盘可视化展示整体安全状况。监控范围涵盖入侵检测告警、异常行为事件、系统漏洞状态、合规基线偏离等。监控分析师需要实时关注告警队列，确保不遗漏任何高危事件。

检测（Detection）：

基于安全规则、威胁情报、行为分析等多种技术手段，从海量日志中识别真实安全威胁。检测能力是SOC的核心竞争力，包括基于签名的已知威胁检测、基于行为分析的异常检测、基于机器学习的UEBA用户实体行为分析、基于威胁情报的IOC匹配检测等。检测规则的覆盖率和准确率直接决定了SOC的防护效果。

分析（Analysis）：

对检测到的安全事件进行深入调查和分析，还原攻击链路，评估影响范围，确定事件严重等级。分析工作需要综合多源日志关联、威胁情报查询、攻击技术映射（ATT&CK框架）、历史事件对比等手段。L2事件分析师需要具备扎实的安全知识储备，能够从碎片化告警中还原完整攻击故事。

响应（Response）：

针对确认的安全事件启动应急响应流程，采取遏制、根除、恢复等处置措施。响应动作包括隔离受感染主机、封禁恶意IP、停用被盗用账号、清除恶意文件、恢复系统服务等。SOAR平台可以实现部分响应动作的自动化执行，大幅缩短响应时间。

恢复（Recovery）：

在事件处置完成后，进行系统恢复、业务连续性保障、事后复盘总结。恢复阶段还包括检测规则优化、防护策略调整、安全意识培训等改进措施，形成安全运营的持续改进闭环。

1.2 SOC成熟度模型

SOC的建设是一个循序渐进的过程，业界通常将SOC成熟度划分为四个级别：

成熟度级别 名称 核心能力 典型特征 建设重点
Level 1 响应型(Reactive) 基础监控与被动响应 依赖告警驱动，人工分析为主，响应速度慢 SIEM基础平台搭建、日志采集覆盖、基础告警规则
Level 2 主动型(Proactive) 主动检测与威胁狩猎 建立检测规则体系，开展威胁狩猎，引入威胁情报 检测规则开发、威胁情报集成、SOAR自动化编排
Level 3 预测型(Predictive) 预测分析与行为建模 UEBA行为分析、机器学习检测、预测性告警 大数据分析平台、ML/AI检测模型、行为基线建模
Level 4 自适应型(Adaptive) 自适应防御与自动响应 全自动化检测响应、自适应防护策略、持续自优化 AI驱动安全运营、自适应安全架构、全流程自动化

**【注意】**大多数企业的SOC建设从Level 1起步，通常需要2-3年时间达到Level 2水平。不要盲目追求高成熟度，应根据企业实际安全需求和资源投入制定合理的成熟度目标。

1.3 SOC组织架构

一个成熟的SOC团队通常采用分层架构，各层级职责明确、协同配合：

角色 层级 核心职责 关键技能要求 人员配比建议
SOC Manager 管理层 团队管理、运营指标监控、资源协调、汇报沟通 安全管理经验、项目管理、沟通能力、安全行业认知 1人
Tier1 L1监控分析师 一线 告警分诊、初步研判、工单创建、升级转发 安全基础、日志分析、SIEM操作、告警分类 占分析师40%
Tier2 L2事件分析师 二线 深度调查、事件分析、影响评估、响应建议 攻击技术理解、多源日志关联、ATT&CK框架、取证基础 占分析师30%
Tier3 L3威胁狩猎师 三线 威胁狩猎、高级检测规则开发、APT追踪 深度攻防技术、威胁情报分析、大数据查询、逆向基础 占分析师15%
DFIR数字取证 专项 数字取证、恶意软件分析、事件调查 取证工具(Forensic Toolkit/EnCase)、内存分析、逆向工程 占分析师10%
SOC Engineer平台工程师 支撑 SIEM/SOAR平台运维、日志管道开发、规则部署 ELK/Splunk运维、Logstash配置、Python开发、系统运维 占分析师5%

**【提示】**对于中小型企业，可以采用一人多岗的模式。L1和L2可以合并为安全运营分析师，L3和DFIR可以由安全研究工程师兼任。关键是明确职责边界和升级流程。

1.4 SOC建设路线图

SOC建设通常分为四个阶段，每个阶段约6-12个月：

建设阶段 时间周期 核心目标 关键里程碑 交付物
Phase1 基础设施搭建 1-6月 搭建SIEM平台，实现基础日志采集与监控 SIEM平台上线、核心日志源接入、安全仪表盘就绪 SIEM架构文档、日志接入清单、监控仪表盘
Phase2 日志接入与规则开发 3-9月 扩展日志覆盖，开发检测规则体系 覆盖ATT&CK Top10技术、告警规则上线、处置流程建立 检测规则库、告警处置SOP、规则覆盖矩阵
Phase3 自动化与编排 6-12月 部署SOAR平台，实现自动化响应 SOAR上线、关键场景Playbook开发、威胁情报集成 Playbook剧本库、自动化响应流程、情报集成方案
Phase4 威胁狩猎与情报融合 9-18月 建立威胁狩猎能力，深度集成威胁情报 狩猎流程建立、情报平台上线、UEBA部署 狩猎手册、情报平台、行为分析模型

**【注意】**各阶段存在重叠，不是严格的瀑布模式。Phase1的SIEM搭建可以与Phase2的规则开发同步推进，Phase3的SOAR部署也可以与Phase4的威胁狩猎并行。

1.5 SOC vs SOAR vs SIEM概念区分

很多初学者容易混淆SOC、SOAR、SIEM三个概念，以下对比表帮助理清三者关系：

维度 SOC SIEM SOAR
概念定位 安全运营中心（组织+流程+技术体系） 安全信息与事件管理（技术平台） 安全编排自动化与响应（技术平台）
核心功能 监控、检测、分析、响应、恢复 日志采集、关联分析、告警生成、报表展示 剧本编排、自动化响应、案例管理、协同工作
关系定位 整体安全运营体系 SOC的核心技术平台之一 SOC的自动化能力增强平台
依赖关系 包含SIEM和SOAR作为技术支撑 独立运行，为SOC提供检测能力 依赖SIEM告警触发，增强SOC响应能力
典型产品 无（是体系不是产品） Splunk ES、QRadar、ELK、Sentinel Splunk SOAR、XSOAR、TheHive、Shuffle

**【提示】**简单理解：SOC是"安全运营中心"这个整体概念，SIEM是SOC用来"发现问题的眼睛"，SOAR是SOC用来"自动解决问题的手"。SOC = 人 + 流程 + SIEM + SOAR + 威胁情报 + 威胁狩猎。

二、SIEM平台建设

2.1 SIEM核心架构

SIEM（Security Information and Event Management）是SOC的核心技术平台，其架构通常分为五层：

第一层：日志采集层（Data Collection Layer）

负责从各种数据源采集日志数据。采集方式包括Agent采集（如Filebeat、Winlogbeat）、无Agent采集（如Syslog、API拉取）、网络镜像（如NetFlow、PCAP）。采集层需要支持多种协议（Syslog、HTTP、Kafka、File、TCP/UDP）和数据格式（JSON、XML、CSV、CEF、LEEF）。

第二层：解析归一化层（Parsing & Normalization Layer）

将不同格式的原始日志解析并归一化为统一的数据模型。这一层是SIEM的关键，需要处理日志字段映射、时间戳标准化、IP地址解析、用户身份关联等。常用的解析技术包括正则表达式（Grok/Regex）、键值对解析（KV）、JSON解析、自定义解析插件等。

第三层：关联分析层（Correlation & Analytics Layer）

对归一化后的日志进行关联分析和威胁检测。分析能力包括基于规则的关联检测（Rule-based Correlation）、基于统计的异常检测（Statistical Anomaly Detection）、基于行为基线的偏差检测（Behavioral Baseline）、基于威胁情报的IOC匹配（Threat Intel Matching）。

第四层：告警层（Alerting Layer）

当关联分析检测到威胁时，生成安全告警并通知分析人员。告警层功能包括告警生成、告警分级（Critical/High/Medium/Low）、告警去重与聚合、告警通知（邮件/短信/IM/Webhook）、告警工单创建。

第五层：展示层（Presentation Layer）

通过可视化仪表盘展示安全态势和运营指标。展示层包括实时安全态势大屏、运营KPI仪表盘、事件调查界面、合规报表、威胁地图等。

2.2 开源SIEM方案对比

方案 核心功能 部署方式 优点 缺点 适用场景
ELK Stack 日志采集、搜索分析、可视化 分布式集群部署 生态丰富、扩展性强、社区活跃 需要自行开发安全功能、资源消耗大 中大型企业自定义SIEM建设
Wazuh HIDS、漏洞检测、合规审计、SIEM Agent+Server架构 开箱即用安全功能、内置合规基线 大规模部署性能瓶颈、UI功能有限 中小型企业终端安全监控
OSSEC HIDS、日志分析、文件完整性监控 Agent+Server架构 轻量级、跨平台、规则丰富 UI简陋、分布式能力弱 小型企业主机入侵检测
AlienVault OSSIM SIEM、资产发现、漏洞扫描 一体化设备部署 功能集成度高、开箱即用 开源版功能受限、扩展性一般 中小型企业一体化安全
Sigma 检测规则通用格式标准 规则库（非平台） 规则跨平台通用、社区规则丰富 本身不是SIEM、需配合其他平台 检测规则开发与管理

**【提示】**对于预算有限的中小企业，推荐ELK Stack + Wazuh + Sigma的组合方案：ELK作为SIEM核心平台，Wazuh提供终端HIDS能力，Sigma统一管理检测规则。

2.3 商业SIEM方案对比

方案 核心功能 价格区间 部署方式 优点 缺点
Splunk ES SIEM+UEBA+威胁情报 高（按数据量计费，百万级/年起） 本地/SaaS 搜索引擎强大、生态完善、SPL灵活 价格昂贵、资源消耗大
IBM QRadar SIEM+UEBA+威胁情报 中高（按EPS计费） 本地/SaaS 关联分析强、内置合规报表 部署复杂、学习曲线陡
Micro Focus ArcSight SIEM+日志管理 中高（按设备数计费） 本地部署 企业级稳定性、合规支持强 界面老旧、扩展性一般
Microsoft Sentinel 云原生SIEM+SOAR 中（按数据量计费） SaaS(云原生) 云原生免运维、与Azure深度集成 强绑定Azure生态、本地部署不支持
Datadog SIEM 云安全监控+SIEM 中（按主机/事件计费） SaaS 云原生部署快、APM集成好 安全功能深度不足、定制化弱

**【注意】**商业SIEM方案选型时，除了功能对比，还需要重点关注：数据量计费模式（按EPS/GB/主机）、总拥有成本TCO、与现有IT基础设施的集成度、技术支持响应速度。

2.4 ELK Stack作为SIEM平台搭建实战

2.4.1 Elasticsearch集群部署

Elasticsearch是ELK Stack的核心搜索引擎，集群部署时需要合理配置以下elasticsearch.yml关键参数：

参数 说明 推荐值 备注
cluster.name 集群名称 soc-elk-cluster 所有节点必须一致
node.name 节点名称 node-1/node-2/node-3 每个节点唯一
node.roles 节点角色 master/data/ingest 生产环境建议角色分离
network.host 监听地址 0.0.0.0或内网IP 不建议暴露公网
http.port HTTP端口 9200 REST API端口
transport.port 传输端口 9300 节点间通信端口
discovery.seed_hosts 种子节点列表 "10.0.1.11","10.0.1.12" 用于集群发现
cluster.initial_master_nodes 初始主节点 "node-1","node-2","node-3" 仅首次启动使用
path.data 数据存储路径 /data/elasticsearch 建议SSD存储
path.logs 日志存储路径 /var/log/elasticsearch -
xpack.security.enabled 安全认证 true 生产环境必须开启

elasticsearch.yml配置示例：

复制代码 
cluster.name: soc-elk-cluster
node.name: node-1
node.roles: [master, data, ingest]
network.host: 0.0.0.0
http.port: 9200
transport.port: 9300
discovery.seed_hosts: ["10.0.1.11", "10.0.1.12", "10.0.1.13"]
cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]
path.data: /data/elasticsearch
path.logs: /var/log/elasticsearch
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12

JVM堆内存配置（jvm.options）：

复制代码 
-Xms16g
-Xmx16g

**【提示】**JVM堆内存建议设置为物理内存的50%，且不超过32GB（以启用指针压缩）。例如64GB内存的服务器，设置-Xms31g -Xmx31g。

2.4.2 Logstash日志解析管道配置

Logstash负责日志的解析和归一化处理，配置文件分为input、filter、output三段。

完整的Logstash配置示例（解析Syslog/Windows EventLog/Nginx日志）：

复制代码 
input {
beats {
port => 5044
type => "beats"
}
tcp {
port => 514
type => "syslog"
}
}

filter {
if [type] == "syslog" {
grok {
match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
add_field => [ "received_at", "%{@timestamp}" ]
add_field => [ "received_from", "%{host}" ]
}
date {
match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
}
}

if [type] == "wineventlog" {
mutate {
rename => {
"winlog.channel" => "event_log"
"winlog.event_id" => "event_id"
"winlog.task_name" => "task_name"
}
}
if [event_id] == "4624" {
mutate {
add_field => { "event_type" => "login_success" }
}
}
if [event_id] == "4625" {
mutate {
add_field => { "event_type" => "login_failure" }
}
}
}

if [type] == "nginx_access" {
grok {
match => { "message" => "%{IPORHOST:client_ip} - %{DATA:user_name} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{URIPATHPARAM:request_uri} HTTP/%{NUMBER:http_version}" %{NUMBER:status_code} %{NUMBER:bytes_sent} "%{DATA:referer}" "%{DATA:user_agent}"" }
}
geoip {
source => "client_ip"
target => "geoip"
}
useragent {
source => "user_agent"
target => "ua"
}
}
}

output {
if [type] == "syslog" {
elasticsearch {
hosts => ["https://10.0.1.11:9200"]
index => "syslog-%{+YYYY.MM.dd}"
user => "elastic"
password => "${ELASTIC_PASSWORD}"
ssl_certificate_verification => false
}
}
if [type] == "wineventlog" {
elasticsearch {
hosts => ["https://10.0.1.11:9200"]
index => "wineventlog-%{+YYYY.MM.dd}"
user => "elastic"
password => "${ELASTIC_PASSWORD}"
ssl_certificate_verification => false
}
}
if [type] == "nginx_access" {
elasticsearch {
hosts => ["https://10.0.1.11:9200"]
index => "nginx-access-%{+YYYY.MM.dd}"
user => "elastic"
password => "${ELASTIC_PASSWORD}"
ssl_certificate_verification => false
}
}
}

**【注意】**Grok正则解析是Logstash中最消耗CPU资源的环节。对于高吞吐场景，建议在Filebeat端使用Ingest Node Pipeline进行解析，减轻Logstash压力。

2.4.3 Kibana安全仪表盘配置

Kibana安全仪表盘是SOC分析师日常工作的核心界面，以下为配置步骤：

步骤1：创建Index Pattern

进入Kibana -> Stack Management -> Index Patterns，创建如下索引模式：

  • syslog-*（系统日志）
  • wineventlog-*（Windows事件日志）
  • nginx-access-*（Nginx访问日志）

步骤2：创建可视化图表

根据安全监控需求，创建以下可视化图表：

图表名称 可视化类型 数据源 用途
登录失败趋势 Line Chart wineventlog-* 监控暴力破解趋势
TOP10源IP告警 Bar Chart syslog-* 识别高频告警源IP
事件类型分布 Pie Chart wineventlog-* 安全事件分类统计
地理位置分布 Map/Coordinate Map nginx-access-* 访问来源地理位置
实时告警列表 Data Table 所有索引 实时告警展示
系统安全态势 Gauge wineventlog-* 安全状态评分

步骤3：创建Dashboard仪表盘

将上述可视化图表组合到Dashboard中，创建以下仪表盘：

  • 安全运营总览仪表盘（综合展示所有关键指标）
  • Windows安全监控仪表盘（专注Windows事件分析）
  • 网络流量安全仪表盘（专注网络层日志分析）
  • 合规审计仪表盘（专注合规相关事件）

步骤4：配置告警规则（Elastic Alerting）

复制代码 
PUT _api/detection_engine/rules
{
"name": "Windows登录失败暴力破解检测",
"description": "5分钟内同一源IP登录失败超过20次",
"risk_score": 75,
"severity": "high",
"type": "threshold",
"query": "event.action:\"logged-in\" AND event.outcome:\"failure\"",
"threshold": {
"field": "source.ip",
"value": 20
},
"time_window": "5m",
"actions": [
{
"type": "email",
"to": ["soc-alert@company.com"],
"subject": "检测到暴力破解攻击: {{context.source_ip}}"
}
]
}
2.4.4 Winlogbeat/Filebeat/Metricbeat采集器配置

Winlogbeat配置（Windows安全日志采集）：

复制代码 
winlogbeat.event_logs:
- name: Security
id: security
tags: ["windows_security"]
processors:
- drop_event:
when:
or:
- equals.winlog.event_id: 4688
- equals.winlog.event_id: 4624
- equals.winlog.event_id: 4625
- name: System
id: system
tags: ["windows_system"]
- name: Application
id: application
tags: ["windows_application"]
- name: Microsoft-Windows-Sysmon/Operational
id: sysmon
tags: ["sysmon"]

output.logstash:
hosts: ["10.0.1.20:5044"]
ssl.certificate_authorities: ["/etc/pki/tls/certs/logstash.crt"]
ssl.certificate: "/etc/pki/tls/certs/winlogbeat.crt"
ssl.key: "/etc/pki/tls/private/winlogbeat.key"

logging.level: info
logging.to_files: true
logging.files:
path: C:/ProgramData/winlogbeat/Logs
name: winlogbeat

Filebeat配置（Nginx访问日志采集）：

复制代码 
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/nginx/access.log
tags: ["nginx_access"]
fields:
log_type: nginx_access
fields_under_root: true
multiline.pattern: '^\d{4}-\d{2}-\d{2}'
multiline.negate: true
multiline.match: after

- type: log
enabled: true
paths:
- /var/log/nginx/error.log
tags: ["nginx_error"]
fields:
log_type: nginx_error
fields_under_root: true

output.logstash:
hosts: ["10.0.1.20:5044"]
loadbalance: true
worker: 2

logging.level: info
logging.to_files: true

Metricbeat配置（系统指标采集）：

复制代码 
metricbeat.modules:
- module: system
period: 10s
metricsets:
- cpu
- memory
- network
- process
- filesystem
processes: ['.*']
cpu.metrics: ["percentages","normalized_percentages"]
process.include_top_n:
by_cpu: 5
by_memory: 5

- module: docker
period: 10s
hosts: ["unix:///var/run/docker.sock"]

output.elasticsearch:
hosts: ["https://10.0.1.11:9200"]
username: "elastic"
password: "${ELASTIC_PASSWORD}"
ssl.verification_mode: "none"

setup.kibana:
host: "https://10.0.1.30:5601"
username: "elastic"
password: "${ELASTIC_PASSWORD}"

2.5 Splunk SIEM配置实战

2.5.1 Splunk安装与索引配置

Splunk安装完成后，需要配置indexes.conf定义索引参数：

参数 说明 推荐值 备注
homePath 热数据存储路径 $SPLUNK_DB/idx/db 建议SSD
coldPath 冷数据存储路径 $SPLUNK_DB/idx/colddb 可用HDD
thawedPath 解冻数据存储路径 $SPLUNK_DB/idx/thaweddb -
maxDataSize 热数据桶最大大小 750MB(64位) -
maxHotBuckets 最大热桶数量 3 -
maxTotalDataSizeMB 索引最大容量 5000000(约5TB) 按磁盘调整
frozenTimePeriodInSecs 数据保留时间 7776000(90天) 按合规要求调整

indexes.conf配置示例：

复制代码 
[winsecurity]
homePath = $SPLUNK_DB/winhost/db
coldPath = $SPLUNK_DB/winhost/colddb
thawedPath = $SPLUNK_DB/winhost/thaweddb
maxDataSize = 750MB
maxHotBuckets = 3
maxTotalDataSizeMB = 5000000
frozenTimePeriodInSecs = 7776000

[syslog_network]
homePath = $SPLUNK_DB/syslog/db
coldPath = $SPLUNK_DB/syslog/colddb
thawedPath = $SPLUNK_DB/syslog/thaweddb
maxDataSize = 750MB
maxTotalDataSizeMB = 5000000
frozenTimePeriodInSecs = 7776000

[nginx_access]
homePath = $SPLUNK_DB/nginx/db
coldPath = $SPLUNK_DB/nginx/colddb
thawedPath = $SPLUNK_DB/nginx/thaweddb
maxDataSize = 750MB
maxTotalDataSizeMB = 3000000
frozenTimePeriodInSecs = 2592000
2.5.2 数据源接入配置

Windows EventLog接入（通过Splunk Universal Forwarder）：

复制代码 
# inputs.conf (部署在Windows Forwarder上)
[WinEventLog://Security]
disabled = 0
index = winsecurity
sourcetype = WinEventLog:Security
renderXml = true
checkpointInterval = 5

[WinEventLog://System]
disabled = 0
index = winsystem
sourcetype = WinEventLog:System

[WinEventLog://Application]
disabled = 0
index = winapp
sourcetype = WinEventLog:Application

Syslog网络设备日志接入（通过Splunk Heavy Forwarder）：

复制代码 
# inputs.conf (部署在Heavy Forwarder上)
[udp://514]
connection_host = ip
sourcetype = syslog
source = network:syslog
index = syslog_network

# transforms.conf (按设备类型路由)
[cisco_asa]
REGEX = %ASA-
FORMAT = sourcetype::cisco:asa
DEST_KEY = MetaData:Sourcetype

[palo_alto]
REGEX = Palo Alto
FORMAT = sourcetype::pan:log
DEST_KEY = MetaData:Sourcetype
2.5.3 SPL查询语言基础

SPL（Search Processing Language）是Splunk的查询语言，以下为基本语法速查表：

命令 功能 语法示例 说明
search 基础搜索 index=winsecurity EventCode=4625 搜索指定索引和条件
stats 统计聚合 stats count by src_ip 按字段分组统计
chart 图表统计 chart count over src_ip by action 生成图表数据
timechart 时间序列 timechart count by EventCode 按时间统计趋势
eval 字段计算 eval risk=if(status="fail",1,0) 计算新字段
where 条件过滤 where count > 10 过滤计算结果
lookup 查找表 lookup threat_intel ip AS src_ip OUTPUT threat_score 关联外部数据
sort 排序 sort -count 按字段降序排列
dedup 去重 dedup src_ip 按字段去重
head 取前N条 head 100 取前100条
table 字段选择 table _time src_ip user action 选择展示字段
rename 字段重命名 rename src_ip AS "Source IP" 重命名字段
join 关联查询 join src_ip search index=threat_intel 关联子查询
rex 正则提取 rex field=message "user=(?\S+)" 正则提取字段
bucket 时间分桶 bucket _time span=1h 按时间分桶
tstats 加速统计 tstats count where index=winsecurity by host 使用TSIDX加速
2.5.4 Splunk告警配置

步骤1：创建Saved Search（保存的搜索）

复制代码 
# savedsearches.conf
[Brute Force Login Detection]
search = index=winsecurity EventCode=4625 | stats count as fail_count by src_ip | where fail_count > 20
dispatch.earliest_time = -5m
dispatch.latest_time = now
cron_schedule = */5 * * * *
alert.severity = 3
alert.suppress = 1
alert.suppress.period = 1h
alert.suppress.fields = src_ip

步骤2：配置Alert Action（告警动作）

复制代码 
# alert_actions.conf
[email_notification]
label = 发送邮件告警
description = 发送邮件通知SOC团队
python.version = python3
is_custom = 0

[webhook_notification]
label = Webhook通知
description = 发送Webhook到SOAR平台
python.version = python3
param.url = https://soar.company.com/api/v1/alerts
param.method = POST
param.content_type = application/json
param.body = {"alert_title":"$name$","severity":"$alert.severity$","src_ip":"$result.src_ip$","fail_count":"$result.fail_count$"}

步骤3：触发条件配置

  • 计划执行：每5分钟执行一次搜索
  • 触发条件：搜索结果数量大于0
  • 触发动作：发送邮件 + 调用SOAR Webhook
  • 抑制规则：同一源IP1小时内只告警一次

三、日志采集与数据源规划

3.1 关键日志数据源分类

日志是SOC的"燃料"，没有全面覆盖的日志采集，再强大的SIEM也无法发挥作用。以下是关键日志数据源分类及优先级：

日志类别 数据源 日志内容 优先级 采集方式
终端日志 Windows安全日志 登录事件(4624/4625)、进程创建(4688)、特权使用(4672)、服务创建(7045) P0-必须 Winlogbeat/Splunk UF
终端日志 Windows Sysmon 进程创建、网络连接、文件创建、注册表修改、驱动加载 P0-必须 Winlogbeat/Splunk UF
终端日志 Linux syslog/auditd 用户登录、命令执行、文件变更、权限变更 P0-必须 Filebeat/rsyslog
网络日志 防火墙日志 允许/拒绝连接、NAT转换、VPN接入 P0-必须 Syslog/NetFlow
网络日志 IDS/IPS告警 入侵检测告警、阻断记录 P0-必须 Syslog/API
网络日志 DNS查询日志 域名解析请求、响应记录 P1-重要 DNS服务器日志
网络日志 代理服务器日志 HTTP/HTTPS访问记录、URL过滤 P1-重要 Syslog/文件
应用日志 Web服务器日志 Nginx/Apache访问日志、错误日志 P0-必须 Filebeat
应用日志 数据库审计日志 登录、DDL/DML操作、权限变更 P1-重要 DB审计插件
应用日志 中间件日志 Tomcat/WebLogic/Nginx错误日志 P2-一般 Filebeat
身份认证日志 AD域控日志 登录认证、Kerberos票据、目录变更 P0-必须 Winlogbeat
身份认证日志 VPN/SSO日志 VPN接入、SSO认证、MFA验证 P1-重要 Syslog/API
云平台日志 AWS CloudTrail API调用、控制台操作、数据访问 P1-重要 AWS API/S3
云平台日志 阿里云Action Trail API调用、控制台操作 P1-重要 阿里云API
云平台日志 Azure Activity Log 资源操作、管理操作 P1-重要 Azure API
威胁情报 外部情报Feed 恶意IP、域名、文件哈希、URL P1-重要 API/STIX/TAXII

**【提示】**日志采集优先级建议：先P0后P1再P2。第一步确保所有P0级日志源接入SIEM，覆盖率达90%以上后，再逐步接入P1和P2级数据源。

3.2 Windows日志采集配置

3.2.1 Windows安全审计策略配置

通过组策略或auditpol命令配置Windows安全审计策略：

复制代码 
# 通过auditpol命令配置推荐的安全审计策略
auditpol /set /category:"账户登录" /success:enable /failure:enable
auditpol /set /category:"账户管理" /success:enable /failure:enable
auditpol /set /category:"详细追踪" /success:enable /failure:disable
auditpol /set /category:"目录服务访问" /success:enable /failure:enable
auditpol /set /category:"登录/注销" /success:enable /failure:enable
auditpol /set /category:"对象访问" /success:enable /failure:enable
auditpol /set /category:"策略更改" /success:enable /failure:enable
auditpol /set /category:"特权使用" /success:enable /failure:enable
auditpol /set /category:"系统" /success:enable /failure:enable

关键安全事件ID清单：

事件ID 事件名称 安全意义 检测用途
4624 账户成功登录 记录登录成功事件 登录行为分析、横向移动检测
4625 账户登录失败 记录登录失败事件 暴力破解检测
4634 账户注销 记录注销事件 会话追踪
4648 使用显式凭证登录 记录显式凭证使用 横向移动检测
4662 对象操作 记录AD对象操作 AD枚举检测
4672 特权账户登录 记录特权账户登录 权限提升检测
4688 进程创建 记录新进程创建 恶意进程检测
4698 计划任务创建 记录计划任务创建 持久化检测
4720 账户创建 记录新账户创建 后门账户检测
4732 成员加入安全组 记录组成员变更 权限提升检测
7045 服务创建 记录新服务创建 持久化检测
3.2.2 Sysmon安装与配置

Sysmon（System Monitor）是微软Sysinternals套件中的高级监控工具，能够记录Windows系统底层行为，是终端检测的利器。

安装命令：

复制代码 
sysmon -accepteula -i sysmon-config.xml

Sysmon配置文件（sysmon-config.xml）关键配置：

复制代码 
<Sysmon schemaversion="4.82">
<HashAlgorithms>SHA256</HashAlgorithms>

<EventFiltering>
<!-- 进程创建 -->
<ProcessCreate onmatch="include">
<!-- 监控可疑命令行 -->
<CommandLine condition="contains">powershell.exe -enc</CommandLine>
<CommandLine condition="contains">cmd.exe /c</CommandLine>
<CommandLine condition="contains">rundll32.exe</CommandLine>
<CommandLine condition="contains">certutil.exe</CommandLine>
<!-- 监控可疑进程名称 -->
<Image condition="end with">.scr</Image>
<Image condition="end with">psexec.exe</Image>
</ProcessCreate>

<!-- 网络连接 -->
<NetworkConnect onmatch="include">
<!-- 监控异常端口连接 -->
<DestinationPort condition="is">4444</DestinationPort>
<DestinationPort condition="is">6667</DestinationPort>
<DestinationPort condition="is">9001</DestinationPort>
<!-- 监控PowerShell网络连接 -->
<Image condition="end with">powershell.exe</Image>
</NetworkConnect>

<!-- 文件创建时间修改 -->
<FileCreateTime onmatch="include">
<Image condition="end with">powershell.exe</Image>
</FileCreateTime>

<!-- 驱动加载 -->
<DriverLoad onmatch="include">
<Signature condition="is">null</Signature>
</DriverLoad>

<!-- 注册表修改 -->
<RegistryEvent onmatch="include">
<TargetObject condition="contains">CurrentVersion\Run</TargetObject>
<TargetObject condition="contains">CurrentVersion\Explorer\Shell Folders</TargetObject>
<TargetObject condition="contains">Services\</TargetObject>
</RegistryEvent>

<!-- 文件创建 -->
<FileCreate onmatch="include">
<TargetFilename condition="contains">.dll</TargetFilename>
<TargetFilename condition="contains">.exe</TargetFilename>
<TargetFilename condition="contains">Startup</TargetFilename>
</FileCreate>
</EventFiltering>
</Sysmon>
3.2.3 Windows Forwarded Events集中转发

在企业环境中，可以通过Windows事件转发（WEF）将所有终端的安全日志集中转发到日志收集服务器：

复制代码 
# 在日志收集服务器上配置WEF订阅
wecutil qc -q

# 创建订阅（订阅配置XML）
wecutil cs subscription.xml

# subscription.xml示例
<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
<SubscriptionId>SOC-SecurityLog-Forwarding</SubscriptionId>
<SubscriptionType>SourceInitiated</SubscriptionType>
<Description>转发安全日志到SOC收集服务器</Description>
<Enabled>true</Enabled>
<Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
<ConfigurationMode>Custom</ConfigurationMode>
<Delivery>
<Batching>
<MaxItems>5000</MaxItems>
<MaxLatencyTime>900000</MaxLatencyTime>
</Batching>
</Delivery>
<Query>
<![CDATA[
<QueryList>
<Query Path="Security">
<Select Path="Security">*</Select>
</Query>
<Query Path="Microsoft-Windows-Sysmon/Operational">
<Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>
</Query>
</QueryList>
]]>
</Query>
<ReadExistingEvents>true</ReadExistingEvents>
</Subscription>

**【注意】**Windows Forwarded Events适合小规模环境（<500台终端），大规模环境建议使用Winlogbeat或Splunk Universal Forwarder直接转发到SIEM。

3.3 Linux日志采集配置

3.3.1 rsyslog配置

rsyslog是Linux系统默认的日志服务，配置文件位于/etc/rsyslog.conf或/etc/rsyslog.d/目录下：

复制代码 
# /etc/rsyslog.d/00-soc-forwarding.conf
# 将安全相关日志转发到SOC SIEM服务器

# 认证日志
auth,authpriv.* @@10.0.1.20:514

# 内核日志
kern.* @@10.0.1.20:514

# 所有日志（按需启用）
*.* @@10.0.1.20:514

# 使用TCP协议（@@表示TCP，@表示UDP）
# TCP更可靠但消耗更多资源，UDP更快但可能丢日志

# 配置日志格式为JSON（便于SIEM解析）
template(name="json-soc" type="list" option.jsonf="on") {
property(outname="timestamp" name="timereported" dateFormat="rfc3339" format="jsonf")
property(outname="host" name="hostname" format="jsonf")
property(outname="severity" name="syslogseverity-text" format="jsonf")
property(outname="facility" name="syslogfacility-text" format="jsonf")
property(outname="program" name="programname" format="jsonf")
property(outname="message" name="msg" format="jsonf")
}

# 使用JSON格式转发
auth,authpriv.* action(type="omfwd" target="10.0.1.20" port="514" protocol="tcp" template="json-soc")
3.3.2 auditd规则配置

auditd是Linux系统的高级审计框架，能够监控文件访问、系统调用、权限变更等：

复制代码 
# /etc/audit/rules.d/soc-audit.rules

# 删除已有规则
-D

# 设置缓冲区
-b 8192

# 监控用户/组文件变更
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k identity

# 监控SSH配置变更
-w /etc/ssh/sshd_config -p wa -k ssh_config

# 监控Cron配置
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron

# 监控系统启动脚本
-w /etc/init.d/ -p wa -k init
-w /etc/systemd/ -p wa -k systemd

# 监控网络配置
-w /etc/hosts -p wa -k network
-w /etc/resolv.conf -p wa -k network
-w /etc/sysconfig/network -p wa -k network

# 监控命令执行
-a always,exit -F arch=b64 -S execve -k cmd_execution

# 监控文件删除
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rmdir -k file_delete

# 监控权限变更
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -k perm_change

# 监控用户切换
-a always,exit -F arch=b64 -S setuid -S setgid -k privilege_escalation

# 锁定规则（防止篡改）
-e 2
3.3.3 journald日志配置

对于使用systemd的Linux系统，journald是默认的日志收集器：

复制代码 
# /etc/systemd/journald.conf
[Journal]
Storage=persistent
Compress=yes
Seal=yes
SplitMode=uid
RateLimitInterval=30s
RateLimitBurst=10000
SystemMaxUse=10G
SystemMaxFileSize=200M
MaxRetentionSec=6month
ForwardToSyslog=yes
MaxLevelStore=info
MaxLevelSyslog=info

3.4 网络设备日志采集

3.4.1 Cisco交换机/路由器Syslog配置
复制代码 
# Cisco IOS Syslog配置
configure terminal
! 配置Syslog服务器地址
logging host 10.0.1.20
! 设置日志级别
logging trap informational
! 设置日志源接口
logging source-interface Loopback0
! 启用时间戳
service timestamps log datetime msec localtime show-timezone
! 启用序列号
service sequence-numbers
! 启用日志缓冲区
logging buffered 16384 informational
exit
write memory
3.4.2 防火墙Syslog配置
复制代码 
# Palo Alto Firewall Syslog配置
set deviceconfig system log-export-schedule traffic-interval 5
set shared log-settings syslog soc-siem
set shared log-settings syslog soc-siem server siem-server address 10.0.1.20
set shared log-settings syslog soc-siem server siem-server port 514
set shared log-settings syslog soc-siem server siem-server transport UDP
set shared log-settings syslog soc-siem server siem-server format BSD
set shared log-settings syslog soc-siem traffic severity informational
set shared log-settings syslog soc-siem threat severity informational
set shared log-settings syslog soc-siem system severity informational
commit

# iptables/nftables日志配置
# 将防火墙日志发送到syslog
iptables -A INPUT -j LOG --log-prefix "IPTABLES-INPUT: " --log-level 4
iptables -A FORWARD -j LOG --log-prefix "IPTABLES-FORWARD: " --log-level 4
iptables -A OUTPUT -j LOG --log-prefix "IPTABLES-OUTPUT: " --log-level 4

# /etc/rsyslog.d/10-iptables.conf
:msg, contains, "IPTABLES-" @@10.0.1.20:514
& stop

3.5 云平台日志采集

3.5.1 AWS CloudTrail日志采集
复制代码 
# AWS CLI创建CloudTrail并配置日志投递到S3
aws cloudtrail create-trail \
--name soc-cloudtrail \
--s3-bucket-name soc-cloudtrail-logs \
--s3-key-prefix cloudtrail \
--is-multi-region-trail \
--include-global-service-events \
--enable-log-file-validation

# 启动日志记录
aws cloudtrail start-logging --name soc-cloudtrail

# 配置S3事件通知到Lambda（转发到SIEM）
aws s3api put-bucket-notification-configuration \
--bucket soc-cloudtrail-logs \
--notification-configuration file://s3-notification.json

# s3-notification.json
{
"LambdaFunctionConfigurations": [
{
"LambdaFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:cloudtrail-to-siem",
"Events": ["s3:ObjectCreated:*"],
"Filter": {
"Prefix": "cloudtrail/",
"Suffix": ".json.gz"
}
}
]
}
3.5.2 阿里云Action Trail日志采集
复制代码 
# 通过阿里云CLI创建操作审计追踪
aliyun actiontrail CreateTrail \
--Name soc-actiontrail \
--SlsProjectName soc-siem-project \
--SlsWriteRoleArn acs:ram::1234567890123:role/aliyunserviceroleforactiontrail \
--EventRW All \
--IsOrganizationTrail false

# 启动追踪
aliyun actiontrail StartLogging --Name soc-actiontrail
3.5.3 Azure Activity Log采集
json 复制代码 
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"type": "Microsoft.Insights/diagnosticSettings",
"apiVersion": "2017-05-01-preview",
"name": "soc-activity-log",
"properties": {
"workspaceId": "/subscriptions/xxx/resourceGroups/soc-rg/providers/Microsoft.OperationalInsights/workspaces/soc-loganalytics",
"logs": [
{
"category": "Administrative",
"enabled": true
},
{
"category": "Security",
"enabled": true
},
{
"category": "ServiceHealth",
"enabled": true
},
{
"category": "Alert",
"enabled": true
},
{
"category": "Recommendation",
"enabled": true
},
{
"category": "Policy",
"enabled": true
},
{
"category": "Autoscale",
"enabled": true
}
]
}
}
]
}

3.6 日志标准化与归一化

不同设备和应用产生的日志格式各异，SIEM需要将它们归一化为统一格式才能进行关联分析。

日志格式统一字段映射表：

统一字段 描述 Windows EventLog源字段 Syslog源字段 Nginx源字段
timestamp 事件时间 TimeCreated timestamp time_local
src_ip 源IP IpAddress host remote_addr
dst_ip 目标IP IpPort - -
user 用户名 TargetUserName - -
host 主机名 ComputerName hostname -
event_id 事件ID EventID - -
action 动作 - message method
status 状态 - severity status
process 进程名 ProcessName program -
bytes 字节数 - - bytes_sent

常见日志格式对比表：

格式 全称 使用厂商 格式示例 优点 缺点
CEF Common Event Format Micro Focus ArcSight CEF:0 Vendor Product
LEEF Log Event Extended Format IBM QRadar LEEF:1.0 Vendor Product
JSON JavaScript Object Notation 通用/现代SIEM {"timestamp":"2024-01-01T00:00:00Z","src_ip":"1.2.3.4",...} 结构化、易解析、通用 体积较大
Syslog Syslog Protocol 网络设备/Linux <134>Jan 1 00:00:00 host program: message 标准协议、广泛支持 非结构化、解析困难
Key-Value 键值对格式 多种厂商 time=2024-01-01 src=1.2.3.4 dst=5.6.7.8 action=allow 简单直观 缺乏标准

3.7 日志保留策略建议

日志类型 合规要求 运营需求 推荐保留期限 存储介质建议
Windows安全日志 180天(等保2.0) 90天热数据 180天 90天SSD + 90天HDD
网络设备日志 180天(等保2.0) 90天热数据 180天 90天SSD + 90天HDD
Web应用日志 90天 30天热数据 90天 30天SSD + 60天HDD
数据库审计日志 365天(金融) 180天热数据 365天 180天SSD + 185天HDD
云平台日志 180天 90天热数据 180天 90天SSD + 90天HDD
邮件日志 90天 30天热数据 90天 30天SSD + 60天HDD
VPN/认证日志 180天 90天热数据 180天 90天SSD + 90天HDD

**【警告】**日志保留策略必须满足企业适用的法律法规和行业标准要求。等保2.0要求日志至少保留6个月，金融行业PCI-DSS要求审计日志保留1年。请在制定保留策略前咨询合规部门。

四、安全告警规则开发

4.1 告警规则开发方法论

高质量的检测规则是SOC有效运营的基础。基于ATT&CK技术的检测规则开发流程如下：

步骤1：选择ATT&CK技术

从MITRE ATT&CK框架中选择需要覆盖的攻击技术。建议优先覆盖ATT&CK Top 10技术，包括：T1059命令与脚本解释器、T1053计划任务/作业、T1543创建或修改系统进程、T1003操作系统凭据转储、T1071应用层协议、T1055进程注入、T1218系统二进制代理执行、T1048通过替代协议外传数据、T1098账户操纵、T1547引导或登录自动启动执行。

步骤2：分析数据源

确定检测该技术需要哪些日志数据源。例如检测T1059命令与脚本解释器需要Windows安全日志4688（进程创建）+ Sysmon进程创建事件（EventID 1）+ PowerShell脚本块日志（EventID 4104）。

步骤3：编写检测查询

基于选定的数据源编写检测查询。查询逻辑需要考虑：攻击者使用该技术的典型行为特征、正常用户可能产生的类似行为（误报来源）、如何区分恶意与正常行为。

步骤4：验证测试

在测试环境中模拟攻击行为，验证检测规则是否能够正确触发。同时运行正常业务操作，检查是否产生误报。建议使用原子红队（Atomic Red Team）测试框架进行模拟攻击验证。

步骤5：调优上线

根据测试结果调整检测逻辑、阈值参数、白名单配置。调优完成后部署到生产环境，设置试运行期（通常2周），持续监控告警情况并进一步优化。

4.2 Sigma规则编写实战

4.2.1 Sigma规则语法详解

Sigma是一种通用的检测规则签名格式，类似于网络入侵检测中的Snort规则，但用于日志事件检测。Sigma规则使用YAML格式编写，可以转换为各种SIEM平台的原生查询语言。

字段 说明 示例 是否必须
title 规则标题 Brute Force Login Detection 是
id 规则唯一ID(UUID) f3e2a1b0-... 否(建议添加)
status 规则状态 experimental/testing/stable 否
description 规则描述 检测5分钟内20次以上登录失败 是
author 作者 SOC Team 否
date 创建日期 2024/01/01 否
references 参考链接 "https://attack.mitre.org/..." 否
tags ATT&CK标签 attack.t1110, attack.credential_access 否
logsource 日志源定义 product: windows, service: security 是
detection 检测条件 selection + condition 是
falsepositives 误报说明 密码过期、用户忘记密码 否
level 严重级别 low/medium/high/critical 否
4.2.2 Sigma规则示例

示例1：检测4625登录失败爆破

复制代码 
title: Windows登录失败暴力破解检测
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: 检测5分钟内同一源IP产生20次以上Windows登录失败事件(4625)
author: SOC Team
date: 2024/01/15
references:
- https://attack.mitre.org/techniques/T1110/001/
tags:
- attack.credential_access
- attack.t1110
- attack.t1110.001
logsource:
product: windows
service: security
detection:
selection:
EventID: 4625
timeframe: 5m
condition: selection | count() by IpAddress > 20
falsepositives:
- 用户忘记密码多次尝试
- 密码过期后多次尝试
- 应用程序配置错误导致认证失败
level: medium

示例2：检测4688可疑进程创建

复制代码 
title: 检测可疑进程创建行为
id: b2c3d4e5-f6a7-8901-bcde-f23456789012
status: stable
description: 检测通过4688事件识别的可疑进程创建行为，包括可疑命令行参数和可疑进程名称
author: SOC Team
date: 2024/01/15
references:
- https://attack.mitre.org/techniques/T1059/
tags:
- attack.execution
- attack.t1059
- attack.t1059.001
- attack.t1059.003
logsource:
product: windows
service: security
detection:
selection_event:
EventID: 4688
selection_suspicious_cmd:
CommandLine|contains:
- 'powershell.exe -enc'
- 'powershell.exe -ExecutionPolicy Bypass'
- 'cmd.exe /c'
- 'certutil.exe -urlcache'
- 'rundll32.exe'
- 'mshta.exe'
- 'regsvr32.exe /s /u /i:'
selection_suspicious_proc:
NewProcessName|endswith:
- '.scr'
- 'psexec.exe'
- 'procdump.exe'
- 'mimikatz.exe'
condition: selection_event and (selection_suspicious_cmd or selection_suspicious_proc)
falsepositives:
- 管理员合法使用PowerShell
- 合法软件使用rundll32加载DLL
level: high

示例3：检测PowerShell EncodedCommand

复制代码 
title: 检测PowerShell编码命令执行
id: c3d4e5f6-a7b8-9012-cdef-345678901234
status: stable
description: 检测使用Base64编码参数执行PowerShell命令的行为，这是攻击者常用的混淆技术
author: SOC Team
date: 2024/01/15
references:
- https://attack.mitre.org/techniques/T1027/
- https://attack.mitre.org/techniques/T1059/001/
tags:
- attack.execution
- attack.t1059
- attack.t1059.001
- attack.t1027
- attack.defense_evasion
logsource:
product: windows
service: powershell
detection:
selection:
EventID: 4104
ScriptBlockText|contains|all:
- 'FromBase64String'
selection_encoded:
CommandLine|contains:
- '-EncodedCommand'
- '-enc '
- '-e '
condition: selection or selection_encoded
falsepositives:
- 部分合法管理脚本使用编码命令
- 部分软件安装脚本使用Base64编码
level: high
4.2.3 Sigma规则转换

使用sigmac工具将Sigma规则转换为不同SIEM平台的查询语言：

复制代码 
# 安装sigmac
pip3 install pysigma
git clone https://github.com/SigmaHQ/sigma.git
cd sigma

# 转换为Splunk SPL
python3 tools/sigmac -t splunk -c splunk-windows rules/windows/builtin/security/win_security_brute_force_login.yml

# 转换为Elastic KQL
python3 tools/sigmac -t kibana -c winlogbeat rules/windows/builtin/security/win_security_brute_force_login.yml

# 转换为Elasticsearch Lucene查询
python3 tools/sigmac -t es-qs -c winlogbeat rules/windows/builtin/security/win_security_brute_force_login.yml

# 转换为Microsoft Sentinel KQL
python3 tools/sigmac -t ala -c ala rules/windows/builtin/security/win_security_brute_force_login.yml

# 批量转换所有规则
python3 tools/sigmac -t splunk -c splunk-windows -o splunk_rules/ rules/windows/

# 转换为Sigma JSON格式（用于API导入）
python3 tools/sigmac -t sigma -c winlogbeat rules/windows/builtin/security/win_security_brute_force_login.yml

**【提示】**sigmac是Sigma官方提供的转换工具，支持超过20种SIEM平台的输出格式。建议将所有Sigma规则统一存储在Git仓库中，通过CI/CD流水线自动转换和部署到各SIEM平台。

4.3 Splunk SPL检测查询示例

4.3.1 检测暴力破解
复制代码 
# 检测同一源IP在5分钟内登录失败超过20次
index=winsecurity EventCode=4625
| bucket _time span=5m
| stats count as fail_count, values(user) as targeted_users by src_ip, _time
| where fail_count > 20
| eval severity=if(fail_count > 50, "critical", "high")
| table _time src_ip fail_count targeted_users severity
| sort -fail_count
4.3.2 检测横向移动
复制代码 
# 检测Type3网络登录后紧接可疑进程创建（横向移动+执行）
index=winsecurity (EventCode=4624 LogonType=3) OR (EventCode=4688)
| transaction host maxspan=5m startswith=(EventCode=4624 LogonType=3) endswith=(EventCode=4688)
| search NewProcessName="*\\cmd.exe" OR NewProcessName="*\\powershell.exe" OR NewProcessName="*\\psexec.exe"
| table _time host src_ip user NewProcessName CommandLine
| sort -_time
4.3.3 检测权限提升
复制代码 
# 检测特权账户登录后创建可疑进程（权限提升+执行）
index=winsecurity (EventCode=4672) OR (EventCode=4688 (CommandLine="*whoami*" OR CommandLine="*net user*" OR CommandLine="*net localgroup*"))
| transaction host maxspan=10m
| where EventCode=4672 AND CommandLine!=""
| table _time host user SubjectUserName NewProcessName CommandLine
| sort -_time
4.3.4 检测持久化
复制代码 
# 检测新服务创建和计划任务创建（持久化机制）
index=winsecurity (EventCode=7045) OR (EventCode=4698)
| eval persistence_type=case(
EventCode==7045, "New_Service_Created",
EventCode==4698, "Scheduled_Task_Created"
)
| eval service_info=case(
EventCode==7045, ServiceName." | ".ServiceFileName,
EventCode==4698, TaskName." | ".TaskContent
)
| table _time host user persistence_type service_info
| sort -_time
4.3.5 检测数据外传
复制代码 
# 检测异常大流量出站+异常DNS查询（数据外传行为）
index=network_logs (src_ip="10.0.*" OR src_ip="172.16.*" OR src_ip="192.168.*")
| stats sum(bytes_out) as total_bytes, count as connection_count, values(dst_ip) as dst_ips, dc(dst_port) as unique_ports by src_ip
| where total_bytes > 1073741824 AND unique_ports > 50
| eval risk_score = case(
total_bytes > 10737418240, 90,
total_bytes > 5368709120, 70,
1, 50
)
| table src_ip total_bytes connection_count dst_ips unique_ports risk_score
| sort -risk_score
4.3.6 检测凭据转储
复制代码 
# 检测LSASS进程访问（凭据转储行为，如Mimikatz）
index=winsecurity EventCode=4663
| search process_name="lsass.exe" OR ObjectName="*\\lsass.exe"
| stats count by host, src_user, process_name, ObjectName, AccessMask
| lookup lsass_access_mask AccessMask OUTPUT access_description
| table _time host src_user process_name ObjectName AccessMask access_description
| sort -_time
4.3.7 检测可疑PowerShell执行
复制代码 
# 检测PowerShell执行可疑命令（编码命令、下载执行、反射加载等）
index=winsecurity EventCode=4688 NewProcessName="*\\powershell.exe" OR NewProcessName="*\\pwsh.exe"
| search (CommandLine="*-enc*" OR CommandLine="*-EncodedCommand*" OR CommandLine="*DownloadString*" OR CommandLine="*Invoke-Expression*" OR CommandLine="*IEX*" OR CommandLine="*DownloadFile*" OR CommandLine="*FromBase64String*" OR CommandLine="*Add-Type*")
| eval risk_indicators = mvappend(
if(match(CommandLine, "-enc|-EncodedCommand"), "Encoded_Command", null()),
if(match(CommandLine, "DownloadString|DownloadFile"), "Download_Behavior", null()),
if(match(CommandLine, "Invoke-Expression|IEX"), "Code_Execution", null()),
if(match(CommandLine, "FromBase64String"), "Base64_Decode", null())
)
| table _time host user NewProcessName CommandLine risk_indicators
| sort -_time
4.3.8 检测账户操纵
复制代码 
# 检测新增账户、账户加入特权组、账户密码重置等账户操纵行为
index=winsecurity (EventCode=4720 OR EventCode=4728 OR EventCode=4732 OR EventCode=4756 OR EventCode=4724)
| eval action_type=case(
EventCode==4720, "Account_Created",
EventCode==4728, "Added_To_Global_Group",
EventCode==4732, "Added_To_Local_Group",
EventCode==4756, "Added_To_Universal_Group",
EventCode==4724, "Password_Reset"
)
| eval risk_flag=if(match(GroupName, "Administrators|Domain Admins|Enterprise Admins"), "HIGH_RISK", "MEDIUM")
| table _time host action_type SubjectUserName TargetUserName GroupName risk_flag
| sort -_time

SPL检测查询示例汇总表：

序号 检测场景 ATT&CK技术 数据源 关键事件ID 告警级别
1 暴力破解登录 T1110.001 Windows安全日志 4625 Medium/High
2 横向移动 T1021.002 Windows安全日志 4624+4688 High
3 权限提升 T1078 Windows安全日志 4672+4688 High
4 持久化-服务/计划任务 T1053/T1543 Windows安全日志 7045/4698 High
5 数据外传 T1048 网络日志 - Medium/High
6 凭据转储 T1003.001 Windows安全日志 4663 Critical
7 可疑PowerShell T1059.001 Windows安全日志 4688 High
8 账户操纵 T1098 Windows安全日志 4720/4732 High

4.4 Elastic KQL/EQL检测查询示例

检测场景 KQL查询语句
暴力破解登录 event.code:4625 and winlog.event_data.IpAddress:* | groupby winlog.event_data.IpAddress | count() > 20
横向移动 (event.code:4624 and winlog.event_data.LogonType:3) or (event.code:4688 and process.name:(cmd.exe or powershell.exe))
权限提升 event.code:4672 or (event.code:4688 and process.command_line:(whoami or net user or net localgroup))
持久化 event.code:(7045 or 4698)
数据外传 destination.bytes:>1073741824 and destination.port:(!80 and !443)
凭据转储 event.code:4663 and process.name:lsass.exe
可疑PowerShell event.code:4688 and process.name:(powershell.exe or pwsh.exe) and process.command_line:(-enc or DownloadString or IEX)
账户操纵 event.code:(4720 or 4728 or 4732 or 4756 or 4724)

EQL（Event Query Language）查询示例（序列检测）：

复制代码 
// 检测登录成功后10秒内创建可疑进程的序列行为
sequence by host.name, winlog.event_data.TargetUserName
[event.code:4624 and winlog.event_data.LogonType:3]
[event.code:4688 and process.name:(cmd.exe, powershell.exe, psexec.exe)]
with maxspan=10s

// 检测特权登录后访问LSASS进程的序列
sequence by host.name
[event.code:4672]
[event.code:4663 and winlog.event_data.ObjectName:"*lsass.exe*"]
with maxspan=5m

4.5 告警分级与处置流程

告警级别 定义 响应时限 处置要求 通知方式 升级条件
Critical(严重) 确认的入侵行为，可能导致数据泄露或系统被控 15分钟内响应 立即启动应急响应，L2/L3介入，可能需要隔离主机 电话+短信+邮件+IM 30分钟未响应升级至SOC Manager
High(高危) 高概率攻击行为，需要立即调查确认 30分钟内响应 L1立即调查，2小时内完成初步分析 短信+邮件+IM 2小时未关闭升级至L2
Medium(中危) 可疑行为，需要进一步分析确认 2小时内响应 L1在4小时内完成调查分析 邮件+IM 8小时未关闭升级至L2
Low(低危) 低风险异常，记录监控即可 8小时内响应 L1在24小时内完成审查 邮件 48小时未处理自动关闭

**【注意】**告警分级不是一成不变的。在调查过程中，如果发现初始评估为Medium的事件实际影响严重，应立即升级为High或Critical，并相应调整响应优先级。

4.6 告警降噪策略

告警噪声是SOC运营的最大敌人。过多的误报会导致分析人员疲劳，甚至忽略真实威胁。以下是四种核心降噪策略：

降噪策略 方法 配置示例 适用场景
白名单配置 将已知合法行为排除在告警之外 排除管理员IP的登录失败告警 已知合法的高频行为
聚合规则 将相同类型的告警合并为一条 同一源IP的多次登录失败聚合成一条告警 同源同类型高频告警
抑制规则 在一定时间内不再产生相同告警 同一告警1小时内只通知一次 持续性告警去重
阈值调整 调整触发告警的条件阈值 登录失败从10次提高到20次触发 根据历史误报率调整

白名单配置示例（Splunk）：

复制代码 
# savedsearches.conf
[Brute Force Login Detection]
search = index=winsecurity EventCode=4625
NOT (src_ip IN ("10.0.1.100", "10.0.1.101", "10.0.2.50"))
NOT (user IN ("svc_backup", "svc_monitor", "healthcheck"))
| stats count as fail_count by src_ip
| where fail_count > 20

聚合规则配置示例（Elastic）：

复制代码 
PUT _api/detection_engine/rules
{
"name": "登录失败聚合告警",
"type": "threshold",
"query": "event.code:4625",
"threshold": {
"field": ["source.ip", "user.name"],
"value": 20
},
"time_window": "5m"
}

**【提示】**告警降噪是一个持续优化的过程。建议每月定期回顾告警统计：Top 10高频告警、Top 10误报告警、告警准确率趋势。对于误报率超过80%的规则，应优先进行调优或下线处理。

五、SOAR安全编排自动化与响应

5.1 SOAR概念与核心功能

SOAR（Security Orchestration, Automation and Response，安全编排自动化与响应）是SOC自动化运营的关键平台。SOAR通过将安全工具、流程和人员编排在一起，实现安全事件的自动化响应和协同处理。

SOAR的四大核心功能：

Playbook剧本编排：

剧本（Playbook）是SOAR的核心概念，定义了特定安全事件的标准化响应流程。剧本由一系列步骤组成，每个步骤可以执行查询、调用API、发送通知、执行响应动作等。剧本支持条件分支、循环、并行执行等逻辑控制，能够实现复杂的响应流程自动化。

自动化响应：

SOAR通过集成各种安全工具的API（防火墙、EDR、邮件网关、AD域控、威胁情报平台等），实现响应动作的自动化执行。例如自动封禁IP、隔离主机、禁用账户、删除恶意邮件等。自动化响应大幅缩短了从检测到处置的时间。

案例管理：

SOAR提供案例（Case）管理功能，将相关的告警、事件、证据、响应动作关联到同一案例中，支持多人员协同调查。案例管理还包括任务分配、工单流转、SLA跟踪、知识库沉淀等功能。

协同工作：

SOAR通过集成邮件、IM（企业微信/钉钉/Slack）、工单系统等协作工具，实现安全事件的跨团队协同处理。分析师可以在SOAR平台内直接与其他团队沟通、共享信息、请求支持。

5.2 开源SOAR方案对比

方案 核心功能 集成能力 优点 缺点 适用场景
Shuffle 剧本编排、自动化响应 200+集成插件 可视化编排、插件丰富、社区活跃 功能相对简单、大规模性能一般 中小型企业SOAR起步
Cortex XSOAR Community Edition 剧本编排、案例管理 有限(社区版) Palo Alto技术背书、引擎成熟 社区版功能受限、集成数量有限 已有Palo Alto生态的企业
TheHive+MISP 案例管理+威胁情报 通过Cortex扩展 开源免费、与MISP深度集成 需要自行搭建Cortex、配置复杂 注重威胁情报的团队
SOCless 剧本编排、自动化响应 AWS Lambda集成 基于Serverless架构、扩展性强 强绑定AWS、学习曲线陡 AWS云原生环境

5.3 商业SOAR方案对比

方案 核心功能 集成数量 价格区间 优点 缺点
Splunk SOAR (原Phantom) 剧本编排、案例管理、自动化响应 350+ 高 与Splunk SIEM深度集成、可视化编排强 价格昂贵、非Splunk环境集成复杂
IBM Resilient 案例管理、剧本编排、自动化 300+ 中高 企业级案例管理强、合规支持好 编排灵活性一般、部署复杂
Palo Alto XSOAR 剧本编排、案例管理、威胁情报 700+ 中高 集成数量最多、剧本市场丰富 价格较高、学习曲线陡
Microsoft Sentinel Playbooks 剧本编排、自动化响应 200+(Azure生态) 中(含在Sentinel中) 云原生免运维、与Azure深度集成 强绑定Azure生态

**【提示】**如果企业已经使用Splunk作为SIEM，建议选择Splunk SOAR以获得最佳集成体验。如果使用ELK Stack，推荐Shuffle作为开源SOAR方案。

5.4 自动化响应剧本(Playbook)设计

5.4.1 Playbook设计原则

有效的Playbook设计遵循"五步法"原则：

第一步：触发条件（Trigger）

明确定义Playbook的触发条件，可以是SIEM告警、特定事件类型、手动触发、定时触发等。触发条件应精确描述，避免误触发。

第二步：信息收集（Enrichment）

自动收集与事件相关的上下文信息，包括查询SIEM关联日志、查询威胁情报、查询资产CMDB信息、查询用户AD信息等。信息收集越充分，后续分析越准确。

第三步：分析研判（Analysis）

基于收集的信息进行自动分析判断，包括威胁情报匹配结果、历史行为对比、风险评分计算、关联事件分析等。分析结果用于决定后续响应动作。

第四步：响应动作（Response）

根据分析结果执行相应的响应动作。响应动作可以自动执行（如封禁IP、隔离主机），也可以半自动执行（如发送通知等待人工确认后执行）。对于关键操作建议设置人工确认环节。

第五步：记录关闭（Record & Close）

记录整个事件的处理过程、响应动作、分析结论，更新案例状态，生成事件报告，关闭工单。记录信息应完整可追溯，用于事后复盘和持续改进。

5.4.2 钓鱼邮件响应Playbook示例

场景：用户报告钓鱼邮件或邮件安全网关检测到钓鱼邮件

完整流程描述：

  1. 触发条件：邮件安全网关产生钓鱼邮件告警 OR 用户通过钓鱼报告按钮上报可疑邮件

  2. 信息收集（自动执行）：

  • 从邮件网关提取完整邮件内容（发件人、收件人、主题、正文、附件、URL链接）
  • 提取邮件附件保存到沙箱环境
  • 提取邮件中的URL链接
  • 查询AD获取收件人信息（部门、职位、权限等级）
  1. 分析研判（自动执行）：
  • 将附件提交到沙箱（Cuckoo/Any.Run）进行动态分析，等待分析结果
  • 将URL提交到威胁情报平台（VirusTotal、URLhaus）查询是否为已知恶意URL
  • 将发件人IP地址提交到威胁情报平台查询信誉评分
  • 将附件哈希提交到威胁情报平台查询是否为已知恶意文件
  • 综合评估：若沙箱判定为恶意 或 威胁情报匹配为恶意，则判定为确认钓鱼邮件
  1. 响应动作（自动+人工确认）：
  • 自动执行：从所有收件人邮箱中删除该钓鱼邮件（通过邮件网关API）
  • 自动执行：在邮件网关上添加发件人IP/域名到黑名单
  • 自动执行：将恶意附件哈希和URL加入IOC黑名单（同步到SIEM和防火墙）
  • 人工确认后执行：若用户已点击链接，隔离用户主机（通过EDR API）
  • 自动执行：发送通知邮件给受影响用户，告知安全风险和注意事项
  1. 记录关闭：
  • 创建案例记录（包含邮件原始内容、分析结果、响应动作列表）
  • 生成钓鱼邮件事件报告
  • 关闭案例并归档
  • 将新发现的IOC同步到威胁情报平台
5.4.3 暴力破解响应Playbook示例

场景：SIEM检测到同一源IP对Windows系统发起多次登录失败

完整流程描述：

  1. 触发条件：SIEM暴力破解检测规则触发告警（5分钟内同一源IP登录失败超过20次）

  2. 信息收集（自动执行）：

  • 查询SIEM获取该源IP最近24小时的所有活动记录（登录成功/失败、网络连接、进程创建等）
  • 查询威胁情报平台获取该源IP的信誉评分和已知恶意标记
  • 查询CMDB获取被攻击主机的资产信息（系统类型、业务等级、是否为关键资产）
  • 查询AD获取被攻击的账户列表和权限等级
  • 查询地理IP数据库获取源IP的地理位置信息
  1. 分析研判（自动执行）：
  • 判断源IP是否为内部IP（内网横向移动 vs 外部攻击）
  • 判断源IP是否在白名单中（VPN出口、堡垒机、监控系统等合法高频登录源）
  • 判断是否有登录成功事件（是否已被攻破）
  • 计算综合风险评分：威胁情报评分(40%) + 攻击频率(30%) + 资产重要性(20%) + 是否有成功登录(10%)
  • 若风险评分>70 或 已有登录成功事件，标记为高危
  1. 响应动作（自动+人工确认）：
  • 自动执行：在防火墙上封禁源IP（添加到临时黑名单，默认2小时）
  • 自动执行：若已有登录成功事件，通过EDR隔离被攻破主机
  • 自动执行：若已有登录成功事件，在AD中禁用被攻破账户
  • 人工确认后执行：若源IP为内部IP，通知该网段负责人确认是否为合法行为
  • 自动执行：创建安全事件工单，分配给L2分析师进行深度调查
  1. 记录关闭：
  • 更新工单状态为"处理中"
  • 记录所有自动响应动作和人工确认结果
  • 若确认为误报（如合法系统批量登录），将源IP加入白名单并解除封禁
  • 关闭案例并归档
5.4.4 可疑进程响应Playbook示例

场景：EDR或SIEM检测到终端上执行了可疑进程

完整流程描述：

  1. 触发条件：EDR检测到可疑进程行为 OR SIEM进程创建检测规则触发告警

  2. 信息收集（自动执行）：

  • 采集可疑进程信息（进程名、PID、命令行参数、父进程信息、进程创建时间）
  • 采集进程文件信息（文件路径、文件哈希MD5/SHA256、文件大小、数字签名）
  • 采集进程网络连接信息（目标IP、端口、协议、DNS查询记录）
  • 采集进程文件操作信息（创建/修改/删除的文件列表）
  • 查询进程树（父进程链和子进程列表）
  1. 分析研判（自动执行）：
  • 将文件哈希提交到VirusTotal进行多引擎检测
  • 将文件哈希提交到内部威胁情报平台查询
  • 将网络连接目标IP提交到威胁情报平台查询信誉
  • 分析父进程链是否合理（如word.exe -> cmd.exe 为可疑，explorer.exe -> notepad.exe 为正常）
  • 分析命令行参数是否包含可疑模式（编码命令、下载行为、反弹Shell等）
  • 综合评估：若VirusTotal检出率>30% 或 威胁情报匹配 或 父子进程关系异常，判定为恶意进程
  1. 响应动作（自动+人工确认）：
  • 自动执行：通过EDR终止可疑进程
  • 人工确认后执行：通过EDR隔离受感染主机（防止横向移动）
  • 自动执行：将恶意文件哈希加入IOC黑名单（同步到所有终端EDR）
  • 自动执行：将恶意C2 IP加入防火墙黑名单
  • 自动执行：通知L2分析师进行深度调查（包含完整进程树和网络连接信息）
  • 自动执行：在SIEM中创建关联检测规则，追踪该C2 IP的其他连接行为
  1. 记录关闭：
  • 创建事件案例（包含进程完整信息、分析结论、响应动作）
  • 若确认为恶意进程，启动DFIR流程进行数字取证
  • 若确认为误报，将文件加入白名单并优化检测规则
  • 关闭案例并归档

5.5 SOAR与SIEM集成架构

SOAR与SIEM的集成形成安全运营的闭环流程：

完整闭环流程描述：

第一环节：SIEM告警生成

SIEM平台实时采集和分析安全日志，当检测规则命中时生成安全告警。告警包含事件详情、关联日志、风险评分、ATT&CK技术标签等信息。

第二环节：告警转发至SOAR

SIEM通过Webhook/API将告警信息自动转发至SOAR平台。转发信息包括告警标题、严重级别、源IP、目标主机、时间戳、关联事件ID等。

第三环节：SOAR触发Playbook

SOAR接收到告警后，根据告警类型和严重级别自动匹配对应的Playbook。Playbook开始执行，进入信息收集阶段。

第四环节：自动化响应执行

Playbook按照预定义的流程执行自动化的信息收集、分析研判和响应动作。在关键决策点，根据分析结果选择不同的响应分支。

第五环节：结果反馈闭环

SOAR将处理结果（响应动作、分析结论、案例状态）反馈回SIEM平台，更新告警状态。同时，SOAR将新发现的IOC（恶意IP、域名、哈希）同步到SIEM和威胁情报平台，用于增强后续检测能力。

**【注意】**SOAR不是要完全替代人工分析，而是自动化处理已知场景的常见操作，释放分析师精力去处理更复杂的安全事件。建议初期将自动化响应范围控制在低风险操作（如封禁IP、查询情报），高风险操作（如隔离主机、禁用账户）应设置人工确认环节。

六、威胁情报集成

6.1 威胁情报分类

威胁情报按照抽象层次和用途可以分为四类：

情报类型 描述 典型内容 主要用户 更新频率 示例
战略情报(Strategic) 高层战略趋势和威胁态势 行业威胁趋势、攻击者动机、地缘政治分析 CISO、安全总监、管理层 月/季度 "2024年金融行业APT攻击趋势报告"
战术情报(Tactical) 攻击者的TTP（战术、技术和程序） ATT&CK技术映射、攻击工具链、攻击流程 L3威胁狩猎师、安全架构师 周/月 "APT41组织常用攻击技术和工具链分析"
运营情报(Operational) 特定攻击活动的详细信息 攻击Campaign信息、攻击目标、攻击时间线 L2事件分析师、L3狩猎师 天/周 "某APT组织近期针对能源行业的钓鱼攻击活动"
技术情报(Technical) 可机读的技术指标(IOC) 恶意IP、域名、URL、文件哈希、证书指纹 L1监控分析师、SIEM平台 小时/天 "恶意IP: 185.220.101.34, 关联APT组织: Lazarus"

**【提示】**SOC建设初期应优先接入技术情报（IOC），因为技术情报可以直接集成到SIEM做自动匹配告警。战术和运营情报主要用于威胁狩猎，战略情报用于安全规划。

6.2 开源威胁情报源

情报源 情报类型 功能描述 API限制 推荐用途
AbuseIPDB 恶意IP IP地址滥用举报和查询，提供IP信誉评分 免费1000次/天 IP信誉查询
AlienVault OTX IOC+TTP 综合威胁情报交换平台，含IOC、Pulse、TTP 无限制(API Key) 综合情报获取
VirusTotal 文件哈希+URL+IP 多引擎文件检测、URL分析、IP信誉 免费4次/分钟 文件/URL分析
MISP IOC+TTP 开源威胁情报平台，支持Feed订阅和共享 无限制(自建) 情报管理和共享
ThreatFox IOC 专注恶意IOC数据库，含APT关联标签 无限制 IOC查询
URLhaus 恶意URL 恶意URL分发平台，专注恶意软件分发URL 无限制 URL检测
Pulsedive IOC+TTP 综合威胁情报平台，提供API查询和Feed 免费1000次/天 IOC查询和丰富

AbuseIPDB API使用示例：

复制代码 
# 查询IP信誉
curl -G https://api.abuseipdb.com/api/v2/check \
--data-urlencode "ipAddress=185.220.101.34" \
--data-urlencode "maxAgeInDays=90" \
-H "Key: YOUR_API_KEY" \
-H "Accept: application/json"

VirusTotal API使用示例：

复制代码 
# 查询文件哈希
curl --request GET \
--url https://www.virustotal.com/api/v3/files/44d88612fea8a8f36de82e1278abb02f \
--header "x-apikey: YOUR_API_KEY"

# 查询IP地址
curl --request GET \
--url https://www.virustotal.com/api/v3/ip_addresses/185.220.101.34 \
--header "x-apikey: YOUR_API_KEY"

ThreatFox API使用示例：

复制代码 
# 获取最近7天的IOC
curl --request POST \
--url https://threatfox-api.abuse.ch/api/v1/ \
--header "Content-Type: application/json" \
--data '{"query":"get_iocs","days":7}'

6.3 MISP平台搭建与使用

MISP（Malware Information Sharing Platform）是开源的威胁情报共享和管理平台，支持情报的导入、管理、关联分析和共享。

6.3.1 Docker部署MISP
复制代码 
# 使用Docker Compose部署MISP
mkdir misp && cd misp

# docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: '3'
services:
misp:
image: coolacid/misp:latest
ports:
- "8080:80"
- "8443:443"
environment:
- MYSQL_HOST=misp-db
- MYSQL_DATABASE=misp
- MYSQL_USER=misp
- MYSQL_PASSWORD=misp_password_123
- MISP_ADMIN_EMAIL=admin@misp.local
- MISP_ADMIN_PASSPHRASE=admin_password_123
- MISP_BASEURL=https://misp.company.com
depends_on:
- misp-db
restart: always

misp-db:
image: mysql:5.7
environment:
- MYSQL_ROOT_PASSWORD=root_password_123
- MYSQL_DATABASE=misp
- MYSQL_USER=misp
- MYSQL_PASSWORD=misp_password_123
volumes:
- misp-db-data:/var/lib/mysql
restart: always

volumes:
misp-db-data:
EOF

# 启动MISP
docker-compose up -d

# 检查服务状态
docker-compose ps
6.3.2 导入外部情报Feed

通过MISP Web界面或API配置情报Feed：

复制代码 
# 通过API添加Feed
curl --request POST \
--url https://misp.company.com/feeds/add \
--header "Authorization: YOUR_API_KEY" \
--header "Content-Type: application/json" \
--header "Accept: application/json" \
--data '{
"name": "AbuseCH ThreatFox",
"provider": "abuse.ch",
"url": "https://threatfox-api.abuse.ch/export/json/v1/",
"input_source": "network",
"format": "json",
"source_format": "misp-json",
"enabled": true,
"distribution": "3",
"sharing_group_id": "0"
}'

# 手动触发Feed拉取
curl --request POST \
--url https://misp.company.com/feeds/fetchFromAllFeeds \
--header "Authorization: YOUR_API_KEY"
6.3.3 通过API查询IOC
复制代码 
# 搜索特定IP的IOC
curl --request POST \
--url https://misp.company.com/attributes/restSearch \
--header "Authorization: YOUR_API_KEY" \
--header "Content-Type: application/json" \
--header "Accept: application/json" \
--data '{
"returnFormat": "json",
"type": "ip-dst",
"value": "185.220.101.34"
}'

# 搜索特定文件哈希的IOC
curl --request POST \
--url https://misp.company.com/attributes/restSearch \
--header "Authorization: YOUR_API_KEY" \
--header "Content-Type: application/json" \
--header "Accept: application/json" \
--data '{
"returnFormat": "json",
"type": "sha256",
"value": "f3e2a1b0c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0"
}'

# 下载所有IOC为CSV格式
curl --request POST \
--url https://misp.company.com/attributes/restSearch \
--header "Authorization: YOUR_API_KEY" \
--header "Content-Type: application/json" \
--header "Accept: application/json" \
--data '{
"returnFormat": "csv",
"type": ["ip-dst", "domain", "sha256", "url"]
}'

6.4 威胁情报与SIEM集成

将威胁情报IOC导入SIEM实现自动匹配告警，是威胁情报最直接的应用方式。

6.4.1 Splunk与MISP集成
复制代码 
# 安装Splunk MISP插件
splunk install app ta-misp -auth admin:changeme

# 配置MISP连接（inputs.conf）
[misp://misp_threat_intel]
interval = 3600
misp_url = https://misp.company.com
misp_key = YOUR_MISP_API_KEY
misp_verifycert = true
lookup_name = misp_iocs
lookup_fields = ip,domain,sha256,url,tag

# 创建威胁情报匹配告警
index=winsecurity OR index=network_logs
| lookup misp_iocs ip AS src_ip OUTPUT tag as misp_tag
| where isnotnull(misp_tag)
| eval alert_type = "Threat_Intel_Match"
| table _time src_ip misp_tag index sourcetype
| sort -_time
6.4.2 Elastic与OpenCTI集成
复制代码 
# Elastic Threat Intel配置
PUT _api/detection_engine/rules
{
"name": "威胁情报IOC匹配检测",
"description": "将网络日志中的源IP与威胁情报IOC进行匹配",
"risk_score": 80,
"severity": "high",
"type": "query",
"query": "source.ip: (185.220.101.34 OR 23.129.64.211 OR 45.155.205.233) OR destination.domain: (malicious-domain.com OR c2-server.net)",
"actions": [
{
"type": "webhook",
"url": "https://soar.company.com/api/v1/threat_intel_alert"
}
]
}

# 使用Threat Intel集成自动丰富告警
PUT _ingest/pipeline/threat_intel_enrichment
{
"description": "使用威胁情报丰富日志事件",
"processors": [
{
"enrich": {
"policy_name": "threat_intel_ip_policy",
"field": "source.ip",
"target_field": "threat.intel",
"ignore_missing": true
}
}
]
}

6.5 威胁情报评分与置信度评估

不同情报来源的可信度不同，需要对情报进行评分和置信度评估。

情报来源可信度评分表：

情报来源 可信度评分 说明
内部安全团队确认的IOC 100 经过内部验证确认的恶意指标
商业威胁情报平台 80 付费情报平台，经过专业团队验证
MISP可信社区共享 70 MISP社区中可信组织共享的情报
VirusTotal多引擎检测 60 多引擎检测一致判定的恶意文件
开源情报Feed(OTX/ThreatFox) 50 开源情报平台，质量参差不齐
单一来源开源情报 30 单一非权威来源的情报

IOC置信度计算方法：

复制代码 
置信度 = (情报来源评分加权平均) * (情报新鲜度因子) * (情报一致度因子)

情报新鲜度因子：
- 7天内: 1.0
- 30天内: 0.8
- 90天内: 0.5
- 90天以上: 0.2

情报一致度因子：
- 3个以上来源确认: 1.0
- 2个来源确认: 0.8
- 1个来源: 0.5

示例：
某IP在OTX(50分)和ThreatFox(50分)中均标记为恶意，情报时间为15天前
置信度 = ((50+50)/2) * 0.8 * 0.8 = 32
结论：置信度较低，作为参考情报使用

**【注意】**威胁情报不是银弹。IOC的有效期很短（通常几周到几个月），攻击者会频繁更换基础设施。建议将威胁情报作为辅助检测手段，而非唯一检测依据。对于高置信度的IOC可以自动响应，低置信度的IOC仅用于告警丰富和调查参考。

七、威胁狩猎(Threat Hunting)

7.1 威胁狩猎方法论

威胁狩猎（Threat Hunting）是SOC的高级能力，指L3分析师主动在环境中搜索潜在的安全威胁，而非被动等待告警触发。威胁狩猎的核心假设是"攻击者已经在环境中"，分析师需要主动寻找被自动化检测遗漏的威胁。

7.1.1 假设驱动狩猎

假设驱动狩猎是最经典的威胁狩猎方法，基于ATT&CK框架构建检测假设，然后主动搜索证据来验证假设。

狩猎流程：

  1. 基于ATT&CK技术构建假设："攻击者可能使用计划任务实现持久化"
  2. 确定需要搜索的数据源：Windows安全日志4698（计划任务创建）、Sysmon EventID 1（进程创建）
  3. 编写狩猎查询，搜索异常的计划任务创建行为
  4. 分析搜索结果，识别可疑的计划任务（异常名称、可疑命令、非标准创建者等）
  5. 对可疑结果进行深入调查，确认是否为真实威胁
  6. 如果确认威胁，启动事件响应流程；如果是新攻击模式，开发新的检测规则
7.1.2 数据驱动狩猎

数据驱动狩猎不依赖特定假设，而是通过统计分析、行为基线、异常检测等方法发现数据中的异常模式。

狩猎方法：

  • 基线异常检测：建立正常行为基线（如用户日均登录时间、频率、来源IP），检测偏离基线的行为
  • UEBA用户行为分析：分析用户行为模式，识别异常行为（如非工作时间大量文件访问、异常地理位置登录）
  • 统计异常检测：使用统计方法（标准差、IQR、Z-Score）检测数据中的异常值
  • 聚类分析：对相似行为进行聚类，识别异常的行为集群
7.1.3 TTP驱动狩猎

TTP驱动狩猎基于已知的APT组织战术、技术和程序（TTP），在环境中搜索相似的攻击行为。

狩猎流程：

  1. 从威胁情报报告中提取APT组织的TTP（如"APT41使用FishMonger后门，通过HTTP POST请求C2通信"）
  2. 将TTP映射到ATT&CK技术（如T1071.001应用层协议-Web协议）
  3. 提取TTP的技术特征（如特定User-Agent、特定URL模式、特定文件名）
  4. 在历史日志中搜索匹配这些特征的行为
  5. 分析搜索结果，确认是否存在相同APT组织的活动痕迹

三种狩猎方法对比表：

维度 假设驱动狩猎 数据驱动狩猎 TTP驱动狩猎
适用场景 有明确的检测假设 需要发现未知威胁 追踪特定APT组织
数据需求 针对性日志数据源 全量日志+历史基线 历史日志+威胁情报
技术难度 中等 高（需统计分析能力） 中等（需情报分析能力）
狩 hunt效果 针对性强，误报率低 能发现未知威胁，误报率较高 能发现APT活动，依赖情报质量
典型工具 SIEM查询、Sigma UEBA平台、机器学习 威胁情报平台、ATT&CK Navigator
适用成熟度 Level 2+ Level 3+ Level 2+

7.2 威胁狩猎实战技巧

7.2.1 Windows环境狩猎
狩猎场景 SPL查询语句 说明
异常计划任务 index=winsecurity EventCode=4698 NOT(user="SYSTEM" OR user="NETWORK SERVICE") 搜索非系统账户创建的计划任务
可疑服务创建 index=winsecurity EventCode=7045 ServiceFileName="\ .exe" NOT(ServiceName="Update " OR ServiceName="Microsoft") 搜索非系统更新类的新服务
异常PowerShell index=winsecurity EventCode=4688 NewProcessName="powershell.exe" (CommandLine=" -enc*" OR CommandLine="Bypass " OR CommandLine="Hidden " OR CommandLine="DownloadString") 搜索异常PowerShell执行
可疑注册表修改 index=winsecurity EventCode=4657 ObjectName="CurrentVersion\Run " OR ObjectName="CurrentVersion\Explorer\Shell Folders" 搜索自启动注册表项修改
异常账户创建 index=winsecurity EventCode=4720 搜索所有新账户创建事件
可疑DLL加载 index=sysmon EventID=7 ImageLoaded="\temp\ " OR ImageLoaded="\AppData\" 搜索从临时目录加载的DLL
7.2.2 网络环境狩猎
狩猎场景 SPL查询语句 说明
异常DNS查询 index=dns_logs stats count by query
可疑C2通信 index=network_logs dest_port IN (4444, 6667, 9001, 1234, 4445, 8080) OR (dest_port!=80 AND dest_port!=443 AND bytes_out>bytes_in*10) 搜索已知C2端口或异常出站流量比例
DNS隧道检测 index=dns_logs eval query_len=len(query)
横向移动网络特征 index=network_logs src_port=445 OR src_port=3389 OR src_port=22 stats dc(dest_ip) as target_count by src_ip
数据外传检测 index=network_logs bucket _time span=1h
信标行为检测 index=network_logs stats count, stdev(_time) as time_jitter by src_ip, dest_ip
7.2.3 终端行为狩猎
狩猎场景 EQL/SPL查询语句 说明
进程注入检测 sequence by host process where event.action:"Image loaded" and dll.name:"*\\temp\\*" process where event.action:"Process accessed" and target.process.name:"lsass.exe" 检测向LSASS注入DLL的行为
可疑进程树 index=sysmon EventID=1 (ParentImage="*winword.exe" OR ParentImage="*excel.exe" OR ParentImage="*outlook.exe") (Image="*cmd.exe" OR Image="*powershell.exe" OR Image="*wscript.exe") 搜索Office程序生成子进程的可疑行为
异常文件操作 index=sysmon EventID=11 TargetFilename="\AppData\Roaming\ .exe" OR TargetFilename="\ProgramData\.exe" 搜索在AppData/ProgramData目录创建的EXE文件
凭据转储行为 index=sysmon EventID=10 TargetImage="*lsass.exe" (SourceImage="mimikatz " OR SourceImage="procdump " OR SourceImage="taskmgr") 搜索访问LSASS进程的可疑行为
活动目录转储 index=winsecurity EventCode=4662 AccessMask="0x100" OR AccessMask="0x101" Properties="1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" 搜索AD目录服务枚举行为（DSync攻击）

7.3 威胁狩猎记录与知识沉淀

威胁狩猎的价值不仅在于发现威胁，更在于将狩猎经验转化为可复用的知识资产。

威胁狩猎假设模板：

复制代码 
威胁狩猎假设记录表

狩猎ID: HUNT-2024-001
狩猎日期: 2024-01-15
狩猎分析师: [姓名]
ATT&CK技术: T1053.005 (Scheduled Task)
狩猎假设: 攻击者可能通过创建计划任务实现持久化，计划任务可能使用异常名称或调用可疑命令

数据源:
- Windows安全日志 EventID 4698 (计划任务创建)
- Sysmon EventID 1 (进程创建)
- Windows Task Scheduler日志

狩猎查询:
index=winsecurity EventCode=4698 NOT(user="SYSTEM")
| eval is_suspicious = if(match(TaskName, "[a-z0-9]{16,}|tmp|temp|test|update"), 1, 0)
| where is_suspicious=1

狩猎结果:
- 发现3个可疑计划任务
- 计划任务1: 名称"SystemUpdateCheck"（伪装系统更新），执行PowerShell下载脚本
- 计划任务2: 名称"a1b2c3d4e5f6"（随机名称），执行rundll32加载可疑DLL
- 计划任务3: 经确认误报（合法运维工具）

发现新威胁: 是（计划任务1和2确认为恶意持久化行为）
新检测规则: 已创建Sigma规则 detect_suspicious_scheduled_task.yml
事件响应: 已启动IR-2024-001事件响应流程

改进建议:
1. 增加4698事件中TaskName的正则匹配规则
2. 将计划任务创建者的用户名加入UEBA分析
3. 增加计划任务执行命令的PowerShell编码检测

威胁狩猎结果记录表：

记录项 内容
狩猎ID HUNT-2024-001
狩猎日期 2024-01-15
狩猎分析师 张三
ATT&CK技术 T1053.005
狩猎假设 攻击者通过计划任务实现持久化
数据源 Windows 4698 + Sysmon EID 1
搜索结果 发现3个可疑计划任务
确认威胁 2个确认为恶意，1个为误报
新检测规则 detect_suspicious_scheduled_task.yml
关联事件 IR-2024-001
改进建议 增加计划任务名称正则匹配+UEBA分析

发现新检测规则的反馈流程：

  1. 狩猎分析师编写新的检测规则草案
  2. 在测试环境验证规则的检出率和误报率
  3. 提交规则评审（由L3和SOC Engineer评审）
  4. 评审通过后部署为试运行规则（2周观察期）
  5. 试运行期监控告警情况，调优阈值和条件
  6. 调优完成后转为正式规则，加入规则库

7.4 威胁狩猎工具

工具 类型 核心功能 优点 缺点 适用场景
Velociraptor 终端取证+狩猎 远程终端取证、DFIR、VQL查询语言 开源免费、VQL强大、Web界面管理 大规模部署资源消耗大 中大型企业终端狩猎
GRR Rapid Response 终端取证+狩猎 远程实时取证、事件响应 Google开发、支持大规模部署 学习曲线陡、UI一般 大规模终端环境
OSquery 终端查询 使用SQL查询终端状态 Facebook开发、SQL语法简单 无实时监控能力、需要管理平台 终端状态查询和合规审计
FleetDM OSquery管理 OSquery集中管理和调度 Web界面管理、支持分布式部署 依赖OSquery、功能有限 OSquery的集中管理平台

Velociraptor VQL狩猎查询示例：

复制代码 
// 搜索所有从Temp目录执行的进程
SELECT * FROM process_tracker()
WHERE Exe =~ "C:\\\\Windows\\\\Temp|C:\\\\Users\\\\.*\\\\AppData\\\\Local\\\\Temp"

// 搜索所有计划任务中的可疑命令
SELECT * FROM Artifact.Windows.Forensics.ScheduledTasks()
WHERE Command =~ "powershell|cmd.exe|rundll32|mshta"

OSquery狩猎查询示例：

sql 复制代码 
-- 搜索监听异常端口的进程
SELECT p.pid, p.name, p.path, lp.port, lp.address
FROM processes p
JOIN listening_ports lp ON p.pid = lp.pid
WHERE lp.port NOT IN (80, 443, 22, 3389, 135, 139, 445)
AND lp.address != '127.0.0.1';

-- 搜索最近24小时内创建的可执行文件
SELECT path, mtime, size, hash.sha256
FROM file
JOIN hash USING (path)
WHERE path LIKE 'C:\Users\%\AppData\Local\Temp\%.exe'
AND mtime > (SELECT unix_time - 86400 FROM time);

八、SOC运营指标与持续改进

8.1 SOC关键度量指标(KPI)定义

SOC运营需要用数据驱动决策，以下为SOC核心KPI指标定义与计算方法：

指标名称 英文缩写 定义 计算公式 目标值 说明
平均检测时间 MTTD 从攻击发生到SOC检测到的时间 检测时间 - 攻击发生时间 <30分钟 反映检测能力
平均响应时间 MTTR 从告警生成到开始处置的时间 响应开始时间 - 告警生成时间 <15分钟(Critical) 反映响应速度
平均修复时间 MTTC 从事件确认到完全修复的时间 修复完成时间 - 事件确认时间 <4小时(Critical) 反映处置效率
告警总量 - 统计周期内产生的告警总数 COUNT(alerts) 按趋势监控 监控告警趋势
告警准确率 - 确认为真实威胁的告警占比 真实告警数 / 总告警数 * 100% >30% 反映规则质量
误报率 FPR 非威胁告警占总告警的比例 误报告警数 / 总告警数 * 100% <60% 越低越好
漏报率 FNR 未检测到的真实威胁占比 漏报威胁数 / 总威胁数 * 100% <5% 需红队测试评估
事件闭环率 - 已关闭事件占总事件比例 已关闭事件数 / 总事件数 * 100% >95% 反映处理效率
威胁狩猎发现数 - 通过狩猎发现的新威胁数 COUNT(hunt_findings) 持续增长 反映狩猎能力
自动化响应率 - 自动化处置的告警占比 自动处置告警数 / 总告警数 * 100% >40% 反映自动化水平
规则覆盖率 - ATT&CK技术覆盖比例 已覆盖技术数 / 适用技术总数 * 100% >60% 反映检测覆盖
日志覆盖率 - 已接入SIEM的日志源比例 已接入日志源 / 应接入日志源 * 100% >90% 反映数据覆盖

**【提示】**KPI指标不是越多越好，建议初期重点关注MTTD、MTTR、告警准确率和事件闭环率四个核心指标。随着SOC成熟度提升，逐步增加威胁狩猎发现数、自动化响应率等高级指标。

8.2 SOC运营报告模板

日报模板：

报告项 内容描述 数据来源
告警概况 当日告警总数、分级统计、趋势对比 SIEM告警统计
高危事件 Critical和High级别事件摘要 事件管理系统
处置情况 已处置事件数、待处理事件数、SLA达标率 工单系统
威胁情报 当日新增IOC数量、匹配命中情况 威胁情报平台
异常发现 威胁狩猎发现的可疑行为 狩猎记录
系统状态 SIEM/SOAR平台运行状态、日志采集覆盖率 监控系统

周报模板：

报告项 内容描述 数据来源
周告警统计 本周告警趋势、Top10告警类型、Top10源IP SIEM统计分析
事件回顾 本周安全事件汇总、处理结果、影响评估 事件管理系统
KPI指标 MTTD/MTTR/告警准确率/事件闭环率周趋势 KPI仪表盘
规则优化 本周新增/修改/下线的检测规则 规则管理系统
狩猎成果 本周威胁狩猎发现、新检测规则开发情况 狩猎记录
情报动态 本周威胁情报更新、新出现的威胁趋势 威胁情报平台
改进计划 本周发现的问题和下周改进计划 团队讨论

月报模板：

报告项 内容描述 数据来源
月度安全态势 整体安全态势评估、威胁趋势分析、行业对比 综合分析
KPI月度分析 核心KPI月度数据、环比/同比分析、目标达成情况 KPI仪表盘
事件深度分析 重大安全事件复盘、攻击链分析、根因分析 事件复盘报告
检测能力评估 ATT&CK覆盖率分析、规则有效性评估、盲区识别 规则管理系统
狩猎成果汇总 月度狩猎发现汇总、新检测规则贡献、威胁狩猎ROI评估 狩猎记录
自动化运营 SOAR运行统计、Playbook执行情况、自动化响应率 SOAR平台
培训与演练 团队培训记录、演练情况、能力提升评估 培训记录
下月计划 下月工作重点、改进措施、资源需求 管理规划

8.3 SOC持续改进流程

SOC的持续改进是一个PDCA（计划-执行-检查-行动）闭环过程：

第一环节：定期回顾告警有效性

每周统计各检测规则的告警触发情况、准确率、误报率。识别准确率低于20%或误报率高于80%的规则，列入优化清单。

第二环节：优化检测规则

针对低效规则进行分析：是否条件过宽导致误报、是否阈值过低导致噪声、是否缺少白名单导致合法行为被误报。根据分析结果调整规则逻辑、增加白名单、调整阈值。

第三环节：调整告警阈值

基于历史数据统计，为每类告警设置合理的阈值。例如暴力破解检测的登录失败次数阈值，可以根据企业规模和历史数据从10次调整为20次或30次。

第四环节：补充数据源

分析检测盲区，识别缺失的日志数据源。例如发现无法检测某些横向移动行为，可能是因为缺少Sysmon日志或网络层日志，需要补充相应数据源。

第五环节：改进Playbook

回顾SOAR Playbook的执行情况，分析自动化响应的效果和问题。优化Playbook的逻辑分支、增加新的集成、调整自动/人工操作的比例。

第六环节：闭环验证

验证改进措施的效果，对比改进前后的KPI指标变化。将有效的改进措施标准化为SOP，纳入SOC运营流程。

8.4 SOC团队培训与演练

培训/演练类型 目的 组织方式 频率 参与人员
CTF训练 提升攻击技术和防御技能 内部CTF平台或参加外部CTF比赛 每月1次 全体分析师
紫队演练 验证检测规则有效性 红队模拟攻击，蓝队实时检测响应 每季度1次 L2/L3 + 红队
桌面推演 检验事件响应流程 模拟安全场景，团队讨论响应步骤 每季度1次 全体SOC + IT运维
ATT&CK评估 评估检测覆盖率 使用ATT&CK Evaluation框架评估检测能力 每半年1次 L3 + SOC Engineer
技术分享会 知识传递和经验交流 内部技术分享，轮流主讲 每周1次 全体分析师
外部培训 获取行业最新知识 参加安全会议、培训认证课程 每年2-4次 关键岗位人员

**【注意】**SOC团队的持续成长需要制度化培训体系。建议为每个角色制定年度培训计划：L1侧重SIEM操作和基础分析能力认证（如CompTIA Security+），L2侧重事件分析和取证能力（如GCIA/GCIH），L3侧重威胁狩猎和高级分析（如GCFA/GREM）。

九、实战案例：企业SOC从零到一建设

9.1 企业背景与需求分析

企业背景：

某中型科技企业，员工规模约2000人，办公终端约1500台，服务器约200台（含本地机房和云服务器），网络出口带宽1Gbps。业务系统包括ERP、OA、CRM、代码仓库等，部分系统通过互联网暴露。

现有安全工具盘点：

  • 防火墙：边界防火墙1台（Palo Alto）
  • 终端安全：企业级杀毒软件（覆盖80%终端）
  • 漏洞扫描：Nessus（季度扫描）
  • 邮件安全：邮件网关（基础过滤）
  • 缺失能力：无SIEM、无SOAR、无集中日志管理、无威胁检测、无安全运营团队

安全需求分析：

  • 合规要求：等保2.0三级要求日志集中存储和分析
  • 安全需求：频繁遭受外部攻击（暴力破解、钓鱼邮件、漏洞利用），缺乏检测和响应能力
  • 运营需求：建立7x8小时安全运营能力（非7x24，成本考虑）
  • 团队规模：初期3人（1名SOC Manager + 2名安全运营分析师）

建设目标（12个月）：

  • 搭建SIEM平台，日志覆盖率>80%
  • 开发50+检测规则，覆盖ATT&CK Top 10技术
  • 部署SOAR平台，实现3个核心场景自动化
  • 建立威胁狩猎能力，月度狩猎产出
  • 达到SOC成熟度Level 2（主动型）

9.2 Phase1 SIEM平台搭建（第1-3月）

技术选型：

基于成本和技术栈考虑，选择ELK Stack作为SIEM平台。

步骤1：ELK Stack集群部署

部署3节点Elasticsearch集群（每节点64GB内存/8核CPU/4TB SSD）：

复制代码 
# 在三台服务器上分别部署Elasticsearch
# 10.0.1.11 (node-1, master+data)
# 10.0.1.12 (node-2, master+data)
# 10.0.1.13 (node-3, master+data)

# 安装Elasticsearch
rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
cat > /etc/yum.repos.d/elasticsearch.repo << 'EOF'
[elasticsearch]
name=Elasticsearch repository for 8.x packages
baseurl=https://artifacts.elastic.co/packages/8.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
EOF

yum install elasticsearch -y
systemctl enable elasticsearch
systemctl start elasticsearch

# 验证集群状态
curl -X GET "https://10.0.1.11:9200/_cluster/health?pretty" -u elastic:password --insecure

步骤2：日志采集器部署

在Windows终端部署Winlogbeat（1500台），在Linux服务器部署Filebeat（200台）：

复制代码 
# 使用GPO批量部署Winlogbeat到Windows终端
# 配置Winlogbeat采集Security、System、Sysmon日志
# 所有终端日志发送到Logstash（10.0.1.20:5044）

# 在Logstash服务器上配置解析管道
# 将Windows事件日志解析为ECS（Elastic Common Schema）格式
# 将Nginx日志解析为标准字段

步骤3：安全仪表盘配置

在Kibana中创建以下仪表盘：

  • 安全运营总览：实时告警数、告警趋势、TOP10告警类型、TOP10源IP
  • Windows安全监控：登录成功/失败趋势、进程创建监控、服务创建监控
  • 网络流量分析：流量趋势、异常连接、防火墙拦截统计
  • 合规审计：用户操作审计、权限变更记录、系统配置变更

Phase1成果：

  • ELK集群上线运行，日均处理日志量约50GB
  • 日志覆盖率：Windows安全日志85%、Linux系统日志80%、网络设备日志90%、Web应用日志75%
  • 安全仪表盘上线，实现基本安全态势可视化
  • MTTD指标：从"未知"降低到约4小时（基于规则检测）

9.3 Phase2 检测规则开发（第3-6月）

步骤1：基于ATT&CK Top 10技术开发Sigma规则

选择ATT&CK Top 10技术作为首批检测规则开发目标：

序号 ATT&CK技术 技术ID 检测规则名称 数据源 上线状态
1 命令与脚本解释器 T1059 PowerShell编码命令检测 Windows 4688 + 4104 已上线
2 计划任务/作业 T1053 可疑计划任务创建检测 Windows 4698 已上线
3 创建或修改系统进程 T1543 可疑服务创建检测 Windows 7045 已上线
4 操作系统凭据转储 T1003 LSASS进程访问检测 Windows 4663 + Sysmon 10 已上线
5 应用层协议 T1071 异常网络连接检测 网络日志 已上线
6 进程注入 T1055 进程注入行为检测 Sysmon 8 已上线
7 系统二进制代理执行 T1218 Rundll32可疑执行检测 Windows 4688 已上线
8 替代协议外传 T1048 异常大流量出站检测 网络日志 已上线
9 账户操纵 T1098 特权组成员变更检测 Windows 4732 已上线
10 引导/登录自动启动 T1547 自启动注册表修改检测 Windows 4657 已上线

步骤2：Sigma规则转换为SPL并部署

复制代码 
# 将Sigma规则批量转换为Elastic KQL
python3 tools/sigmac -t kql -c winlogbeat rules/soc_custom/

# 部署到Elastic SIEM
# 通过Elastic Detection Engine API导入规则
for rule in rules/soc_custom/*.yml; do
python3 tools/sigmac -t kibana -c winlogbeat "$rule" | \
curl -X POST "https://10.0.1.11:9200/_api/detection_engine/rules" \
-H "Content-Type: application/json" \
-u elastic:password --insecure \
-d @-
done

步骤3：验证测试

使用Atomic Red Team模拟攻击验证检测规则：

复制代码 
# 安装Atomic Red Team
Invoke-Expression (Invoke-WebRequest 'https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1059.001/T1059.001.md' -UseBasicParsing)

# 执行T1059.001 (PowerShell)原子测试
Invoke-AtomicTest T1059.001

# 验证SIEM是否产生对应告警
# 检查Elastic Detection Engine告警面板
相关推荐
SKYLAB011 小时前
打破智能家居生态壁垒｜微喇智能 WKV553‑A 模组原生支持 Matter，解锁跨平台互联新体验
网络·智能家居
愚公搬代码1 小时前
【愚公系列】《Web应用安全》001-VMware的安装
前端·安全
anscos2 小时前
案例分享｜ Latitude AI × Parasoft：搭建 L2-L3 自动驾驶量产验证与功能安全完整链路
人工智能·安全·自动驾驶
笨鸟先飞，勤能补拙2 小时前
Web 服务器与计算机网络全景原理
运维·服务器·前端·网络·人工智能·计算机网络·web安全
KindSuper_liu2 小时前
Unity 游戏网络基础：从 TCP、UDP 到 HTTP、TLS 与 Best HTTP
网络·游戏·unity
caimouse3 小时前
ReactOS 图形系统分析（3）：显示驱动 DDI framebuf.dll
linux·运维·网络
M158227690553 小时前
四通道 Profinet 转 Modbus RTU 网关 SG-PN-Modbus_4 全场景落地详解
网络·工控布线
佳児素花痴╮3 小时前
网络问题与基础理论
运维·服务器·网络
Oflycomm3 小时前
IPC网络摄像机与安防监控：Wi-Fi 6模组、AOV低功耗与边缘AI的产业落地
网络·人工智能·安防监控·wifi6·ipc网络摄像机
热门推荐
01GitHub 镜像站点02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新04VSCode+CodeX扩展，无法启动052026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？06AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路07Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费08历年考研数学一、数学二、数学三真题试卷及答案PDF092026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片10如何新建文件夹？ 电脑新建文件夹的4种方法