SCADA系统该如何解决脆弱性泄露问题?

SCADA系统该如何解决脆弱性泄露问题?,第1张

脆弱性泄露具有多种性质,在信息安全领域中历史悠久。虽然安全专业人员有时支持以缓和形式管理脆弱性泄露,SCADA系统更多相关结论的出现,使得许多安全专业人员重新对他们的观点进行思考。利用熟练的技术风险管理方法以及对风险模型的更为细致的观察,有助于在这个方面上更加清晰的思考。

理解泄密对IT风险所产生的影响的关键是承认威胁和脆弱性之间的相互作用。容易陷入仅考虑受影响脆弱性程度的陷阱。当研究人员公开脆弱性时,通常是为了更加安全的软件。实际上,脆弱性级别不受初期揭露的影响;无论我们是否知道脆弱性级别,当脆弱性进入环境时,级别发生变化(由于攻击者)。揭露的目的是识别脆弱性,并消弱脆弱性–通常通过路径–因此降低了脆弱性级别。

但是一个系统的修补是一个非常危险且耗时的过程。如同所有系统变化一样,进入生产前,必须对补丁进行彻底评估和测试。即便如此,补丁仍可能失败。因此必须对补丁过程相关成本和避免损害所获得利益进行对比。以前我们知道极少脆弱性曾经被实际解决,利用SCADA系统,我们现在可以处理高度敏感的系统,一般长时间不发生变化,实际应用补丁的可能性相当低。更重要的是,因为在种情况中无可可用的补丁,必须采用其它机制。最终,脆弱性程度不可能被影响数月。

威胁受揭露细节影响严重,似乎不直观。因为聪明人自有其成本利益的分析,任何使其成本降低的举措将增加其利益。提供的信息越多,例如武器化的攻击代码,成本越低。利用SCADA系统,攻击者知识库仍然相对较小,因此whitehats专家帮助大大帮助了该坏人。

许多研究人员(但不是全部)寻找脆弱点,试图降低风险。然而,他们忽略了威胁部分。这意味着,为了降低风险,脆弱性级别降低必须大于威胁程度的增加。虽然大多数脆弱性从来未被利用,过去的众多例子表明在揭露后发生的事故更多。既然已经掌握了SCADA的情况,不可能通过降低脆弱性级别以弥补威胁的增加,因此发生更多的事故。

研究人员提到其成功时,通常突出他们认为变得更安全的软件应用–通常这是微软喜欢的方式。这恰恰是他们不了解脆弱点以及理解威胁重要的很好的例子。虽然这些应用程序实际变得更加安全,实际上与事故降低无关紧要。这突出了两件事-第一,在所包含环境中起作用的事情比一定在整体中起作用-这也是为何QA部门仍然有意义的原因。第二,这种整体运行是不起作用的。

第二件事简直是不起作用的。在面对这些“更安全”方案时,风险如何改变?有没有人说明风险实在正在下降?问题是在世界代码库中(或者当今大型数据中心)太多软件试图利用现代技术查找每一个缺陷。不仅如此,差距正在扩大–这就像一个较差的数学数字问题-软件开发正在前面以50mph速度前进,脆弱性研究以5mph速度在相同方向移动,何时能够追上?

由于我们不可能找到所有脆弱性,通常也不可能找到“正确的”脆弱性,因此我们需要利用更好的且更有效的方式保护我们自己。虽然对脆弱性的“正面攻击”不起作用,但是还有其它方式处理这些问题。首先,我们可以在架构中涉及更好的控制方法。类似微软蓝帽奖的举措更有可能引起安全突破。第二,我们可以更加努力地进行威胁监测。虽然有另一个问题,但是已经显现成功,而且正在转好。这只是开始。

SCADA系统是个严肃的行业,其中可能威胁人的生命。Stuxnet是缺陷寻找不起作用的很好的例子-我们丢失了那些价值-以及替换技术的承诺-我们才发现违反规律并返回。为突出某问题的严重性,使其恶化毫无意义。让安全研究人员-在我们领域内最优秀的人才-开始以不同方式思考该问题。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/dianzi/2644139.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-08-12
下一篇 2022-08-12

发表评论

登录后才能评论

评论列表(0条)

保存