Rhosinjay-cyb/Incident-Response-with-Playbooks

## 项目标题 使用 playbook 自动化安全事件响应 ## 目标 本项目的旨在设计一个基于 Azure Logic Apps 的 playbook，并通过自动化规则将其与 Microsoft Sentinel 集成，以促进对 Microsoft Sentinel 中安全事件的自动响应，从而支持安全运营 的有效管理。 ## 使用的工具 Microsoft Sentinel、Microsoft Defender 门户、Azure Logic Apps ## 实验环境设置 * 创建分析规则 * 使用 Azure Logic Apps 设计 playbook 的工作流 * 创建自动化规则（将 playbook 与安全事件集成） * 测试 playbook ## 背景信息 本项目标志着我关于使用 Microsoft 安全堆栈工具管理安全运营项目的延续。在本项目开始之前，以下资源和服务（Azure Bastion, Project-BST；虚拟机, Sales-VM；虚拟网络, Project-vnet；子网, Sales-vnet 和 AzureBastionSubnet；集成了 Microsoft Sentinel 的 Log Analytics Workspace, Project-workspace；所有资源均位于同一资源组 Project-RG 中）已经部署完毕，并将在本项目的测试阶段使用。此外，Azure Bastion (Project-BST) 的诊断设置也已经启用，其事件日志正被发送到集成了 Microsoft Sentinel 的 Log Analytics Workspace (Project-workspace) 进行分析。 为了提供项目背景，销售部门拥有一台托管关键应用程序和数据的虚拟机 (Sales-VM)，并希望增强其安全性。该部门批准了 Azure Bastion 和一个特定的 IP 地址用于远程连接到 VM。该部门希望将所有其他 IP 视为不受信任的 IP，并阻止此类连接。因此，针对销售部门的安全解决方案是本项目的核心。 最初，用于远程连接的每个 IP 都可以通过存储在 Project-workspace 的 MicrosoftAzureBastionAuditLogs 表中的事件日志进行监控。 为了解决销售部门的安全挑战，将创建一条分析规则来检测使用不受信任 IP 的远程连接，设计 playbook 工作流，并利用附加到该分析规则的自动化规则来触发 playbook。playbook 的主要操作是一旦检测到攻击，便阻止到 VM 的入站连接，特别是 RDP 流量。但是，被阻止的流量只会阻止将来对 VM 的远程连接，而攻击者的远程会话仍将保持活动状态。下一个操作是在所有活动的远程会话中识别攻击者的远程会话并将其关闭。playbook 的最后一个操作是向安全运营团队的相关成员发送有关 playbook 执行结果的电子邮件通知，以便其采取必要的行动。 下一节将讨论分析规则的创建和 playbook 中工作流的设计，随后分别是 playbook 的测试和结论。 ## 采取的步骤 该项目按以下顺序完成 ### 创建分析规则 项目以创建一个名为“UnusualBastionAccess”的计划分析规则开始，用于检测通过不受信任 IP 经由 Azure Bastion 到 Sales-VM 的远程连接。  ### 创建 Azure Logic App playbook 该 playbook 使用 Microsoft Sentinel 事件作为触发器创建。在创建 playbook 时，指定了订阅和资源组以及 Azure Logic App 的层级。  ### 设计 playbook 的工作流 创建 playbook 后，使用逻辑应用设计器面板设计了 playbook 从触发器到最后一个操作的工作流。  工作流的触发器是 Microsoft Sentinel Incident，因为该 playbook 被设计为在 Microsoft Sentinel 中创建事件时运行。 为了收集事件中的实体，初始化了这些数组数据类型的变量，用于收集和存储实体。 注意：实体映射是安全团队在创建分析规则时的职责，将正确的实体映射到分析规则有助于丰富事件调查。  for each 循环有两个独立的条件用于收集实体。第一个条件在实体种类等于 Ip 时将 IP 附加到数组 IPList 中；而第二个条件在实体种类等于 Account 时将 Username 附加到数组 UserList 中。  上述操作仅实现了从安全事件中收集实体。 下一个操作用于创建网络安全组 安全规则，以阻止到 Sales-VM 的所有入站连接，包括传入的 RDP 流量。此操作使用了 Azure Resource Manager 连接器，并在可用选项中选择了“Create or update resource”。相应地填写了参数，资源浏览器在获取短资源 ID 方面非常有帮助。在高级参数中选择并同样指定了位置和属性。属性字段中的值现在将通过更新 Sales-VM-nsg 用于创建 NSG 安全规则，该规则将阻止到 Sales-VM 的入站连接。阻止入站流量将防止攻击者重新连接。 注意：为了使 Playbook 完成此操作，需要将 playbook 的托管标识分配在虚拟机的 NSG (Sales-VM-nsg) 处被赋予网络参与者角色，以强制执行最小权限原则。  工作流中的下一个操作是关闭攻击者的远程会话。此操作还确保仅关闭恶意会话，而跳过其他会话，从而防止对生产运营的破坏。此操作通过 HTTP 连接器实现，该连接器向 Azure Resource Manager (ARM) 的 API 发送 Web 请求，ARM 验证了请求并允许 runCommand 服务利用 Azure VM 代理执行在 HTTP 请求正文中指定的 PowerShell 脚本，主要是为了关闭攻击者的远程会话。 注意：为了使 Playbook 完成此操作，需要将 playbook 的托管标识在资源 Sales-VM 的范围内分配虚拟机参与者角色。  工作流中的最后一个操作是向安全运营团队的相关成员发送电子邮件通知，以进行事件审查和其他必要操作。除了向团队发出警报外，该电子邮件还提供了攻击的概要，包含从安全事件中提取的实体详细信息。  ### 将 playbook 与 Microsoft Sentinel 事件集成 创建了一个自动化规则，将 playbook 与 Microsoft Sentinel 事件集成。安全事件的生成始于安全警报，而分析规则负责触发安全警报。因此，编辑了之前创建的分析规则，并在分析规则的“Automated Response”选项卡中创建了一个自动化规则。此配置现在允许在生成事件后触发 playbook。 自动化规则中有两个操作，第一个是将安全事件分配给 SecOps 团队的一名成员，另一个操作是运行 playbook。   为确保 Microsoft Sentinel 与 playbook 之间无缝交互而实施的一个主要先决条件是，在资源组级别配置 Microsoft Sentinel 的 playbook 权限。此配置会自动将 Microsoft Sentinel Automation Contributor 角色分配给 Azure Security Insights (服务主体)，这赋予了 Microsoft Sentinel 触发该资源组中任何 playbook 的权限。但是，拥有 Microsoft Sentinel Contributor 角色的用户也可以在安全事件上手动运行 playbook。  ## 测试 Playbook 使用 Sales-user 账户（与 Sales-VM 一起创建）通过 Azure Bastion 使用受信任 IP 登录到 Sales-VM。然后在 Sales-VM 上创建了一个新的用户账户，并将其添加到远程桌面用户组，以允许使用 Random-user 账户进行远程登录。  注意：创建新用户账户只是为了有效地演示 playbook 的测试。  为了模拟攻击场景，使用 Random-user 账户通过 Azure Bastion 远程登录到 Sales-VM，但使用的是不受信任的 IP 地址。   检测到使用不受信任 IP 连接到 Sales-VM 导致触发了 Microsoft Sentinel 警报，随后生成了事件。  在查看事件页面时，观察到自动化规则已将事件分配给了 SecOps 团队的一名成员。 对事件页面的进一步审查表明，该 playbook 已被事件成功触发。  在 playbook 运行之后，其预期结果得到确认如下： 创建了一个 NSG 安全规则，以阻止到 Sales-VM 的所有入站 RDP 连接；  关闭了使用不受信任 IP 连接的攻击者 的远程会话；  并向 SecOps 团队的相关成员发送了电子邮件通知，以采取必要行动。  恢复操作和事件管理包括以下内容： 删除由 playbook 操作创建的 NSG 规则，以允许到 VM 的远程连接；  对安全事件进行分类；  并关闭该事件。   ## 进一步测试 实施了进一步的测试以评估 playbook 的性能。在这种情况下，在 Sales-VM 上创建了另一个用户账户 并将其添加到远程桌面用户组。之后，两个用户账户 (Random-user 和 SecondRandom-user) 都通过 Azure Bastion 登录到 Sales-VM，且两个用户使用了不同的不受信任 IP。    同样，攻击被检测到，并导致了安全事件。事件页面显示了涉及攻击的账户和 IP。每个攻击者的会话也被关闭，并且与攻击相关的所有实体都被提取并随电子邮件通知发送。在攻击是同时发生的并涉及多个账户和 IP 的情况下，playbook 将提取每一个实体（正如在事件页面中看到的那样），并且每个攻击者的会话都将被关闭。  ## 结论 本项目成功演示了 playbook 在支持事件响应同时增强安全运营管理方面的实施。它还提供了有关在 Azure Logic Apps 中设计和编排工作流以与 Microsoft Sentinel 无缝集成的宝贵见解。总体而言，该项目突出了对现实世界安全事件的端到端管理，涵盖了从检测和遏制到恢复和关闭的完整事件生命周期。 ## 过往项目 * 部署 Azure Firewall 以实现安全访问和流量控制 * 部署 Microsoft Sentinel 以支持云工作负载保护

标签：AI合规, Azure Bastion, Azure Logic Apps, IP 地址批量处理, IP封锁, Microsoft Sentinel, Playbook, SecOps, 云安全架构, 分析规则, 剧本, 威胁管理, 安全事件响应, 安全编排自动化与响应(SOAR), 安全运营中心(SOC), 微软安全栈, 网络安全, 网络安全实验室, 自动化规则, 虚拟机安全, 隐私保护