
没有组织想在网络安全事件发生时才被动响应,因此许多企业都已经制定了安全事件响应的策略和计划,尽量减小攻击事件造成的影响。然而,但随着网络威胁形势的不断变化,很多错误的做法可能会破坏响应计划的有效执行,并使组织的系统暴露在更多威胁的面前。以下是企业在制定网络安全事件响应计划时最常见的10个错误:
响应流程过于繁琐
在一些企业的网络安全事件响应计划中,包含了复杂的响应流程和策略,而在危急关头,安全人员往往没有最好的状态来执行复杂的响应流程,也不利于团队集中精力解决事件,反而会影响到事件处置的时间和效果。只有在网络安全攻击事件发生的危急关头,企业才需要真正启动事件响应计划,而在争分夺秒的情况下,简单直观的事件处置流程会更容易落实,还节省时间。
指挥链不清晰
网络安全事件响应计划并不会自动执行,需要由明确分工的人和团队来执行。当很多人共同应对一起事件时,企业需要按照指挥链为人员分配角色和职责。高度协同合作并让每个人都与所采取的行动保持同步是非常关键的。
很多企业组织可能已在事件响应计划中设计了所有必要的程序,但是如果统筹规划好这些步骤的执行顺序和启动条件,实际能起到的作用就会非常有限。企业应该通过明确的角色和责任来避免,提前做好安排,才能在紧急情况下迅速响应。
没有确立优先级
优先解决那些可能危及系统的问题有助于创建更安全的数字环境,但如果将响应资源浪费在那些可能的影子事件上,只会适得其反。大量实践表明,后果严重的网络安全事件必然会发生,所以组织需要能够根据事件的影响来确定响应优先级,不然就会产生事件疲劳,严重威胁发生时却无力解决。
但是事实上,很多企业在安全事件响应时,还是在随机选择优先处理的事件,并且没有建立可量化的优先级评估指标。在网络安全事件响应时,最关键的威胁数据应该得到最大程度的重视和关注,企业要根据事件与数据情报的综合分析为事件响应确定优先级。
使用通用的响应计划
目前的市场上,有很多通用型的网络安全事件响应计划,并宣称可以帮助企业节省事件响应的时间和资源投入,但事实恰恰相反。这些通用型事件响应计划对企业的帮助非常有限,有时甚至会适得其反。没有两个组织的网络系统和响应需求是完全一样的,因此最有效的事件响应计划是需要按需定制的。组织应当针对自身系统的特定情况,并围绕自身的能力优势来构建防御体系。尽管一些知名的网络安全框架(比如《NIST计算机安全事件处理指南》)提供了标准化的响应流程,但企业应该以此作为参考,根据自身独特的网络环境定制事件响应流程。
使用已过时的响应计划
企业会在一些历史的处置实践中形成思维定势,并依赖于延续这些固化的处置策略和流程。然而,很多时候安全事件的发生难以预测,固化的解决方法往往无法有效发挥作用。当企业面对网络安全危机时,运用已过时的响应策略不会有多大实际的帮助。
响应计划好比系统的支持文档。系统在不断发展变化,这需要在安全应对策略中也有所体现。拥有灵活的策略和流程可以帮助企业适应不断变化的处置需求,并在需要时找到正确、合适的解决方案。
不了解系统安全环境
企业只有充分了解目前信息系统的安全环境(包括使用的应用软件、开放端口和第三方服务等),才能根据系统的真实状态,定制合适的事件响应计划,不然既不知道哪里出了问题,也不知道该如何解决问题。
这种了解需要基于全面的系统运行态势观察和监控,可以通过安装先进的网络监控工具来实现。这类工具可以提供有关企业网络平台上的安全漏洞、异常行为风险和运营活动等实时数据信息。
缺乏度量指标
网络安全事件响应是一项持续性工作。为了改善响应计划的效果,企业组织必须不断衡量自身的安全态势表现。确定具体指标可以为衡量相应计划的有效性提供一个参考标准。以事件响应时间为例。响应威胁的速度越快,恢复数据的效果就越好。只有长期跟踪响应时间,并努力做得更好,才能不断改善相应计划中的这个指标。
无效的可执行文档
当重大安全事件发生后的一个常见问题是,安全团队知道他们的责任是什么,但不确定如何履行这些责任。编写安全事件响应执行文档可以为安全团队提供具体的行动指导,已经成为保证安全事件响应计划有效落地的标准操作程序(SOP)。但实际的问题是:响应计划的各种细则是否有效地记入了文档?文档内容是否清晰全面?
事件响应文档对于有效执行安全事件响应计划至关重要。该文档应该让每一个参与安全事件响应的成员都易于访问,并且可以在事件响应混乱期提供指导。编写文档切勿模棱两可,避免使用技术术语。用尽量简单的话把每一步都讲清楚,以便任何人都能践行。
孤立的安全事件报告
随着数字化转型的深入,企业中部署的应用系统和安全工具也在随之激增,这也为企业安全分析师带来了更多工作负担,他们必须分散精力处理更多的监控、关联以及警报响应工作。虽然这些系统都是独立工作,但其运行中的问题都会影响到组织的整体运作态势。如果网络安全响应计划没有全面考虑到来自所有系统的数据,就会缺乏完整性。企业应该充分利用先进自动化工具,全面收集各类系统上的所有数据,并将它们存储在易于访问和检索的地方,这样才能兼顾各个方面的安全风险,确保没有漏网之鱼。
没有做好备份
将关键业务系统和数据进行备份是防止严重网络攻击后果的主动安全措施,但即使组织已经使用了可靠的备份工具或服务,它也可能会在网络攻击中受到影响。企业不能等到攻击发生时才发现备份机制已经失效,这样将会非常的被动。企业应该在安全可控的环境下测试备份机制的有效性和健壮性,可以采用道德黑客攻击方法,针对保存敏感数据的系统发动攻击。

日本 1F
指挥链不清晰这点我们公司吃过亏,去年搞演习时乱成一团
日本 2F
用通用模板真是坑,之前照着抄结果完全不适用我们系统
广东省广州市 3F
备份机制失效太真实了,上个月中勒索病毒才发现备份早坏了
澳大利亚 4F
优先级这块有量化指标吗?还是全靠经验判断?
江苏省无锡市 5F
流程搞太复杂根本没法用,紧急时候谁记得住十几步操作
澳大利亚 6F
文档写得太技术化确实问题大,新人来了根本看不懂
山东省青岛市 7F
系统环境不了解就做预案简直是纸上谈兵🤔
泰国 8F
感觉响应时间指标挺关键的,但很多公司都不重视这个
澳大利亚 9F
这些错误我们踩过七八个,现在还在慢慢改
中国 10F
自动化工具整合数据这块有推荐方案吗?
上海市 B1
@ 无影神掌 自动化工具这块,SIEM平台算是一个基础吧,但定制化挺麻烦的。
浙江省 11F
流程搞太复杂真的不行,我们上次应急演练就因为步骤太多卡住了。
湖北省武汉市 B1
@ 虚空之眼 说得太对了,我们公司文档一堆术语,新同事看了直摇头。
山东省济南市 12F
指挥链不清晰太要命了,一出事都不知道该听谁的。
广东省肇庆市 13F
通用计划害死人,我们之前图省事用的模板,结果跟自家系统完全对不上。
北京市 14F
优先级评估我们是用CVSS评分结合业务影响自己搞的,还算有点用。
浙江省台州市 15F
文档写得太技术,新人来了直接懵,得改得大白话才行。
北京市 16F
系统环境摸不透,做计划就是瞎搞,我们花了小半年才把资产理清楚。
广东省深圳市 17F
备份不测试等于没备份,血的教训。
日本 18F
感觉好多公司都这样,计划做完了就扔那吃灰,从来不更新。
澳大利亚 19F
这些点总结得挺全,我们正在搞第三轮修订。
韩国 20F
备份测试确实太容易忽略,等出事就晚了。
广东省广州市 21F
这些坑我们基本都踩过,现在还在填坑的路上。
韩国 22F
自动化工具这块有啥好用的推荐不?
重庆市 23F
优先级评估我们用的是业务影响矩阵,感觉比纯经验靠谱点。
上海市 24F
流程复杂真是硬伤,紧急情况下根本记不住那么多步骤。
海南省海口市 25F
指挥链混乱的话,再好的计划也白搭。
新西兰 26F
感觉很多公司都把计划当摆设,从来不更新。
泰国 27F
系统资产梳理太重要了,不然预案就是空中楼阁。
日本 28F
文档写得简单易懂才是王道,技术术语少用点。
印度 29F
响应时间指标确实该重视,不然没法衡量效果。
北京市 30F
通用模板省事是省事,但真用起来全是问题。
广东省佛山市顺德区 31F
优先级这块有没有现成的框架可以参考啊?
北京市 32F
备份不测试跟没有一样,我们吃过这个亏。
浙江省温州市 33F
指挥链混乱最要命,出事了互相推诿。
宁夏银川市 B1
@ 尬场救星 指挥链一乱,团队协作就崩了。
上海市 34F
响应文档写得不清不楚,执行起来更乱。
日本 B1
@ 量子漫步 文档写得好,执行才不乱。