安全运营中心 (SOC)

https://app.letsdefend.io/training/lesson_detail/introduction-to-soc

如果你想成为一名安全运营中心分析师
如果你的职业目标是成为一名 SOC 分析师，我们建议你重点关注 SIEM、日志管理和 EDR 等 SOC 工具，并做好笔记。

完成本课程后，您可以继续学习更高级的技术课程。但是，您应该先从本课程开始。

SOC类型和角色

什么是SOC？
安全运营中心 (SOC) 是一个设施，信息安全团队在此持续监控和分析组织的安全状况。SOC 团队的主要目的是利用技术、人员和流程来检测、分析和应对网络安全事件。

(SOC) 模型类型
根据您的安全需求和预算，有几种类型的安全运营中心 (SOC)：

内部安全运营中心
当一个组织组建网络安全团队时，就会成立这个团队。考虑建立内部安全运营中心 (SOC) 的组织应该有预算来支持其持续运作。

虚拟SOC
这种类型的安全运营中心团队没有固定办公地点，经常在不同地点远程办公。

共同管理的安全运营中心
联合管理型安全运营中心（Co-Managed SOC）由内部安全运营中心人员与外部托管安全服务提供商（MSSP）合作组成。在这种模式下，协调至关重要。

指挥安全办公室
这个安全运营中心（SOC）团队负责监管大区域内的各个小型安全运营中心。采用这种模式的机构包括大型电信运营商和国防机构。

人员、流程和技术
构建一个成功的安全运营中心（SOC）需要周密的协调。最重要的是，人员、流程和技术之间必须建立紧密的联系。

简而言之，我们将讨论SOC所需的人员、流程和技术。

人员
一支强大的安全运营中心 (SOC) 团队需要训练有素、熟悉安全警报和攻击场景的人员。由于攻击类型不断变化，因此需要能够轻松适应新型攻击并愿意进行研究的团队成员。

流程
为了进一步完善您的安全运营中心 (SOC) 架构，您需要使其符合多种不同的安全要求，例如 NIST、PCI 和 HIPAA。所有流程都需要高度标准化，以确保万无一失。

技术
团队需要针对渗透测试、检测、预防和分析等诸多任务配备不同的产品，并且需要密切关注市场和技术动态，以找到最适合组织的解决方案。有时，市场上最好的产品可能并不一定最适合您的团队。请记住，还要考虑其他因素，例如组织的预算。

SOC角色
安全运营中心分析师
根据安全运营中心 (SOC) 的架构，该角色可分为 1 级、2 级和 3 级。安全分析师负责对警报进行分类、查找原因并提供补救建议。

事件响应人员
事件响应官是负责威胁检测的人员。该职位负责对安全漏洞进行初步评估。

威胁猎手
威胁猎手是网络安全专业人员，他们主动寻找并调查组织网络或系统中的潜在威胁和漏洞。他们结合人工和自动化技术，检测、隔离和缓解高级持续性威胁 (APT) 以及其他可能绕过传统安全措施的复杂攻击。威胁猎手通常对组织的 IT 基础设施和安全态势有着深入的了解，并掌握新兴威胁和攻击策略。他们的目标是在威胁造成损害或中断业务之前发现并消除它们。

安全工程师
安全工程师负责维护安全信息和事件管理 (SIEM) 解决方案以及安全运营中心 (SOC) 产品的安全基础设施。例如，安全工程师负责构建 SIEM 与安全编排、自动化和响应 (SOAR) 产品之间的连接。

SOC 经理
安全运营中心（SOC）经理承担预算编制、战略制定、人员管理和运营协调等管理职责。他们处理的是运营问题，而不是技术问题。

安全运营中心分析师及其职责

在本节中，我们将讨论什么是安全运营中心（SOC）分析师，他们在安全运营中心团队中的位置，以及该职位的总体职责。在了解该职位的技术细节之前，仔细阅读这些部分非常重要。这样，有志成为安全运营中心分析师的候选人可以了解自己未来的职业发展方向。

安全运营中心 (SOC) 分析师是第一个调查系统威胁的人员。如果情况需要，他们会将事件上报给主管，以便主管能够缓解威胁。SOC 分析师在 SOC 团队中扮演着重要角色，因为他们是第一个响应威胁的人员。

成为安全运营中心分析师的优势
攻击手段和恶意软件种类繁多，而且每天都在不断增加。作为一名分析师，调查这些不同类型的事件会让你更有乐趣。即使你使用的操作系统、安全产品等相同，由于分析的事件各不相同，工作也不会那么单调乏味。此外，你可能不会每周或每天都遇到这些攻击手段。

安全运营中心分析师的一天
安全运营中心 (SOC) 分析师通常会在一天中审查安全信息和事件管理 (SIEM) 系统中的警报，并确定哪些是真正的威胁。为了得出结论，他们会使用各种安全防护产品，例如端点检测与响应 (EDR)、日志管理和安全运营自动化 (SOAR)。我们将在后续的培训课程中详细解释这些产品的使用原因和方法。

要成为一名成功的 SOC 分析师，不依赖安全产品，并且能够正确分析 SIEM 警报，您必须具备以下技能和能力。

操作系统
要判断系统中的异常情况，首先需要了解什么是正常情况。例如，Windows 操作系统中包含许多服务，如果不了解哪些服务是正常的或可以被视为正常的 Windows 服务，就很难判断哪些服务可疑。因此，您应该熟悉 Windows/Linux 操作系统的工作原理。

网络
首先，在这个岗位上，你将处理大量的恶意IP地址和URL，因此你需要确认网络上没有任何设备试图连接到这些地址。完成这一步后，分析的方向就确定了。

这一步稍微复杂一些，因为您可能需要在网络上找到潜在的数据泄露点。要完成所有这些操作，您需要了解网络基础知识。

恶意软件分析
在应对大多数威胁时，您很可能会遇到某种恶意软件。为了了解这些恶意程序的真正目的（它们有时会表现出不同的行为来迷惑分析人员），您需要具备恶意软件分析技能。

至少要确定恶意文件的命令和控制中心是什么，以及是否有设备与该地址通信。

总的来说，我们已经讨论了什么是安全运营中心（SOC）分析师，该职位有哪些职责，以及SOC分析师需要具备哪些技能。随着课程的深入，还将涵盖技术领域，首先从安全信息和事件管理（SIEM）入手。

SIEM与分析师关系

本课将讨论什么是 SIEM，为什么在 SOC 中使用 SIEM，以及 SIEM 与 SOC 分析师的关系。

什么是SIEM？
SIEM 是一种安全解决方案，它结合了安全信息和事件管理，涉及对环境中发生的事件进行实时记录。事件日志记录的最终目的是检测安全威胁。

总的来说，SIEM产品功能丰富。作为SOC分析师，我们最感兴趣的是那些能够收集和过滤数据并针对可疑事件发出警报的功能。

例如：如果用户在 Windows 操作系统上尝试在 10 秒内输入 20 次错误密码，则此行为可疑。忘记密码的用户不太可能在如此短的时间内尝试输入这么多次密码。因此，我们创建了一条 SIEM 规则/过滤器来检测超过阈值的此类活动。基于此 SIEM 规则，当出现这种情况时，系统将生成警报。

一些流行的 SIEM 解决方案包括：IBM QRadar、ArcSight ESM、FortiSIEM、Splunk 等。要了解更多信息，您可以访问 LetsDefend 的“监控”页面。

SOC分析师与SIEM之间的关系
尽管 SIEM 解决方案功能丰富，但 SOC 分析师通常只负责跟踪警报。配置和规则关联则由其他团队/人员负责。

如上所述，警报由经过过滤器的数据生成。警报首先由安全运营中心 (SOC) 分析师进行分析。这正是 SOC 分析师在安全运营中心工作的开始。本质上，他们必须判断生成的警报是真实威胁还是误报。

为了更好地理解，我们回到“监控”页面；如下所示，SIEM 界面上有各种警报。SOC 分析师应借助其他 SOC 产品（例如 EDR、日志管理、威胁情报源等）分析这些警报的详细信息，并最终确定它们是否构成真正的威胁。

您可以在“主频道”中查看新创建的警报，并将此频道视为共享频道。在此模拟环境中，您的队友不可见，但在实际工作场景中，他们将能够看到此面板。选择要处理的警报后，单击“操作”区域中的“认领”按钮，即可认领该警报并将其定向到“调查频道”。这样，您的队友可以看到您正在处理哪个警报。同时，这也有助于他们了解您已在处理哪些警报，以便他们选择其他警报。这样，您的团队就可以快速查看所有警报。

点击警报后，即可查看警报详情。这样您就可以收集调查所需的信息（主机名、IP 地址、文件哈希信息等）。

小贴士
请注意，SIEM 系统有时会产生误报。优秀的 SOC 分析师能够识别此类情况并向团队提供反馈，从而提高 SOC 团队的效率。

例子：
假设一个 SIEM 团队制定了一套规则，该规则会针对 URL 地址中包含“union”一词的情况生成警报，并且正在尝试检测 SQL 注入。

用户使用“https://www.google.com/search?q=sql+union+usage”进行搜索，SIEM 系统随即生成了警报。目前看来，并未发现明显的威胁。该警报的触发原因是 URL 中包含关键词“union”。此类异常情况可以分享给 SIEM 团队，以便优化警报流程。

结语
到目前为止，我们已经介绍了什么是 SIEM、它如何帮助 SOC 分析师以及如何使用它。在课程的后续部分，我们将讨论如何分析 SIEM 中创建的警报。

最后，作为安全运营中心 (SOC) 分析师，您可以查看安全信息和事件管理 (SIEM) 控制面板：

日志管理

作为一名安全运营中心（SOC）分析师，您将进行大量的日志分析。因此，熟悉“日志管理”系统/解决方案至关重要。您使用哪种产品并不重要，重要的是要知道要查找什么以及在哪里查找。

本课的剩余部分将讨论 SOC 分析师如何有效地使用“日志管理”解决方案。

什么是日志管理？

顾名思义，日志管理提供对环境中所有日志（Web 日志、操作系统日志、防火墙日志、代理日志、EDR 日志等）的访问权限，并允许您在一个位置集中管理它们。这可以提高效率并节省时间。

如果无法从一个地方访问日志，那么相同的请求（例如，目标是确定 letsdefend.io 上的所有用户）就必须发送到不同的设备。这将增加出错的概率，并延长所需时间。

如果您访问 Let’sDefend 的“日志管理”页面，您会看到代理、Exchange 和防火墙等各种日志源，它们都列在“类型”列表中。这意味着所有这些日志源都已集中到一个位置，只需一次查询即可查看来自代理、防火墙等来源的日志输出。

日志管理的目的

安全运营中心 (SOC) 分析师通常依赖日志管理来确定是否存在与特定地址的通信，并查看通信详情。假设您遇到一段恶意软件，运行后发现它正在与“letsdefend.io”地址通信并执行来自该地址的命令。在这种情况下，“letsdefend.io”是命令与控制中心，您可以在公司日志管理中搜索“letsdefend.io”，查看是否有任何设备尝试与该命令与控制中心通信。

这就引出了第二种情况：您收到一条 SIEM 警报，指出您网络中的一台 LetsDefendHost 设备正在向 IP 地址 122[.]194[.]229[.]59 泄露数据。您已经进行了调查，将该设备从网络中隔离，执行了必要的流程，现在您已恢复控制。但您仍然遗漏了一个问题：是否有其他设备向可疑 IP 地址 (122[.]194[.]229[.]59) 发送数据？警报可能只包含了 LetsDefendHost，但您仍然应该在日志管理中搜索该可疑地址，看看系统是否遗漏了任何信息，并尝试查找任何关联。

EDR - 端点检测与响应

安全运营中心 (SOC) 分析师在对终端设备进行分析时，必须花费大量时间使用端点检测与响应 (EDR) 系统。以下章节将探讨 EDR 对 SOC 分析师的益处以及如何有效使用它。

什么是EDR？

端点检测与响应 (EDR)，也称为端点威胁检测与响应 (ETDR)，是一种集成的端点安全解决方案，它将对端点数据的持续实时监控和收集与基于规则的自动化响应和分析功能相结合。（定义来源：mcafee.com）

使用EDR进行分析

工作场所常用的一些 EDR 解决方案：CarbonBlack、SentinelOne 和 FireEye HX。

要了解作为分析师可以使用 EDR 做什么，让我们来看看 LetsDefend 上的“端点安全”。

如图所示，可访问的终端设备列在左侧。您可以在搜索栏中搜索终端设备，或者，如果存在 IOC（例如 IP 地址、文件哈希值、进程名称等），我们可以对所有主机进行搜索。

右侧显示有关设备的常规信息，并显示浏览器历史记录、网络连接和进程列表等部分。

现场调查

接下来，您可以点击“连接”按钮，访问机器本身以继续进行分析。

遏制

你需要将被黑客入侵的机器与网络隔离。这样做有两个重要原因：一是防止攻击者连接到内部网络并在内部网络中自由移动。

因此，在漏洞修复且设备准备就绪之前，应将设备与内部和外部网络隔离。您可以使用 EDR 解决方案的隔离功能来确保隔离。此功能允许选定的设备仅与 EDR 中心通信。这意味着即使设备与网络隔离，您仍然可以继续进行分析。

小贴士

如果您拥有任何类型的入侵指标 (IOC)，例如文件哈希值、文件名等，您可以在 EDR 中对所有主机执行搜索，查看是否存在匹配项。例如，假设您确定某个设备已被入侵，并且您获得了一个 MD5 哈希值为“ac596d282e2f9b1501d66fce5a451f00”的文件。您可以在 EDR 中搜索此哈希值，以确定该文件是否存在或是否正在其他设备上执行。这将有助于您了解哪些设备受到了此次攻击的影响。

结论

我们介绍了EDR的基础知识，您会发现它的使用频率与日志管理一样高。过去，我们看到一些分析师未能有效地使用EDR解决方案，因此花些时间学习这个主题将使您领先于其他人。

请记住前往“端点安全”进行练习，然后在“监控”页面上查看警报。

下一节，我们将讨论如何使用 SOAR 加快分析过程。

SOAR（安全编排自动化和响应）

SOAR 代表安全编排自动化与响应 (Security Orchestration Automation and Response)。它使环境中的安全产品和工具能够协同工作，从而简化 SOC 团队成员的任务。例如，它会自动在 VirusTotal 上搜索 SIEM 警报的源 IP 地址，从而减轻 SOC 分析师的工作量。

行业中常用的一些SOAR产品：

Splunk Phantom
IBM Resilient
Logsign
德米斯托

下图展示了使用 SOAR 解决方案可以实现的效果。

图片来源：hawk-eye.io

本课的剩余部分将重点介绍 SOAR 的优势以及 SOC 分析师如何有效地使用 SOAR。

节省您的时间

SOAR 通过自动化流程的工作流节省时间。一些常见的工作流程包括：

IP地址信誉控制
哈希查询
在沙箱环境中扫描已获取的文件
…

集中化（一个平台满足您的所有需求）

它通过提供一体化软件，允许您在环境中使用不同的安全工具（沙箱、日志管理、第三方工具等）。这些工具已集成到 SOAR 解决方案中，并可在同一平台上使用。

剧本

您可以使用 SOAR 中针对不同场景创建的剧本轻松调查 SIEM 警报。即使您不了解或记不住所有步骤，也可以按照剧本中概述的步骤进行分析。

此外，这些操作手册有助于确保整个安全运营中心 (SOC) 团队在执行分析时步调一致。例如，所有团队成员都需要检查 IP 信誉，因此如果某个团队成员没有检查而其他成员都检查了，就会出现问题。我们可以通过在操作手册中添加此步骤来避免这种情况。

LetsDefend 和 SOAR

您可以将“案例管理”理解为与 SOAR 相同。在 SIEM（监控）页面上，您可以为已创建的案例提交工单。查看该页面时，首先看到的是已打开和已关闭案例的列表。

点击任何未解决的案例，您将看到一个自动分配的剧本。您可以按照此剧本调查相关的 SIEM（监控）警报。

到目前为止，我们已经介绍了什么是安全运营自动化与响应 (SOAR) 解决方案、它在安全运营中心 (SOC) 环境中的应用方式，以及它如何使 SOC 分析师受益。在下一课中，我们将探讨威胁情报及其与 SOC 分析师的关系。

威胁情报源

安全运营中心 (SOC) 团队应立即掌握最新威胁信息并采取必要的预防措施。为了满足这一需求，威胁情报源应运而生。作为 SOC 分析师，您可以利用这些信息源指导您的调查工作。

威胁情报源是由第三方公司提供的数据（例如恶意软件哈希值、C2（命令与控制）域/IP 地址等）。

查看 Let’sDefend 的威胁情报页面，可以看到多种类型的数据（哈希值、IP 地址等）。

此处的数据包含先前恶意活动的痕迹。它可能是恶意软件的哈希值，也可能是命令与控制中心的 IP 地址。作为安全运营中心 (SOC) 分析师，您需要搜索威胁情报源，以确定手头的哈希文件是否曾在过去的恶意场景中使用过。

以下是一些您可以使用的免费且常用的资源：

https://www.virustotal.com/gui/home/upload

https://talosintelligence.com/

需要强调的要点：

如果您通过数据源运行的数据没有显示出来
假设您在 VirusTotal 中对某个 .exe 文件进行了哈希值检测，并且之前并未发现任何可疑之处。在这种情况下，您不应想当然地认为该文件是安全的，否则就大错特错了。安全运营中心 (SOC) 分析师应该仔细执行必要的文件分析（静态/动态）。

我们不应忘记，IP地址是可以易手的。
例如，假设攻击者在 AWS（亚马逊网络服务）上创建了一个服务器，并将其用作命令和控制中心。然后，各种威胁情报源将该 IP 地址列为恶意地址。

两个月后，攻击者关闭了服务器，其他人将自己的个人博客迁移到了该服务器上。但这并不意味着访问过该博客的人都接触到了恶意内容。该IP地址过去曾被用于恶意用途，并不意味着它现在仍然包含恶意内容。

SOC分析师常犯的错误

和其他人一样，安全运营中心（SOC）分析师也会犯错。本节将讨论SOC分析师常犯的错误以及如何避免犯同样的错误。

过度依赖 VirusTotal 的结果
对沙箱中恶意软件的快速分析
日志分析不足
忽略 VirusTotal 数据

建议您在完成本课程前面的课程后再复习本课。

过度依赖 VirusTotal 的结果

有时，在分析文件 URL 并确认地址无害后，我们可以依赖 VirusTotal 绿色屏幕上显示的结果。然而，现在出现了一种利用绕过杀毒软件 (AV) 技术开发的新型恶意软件，VirusTotal 可能无法检测到。因此，我们应该将 VirusTotal 视为辅助工具，并在进行分析时牢记这一点。

以下是一篇关于此主题的详细博文，供您进一步阅读： https://medium.com/maverislabs/virustotal-is-not-an-incident-responder-80a6bb687eb9

对沙箱中恶意软件的快速分析

在沙盒环境中进行 3-4 分钟的分析未必总能得出准确结果。原因如下：

恶意软件可能能够检测到沙盒环境，因此不会自行激活。

恶意软件可能在操作完成后 10 到 15 分钟内不会激活。

因此，分析的持续时间应尽可能延长，并且如果可能的话，应在真实环境中进行。

日志分析不足

有时我们会发现一些日志分析没有正确执行。例如，假设在主机名为“LetsDefend”的机器上检测到了恶意软件，并且该恶意软件正在秘密地向地址“letsdefend.io”发送数据。作为安全运营中心 (SOC) 分析师，您应该使用日志管理解决方案来确定是否有其他设备也在尝试连接到此地址。

忽略 VirusTotal 数据

如果您在 VirusTotal 中执行的搜索已被查询过，则会显示缓存中的结果。例如：我们在 VirusTotal 中搜索了地址“letsdefend.io”，结果如下所示。

攻击者只需在 VirusTotal 上搜索一个干净的 URL，然后将其替换为恶意内容即可。因此，您不仅应该查看搜索缓存，还应该进行新的搜索。

结论

本课涵盖了安全运营中心（SOC）分析师常犯的错误以及如何避免这些错误。请记得不时回顾本部分内容，以巩固记忆。

Co-Managed SOC

Co-Managed SOC（联合管理安全运营中心）是一种“混合”安全运营模式，它在完全自建和完全外包之间取得平衡，让组织的内部团队与外部安全服务提供商（MSSP）共同承担安全运营的责任。

这种模式的核心是协作与责任共担，而非简单的服务购买。

🧠 它是如何运作的？

在这种模式下，内外团队分工协作，共同完成安全运营的各个环节。

  • 内部团队：通常负责预防和修复工作。他们利用对自身业务和系统的深刻理解，主导安全策略制定、漏洞修复和系统加固等。
  • 外部专家团队：则专注于7x24小时的实时监控、威胁监测、事件分析与分级响应。他们提供专业的安全工具、威胁情报和资深分析师资源。

✨ 主要特点与优势

这种模式有效解决了企业在安全管理上面临的多个痛点：

  • 保留控制权与可见性：与完全外包不同，企业依然掌握自身安全环境的战略所有权和运营控制权。
  • 弥补人才与技能缺口：直接应对网络安全人才短缺的挑战，让企业无需承担高昂的7x24小时全职招聘和培训成本，即可获得外部专家的支持。
  • 缓解警报疲劳，提升效率：外部专家团队可以协助筛选和调查海量安全警报，将其中高达90% 的无效或低优先级警报过滤掉，只将有确认的、可操作的高危告警推送给内部团队。
  • 优化成本：避免自建完整SOC所需的高昂基础设施和人力成本，同时又能确保安全监控的质量。该市场在2025年估值已达39.8亿美元，预计到2032年将增长至124.5亿美元，足见其受欢迎程度。

⚖️ 它与其他模式有何不同？

为了帮你更清晰地理解，这里有一个简单的对比：

模式 责任主体 控制权 成本 适用场景
自建SOC (In-house) 完全内部团队 完全控制 最高 对数据主权和定制化要求极高的大型企业
Co-Managed SOC (联合管理) 内部 + 外部团队共同承担 共享控制，内部主导 中等 寻求平衡控制、成本和专业能力的中大型企业
完全外包SOC (Outsourced) 外部服务商 基本移交 根据服务水平而定 希望完全放手、专注于核心业务的中小企业

🎯 谁适合采用Co-Managed SOC？

这种模式特别适合以下情况的组织：

  • 已经部署了SIEM（如Microsoft Sentinel）等安全工具，但缺乏足够人手进行7x24小时监控和管理的组织。
  • 希望利用外部专家的先进威胁情报和技术，但又不想完全放弃对安全策略主导权的组织。
  • 需要快速提升安全运营能力，但招聘周期长、成本高的组织。

总的来说，Co-Managed SOC是一种灵活且战略性的选择，它通过“内外结合”的方式，帮助企业以可控的成本和资源，获得更强大、更高效的安全防御能力。

如果你想进一步了解它和完全外包模式（MSSP）的具体区别，或者它如何与SIEM、MDR等具体技术结合，我可以为你提供更详细的信息。

Threat Hunter是做什么的

Threat Hunter（威胁猎人） 是安全团队中的“主动搜查者”和“侦探”。与普通安全分析师被动等待警报不同，威胁猎人是主动出击，在攻击造成实质性破坏之前，去发现那些已经成功绕过现有防御体系、隐蔽潜伏在企业网络中的高级威胁。

可以用一个比喻来理解：

  • 普通SOC分析师：像保安，盯着监控屏幕（SIEM警报），听到警报声（告警）就冲过去处理。
  • 威胁猎人：像刑警，不依赖报警电话，而是根据作案手法、异常痕迹和情报线索，主动到数据海洋里翻找，找出那个“隐形”的敌人。

🎯 威胁猎人的核心工作是什么？

他们的工作不是简单的“看日志”，而是一个系统性的主动防御过程，通常遵循**“假设失陷”（Assume Breach）**的心态——即默认网络已经被入侵，然后去寻找证据证明或推翻这个假设。

具体工作包括：

  1. 提出并验证假设（Hypothesis-Driven Hunting）

    • 他们会基于最新的威胁情报（例如，某个黑客组织最近利用了特定的漏洞），提出假设：“我们环境里会不会也有类似的攻击？”
    • 然后，他们会在海量数据（网络流量、终端日志、身份验证记录）中有目的地搜索，验证这个假设是否成立。

  2. 追踪高级威胁（APT）与“噪声”中的异常

    • 他们寻找的不是已知病毒特征，而是**“异常行为”**。例如：一位财务员工在凌晨3点从异地登录，并开始下载大量数据库文件；或者一个服务器发起了从未有过的外部连接。这些行为往往意味着攻击者已经窃取了合法账号。

  3. 攻击链（Kill Chain）与溯源分析

    • 即使没有直接抓现行，他们也会通过线索回溯攻击链条。比如，从一台可疑的电脑出发，检查它之前访问过哪些IP、创建了什么进程，从而还原整个攻击路径，找出攻击的源头和受影响的范围。

  4. 主动搜索“沉寂”的恶意软件

    • 很多高级恶意软件会“休眠”或使用加密通信（C2）回传数据。威胁猎人会通过分析网络流量中的微小抖动或异常的DNS请求，揪出这些潜伏的“地雷”。

  5. 优化防御体系（反馈闭环）

    • 找到入侵证据后，他们不仅会清除病毒，还会复盘攻击是如何进来的，并调整现有的防火墙规则、端点检测策略，完善SIEM的告警模型，让系统下次能自动拦截同类攻击。

🧠 威胁猎人需要具备哪些独特技能？

  • “坏人”的思维：他们必须像攻击者一样思考，预判攻击者会从哪里下手、如何隐藏脚印。
  • 强大的数据挖掘能力：精通Splunk、ELK、KQL（Kusto查询语言）等工具，能在大数据中编写复杂查询语句。
  • 对框架的深度理解：非常熟悉 MITRE ATT&CK 框架（攻击战术和技术知识库），能对照框架来识别攻击者的每一步动作。
  • 极强的耐心与好奇心：大部分搜索可能一无所获（这是好消息），但依然要不断寻找细微的异常。

🔗 回到你之前问的 Co-Managed SOC

在你之前问到的 Co-Managed SOC（联合管理SOC） 模式中，威胁猎人通常扮演着**“高阶外援”**的角色：

  • 企业内部团队日常处理告警和修复漏洞，可能缺乏时间或高级技能去做深度狩猎。
  • 外部的MSSP（托管安全服务商）专家则可以利用他们的高级威胁情报和资深猎人团队，定期或持续地为企业执行主动狩猎任务，帮助企业弥补这块最关键的高阶能力缺口。

简单来说，Threat Hunter 是企业安全防御从“被动挨打”转向“主动出击”的关键角色。如果你还想了解他们和普通安全分析师具体有什么区别，或者想了解他们常用的具体工具（比如如何用KQL进行狩猎），我也可以为你展开讲讲。😊

Let’sDefend 的哪个页面是 SIEM 页面？

日志管理
端点安全
监测
威胁情报

正确答案：
监测

这个问题的答案之所以是 “监测” ，是因为在 Let’sDefend 这个模拟蓝队（防御）训练平台中，“监测”（Monitor）页面就是其核心SIEM（安全信息和事件管理）功能的入口和操作界面。

具体原因可以通过排除法和功能定位来解释：

1. 从“平台设计”看（最直接原因）
Let’sDefend 模拟的是真实SOC（安全运营中心）的工作台。在该平台的菜单栏中，“监测”（Monitor）板块专门用来展示所有实时上报、聚合和关联后的安全告警（Alerts）。分析师正是在这个页面查看告警详情、分析原始日志、确认攻击类型，这正是SIEM系统的核心职能——“事件监测与响应”。

2. 从“功能排除”看（为什么不是其他选项）

  • 日志管理（Log Management）：这属于SIEM的底层数据源，主要负责存储和索引原始日志（如Windows事件、防火墙日志）。它只是SIEM的“食材仓库”，而不是烹饪和上菜的“操作台”。在Let’sDefend上，这个页面通常用于检索历史原始日志，而非处理实时告警。
  • 端点安全（Endpoint Security）：这对应的是EDR（端点检测与响应），是独立于SIEM之外的另一个安全产品，专注于单台主机（PC/服务器）上的进程、文件和注册表行为。两者是互补关系，而非SIEM本身。
  • 威胁情报（Threat Intelligence）：这是为SIEM提供决策依据的外部“字典”或“黑名单库”，用于帮助SIEM判断某个IP或域名是否可疑。它只是SIEM的“外挂大脑”，而不是SIEM的操作主界面。

3. 从“术语本质”看
SIEM的全称是 安全信息与事件管理（Security Information and Event Management），它的本职工作就是**实时“监测”**网络和系统中的异常信号，并将海量信息转换成可供分析师处理的安全告警。Let’sDefend直接将这个页面命名为“监测”，既符合SIEM的定义，也最贴近分析师日常“看告警”的工作场景。

简单来说：日志管理是数据，端点安全是隔壁部门，威胁情报是参考资料，只有监测才是SIEM干活的地方。你进入“监测”页面，就是在操作该平台的SIEM控制台了。😊

NIST（美国国家标准与技术研究院）对事故的生命周期分为哪些不同阶段？

正确答案：

准备、检测/分析、遏制/根除和恢复、事件后活动

What can be used to conduct an analysis with SOAR?

information management system
ticket
playbook
a google search

答案playbook

这个问题的答案之所以是 Playbook（剧本），是因为在SOAR（安全编排、自动化与响应）平台中，“Playbook”是执行任何自动化分析和响应动作的核心“大脑”与“指令集”。

简单来说：没有Playbook，SOAR就只是一个空壳；有了Playbook，SOAR才能代替人类去自动完成分析动作。

为了帮你更透彻地理解，我们可以从“SOAR到底是怎么工作的”以及“排除法”两个角度来看：

1. 从SOAR的核心机制看（为什么是Playbook）

  • Playbook 就是“自动化工作流”：你可以把它理解成一份给机器看的“应急处置流程图”。在这张图里，提前画好了所有步骤：如果检测到某个告警，那么第一步查询威胁情报、第二步提取文件哈希、第三步隔离受影响终端、第四步创建工单……
  • 分析是由Playbook驱动的：当SOAR要“开展分析”时（比如分析一个可疑IP），它并不是随便乱查，而是严格遵循Playbook里写好的逻辑去执行。比如，Playbook会指挥SOAR自动去调用防火墙查询、去病毒库比对、去内网资产库关联。正是Playbook里预设的决策树和动作序列，构成了SOAR进行自动分析的基础。

2. 用排除法看（为什么不是其他选项）

  • Ticket（工单）：工单是SOAR分析的“产出物”或“载体”。当Playbook执行完自动分析后，如果需要人工介入，SOAR会自动生成一张工单给分析师。工单记录的是“分析的结果”，而不是“用来分析的工具”。
  • Information Management System（信息管理系统）：这只是一个存放数据的**“数据库”**。SOAR在分析过程中会去读取里面的资产信息或人员信息，但它只是一堆静态数据，没有逻辑，不会主动“做”任何分析动作。
  • A Google Search（谷歌搜索）：在真实SOAR环境中，这通常对应的是“威胁情报查询”这个**“动作”。这个动作确实常被写在Playbook里，作为分析步骤中的一环（比如去谷歌搜索IP是否恶意）。但它仅仅是一个单一的查询手段，并不能代表SOAR进行“完整分析”所需的全部逻辑和流程编排。只有Playbook才能把这些零散动作串联成一个完整的分析闭环**。

🎯 一句话总结

  • Ticket（工单） 是 SOAR 要处理的 “案件”；
  • Google Search（情报查询） 是 SOAR 办案时的 “其中一个工具”；
  • Playbook（剧本） 则是 SOAR 办案时的 “完整行动方案”——先查谁、再问谁、接着封锁谁，全都由它指挥。

所以，在SOAR的语境下，能够用来“开展分析”的核心构件，只能是Playbook。它赋予了SOAR自动判断和自动操作的灵魂。😊

I am responsible for connecting security products. My job title is …

威胁情报
安全分析
安全工程师
渗透测试

正确答案：安全工程师

这个问题的答案之所以是 “安全工程师”（Security Engineer），是因为**“连接安全产品”这项工作在本质上是工程与架构类**的任务，而非分析或攻防类任务。

我们可以从“职责分工”和“工作内容”两个维度来拆解：

1. 从“工作性质”看（为什么是安全工程师）

**“连接产品”**在网络安全领域具体指：配置API接口、编写集成脚本、设置日志转发（Syslog/CEF）、部署传感器、调试网络连通性、确保不同厂商（如防火墙、EDR、SIEM）之间的数据格式兼容并正常流通。

  • 这属于安全基础设施建设和系统集成的范畴。
  • 安全工程师的核心职责就是**“搭桥铺路”，确保各种安全工具能够稳定运行并相互通信。他们关注的是数据的“流”**（数据能不能到达目的地），而不是数据“流”的是什么内容。

2. 用“排除法”看（为什么不是其他选项）

  • 安全分析师（Security Analyst）：他们是**“看数据的人”。他们的工作是在SIEM或SOC界面里调查告警、分析入侵事件。他们使用**已经连接好的产品，但通常不需要也不被允许去动底层的网络配置或API集成代码。
  • 威胁情报（Threat Intelligence）：这是一个**“数据来源”或“研究方向”**，不是岗位职责。做威胁情报的人关注的是外部攻击者动向和IOC（入侵指标），而不是去物理连接或配置软件接口。
  • 渗透测试（Penetration Testing）：这是**“攻击队”的工作。他们的任务是模拟黑客入侵、挖漏洞、提权。他们可能会为了绕过防御而禁用某个产品，但绝不会**去负责把防火墙和日志服务器“连接”起来。

🎯 现实工作中的真实场景

在一个典型的安全团队里，分工通常是这样的：

  • 当公司买了新的EDR（端点检测与响应）系统，需要把它接入公司的SIEM和威胁情报源。安全工程师拿着服务器权限和API密钥，登录后台写代码、改配置，搞定连接。
  • 连接完成后，安全分析师登录SIEM界面，看到数据进来了，开始针对这些数据做分析。

简单来说：工程师负责“接水管”，分析师负责“看水质”，渗透测试负责“砸水管”，威胁情报负责“预报洪水”。既然题干说的是“连接产品”，那答案毫无疑问是安全工程师。😊

Which is a common mistake for SOC analysts?

insufficient log analysis
putting aside the managerial tasks
running scripts with root privileges
have a burn-out

正确答案： insufficient log analysis

这个问题的答案之所以是 “insufficient log analysis”（日志分析不足），是因为在SOC（安全运营中心）分析师的日常工作中，这是最典型、最致命且最容易犯的“职业级”错误，直接关系到安全事件的漏报和误判。

而其他选项要么是“操作红线（绝对禁止）”，要么是“职业结果（而非错误）”，要么不属于分析师的职责范畴。

我们可以通过以下逻辑来深度拆解：

1. 为什么“日志分析不足”是常见错误（核心原因）

  • 被SIEM“惯坏”了：很多初级分析师过度依赖SIEM的预置告警规则和仪表盘，只去看告警标题，而不去点开原始日志（Raw Log）查看完整上下文。例如，SIEM告警显示“来自恶意IP的登录”，但如果你不深入分析日志，你就不会发现这个登录其实成功了，从而严重低估事态的严重性。
  • 时间压力下的“偷懒”：SOC通常面临海量告警（警报疲劳）。为了赶KPI，分析师倾向于快速把告警标记为“误报”（False Positive），而不去检查同一时间段内关联的防火墙日志、Windows事件ID（如4624/4625）或DNS日志。
  • 后果：日志是数字世界的“黑匣子”，分析不足直接导致高级持续性威胁（APT）横向移动或数据外泄被完美忽略，这是SOC最不能容忍的“失职”错误。

2. 用“排除法”看（为什么其他选项不对）

  • putting aside the managerial tasks（搁置管理任务）：这属于时间管理问题，而非“安全分析”能力问题。而且，SOC分析师的核心KPI是事件处理，管理任务（如写报告、开会）虽然烦人，但搁置它们通常不会直接导致“黑客入侵”或“安全漏报”，所以它不是针对分析过程的常见错误。
  • running scripts with root privileges（以root权限运行脚本）：这不是“常见错误”，而是绝对的“运维禁忌”和“严重违规”。SOC分析师通常只有读取权限，如果随意拿root跑脚本，极大概率会导致系统崩溃或引入后门。这属于操作失误，而不是日志分析层面的错误。
  • have a burn-out（职业倦怠）：这确实是SOC行业普遍存在的现象（高压、轮班导致），但它是一个**“结果”或“职业健康问题”。题干问的是“在做分析工作时犯的常见错误”（a common mistake for analysts），倦怠是心理状态，不是具体的技术分析错误**。

🎯 现实场景对照

  • 好的分析师：看到一个告警，会立刻拉取源IP过去24小时的所有DNS请求、目标主机的进程创建日志（Sysmon事件1）和身份验证日志。他们分析充分的日志。
  • 犯错误的分析师：只看到界面显示“恶意域名访问”，因为内部资产装了杀毒软件，就觉得“应该没事”，直接关掉告警，没去分析网关日志确认是否真的有数据包外传。

一句话总结： 只有**“日志分析不足”**直接击穿了SOC分析师存在的核心价值——“从数据中找出攻击真相”，因此它是公认的最常见职业错误。而跑root脚本是严重事故，倦怠是身体问题，管理任务是次要优先级。😊

soc测试题

https://app.letsdefend.io/training/quiz-result/soc-fundamentals

测试结果： 16 Points