安全事件中最困难的部分通常发生在事件本身结束之后：企业必须解释发生了什么、何时发现的、涉及哪些数据、谁受到影响，以及为什么做出某些决定。
对许多中小企业而言，这些记录并不完整。详细信息可能散落在聊天消息、收件箱、帮助台工单、截图以及团队成员的记忆中。企业凭借这些拼凑起来的记录在事件期间勉强维持，但当监管机构、保险公司、客户或董事会成员要求提供清晰的时间线时，问题就出现了。
各种规模的企业都需要一份详尽的安全事件日志。它应当成为单一事实来源，记录发生了什么、事件是如何处理的，以及有哪些证据支持在此过程中做出的决定。
即使你不需要报告事件，这些记录也很有价值。我们将解释为什么安全事件日志对企业有帮助，以及如何创建自己的日志。
为什么安全事件日志很重要
安全事件日志在企业最可能疏于记录详细信息的时候建立问责机制。事件期间，行动发生得很快：重置密码、停用帐户、联系 IT 提供商、检查客户数据并向领导层通报。这些步骤在当时可能正是企业所需要的，但如果没有记录每项行动发生的时间、由谁批准以及有哪些证据支持该决定，事后解释起来就会困难得多。
对于总部位于欧洲的企业来说，这不仅仅是良好实践。根据《通用数据保护条例》 (GDPR)，无论是在英国还是欧盟，个人数据泄露事件都需要进行评估，其中一些必须报告给相应的监管机构。
在英国，ICO 的 报告违规（新窗口） 指南解释说，组织必须评估对人们权利和自由的潜在风险，并在风险可能发生时通知 ICO。第33条还要求控制者记录个人数据泄露事件，包括泄露事实、影响以及采取的补救措施。欧盟 GDPR 下也适用相同要求。
例如，ICO 并不要求每家中小企业都拥有企业级系统，但确实要求有适当的记录。其泄露响应和监控框架指出，组织应制定程序，确保个人数据事件和泄露事件能够被检测、管理并适当记录。这意味着不应只在严重泄露已经发生后才创建事件日志。它应当成为正常响应流程的一部分。
良好的记录也有助于保险索赔。网络保险公司可能会要求提供证据，说明事件何时被发现、采取了哪些遏制措施、哪些帐户受到影响，以及企业是否遵循了其事件响应流程。保存完好的日志可以显示企业行动迅速且始终如一。
它还能帮助公司学习。记忆和口头记录并不可靠，但一份记录若能显示事件始于重复使用的密码、缺少 多重身份验证 (MFA)、供应商访问或延迟的离职流程，就能为企业提供具体的修复事项，以及随着时间推移加强安全的更清晰方向。
事件日志与事件响应计划的区别
安全事件日志和事件响应计划相互关联，但并非同一份文件。
事件响应计划 说明了当出现问题时企业应该怎么做。它分配角色、升级路径、遏制措施、沟通职责和恢复程序。事件日志记录实际发生的事情。它是特定事件的时间线、证据链、决策记录和后续文件。
这种区别很重要，因为即使是一份好的计划，如果没有文档记录也可能失败。企业可能采取了正确的步骤，但事后仍难以证明。日志应当能够回答一些实际问题：我们何时得知、谁采取了行动、遏制了什么、哪些数据面临风险、我们做出了什么决定，以及之后发生了什么变化？
| 事件响应计划：你的企业应该做什么 | 安全事件日志：实际发生了什么 |
| 谁领导响应 谁联系 IT、法律、保险公司或监管机构 如何遏制、恢复和沟通 | 事件何时被发现 哪些系统和数据受到影响 采取了哪些行动、由谁采取以及何时采取 |
安全事件日志应包含哪些内容
一份有用的事件日志需要足够一致，以便企业日后重建事件经过，并解释响应期间做出的决定。
发现日期和时间
记录企业首次察觉事件的时间、谁注意到它以及如何发现的。如果时间只是近似值，请标记为近似。发现时间很重要，因为 GDPR 报告时间线和保险要求通常取决于企业何时察觉问题。
事件性质
用平实的语言描述发生了什么。避免使用“安全问题”或“可能的泄露”等没有上下文的模糊标签。日志应说明哪些系统受到影响，以及事件是否涉及凭证、电子邮件、文件、客户数据、支付系统、端点或第三方访问。
涉及的数据
如果个人数据可能受到影响，请记录涉及的数据类型：姓名、电子邮件地址、电话号码、地址、帐户详细信息、财务信息、员工记录、客户通信、登录凭证或任何其他相关类别。估计可能受影响的个人数量，并明确该数字是已确认还是仍在调查中。
可能的原因
记录已知或怀疑的原因，即使调查仍在进行中。随着新详细信息出现，日志可以从“原因未知”更新为“网络钓鱼电子邮件导致凭证泄露”或“前承包商帐户仍然活跃”。日志应显示企业的理解如何随时间变化。
立即遏制措施
记录为限制损害而采取的措施。这可能包括重置密码、撤销会话、强制执行 MFA、暂停帐户、移除邮箱规则、隔离设备、移除供应商访问、更改防火墙或临时关闭服务。在可能的情况下，为每项行动包含负责人和时间戳。
通知决定
记录企业是否通知了相关监管机构（英国的 ICO，或欧盟其他国家的国家数据保护机构）、受影响的个人、客户、供应商、保险公司、法律顾问或执法机构。如果决定不通知，请记录理由。这种解释往往与通知本身同样重要。
补救措施和时间线
遏制针对的是即时事件。补救则降低同一问题再次发生的可能性。记录后续行动，例如强制执行 MFA、移除共享凭证、更新访问策略、改进离职流程、修复错误配置或更改备份的保护方式。
经验教训
最后写明企业学到了什么以及将改变什么。这不应写成指责。它应指出弱点、需要改进之处以及谁负责后续跟进。
面向中小企业的简单事件日志模板
记录事件并不需要专业软件。如果访问受到控制且条目保持一致，电子表格、安全的内部表单、工单系统或共享登记表都可以使用。
有效的事件日志应包含以下字段：
- 事件 ID： 唯一参考编号。
- 发现日期和时间： 企业察觉事件的时间。
- 报告人：员工、服务提供商、客户、供应商、监控警报或外部方。
- 事件类型：网络钓鱼、恶意软件、凭证泄露、数据丢失、未经授权的访问、勒索软件、供应商事件、设备丢失、电子邮件误发或其他。
- 摘要：用通俗语言说明发生了什么。
- 受影响系统：涉及的应用、帐户、设备、数据库、收件箱或第三方服务。
- 涉及数据：个人数据是否受到影响、涉及哪种类型，以及可能影响多少人。
- 可能原因：已知、疑似或正在调查。
- 遏制措施：立即采取了哪些行动。
- 通知决定：监管机构、个人、客户、保险公司，或不予通知并说明理由。
- 证据链接：截图、工单、日志、电子邮件、访问记录、导出文件或提供商报告。
- 补救措施：遏制后采取的措施。
- 负责人：负责跟进的人员。
- 状态：未解决、监控中、已遏制、已解决、已关闭。
- 经验教训：应做出哪些改变。
如何记录通知决定
通知决定应在安全事件日志中单独记录，因为事件发生后往往需要审查。
根据英国和欧盟 GDPR，发生个人数据泄露时，组织必须评估对个人权利和自由可能造成的风险。如果风险很可能发生，必须尽快通知监管机构，并在可行的情况下于 72 小时内通知：英国的 ICO（新窗口），或各欧盟成员国的国家数据保护机构。如果风险很高，还必须及时通知受影响的个人，不得无故拖延。两边的门槛和时限相同；只是主管机构不同。
一份良好的事件日志应显示企业进行了这项评估。它应记录是否涉及个人数据、可能造成何种损害、当时有哪些保护措施，以及企业为何决定报告或不报告。
例如，涉及管理员密码泄露的事件可能不会立即揭示个人数据是否被访问。日志应反映这种不确定性。它可以记录最初的担忧、调查步骤、帐户活动审查，以及证据可用后的最终结论。
在流程进行到这一步时，许多企业专注于安排技术修复，却忘记记录合规方面的推理。密码被重置，帐户得到保护，运营继续。几周后，企业无法解释为何认定该事件无需报告。
监管机构对记录有何期望
监管机构不仅查看是否报告了泄露事件，还可能询问企业如何：
- 识别事件
- 评估风险
- 决定是否需要通知
- 记录所采取的行动
一份良好的记录应从头到尾清晰说明事件经过。它应显示发生了什么、涉及哪些个人数据、可能造成什么损害、企业为遏制问题采取了哪些措施，以及为何报告或未报告该泄露事件。
详细程度应与事件的严重性相匹配。误发的电子邮件不需要像勒索软件攻击那样记录，但仍需记录在案，以显示企业已对其进行适当评估。
这些记录还应安全存储。事件日志可能包含有关受影响个人、暴露系统、员工操作、截图、访问日志或补救步骤的敏感详细信息。访问应仅限于需要的人员，保留期限应与公司更广泛的数据保留策略保持一致。
凭证访问日志
许多事件都涉及凭证：它们可能由重复使用的密码、共享帐户、已泄露的收件箱、暴露的管理员登录、可疑的 MFA 提示，或未妥善办理离职的员工触发。
因此，凭证访问记录可以直接作为网络安全事件文档的输入。当事件涉及共享登录或敏感帐户时，企业需要知道谁拥有访问权限、访问是如何共享的、权限是否发生变化，以及事件发生后凭证是否已轮换。
像 Proton Pass for Business 这样的企业密码管理器可帮助团队在已加密的保险库中管理凭证、生成唯一密码、使用自动填充、安全地分享凭证、管理通行密钥，以及使用内置的双因素身份验证。对于事件文档而言，最大的价值在于围绕凭证的访问轨迹：谁有权访问共享保险库/帐户、访问如何被管理以及由谁使用，以及事件发生后发生了哪些变化。
面向 IT 团队的密码管理器增加了管理员功能，例如策略、报告、日志、基于角色的访问控制、SCIM 预配以及 SSO 集成。这些功能可以帮助企业显示凭证访问是如何受到控制的，并在调查与凭证相关的事件时提供证据。
密码管理器无法取代事件日志、法律评估、监管通知流程或事件响应计划。但它可以提供凭证证据，供这些流程使用。
使用企业密码管理器，保留完整的凭证访问审计轨迹。
