<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Cloud &#38; Telecom Security &#187; VMS</title>
	<atom:link href="http://sbin.cn/blog/tag/vms/feed/" rel="self" type="application/rss+xml" />
	<link>http://sbin.cn/blog</link>
	<description>Technologies and comments on cloud and telecom security, bridging China and the world!</description>
	<lastBuildDate>Fri, 17 Feb 2012 06:43:02 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
		<item>
		<title>【老文章】建设“补丁”管理系统</title>
		<link>http://sbin.cn/blog/2004/02/23/security-patching-system/</link>
		<comments>http://sbin.cn/blog/2004/02/23/security-patching-system/#comments</comments>
		<pubDate>Mon, 23 Feb 2004 14:17:00 +0000</pubDate>
		<dc:creator>Richard</dc:creator>
				<category><![CDATA[-Chinese-]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Telecom]]></category>
		<category><![CDATA[KPI]]></category>
		<category><![CDATA[Patch]]></category>
		<category><![CDATA[SOC]]></category>
		<category><![CDATA[VMS]]></category>
		<category><![CDATA[信息安全]]></category>

		<guid isPermaLink="false">http://sbin.cn/blog/2004/02/23/security-patching-system/</guid>
		<description><![CDATA[这篇文章写于2004-2-23发表在中国计算机报。讨论了安全补丁的管理成本、打补丁的时机以及建立补丁管理系统的建议。 &#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62;&#62; 进入到当前的互联网年代，几乎每天都有新的软件缺陷、漏洞被发现，同时伴随着相应的补丁或者临时解决办法。软件的缺陷或漏洞随时都可能会造成系统崩溃或者入侵。但是大量的漏洞和补丁安装需要占用大量的资源，或许还需要系统重起，降低运行服务方面的数字，另外仓促推出的补丁也未必就是安全的，或许还会引入稳定性、性能方面的隐患。两者相权，如何取舍？不管怎样，补丁和漏洞管理不仅仅是安全管理员的事情，而已经成为整个IT部门运行的关注焦点。本文希望和大家讨论并共享在补丁以及漏洞管理方面的若干思路和经验教训。 数字与难题 先来看一组数字。根据Meta Group的报道，2002年总共发表了4192个漏洞，同时按照一个实际的统计，系统管理员总工花费了1920个工时，来将4个补丁全部打到120台服务器上，即在一个服务器上面打一个补丁的时间大概为4小时，包括备份安装测试等环节。假设系统管理员有很好的技能训练，可以在20分钟内阅读研究完一个漏洞及其补丁（解决方案），那么4192个漏洞总工需要172个人天，再假设其中只有10％的漏洞适用于自己的网络环境，这样413个漏洞，每个相应的补丁布署在10台服务器上，这样共需要2065个人天（即同样配置的服务器数量为10个左右）。我们可以看到，这两个人天数字加在一起，差不多是10个全职的安全管理员，这里还没有考虑对厂家发表的补丁进行的测试和验证过程，也没有考虑打补丁失败造成的二次资源消耗。可以看到，补丁和漏洞的管理已经成为一个很大的资源漏斗，占用大量的系统管理员资源。 管理者对这些系统和安全隐患不能视而不见，但是，这样巨大的资源消耗也承受不起，必须找到更加有效的解决途径，这些解决途径包括以下措施： ? 引入知识共享或者外部知识库（专业服务），减少漏洞和补丁学习过程消耗 ? 建立有效的补丁管理流程和备份回卷计划 ? 引入自动化的补丁和漏洞管理工具，加速布署过程 打还是不打？ 考虑到上面的数字，我们看到，“补丁”绝对不是免费的，而是很昂贵的。这个成本中包括收集、了解、测试、布署、备份恢复，以及风险成本。但是，“不打”的成本是数据失密、丢失、窜改、拒绝服务、系统恢复，以及其它无形损失等。简而化之，下面的成本不等式成立的时候，就是可以“打补丁”的时机： 布署成本＋补丁失败概率×失败成本 &#60;= 攻击入侵概率 × 攻击入侵成本 通常使用三个数字来描述一个漏洞的安全风险特性：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基础设施管理系统相匹配的补丁管理策略和操作流程。 [...]]]></description>
		<wfw:commentRss>http://sbin.cn/blog/2004/02/23/security-patching-system/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

