优化 SOC · 攻击 SOC

好吧，你有那些闪烁的框框和五颜六色的仪表板，显示着没人记得为什么想要查看的数据。你甚至在所有的 KQL 图表中放了表情符号，因为你可以。你对那个“在这里输入提示...”的框子垂涎欲滴，预算在你口袋里烧了个洞。

这就是你：

追逐一个似乎长了翅膀的球门。如果你转过身，你会看到你正在大量流失假阳性，你有很多未诊断的系统健康警报，还有一些未知的未知，不是因为“这就是事物的本质”，而是因为你没有给自己一分钟的时间坐下来思考。

在这篇文章中，我们将看看 Microsoft 统一安全运营平台内置的一些功能，以及一些没有内置的功能，以帮助你清理并优化你的 SOC，恢复到一个干净的状态。这篇文章的大部分内容是我在过去几年中找到的一系列解决方案，也是一些其他出色的人花时间构建这些解决方案并与大家分享的成果。给他们一个感谢。

需要解决的问题

1. 数据收集健康
2. 假阳性
3. ATT&CK 覆盖
4. 演练本健康

数据收集健康

Sentinel 工作簿

你知道你的数据收集器是否停止了数据摄取吗？你能否检测到来自 DnsEvents 表的事件异常增加？要回答这些问题以及更多问题，你需要从 Sentinel 内容中心安装以下工作簿。

微软文档提供了足够的细节，但为了快速概述，你可以获得指定时间范围内的数据大小、每条记录的平均大小和每秒事件数等信息。你可以查看可视化趋势数据，以识别你的数据摄取在几周和几个月内的实际情况。

我喜欢这个工作簿的一个地方是顶部的第二个标签，数据收集异常。这个标签帮助你使用时间序列分解、线性回归 和Tukey 的围栏 来识别数据收集基线中的异常，这些是一些系列异常和离群值 KQL 函数的基础。通过调整阈值和采样间隔，你应该能够快速找到数据中的关注区域。

需要注意的一点是，确保你的时间范围 和采样间隔 互为补充。例如，你在周末的数据收集将与工作日看到的完全不在一个范围内。因此，如果你有 30 天的范围，那么选择 7 天的间隔。60 天的范围，则选择 14 天的间隔。相应调整。

你可以很容易地通过点击每个图表右上角的日志分析图标，将此工作簿中的数据转换为警报，以便生成超出基线的数据收集警报。

数据摄取失败警报

说到数据收集失败的警报，来自微软的优秀Rod Trent 分享了他关于如何在 Microsoft Sentinel 数据停止填充时收到通知 的解决方案。在他的文章中，Rod 分享了识别数据摄取失败的查询和如何配置分析规则以确保你收到通知的说明。

当然，你可以根据自己的喜好调整查询。假设你有一个关键表格，你希望在 3 小时内没有摄取后收到通知。让我们取这个公式并调整为仅 3 小时：

60 秒 x 60 分钟 x 3 小时 = 10,800

所以然后：

HuntingBookmark|where TimeGenerated > ago(4h)| summarize last_log = datetime_diff("second",now(), max(TimeGenerated))|where last_log >=10800

然后确保调整查询调度参数以适应这些更改：

这样就设置好了。

Azure Policy 简介

你能百分之百确定每个 Arc 管理的服务器都与数据收集规则 (DCR) 关联吗？你能多快识别出不合规的资源？你是否有补救计划？好在有一个工具可以解决这些问题，那就是 Azure policy。

正如其名，你可以使用 Azure Policy 制定策略定义，帮助你在环境中执行标准。你可以创建新的策略定义，也可以使用任何内置的策略定义，这些本质上是 JSON 格式的规则。这些规则定义了你的资源必须满足的条件。例如，我们可以要求 Arc 服务器安装 AMA（代理）并且机器与数据收集规则关联。

这有一个内置的策略定义，定义 ID 为：/providers/Microsoft.Authorization/policyDefinitions/ef9fe2ce-a588-4edd-829c-6247069dcfdb

在这个策略定义模板中，你只需要定义几个参数，比如策略范围（目标订阅和资源组）以及通过其资源 ID 指定所需的数据收集规则。接下来，我们选择是否允许此策略创建补救任务。是的，这意味着该策略定义将尝试自动修复任何不合规的资源。请注意，系统会创建一个系统分配的托管身份来执行补救任务，这是你应该预料到的。

最后，审查并创建。你的策略会根据各种触发器进行评估，但我始终建议在查看合规性仪表板之前保持耐心。

要查看资源的合规性，请转到 Azure Policy > 合规性，然后在列表中搜索你创建的策略定义名称。点击进入你的策略可以深入了解不同资源，确定它们失败的原因以及是否创建了补救任务。

最后，为了更有效的报告和策略组织，你可以将类似的策略定义分组到所谓的计划中。假设我们有多个基于 DCR 的策略定义，一个用于 Windows 事件，一个用于 DNS，另一个用于 Syslog 等。我们可以将这些组合成一个名为"Arc 管理服务器数据收集"的计划。然后我们会定义我们想要在这个计划范围内的策略，以及允许未来策略被纳入这个计划的条件。

正如你所想象的，这只是 Azure Policy 功能的一个简单用例。在这里，我们建立了一个保障，确保我们从受管理资源的数据收集得到覆盖，无论是现有的还是新的资源。

警报....唉

警报疲劳的历史

每次打开事件队列时，你是否会呻吟，翻白眼，然后关闭浏览器标签页，自言自语说"我稍后再处理这些"？好吧，这就是警报疲劳，我的朋友，这不是开玩笑的。它会影响你的心理健康，让你和团队成员处于风险之中，更不用说当工作变得单调乏味时对组织的影响了。

本节中的很多内容可能会感觉很常识，但我们还是要讨论这个问题。

Anton Chauvkin 博士写了一篇关于这种现象的精彩文章，并为如何开始对抗这个持续了半个多世纪的问题奠定了一些重要基础。在这里阅读"Anton 的警报疲劳研究"。

这篇文章几乎涵盖了我想在这里写的所有内容，他还添加了很多关于这个问题的精彩信息和背景。去读读吧！

审查分析规则的效率

读完了吗？现在让我们来看看一个资源，它将帮助我们识别误报问题区域。我的一位同事发现了来自我们的朋友Bert-Jan（来自kqlquery.com）的这个令人印象深刻的查询。他简单但强大的分析规则效率查询提取并分类了过去 30 天的所有警报，以易于阅读的格式显示，让你能够快速找到问题区域。

通过这些结果，我们可以找出那些填满我们警报源的规则，并根据 Anton Chauvkin 博士制定的行动计划采取行动。需要注意的一点是，结果中没有显示的任何分析规则也应该被审查。这些规则正在运行，因此正在扫描数据行并花费你的钱。它们真的为你做了什么有用的事情吗？

在处理这些规则时，问问自己以下问题：

1. 为什么我需要这个警报，和/或我是否有能力采取行动？
2. 我能调整逻辑来降低误报率吗？
3. 我能禁用这个规则的警报，或者用它来丰富其他警报/事件吗？

ATT&CK 覆盖

你是否覆盖了你的 ATT&CK 图谱？

继续我们关于队列中的警报是否真正对我们有意义的讨论。我们有几种方法可以回答这个问题。幸运的是，MITRE 已经创建了一个框架，我们可以基于它来开展一些工作。

我们的另一位朋友，来自https://www.michalos.net/ 的Michalis Michalos 写了一份深入的指南：使用 Microsoft Security 实施 MITRE ATT&CK - 第 1 部分和第 2 部分。在这份指南中，Michalis 介绍了 ATT&CK 框架如何在整个 Microsoft Security 生态系统中使用，以及我们如何在检测和分析规则中实施它。在第 2 部分中，他介绍了 Sentinel ATT&CK 图谱，这是确保你和你的主管确信你确实在保护资产的最佳工具，它提供了一个可视化矩阵，实时映射你当前环境中的规则和查询。

用例映射工作簿

我的同事发现的另一个很棒的工具是最近由微软的Mario Cuomo（他的网站是mariocuomo.github.io）发布的这个出色的工作簿。他的工作簿（解决方案）用例映射器为你提供了一个工具，可以识别内容中心中可用的解决方案（分析规则和搜寻查询），这些解决方案映射到特定的 ATT&CK 框架战术，并显示你的覆盖范围。结合你从 Michalis 那里学到的信息，你应该已经完全掌握了。

剧本健康

又一个 Sentinel 工作簿

如果你正在使用"剧本"或 Logic Apps（你绝对应该使用），你是否也在监控它们的健康状况？你知道上个月它们失败运行了多少次吗？你知道它们的平均运行次数和平均运行时间吗？

如果你对这些问题中的任何一个回答"不知道"，那么请确保你安装了微软提供的工作簿剧本健康监控（预览版）。它为你提供了自动化环境的快速鸟瞰视图，让你能够快速识别已停止工作的剧本和可以优化以降低成本的自动化。

Logic App 警报规则

可视化总是很好，但是如果我们能以较低的成本收到剧本运行失败的电子邮件，那不是很好吗？这就是警报规则发挥作用的地方。

请记住，如果你有大量运行的自动化，比如用警报中的实体数据丰富警报的剧本，你可能会收到大量消息。在这种情况下，最好采用工作簿方式，进行一些手动诊断。

我建议转到监控控制台 > 警报 > 创建 > 警报规则。你必须一次完成一个（每个逻辑应用），因为选择每个警报规则的多个资源可能（而且确实）会禁用使用基于指标的信号的能力。在警报规则创建向导中，选择你要限定范围的逻辑应用。接下来在信号选项卡上，选择"运行失败"信号。现在你必须决定对该逻辑应用最有意义的条件。

对于这个例子，让我们假设这个逻辑应用是非关键的，每天运行一次。

我这样设置是因为可能会由于某些原因出现故障，但在下次运行时会自行纠正。或者可能 Microsoft 自动化引擎或目标 API 端点正在进行维护。这允许非关键自动化失败，但会提醒我长期失败。

接下来是操作。选择"使用快速操作" > 电子邮件，剩下的由你决定。点击保存。在下一个选项卡上添加一些详细信息，审查并创建....重复这个过程。这些每个平均每月大约 0.10 美元，对大多数人来说不是什么大问题，但要注意这一点。

值得一提的内容

SOC 优化

你无疑已经知道新的SOC 优化工具，如果你不熟悉，请点击链接了解。微软专门开发它来帮助你和你的团队优化 SOC 运营，并按照预期方式使用整个平台。是否有你忽视的数据源？是否有你装备不足以检测的攻击类型？你会在优化报告中找到所有这些内容和更多信息。

我不会在这里详细介绍，因为微软已经做了：

FastTrack

最后，如果你是潜在的微软客户，或者如果你已经在使用这些工具并需要审查和最佳实践指导，那么Microsoft FastTrack 团队就是你要找的。FastTrack 团队中有一些人活跃在社交媒体社区，有一些人参加过几个播客，很容易看出他们是一个出色的团队。他们都是受过高等教育的人，深入了解他们的工具，更重要的是，他们知道如何教授这些知识。

最后的想法

这绝不是一个详尽的列表，但对于让我们的安全运营有序来说是一个很好的开始。我们确保我们需要的数据正在进入，并且我们有办法识别这个系统何时出现故障。然后我们消除令人疲惫的警报，以防止团队疲劳，为更有价值的工作腾出时间。接下来我们确保我们有的警报可以映射到有意义的 TTP。最后，我们寻找为我们的自动化创建问责制的方法，失败警报和工作簿来可视化我们环境中每个剧本的性能。

我给你留下这些最后的话；很多时候我们都在寻求实施最新的解决方案，为最新的情报创建下一个检测，并集成另一个 SAAS 应用程序的日志流。我们很少回去调整那个嘈杂的规则，创建更智能的解析器，或在我们的自动化中添加那行代码使其运行得更有效率。这一切就像一堆积木一样越堆越高。与其采取"现在先让它运行起来，以后再修复"的方法，不如现在就着手解决它。

承诺本周花时间清理整顿

感谢阅读

一如既往，我希望你能从中找到一些有用的内容，并能带着让你的环境更有效率的计划离开。本文提到的这些人都是社区中优秀的成员，他们不断构建和分享，请务必关注他们，你会学到很多，不会后悔的。现在去创造一些东西并与社区分享吧。

下次再见，在 Attack the SOC！