检测工程流程

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

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

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

亮点

完整视频

转录

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

Hayden Covington：
是的， definitely。这占了我很多时间，尤其是最近。

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指标的，这可以让你对我有个大致了解。
说了这些，让我们先看几个关键术语。我想先覆盖这些，以确保当我说某些词时，你明白我在说什么。检测工程有很多不同的术语，人们使用的方式也不同。一个很好的例子是“误报”（false positive），这对很多人来说可能意味着很多不同的事情。所以我想在这里统一一下，这样当我说某个词时，你就能准确理解我想表达的意思。

• 检测或规则（Detection or Rule）：通常是SIM中的搜索语法，用于检测活动。
• 警报（Alert）：检测的输出。
• 工单（Ticket）：最终进入工单系统的内容。
  一般来说，至少对Black Hills来说，我们有一个检测触发，该检测创建一个警报，然后该警报根据不同的标准可能会或不会进入工单系统。所以统一这些术语，这样当我在后面 interchangeably 使用这些词时，你知道我的意思。检测或规则我会 interchangeably 使用，但如果我说警报，我指的是警报，不一定是工单。
  现在谈谈科学方法。科学通常会遵循一个非常静态和严谨的方法来得出正式结论。这个过程是：观察、研究、假设、实验、分析、结论，然后不断重复。我敢肯定你们中有些人从学校就记得这个，这是一个非常具体的方法，从观察到理论的过程。
  在科学方法中，你的过程从观察开始，你看到一些东西，然后说：“哦，好吧，让我们进一步研究一下。”随着你的研究，你可能会形成一个假设。随着过程的进行，它从观察变成假设，然后你开始实验，验证你的假设。如果我 breezed over，假设基本上只是用一种科学的方式说你认为的情况是什么。所以这是你对特定情况的断言。你的实验测试它，检查结果，确定它是否与你的假设一致。如果一致，很好；如果不一致，你就修改它。这个过程的最终目标是让你的工作变成科学理论。
  科学界的理论基本上是可以反复测试和验证的东西。原子理论就是一个很好的例子，一切都是由原子组成的。你可以测试它，而且它已经被测试了很长时间，它是可重复的，你可以验证它。但它并不总是一样的，随着时间的推移，随着新事物的发现，它发生了变化。
  但检测工程的等价物是什么？检测工程的理论等价物将是一个高质量的检测。它是经过充分研究、充分文档化的，可验证、可重现，并且不断改进。这是一个你建立、理论化并不断反复测试以确保其有效的假设。
  你可能在想，这与检测工程有什么关系？这次网络研讨会的重点是什么？我们能停止谈论学校吗？这可能是你的想法，也许不是。但我会将科学过程与检测工程过程对齐，并解释如何以同样的方式进行，从而获得更好的结果，或者至少是更一致的高质量检测结果。
  这两个过程如果你以正确的方式看待它们，可以对齐。你从一个检测故事开始，我会覆盖每一个步骤，并实际 walk through 一个例子，看看每个步骤是什么样子。但你从一个检测故事开始，基于那个故事进行研究，构建查询，回测数据，构建金丝雀和文档，然后上线它。但这并没有结束，你 continuously improve it。就像它是一个理论一样，不断验证并确保它 holds up。
  检测工程方面的假设可以从你的研究阶段开始，不一定从检测故事开始。你可能在研究一些东西时说：“哦，这会是一个很棒的检测。”但在很多情况下，它会有某种输入，我们会讨论将这两个方面进行比较。它们对齐得很好。你的观察是你的检测故事或你的研究。你的查询和回测将是你的实验。你的金丝雀是验证和确认你的假设，你的数据也验证它是否有效。作为你实验的一部分，检测工程的文档将是你的报告。然后当你上线你的检测并改进它时，那将是你的理论。
  我稍微谈了一下，但为什么这很重要？遵循一个流程有什么好处？它会不会只是增加更多时间？它可能会给你的检测工程流程增加一点时间，但为什么你应该关心？
  有几个原因。首先是一个更明确的范围。如果你以这种方式构建检测，你从一开始就会定义范围，至少比你可能做的更多。它将让你更好地专注于该检测的预期输出。你会更容易理解你在寻找什么。因为在这个过程中 inherently built in 会有研究，会有文档。所以当你在构建东西时，你已经研究过你在寻找什么，你不会错过任何步骤。当你经历一个框架、一个过程时，不必担心忘记中间的步骤会容易得多。最终的目标是让你的检测具有更高的整体质量。
  如承诺的那样，我们将把它应用到一个场景中。我们将 walk through 每一个步骤，基本上构建一个检测。这个检测将是PSExec明文认证。
  第一步是检测故事，我们将从这里开始。检测故事是一种方式，它是你的输入，将是你的初始输入。在很多方面，我们称之为检测故事。对你来说，它可能只是有人提交给检测工程团队的一个工单。但这个检测故事应该以结构化的方式完成。你应该有一个理由，检测应该有数据源，有一些示例量，一些工件。你不应该只是一个工单说：“嘿，你能做一个PSExec的检测吗？”它需要更公式化或更正式化。你需要对它进行审查，需要能够在接受这些之前要求某些东西。否则，你会浪费很多时间猜测原始人想要什么，或者在某些情况下，你会做一个完全不必要的检测。
  这些来源，如我所说，可能来自你的同行，可能来自你的管理层，但也可能来自博客、文章、客户请求。在这个案例中，它来自之前的攻击。所以这个特定的检测，我向你展示了命令行日志。这是一个在恶意流量中观察到的IOC。
  所以这是PSExec，它传递一个主机列表，然后以用户身份用明文密码在命令行上进行认证，然后将恶意软件复制到该列表中每台机器上的特定文件夹。所以在这个案例中，对于检测故事，提交的人的理由可能只是“观察到恶意IOC”或“恶意流量”。你的来源可能是Windows。预期量完全取决于你的环境。但稍微剧透一下，对我们和我们监控的客户来说，预期量很低。工件如果你有的话非常重要，所以链接到资源。
  这就是检测故事。下一步，这个过程的第一步正式步骤，因为我把检测故事算作初始输入，将是你的研究。
  研究和记录你发现的东西，并在进行过程中尝试。当你进行实验时，尝试查询，看看什么有效什么无效，你应该记录所有你发现的东西，所有报告、细节。你以后总是可以删除它们，如果它们与你的笔记中的最终产品无关。但我真的 highly recommend 你写下这些东西，以防以后需要。一个好的检测需要你充分理解你在寻找什么。这项研究应该基于最初的检测故事。你应该非常小心这个范围。你很容易发现自己分支太远。比如，从PSExec明文认证到只是寻找PSExec，或者PSExec与文件共享交互，你突然发现自己正在做实际上是四个不同检测的东西，或者应该是四个不同检测的东西。你会在过程中分心。所以小心范围。
  对于这个场景，研究相当 straightforward。我们需要研究如何检测这个，基本上只是去查看psexec的不同命令标志。很明显，有一个 dash P 标志，你用它来在psexec中传递密码，还研究是否应该发生这种情况。所以在某些情况下，我从我们的一些 defer 同事那里听说PS exec是邪恶的，你永远不应该使用它。我不会说我是否同意这一点。但最终的重点是，对于这个特定情况的最佳实践是什么。所以psexec P，那是什么样子？好还是坏？应该发生吗？不应该？长话短说，你绝对不应该这样做。如果你不传递 dash P 标志，它需要一个交互式密码，这是你应该做的事情。在命令行上以明文形式让任何人都看到，并不理想。攻击者为什么会以这种方式运行它？一个好的例子是，在这个案例中，它是通过批处理脚本运行的，所以以这种方式批量运行要容易得多。而且他们甚至不必在电脑前就能运行它。
  所以你有了你的研究， kind of 你想寻找什么，标志，你想尝试检测什么。此时你可能有一些示例逻辑。现在是时候正式化你的查询了。这是你检测的核心，在很多方面是最重要的部分，因为如果你没有一个好的查询，你就不会有任何好的输出。所以应该尽可能由你的研究 informed。当你在研究时，你也会看到一些你可能想排除的东西。比如，举个例子，当我们在研究这个时，我们注意到：“嘿，我们的一个用户或一个遗留应用程序必须这样做。”这并不好，但这可能是你研究的一部分，出现了你 do and don’t want to include 的东西。你可能有多个查询，当你进行时， kind of 评估它们的不同结果。我们稍后在这个过程中会更大规模地做这件事。但现在，运行一些基本查询以了解结果是什么样子，是个好主意。你不想得到一个查询，然后运行五分钟，认为“嘿，太棒了”，然后 move four steps down the line，只是后来发现你并没有真正看到你需要看到的东西。
  你可能还有查询语言的选择。现在是时候挑选了。我们使用elastic，所以KQL、EQL、ESQL、Lucy和 like a billion other languages 以及 whatever one they come up with next week。在这个案例中，我不会剧透我们将为这个检测使用哪一个。但这一步的重点是，你的查询需要找到一个平衡。
  如果你的查询太宽泛，你冒着 burnout 的风险，冒着高量的风险。你甚至可能有太多事件，你想要的关键事件被埋在那巨大的工单混乱中。如果你有太多工单，你的SOC也会真的不喜欢你。中间立场是我们的目标，显然我们想要一个量或我们想要平衡， volume and fidelity 之间 really good balance。我们希望我们的检测查看我们想看到的一切，但我们也希望当它触发时，有很高的真阳性率。
  另一方面，如果你太窄，太具体，你可能会错过小东西。所以如果你寻找 dash p 而密码在括号或引号中， right。那将是太窄的一个例子。或者你寻找 dash P 而他们在之前传递了一个文件。对于这个案例，有很多例子可能太宽或太窄。目标再次是中间立场，找到某个中间点，在那里你会看到足够的事件，但不会看到太多以至于你的检测由于量而 rendered itself useless。
  对于这个检测场景，kql not Kusto。这是Kibana查询语言。这个有一个非常简单 straightforward 的方式来寻找像这样的东西，进程名字段和进程参数字段，这是一个数组或列表，记不清了，但它会在这个进程参数字段中有这个 dash P 作为一个单独的值。正如你在截图中看到的。所以在我们的案例中，如果我们搜索进程名 psexec 和进程参数 P，任何出现参数 P 的情况，无论其他参数是什么，这都会 pick it up。所以这是一个 good middle ground 的例子，因为我们不是太具体，但我们不是在查看所有 P.S. exec。如果这是一个生产检测，我还会 highly recommend 做其他几件事，比如将进程名字段全部转为小写，这样无论大小写如何，你都能匹配。然后还要寻找一些PS exec 的仿冒名称。或者 maybe, better yet, theorizing a little bit，可能有一种方式你可以寻找类似的执行， maybe 查看命令行 like arguments as a whole，然后还看到PS exec 服务被安装。所以有很多方式你可以更具体地进入这个。但对于我们的案例，对于这个场景，这个例子，它超级 straightforward。
  所以进程名和参数 dash P。现在是橡胶 meets the road 的时候了，你需要验证你到目前为止的工作将会变成你想要的东西。
  我稍微提到过。但在上线和发布检测之前估计你的量是绝对需要做的事情， before your SOC comes to you with, pitchforks and torches。而那不是，那不是你想要的东西。所以这看起来像什么？有些地方这样做，有些地方，我的意思是，你可能从未听说过做回测或回填或 whatever it is you want to call it。
  所以对我来说，这看起来像是我想让我的查询 against 90天的先前数据运行。90天是理想的。30天是绝对最小值。但你需要回顾看看这个检测在过去历史上会是什么样子， honestly，只要你能。当你这样做时，你可能会发现你需要过滤掉的东西。你可能会说：“哦，糟糕，我们有这个客户以这种特定方式做这件事。他们应该这样做吗？不应该吗？”或者在某些情况下，你会和他们谈谈。但在其他情况下，它可能是你过滤的东西。在某些情况下，你可能最终不得不基于这个回测重写部分你的查询。不幸的是，我 definitely recommend 在做这个回测步骤时的另一件事是你应该保存你的结果。如果你在回测中没有看到任何结果， somewhere 文档它，在你正在进行的文档中记录它， right？这样做 as you go。保存，有一个截图，有你的查询，有你做的时间段。这样如果它 later 开始疯狂触发，你可以说：“嘿，我做了我的尽职调查， right？”可能有， like I said，一些不幸的情况当你做回测时。
  如果量 extremely, extremely high，你可能有两个选项，或者 maybe three options，我猜你可能最终不得不完全放弃这个检测想法。那并非闻所未闻。 alternatively，有两种不同的方式你可以 really go down。所以其中之一是你可以让它作为一个比你最初 intended 更低优先级的检测。那可能 sucks。但在很多情况下，比没有检测好。所以让它作为比你最初说的更低优先级，你至少仍然获得那种可见性。 alternatively 你可以重新评估你的查询。所以 maybe 有一种方式让你重新制定你的查询并避免大量噪音。查看所有事件之间的公共字段，堆叠数据，查看最常发生什么。如果你关心，你可以查看堆叠数据并说：“嘿，每次我们看到这个并且它是合法的，这个标志也在这里或者它从这个位置运行”，堆叠数据，看看什么突出，什么是最常见的，并尝试考虑你可以和不能过滤什么以摆脱所有那些噪音。
  对于这个场景，我运行的场景只是90天回测。有零结果，这要么是最好的可能结果，要么是最坏的可能结果。最好的可能结果是：这是非常高的 fidelity。这太棒了。最坏的可能结果是某些东西非常 broken，要么是SIM，要么是我的查询，或者 maybe 只是我。如果你足够仔细地看截图，你会注意到我不只是搜索了进程名和参数，我还搜索了一个用户名并 specifically excluded 那个用户名。所以我有零结果，因为我从查询中排除了实际的恶意流量。所以这表明我的查询确实有效，因为它之前确实 pick up 了恶意流量，我只是必须排除它。
  有人问：KQL是否区分大小写？是的，有一些方法可以绕过它，但大多数时候它是区分大小写的。所以小心那个。
  所以那是我们的，那是我们这个场景的回测。你接下来需要的，而这个 so often forgot about，是一个金丝雀。
  金丝雀做什么？它验证你的检测从这一点到未来是否工作。一旦它被部署，你最不希望的是它停止工作而你从未意识到它停止了。也许一个字段值更新了或某种映射改变了，它已经坏了六个月。而你只有在攻击者做了你本该检测的事情时才发现。
  所以金丝雀填补了那个空白。它是代码，理想情况下按计划执行，以验证你的检测按预期工作。这个逻辑可以非常简单，从只是在命令行上运行一个单一的 singular 命令，到一些超级 wildly complex 的东西，或者编译某种C应用程序并在其中做所有 sorts of weird stuff 以触发一些警报。理想情况下 like I said，你应该以间隔运行它，并且你应该配置报告，如果它未能发送警报。所以对有些人来说，困难的部分是当你有这个金丝雀并在生产中运行，按计划运行时，它需要在失败时提醒你。否则再次，它没有，没有，没有 serve its purpose 如果它不提醒你。因为如果，你不会看到这个已经失败。它，它没有，它没有帮助你