事件管理-计划:网络事件响应流程
2021-10-26
来源:祺印说信安
本节概述了基本响应计划的组成部分,分解了在实践中应如何管理事件。这将能够制定自己的量身定制的计划。
无论组织是 10 人还是 10,000 人,制定有关如何处理事件的指南都将帮助组织在真实事件的压力下做出正确的决策。
花时间制定计划将确定事件处理能力的差距。
制定事件响应计划是实现稳健有效的事件管理和技术响应能力的关键一步。
内容
制定事件响应 (IR) 计划
事件管理 (IM)
事件分类
事件分类
上报和决策
核心技术响应
事后审查
剧本和监管问题
事件响应 (IR) - 制定您的计划
您的网络安全事件响应计划应该是事件处理过程的起点。
基本的事件响应计划应包括:
主要联系人
IR 团队/提供商、IT、高级管理人员、法律、公关、人力资源、保险。 始终考虑人员无法联系的风险 - 理想情况下,包括至少 2 种联系方式和 2 个或更多人(或组)详细信息。
升级标准
随着关键决策的过程
基本流程图或流程
这应该涵盖整个事件生命周期
至少一个会议号
这应该始终可用于紧急事件呼叫
有关法律或监管要求的基本指南
何时寻求法律支持、人力资源或遵循仔细的证据收集指南
这是一个基本的计划,讨论的大多数主题和信息都应记录在组织的 IR 计划中(或旁边)。
增强 IR 计划,请注意包括:
在紧急情况下可以轻松使用的简单清单
用于记录和跟踪事件 以及事件后审查的表格,以确保捕获所有关键要素
包括有关 IR 阶段的 更多详细信息以及有关控制、分析、补救和从事件中恢复的更多技术指导
特定类型事件的剧本/指南
除了 IR 计划外,应该有相互关联的业务连续性、灾难恢复和通信计划(包括内部 和 外部通信)。
事件响应 - 高级流程
下图提供了一个高级事件响应流程的示例,其中的指导说明为红色。
事件管理 - 通讯、监督、跟踪和记录
事件管理汇集了指导、通知和支持整体的协调功能响应过程,包括多个方面,包括:
跟踪、记录、分配和关联所有发现、任务和通信。请注意,在随后可能由监管机构或法院审查的情况下,仔细跟踪整个响应非常重要。这包括真实或潜在的数据泄露和犯罪活动。
安排定期更新会议或电话,以及相关团队的参与
将严重事件上报给高级管理层
确保适当地传达事件(向团队、更广泛的业务、其他利益相关者)
确保涵盖从最初发现到关闭的整个事件生命周期。
*在发生敏感事件或由于网络/电子邮件/电话系统中断而无法使用正常渠道时,请考虑安全或替代通信的选项。
清晰度至关重要
了解每个人的角色和职责对于确保事件得到管理和成功处理至关重要。
无论涉及谁,都必须有一个协调的中心点,以确保所有调查结果相互关联并计划行动。
创建网络安全事件响应团队中显示了一组事件响应团队角色示例。
仔细记录事件响应、做出的决定、采取的行动、捕获(或丢失)的数据对于事后审查非常有用。如果需要向监管机构提供回应证据,则尤其如此。
分类 - 了解事件的类型和严重性
了解事件的类型和严重性可以确定响应有多紧急,还使组织能够确保从一开始就涉及正确的人员。
评估事件时需要考虑两个方面:严重性和类别或类型。
通常根据以下情况考虑严重性:
1、可用性数据或系统的可用性是否受到影响?(即对业务产出有什么影响?)
2、保密敏感数据是否被访问、泄露或窃取?
3、正直数据或系统是否已被更改以致无法信任?
综上所述,应考虑问题的规模、涉及的系统或数据类型以及事件的实际后果。
在量化影响时,拥有详细说明所有关键资产和数据的完整文档会有所帮助。
严重性矩阵
为了帮助组织评估事件的严重性,请创建一个示例结果矩阵,按严重性进行评级。这些将有助于了解事件响应的严重程度、需要参与的人员以及响应是否需要优先于其他活动。
下面是一个示例严重性矩阵。应该仔细考虑什么对业务最重要,并根据组织定制示例列:
严重性例子
危急
超过 80% 的员工(或几个关键员工/团队)无法工作
没有已知解决方案的关键系统离线
敏感客户或个人数据的高风险/明确泄露
?[TBC] 的财务影响
严重的声誉损害 - 可能会长期影响业务
高的
50% 的员工无法工作
泄露个人或敏感数据的风险
非关键系统受到影响,或关键系统受到已知(快速)解决方案的影响
?[TBC] 的财务影响
潜在的严重声誉损害
中等的
20% 的员工无法工作
可能泄露少量非敏感数据
声誉风险低
少数非关键系统受到已知分辨率的影响
低的
影响最小(如果有的话)
一两台非敏感/非关键机器受影响
<10% 的非关键员工暂时受到影响(短期)
事件的分类
应该确定面临的事件类型。一些例子包括:
恶意代码:网络上的恶意软件感染,包括勒索软件
拒绝服务:通常会导致网站大量流量瘫痪,可能适用于电话线、其他面向 Web 的系统,在某些情况下也适用于内部系统。
网络钓鱼:试图说服某人信任链接/附件的电子邮件。
未经授权的访问:未经授权的人(内部或外部)访问系统、账户、数据——例如访问某人的电子邮件或帐户。
内部人员:员工的恶意或意外行为导致安全事件。
数据泄露:丢失/被盗的设备或硬拷贝文件、未经授权的访问或从网络中提取数据(通常与上述一些相关联)。
有针对性的攻击:专门针对企业的攻击 - 通常是由老练的攻击者发起的(通常包括上述几个类别)。
类别矩阵
与严重性一样,创建不同类别的矩阵非常有用。
可以通过在每个类别旁边添加不同严重性事件的示例来增强这一点。这将有助于指导和告知回应。
图片
上报 - 决策和权力
升级
通常,矩阵用于确定事件的严重性或优先级。严重性级别将告知需要多快处理事件以及可能需要将其上报给谁。
例如,一个高危或危急的事件很可能总是需要上报到 CIO 或董事会级别。低优先级事件很可能由 IT 安全团队单独处理。应该记录上报联系人是谁,以及他们的联系方式(包括非工作时间)以及上报需要多快发生。
当局
升级到的人必须有权做出关键决定。例如,当决策可能导致重大业务影响时,例如使关键服务或系统脱机。
确定有权(或拥有授权)做出此类决定的人员,并确保上报流程酌情包括这些关键人员。如果主要联系人不可用,考虑代理和使其他人能够做出决定的流程也很重要。
除了通用指南之外,确定技术团队应根据最高业务风险自主行动的特定情况以及早期采取遏制措施可能会减少特定事件的影响的特定情况可能很有用。
核心响应 - 事件响应周期
技术响应能力中详细考虑了分析、遏制、修复和恢复四个核心响应阶段。
但是,此处提供了每个阶段的简要说明。
分析
遏制/缓解
修复/根除
恢复
在整个响应过程中,应跟踪所有任务和发现。调查结果和分析应该相互关联,重新确定响应行动的优先级。
在某些情况下,响应需要升级或降级。
事件后审查和关闭 - 从事件中学习
事后审查应包括:
事件本身的教训
是否有安全改进可以防止事件发生或启用早期检测?
考虑可以防止或检测到此事件的战术修复以及可能只能在多个事件中识别的战略解决方案。例如,无效的治理流程导致通过以前未记录的、面向互联网的资产进行多次入侵。
特别是,是否有任何信息对您的回答有很大帮助,但很难或不可能获得?制定计划,在未来发生任何攻击之前收集这些数据。
回应的教训
响应是否成功且有效?
有没有可以更好地处理的元素?
是否有可能有用但不可用的数据(例如,正确的日志,或在响应早期被覆盖的内容?)。保留响应期间活动的记录将有助于此审查。
问题
应该跨人员、流程和技术能力考虑这些问题。
例如:
是否有相关数据和工具可用于进行分析?
流程和沟通是否运作良好?
是否有合适的人参与并有权做出必要的决定?
剧本
剧本(或运行手册)是详细的响应计划,通常侧重于特定的事件类型。
典型的剧本示例包括“恶意软件感染”、“网络钓鱼电子邮件”、“数据泄露”等。
我们建议从前 3-5 种最有可能和高风险的事件类型开始。要确定这些是什么,请查看之前影响组织的事件,并利用与您所在行业和所在国家/地区相关的威胁情报和一般网络安全新闻。
还应该考虑那些适用于全球的威胁,例如主要的勒索软件攻击。
至少,应该记录一组简单的说明,这些说明至少涵盖每个事件的前几个小时,因为这些可能是最关键和时间紧迫的。
手册说明应包括:
与谁联系 - 技术团队、供应商、高级管理人员,以及在需要时何时与法律、人力资源、公关联系
如何理解/分类事件(与此类事件相关的细节)
减少影响/防止进一步影响的指南 - 特定类型的遏制或缓解行动
必要时保留证据或数据的步骤
增强的剧本
还可以包括更多的事件类型和额外的指导阶段。例如,关于分析、如何完全补救和从事件中恢复、如何以及何时关闭以及如何执行事件后审查的指导。
应该考虑法律、媒体和监管方面的问题。或者,IR 团队的剧本可能只包含有关何时与这些团队合作的指导,他们可能在这方面有自己的详细指导。
如果合适,还可以在事件管理和编排系统中实施和嵌入剧本。
法律和监管要求
无论业务类型如何,位于英国或欧盟或在英国或欧盟开展业务,都需要遵守GDPR和DPA法规。在中国,则需要遵守《网络安全法》《数据安全法》等法律法规。
几乎所有组织都将保存员工及其客户的个人数据。该行业可能还有特定的监管要求,并且可能存在基于任何合同协议的特定客户报告要求。
这方面的最低准备工作应包括参与法律咨询和记录:
根据企业持有的数据类型和数量(包括供应商持有的任何数据),什么构成可报告事件
何时以及如何获得法律支持
需要额外的步骤。例如,保存证据或记录所采取的行动
为了进一步改善这一点,还应考虑以下几点:
创建可用于任何监管报告的表格
举办研讨会,重点关注援引法律/监管要求的场景,并演练适当的步骤
执法和取证
如果决定进行任何法律诉讼(例如起诉犯罪分子),则还需要聘请相关执法机构。这(以及任何民事案件)可能需要谨慎处理证据。