Cloud & Telecom Security

ENISA的全称是欧洲网络信息安全局，前几天刚刚写了一个帖子讲了它发布的社会安全网络白皮书(http://sbin.cn/blog/2010/02/08/enisa-msn-security-wp/)。该组织的名称和法律地位非常令人“敬仰”，但是，由于属于新生报到，在业界还没有引起太多的关注和媒体报导。大家可以Google一下，尤其是中文内容更是少之又少。http://www.enisa.europa.eu/ 是该组织的官方网站。

近日，ENISA与云安全联盟CSA一起，发起了一个非常引入注目的业界项目 – Common Assurance Metric – Beyond the Cloud， 直译为”通用保障指标-在云之上”，我们简称CAM。该名字起的很有魄力，也很有诗意（喜欢文明系列游戏的人会联想到CIV4-Beyond the Sword，喜欢唱歌的朋友会响起“月亮之上”的旋律，呵呵）。不知看到这个题目，你是什么感觉？我的第一眼是ENISA和CSA有眼力，选题很棒。

CAM项目的使命和目标包括：
- 开发一个能够为业界机构验证测量信息保障成熟度的客观的、可量化的指标框架。
- 避免消费者被主观的、人为的提供商安排所左右
- 促使不需要第三方审计公司即可达成的、相对透明和公正的安全运行评价 Read more…

Actually, the whole thread was originated with a message at discuss@securitymetrics.org “Request for ideas” by Dimitrios Stergiou. Dimitrios likes to have some recommendations for his master program. By a sudden idea, I dropped him a message to recommend him to work on this true or false problem at security metrics.

It’s true or false: 70% of security incidents are due to insider threats?
I just read one book, “The New School of Information Security”, by Adam Shostack, Andrew Stewart, Addison-Wesley, 2008, where I found one interesting argument by the authors. The authors doubt the statement that 70% of security incidents are due to insider threats. You know, many consultants and books, articles regard this statement as one basic hypothesis at security. What’s your idea about it?

Completely a surprise, I found Adam, Andew, Dan and many experts jumped in to this discussion thereafter. A lot of fresh ideas emerged at discussion threads. In order to get more experts into this topic, I submitted a discussion at SecurityMetrics group, LinkedIn.

This RSA/IDC report has some information related to this topic – Insider Risk Management: A Framework Approach to Internal Security(Thanks to Hammud).  It is a good reference. In summary it told us two things that: Read more…

读到一个不错、很有思想的帖子，来自于Steven Fox，推荐给大家。

Read more…

今年桌子上用的是安言咨询Robin送的小台历，每个月都有一个小故事，通过这个小故事引申出某个方面对安全管理的启发。都很有启发，先谢过Robin。

六月份的故事是关于扁鹊的，“名医起死回生，神医防微杜渐”。 我把这个故事引申了一下，把扁鹊兄弟和安全运维以及安全度量给搞了次“联想”。故事的原文是这样的：

扁鹊是公认的名医，其实他还有两个哥哥，医术比扁鹊还好。一次，魏文帝问起此事，扁鹊解释说：我的两位兄长才是真正的神医。我大哥治病，是在病情发作之前。他所在的地方人们身体健康，根本不生病，所以他的名气无法传出去，只有我们家的人才知道。我二哥治病，是在病情初起之时。他所在的地方人们患上轻微的小病很快就痊愈，所以他的名气只有在本乡传播。我扁鹊治病，是在病情严重的时候。一般人都见我经脉穿针放血、皮肤上敷药等大手术，以为我医术高明，名气因此响遍全国。 Read more…

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

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

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

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

在Andrew的《安全度量》一书中，提到了一个关于反病毒系统的指标。 Dan Geer提到他的一位CSO朋友说：“去年他们阻止了70000个病毒进入内部网络，但是更为自豪的是阻止了500个病毒流向外网。”， 内外网的病毒比是140：1。 于是我也查了一下我们的数字，我们一个月阻止了12000个病毒进入内网，却有300个病毒流向外网，这样我们内外网的病毒比是40：1。按照Andrew的说法，似乎我们的内部网没有那位华尔街投资银行的网络干净。但是，为了比较这个指标，我们还需要另外一个数字，就是进入内部网络的邮件总数，流向外网的邮件总数，有了这两个数字后，其实我们就可以比较两个比例：

进入内网病毒率= 检测到的进入内部网络病毒数量 / 进入内部网络邮件总数
流向外网病毒率= 检测到的流向外网病毒数量 / 流向外网邮件总数

将上下两个病毒率进行比较，或许更有趣一些。大家可能会认为，一般企业两个出、入两个方向的邮件总数应该差不多。一般“入”方向肯定会大很多，因为至少有大量的垃圾邮件存在。垃圾邮件百分比现在居高不下，一般可能在40%-70%之间，甚至更高。

关于服务器的病毒感染率，尤其是邮件服务器和文件服务器、FTP服务器等，每日都有大量的文件交互，普通用户的文件染毒就会直接影响服务器染毒的指标。这个染毒不是系统级染毒。如何处理这个指标呢？与系统管理员的绩效联系起来，似乎有些还有些距离。

大家在安全运营工作中是如何处理各种各样的安全指标的，都来分享一下吧。

著名安全专家Bruce Schneier在CSO杂志上发表他关于安全投入回报的一个篇文章。我想这也就是Andrew在安全度量中提到的观点。读过这篇文章，事实上，Bruce并没有完全反对安全投入回报分析。他只是提醒安全经理小心使用安全厂商们的回报模型和数字，因为其中可能有很多水分，并不可靠。

Bruce也举了若干个例子来说明一般的财务ROI分析模型以及ALE（就是CISSP培训中的那个术语annualized loss expectancy ）不适用于小概率、巨损失的情形。而很多安全风险和投入就属于这一类。

Bruce的例子很有趣。ROI模型在小概率、大损失的场合不太适合使用，因为没有足够多的样本和数据可以用来统计。大家来看一下Bruce的例子。机场的安全检查新措施大概给每位旅客增加了半个小时的等待时间，按照统计数字，2007年美国一共有7.6亿人次旅客登机，这样总共的等待时间达到了惊人的43000年，假设人均寿命是70岁，就相当于这种安全检查每年杀死大概620个人。很令人吃惊吧！如果考虑到消耗的时间全部是清醒的时间、登机旅客的经济工作能力等，这个人数可能要达到上千人。好了，现在的问题来了 – 这样的安全检查措施值得吗？ROI分析需要证明如果不要安全检查的话，恐怖主义至少会杀死更多的人。

坦白说，这样的判断并不难做，911事件改变了很多人的看法。但是在互联网和IT系统中，这个判断和分析就不那么容易了。

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

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

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

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

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

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

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

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

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

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

This evening, I read one whitepaper sent by Paul a few days ago. This is a good whitepaper which covers much CISSP knowledge and financial terms, e.g. probability, NPV, etc. This whitepaper makes a new term – ROSI. It means Return On Security Investment.

This diagram is copied from the whitepaper which is used to illustrate the security investment and attitude. It’s interesting. Actually, security awareness is one of most important jobs of all CISO. They must be very good at promoting security and communicate with financial controllers and business decision makers.

It’s very cool that you can calculate quantitively the return against security investment, even though it must come along with a lot of assumptions.

这段时间又到了总结过去、瞻望未来的时间，又要计划新的一年安全运营的目标和考核指标，大家都讲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”，以及大家已经推荐的若干本专著，网络链接，都非常不错。

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

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.

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…

什么是“审计”？

我们知道，审计（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 评论

zhaol 2006-12-26 评论