Archive

Posts Tagged ‘KPI’

[Chinese]网络信息安全度量和考核指标体系(6)-擦桌子理论

October 3rd, 2008 5 comments

不要为KPI而活着。KPI只是一堆数字。偏执于KPI会死的很难看。

臭名昭著的”毒奶粉“事件(三聚氰胺)是一个KPI失败的例子。质检总局们关注蛋白质含量等KPI,但是却忽视了其它有毒物质的检测方面,而实际上保证无害、健康才是最重要的检测目标 – business objective。搞得各家奶业公司竞相降价逐利,丧心病狂地掺杂三聚氰胺这样的”毒药“来提高蛋白质含量的KPI。 这样的KPI完成地再好,最终也落得个丢了乌纱帽、千夫所指的下场。

在企业中做IT也是这样同样的道理。

通常,各个IT部门都会有各自的一些KPI,这些指标有的是传统留下来的,大家都用的,比方说电路和设备的可用率等。也有为了反映当年的策略目标制定的。有的是自上而下的,有的是部门报上来的,经常一次几次的评审,最终确定为当年的KPI。KPI不可能很全,也不可能很多,另外,在一年之初也不可能全部预计到后面的发展。这些都注定KPI不是运行的全部目标,也不是保护伞。 Read more…

[Chinese]网络信息安全度量和考核指标体系(4) – 读Andy的“安全度量”

May 8th, 2008 2 comments

坦白说,在LinkedIn上提问之前,就安全度量指标系统而言,我并没有做过更多的学习和研究。在得到大家的热烈指导和响应后,我越来越发现原来有这么多的资源和信息已经在哪里,可以借鉴。写了前面三段关于安全的度量指标体系的帖子后,我开始读Andy的“安全度量”。

Security MetricsAndy(Andrew Jaquith)的“安全度量”(Security Metrics: Replacing Fear, Uncertainty, and Doubt)这本书是一本不错的书。几个星期前从网上找来了PDF的英文版,前几天买了中文版(电子工业出版社,2007年12月)。这两天在深圳出差,抽路上的时间把书读了一遍。下面是点到为止式的一些评论。 Read more…

[Chinese]网络信息安全度量和考核指标体系(3)

May 6th, 2008 No comments

Ken的观点很有趣,虽然每个人都知道这个管理方面的格言:如果你不能测量它,你就不能管理它。但是,普林斯顿大学爱因斯坦办公室悬挂的一句话:“Not everything that counts can be counted, and not everything that can be counted counts. ”。 同样也是很令人思考的。

将安全事件的数量当作关键KPI – 这虽然非常直观,甚至是管理层很直觉的反应,但是还是不建议将安全事件的数量当作安全运行的KPI,甚至不建议把安全事件解决的时间当作KPI. 因为在很多时候,都很难保证不发生安全事件,或者发生安全事件后一定可以在某段时间内予以解决。例如国内、国外都发生过、或者正在发生着互联网的拒绝服务攻击,包括掌握着巨大资源的运营商都很难避免此类攻击,或者在遭受攻击后很快能制止攻击、或消除影响、恢复业务。我听说的很多例子只是被动地过滤或者更换地址等。这样,安全运行团队的业绩的偶然性就会很大,带来很多不公平的因素。
Read more…

[Chinese]网络信息安全度量和考核指标体系(2)

April 30th, 2008 No comments

继续整理关于安全考核指标体系(Metrics System)的一些想法和大家的反馈。

# 安全考核指标体系有什么意义?有什么价值?

第一, 从各种视角反映出当前组织的安全保护和运行状态,向管理层提供战略和战术层面的反馈,以及趋势分析
第二,用以诊断各种流程存在的优势和不足,并提供何以改进的提示
第三,用以组织的绩效考核

# 在设计安全指标体系时应该注意的要点,同时也可以说是好的指标体系的特点:

  • 与业务目标相关。这是第一位的要点。安全指标体系不是为了指标而指标,为了标准而指标,而是为了核心业务目标而制定。因为不同的组织企业,在不同的历史阶段有不同的业务目标,所以指标体系也不会有全世界通用的”灵丹妙药”。需要根据自己的特点而制定,但是可以参考一些业界的最佳实践。
  • 定义清晰,易于理解。大部分的指标是要团队、很多团队的协作才能实现的。所以,指标制定出来后,需要宣传贯彻,需要申请资源和协作。清晰易懂的指标体系帮助形成目标一致的合力synergy。
  • 前后一致,可测量,容易收集,低成本。大家都很了解SMART原则,这里也适用这一原则,即指标要具体(Specific),可量化(Measurable),可达成(Achievable or Attainable),现实的(Realistic),并且有限定的时间期限(Timely)。有明确的收集频率,收集源,较低的收集成本。
  • 可控制,通过行动可以影响结果。指标应该有明确的责任人和达成共识的阈值。责任人明确通过努力而影响并达成该指标。
  • 可以进行数量化、图形化的呈现

指标中的一部分会成为KPI,即关键绩效指数。这时通常有两种类型,其一是当前可以达成,但是需要一直保持,例如设备利用率;其二是通过努力在一定时间内达成,例如当前的每百设备高危漏洞数量是10个,设立的目标是降至每百设备1个。 Read more…

[Chinese]网络信息安全度量和考核指标体系

April 20th, 2008 2 comments

这段时间又到了总结过去、瞻望未来的时间,又要计划新的一年安全运营的目标和考核指标,大家都讲SMART,道理没错。可是一年的大方向是什么?然后确定下来的实现目标又是什么?带着一些问题,抱着试试看的心情,我在LinkedIn里提交了一个问题:how to measure the information security operations? 出乎我的意料的是,我得到了许许多多热心的、精彩的回答。非常有启发性。等我仔细整理后,再给大家一些分享。

安全考核(度量metrics、测量measurement)指标体系等是很意思的话题,可以说安全经理们天天都要打交道的问题。MBA的课程以及很多管理课程都会强调“如果你无法测量它,你就无法管理它!”, 包括ITIL也是遵循同样的逻辑。在安全运营这里这个原理也成立。所以说,问题就不再是要不要安全指标考核体系,而是如何选择适当的、正确的指标了。适当的、正确的安全考核指标应该体现出当前的工作和努力方向,它可以帮助安全团队与非安全团队、非安全专业人员更好地了解信息安全的工作和状况。同样,这些指标体系(Metrics System)对做好高级管理层的沟通并获取他们的支持也非常重要。

在这个课题上,已经有很多非常完整的参考资料,例如NIST SP800系列中的SP800-55,“Security Metrics Guide for
Information Technology Systems”,SP800-80, “Guide for Developing Performance Metrics for Information Security”,以及大家已经推荐的若干本专著,网络链接,都非常不错。

各位有什么好主意、思路不妨也分享一下。

Practice of measuring of the anti-virus system

April 5th, 2008 No comments

There is no doubt that anti-virus is the basic and one of the top critical security of all IT organizations. However, there might be sharp difference in the measurement of anti-virus effectiveness. In a previous presentation one year ago, I mentioned that the installation rate and update-in-time rate are two important factors to measure the performance of anti-virus system. In fact, a lot of IT organizations use these two factors as their KPI for desktop anti-virus or mal-protection.

We had some interesting practice on this. One year ago, we set up one new KPI – infection rate for anti-virus team, besides the above two. This new KPI means the number of infected machines in one month. At that time, we don’t know the average number of this KPI in the industry and even we don’t know whether or not it’s a proper KPI for anti-virus. One year passed. We lowered this number from above 10%, to lower than 5%. It’s a great achievement. The more convincing point is that we got to know this number of our international part is close to our current number of China.

The other potential KPIs and metrics for anti-virus system we discussed include the helpdesk ticket number related to desktop anti-virus, deskside support hours, number of re-installation of operating system, and etc.

Patch Management System Dynamics

May 10th, 2007 3 comments

Entering Internet age, new software vulnerabilities are found every day and the corresponding patches and temporary workarounds are coming with them. The software vulnerabilities may cause system breakdowns or are being exploited at any time. As the mass of installations of the patches costs lots of system resourse or may cause the restarting of the system, and performance decreases. On the other hand, rushing on patch might not be secure or might bring potential dangers to the stability and functionality of a system. How can these problems be solved? The patch and vulnerability management is not only the business of the security administrators but also the focus of the entire IT operation sector. We would like to share our knowledge and best practices on managing patches and vulnerabilities with the industry.

Figures and problems

Lets read some figures first. As reported by Meta Group, a total of 4192 vulnerabilities were found in 2002 and at the same time, as per the real statistic, system administrators cost a total of 1920 work hours to make up all 4 patching to 120 servers. This means that it will take about 4 hours to patch a server – including backup, installation and debugging. Suppose the system administrators are skilled and they can completely learn vulnerability and patch solution within 20 minutes. This needs 172 persons to cost an entire working day for making up the 4192 vulnerabilities. In case of only10% – 413 vulnerabilities – of them are adapted to our own network environment and each correspondent patch is on 10 servers, it needs 2065 persons/day (there are about 10 servers with the same configurations. From these figures we have learnt that by adding up the days of the two persons, there needs to be almost 10 full time administrators, while that doesn’t include the processes of testing and validating the issued patching and the secondary resource consuming resulted from the failure of patching making up. Thus we can see that the patching and vulnerability management has been a huge resource funnel and wastes a lot of system management resources. Read more…

[Chinese]信息系统安全审计之我见

July 23rd, 2006 No comments

什么是“审计”?

我们知道,审计(Audit)是指检查、验证目标的准确性和完整性,用以检查和防止虚假数据和欺骗行为,以及是否符合既定的标准、标竿和其它审计原 则。各国各级政府、组织一般都设有专门独立的审计部、审计委员会、审计署等机构。审计早年用于财务系统,到现在词典、字典中的“审计”(也包括 Audit)的定义都是针对财务系统。在当今的世界里,几乎所有企业、机构和组织的财务系统都运行在信息系统上面,所以信息手段成为财务审计的一种技术的 同时,财务审计也间接带动了通用信息系统的审计。在美国安然公司(Enron)和世通(WorldCom)财务欺诈案爆发后,在2002年美国紧急出台了 萨班斯法案(SOX, or SOA),赋予了“审计”新的意义,这里也包括了信息系统的审计。“审计”成为企业内控、信息系统治理、安全风险控制等的不可或缺的关键手段。

另据新闻报 导,在最近结束的IATA年会上达成一个重要共识:所有成员航空公司都要进行运行安全审计(IOSA),申请加入IATA的成员在正式加入前必须通过 IOSA审计。目前所有的成员公司要在2007年之前完成审计,否则不予保留会员资格。审计已经逐渐成为越来越多的政府部门、行业分支、大企业等加强治理 的重要手段。

美国信息系统审计的权威专家Ron Weber将它定义为“收集并评估证据以决定一个计算机系统是否有效做到保护资产、维护数据完整、完成目标,同时最经济的使用资源”。

审计系统主要包括两种形态

  • 基于主机的审计(主机、网络等各种日志)
  • 基于网络的审计(网络会话和行为)

它们分别依赖不同的手段来收集审计信息,面向不同的风险和威胁:

1 前者收集并分析各种日志。这是较早的、较为传统的审计方式,登入、登出、添加、删除、修改、更新等活动,应用日志、操作系统日志、数据库日志、网络设备的 日志等。按照IDC的新定义,SIEM(安全信息和事件管理)类安全产品负责收集安全设备和其它信息系统的日志和事件告警,进行过滤、相关、分析等处理。 一般说来,前两年如火如荼采购中的SOC产品(如果喜欢叫平台也可以)基本上都属于IDC的SIEM类。

2 后者直接查看数据本身。由于各种先进的攻击方法的出现、由于IDS的漏报、由于当前对于内部滥用和误用(这些都很难从安全设备的日志中发现)的担心,对于 网络和应用数据本身的记录、回放、分析等形成了另外一个审计分支。这类产品最早的出处应该是雷神(Raytheon )公司的SilentRunner(如果大家还记得的话,后来被CA公司收购,现在产品的名字叫Network Forensics),专门用于分析网络流量和海量日志,从中发现IDS等安全设备不能发现的潜在威胁和事件,违反安全策略和规则的行为。另外NAI公司 的Sniffer,或者后来的开源软件TCPDUMP虽然缺少上层的分析层和展现层,也有一部分这方面的功能。NAI公司分家后,Sniffer公司继承 了网络取证分析产品InfiniStream Security Forensics。Niksun公司的NetDetector, NetVCR, NetX等系列产品可以“连续的流量记录和存储”、帮助分析网络中的流量、监控网络行为“网络异常及入侵检测”、以及帮助进行符合性分析和事件取证“网络 审计分析”等。

近两年来,随着对操作行为本身进行审计的需求的提升,于是产生了一种使用应用代理进而建立堡垒主机的方式来控制网络访问活动、并获得操作数据进行记 录并分析的审计系统。这类系统的代表包括Symark公司的PowerBroker,以及Bluecoat公司的ProxySG等。这类审计系统需要客户 端显式地配置代理指向的地址,并可能需要进行二次验证以符合代理的安全策略。

国内已经开始有越来越多的公司开始涉足并推出自己的安全审计产品,除去上述第一种的日志收集产品之外,还出现了相当多的网络镜像方式获得数据,进行 会话重组和协议分析,可以根据安全策略发送Reset包主动中断网络连接(有些还可以进行身份认证和授权验证),这类产品的代表包括清华紫光的ACA、以 及复旦光华的S_Audit等。前者与认证、授权等结合,面向运行维护需求,而后者则加入了很多HTTP、IM等应用的分析展现功能,面向企业内部安全使 用控制。

[待续]

richardong 2006-09-15 评论

我对文章中对”审计”的分类有一点建议和一点补充:

原文:

  • 基于主机的审计(主机、网络等各种日志)
  • 基于网络的审计(网络会话和行为)

我的观点:

  • 基于主机的审计(用代理监视并记录发生在主机上的行为)
  • 基于网络的审计(网络会话和行为)
  • 日志审计(各种日志:操作系统日志、数据库日志、网络设备日志等)

最后,我认为这三者应该统一在一个平台上,但与SOC最大的不同点在于,这样一个平台不应该强制将各种格式迥异的日志转换成统一的格式(Normalization)。

zhaol 2006-09-15 评论

多谢。不过我保留我的观点。审计要素或者是行为业务数据本身,或者是数据的数据,即元数据,传统的日志和审计系统都是后者。也就是我所说的基于主机的审计。前者记录业务数据本身,也就是我所说的基于网络的审计。或者我对这两类的名称上有些含混。欢迎继续争论…

zhaol 2006-12-26 评论

在三所产品测试网页上有一个安全审计产品的标准…
业界还有许多与审计有关的最佳实践/标准/框架,例如CoBiT,BS7799/ISO27001等。

zhaol 2007-01-20 评论

SOC 正如其名字所说是个Operations Center,主要目的是负责监控、然后带动后台的其它运维活动。不管是日志审计、还是操作行为审计都不是SOC的主要方向,管理制度方面(例如补丁、口 令、策略配置等)的审计更不是SOC的内容。相反的,SOC的运行倒应该是审计的对象:监控的有效性、响应的及时性、措施的有效性等。

[Chinese]安全管理过程中的执行力

November 9th, 2005 13 comments

安全管理很多依赖于企业自身的企业管理水平,如果剥去安全策略、管理制度和流程的完备性、前瞻性等技术因素的包装,其实,企业治理过程中最为重要的要素之 一 - 执行力,对安全管理同样非常关键,它决定了那些(可能漂亮或者不怎么漂亮、完备或者不怎么完备的)安全策略、制度流程等是否能够得到落实。实际上是安全效 率(efficiency) 和 安全有效性或效力(effectiveness)的问题。开发几尺厚的安全策略制度流程手册文档,购买千兆防火墙、IDS,上安全管理中心(SOC)等等 这些措施大多都是面向的安全效率,而如何能够保证所有的或关键的安全措施都能够坚守岗位(Stick)、按照策略运转是效力问题。

在2002年准备SOC项目时,考虑推出了“可视化”、“可量化”、“可管理”、“可运营”等几个概念,强调了企业信息系统中安全风险的可视化和可量化, 能够实用技术手段揭示“冰山水面下的部分”。“可管理”、“可运营”强调了安全管理与企业管理的融合,安全管理要走出去,加强沟通宣传,避免“曲高和寡” 的技术主导倾向,时刻要考虑组织职位流程方面的落地能力、可操作性。

这一切做法的出发点从本质上说与IT治理、企业治理的思路是一致的,安全管理不需要“重新发明轮子”,我们只需要多借鉴,多思考,很多安全问题其实可以寻求安全之外的经验知识来帮助解决。安全管理活动中需要注意提高“执行力”。

Read more…

9 Common Mistakes in Building A Security Operations Center (Chinese)

October 25th, 2005 1 comment

This post was published at cww.com.cn , 2004, where I summarized the 9 common mistakes at a Security Operations Center(SOC) project, which was becoming hotter and hotter at China. In brief, they are:

  1. unbalanced resource investment on security elements and management
  2. unmatched organization structure
  3. misunderstanding of SOC as a pure product. It’s a project on management
  4. without consideration of IT infrastructure accordingly
  5. wrong project goal
  6. not enough support from the software vendors and/or system integrators
  7. without thorough understanding of the SOC products under implementation
  8. withoug corresponding management processes, such as monitoring and incidents management
  9. regarding the finish of the product implemantation as the end of the SOC construction.

Read more…

【老文章】建设“补丁”管理系统

February 23rd, 2004 No comments

这篇文章写于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基础设施管理体系中去。

【老文章】安全管理中心建设中易犯的9个错误

February 8th, 2004 No comments

发表于通信世界,总结了安全管理中心建设过程中的一些心得。
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发展过程中的经验和教训,更好地指导后面的建设。本文希望能够抛砖引玉,以期获得更多的宝贵讨论。