课件分享：D6-2技术控制措施的评估与测试＃CISSP认证学习

每天叫醒你的不是闹钟，而是学习

01

技术控制是通过使用IT资产来实现的安全控制。这种资产通常但并非总是一些以某种特定方式配置的某种软件。当我们在审计自己的技术控制时，所要测试的是：技术控制对那些我们在风险管理流程中所识别到的风险的降低能力。因为我们需要理解实施特定控制的环境，所有各种控制与那些试图降低的风险之间的联系是很重要的。

一旦我们理解了技术控制的目的，我们就能够选择合适的方法来测试其是否有效。而对于试图做代码审查而言，我们可能更适合去测试第三方软件的漏洞。作为安全专业人员，我们必须熟悉、并对最为常用的技术控制措施的评估与测试方法具备理想的经验，以便我们能为当前的工作选择合适的方法。

02

脆弱性测试，无论是手动还是自动进行或者(更适宜地)组合这两种方式，都需要由拥有深厚安全背景、极其可信的员工或顾问来完成。即使最为自动化的脆弱性扫描工具也会生成误报；或者就一个具体的脆弱性向你报警，但这个脆弱性并不会危及你的环境或者在其他地方已经进行了充分的保护。此外，还可能存在两个单独的脆弱性，它们本身并不是非常重要，但结合在一起就会造成严重的影响。当然，漏报还是会发生，例如某个脆弱性的一个隐蔽元素会给你的环境造成重大危害，但并没有被工具指出来。

在执行脆弱性测试之前，管理层需要制定一份书面协议。这样做可以防止测试人员因为该项工作而被起诉，并通过书面形式向测试人员说明在测试过程中哪些应该做、哪些不应该做，以确保他们不会对工作职责存在误解。

管理层必须了解，测试的结果只是一个“即时快照”。随着环境发生改变，新的脆弱性可能会出现。管理层还应该了解，可供使用的测试方法有若干种，每一种方法都可以解释环境中存在的不同种类的脆弱性，每一种方法所能提供的结果的完整性也存在一定限制。

03

透测试是指根据所有者(例如高级管理层)的要求模拟攻击一个网络及其系统的过程。渗透测试应用一组专门进行测试及可能绕过系统安全控制的程序和工具，它的目的是评估组织机构抵御某种攻击的能力，以及暴露环境中存在的任何弱点。

渗透测试的结果应以报告的形式提交给管理层，其中应说明被标识的脆弱性和这些脆弱性的严重程度，并就如何处理这些脆弱性给出合理的建议。安全专业人员应获得包含授权测试范围的授权书。在测试活动中，测试团队成员需要使用这份授权书或备忘录。

脆弱性测试与渗透测试有什么区别呢？

脆弱性评估可以标识系统内的一系列脆弱性，这种评估通常采用一个扫描工具来完成。与之相反，在渗透测试中，安全专业人员利用了一个或几个脆弱性，从而向客户(或你的上司)证明黑客确实能够访问公司的资源。

经常被攻击者利用的脆弱性包括：

内核缺陷：这些问题在后台出现，深入到操作系统内。内核中的任何缺陷都可能被攻击者发现，如果可被利用，那么攻击者就能够最大限度地控制系统。确保为环境中的操作系统及时安装安全补丁(经过充分测试后)，尽可能减少出现脆弱性的可能性。

缓冲区溢出：糟糕的编程实践或者库中偶尔出现的bug都可以使输入超出程序被分配空间的存储限额。这会重写分配到缓冲区之后的数据或程序内存，有时允许攻击者注入程序代码，然后让处理器执行。这样，攻击者就拥有了与被攻击程序相同的访问权限。如果程序以管理用户身份或由系统本身运行，那么就可能意味着攻击者能够访问整个系统。良好的编程实践和开发人员教育、自动化的源代码扫描器、改良的编程库以及防止缓冲区溢出的强类型语言，这些都是避免这种极为常见的脆弱性的方法。

符号链接：虽然攻击者无法查看或修改敏感系统文件和数据的内容，但是如果一个程序访问一个符号链接(一个将访问重定向至其他位置的存根文件)，那么攻击者就可以入侵这个符号链接，从而获得未授权访问(符号链接主要用在Unix和Linux系统中)。这样，攻击者就可以破坏重要的数据或获得系统的特权访问级别。在过去，攻击者曾利用符号链接使一个程序检测口令数据库，或者使用一些字符替换口令数据库中的一行数据，从而创建一个权限与根用户相当的、不需要口令的账户。必须编写程序和特定的脚本，确保无法绕开文件的完整路径。

文件描述符攻击文件描述符是许多操作系统用于表示某个进程中的开放文件的编号。某些文件描述符是通用的，在所有程序中都是指相同的文件。如果程序以不安全的方式使用文件描述符，那么攻击者就能够向程序提供无法预料的输入，或者将输出转移到一个具有执行程序权限的、意想不到的位置。良好的编程实践和开发人员教育、自动化的源代码扫描器以及应用程序安全测试都可以减少这种脆弱性。

竞态条件如果一个程序的设计方式使它处于某种易受攻击的条件，而后再设法减少那些易受攻击的条件，那么就会出现竞态条件。竞态条件的示例包括：打开临时文件，而没有首先确保未授权用户或进程无法读取或写入这些文件；在特权模式下运行或初始化动态负载库功能，而没有首先确认动态负载库路径是否安全。攻击者可以利用这些竞态条件让程序(使用它得到提升的权限)读取或写入无法预料的数据，或者执行未授权的命令。良好的编程实践和开发人员教育、自动化的源代码扫描器以及应用程序安全测试都可以减少这种脆弱性。

文件和目录许可前面描述的许多攻击主要利用的是不适当的文件或目录权限，也就是说，系统某部分(一个更加安全的系统部件依赖于它)的访问控制中的一个错误。而且，如果系统管理员犯下错误，导致某个关键文件的权限的安全性降低(如允许常规用户访问口令数据库)，那么攻击者就可以利用这个错误将一名未授权用户添加到口令数据库中，或者将一个不可信的目录添加到动态负载库的搜索路径中。文件完整性检查器(它还应检查预期的文件和目录权限)可以及时甚至有望在攻击者注意并利用它们之前检测出这类问题。

漏洞测试和渗透测试有着至少三种：黑盒测试、白盒测试和灰盒测试。

黑盒测试 将被测试的系统视为完全的不透明。这意味着测试人员没有对于系统内部设计或特征的先决知识。所有知识只能通过评估本身才能传给测试人员。这种方法最好地模拟了外部攻击者，并且可以产生对信息泄露的洞察，从而可以给对手提供更好的攻击途径的信息。黑盒测试的缺点是：它可能不会覆盖所有的内部控制，因为其中的一些在审计过程中不太可能会被发现。还有另一个问题就是：在没有系统内部知识的情况下，测试团队可能会忽略对于子系统至关重要的各种日常操作。

白盒测试 在执行第一次扫描之前，审计师已经完全了解系统的内部工作原理。这种方法允许测试团队锁定特定的内部控制和功能，并且产生对于系统更完整的评估。其缺点是：尽管它可能对内部威胁有着更准确的描述，但是白盒测试可能无法代表外部攻击者的行为。

灰盒测试 介于其他两种方法之间的某处。内部工作信息有一部分而不是全部被提供给测试团队。这有助于将他们引导到我们想要彻底测试的领域，同时也在一定程度上能发现系统其他功能方面实际发生的情况。这种方法减少了白盒和黑盒测试中的各种问题。

04

日志审查是通过检查系统的日志文件，以检测各种安全事件或验证各种安全控制的有效性。日志审查实际上是在安全专家进行第一项事件检查之前就开始了的。为了使事件日志能够提供有价值的信息，他们必须捕获那些非常具体的、但可能是大量的、且基于行业最佳实践和组织风险管理流程的信息。而那些可以帮助你评估安全态势的，一整套万能适用的事件类型是并不存在的。相反，你需要不断调整系统，以应对持续变化的威胁环境。另一个为组织设置有效日志审查的关键因素是：确保所有联网的设备时间都标准化。

默认情况下，大多数日志文件都被本地存储在对应的设备上。这种方法所面临的挑战是：它使得对于事故而言，很难跨设备地关联各种事件。此外，它也使得攻击者更容易改变所攻破任何的设备上的各种日志文件。通过集中化整个组织中所有日志文件的位置，我们就解决了上述这两个问题，也更容易去归档日志，用以长期保留。因为这些日志可能会很大，所有有效的归档十分重要。

日志文件通常是攻击者用来试图隐藏其操作的首选项。作为安全专业人员的我们只有知道了这一点，才能尽自己之所能使之无法得逞，或至少使得攻击者们难以成功地篡改我们的日志文件。

05

真实用户监控（Real user monitoring，RUM）是用一种被动的方式来监控真实用户与Web应用程序或系统的交互。它使用代理从用户的角度来捕获诸如延迟、抖动和错误等指标。不同于综合事务，RUM使用的是真人而不是脚本的命令。

06

误用案例向我们的统一建模语言例图（Unified Modeling Language，UML）引入了一些新的关联。威胁者的误用案例是指：威胁我们系统特定部分或合法的用例。通常你所看到的带阴影的椭圆连接到带有标记为“威胁”箭头的无阴影的椭圆就表示这种关系。另一方面，系统开发者和安全人员可以实施控制来消减这些误用。这就创建了新的、带有标记为“减缓”箭头的、在无阴影与带阴影椭圆形之间的连接。

误用案例测试背后的思想是：确保我们有效和全面的识别出每个风险，以决定在风险管理过程中需要减缓的风险，并能够适用于考虑的系统。这并不意味着误用案例的测试需要包括我们系统中所有可能的威胁，但至少它应该包括我们需要涉及到的威胁。这个过程迫使系统开发人员和集成商将我们风险管理过程的产品融入到各种系统开发工作的早期阶段。它还使得快速跨越复杂的系统更为容易，并确保有效的安全控制被置于正确的地方，而不必深入到源代码中

07

如果你想从内部去测试自己的软件系统，那么可以使用代码审查，去系统地检查组成一个软件各部分的指令，并由该代码作者以外的其他人来执行。这种方法可以说是一种成熟软件开发过程的标志。事实上在许多组织中，一直到有人进行了代码审查并予以签发之后，开发人员们才被允许推出他们的软件模块。

08

接口测试是对给定的一组交换点的系统进行评估。这种评估应包括已知好的和坏的交换，以确保系统在交换的两端能够正确地运行。在软件测试中，位于好的和差的分割边界处，被称为边界条件。

然而真正的障碍却在于发现其间的测试用例上。因此接口测试的主要任务是提前设想所有的测试用例，记录它们，然后将它们插入到一个可重复的，且自动化的测试引擎中。

-END-