4.9 网络安全事件管理实务
网络安全事件响应机制是CSO需要掌握的重要内容,要使网络安全响应机制有效运转,除了上述建立过程,还需要关注下述实操过程中的实务问题。
4.9.1 避免外行领导内行
通常情况下,由于绝大多数公司高层在实际工作中并不直接负责网络安全,因此他们对网络安全未必都能有较为深刻的理解,对网络安全事件响应程序和作用也就缺乏认识。CSO切忌避免在网络安全危机来临之时,临时让公司高层进行决策,这种主观上的临时决策往往会给网络安全事件的处置带来新增风险。
因此,基于完善的网络安全事件响应机制,CSO必须给予公司高层“傻瓜式”的决策,即启动预案是“是”还是“否”。至于预案启动的后续所有操作,理论上不应由公司高层干预,应按照既定的流程执行。如果执行过程中遇到问题,则需要根据现场情况由专业人员设计具体执行方案后,再由公司高层决策“是”或“否”。
鉴于此,CSO在平时也有必要开展一些活动,以提升高层领导相应的网络安全事件处置知识及网络安全背景及管理能力,这样在发生网络安全事故时才能更好地借助专业性知识储备来做出正确的分析判断和决策处置。
4.9.2 事件响应指南的常见问题
当下绝大多数机构均已按照网络安全事件响应管理的要求编制了安全事件响应指南,但是如果这些处置指南存在以下四个主要问题,将会导致发生事故时无法有效指导相应处置工作的执行,造成不必要的风险损失。
(1)事件响应指南没有做到操作级
一般情况下我们可以把事件响应指南分为场景级指南和应急操作级预案。例如仅泛泛说明有病毒入侵导致业务主机宕机、业务中断,要求进行网络隔离和病毒查杀的预案属于场景级别。而详细描述通过何种具体操作恢复宕机主机、阻断网络病毒的传播、删除主机病毒、进行数据恢复的预案则属于应急操作级别。显而易见,应急操作级预案是场景级指南的细化,其落地性和可操作性更强。
很多机构的响应指南通常仅限于场景级别,这些定义的场景如停电、网络通信中断、网络攻击和入侵、业务中断、数据泄露、安全临检等。未编制应急操作级预案的原因包括机构的网络复杂、业务系统繁多复杂、业务操作复杂以及牵涉部门人员较多等因素,这些因素导致网络安全部门难以下定决心进行预案编制。尽管存在上述客观因素,但考虑到事件处置的有效性和可靠性,建议机构下决心编制和完善应急操作级预案。
在编制过程中可采取循序渐进的方式,首先将场景进行细化,将其拆分成不同的操作子场景;其次要求在某一操作子场景情况下涉及的部门进行场景适用性确认,并据此进行应急操作级预案的编制;最后定期或不定期组织相关人员进行预案的评审和修编。相信只要持续进行该项工作,机构最终将建立完善的应急操作级预案体系。
(2)事件响应指南没有考虑实施完成的自持性
不少中小机构在一些特定的指南,如网络攻击、入侵事件响应指南和数据灾备恢复指南中基本上很少考虑机构内部人员是否能够独立完成该处置操作的需求。在实际事件处置的活动中,由于网络攻击、入侵防控和数据恢复的复杂性,同时还可能受限于机构的编制和人员的技能,很多中小机构在发生此类安全事故时,其内部事件响应人员并不能独立应对。
因此这些机构在制定响应指南时需要评估机构本身的事件处置能力,并考虑在发生事故时是否需要邀请第三方力量参与,帮助共同应对。此外机构还要考虑和评估参与的第三方机构的匹配能力、介入的成本负担、介入的方式和方法、信息共享的范围和内容、合同及责任的约定,以及因共享信息和介入后可能发生第三方信息泄露的风险。
(3)事件响应指南更新不及时
机构在运营过程中常常会面临内外部环境的变化。外部变化通常包括法律法规等监管要求的变化(如提升和加强了对事件响应处置的要求)、第三方合作机构和人员(业务往来/运维支撑/开发外包等)发生了人事及通信联系方式变更、服务能力变更、驻地机构变更等。内部变化则主要包括内部的网络环境发生变化、业务系统发生软硬件更迭/升级、业务操作流程变更、内部人员人事及通信联系方式变更、事件处置工具不再可用等。以上内外部的变化如果没有在事件应急响应指南中得到及时更新,那么当发生事故时,将发生指南与实际情形相差甚远的情况,而致使相应处置工作无法按预期顺利进行。
(4)事件响应指南未得到实际操演
响应指南本身是停留在纸面上的,在没有实际操作的情况下,指南所涵盖的内容并不能得到充分的检测,同时也不能发现其中内容的不足(如未考虑到备品备件的不足、人员实际到岗的不足、人员事件处置技能的不足等)。在实践中,由于并行测试和完全中断测试演练成本高、周期长,通常难以进行,可以参考应急预案的演练模式对事件响应指南进行操演。
例如在模拟测试的方式下,建议采取头脑风暴的方法,在预先设定的场景中尽可能全面地评估和考虑所有的可能性,并进行一一推演和测试。当然,如果机构具备并行测试和完全中断测试的条件,建议定期采用这两种演练方式并获得最为全面和最为真实的演练效果。
4.9.3 人员因素是事件响应的关键要素之一
在网络安全事件响应处置流程中,在预防/准备阶段通过开展对内部员工的安全意识教育、安全技能培训提升以及演练可以极大改善事件响应处置的效果。普通员工的安全意识教育在此不再多说。
需要特别注意的是,在实践中,机构的IT设施运营通常由软件开发与测试、业务运维、系统运维、网络运维、桌面运维、安全运维的员工或外包服务商来完成,因此对于这几类角色的人员,一定要让他们具备较之普通员工更高的安全意识,深入了解自己负责的工作内容可能面临怎样的安全威胁、产生怎样的安全风险以及相应的应对手段。
此外,演练也应覆盖以上人员,通过桌面推演、模拟测试、并行测试、完全中断测试以及第三方参演的红蓝对抗的方式锤炼他们的事件处置能力,增加他们的事件处置经验,机构的事件响应处置能力也将随之改善和提升。
网络安全事件响应小组是事件响应处置中的主要团队。机构管理者通常过于强调小组成员组成的全面性、小组成员的技能,却忽视了人员在事件处置时所面临的精神压力。这些压力包括逃避免责压力和响应处置压力。
逃避免责压力即网络安全事件响应人员本身可能就是平时的运维人员或一线管理人员,因此一旦发生网络安全事故,根据人类心理容易趋利避祸,有可能会采取瞒报漏报、虚报谎报的方式来尽可能降低自身可能因事后追责而需要承担的个人风险。
因此,在安全管理过程中需要尽可能地避免此类情况的出现。具体可行的方式包括在相关管理制度中明确禁止主动屏蔽正确信息的输出以及对应处罚,在明确职责的同时也尽可能阐明例外的情况以及相应的免责,同时也包括对应急处置应对得当,避免更进一步损失发生的奖励措施。
响应处置压力即在处置的过程中,由于响应时间窗口十分有限,事件处置人员面临的公司高管传递的工作压力。心理抗压能力差的员工在此种情况下可能会出现心理抵触、工作推诿、专注力和操作能力的非正常下降。因此在处置过程中,应要求处置人员具备良好的心理抗压能力和娴熟的处置应对技能。
在平时的安全事件响应处置演练过程中,CSO一方面需要加入压力训练的内容,以增加和强化在这种压力环境下的抗压演练;另一方面也需要主动观察参演人员的具体表现,对未来参与事件响应的人员有正确的预判和优先预设的考虑。
4.9.4 建立“吹哨人”机制
在常规的安全事件响应处置流程中,安全事故的发现和处置报告应遵循层层上报的机制。这个传统的流程机制本身没有错,但是如果机构存在官僚作风,以及前面提到的层级领导缺乏专业性知识储备的情况,那么该流程机制就有可能导致安全事故响应处置窗口期被人为的拉长。
另外网络安全应急响应小组通常被认为是纯粹的技术单元,因此在很多机构的网络安全管理体系中,网络安全响应小组的意见和报告并不能直接和完整地呈现在管理层的沟通会议上,这意味着,没有一种可行的直接上报机制和通道能将最直接的风险损失分析信息上传抵达更高决策层。此种快速直通车机制的缺失或将导致身处一线的员工在一些突发且隐患巨大的情况下无法成为唤醒巨人的“吹哨人”。
因此建议机构组织可以考虑设置和开放这样的“吹哨人”上报机制和通道,允许技术层面的反馈也能在特殊情况下直接反馈于高管层,缩短网络安全事件响应处置的时间窗,并降低风险损失。此外,该机制从管理层面上看还可增加一个威慑监督的作用,在一定程度上减少和降低执行管理人员发生瞒报、虚报等不合规行为的概率。
4.9.5 合理的汇报升级机制
网络安全事件处置的要点在于对于不同等级的网络安全事件,应由相应等级的网络安全事件处置责任人员来负责处置,这样可以避免由于负责人权限或资源不足导致的事件无法被及时解决,影响面扩大。
在实际操作中,很多技术负责人往往执着于网络安全事件中的具体故障或问题处理,在问题处理限于窘境的时候,不知道应该交出自己的负责权,让权利更大的上级介入并进行更大范围的总体干预和协调。陷于具体问题处置的后果往往就是网络安全事件响应处置周期的失控。
要解决这样的问题,在网络安全事件响应机制中应严格规定和执行网络安全事件的逐级汇报机制。如事件发生30分钟内,汇报给安全主管,由安全主管负责事件处置;安全主管接到汇报30分钟后如无法解决,则汇报给CSO,由CSO负责事件处置;CSO在接到汇报后60分钟内无法解决事件,则汇报给CEO,由CEO负责进一步处置,以此类推。通过这样的逐级汇报机制,让更多的资源逐步进入网络安全事件处置的流程中。
另外要注意的是,汇报机制不仅要包括机构内部人员,还需要考虑机构外部人员的介入,包括行业主管单位、监管机构、执法机构等。因为有些企业的网络安全事件影响范围扩大到一定程度后,可能不仅影响企业自身的业务开展,还会影响社会稳定或国家安全。
4.9.6 不慎重的危机公关将是另一场危机
在发生网络安全事故时,机构有可能会根据情况开展危机公关,消除或降低客户或公众存在的愤怒、困惑和沮丧等情绪,挽回公众对机构的信任,降低企业商业信誉遭受破坏的风险。然而回顾既往众多的安全事件危机公关处置示例,我们可以发现很多处置不当的例子。综合来看,主要有以下这些问题。
- 事件上报不及时。
- 事件对外披露不及时。
- 对外披露信息不足。
- 对外披露信息可信度不足。
- 出现多个发布口径,且披露信息不一致。
- 措辞表态不恰当。
- 发言人的级别与事件危害程度和影响程度不符合。
- 发言人现场应对能力不足。
- 后续责罚措施及补偿应对措施处置不当。
……
这些问题的存在不仅无法达到公关本身设定的目标,而且可能导致事件影响不断发酵和蔓延,消耗和浪费了客户或公众的信任度,最终不得不付出更多的处置成本和公关成本。因此在决定进行正式对外的危机公关时,建议机构提前做好公关分析和演练(如果涉及现场发布会的话)。在公关分析的时候,内部一定要对事故信息进行梳理,使得信息同步对称。梳理的内容包括:
- 发生事故的原因是什么?
- 哪些系统和业务受到了影响?
- 影响的程度如何?
- 是否发生客户信息泄露的情况?
- 预计泄露了多少数据信息?
- 可能造成什么影响?
- 机构内部当前的响应处置进度和情况如何?比如系统漏洞是否已修补、攻击入侵是否已结束或已经得到控制、恶意代码是否已清除、系统配置是否已恢复、业务是否已恢复运行、业务数据是否已恢复、已采取了哪些安全改进措施等。
- 拟对遭受损失的客户所采取的补偿措施。
- 针对本次事故对客户侧推荐的安全建议。
- 适合的信息发布时间点、发布渠道以及恰当的发言人。
- 公关后可能未达到预期效果后的备选方案设计等。
参与的部门和人员建议包括IT支撑团队、市场/业务团队、法务团队、公关团队以及牵头负责的高管。此外,如果有现场信息发布会,那么建议在正式的发布会之前进行至少一次的模拟演练,确保公关发布万无一失。
4.9.7 重视网络安全事件的回顾工作
在网络安全事件关闭后,要重视网络安全事件的回顾工作。回顾工作的目的是防止类似的网络安全事件在未来再次发生,因此,在回顾过程中重点要对导致该网络安全事件的核心原因进行深入分析,找到根源问题并进行改进。同时,在回顾的过程中还应设立奖惩机制,对安全事件处置过程中各负责人的工作表现进行评价、表彰或惩处,这样可以引导员工向组织期望的方向发展,有助于未来网络安全工作的开展。