安全事件

检查清单#

这些项目的详细信息在下一节中提供。

1. 停止正在进行的攻击。
2. 切断攻击向量。
3. 组建响应团队。
4. 隔离受影响的实例。
5. 确定攻击的时间线。
6. 识别被泄露的数据。
7. 评估对其他系统的风险。
8. 评估再次攻击的风险。
9. 应用额外的缓解措施，增加监控等。
10. 对受影响的系统进行取证分析。
11. 内部沟通。
12. 涉及执法机构。
13. 联系可能被用作攻击向量的外部方。
14. 外部沟通。

攻击缓解#

尽快通过任何必要手段停止攻击。关闭服务器，网络隔离它们，如果有必要，关闭数据中心。一些常见的尝试包括：

• 从提供商控制台关闭实例（如果可以的话，不要删除或终止，因为我们需要进行取证）。
• 如果你碰巧登录到该服务器，可以尝试：
  • 恢复我们的默认iptables规则以限制流量。
  • kill -9任何你认为是攻击者的活动会话。
  • 更改root密码并更新/etc/shadow以锁定所有其他用户。
  • sudo shutdown now

切断攻击向量#

识别可能的攻击向量并修复它们，以防止在停止攻击后立即重新利用。

• 如果你怀疑第三方提供商被攻破，删除所有账户，除了你自己的（以及其他在场的其他人），并立即轮换你的密码和MFA令牌。
• 如果你怀疑服务应用程序是攻击向量，禁用任何相关的代码路径，或完全关闭服务。

组建响应团队#

识别安全事件的关键响应者并让他们保持联系。建立一种安全的方法来交流与事件相关的所有信息。在确信攻击不是由内部触发之前，应将事件的细节（甚至事件发生的事实）保密给响应者。

• 如果没有这样做，呼叫一位事件指挥官。他们还将任命通常的事件指挥角色。事件指挥团队将负责记录所采取的行动，并在适当的时候通知内部利益相关者。
• 给项目起一个无害的代号，用于聊天/文档，这样如果有人无意中听到，他们不会意识到这是一起安全事件。（例如，蓝宝石独角兽）。
• 如果尚未进行，开始语音通话。
• 使用事件的代号设置聊天室。
• 邀请所有响应者加入语音通话和聊天室。
  1. 安全团队应始终包括在内。
  2. 任何受影响服务的代表应包括在内。
  3. 尽早邀请执行利益相关者和法律顾问，但优先考虑操作响应者。
• 在完成取证之前，不要与响应团队以外的人交流事件。攻击可能是内部发生的。
• 在所有电子邮件和聊天主题前加上“律师工作项目”。

隔离受影响的实例#

任何受攻击影响的实例应立即与其他实例隔离。尽快对系统进行镜像，并将其放入只读冷存储中，以供以后的取证分析。

• 从所有其他主机中屏蔽任何受影响实例的IP地址。
• 如果没有这样做以停止攻击，立即关闭并关闭实例。
• 对连接到实例的任何磁盘进行磁盘镜像，并将其发送到离线冷存储位置。确保这些镜像是只读的，不能被篡改。

识别攻击的时间线#

利用所有可用的工具来识别攻击的时间线，以及攻击者究竟做了什么。

• 攻击开始前攻击者在系统上进行的任何侦察。
• 攻击者何时获得系统访问权限。
• 攻击者在系统上执行的操作及其时间。
• 识别攻击者在被检测到之前，以及在被踢出之前，对系统有多长时间的访问权限。
• 识别攻击者在数据库上运行的任何查询。
• 尝试识别攻击者是否仍然通过另一个后门访问系统。监控日志中的异常活动等。

被泄露的数据#

利用日志文件的取证分析、时间序列图表以及任何其他可用的信息/工具，尝试识别哪些信息被泄露（如果有的话），

• 识别攻击期间被泄露的任何数据。
  • 是否有任何数据从数据库中被外泄？
  • 系统上哪些密钥现在被认为是泄露的？
  • 攻击者是否能够识别系统的其他组件（绘制网络图等）？
• 准确找出哪些客户数据被泄露，如果有的话。

评估风险#

根据被泄露的数据，评估对其他系统的风险。

• 攻击者是否有足够的信息找到另一种进入方式？
• 主机上是否存储了任何密码或密钥？如果是，无论它们是如何存储的，都应被视为泄露。
• 在初始攻击中使用的任何用户账户应在他们拥有的每个其他系统上轮换所有密钥和密码。

应用额外的缓解措施#

开始对系统的其他部分应用缓解措施。

• 轮换任何泄露的数据。
• 识别需要的新警报，以通知类似的违规行为。
• 屏蔽与攻击相关的任何IP地址。
• 识别任何被泄露的密钥/凭证，并立即撤销其访问权限。

取证分析#

一旦你确信系统是安全的，并且有足够的监控来检测另一次攻击，你就可以进入取证分析阶段。

• 利用你创建的任何只读镜像，你拥有的任何访问日志，并仔细检查它们以获取更多关于攻击的信息。
• 准确识别发生了什么，如何发生的，以及如何在未来防止它。
• 跟踪所有参与攻击的IP地址。
• 监控日志中攻击者试图重新访问系统的任何尝试。

内部沟通#

委派给：工程副总裁或总监

只有在通过取证分析确信攻击不是由内部发起的情况下，才进行内部沟通。

• 不要过于详细。
• 概述时间线。
• 讨论采取的缓解步骤。
• 一旦了解更多信息，再跟进。

与执法机构/外部行为者联络#

委派给：工程副总裁或总监

与执法机构合作，识别攻击的来源，让任何系统所有者知道他们控制的系统可能被攻破，等等。

• 联系当地执法机构。
• 联系FBI。
• 联系在攻击中使用的任何系统的运营商，他们的系统也可能被攻破。
• 联系安全公司帮助评估风险和任何后续的公关步骤。
• 联系你的网络安全保险提供商。

外部沟通#

委派给：营销团队

一旦你验证了所有信息的准确性，有了事件的时间线，知道了哪些信息被泄露，如何被泄露，并且确信它不会再发生。只有这样，你才应该准备并向客户发布公开声明，告知他们被泄露的信息以及他们需要采取的任何步骤。

• 在任何公告的标题中包含日期，以免与潜在的新违规混淆。
• 不要说“我们非常重视安全。”当人们读到这句话时，他们会感到反感。
• 诚实，承担责任，并提出事实，以及我们计划如何在未来防止此类事件。
• 尽可能详细地描述时间线。
• 尽可能详细地描述被泄露的信息及其对客户的影响。如果我们存储了不应该存储的东西，要诚实地说明。这会在以后曝光，而且会更糟。
• 不要点名羞辱任何可能导致泄露的外部方。这是不好的行为。（除非他们已经公开披露，在这种情况下，我们可以链接到他们的披露）。
• 尽快发布外部沟通，最好是在泄露后的几天内。你等待的时间越长，情况会越糟。
• 如果可能，在向公众发出通知之前，先与客户的内部安全团队联系。

事件期间的沟通#

• 首选语音通话和Slack，而不是其他任何方法。
• 避免使用电子邮件，但如果出于某种原因绝对需要，
  • 电子邮件的主题应该是“律师工作项目”，别无其他。
  • 如果电子邮件链中有任何非@pagerduty.com域的联系人，确保你的电子邮件是加密的。
• 不要使用短信来交流事件。
  • 唯一的例外是告诉某人转移到更安全的渠道。例如，“请尽快加入Slack。”
• 在获得批准之前，不要向响应团队以外的人传播任何关于事件的信息。

附加阅读#

• 计算机安全事件处理指南（NIST）
• 事件处理者手册（SANS）
• 应对IT安全事件（Microsoft）
• 定义CSIRT的事件管理流程：正在进行的工作（CMU）
• 创建和管理计算机安全事件处理团队（CSIRT）（CERT）