检测工程流程

本次网络研讨会最初于2024年11月8日发布。

在视频中，Hayden Covington讨论了检测工程流程以及如何应用科学方法来提高检测质量。讨论内容包括创建高质量检测所涉及的步骤，如研究、查询构建、回测和持续改进。Hayden强调了结构化流程、文档编写以及激情和热情在网络安全工作中的重要性。

检测工程涉及应用科学方法来提高检测的质量和一致性。
创建高质量检测的过程包括定义检测故事、进行研究、构建查询和持续改进等步骤。
结构化的检测工程流程可以带来更明确的范围定义、更高质量的检测和整体安全管理的改进。

亮点

1:35 理解检测工程术语和科学方法：澄清检测工程术语如“检测”、“告警”和“工单”，确保观众理解；讨论科学方法。
1:14 构建PSExec明文认证检测的结构化方法：通过形式化的检测故事探索构建PSExec明文认证检测的结构化流程。
1:03 研究及文档在检测流程中的重要性：从彻底的调研和文档记录开始，根据初始检测故事提炼见解以进行有效分析。
1:40 回测的重要性：为有效检测实施做准备：在发布检测规则前，针对历史数据回测查询以优化准确性，并为未来参考记录结果。
1:16 谨慎使用真实数据确保检测准确性：通过回放真实数据确保检测准确性，但需注意设置变更可能影响静态数据随时间推移的可靠性。
1:12 检测工程中的高效告警管理：通过主机和用户名配对抑制重复告警，确保调查专注而不受干扰。
1:06 检测工程的演进：将科学方法应用于告警：检测工程涉及通过研究和科学方法演进和调整告警，将检测视为演进的理论。
2:06 检测工程中自动化与人工监督的平衡：AI可以简化检测工程，但仍需人工监督以确保安全流程的准确性和可靠性。
1:01 Black Hills：充满激情和投入的SOC分析师提供增强的安全解决方案：Black Hills培养充满激情的SOC环境，提供技术精湛且乐于协作解决问题的分析师。

完整视频

文字记录

Jason Blanchard 大家好，欢迎来到今天的Black Hills信息安全网络研讨会。我是Jason Blanchard，是Black Hills的内容社区总监。如果您需要红队威胁狩猎、主动SOC、ANTISOC或我们提供的任何其他服务，您知道在哪里可以找到我们。但今天我们有——Hayden将和您聊聊他想聊的话题。也就是检测工程流程。我们的做法是联系在Black Hills工作的每一位技术人员，问他们是否愿意做一个网络研讨会。很多时候他们会说，我不知道该讲什么。然后Hayden，我联系了他，他说，哦，我有个主意。让我从我正在准备的课程中提取一些材料，然后来做这个。所以Hayden正在从他为Antisyphon培训组织设计的课程中提取材料，并将在今天作为免费网络研讨会的一部分进行分享。但Hayden是我们SOC的一员。 Hayden，你的生活围绕着检测工程。这是你一直在做的事情，对吧？

Hayden Covington 是的。没错，确实如此。这占用了我很长时间，尤其是最近。

Jason Blanchard 是的。Hayden去年参加过一次网络研讨会。效果非常好——不是要抬高期望，不是要让Hayden觉得，哦，天哪，别这样。但去年确实很棒。我们当时说，嘿，你应该整理一门课程。你应该回来。你应该做这个。我讨厌我把这些都强加给他。但是，Hayden挺身而出，创建了一门课程，并且今天将继续进行这个网络研讨会。所以我要退到后台。Hayden，如果你在任何时候需要我，我会再出来。如果你因为任何原因消失了，我会再上来。但非常感谢你的参与。请加入我们的Discord。如果你还没有为Hackett签到，请务必签到。我们会记录你参加的网络研讨会次数。一旦达到10次，我们会给你发送奖励。达到20、30、40和50次，我们也会发送奖励。我们感谢你的到来。今天你本可以在很多地方，但你决定来这里，我们对此表示感谢。好了，Hayden，现在交给你了。

Hayden Covington 太棒了。谢谢。正如Jason所说，这些内容很多直接来自我的课程。稍后我会再谈谈那门课程。那是最后的部分。这样，如果你不想听那部分，你只需要听关于检测工程的内容——如果你看不出来，我对此有点兴奋——但不管怎样，或者看幻灯片，今天谈论检测工程，以及我认为你应该如何将科学方法应用于该流程以获得更好的输出。但我已经超前了，所以我们来看第一张幻灯片。我是谁？Jason稍微提到了一点。我在Black Hills SOC工作。我是一名SOC分析师、检测工程师、安全工程师，谁知道呢？我做了很多不同的事情，但我确实花了相当多的时间为Black Hills和其他公司做检测工程。就个人而言，我是那种极度A型人格，高度有条理、非常具体、有规划，虽然不是刻板，但绝对非常非常具体和有意为之，与此相符的是我的一些个人兴趣。我是一名铁人三项运动员。我痴迷于一级方程式赛车。所以这两件事在数据方面、在这种人格类型方面高度相关。我上次做的网站、上次的网络研讨会是关于SOC指标的。这让你对我有个大致了解。

说到这里，我们先来看几个关键术语。我想先介绍这些，以确保当我说到某些东西时，你明白我在说什么。检测工程有很多不同的术语。一个很好的例子（虽然没在这张幻灯片上）是误报。这对很多人来说可以意味着很多不同的事情。所以我想在这里先统一一下，当我说某个词时，你能准确理解我想表达的意思。所以，检测或规则是指搜索语法，通常在你的SIEM中，用于检测活动。这就是检测或规则。告警是检测的输出。然后工单是最终进入你工单系统的内容。所以一般来说，至少对Black Hills来说，情况是这样的：我们有一个检测规则触发，该检测规则创建一个告警，然后该告警根据不同的标准可能会也可能不会进入工单系统。所以先统一一下，这样当我交替使用这些词时，你知道我的出发点。检测或规则我会交替使用。但如果我说告警，我指的是告警，不一定是工单。但话说回来，稍微谈谈科学方法。科学方法，科学通常会遵循一个非常静态和严谨的方法来得出形式化的结论。这个过程是：观察、研究、假设、实验、分析、结论。然后你不断重复，我敢肯定你们有些人可能还记得学校里教的这个，这是一个非常具体的方法，说明事物如何从观察变成理论。所以，就这里的科学方法而言，你的流程大致从你进行观察开始，你看到某事然后说，哦，好吧，让我们进一步研究一下。当你研究它时，你可能会形成一个假设。当你经历这个过程时，它从观察变成了假设。然后你开始实验。你根据你的假设验证你认为的情况。如果我说的太快了，假设基本上就是一种简单的说法，或者说一种科学的说法，表达你认为的情况是什么。所以这是你对此特定情况的断言。然后你的实验，你测试它，检查结果，判断它是否符合你的假设。如果符合，那很好。如果不符合，你就修改它。这个过程的最终目标是让你的工作变成科学理论。所以科学界的理论基本上是，它是可以被反复测试和验证的东西。原子理论就是一个很好的例子，即一切都是由原子构成的。你可以测试它，而且它已经被测试了很长时间。并且它是可重复的，你可以验证它。但它并非一成不变。随着时间的推移，随着新事物的发现，它确实发生了变化。但检测工程的等效物是什么？那么，检测工程的理论等效物是什么？检测工程的理论将是一个高质量的检测。它是经过充分研究、充分记录的。它是可验证、可复现、持续改进的。它是一个你建立起来、理论化的假设，你不断地、反复地测试它以确保其有效性。所以你可能会想，这和检测工程有什么关系？这次网络研讨会的重点是什么？我们能不谈学校的事了吗？你可能正在这么想，也许不是。但我会将那个科学过程与检测工程过程对应起来，并向你解释如何以类似的方式进行，从而得到更好的结果，或者至少是更一致的高质量检测结果。所以这两个过程如果你以正确的方式看待，是可以对应起来的。你从一个检测故事开始，我会介绍每一个步骤，并且我们实际上会走一遍每个步骤的例子。但你会从检测故事开始。你基于那个故事进行研究。你构建查询，回测数据，构建金丝雀和文档，然后上线它。这并没有结束，你还要持续改进它。就像它是一个理论一样，不断地验证并确保它成立。检测工程这边的假设可以从你的研究阶段开始。它不一定非要从检测故事开始。你可能在研究某件事时说，哦，这将是一个很棒的检测。但在很多情况下，它通常会有某种输入，我们稍后会通过并排比较来讨论。它们对应得相当好。所以你的观察就是你的检测故事，是你的假设或研究。你的查询和回测将是你的实验。你的金丝雀是验证和确认你的假设，你的数据也在验证它是否有效。作为你实验的一部分，检测工程的文档将类似于你的报告。然后当你上线你的检测并改进它时，那将是你的理论。所以我稍微谈了一下，但这为什么重要呢？那么，实际遵循一个流程有什么好处？是不是只会增加更多时间？它可能会给你的检测工程流程增加一点时间。但你为什么要在乎呢？有几个原因。首先是范围定义更清晰。如果你以这种方式构建检测，你从一开始就定义了范围，至少比你可能的更清晰。它将使你更好地专注于该检测的预期输出。你会更容易理解你在寻找什么。因为在这个过程中 inherently 内置了研究和文档。所以当你在构建东西时，你已经研究了你正在寻找的东西。你不会遗漏任何步骤。所以当你经历一个框架、一个流程时，不必担心忘记中间的步骤会容易得多。最终目标是让你的检测具有更高的整体质量。如之前承诺的，将把它应用到一个场景中。我们将逐步完成每个步骤，基本上构建一个检测。所以这个检测将是PSExec明文认证。

所以第一步是检测故事，我们将从这里开始。检测故事，它是一种方式，是你的输入，将是你的初始输入。在很多方面，我们称之为检测故事。对你来说，它可能只是有人提交给检测工程团队的一个工单。但这个检测故事应该以结构化的方式完成。你应该有做这个的理由。检测应该有数据源。你有一些示例量，一些工件。你不应该只是一个工单说，嘿，你能为PSExec做一个检测吗？它需要更公式化或更形式化。你需要对它进行审查。在接受这些之前，你需要能够要求某些东西。否则，你会浪费大量时间去猜测原始人员想要什么，原始请求者想要什么，或者在某些情况下，你可能会做出一个完全不必要的检测。正如我提到的，这些来源可能来自你的同事，可能来自你的管理层，但也可能来自博客、文章、客户请求。就这个例子而言，它来自一次先前的攻击。所以这个特定的检测，我展示的是命令行日志。这是一个在恶意流量中观察到的IOC。所以这是PSExec，它传递一个主机列表，然后以用户身份通过命令行明文传递密码进行认证。然后它提供并将恶意软件复制到该主机列表中每台机器上的特定文件夹。所以在这种情况下，对于检测故事，提交它的人，他们的理由可能只是，观察到的恶意IOC或恶意流量。你的来源可能是Windows。然后预期量完全取决于你的环境。但稍微剧透一下，对我们和我们监控的客户来说，预期量很低。然后工件非常重要，如果你有的话。所以链接到资源。这就是检测故事。

下一步，这个流程的第一个正式步骤，因为我把检测故事算作初始输入，将是你的研究。所以研究和记录你在进行过程中发现和尝试的东西，当你尝试查询，看看什么有效什么无效时。你应该记录你发现的所有东西，所有报告、细节。如果它们与最终产品无关，你以后总是可以删除它们。但是，我强烈建议你把这些东西写下来，以防以后需要。一个好的检测需要你充分理解你在寻找什么。这项研究应基于最初的检测故事。你需要非常小心这个范围。你很容易发现自己扩展得太远。比如，你可能会从PSExec明文认证，变成只是寻找PSExec，或者PSExec与文件共享交互，然后你突然发现自己实际上在处理四个不同的检测。或者你可能有些东西本应是四个不同的检测。你会有点分心。所以要小心范围，对于这个场景。就研究而言，这相当简单。我们需要研究什么以及如何检测它，基本上就是去看看psexec的不同命令标志。很明显，有一个破折号P标志，你用来在psexec中传递密码，然后还要研究这是否应该发生。所以在某些情况下，我从我们这里的一些防御人员那里听说，PSexec是邪恶的，你永远不应该使用它。我不会说我是否同意这一点。但最终的重点是，对于这个特定情况，什么是最佳实践。所以psexec -P，那看起来像什么？这样好吗？坏吗？应该发生吗？不应该吗？长话短说，你绝对不应该这样做。如果你不传递破折号P标志，它需要一个交互式密码，这才是你应该做的。将其以明文形式放在命令行上让任何人都能看到，这并不理想。攻击者为什么会以这种方式运行它？嗯，一个很好的例子是，在这种情况下，它是通过批处理脚本运行的，所以通过bash脚本大规模运行这种方式要容易得多。而且他们甚至不必在电脑前它也能运行。所以你有了你的研究，大致知道你想寻找什么。标志，你想尝试检测的东西。此时你可能有一些示例逻辑。现在是你需要形式化你的查询的时候了。这是你检测的核心部分。在很多方面这是最重要的部分，因为如果你没有好的查询，你就不会有好的输出。所以应尽可能由你的研究来指导。当你在研究时，你也会看到一些你可能想排除的东西。例如，当我们在研究这个时，我们注意到，嘿，我们的一个用户或一个遗留应用程序必须这样做。这不太好。但这可能是你研究过程中发现的东西，是你想做和不想包含的内容。你可能会尝试多个查询，并评估它们的不同结果。我们将在流程后面更大规模地这样做。但现在，运行一些基本查询以了解结果的样子，是个好主意。你不想得到一个查询，然后运行五分钟，觉得，嘿，太棒了，然后继续往下走四步，结果后来才发现你实际上没有看到你需要看到的东西。你可能还需要选择查询语言。现在是时候选择了。我们使用Elastic，所以有KQL、EQL、ESQL、Lucene以及像十亿种其他语言，还有他们下周想出来的任何新语言。在这个例子中，我不会剧透我们将为这个检测使用哪一种。但这一步的重点是，你需要找到一个平衡点。所以如果你的查询太宽泛，你面临分析师倦怠、高容量的风险。你甚至可能有太多事件，以至于你想要的关键事件被埋没在那一大堆工单中。如果你有太多工单，你的SOC也会非常不喜欢你。我们显然目标是中间地带，我们希望在数量和保真度之间取得非常好的平衡。我们希望我们的检测能看到我们想看到的一切，但我们也希望当它触发时，是真阳性的比率非常高。另一方面，如果你太窄、太具体，你可能会遗漏一些小东西。例如，如果你寻找破折号p，而密码在括号或引号里，等等。那将是太窄的一个例子。或者你寻找破折号P，而他们在之前传递了一个文件。对于这种情况有很多例子可能太宽或太窄。目标再次是中间地带，找到一个中间点，让你能看到足够多的事件，但又不会多到让你的检测因为数量而变得无用。对于这个检测场景，KQL（不是Kusto）。这是Kibana查询语言。对于像这样的情况，它有一个非常简单直接的方法，即process.name字段和process.args字段（一个数组或列表，记不清了），但破折号P会作为单独的值出现在这个process.args字段中。正如你在截图中看到的。所以在我们的例子中，如果我们搜索进程名psexec和进程参数P，只要出现参数P的情况，无论其他参数是什么，这都能捕捉到。所以这就是那个良好中间地带的例子，我们不是太具体，但也不是查看所有的P.S. exec。如果这是一个生产检测，我还会强烈建议做其他几件事，比如将process.name字段全部转为小写，这样无论大小写如何你都能匹配。然后还要寻找一些PSexec的仿冒名称。或者也许更好的是，稍微理论化一下，可能有一种方法可以寻找类似的执行，比如查看整个命令行参数，然后也查看PSexec服务是否被安装。所以有很多方法可以让你在这方面更具体。但对于我们的情况，对于这个示例，它超级简单。所以是进程名和参数破折号P。

现在是检验你到目前为止的工作是否会产生你想要的结果的时候了。我稍微提到过。但在上线和发布检测之前估算你的量是你绝对需要做的事情，否则你的SOC会拿着干草叉和火把来找你。而那可不是你想要的事情。那么这看起来像什么？有些地方会这样做，有些地方可能你从未听说过做回测或回填或随便你怎么叫它。所以对我来说，这看起来像是我想让我的查询针对过去90天的数据运行。90天是理想的。30天是绝对最低要求。但你需要回顾过去，看看这个检测在历史上会是什么样子，时间越长越好，说实话。当你这样做时，你可能会发现需要过滤掉的东西。你可能会说，哦，糟糕，我们有个客户以这种特定方式做这件事。他们应该这样做吗，不应该吗？或者在某些情况下，你会和他们谈谈。但在其他情况下，可能是你需要过滤掉的东西。在某些情况下，你可能最终不得不根据这次回测重写部分查询。不幸的是，在做这个回测步骤时，我强烈建议的另一件事是保存你的结果。如果你在回测中没有看到任何结果，把它记录在某个地方，记录在你正在编写的文档中，对吧？边做边记录。保存截图，保存你的查询，保存你进行测试的时间段。这样如果以后它开始疯狂触发，你可以说，嘿，我尽职尽责了，对吧？就像我说的，可能有些不幸的情况，当你做回测时。如果量非常大，你可能有两个选择，或者也许三个选择，你可能最终不得不完全放弃这个检测想法。这并非闻所未闻。或者，你可以有两条不同的路可走。其中一条是，你可以把它作为一个比你最初预期的优先级更低的检测。那可能很糟糕。但在很多情况下，这比没有检测要好。所以把它作为比你最初说的优先级更低的检测，你至少仍然能获得那种可见性。或者，你可以重新评估你的查询。所以也许有一种方法可以重新制定你的查询，避免大量噪音。查看所有事件之间的公共字段，堆叠数据，查看发生最多的是什么。如果你在乎，你可以查看堆叠的数据，然后说，嘿，每次我们看到这个并且它是合法的时，这个标志也在这里，或者它是从这个位置运行的，堆叠数据，看看什么突出，看看什么是最常见的，然后考虑你可以过滤什么，不能过滤什么来消除所有噪音。对于这个