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

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

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

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

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

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

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

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

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

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