Cloud & Telecom Security

Another way of thinking about it, specifically that if you want security then you must control the future, if you want to control the future then you must be able to draw conclusions from what you know, if you want to draw conclusions then the basis for those conclusions must be reproducible, and if you want reproducible bases you have to have a measurement regime.

- Dan Geer

- Good enough is good enough.
- Good enough always beats perfect.
- The really hard part is determining what is good enough.

- by Ravi Sandhu

You can download the whole paper here.

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.