响应安全事件

从战略上应对影响企业中的 GitHub 组织或存储库的安全事件。

在本文中

本文中的指南面向企业所有者、组织所有者、安全经理和安全团队。 但是，需要具有企业所有者角色才能执行本文中所述的多项操作。 某些步骤可能需要与组织所有者或存储库管理员进行协调。

介绍

本指南逐步讲解如何应对安全事件，概述用于验证和调查威胁的各个方面，并介绍可用于控制和修复威胁的工具。

重要

此处的步骤是一般准则。 每个事件都是独一无二的，可能需要根据具体情况使用不同的方法。

虽然 GitHub 支持 可以帮助解决特定于平台的问题，但在调查和应对影响您系统和资源的安全事件方面，您最有能力和优势。

先决条件

理想情况下，你已为企业启用了 审核日志流式处理 和 源 IP 地址可见性 （将数据流式传输到安全信息和事件管理 （SIEM） 系统），并且你有权访问该数据。 请参阅“流式处理企业审核日志”。

在整个响应中

在进行响应过程中，请确保：

  • 保留证据：获取可疑活动的屏幕截图、导出日志或查询结果，并在清理之前保存受影响文件或代码的副本。
  • 记录：记录你的发现（例如，时间、日期、泄露指标（IoC）、受影响的存储库），并记录你做出的每个决定。
  • 沟通：通知相关利益干系人（如安全主管和工程经理，以及法律和隐私团队（如果敏感数据处于危险状态），并使其保持更新。

步骤 1：评估信号并快速验证

目标是快速确定你看到的信号是否可能是真正的主动威胁。

1. 识别

尝试识别所看到信号的性质。 例如，信号是否显示以下指示：

  • 凭据泄露（泄露机密的警报，在外部站点发现的凭据报告）
  • 未经授权的访问或帐户泄露 （可疑登录报告、不熟悉的提交或更改）
  • 数据外泄 （可疑文件更改或添加报告、意外工作流运行、异常 API 活动、未知存储库创建或意外存储库可见性更改）
  • 恶意代码注入 （报告可疑代码更改、意外的工作流运行、添加新文件）
  • 供应链攻击 （可疑包版本报告、易受攻击依赖项的警报）

若要帮助识别整个组织或企业中的这些威胁信号，请参阅 常见安全事件调查领域。

注意

Runner 的 IP 地址是从共享基础设施中动态分配的，可能会因其他无关活动而被标记。 有关详细信息，请参阅“故障排除工作流”。

建议不要在调查的早期阶段花费太多时间进行深入检查，因为初始目标是 确定 威胁信号，以 验证 威胁信号并制定响应策略。

2. 验证

检查是否有证据来验证潜在威胁是否真实，以及它当前是否处于活动状态。

以下 GitHub 工具和表面可能会有所帮助。

工具/表面Purpose
安全概述和安全警报查看整个组织或企业的安全警报
审核日志搜索与要调查的信号相关的事件，例如令牌创建、权限更改或存储库可见性更改
活动视图查看特定存储库的推送、提交和分支活动的时间线
GitHub 代码搜索跨存储库搜索已知泄露指标，例如特定文件名或代码模式
依赖项关系图检查存储库是否依赖于特定包或包版本
工作流运行和日志查看工作流执行历史记录并检查可疑活动的日志输出

有关每个工具的详细信息，请参阅 安全事件调查工具。

验证阶段可能 很快：

  • 旨在收集足够的证据，以确定信号是否可能是 真实 和 积极的 威胁。
  • 如果无法快速排除信号为误报，则假定它是真实的。
  • 稍后可以执行深入调查。

3. 决定

根据收集的证据，确定三件事：

  1. 这是真正的威胁吗？ 如果不能快速自信地将信号排除为误报，请将其视为真实信号并继续遏制。
  2. 威胁是否仍处于活动状态？ 如果攻击者似乎仍然具有访问权限或仍在活动，请优先立即采取控制措施。 如果妥协看起来是历史的，你仍然需要调查和修正，但你可能有更多的时间来计划你的响应。
  3. 潜在的范围是什么？ 考虑泄露可能达到的距离—单个凭据、存储库、组织或整个企业。 这将帮助你适当地调整响应。

如果有疑虑，请将威胁视为真实威胁，然后根据证据适当调整响应。

步骤 2：包含威胁

下一步假设正在处理真正的活动威胁。 现在的目标是根据你目前所知立即降低持续风险。

可以选择执行多个包含操作来限制攻击者的访问和功能。

重要

应根据威胁的性质、潜在范围和此时提供的证据来选择操作。 我们不建议对每个事件采取所有这些操作。 某些操作比其他操作更具破坏性或破坏性，因此，必须根据对上述威胁性质的评估来权衡每个操作的风险和好处。

撤销已泄露的凭据

对于公开或利用的凭据，可以采取的最直接操作是撤销受影响的凭据，以防止进一步滥用。

  • 通过 API 撤销

    如果令牌是以下类型之一，并且令牌的文本值是已知的，则可以通过 REST API 提交请求来撤销令牌（或任何人）。 请参阅“撤销”。

    • Personal access token (classic)
    • Fine-grained personal access token
    • OAuth app 访问令牌
    • GitHub App 用户访问令牌
    • GitHub App 刷新令牌

  • 吊销和限制选项

    还有一些用于阻止凭据访问的其他选项。 有关按凭据类型列出的完整列表，请参阅 GitHub 凭据类型参考。

  • 撤销或删除特定用户的凭据

    如果已确定特定的泄露帐户，则企业或组织所有者 GitHub Enterprise Cloud 可以撤销该单个用户的 SSO 授权。 对于具有 Enterprise Managed Users 的企业，您还可以彻底删除凭据。 这种方式比批量操作的干扰更小，同时仍能遏制威胁。 请参阅“在企业中撤销授权或删除凭据”。

  • 撤销或删除特定类型的凭据

    如果该事件仅限于一种凭据类型，例如 personal access tokens (classic)，则企业或组织所有者可以使用 或 REST APIGitHub，针对所有成员仅撤销该类型的 SSO 授权，或仅删除该类型的凭据。 这会针对受影响的凭据类型，而不会中断其他凭据。 请参阅“在企业中撤销授权或删除凭据”。

  • 紧急行动（重大事件）

    在 GitHub Enterprise Cloud 上的企业 和组织 所有者可以批量执行紧急操作，对其整个企业 或组织的访问进行锁定。 对于具有 Enterprise Managed Users此功能的企业，这包括 删除所有用户令牌和密钥。 这些是具有高影响力的操作，会破坏自动化，应该仅用于重大事件。 请参阅“响应企业中的安全事件”。

所有这些取消授权和吊销操作（无论是由管理员发起还是由受影响的用户启动）都记录在审核日志中，受影响的用户会收到电子邮件通知。

限制访问

若要限制对企业、组织或存储库的访问，可以立即执行多项操作。

  • 配置 IP 允许列表

    阻止未知或可疑的 IP 地址访问组织或企业。 请参阅 使用 IP 允许列表限制企业网络的流入流量 （企业管理员）和 管理组织允许的 IP 地址 （组织所有者）。

  • 删除遭到入侵或可疑的用户

    删除用户或暂停帐户。 请参阅 从组织中删除成员 （组织所有者）。

  • 将存储库可见性更改为专用

    将受影响的存储库可见性更改为专用存储库，并限制其他人进行进一步更改的能力。 例如，如果敏感代码在属于组织的公共存储库中公开，或者恶意参与者将存储库的可见性设置从专用更改为公共，则可以更改存储库的可见性。 请参阅 设置存储库可见性 （存储库管理员和组织所有者）和 限制在组织中更改仓库可见性 （组织所有者）。

  • 紧急行动（重大事件）

    企业所有者可以在GitHub Enterprise Cloud上采取批量紧急措施来封锁整个企业的访问权限。 其中包括 锁定 SSO 以阻止所有非所有者访问，并 撤消跨组织的所有用户 SSO 授权。 这些是具有高影响力的操作，会破坏自动化，应该仅用于重大事件。 请参阅“响应企业中的安全事件”。

禁用恶意组件和活动

步骤 3：完全调查

立即遏制后，目标是了解事件的完整范围和影响，识别所有 IOC 和持久性机制，并收集用于围堵和完全消除威胁所需的证据。

重要

事件响应不是线性过程。 在发现新的 IoC 或对攻击更加了解时，可能需要反复进行调查、遏制和修正。

  1. 根据你所看到的信号和到目前为止收集的证据，制定一个 工作假设 ，了解所发生的事情，并决定你需要证明或反驳该假设所需的其他证据。

  2. 请考虑 AUTOTITLE 中概述的不同调查区域，以帮助指导调查。

    不要将调查限制在单一方向。 许多攻击使用多种技术的组合，例如恶意包安装与凭据利用、工作流文件注入和数据外泄相结合。 确保正在调查所有潜在的攻击途径。

  3. 记录迄今已知的所有 IoC，在 GitHub 的所有表面搜索跟踪。

  4. 清点 所有受影响的工作流、存储库和组织，以系统地捕获事件的范围。

    • 包括存储库名称、受影响的内容（代码、机密、工作流）和泄露时间线。
    • 创建所有受影响的帐户和凭据的列表。 请注意，哪些令牌、SSH 密钥或其他凭据可能已公开或滥用。

  5. 根据证据验证 你的工作理论。

    • 查看已收集的证据。 它是否支持你的初始假设？
    • 请考虑替代说明。 你观察到的活动是否有其他原因？
    • 如果假设被反驳，请根据证据形成新的假设，并根据需要重复调查步骤。
  6.           如果发现新的 IoC 或持续活动的证据，需要立即采取行动，**请返回遏制**。

对所发生的事情和根本原因的理解高度有信心后，请记录调查结果并继续修正。

步骤 4：修正

现在的目标是删除所有泄露跟踪，修复根本原因，并将系统还原到安全状态。 修正操作将取决于面临的泄露，但一些良好做法如下所示。

轮换令牌和机密

即使不确定凭据是否已被泄露，只要有泄露的可能，也应该轮换凭据。

  • 生成新的令牌和密钥以替换已吊销或可能已泄露的任何令牌和密钥。
  • 在存储库、环境和组织级别轮换存储在 GitHub 中的机密。
  • 在可能已被使用已泄露令牌访问过的外部系统中更新任何凭据。
  • 请考虑启用令牌过期策略，以鼓励今后定期轮换。 请参阅“在企业中强制实施个人访问令牌策略”。

对持久性机制的审核

你需要检查攻击者可能已建立的持久性机制，以确保在您进行初步封锁措施之后，访问权限仍然可以保持。

这包括（但不限于）检查以下内容：

  • 可能已添加或修改的可疑或不熟悉的工作流文件。
  • 指向不熟悉域的新 Webhook。
  • 新自托管运行程序。
  • 对自托管运行程序的修改。
  • 新安装的 GitHub Apps 或 OAuth app 授权。
  • 新的部署密钥已添加到代码库中。
  • 新的二进制文件或可执行文件。

审核并重新安装依赖项

受损的依赖项可以作为攻击途径。 请确保对依赖项进行全面审核，并从受信任的源重新安装依赖项。

  • 查看 Dependabot 中与易受攻击依赖项相关的警报，以及在可用时查看针对恶意包的 Dependabot malware alerts。 有关当前支持的生态系统列表，请参阅 Dependabot 恶意软件警报。
  • 若要调查其他恶意软件公告，请在 type:malware 中搜索 GitHub Advisory Database，并检查您的依赖关系图中是否有匹配项。
  • 将依赖项固定到已知良好的版本或提交 SHA，然后从包注册表重新安装。

验证修正

确认修正工作已成功。

  • 查看 code scanning 警报以确认代码漏洞已解决，并且未引入任何新漏洞。
  • 查看 secret scanning 警报，确认未在任何存储库中公开任何机密，并且所有警报都已解决。
  • 在事件发生后的几天和几周内，继续查看和监视审核日志及其他相关方面。

步骤 5. Document

完整的文档对于剩余阶段和将来的参考至关重要。

  • 记录调查期间发现的所有 IoC。
  • 记录执行的所有修正步骤，包括时间戳和执行每个操作的人员。
  • 维护受影响存储库、工作流和帐户的清单。
  • 记录决策及其背后的推理。
  • 请注意任何合规性、法律或隐私方面的影响。 请考虑此事件是否构成需要通知的数据泄露。

步骤 6：反射和强化

现在的目标是从事件中吸取教训，加强安全态势，以防止类似的事件。

  1. 编写 事件摘要。 这应包括从第一个指示到解决的事件的时间线，以及根本原因分析、决策和行动以及吸取的教训。
  2. 跟踪安全事件中的任何未完成操作项，例如剩余补救任务，以及需要根据所吸取的教训实施的任何安全改进。

Copilot 可以帮助创建这些问题，你可以将定义明确的问题分配给 Copilot 独立处理。 请参阅 启动GitHub Copilot会话。

  1. 如果还没有，请确保您的公司或团队具有最新的一份安全事件响应计划。 这应包括已定义的角色和责任、升级路径、通信协议、严重性分类条件和常见威胁类型的分步响应过程。 Copilot 可以帮助根据特定需求和资源生成和优化此计划。 有关其他指南，请参阅 什么是事件响应。

后续步骤

  • 如果尚未这样做，请考虑强化安全状况，以减少未来事件的风险。 请参阅“防范安全威胁”。