产品脆弱性评估文档
脆弱性检测是信息安全风险评估的重点。脆弱性检测一般以信息系统脆弱性的分类为切入点，以脆弱性特征库的建立为工作的重点，以确定脆弱性采集方案为最终目标。脆弱性的分类方法为特征库中的脆弱性提供了组织形式，特征库中包含的脆弱性的粒度将决定脆弱性的采集方案[1]。在国际标准化组织(ISO)所制定的第13335 号信息安全管理指南中，将脆弱性检测从资产的角度进行分类，提出了物理层面、人员、管理等重要概念。在国家标准《信息安全风险评估指南》中，明确将脆弱性分成物理、网络、系统、应用与管理五大方面，并提出从这五个方面来识别脆弱性。本文对信息系统的应用脆弱性检测的方法进行研究，提出了应用脆弱性检测的一些指导方法。
1.隐蔽信道技术分析
隐蔽信道是资源配置策略和资源管理执行结果的信道。利用正常情况下不认为是数据客体的实体，从一个主体到另一个主体进行信息传输的信道，称为隐蔽信道。因此，TCSEC定义隐蔽信道是一个通信信道，它允许进程以一种违反系统安全策略的方式传递信息:隐蔽信道只和非自主访问安全策略有关，与自主访问安全模型无关。隐蔽信道是一种可用于在用户之间传递信息的机制，而这种机制是系统不允许的。
隐蔽信道又分为隐蔽存储信道和时间隐蔽信道。
隐蔽存储信道:如果一个进程直接或间接地写一个数据变量，另外一个进程直接或间接地读这个数据变量，这样形成的隐蔽信道就称为隐蔽存储信道。
时间隐蔽信道:如果一个进程通过调整它自己使用的系统资源(例如:CPU时间)的方法，从而影响到实际的响应时间，另一个进程通过观察这个响应时间，获取相应的信息。这样形成的隐蔽信道就称为时间隐蔽信道。
不管是隐蔽存储信道还是时间隐蔽信道，发送者和接收者之间的信息必须有同步关系。
2.隐蔽信道标识
隐蔽信道标识就是搜索系统中可能存在的隐蔽信道，并进行标识。一个隐蔽信道可以用一个三元组表示:
2.1文法信息流分析 文法信息流分析(SyntacticInformation-Flow Analysis )，是将信息流文法同每一 条实现语言的语句相联系。只要证明在完整的程序和TCB原语设计或源代码中，所有的信息流形式都符合信息流策略，那么就不存在隐蔽信道。否则，这个信息流可能是导致隐蔽信道的信息流，对于这些信息流必须借助语义分析确定:这个信息流是真实的还是虚假的非法信息流；这个信息流是否具有导致真实隐蔽信道的使用场景；文法信息流分析具有以下优点:能够以简单清楚的方法自动实现；可以应用于顶级形式化设计和源代码；能够应用于增量的独立功能和TCB 原语；在详细设计和源代码中，不会错过任何导致隐蔽信道的信息流。 但是，它也有以下缺点:发现的非法信息流可能是虚假的(将增加通过手动文法分析方法，消除这些信息流的工作量)；不适用于非形式化设计；不能帮助开发者确定，放置隐蔽信道处理代码的TCB位置；
2.2共享资源矩阵方法 共享资源矩阵方法(Shared ResourceMatrix Method，SRM)，要求进行以下五个步骤:分析所有形式化或非形式化，或者源代码中指定的TCB 原语操作；建立一个共享资源矩阵，行是用户可见的TCB 原语，列是被查看或修改的TCB变量；根据这些变量是读还是修改，用R或是M 标记共享资源矩阵的每一个
这个条目添加到共享资源矩阵中。对行是R 或M的每一个矩阵列进行分析，每当这些列的变量由一个进程读，而
由另一进程写，并且前一进程的优先级不支配后一进程的优先级时，这些列的变量 可能支持隐蔽信道。
3 隐蔽信道带宽估算
对于搜索到的隐蔽信道，应该估算它们的带宽。系统的硬件配置，如:CPU速度、内存大小和速度、缓存大小、硬盘速度等，对隐蔽信道带宽都有很大的影响；TCB 原语的选择、噪声等因素也对隐蔽信道的带宽有很大影响。为了估计隐蔽信道的最大带宽，假设隐蔽信道是没有噪声的，系统中只有收/发进程，收/ 发进程之间的同步时间可以忽略，这些假设对计算隐蔽信道的最大带宽是合适的，但实际上是很难达到的。
3.1隐蔽信道处理 对隐蔽信道的处理，一般采取以下三种方法:消除隐蔽信道、带宽限制、审计隐蔽信道的使用。
3.2消除隐蔽信道 为了消除系统中的隐蔽信道，必须对系统的设计和实现进行修改。这些修改包括:通过为每一个共享者预先分配所需要的最大资源，或者为每一个安全级别划分出相应的资源，从而消除可能造成隐蔽信道的资源共享。消除引起隐蔽信道的接口、功能和机制。
3.3带宽限制 带宽限制就是要降低隐蔽信道的最大值，或者平均值，以使得任何一个隐蔽信道的带宽限制在一个预先定义的可接受的范围内。限制隐蔽信道带宽的方法主要有:故意在信道中引入噪声。(例如:对共享变量使用随机分配算法，共享变量一般包括:共享表的索引，磁盘区域，进程标识等；或者以随机方式引入无关的进程修改隐蔽信道的变量。)；在每一个真实隐蔽信道的TCB 原语中，故意引入延时；
3.4审计隐蔽信道的使用 通过审计，能够对隐蔽信道的使用者起到威慑的作用。对隐蔽信道的审计，要求记录足够多的数据，以能够:标识个别隐蔽信道的使用，或者某一类型隐蔽信道的使用；标识个别
隐蔽信道或者某一类型隐蔽信道的发送者和接收者。此外还要求，必须发现所有对隐蔽信道的使用；应该避免虚假的隐蔽信道使用记录。一旦审计跟踪分析确定了一个隐蔽信道的使用，那么对于这个隐蔽信道进行真实的带宽估算是可能的，也是需要的。
通常情况下，不可能根据审计跟踪发现通过隐蔽信道泄漏的实际信息，因为用户能够对数据进行加密。同时，仅仅通过检查审计跟踪，没有办法区别泄漏的是真实信息还是噪声信息。审计隐蔽信道的使用，将遇到以下问题:无法区别是隐蔽信道的使用，还是没有危害的TCB 原语使用；在隐蔽信道使用者中，不能将发送者明确地从接收者中区
分出来。之所以会出现这些问题，是因为:单个TCB 原语，根据不同的参数值和系统状态，能够改变和查看一个变量或属性；不同的TCB 原语，能够被不同的隐蔽信道共享。这样的TCB 原语允许用户伪装隐蔽信道的使用以旁路审计，并且将引起隐蔽信道的虚假检测。隐蔽信道审计的关键设计，是决定哪些事件需要记录，哪些数据需要使用审计工具进行保存，以确保能发现所有的隐蔽
信道使用。如前所述，隐蔽信道的标识能 够简写为
隐蔽存储信道标识 开发者应确定用于标识隐蔽存储信道的信息来源，这些信息来源应该包括描述性高层设计和系统参考手册，还应该包括源代码和处理器设计(如果涉及到硬件分析)。开发者应保证所使用的标识方法是彻底地和可靠地，应可重复。这就意味着，其它独立测试者，使用同样的标识方法和信息来源，能够得到同样的结果。否则，标识证据将缺乏可信度。开发者所标识的隐蔽存储信道，应包括共享变量和读写变量的TCB 原语。开发者还应该将潜在的隐蔽信道和实际的隐蔽信道区分开。对于实际的隐蔽信道，开发者还应提 供实际的隐蔽信道使用场景。
隐蔽存储信道处理 开发者应根据实际情况，确定隐蔽信道的两个带宽常数:Bmin和Bmax。如果隐蔽信道的带宽小于Bmin，那么这个隐蔽信道可以被接受，不必采取什么措施；如果一个隐蔽信道的带宽大于Bmax，那么这个隐蔽信道比较严重，如果能够消除，最好消除，如果不能够消除，那
么应该采取措施将带宽降低到Bmax；如果一个隐蔽信道的带宽在Bmin和Bmax之间，那么必须对这个隐蔽信道进行审计。(通常建议Bmin=1bits/sec，Bmax=100bits/sec。)开发者应该说明:隐蔽信道是如何消除的；隐蔽信道的带宽是如何限制在一个可
接受的范围内；开发者应提供证据，证明所采取的隐蔽信道处理方法是有效的。
信息系统安全脆弱性分析技术
当前安全脆弱性时刻威胁着网络信息系统的安全。要保障网络信息安全，关键问题之一是解决安全脆弱性问题，包括安全脆弱性扫描、安全脆弱性修补、安全脆弱性预防等。
网络系统的可靠性、健壮性、抗攻击性强弱也取决于所使用的信息产品本身是否存在安全隐患。围绕安全脆弱性分析的研究工作分为以下几个方面：
第一类，基于已知脆弱性检测及局部分析方法
Satan是最早的网络脆弱性分析工具，也是该类研究的代表，由网络安全专家Dan farmer和Wietse venema研制，其基本的设计思路是模拟攻击者来尝试进入自己防守的系统，Satan具有一种扩充性好的框架，只要掌握了扩充规则，就可以把自己的检测程序和检测规则加入到这个框架中去，使它成为Satan的一个有机成分。
正因为如此，当Satan的作者放弃继续开发新版本之后，它能被别的程序员接手过去，从魔鬼（Satan）一跃变成了圣者（Saint）。Saint与Satan相比，增加了许多新的检测方法，但丝毫没有改变Satan的体系结构。Satan 系统只能运行在Unix系统上，远程用户无法使用Satan检测。Saint解决了Satan远程用户问题，但是Satan和Saint都无法对一些远程主机的本地脆弱性进行采集，而且两者的脆弱信息分析方法停留在低级别上，只能处理原始的脆弱信息。