前言
欢迎来到另一期使用 Elastic 进行 Okta 威胁研究的文章。之前，我们发表过文章，探讨了 Okta 的核心服务和产品。本文致力于网络防御的实践方面——建立一个强大的 Okta 威胁检测实验室。我们的旅程将引导您了解使用 Elastic Stack 配置实验室环境、集成 SIEM 解决方案以及与 Okta 无缝连接的复杂性。
本文的目的不仅仅是提供信息，更是赋能。无论您是经验丰富的网络安全专业人士还是好奇的爱好者，我们的演练旨在为您提供知识和工具，以理解和实施针对 Okta 环境的高级威胁检测机制。我们认为，实践经验是有效网络安全实践的基石，本指南旨在为您提供一个切实可行的路线图，以增强您的安全态势。
在我们开始这次技术探险时，请记住，网络安全的世界是动态且不断发展的。这里讨论的方法和策略反映了当前的形势和最佳实践。我们鼓励您以探索和适应的心态对待本指南，因为网络安全中的技术和工具在不断进步。
现在，让我们深入研究为 Okta 研究设置的检测实验室。
前提条件
首先，此实验室设置需要一个 Okta 许可证（试用许可证也可以）。这至少允许我们在我们的环境中生成 Okta 系统日志，然后我们可以将其摄取到我们的 Elastic Stack 中。
其次，在设置 Okta 后，我们可以部署 Windows Server、设置 Active Directory (AD)，并使用 Okta 中的 AD 集成，将 AD 与 Okta 同步，以进行身份和访问管理 (IAM)。对于实验室的其余部分，此步骤不是必需的，但是，它可以帮助我们扩展实验室，以进行其他练习和场景，在这些场景中，端点和 Okta 数据对于搜索都是必需的。
注册 Okta Workforce Identity
我们将通过注册 Workforce Identity Cloud 试用版来为此演练设置一个全新的 Okta 环境。如果您的环境中已经设置了 Okta，则可以跳到 设置 Elastic Stack 部分。
注册试用版后，您通常会看到一个 URL，其中包含一个试用许可证子域和用于登录 Okta 管理控制台的电子邮件。
首先，用户必须转到他们注册时提供的电子邮件，并按照 Okta 的激活电子邮件中的说明进行操作，该电子邮件包含一个要扫描的二维码。
二维码链接到移动设备（iOS 和 Android）上提供的 Okta Verify 应用程序。系统会提示在移动设备上使用电话号码和面部识别进行多因素身份验证 (MFA)。
图像 1：通过移动设备设置 Okta Verify
设置完成后，我们将被重定向到 Okta 管理控制台以使用 Okta Verify 配置 MFA。
图像 2：Okta 管理控制台
此时，您应该拥有 Okta 的试用许可证、已设置 MFA，并且可以访问 Okta 管理控制台。
设置您的免费云堆栈
对于本实验室，我们将使用 Elastic Cloud 实例的免费试用版。您还可以选择在 Amazon Web Services (AWS)、GCP 或 Microsoft Azure 中创建堆栈，如果您想在现有的云服务提供商 (CSP) 中设置堆栈。确保为您的 Elastic Cloud 环境启用 MFA。
注册免费试用版后，我们可以专注于配置 Elastic Stack 部署。对于本实验室，我们将把我们的部署称为 okta-threat-detection，并在 GCP 中部署它。可以保留部署的默认设置，并且我们建议使用最新版本的所有最新功能。在本演示中，我们使用以下设置：
- 名称：okta-threat-detection
- 云提供商：Google Cloud
- 区域：爱荷华州 (us-central1)
- 硬件配置：存储优化
- 版本：8.12.0（最新）
在此步骤中，可以配置用于调整 Elasticsearch、Kibana、集成等的其他设置的选项。但是，对于本实验，默认设置即可。如果您选择将 Elastic Stack 用于更永久、长期的策略，我们建议根据您的需求进行架构规划和设计。
设置完成后，选择“创建部署”，Elastic Stack 将自动部署在 GCP（或您选择的任何云提供商）中。您可以将显示的凭据下载为 CSV 文件，或将其保存在您认为合适的任何位置。部署大约需要 5 分钟才能完成，完成后，您可以选择“继续”以登录。恭喜您，您已在几分钟内成功部署了 Elastic Stack！
图像 3：您新部署的 Elastic 堆栈
从安全解决方案设置 Fleet
提醒一下，Fleet 允许创建和管理代理策略，该策略将包含 Elastic Agent 上的 Okta 集成。此集成用于访问和将 Okta 日志摄取到我们的堆栈中。
创建 Okta 策略
为了让我们的 Elastic Agent 知道它正在使用哪个集成、要收集哪些数据以及在我们的堆栈中将这些数据流式传输到哪里，我们必须首先设置一个自定义的 Fleet 策略，我们将其命名为 Okta。
要在您的 Elastic Stack 中设置 Fleet 策略，请在您的 Elastic Stack 中执行以下操作：
- 导航菜单 > 管理 > Fleet > 代理策略 > 创建代理策略
- 输入“Okta”作为名称 > 创建代理策略
图像 4：Elastic Stack 中的 Fleet 代理策略页面
设置 Okta 集成
建立策略后，我们需要为我们刚刚部署的 Elastic Stack 安装 Okta 集成。
通过选择刚刚创建的代理策略中的“Okta”名称，我们需要选择“添加集成”来添加 Okta 集成，如下所示。
图像 5：代理策略中的 Okta 集成
在搜索栏中键入“Okta”将显示需要添加的 Okta 集成。选择此集成，应显示以下提示。
图像 6：Okta 集成页面
通过选择“添加 Okta”，我们现在可以开始通过简单的分步过程来设置集成，这与在 Elastic Stack 中添加我们的第一个集成是相辅相成的。
图像 7：将集成添加到 Elastic Stack
在端点上安装 Elastic Agent
如前所述，我们必须在端点上安装至少一个代理，以访问 Okta 中与配置的 Okta 策略关联的数据。我们建议使用轻量级的 Linux 主机，可以是本地虚拟机，也可以是 GCP 等 CSP 中的虚拟机，以使所有内容都保持在同一环境中。对于本出版物，我将在 Google 的 Compute Engine (GCE) 中使用 Ubuntu 20.04 LTS VM 的 VM 实例。您的端点可以是轻量级的，例如 GCP N1 或 E2 系列，因为它的唯一目的是运行 Elastic Agent。
选择“安装 Elastic Agent”按钮，然后选择将在其上安装代理的主机。在此示例中，我们将使用 Linux 主机。选择后，可以使用“复制”选项将命令复制并粘贴到 Linux 控制台中，然后执行。
图像 8：安装 Elastic Agent
创建 Okta 令牌
此时，我们需要一个 API 密钥和一个 Okta 系统日志 API URL 用于集成设置。因此，我们必须转到 Okta 管理控制台来创建 API 令牌。
图像 9：访问 Okta 管理控制台
从 Okta 管理控制台，选择以下内容：
- 安全性 > API > 令牌
- 选择“创建令牌”按钮
在本例中，我们将 API 令牌命名为“elastic”。由于我的管理员帐户创建了令牌，因此它继承了我帐户的权限和特权。一般来说，我们建议创建一个单独的用户，并使用最小权限原则 (PoLP) 正确地限定权限，以获得最佳安全实践。我建议将提供的 API 令牌密钥复制到剪贴板，因为它是 Okta 集成设置所必需的。
图像 10：复制您的 API 令牌
我们还需要捕获 Okta API 日志 URL，这是一个 HTTPS URL，其 URI 为 /api/v1/logs 或系统日志 API 端点。
例如：https://{okta-subdomain}.okta.com/api/v1/logs
Elastic Agent 通过 Okta 集成，将向此 API URL 发送请求，并在请求的授权标头中包含我们的 API 令牌，作为 Web 系统的单点登录 (SSWS) 令牌。有了这些信息，我们就可以完成在 Elastic Stack 中的 Okta 集成设置了。
添加 Okta 集成要求
回到 Elastic Stack 中的 Okta 集成设置，它要求我们添加 API 令牌和 Okta 系统日志 API URL，如下所示。除此之外，我们将“初始间隔”从 24 小时更改为 2 分钟。这将有助于我们在完成设置后立即检查 Okta 日志。
图 11：配置日志收集
将此信息提交到 Okta 集成设置后，我们可以选择“确认传入数据”按钮，以验证日志是否已从 Elastic Agent 正确摄取。
图 12：预览来自 Okta 的数据
虽然我们已确认数据实际上正在从 Elastic Agent 中摄取，但我们还必须确认我们正在摄取 Okta 特定的日志。我建议您花一点时间回到 Okta，并在管理控制台中更改一些设置。这将生成 Okta 系统日志，最终将由我们的 Elastic Agent 提取并摄取到我们的 Elastic Stack 中。完成后，我们可以利用 Kibana 中的“Discover”功能搜索应该已生成的 Okta 系统日志。
以下查询可以帮助我们完成此操作 - event.dataset:okta*
图 13：使用 Discover 浏览您的 Okta 数据
如果您设法从中找到 Okta 日志，那么恭喜您，您已成功完成这些步骤
- 使用试用许可证注册了 Okta Workforce Identity
- 通过 cloud.elastic.co 部署了试用 Elastic Stack
- 将代理部署到您选择的主机
- 创建了 Okta 策略
- 设置了 Okta 集成
- 创建了 Okta API 令牌
- 确认了来自我们的 Elastic Agent 的传入数据
启用 Okta 检测规则
Elastic 拥有 1000 多个预构建的检测规则，不仅适用于 Windows、Linux 和 macOS 端点，还适用于包括 Okta 在内的多个集成。您可以查看我们当前现有的 Okta 规则 和对应的 MITRE ATT&CK 覆盖范围。
要启用 Okta 规则，请在 Elastic Stack 中完成以下操作
- 导航菜单 > 安全 > 管理 > 规则
- 选择“加载 Elastic 预构建的规则和时间线模板”
- 加载所有规则后：a. 选择“标签”下拉列表 b. 搜索“Okta” c. 选择所有规则 > 构建操作下拉列表 > 启用
图 14：搜索开箱即用 (OOB) Okta 检测规则
虽然我们不会深入探讨所有规则信息，但我们建议您 这样做。Elastic 还有其他信息，例如相关集成、调查指南等等！此外，您可以通过单击“创建新规则”按钮 创建自己的 检测规则，并将其 贡献 到我们的检测规则存储库中，从而为我们的社区做出贡献。
让我们触发一个预构建规则
在启用所有 Okta 规则后，我们现在可以继续通过一些简单的模拟来测试这些规则的警报。
在此示例中，让我们使用 尝试重置 Okta 用户帐户的多因素身份验证因素 检测规则，该规则通过预构建的检测规则开箱即用 (OOB)。
图 15：启用 OOB Okta 检测规则以测试警报
要触发，我们只需登录到我们的 Okta 管理控制台，然后从“目录”>“人员”中选择一个用户，然后选择“更多操作”>“重置多因素”>“全部重置”。
图 16：在 Okta 中重置用户的 MFA
完成后，日志将很快被摄取到 Elastic Stack 中，并且检测引擎将针对模式与 logs-okta* 匹配的数据流运行规则的查询。如果一切按预期进行，则警报应通过 Elastic Stack 中的“安全”>“警报”页面提供。
图 17：触发的 OOB Okta 检测规则的警报页面弹出窗口
让我们触发一个自定义规则
可以预见的是，并非所有 OOTB Okta 规则都可能适合您的环境或检测实验室。因此，您可能希望为来自 Okta 集成的数据创建自定义检测规则。请允许我演示如何执行此操作。
假设我们有一个用例，我们想要确定当一个唯一的用户 ID (Okta 参与者 ID) 从两个不同的设备建立会话时，这表明存在潜在的网络会话劫持。
为此，我们将依赖 Elastic 的管道查询语言 ES|QL。我们可以先导航到“安全”>“检测规则 (SIEM)”>“创建新规则”。然后，我们可以选择 ES|QL 作为规则类型。
图 18：Elastic 安全解决方案中的“创建新规则”Kibana 页面
要为此事件重新创建 Okta 系统日志，我们将在相对较短的时间内从多个设备使用同一帐户登录 Okta。为了进行复制，我已通过 macOS 和 Windows 端点以及我的手机执行此操作，以实现多样性。
以下自定义 ES|QL 查询将识别此活动，我们可以在将其添加到新规则之前通过 Elastic Stack 中的 Discover 进行确认。
图 19：在规则实施之前在 Elastic Discover 中测试 ES|QL 查询
现在我们已经调整并测试了我们的查询，并且对结果感到满意，我们可以将其设置为我们新规则的查询。
图 20：使用 ES|QL 查询逻辑创建新的自定义检测规则
图 21：为 Okta 威胁启用带有 ES|QL 查询的自定义检测规则
现在我们的规则已经创建、测试和启用，让我们尝试通过复制此活动来触发警报。为此，我们只需使用多个用户帐户从同一设备登录到我们的 Okta 管理控制台。
正如我们所看到的，我们现在有一个针对此自定义规则的警报！
图 22：触发与自定义检测规则匹配的事件的警报
奖励：同步 Active Directory (AD)
正如我们在 之前的 Okta 安装 中讨论的那样，Okta 的一项核心服务是与第三方 IAM 目录服务（如 AD、Google Workspace 和其他服务）同步。在您的实验室中执行此操作可以实现进一步的威胁检测能力，因为可以在 Windows 日志和 Okta 之间进行用户交叉关联。对于本文，我们将逐步完成在本地 Windows Server 上与 AD 同步的过程。注意 - 我们建议将 Windows Elastic Agent 部署到您的 Windows Server 并设置 Windows 和 Elastic Defend 集成以进行其他日志摄取。
- 设置 您的 Windows Server（我们使用的是 WinServer 2019）
- 从您的 Okta 管理控制台部署 Okta AD 代理 a. 目录 > 目录集成 b. 添加目录 > 添加 Active Directory
- 逐步完成引导步骤，以在 Windows Server 上安装 Okta AD 代理 a. 执行 Okta 代理可执行文件也需要在 Windows Server 端进行设置
- 确认 Okta AD 代理已成功部署
- 将 AD 与 Okta 同步 a. 目录 > 目录集成 b. 选择新的 AD 集成 c. 选择“立即导入”选择增量或完全导入
- 选择要导入的用户和组并导入它们
图 23：成功部署 Okta 代理并与 AD 同步
完成后，在 Okta 管理控制台的“目录”下，您应该会看到已成功导入的人员和组。从这里，您可以模拟攻击场景，例如本地（Windows 主机）被盗的登录凭据被用来重置 Okta 中的 MFA。
其他注意事项
虽然这不仅是 Elastic Stack、Okta 集成以及用于威胁研究实验室的更基本设置，但我们的设置还有其他注意事项，这些注意事项取决于我们的研究目标。虽然我们不会深入探讨具体细节或详尽列出可能的情形，但以下是您的实验室需要考虑的事项列表，以准确模拟企业环境和/或攻击者策略
- Okta 是我的 IdP 真实来源吗？如果不是，请设置第三方（如 Azure AD (AAD) 或 Google Workspace）并同步目录服务。
- 我是否会模拟攻击者行为 - 例如 SAMLjacking？如果是，我需要哪些利用 SAML 进行身份验证的第三方集成？
- 我想研究租户中毒吗？如果是，我应该使用 Okta 设置多租户架构吗？
- 当我尝试绕过 MFA 时，我是否需要单独的软件（如 VPN 或代理）来模拟归因规避？
- 哪些其他工具（如 EvilGinx）允许我尝试网络钓鱼策略，以及这些练习的 Okta 中需要哪些设置？
- 在 OAuth 工作流程期间，我应该如何捕获授权代码，以及如何重放访问令牌的交换请求？
- 对于密码喷洒或凭据填充，我应该集成哪些第三方应用程序，以及多少应用程序足以实现准确的检测逻辑？
- 我应该如何探索用户配置文件的宽松访问策略？
要点
在本指南中，我们已成功导航了使用 Elastic Stack 设置 Okta 威胁检测实验室的过程，突出了保护 Okta 等 SaaS 平台的重要性。我们的旅程包括部署 Elastic Stack、集成和测试 Okta 系统日志以及实施预构建和自定义检测规则。
关键要点是 Elastic Stack 在威胁检测方面的多功能性，它能够适应各种场景并增强网络安全能力。 本演练展示了在 Okta 环境中实现有效的威胁管理既是可行的，也是必要的。
在我们结束时，请记住此练习的真正价值在于它的实际应用。通过建立自己的检测实验室，您不仅可以加强安全态势，还可以为更广泛的网络安全社区做出贡献。请继续关注关于 SaaS 和 Okta 的其他威胁研究内容，我们将在其中探讨针对 Okta 环境的常见攻击以及检测策略。