Cloud & Telecom Security

It’s very exciting to get the login page of https://imo.im. It’s amazing. It’s a web-based multi-client instant messager. At this moment, it can support MSN, Yahoo, AIM / ICQ, Google Talk, MySpace, and Skype. Yes, and Skype.

I used my MSN account to do the first ride. It has multiple crisp and slim windows embeded in the webpage, one small window for a session. The login and chatting are very responsive.  It support Chinese (double byte characters) very well.

Then I began to test Skype. The Skype login is quite fast. It works! I am wondering how these guys simulate a Skype client to login. You know two years ago it became top news when somebody re-engineered the Skype protocol and developed their own Skype-compatible client.

I know imo.im is using SSL. However, before users are rushing to transfer to imo.im, they must solve security concerns. That’s far away to convince users at its security. For example, how they handle the user data, including the account information, password, and chat history.  Actually when I recommend imo.im to one of my friends, I was told that he did not want to test this because he didn’t want to exposure his account information.

All in all, this is my first ride with imo.im. Its user experience is by far better than previous web IMs. In addition, it supports Skype. It’s great plus. However, there is a long way for them before users are convinced to drop their trational GUI IM clients.

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

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

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

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

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

It’s exciting to fing more and more nice and elegant themes released. I just changed my blog theme to ElegantBox. Just as its name reflects, it’s very elegant. Meanwhile, it support Postviews and Tags just out of box.

I don’t have time to read the change log of WordPress 2.6.2. It might be a quick fixing update. Any way, I downloaded and installed it. Hope everything going well.

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

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

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

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

“完成了一次漂亮的风险评估，发现了很多重要的关键的漏洞。这些漏洞大大小小存在于各种服务器和网络设备等，分别由不同的部门和小组管理运维。接下来如何策划管理来保证这些漏洞能够得到及时的修复呢？”
“我会向领导正式汇报，然后召集一次漏洞修补的启动会，和大家一起制定修复计划，然后督促大家完成”
“在执行过程中，发现很多服务器上的补丁不能按时打上、漏洞不能按时修复。服务器小组和应用小组的理由也很充分：资源不够；陈旧应用不清楚，不敢随便打补丁或重启；申请不到变更时间窗口；等等。这时，你怎么办？”
“我会继续沟通，必要时向领导汇报”
“向领导汇报什么？”
“汇报当前漏洞修补的进度，我们碰到了麻烦，需要领导支持”
“领导肯定会支持你，但是你到底需要什么样的支持呢？“
”希望领导命令系统小组必须尽快修补漏洞，或者告诉我们可以接受风险、放弃修补”
“如果你是CIO，又会如何做决定呢？”
“#￥%@&”
Read more…