AdityaBhatt3010/Microsoft-Sentinel-Understanding-Cloud-Native-SIEM-and-SOAR
GitHub: AdityaBhatt3010/Microsoft-Sentinel-Understanding-Cloud-Native-SIEM-and-SOAR
该项目系统讲解 Microsoft Sentinel 云原生 SIEM/SOAR 平台的安全运营四阶段工作流及 SOC 分析师实践。
Stars: 1 | Forks: 0
# Microsoft Sentinel：理解云原生 SIEM 与 SOAR
Microsoft Sentinel 是微软的云原生平台，用于安全监控、威胁检测、调查和自动化响应。
对于安全运营中心（SOC）来说，困难的部分很少是生成安全数据。现代环境已经跨端点、身份、应用、云资源和网络基础设施产生了海量的日志。真正的挑战是将这些数据转化为分析人员可以调查和采取行动的信息。
本文探讨了 Microsoft Sentinel 的基础知识、SOC Analyst 的职责，以及 Sentinel 安全运营工作流背后的四个核心阶段。🔍
## 安全运营与 SOC Analyst
**安全运营中心（SOC）**是一个集中的安全职能部门，负责监控组织的环境并保护其免受网络威胁。
SOC Analyst 运作在这一防御过程的最前线。他们的职责通常包括监控安全事件、对告警进行分诊、调查安全事件、狩猎威胁，以及协助改善组织的整体防御态势。
**Microsoft Security Operations Analyst** 在遵循相同防御目标的同时，主要使用微软的安全生态系统。
总体任务很简单：**降低组织风险**。
这可能涉及：
* 修复环境中的活跃攻击
* 建议改进威胁防护实践
* 将策略违规行为上报给相关利益相关者
* 调查可疑活动和安全事件
### SOC Analyst 级别与职责
| 职责 | 典型 SOC 级别 |
| ---------------------------- | ----------------- |
| 监控 | SOC Level 1 |
| 分诊 | SOC Level 1 |
| 事件响应 | SOC Level 2 |
| 威胁狩猎 | SOC Level 2 |
| 高级威胁狩猎 | SOC Level 3 |
| 威胁情报分析 | SOC Level 3 |
| 漏洞管理 | SOC Level 3 |
Level 1 分析师通常会花费大量时间**监控和对告警进行分诊**。当事件演变为需要深入调查或响应的安全事件时，Level 2 分析师通常会介入。
Level 3 的职责通常会进一步深入到高级狩猎、威胁情报和以漏洞为中心的活动中。
以微软为中心的 SOC 环境通常使用以下技术：
* Microsoft Sentinel
* Microsoft Defender for Cloud
* Microsoft Defender XDR
* 第三方安全产品和数据源
在这些环境中工作时，熟悉 Microsoft 365、Windows、Azure 服务、网络和脚本概念也非常有价值。
## 理解 SIEM 与 SOAR
在探索 Microsoft Sentinel 本身之前，需要明确两个安全概念：**SIEM** 和 **SOAR**。
### 安全信息与事件管理 — SIEM
**SIEM** 代表**安全信息与事件管理**（Security Information and Event Management）。
SIEM 从多个系统收集与安全相关的数据，并提供一个集中位置，供分析师搜索、关联和分析这些信息。
SOC 无需再从多个单独的系统中手动审查日志，而是可以将安全遥测数据汇集在一起，并在整个环境中搜索模式。
典型的 SIEM 功能包括：
* 收集日志
* 查询安全数据
* 关联事件
* 检测异常
* 生成安全告警
* 根据可疑活动创建安全事件
在实际应用中，SIEM 帮助回答以下问题：
### 安全编排、自动化与响应 — SOAR
**SOAR** 代表**安全编排、自动化与响应**（Security Orchestration, Automation, and Response）。
虽然 SIEM 主要侧重于收集和分析安全信息，但 SOAR 侧重于**在识别出可疑活动之后发生的事情**。
安全团队经常执行重复性的响应任务。自动化该过程的部分环节可以减少手动工作，并让分析师能够专注于真正需要人工调查的安全事件。
SOAR 功能可用于：
* 事件富化
* 自动化调查步骤
* 事件管理
* 响应工作流
* 修复活动
其核心理念是结合安全工具和自动化工作流，使事件响应更快、更一致。⚙️
## 什么是 Microsoft Sentinel？
**Microsoft Sentinel 是一个可扩展的、云原生的 SIEM 和 SOAR 平台。**
它将安全监控和分析与编排及自动化响应功能结合在一起。
在 SIEM 方面，Sentinel 可以：
* 收集和查询日志
* 关联安全事件
* 检测可疑模式或异常
* 生成告警和安全事件
在 SOAR 方面，Sentinel 可以：
* 定义自动化安全工作流
* 使用 playbook
* 自动化选定的威胁响应活动
这为安全团队提供了跨组织安全活动的集中视图。
Sentinel 可以支持：
* 攻击检测
* 威胁可见性
* 主动威胁狩猎
* 安全事件调查
* 威胁响应
其安全运营工作流大致可以分为**四大支柱**：
1. **收集**
2. **检测**
3. **调查**
4. **响应**
理解这四个阶段会让后续理解 Sentinel 变得容易得多。
# Microsoft Sentinel 的工作原理
安全运营始于数据。
没有日志，就没有东西可以关联。没有关联或分析，就无法可靠地检测到可疑活动。没有检测，就没有可以调查的事件或可以自动化的响应。
因此，Sentinel 的工作流遵循安全数据从接入到响应的过程。
## 阶段 1：收集
第一阶段是**收集**。
Microsoft Sentinel 需要对受保护的系统具有可见性。因此，必须从相关数据源接入安全数据。
### 数据连接器
**数据连接器**用于将数据接入 Microsoft Sentinel。
Sentinel 支持大量专为各种微软和第三方技术设计的连接器。
根据环境的不同，数据可能来源于：
* 身份平台
* 端点
* 云基础设施
* 应用程序
* 网络设备
* 安全产品
目标是将相关的安全遥测数据引入集中的分析环境中。
### Log Analytics Workspace
一旦接入数据，就必须将其存储起来，以便分析师和检测系统能够对其进行处理。
接入的日志存储在 **Log Analytics workspace** 中。
然后可以使用 **Kusto Query Language (KQL)** 查询这些数据。
一个简化的 KQL 查询可能如下所示：
```
SecurityEvent
| take 10
```
此查询访问 `SecurityEvent` 表并返回一小部分记录样本。
这里的目的还不是高级威胁狩猎。它只是演示了**存储的日志数据与基于 KQL 的分析**之间的关系。
此阶段的基本流程是：
**数据源 → 数据连接器 → Log Analytics Workspace → KQL**
一旦安全数据可用，Sentinel 就可以开始检测可疑活动。
## 阶段 2：检测
如果没有人能从中识别出有意义的操作，那么收集数百万条日志就没有多大用处。
**检测**阶段将安全数据转化为可见性和可操作的发现。
### 工作簿
**工作簿是 Microsoft Sentinel 中用于可视化的仪表板。**
它们帮助分析师将原始数据转化为更容易理解的视图。
工作簿可以显示：
* 安全趋势
* 事件量
* 身份验证活动
* 告警模式
* 资源信息
Sentinel 提供了内置的工作簿，同时也可以使用 KQL 创建自定义可视化。
当分析师需要对活动有一个更广泛的概览，而不是逐一检查单个日志记录时，这尤其有用。
### 分析规则
**分析规则**提供主动安全分析。
这些规则检查收集到的数据，寻找可能表明可疑行为的活动或模式。
当检测到相关条件时，分析规则可以产生：
* 安全告警
* 安全事件
这是一个重要的区别。
日志是底层数据。**告警**代表检测到的可疑活动。相关的安全发现随后可以成为需要分析师调查的**安全事件**的一部分。
简化的概念流程如下所示：
**日志 → 分析规则 → 告警 → 安全事件**
确切的检测逻辑取决于被监控的规则和安全场景。
### 威胁狩猎
安全团队不能完全依赖等待自动化检测。
**威胁狩猎**是一个主动的过程，分析师在其中搜索可能尚未触发现有告警的可疑活动。
Microsoft Sentinel 提供内置的狩猎查询来支持此过程。
例如，分析师可能会调查异常的身份验证模式、意外的账户活动或与已知攻击技术相关的行为。
KQL 在这里变得尤为重要，因为分析师可以直接查询收集到的遥测数据并测试调查假设。
它不是在问：
而是在问：
这种区别是主动安全运营的基础。
## 阶段 3：调查
当可疑活动触发分析规则时，SOC Analyst 需要了解实际发生的情况。
这就是**调查**阶段的开始。
安全事件为分析师提供了一种结构化的方式，以对可疑活动进行分诊和调查。
典型的事件管理活动包括：
* 更改事件状态
* 将事件分配给其他分析师
* 审查关联的实体
* 检查事件时间线
* 调查相关的安全活动
* 记录调查评论
### 理解实体
在调查过程中，不同的对象可能与可疑活动相关联。
这些可能包括：
* 用户账户
* 主机
* IP 地址
* 应用程序
* 文件
映射这些实体有助于分析师理解围绕一个事件的关系。
例如，一个可疑的身份验证事件可能涉及一个用户账户、一个 IP 地址和一个主机。将这些实体放在一起查看，比独立调查每个日志条目能提供更多的上下文。
分析师实际上是在试图重建事件的全貌：
**发生了什么？**
**涉及哪些系统或身份？**
**活动何时开始？**
**事件之间有何关联？**
**该活动是否构成真正的安全威胁？**
因此，调查远不止仅仅是确认一个告警。
## 阶段 4：响应
一旦对事件进行了调查，安全团队可能需要采取行动。
最后阶段是**响应**。
SOC 团队面临的一个主要挑战是**告警疲劳**。
当分析师被大量的安全告警淹没时，就会发生告警疲劳。发生这种情况时，团队有效识别和调查真正威胁的能力可能会降低。
这就是自动化变得特别有价值的地方。
### 通过 Playbook 实现自动化
在 Microsoft Sentinel 中，自动化工作流被称为 **playbook**。
Playbook 可以自动化选定的安全运营和响应活动。
它们可能支持：
* 事件管理
* 富化
* 调查
* 修复
考虑一个涉及可疑 IP 地址的事件。
自动化工作流可以收集有关该 IP 的额外上下文，用收集到的信息丰富该事件，并在适当的情况下执行预定义的响应操作。
目标不是盲目地自动化每一个安全决策。
相反，自动化应该减少分析师重复性的工作，并使响应过程更加一致。
从概念上讲，工作流变为：
**安全事件 → Playbook → 自动化工作流 → 响应操作**
这种响应和自动化功能代表了 Microsoft Sentinel 的 **SOAR** 方面。
# 四阶段 Sentinel 工作流
整个 Sentinel 安全运营模型可以总结为：
```
Collect
↓
Detect
↓
Investigate
↓
Respond
```
### 收集
通过**数据连接器**接入安全数据，并将其存储在 **Log Analytics workspace** 中。
### 检测
使用**工作簿、分析规则和威胁狩猎**来识别可疑活动。
### 调查
对事件进行分诊、检查实体、审查时间线，并确定可疑活动的范围。
### 响应
使用手动响应流程和自动化的 **playbook** 来管理或修复事件。
这些阶段也与常见的 SOC 职责紧密契合。
监控和初始分诊通常与 Level 1 运营相关，而事件响应和威胁狩猎经常需要 Level 2 的介入。
## 何时应使用 Microsoft Sentinel？
当组织需要**监控云和本地环境的安全威胁**时，Microsoft Sentinel 主要非常有用。
现代基础设施可能涵盖：
* Azure
* 其他云平台
* 本地系统
* 端点
* 身份服务
* 网络基础设施
Sentinel 提供了一个集中的安全运营平台，可以在其中收集和分析来自这些环境的数据。
组织可能会将 Sentinel 用于：
* 可视化安全日志数据
* 检测异常
* 进行威胁狩猎
* 调查安全事件
* 自动化对告警和事件的响应
有几个特点使得 Sentinel 与现代 SOC 环境尤为相关。
### 云原生架构
Microsoft Sentinel 是**云原生的**。
组织无需仅仅为了部署该平台而去配置传统的 SIEM 服务器。
这支持了可扩展性，并减少了与传统安全监控部署相关的一些基础设施管理工作。
### 集中式监控
来自多个来源的安全数据可以被引入到一个集中的平台中。
这提高了跨环境的可见性，并帮助分析师关联那些原本可能孤立在单独工具中的活动。
### 集成
Sentinel 与 Azure 服务及微软更广泛的安全生态系统紧密集成。
其连接器还允许组织从大量外部来源接入数据。
### 自动化事件响应
通过 playbook 和自动化，可以简化重复性的响应活动。
当 SOC 团队处理大量告警时，这尤其有用。
### 混合与多云可见性
组织很少完全在单一类型的基础设施中运行。
Sentinel 可以支持跨云和本地环境的安全监控，这使其对混合安全运营非常有用。
## Microsoft Sentinel 与 Microsoft Defender for Cloud
Microsoft Sentinel 和 Microsoft Defender for Cloud 解决的是相关的安全问题，但它们的主要目标不同。
| Microsoft Sentinel | Microsoft Defender for Cloud |
| ------------------------------- | ---------------------------------------------- |
| SIEM 和 SOAR 平台 | 云安全态势和工作负载保护 |
| 集中式安全监控 | 安全态势可见性 |
| 日志收集和分析 | 配置错误识别 |
| 威胁检测和狩猎 | 安全建议 |
| 事件调查 | 策略和合规性见解 |
| 自动化工作流 | 云工作负载保护 |
如果目标是收集安全事件、关联活动、调查事件并支持 SOC 运营，**Microsoft Sentinel** 是首选平台。
如果目标是了解云安全、识别配置错误并审查安全建议，**Microsoft Defender for Cloud** 更直接地契合该需求。
这两个平台也可以协同工作。
例如，Defender for Cloud 的安全告警可以接入到 Microsoft Sentinel 中。然后，Sentinel 可以将这些发现与其他安全遥测数据相关联，并提供更广泛的事件调查工作流。
## 关键要点 🛡️
Microsoft Sentinel 在一个云原生安全运营平台中结合了 **SIEM 和 SOAR 功能**。
理解其工作原理的最简单方法是通过其四个核心阶段：
**收集 → 检测 → 调查 → 响应**
数据连接器接入安全遥测数据。
Log Analytics workspace 存储收集到的日志。
KQL 允许分析师查询和调查这些数据。
工作簿可视化安全信息。
分析规则根据可疑活动生成告警和安全事件。
威胁狩猎允许分析师主动搜索威胁。
事件提供了结构化的调查工作流。
Playbook 自动化安全运营和响应活动。
这些功能结合在一起，为 SOC 团队提供了一个集中式平台，以跨现代环境监控、检测、调查和响应安全威胁。
Microsoft Sentinel 不仅仅是一个存储日志的地方。其真正价值在于将安全遥测数据转化为**检测、调查和可操作的响应工作流**。
标签：AMSI绕过, KQL, SOAR, SOC运营, 威胁检测, 安全响应, 微软Sentinel, 速率限制