本文，我们来探讨一下用打补丁的方法为SCADA 和 ICS系统提供安全保障的好处、弊端及其不为人知的内幕。首先，我们假设不需要关闭进程也可以安装补丁(比如说，为冗余控制器分阶段打补丁)……
“你可能要面临风险了，我的朋友……”图片来源：pictureshowpundits.com
为SCADA 和 ICS安全而打补丁的影响
在一篇针对OS软件发布后公开披露的漏洞补丁的重要研究中，Yin等指出所有补丁中有14.8%到24.4%是错误的并会直接危害到最终用户。更糟糕的情况是，这些错误的“解决方案”中有43%会导致系统崩溃，瘫痪，资料损坏或其他安全问题。
此外，补丁并不总能依照其所设计的那样解决对应的安全问题。如工业控制系统-计算机应急响应小组(ICS-CERT)成员Kevin Hemsley所言，在2011年ICS-CERT发现，通过打补丁来修复发布的控制系统产品漏洞出现了60%的失败率。
即使是好的信息安全补丁也可能引起问题
大多数的补丁需要关闭或重启正在运行的操作。有些可能也会中断或解除掉之前依靠控制系统运行的功能。例如，Stuxnet蠕虫病毒攻击的其中一个漏洞是西门子 WinCC 系统SQL 数据库的硬编码密码。
与此同时，西门子也因未能及时发布解除密码的补丁而广受指责。而那些通过自己人为修改密码的客户则很快就会发现，许多关键的控制功能都需要这个密码才能进入。在这种情况下，所用的“解决方案”要比原来的“疾病”后果更加严重。
打补丁通常需要专家在场
关于打补丁还需要警惕的一点是打补丁的过程需要那些有专门技能的人在场。
举例来说，2003年1月Slammer病毒攻击的漏洞其实原本有一个在2002年发布的补丁(MS02-039)。不幸的是，这并没有帮助一家在墨西哥海湾拥有大量采油平台的公司逃过一劫。这家公司在2002年夏天开始打了补丁运行，但服务器还是重新出现了问题，需要windows专家在场打补丁。由于这些专家中只有极少人具有进入采油平台的安全认证，因而在六个月后受到Slammer病毒攻击时还有许多平台尚未打补丁。
若没有补丁会怎样
当然，你只有在供应商提供补丁时才能使用补丁修复漏洞。但不幸的是，并非所有漏洞都有对应的补丁。在2012年1月的SCADA信息安全技术研讨会(S4)上，Sean McBride表示在ICS-CERT记录的364个公开漏洞中只有不到一半在当时有可用补丁。
有些人指责供应商无动于衷和懒惰，但其实有很多因素阻碍了补丁的及时发布。
2010年，ICS的一家重要供应商告诉我在产品的关键任务内部测试中已经发现了安全隐患。但不幸的是，这些漏洞是嵌入在由第三方提供的OS软件中。现在OS提供商拒绝解决这些漏洞问题，因此ICS供应商(及其客户)就将面临无可用补丁的情况。
2011年的案例涉及另一家ICS供应商， 一名独立的信息安全研究人员发现了PLC中的漏洞，并公开披露了他们。该供应商开发了补丁准备撤除这些后门)，但随即他们发现这些后门被那些为用户提供检修服务的团队所广泛使用。而让这个问题更加棘手的是，这家公司产品变更的质量保证(QA)程序需要4个月才能完成。这意味着即使用户愿意为信息安全而放弃检修服务，他们仍需要接受四个月开放的空窗期等待正规的补丁测试流程结束。
当用打补丁解决SCADA和ICS系统信息安全时，“解药”可能会比疾病本身后果更严重
许多SCADA/ICS使用者选择不打补丁
我的上一个例子突出了为保障关键系统安全而打补丁一个重要问题。那就是许多用户不想承担降低服务质量和增加停机故障的风险。而上上个例子提到的供应商私底下向我反映他们发布的漏洞只有10%的下载率。
我自己关于ICS安全产品的经验也证实了补丁在这个领域的接受程度较低。
按计划发布的补丁是有效补丁，应对性的补丁是无效补丁，紧急发布的补丁是危险补丁
我们明确一点，对任何控制系统而言，修补漏洞都是一项重要的进程。 而且对良好的信息安全而言修补漏洞很关键。但是从IT应对策略角度来说，每个月或每个周不间断地打补丁对SCADA和ICS系统来说并不可行。匆忙地打补丁更加危险。
SCADA/ICS供应商在尝试开发“紧急”补丁时会面临多个问题——他们需要考虑安全因素和质保(QA)要求，这通常会延迟补丁的发布。还在有些情况下，一个合理且安全的补丁也不起作用。
SCADA/ICS的用户有类似的顾虑。而且很坦白地讲，谁能因为他们不想增加系统故障或不想让他们的关键控制器或服务器系统面临安全威胁而责怪他们呢?
对合法产品的补丁支持也有问题——许多人希望一个控制产品能够运行20年，把它运行的比典型的IT支持窗口还好。最后，正如我们在Slammer病毒攻击例子中提到的，打补丁可能需要重要的人员帮助才能做到安全安装。
所以开始制定一个对你的运行环境有效的补丁计划吧。确保它包含恰当检测和变更管理控制的流程。
不要指望补丁能够迅速解决你的控制系统安全问题。如果你的确是这样想的，你会发现新出现的问题将比修补的漏洞更糟糕。
其实，我一点儿也不反对打补丁的。实际上，我认为应用补丁是一个完整的安全系统的关键部分。据US-CERT(美国计算机应急响应小组)统计，大约95%的网络入侵可以通过为系统更新适当的补丁来避免。而如果你从来不打补丁，你将让你的系统完全暴露在几十年的恶意软件前。
我所反对的是将打补丁当成一个对安全漏洞不由自主的迅速反应 。你认为你若无法控制打补丁的过程，便无法期望控制系统可靠地运行。
引用陶氏化学的Richard Brown(市场开发部副总监——译者注)所言：
“补丁管理就是对变动的风险管理”。
补丁是对你的系统的改变。而对系统的这些改变都需要管理。一个人不能盲目地对进程控制环境配置新的补丁而不面临操作紊乱的风险。因此就需要精心的用政策措施和实践经验来平衡我们对系统的可靠性和安全性两方面的需求。
一个成功的补丁策略可以平衡系统可靠性与安全性。
优先化你的安全补丁
在补丁管理方面有很多推荐措施，其中我个人比较看好的一个来自于爱迪生电器协会(EEI)。他们的建议是按优先次序为机器更新补丁程序。而优先次序的判断基于两个因素：被修补的系统的危急程度和补丁本身的危急程度。
爱迪生电器协会(EEI)的程序需要启动两个子系统。第一个子系统包含一个列示了所有优先化机器的详单，并分组界定了他们打补丁的时间和方法。
有些机器属于“及早采纳型”，他们一有可用的补丁就安装，就好像他们是测试机或是有质量保证的机器。通常而言，都是针对实验或培训用的计算机。“关键业务型”机器就是那种在及早采纳型机器稳定操作一段时间后会自动打补丁(根据补丁的危急程度)，并且认可那些从控制系统供应商处获得的补丁的机器。这种机器后来升级成为“禁止接触型”机器，这类机器使用时就需要在应用补丁之前人工干预并且/或者详细咨询供应商。
下图是Astra-Zeneca(A-Z)制药公司的一个例子，显示了他们系统的补丁循环。
Astra-Zeneca 图解，取自“SCADA和ICS补丁：在进退维谷之境”的演讲
来源：Joakim Moby, Astra-Zeneca，2006年工业标准年会博览会
第二个子系统是记录了新发布的补丁及其对进程操作的重要性水平的程序。当公布一个新漏洞和/或者一个可用的补丁方案，此程序就可以追踪记录它的潜在影响——对公司的控制系统是好还是坏。然后该补丁就会被评估，其风险评估的结果将被用于确定补丁被采纳的优先级。
例如，风险评估可以追踪一系列问题的处理进程以判定补丁的紧迫性和需要进行测试的级别。这些问题可能包括以下关注点，如“补丁还处于研发期吗?”或者“供应商所指定的安全级别是什么?”或者“它是否受到过供应商的测试?”
此风险评估可以确定整个的补丁实施层次。做这个评估的重要指导可以从供应商网站处获得，如霍尼韦尔的微软安全修补资格矩阵(需要登录许可才能访问)，它就报告了新近发布的补丁的测试状态。
执行补丁应对计划
补丁实施层次是预先与应对计划绑定在一起的。下面的表格列举了几种不同的应对计划。这些计划是依照不使用补丁的风险高低而区分的。
比如，如果一个给定的补丁所针对的漏洞风险低，那么其采纳和测试循环的工作都可以暂缓。若风险高，那么该补丁就需要尽快配置。若需要比下面列示的三种更多(更少)的应对计划，也可按需创建。
任何补丁计划的制定都需要与所有软件和系统供应商的密切合作。许多供应商已经有一个系统，用于优先化补丁并批准其应用程序与内部补丁管理系统绑定。如前所述，霍尼韦尔有一个补丁批准程序，用于在微软补丁发布的5天内为他们的新版软件批准可用补丁——且对这些重要补丁的批准通常几小时内就可完成。
为系统打补丁的计划一经决定，用安全的手段分置补丁就非常关键。直接从业务系统分置不是一个好办法。如霍尼韦尔安全指南所述：
“直接从业务系统将微软修补程序、补丁和病毒定义文件更新分置到过程控制网络的节点不是最优的操作办法，因为它与‘最小化这些网络节点间的直接通讯’的目标相悖。”
大多数供应商建议在控制系统和IT网络间的缓冲区(DMZ)安置一个专用的补丁管理器和反病毒服务器。这样单一服务器便可一身多职了。
最后，有许多自动操作的工具和服务能够帮助公司完成补丁管理的工作。通常包括清点计算机，识别相关补丁和工作区，测试补丁，以及向各级管理层报告网络状态信息等功能。
用这种类型的工具可以极大地提高配置关键补丁时的响应时间，同时减少负责过程控制和安全防护的员工的工作量。比如，一家食品加工类的大公司报道称一旦公司配置了一个补丁管理工具，那么只一名员工就可以成功地在超过6家大公司网站管理所有的PCN补丁工作。
计划性地打补丁是正确的，应对性地打补丁是错误的
别误解我的意思，我不是说不要打补丁!恰恰相反——给漏洞打补丁对良好的安全性非常重要。然而，正如我在上一篇博客提到的，像IT策略那样定期迅速地、应对性地、不间断地打补丁并不适用于SCADA和ICS系统。
若要一个补丁策略成功，必须要适当的计划，并配合以测试和改变管理控制工具。如果没有这些程序做保障，你将使控制系统处于高风险当中。
