类比分析|新冠疫情危机处置VS信息安全事件响应
2020-03-17
- 前言
本次突发的新冠疫情来势汹汹，截至目前除我国外全球多个疫情爆发地区呈现不乐观发展的态势，部分国家政府已经将其视为一个关系到国家公共卫生安全的威胁并对应提高了威胁级别和采取了相应的应对措施。新冠疫情是一场公共卫生的突发事件，其处置流程和信息安全事件响应处置的流程实质上并无根本区别。因此，如果从信息安全事件响应管理的角度去看待各国政府应对本次突发疫情的处置措施和效果，确有不少值得警惕和学习的地方。
- 信息安全事件响应管理内容简析
信息安全事件响应管理是IT治理中关于信息安全运营的一个重要的管理程序。它主要解决发生信息安全事故后机构如何通过既定的处置预案，协调安排相应的资源去处理解决正在发生或已经发生的安全风险，将其限制在企业机构能够承受的风险接受范围内。关于信息安全的应急处置管理，国内外有大量的安全标准、实践指南和手册可供参考。其中国内的标准包括《信息安全事件管理 第1部分：事件管理原理》（GB/T 20985.1-2017）、《网络安全事件描述和交换格式》（GB/T 28517-2012）、《信息安全应急响应计划规范》（GB/T 24363-2009）、《信息系统灾难恢复规范》（GB/T 20988-2007）以及正在制定的《公共信息网络安全预警指南》、《网络安全威胁表达模型》、《网络安全事件应急演练通用指南》等标准。国外的标准则包括美国国家标准与技术研究院（NIST）制订的《计算机安全事件处理指南》（NIST SP 800-61r2）、《网络空间安全事件恢复指南》（NIST SP 800-184／2016），ISO组织的《信息安全事件管理第1部分 事件管理原理》（ISO/IEC 27035-1:2016）、《信息安全事件管理第2部分 事件响应规划和准备指南》（ISO/IEC 27035-2:2016）以及《信息和通信技术事故应对行动指南》（ISO/IEC 27035-3）。不论是国内和国外的标准，针对信息安全事件响应管理都遵循了PDCA戴明环的循环处置流程，尽管不同的标准可能将其流程进一步拆解为不同的阶段或相对强调某一阶段的内容(例如NIST SP 800-61r2强调分析与检测，ISO/IEC 27035-2:2016强调报告和检测)。
- 安全观察分析
安全观察1：领导的专业性知识储备可帮助更好的增加应急响应处置的整体可控性
通常情况下绝大多数机构中CEO、CIO或CTO由于实际工作中并不直接负责IT安全，因此他们对信息安全未必都能有较为深刻的理解。其次一些机构中信息安全管理部门的负责人也可能不具备信息安全的知识和实践背景，严重的甚至连IT背景都不具备。
如果机构中这样的高管和中层负责人在日常工作中主观意愿上亦未能深入学习和了解监管的安全要求、信息安全领域的背景知识以及机构当前的信息安全状态，那该机构在信息安全管理方面将陷入一种盲从和外行领导内行的境地。该情况可能导致在发生信息安全事故时，信息安全的直接负责人无法正确的理解认知和评估判断应急处置上报信息中提及和反馈的当前正在发生和未来可能持续或新增的风险。
在这种情形下，该负责人很可能做出不正确和不恰当的处置决策。这种不正确或不恰当的战术层面判断处置决策可能进一步误导机构的CEO或董事会做出战略层面的误判，导致在第一时间没有能够投入充足的资源以及没有采取其他相关的正确措施将事故的影响和危害控制在更小的范围，同时还将造成当前风险的持续蔓延以及产生额外的新的安全风险。从另一个角度看，由于C-level层的权限更大，如果该层领导也缺乏对信息安全风险的深刻认知，那么机构将失去从战略层面纠正战术层面错误的最后一个风险控制点。有鉴于此，机构应该通过IT风险治理机制让C-level层及中层管理执行层的领导具备和提升相应的信息安全管理知识背景及管理能力，在发生信息安全事故时才能更好的借助专业性的知识储备来做出正确的分析判断和决策处置。
安全观察2：应急预案的完善度关系到响应处置的有效性和可靠性
当下绝大多数机构均已按照信息安全事件响应管理的要求编制了安全应急处置预案。但这些处置预案存在以下四个主要问题，导致发生事故时，预案无法有效的指导相应处置工作的操作执行，造成了不必要的风险损失。
- 问题一：应急预案没有做到应急操作级
一般情况下我们可以把应急预案分为应急场景级预案和和应急操作级预案。例如仅泛泛说明有病毒入侵导致业务主机宕机，业务中断，要求进行网络隔离和病毒查杀的预案属于场景级别。而详细描述通过何种具体操作恢复宕机主机、阻断网络病毒的传播、删除主机病毒、进行数据恢复的预案则属于操作级别。显而易见，应急操作级预案是应急场景级预案的细化，其落地性和可操作性更强。
很多机构的安全预案通常仅限于应急场景级别的预案，这些定义的场景例如停电、网络通信中断、网络攻击和入侵、业务中断、数据泄露、安全迎检等。未编制操作级应急预案的原因包括由于机构的网络复杂、业务系统繁多复杂、业务操作复杂以及牵涉部门人员较多等因素导致信息安全部门难以下定决心去进行预案编制。尽管存在上述客观因素，但考虑到应急处置的有效性和可靠性，建议机构仍需下决心开展操作级预案的编制和完善。
在编制过程中，可采取循序渐进的方式，首先将应急场景进行细化，将其拆分成不同的操作子场景；其次要求在某一操作子场景情况下涉及的部门进行场景适用性确认并据此进行操作级预案的编制；最后定期或不定期组织相关人员进行预案的评审和修编。相信只要持续进行该项工作，机构最终将建立完善的操作级应急预案体系。
- 问题二：应急预案没有考虑预案实施完成的自持性
不少中小机构在一些特定的预案中如网络攻击/入侵应急处置预案和数据灾备恢复预案中基本上很少考虑机构内部人员是否能够独立完成该应急处置需求。在实际应急处置的活动中，由于网络攻击入侵防控和数据恢复的复杂性，同时还可能受限于机构的编制和人员的技能，很多中小机构在发生此类安全事故时，其内部应急响应人员并不能独立应对。
因此这些机构在制定应急预案时需要评估机构本身的应急处置能力并考虑在发生事故时是否需要邀请第三方力量进行参与介入，帮助共同应对。此外机构还要考虑和评估参与介入第三方机构的匹配能力、参与介入的成本负担、参与介入的方式和方法，信息共享的范围和内容、合同及责任的约定以及因共享信息和应急介入可能发生第三方信息泄露的风险。
- 问题三：预案更新不及时
机构在运营过程中常常会面临内外部环境的变化。外部变化通常包括法律法规等监管要求的变化（如提升和加强了对应急响应处置的要求）、第三方合作机构/和人员（业务往来/运维支撑/开发外包等）发生了人事及通信联系方式变更、服务能力变更、驻地机构变更等。内部变化则主要包括内部的网络环境发生变化、业务系统发生软硬件更迭/升级、业务操作流程变更、内部人员人事及通信联系方式变更、应急处置工具不再可用等。以上内外部的变化如果没有在应急预案中得到及时更新，那么当发生事故时，将发生预案与实际情形相差甚远的情况而致使响应处置工作无法按预期顺利进行。
- 问题四：应急预案未得到实际操演
预案本身是停留在纸面上的，在没有实际演练的情况下，预案所涵盖的内容并不能得到充分的检测同时也不能发现预案内容的不足（例如未考虑到备品备件的不足，人员实际到岗的不足、人员应急处置技能的不足）。实践中由于并行测试和完全中断测试演练成本高，周期长，通常难以进行，那就需要采用其他应急演练方式并尽可能的全面。
例如在模拟测试的方式下，建议可以采取头脑风暴的方法，在预先设定的场景中尽可能全面的评估和考虑到所有的可能性，并进行一一推演和测试。当然，如果机构具备并行测试和完全中断测试的条件，建议定期采用这两种演练方式并获得最为全面和最为真实的演练效果。
安全观察3：人员因素是应急响应的关键要素之一
在信息安全事件响应处置流程中，在预防/准备阶段通过开展对内部员工的安全意识教育、安全技能培训提升以及应急演练可以极大改善应急响应处置的效果。普通员工的安全意识教育在此不再多说。
需要特别注意的是在实践中机构的IT设施运营通常由软件开发与测试、业务运维、系统运维、网络运维、桌面运维、安全运维的员工或外包服务商来完成，因此对于这几类角色的人员，一定要让他们具备较之普通员工更高的安全意识，深入了解自己负责的工作内容可能面临怎样的安全威胁，产生怎样的安全风险以及相应的应对手段。
此外应急演练的设计应覆盖以上人员，演练中让他们都能实际参与，通过桌面推演、模拟测试、并行测试、完全中断测试以及第三方参演的红蓝对抗的方式锤炼他们的应急处置能力，增加应急处置经验。随着参演人员的实际参与，机构的事件响应处置能力也将随之改善和提升。
信息安全应急响应小组是应急响应处置中的主要团队。机构管理者通常往往过于强调小组成员组成的全面性，小组成员的技能，但却忽视了人员在应急处置时所面临的精神压力。这些压力包括逃避免责压力和响应处置压力。
逃避免责压力：应急响应人员本身可能就是平时的运维人员或一线管理人员，因此一旦发生信息安全事故，从人类心理趋利避祸的情况下，有可能会采取瞒报漏报、虚报谎报的方式来尽可能降低自身可能因事后追责而需要承担的个人风险。因此，在安全管理过程中需要尽可能的避免此类情况的出现。具体可行的方式包括在相关的管理制度中明确禁止主动屏蔽正确信息的输出以及对应处罚，在明确职责的同时也尽可能阐明例外的情况以及相应的免责，同时也包括对应急处置应对得当，避免更进一步损失发生的奖励措施。
响应处置压力：在处置的过程中，由于响应时间窗口十分有限，应急处置人员面临着公司高管传递的工作压力。心理抗压能力差的员工在此种情况下可能会出现心理抵触、工作推诿、专注力和操作能力的非正常下降。因此在处置过程中，常要求处置人员具备良好的心理抗压能力和娴熟的处置应对技能。
图：工作压力和工作表现的关系曲线图[1]
一个具备良好抗压能力心理素质的人员其最佳表现峰值点与其他人相比在如上图所示的关系曲线图中将会右移。因此在平时的安全应急演练过程中一方面需要参入压力训练的内容增加和强化在这种压力环境下的抗压演练。另一方面信息安全管理经理也需要主动观察参演人员的具体表现，对未来参与应急响应的人员有正确的预判和优先预设的考虑。
安全观察4：建立“吹哨人”机制增加重大事故的快速响应能力
在常规的安全事件响应处置流程中，安全事故的发现和处置报告是遵循层层上报的机制。这个传统的流程机制本身没有错，但是如果机构存在着官僚作风以及前面提到的层级领导缺乏专业性知识储备的情况，那么该流程机制就有可能导致安全事故的响应处置窗口期被人为的拉长。
另外信息安全应急响应小组通常会被认为是纯粹的技术单元，因此在很多机构的信息安全管理体系中，信息安全响应小组的意见和报告并不能直接和完整的呈现在管理层的沟通会议上，这意味着没有一种可行的直接上报机制和通道，能将最直接的风险损失分析信息直接上传抵达更高的决策层。此种快速直通车机制的缺失或将导致身处一线的员工在一些突发且隐患巨大的情况下无法成为唤醒巨人的“吹哨人”。
因此建议机构组织可以考虑设置和开放这样的“吹哨人”上报机制和通道，允许技术层面的反馈也能在特殊情况下直接反馈于高管层，缩短应急响应处置的时间窗并降低风险损失。此外，该机制从管理层面上看还可增加一个威慑监督的作用，可以在一定程度上减少和降低执行管理人员发生瞒报虚报等不合规行为的几率。
安全观察5：不慎重的危机公关将是另一场危机
在发生信息安全事故时，机构有可能会根据情况判断而开展危机公关，消除或降低客户或公众存在的愤怒、困惑和沮丧等情绪，挽回对机构的信任，降低商业信誉遭受破坏的风险。然而在回顾既往众多的安全事件危机公关应急处置案例，我们可以发现很多处置不当的例子。综合来看，主要有以下这些问题。
- 事件上报不及时；
- 事件对外披露不及时；
- 对外披露信息不足；
- 对外披露信息可信度不足；
- 出现多个发布口径，且披露信息不一致；
- 措辞表态不恰当；
- 发言人的级别与事件危害程度和影响程度不符合；
- 发言人现场应对能力不足；
- 后续责罚措施及补偿应对措施处置不当；
- ……
这些问题的存在不仅没能达到公关本身设定的目标，反而可能导致事件影响不断发酵和蔓延，消耗和浪费了客户或公众的信任度，最终不得不付出更多的处置成本和公关成本。因此在决定进行正式对外的危机公关时，建议机构需要提前做好公关分析和演练（如果涉及现场发布会）。在公关分析的时候，内部一定要对事故信息进行梳理和信息的同步对称。包括，
- 发生事故的原因是什么；
- 哪些系统和业务受到了影响；
- 影响的程度如何；
- 是否发生客户信息泄露的情况；
- 预计泄露了多少数据信息；
- 可能造成什么影响；
- 机构内部当前的响应处置进度和情况如何，如系统漏洞是否已修补、攻击入侵是否已结束或已经得到控制、恶意代码是否已清除、系统配置是否已恢复、业务是否已恢复运行、业务数据是否已恢复、已采取了哪些安全改进措施；
- 拟对遭受损失的客户所采取的补偿措施；
- 针对本次事故对客户侧推荐的安全建议；
- 适合的信息发布时间点，发布渠道以及恰当的发言人；
- 公关后可能未达到预期效果后的备选方案设计等
参与的部门和人员建议包括IT支撑团队、市场/业务团队、法务团队、公关团队以及牵头负责的高管。此外，如果有现场信息发布会，那么建议在正式的发布会之前进行至少一次的模拟演练，确保公关发布万无一失。
- 结束语
在现实世界中，机构出了安全事故总要有人担责。因此机构中的信息安全管理者，不论是CEO还是CIO、CTO、CSO甚至是安全部门经理的职业生涯都可能因此而受到影响。
2017年9月7日美国征信巨头Equifax被披露发生大规模数据泄露事件，泄露敏感信息涉及1.43亿用户，导致公司股价暴跌30%，公司资本市值蒸发50亿美元。该公司随之在9月15日宣布其首席安全官(CSO)苏珊·马尔定，首席信息官(CIO)大卫·韦伯即刻从公司退位。同年Uber公司发生的信息泄露事故导致Uber公司首席安全官乔·沙利文和公司安全与执法法律总监克雷格·克拉克被辞退。
以上这些案例让手握高薪的CEO/CIO/CSO们有种高处不胜寒的感觉。在安全行业普遍流传着一种说法，没有不被攻破的堡垒，只是不知道什么时候发生。因此机构的信息安全管理者们需要认真看待和审视机构的安全现状，加强信息安全管理和建设。在本文所提到的安全应急处置方面建议机构加强高管层的安全意识教育、优化响应处置工作的流程和机制、不断地完善信息安全应急预案、持续地进行安全演练，以练兵千日，用兵一时的姿态去认真对待未来可能面临的安全事故和安全威胁。
参考文献
- https://examinedexistence.com/the-correlation-between-stress-and-performance/
