Cloud & Telecom Security

这篇文章写于2004-2-23发表在中国计算机报。讨论了安全补丁的管理成本、打补丁的时机以及建立补丁管理系统的建议。

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

进入到当前的互联网年代，几乎每天都有新的软件缺陷、漏洞被发现，同时伴随着相应的补丁或者临时解决办法。软件的缺陷或漏洞随时都可能会造成系统崩溃或者入侵。但是大量的漏洞和补丁安装需要占用大量的资源，或许还需要系统重起，降低运行服务方面的数字，另外仓促推出的补丁也未必就是安全的，或许还会引入稳定性、性能方面的隐患。两者相权，如何取舍？不管怎样，补丁和漏洞管理不仅仅是安全管理员的事情，而已经成为整个IT部门运行的关注焦点。本文希望和大家讨论并共享在补丁以及漏洞管理方面的若干思路和经验教训。

数字与难题

先来看一组数字。根据Meta Group的报道，2002年总共发表了4192个漏洞，同时按照一个实际的统计，系统管理员总工花费了1920个工时，来将4个补丁全部打到120台服务器上，即在一个服务器上面打一个补丁的时间大概为4小时，包括备份安装测试等环节。假设系统管理员有很好的技能训练，可以在20分钟内阅读研究完一个漏洞及其补丁（解决方案），那么4192个漏洞总工需要172个人天，再假设其中只有10％的漏洞适用于自己的网络环境，这样413个漏洞，每个相应的补丁布署在10台服务器上，这样共需要2065个人天（即同样配置的服务器数量为10个左右）。我们可以看到，这两个人天数字加在一起，差不多是10个全职的安全管理员，这里还没有考虑对厂家发表的补丁进行的测试和验证过程，也没有考虑打补丁失败造成的二次资源消耗。可以看到，补丁和漏洞的管理已经成为一个很大的资源漏斗，占用大量的系统管理员资源。

管理者对这些系统和安全隐患不能视而不见，但是，这样巨大的资源消耗也承受不起，必须找到更加有效的解决途径，这些解决途径包括以下措施：
? 引入知识共享或者外部知识库（专业服务），减少漏洞和补丁学习过程消耗
? 建立有效的补丁管理流程和备份回卷计划
? 引入自动化的补丁和漏洞管理工具，加速布署过程

打还是不打？
考虑到上面的数字，我们看到，“补丁”绝对不是免费的，而是很昂贵的。这个成本中包括收集、了解、测试、布署、备份恢复，以及风险成本。但是，“不打”的成本是数据失密、丢失、窜改、拒绝服务、系统恢复，以及其它无形损失等。简而化之，下面的成本不等式成立的时候，就是可以“打补丁”的时机：

布署成本＋补丁失败概率×失败成本 <= 攻击入侵概率 × 攻击入侵成本

通常使用三个数字来描述一个漏洞的安全风险特性：I(影响度，即攻击入侵成本)、P(流行度，即多大范围内传播了该漏洞)、S(简易度，即利用该漏洞的难易)。后两者的乘积（P×S）大约可以反映该漏洞导致攻击入侵的概率。这样，不等式的右边I×P×S代表的是该漏洞对应的“不打补丁”成本，本质上反映的是补丁管理决定的防御强度（是否可以承受），参照下面的示意图。

图：从风险管理角度看补丁管理
在曲线的最高点，按照100％安全的要求，即使是IPS乘积为0的补丁（即风险极小）也必须完全布署。这时的代价极高，通常不符合安全风险管理的投资回报原则。

从上面的不等式，我们可以看出，左面的布署成本和补丁失败成本决定了“合算”的IPS强度。如果我们将布署成本降下来，通过测试将补丁失败的几率降下来，则可以在保证投资回报的前提下，将补丁引起的损失和成本降到最低，就可以提高IPS决定的防御强度。

早打还是晚打？
通常认为，对于发现的漏洞和补丁应该尽快安装布署。但是，按照美国USENIX组织发表的一个针对CVE漏洞和补丁的研究数字，大概有18％左右的补丁后来进行了重新发布，即出现了补丁的补丁，也即意味着在第一时间安装上的补丁，有18％的可能会带来新的缺陷或安全漏洞。随着时间的推移，补丁本身的安全性和稳定性会上升，由此造成的损失风险相应降低。

参加下图，我们必须在早打带来的补丁失败风险与晚打带来的入侵攻击风险之间进行平衡，选择较好的时机。从对实际CVE漏洞和补丁的研究来看，新发表的“补丁”大概需要2周到4周左右的时间稳定下来，换句话说，在“补丁”发表后两周，考虑尽快布署可能是较为稳妥的时间。如果不满足这样的时间延迟，则需要自己建立更强大快速的安全实验室，专门来研究测试“补丁”。将大规模布署“补丁”的时间延迟提高到1周以内。

图：打补丁的时机

自动化
从前面的不等式我们看出，降低布署成本、减小补丁失败成本，可以提高“补丁管理”决定的安全防御强度。

降低布署成本的有效办法就是“自动化”，建立覆盖全网的自动化补丁知识库和管理系统，集中收集、建立、分发“补丁”包。这样的自动化系统可以带来下面所列的明显收益：

* 将整个补丁分发过程的时间窗口减小到极低
* 将每服务器/每补丁数小时的“工时”成本降到很低 －分发安装费用降到接近0，只剩下制作软件分发包、检查测试补丁安装结果的“工时”成本
* 保证全网在补丁配置管理方面的一致性

另外，减小补丁失败成本的办法是对补丁进行有效测试，具体做法可以是购买专业厂家的服务，也可以建立自己的安全实验室。这样的投资对于分布式的大企业来说，具有非常高的投资回报率。

流程
补丁本身的特点注定补丁管理不可能有很好的预见性，但是作为管理者，在流程和手段上，却不能不预见到补丁管理的特性和意义，及其实施中的具体问题。所有的补丁分发与管理工具只是帮助加速或者自动化相应的策略和过程，提高效率和质量而已，但是不可能改变逻辑。如果补丁管理流程本身是混乱的，那么自动化的后果也肯定是混乱。

补丁管理相关策略和流程的设计需要充分考虑以下相关的重要流程环节：

? 企业的安全策略：漏洞或者缺陷是对安全的威胁，安全策略应该覆盖针对漏洞和补丁的相应策略；补丁和漏洞管理流程则应该与上述策略相适应。
? 变更和发布管理：补丁的制作、测试、批准和布署应该纳入标准的变更和发布流程。如果当前尚没有完整的变更和发布流程，则在补丁管理流程中应该明确定义补丁的优先级或者分类、制作、测试、批准和布署以及验证等相关职位、职责和时间。
? 配置管理：按照ITIL的最佳实践，完整一致的中心配置管理数据库（CMDB）是保持高水平IT服务管理的保障。定义补丁和漏洞相关的配置管理条目，并通过流程保证及时正确的更新。
? 资产管理：如果已经具备了资产管理体系和流程，补丁和漏洞应该与具体的资产和相关业务优先级对应起来，正确设计不同关键性资产的特定流程。
? 备份恢复和业务连续性管理：补丁布署的前后都会与企业的备份恢复以及业务连续性管理有关，需要充分参考、在必要时修改更新备份恢复和业务连续性计划。
? 紧急响应：所有的补丁管理流程必须设计相应的紧急响应流程。从前面的数字，我们知道，即使是官方正式发表的补丁，也有相当的概率会出现自身新的缺陷或漏洞。并且与企业系统的应用关联在一起，补丁的漏洞是绝对不可忽略的。流程中必须保证这样的恢复和紧急响应环节。

管理层应该综合考虑相关的各个方面，充分借鉴在IT服务管理或者ITIL方面的实践经验，或者借助于外部的专业服务，设计与整体IT基础设施管理系统相匹配的补丁管理策略和操作流程。

在应用前面的自动化补丁管理系统之前，应该充分调查研究具体的IT环境和整个补丁生命周期的各种问题，设计较为周密的补丁管理策略和流程，至少应该明确定义补丁管理的使用范围、补丁优先级、补丁分发包的制作和测试、批准与分发安装、安装后测试、备份恢复计划等。

综述
补丁管理是当前IT系统管理中越来越繁杂的内容。补丁全部不打，安全风险太大；什么样的补丁都打，一方面成本很高，另外补丁本身带来的风险也不可忽略。本文建议通过漏洞的影响度、流行度、简易度乘积（IPS）与资产联系起来判断该漏洞的安全风险，设定阈值。一般情况下，留出2周左右的测试时间，尤其是对于电信、银行等关键性应用场合。布署自动化的补丁管理工具可以大幅减小漏洞收集和补丁布署成本，从而在相同投入情况下，提高补丁管理带来的安全强度。补丁管理必须建立相应的流程，该流程应充分参考借鉴ITIL的最佳实践，融入到整体的IT基础设施管理体系中去。

发表于通信世界，总结了安全管理中心建设过程中的一些心得。
URL= http://www.cww.net.cn/Industry/Article.asp?id=10723
赵 粮
博士，冠群电脑（中国）有限公司
2004-2-18

网络安全正在受到越来越高的关注，其中一个最为热烈的话题就是安全管理中心的建设。安全管理中心（SOC），或者叫作安全总控中心（SCC），通过一个中央管理平台，收集整合来自各种各样安全产品的大量数据，并且从海量数据中提取用户关心的数据,呈现给用户，帮助用户对这些数据进行关联性分析和优先级分析。除此之外，安全管理中心还能够提供相当程度的集中“控制”和“管理”能力，可以帮助提供实时、准实时的安全风险管理能力。

目前，国内外的多家安全公司都提出了安全管理中心的产品或解决方案，移动、电信、联通等多家运营商都正在酝酿该方向的建设项目，几家省公司已经成为先行者。笔者有幸从开始酝酿、设计、建设等整个环节负责、参与了若干个安全管理中心项目，希望将自己的一些体会和经验教训与大家分享。前面已有一篇讨论基于安全管理中心的实时安全体系的讨论，本文从容易出现的九个错误的角度来讨论安全管理中心的建设。

1 错误或者失衡的资源分配和投资比例。

[separator]
我们知道，在绝大多数情况下，安全建设本身不是目的，而是为了保护企业的核心业务和资产。这样从投资的角度讲，投资回报率是必须考虑的。对于一个典型的网络管理中心（NOC）或者计费中心来讲，大约有数十台设备，主要包括各种层面的服务器和工作站，以及存储系统。而经过历次的安全建设和采购后，我们经常可以发现，中心连同分布在各地的防火墙、入侵检测、反病毒，它们的管理器和数据库等，在数量上也达到了数十个，与业务系统的规模相差不大，甚至数量上还可能会超出。虽然单个安全设备的维护工作量比高端服务器要低一些，但是总体上的保护体系和被保护的资产在维护资源上的投入失去了适当的比例。该现象的另外一个表现是大部分省公司、甚至总部还没有专门的安全管理员，IT系统的管理员兼职来维护管理安全设备，再没有足够精力的情况下，安全管理维护方面会被简化、忽略调，不能充分发挥安全投资的效率，间接地降低了安全体系的效果。
另外，可以认为，安全体系由两大类组件组成，其一是功能组件，例如访问控制、身份和认证管理、入侵检测、反病毒等，其二是管理性组件，事件收集和展现、知识管理、工单管理等。管理性组件的目的是提升功能组件的效率，减小相应的管理员人工成本。这个比例在典型安全体系设计中，国际上的比例大概是在10- 30%左右，换句话说，应该注意管理与功能投入上面的平衡。
通过上面的分析，我们知道，过多的功能性组件会导致管理成本过高，管理不利，效果不好；而过多的管理组件投入，又容易功能覆盖不到位，管理组件成为空中楼阁，无源之水。

2 错误的架构、不匹配的组织。
准确地讲，安全管理中心并不只仅仅是某个产品，或者某些产品的集成，它还是一种安全管理形式，需要相应的企业管理组织来负责运营，技术架构和组织架构再设计伊始必须互相匹配，运行的效率才有可能达到令人满意的程度。所以，在总部或者某个省电信公司考虑设计安全管理中心时必须考虑到自己当前的IT管理结构、预期的改变、安全管理的模式。首先在组织结构方面达成共识，再来考虑技术架构，考虑产品的可扩展性，未来是否可以平滑过渡，适应未来的组织结构改变。如下图所示，对于当前的几个主要电信公司来说，都是两级管理体制，省一级实现了集中管理。值得注意的是，安全管理中心并不必然地导向一个对立运作的实体，它可以和网络管理中心合署办公，也可以与企业信息化部或者IT部门合为一体，这依赖于建设需求方管理层参与设计，在建设和运营路线最终达成一致的思路。关键的一点是在开始规划选型时，考虑好以后的接口和平滑过渡，才可以更好地保护投资。

图：安全管理中心架构示意图

3 认为SOC的建设主要是产品安装，对建设中项目风险认识不足。
安全管理中心需要对以前存在的、现在建设中的、甚至规划中可能出现的安全产品进行管理，对多种多样的应用和设备进行事件审计和策略配置，另外，每个建设方对安全管理中心的功能定义也会进行增减，所以，建设过程中往往会涉及到多个厂家的许多产品（包括安全设备和其它）。另外，各个建设方情况千差万别，通常纯粹的安全管理产品很难很好地满足要求，必然会涉及到大量地定制和开发服务，这些对于项目管理来讲，背后都蕴涵着大量风险。需要很好地评估项目风险，并且通过仔细考察集成商和供货商的资质、质量体系和成功经验，慎重选择。

4 设计建设SOC时设施的特点没有考虑IT基础。
各个总部和省公司的IT系统各不相同，不同拓扑结构、不同的网络业务架构、不同的网管系统、不同的集成商、不同的安全防护水平。从IT服务管理（ITSM）的角度来看，它们具有不同的成熟度。从BS7799角度来看，10个安全领域的重视程度又不同。有些省公司已经建设有成熟的帮助台（Service Desk）和流程管理系统，IT系统网管实现了集中监控和集中的事件管理。SOC和NOC在许多方面有共同的特点，可以分享许多建设运营经验，以及IT组件。并且，在许多情况下，在事件管理、流量监视等方面，SOC和NOC共享的程度越高，安全保护的效果就会越好。

5 定义了不适当的项目目标。
一般来说，参照下图所示，安全管理分为四个层次，或者能力成熟度，越高的层次表示安全管理的成熟度越高，残余的安全风险就越低，但是通常来说，要求的安全投入也会较高。第一层是集中审计，能够对全网范围内的关键安全事件做到集中的、统一的收集和审计；第二层是集中监视，除了事件审计之外，还需要对安全防御体系自身的健康状况进行监视，对威胁情况进行监视；第三层是集中管理，在前面两层的基础上，能够对整体安全体系制定安全策略，集中分发配置，与IT基础设施的管理可以无缝集成，实现良好的实时风险管理；第四层是战略防御，除了自身安全体系的审计、监视和管理之外，强调了网络对抗和取证分析能力，针对性的实时优化安全策略。每个层次有不同的特性和实现手段，对于特定的建设环境来讲，并不一定意味着越高的层次就越好，而是应该量体裁衣，具体问题具体分析。可以在四个层次中选择适合自己的特性来分期建设，分步实现目标，达到最高的投资回报。

图：安全管理成熟度示意图

6 集成商和原厂家的技术支持力度不够。
这个问题应该属于项目风险控制范围之内，单独拿出来的目的是想强调一下：一定要慎重考察注意集成商和所选择产品的原厂家的技术支持力度，特别是本地技术支持力度。因为SOC建设中有大量的定制开发和服务，不可避免地需要频繁、有效地技术支持。很大程度上会影响整个项目的质量效果。

7 对选择SOC产品的可扩展性、健壮性、性能没有透彻的了解。
SOC与NOC建设相似，产品更换替代的成本很高，一般会采取升级、扩容、融合等进行发展，全天候7×24运行，越是遭到攻击、产生大量事件和网络负载的情况下越需要SOC的服务，所以在一开始的产品选择阶段要特别注意可扩展性、健壮性和性能的指标。这里的扩展性指能否层次化布署、能否顺利融合部门级的 SOC、是否可以通过硬件升级来实现更高的系统容量等。健壮性和性能是指在遭到大规模攻击、大量事件冲击的情况下，系统能否正常工作，表现如何？系统是否支持高可用性布署等

8 没有设计好相应的管理和应急流程。
我们已经知道，SOC建设远远不只是产品采购，还有许多定制服务。此外，SOC与NOC一样，需要相应的管理和应急处理流程，这些流程制度是整体安全策略的组成部分，应该纳入严格的配置和变更管理之下，并且做好相应的宣传和培训，定期进行演练，使得每个角色和相关人员都明白自己的责任和相关流程。管理和应急流程应该尽可能多地依靠自动化手段实现，并带有质量保证措施和考核措施。在流程设计和建设上面，可以参考ITSM中成熟的服务台技术和产品，充分结合 NOC的流程制度。

9 认为SOC建设完、验收结束就大功告成。
SOC是一种统一集中管理形式，是安全风险管理的最高级形式－实时风险管理。它的建设验收只是实现了第一步。接下来还需要及时地维持并更新、升级知识库（资产库、漏洞库、补丁库等），经常性的优化安全策略，演练应急流程的有效性，审计安全制度的执行落实情况。

安全管理中心是继网络管理中心（NOC）后的又一类引人注目的管理系统，它综合了许多国际标准、安全模型、IT管理技术，属于安全领域的新生事物，无疑需要众多从业者的关注和研究实践，分享SOC发展过程中的经验和教训，更好地指导后面的建设。本文希望能够抛砖引玉，以期获得更多的宝贵讨论。