如何评测软件系统的安全性

常常被问到这么一个问题：如何评测一个软件系统到底有多安全？

 

一个回答是：我们不是有专门的软件安全评测标准和机构吗？没错，我们有专门的国际标准Common Criteria， ISO/IEC 15408，国家标准GB 18336。有专门的评测中心，如Common Criteria Lab，和中国信息安全产品测评认证中心。

 

似乎我们只要按照标准提供相应文档，把软件交给评测机构，不就行了？ 但是，事实上真的这么简单吗？举个例子，微软的Windows 2000系统得到了Common Criteria的EAL4+认证，但是还是有这么多软件安全补丁发布。问题到底出在什么地方？

 

我们先看一下Common Criteria是如何评估软件系统的安全的。首先要确定产品对应的Protection Profile （PP）。一个PP定义了一类产品的安全特性模板。例如数据库的PP，防火墙的PP等等。然后，根据PP再提出具体的安全功能需求（security functional requirement），如用户的身份认证是如何实现的。接下来，确定产品的安全对象（secure target），以及它是如何满足对应的安全功能需求的。

 

也就是说，Common Criteria主要集中在大方向上的软件设计上的安全。但是，对于具体的编码实现，和部署则没有涉及。而SD3，也就是安全设计（secure designed），安全开发（secure development）和安全部署（secure deployment）的三个环节，哪个出问题都不行。

 

另一方面，最终的用户关心的核心问题就是“这个软件安全吗”。一个由于设计导致的安全漏洞，和一个由于实现导致的安全漏洞，对用户的最终影响没有区别。Common Criteria在针对软件实现和部署上的评估上的不足，可以是说是CC面对的最大挑战。另外，Common Criteria要求的文档之多，评估的周期之长，也极大影响了它在评估面向企业和个人用户的软件安全性的有效程度。例如，一个产品的评估周期有时长达2-3年：等评测结果出来，老产品也要被新产品替代了。

评估（并提高）一个软件系统的安全程度，需要从设计，实现和部署三个环节同时着手。目前，微软的安全软件开发周期（SDL）提供了一个基于微软开发模型的参考解决方案。它并不是一个类似CC的评估测试标准。但是在如何有效的评估软件实现和部署环节的安全性上（例如FUZZ测试），大家可以借鉴一下。