安全需求学习笔记(一)

最近由于要编写关于应用安全需求方面的规范文档需要学习关于安全需求的知识，看到一篇文章挺好用的说，特意写下学习笔记。

原文链接: http://www.uibk.ac.at/linuxdoc/LDP/HOWTO/Secure-Programs-HOWTO/requirements.html

里面介绍到Common Criteria标准(简称CC),它包括三个部分:CC的介绍(Introduction)，安全功能需求(Security Functional Requirement)和安全保障需求(Security Assurance Requirement)。另外有一份"Common Evaluation Methodology" (CEM)文档用于指导大家怎样按照CC去评估软件的安全需求。

由于CC作为ISO/IEC 15408:1999国际标准，要实施它是非常昂贵的。因此ISO的标准往往不如W3C,IETF所倡导的免费标准受欢迎。而且由于ISO收费都据为己有，而没有回馈给为他们编写标准的志愿者们。所以CC的编写者们预见到这种情况，特意地编写了另外一个版本:[url]http://csrc.nist.gov/cc/ccv20/ccv2list.htm [/url]，这个版本是免费的，因此尽管它并不是ISO标准，但是却广为使用，而免除我们实施ISO的高昂费用。

CC通常用于创建两类文档，"保护概述(Protection Profile)" (PP) 或者是"安全目标(Security Target)" (ST)。

一个PP文档通常是由用户群组定义出来的产品所需的安全属性。基本上，PP是一个由用户按照CC特定要求定义出来的安全需求列表。因此假如你想要构建某类产品，你可能可以找到一个或多个该类产品的PP文件，用于描述其它用户对该类产品的安全需求(例如，一个操作系统或者防火墙)。

一个ST文档描述一个产品于安全相关的具体行为，或者其行为的一个子集。一个ST文档不需要特意去满足任何一个PP文档的要求，但是它可以同时满足一个或者更多的PP文档要求。

PP和ST都可以用于进行正规的安全需求评估。

一个基于PP的评估只需要保证PP符合各类文档描述的规则以及明智的检查。

一个基于ST的评估会使用ST文档去校对一个特定的产品(也叫"评估目标(Target Of Evaluation)"(TOE))的行为是否和ST文档描述的情况一样，检查TOE是否满足ST所要求的安全功能需求。顾客可以根据所需拿ST的评估结果和PP所描述的安全特性进行比较。通过这种对比，消费者可以知道产品是否满足其所需——假如不满足，也能知道其限制在何处。

为了制定一份PP或ST,你需要进行一个定义安全环境的流程，即你的假设，面临的威胁，以及组织相关的政策文档(如果有的话)。通过安全环境的定义，可以派生出产品以及该类产品的安全目标。最后，挑选能够符合目标的安全需求。

安全需求分为两类:功能需求(产品必须能做什么)和保障需求(通过度量确保满足安全目标)。实际上定义PP和ST往往并不如这里所说的那么简单，但是最终的结果必须能够罗列出一种清晰的关系以确保没有任何关键目标被轻易忽视了。即使你并不打算写一份PP或者ST，CC的一些意见仍然对你有帮助；定义出安全环境，安全目标及安全需求的过程对于你定义出产品的什么特性是重要的仍然有很大的帮助。

CC的最主要目标是为了制定出正规的功能需求和保障需求。大体上来说，大部分的CC就像是一个安全需求的"chinese menu(中文菜单?)"一样供任何可能需要的人选择。PP的作者们会从各种选项中挑选出他们所需的，而ST的作者们会从CC中挑选出他们会提供的。

由于会有很多人很难定义出一组合理的保障需求，因此一批预定义的保障需求，名为"评估保障等级(Evaluate Assurance Levels)"(EAL)，被定义在CC里面，以供有1到7个等级。EAL2是对EAL2所定义的一套保障需求的简述。产品可以自己定义额外的保障度量，例如，它们可以把EAL2和其它的保障需求加在一起(假如这时这组需求无法到达更高的等级，我们叫这个等级为EAL2+(EAL2 plus))。现在已经有很多国家签署了公共声明承认有资格的实验室去进行EAL4或者更低等级的评估结果。

假如你要写ST或者PP，有一个开源软件可以帮助你，叫做CC Toolbox"。它可以保证需求之间的依赖关系是否得当，提供通用的需求，并且帮助你快速完成一份文档，但是显然它不能帮你去完成你对所需要的安全需求的思考。对于PP和ST具体所需要包括的内容，在CC文档的附录B和C中分别有描述。

假如你决定要让认证实验室为你进行评估，那你要准备好花钱，花费时间，并且要按照流程走。另外，评估要求你花钱让认证实验室为你评估，评估的等级越高花的钱越多。单纯相信你的产品足够安全是不足够的；评估员还要找证据去支持各种宣称的目标。因此，评估需要有文档，而且所需的文档必须符合或者改进到符合CC的要求(尤其是对于高等级的评估)。每一个要求都必须要证明是符合于某些等级的，因此要求越多越强壮，而设计越复杂，评估费用越高。显然，假如发现缺陷，它们通常都要被修正。必须注意我们是要给钱给一个实验室让它帮我们去评估一个产品并且验证其真实性。假如一个产品不能符合其要求，那你基本上只有两个选择：要么修复它，要么修改(降低)要求。

在进行一次正规的ST评估之前跟你的客户讨论他们想要些什么是非常重要的；一个包含了功能需求和保障需求但是并不符合客人需求的评估将是物非所值的，而且一个疏忽了必要需求的ST也可能不被顾客所接受(因为必要的部分将不被进行评估)。PP文档叙述了这些需求，但是要确保PP反映的是顾客的真实需求(也许顾客只需要PP中的一部分功能或保障需求，或者他们脑中有一个完全不一样的安全环境，或者在想你的产品可能会在其它的情况可以被用到)。值得注意的是ST不需要让产品满足每一个安全特性；一份ST只会描述什么将会被(或者已被)评估。一个拥有较高EAL等级的产品不需要比一个有较低EAL等级甚至没有等级的产品更加安全；假如安全环境不一样的话，可能可以通过不去评估一个有较高等级的产品，或者省略一些重要的评估目标等方式来节省时间和金钱上面的开销。评估并不等同于证据，它只是利用定义好的最低门槛来获得对需求或产品的信任。