第六章 安全评估与测试

1、审计策略

“审计”简而言之是一个系统性评估。在CISSP考试环境中，可以将其含义缩小为对信息系统内部安全控制的系统性评估。

（1）信息系统的安全审计流程

• 确定目标，显然其他一切都取决于这点。
• 让合适的业务部门领导参与进来，以确保业务需求能够被识别和涉及。
• 确定范围，因为并不需要全部涵盖进来。
• 选择审计团队，根据目标、范围、预算和可用的专业知识，来决定是由内部人员还是外部人员所组成。
• 计划审计，以确保按时、按预算实现所有目标。
• 执行审计，要在坚持计划的同时，记录其中的任何偏差。
• 记录结果，因为所产生的大量信息即是有价值的，同时也是不稳定的。
• 将结果传达给合适的领导，以实现和维持强有力的安全态势。

（2）内部审计和第三方审计

• 内部审计
  • 优势：
    1. 熟悉组织内部运作组织中评估资源更为灵活
  • 缺点：
    • 经验有限，发现能力可能不足
    • 存在利益冲突可能性
• 第三方审计
  • 优势：
    1. 经验足，更专业
    • 不了解内部动力和政治，更公正
  • 缺点：
    1. 成本高

（3）服务性组织控制

• 当公司以整合方式共同开展工作时，必须特别注意确保每一方都能承诺提供必要的保障、义务和责任，而且这些应该在每一方所签署的合同中被明确规定下来。服务器组织是那些提供第三方服务的组织，他们可以直接影响到公司各个客户的控制环境。例子：保险和医疗索赔处理商、信托公司、应用服务提供商（ASP）、托管的安全提供商等。
• SAS70：早期最著名的由美国注册会计师协会AICPA制定，最初重点解决的是财务问题，针对执行审计和测试的目标，后来延伸到了行业之外，每个组织需要确保服务提供商为组织的数字资产提供必要的保护。
• SOC：2011年AICPA发布了一个新的服务性组织控制（SOC）审计标准框架。
  1. SOC 1 适合于财务控制
  2. SOC 2 适用于信任服务（安全性、可用性、保密性、过程完整性和隐私）
  3. SOC 3 也适用于信任服务（安全性、可用性、保密性、过程完整性和隐私）
  4. SOC 2和3之间的差异是：SOC 2报告所产生的结果提供了适用于所列出的、信任服务控制的详细数据，这不是给一般公众的。而SOC 3生成的报告细节较少，可用于一般公众性目的。
  ​

2、审计技术控制

（1）脆弱性测试

测试评估目标包括：

• 评估一个环境的真实安全状态
• 标识尽可能多的脆弱性，对每个脆弱性进行公正的评估并排定优先顺序
• 测试系统如何应对某些情况和攻击，不仅需要了解已知的脆弱性，还要了解环境中特定元素如何被滥用的原理
• 在决定测试范围并达成一致前，必须解释测试可能造成的后果
• 人员测试包括检测人员的任务
• 物理测试包括审查设施和周边保护机制
• 应使用一种自动扫描产品来标识已知的系统脆弱性​

漏洞和渗透测试的三种颜色的盒子：

• 黑盒测试：
  将被测试的系统完全不透明。这种方法最恰当的模拟了外部攻击者。
  缺点：
  它可能不会覆盖所有的内部系统，存在一些系统在审计过程中不被发现。另一个问题是在没有系统内部知识的情况下，测试人员可能会忽略一些系统信息。
• 白盒测试：
  在执行第一次扫描之前，审计师已经完全了解了系统的内部工作原理。
  缺点：无法代表外部攻击者的行为。
• 灰盒测试：
  内部工作有一部分提供给测试团队。介于黑盒和白盒2种测试之间。

（2）渗透测试

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

• 安全专业人员应获得包含授权测试范围的授权书
• 漏洞扫描
  1. 识别网络中活跃状态的主机
  2. 识别网络中活跃状态的和易攻击的服务（端口）
  3. 识别应用程序和其标识的捕获
  4. 识别操作系统
  5. 识别已发现的操作系统和应用程序的相关漏洞
  6. 识别错误配置的设置
  7. 测试主机上应用程序的使用/安全策略合规性
  8. 建立渗透测试的基础
• 渗透测试的目的是标识脆弱性，评估环境中安全机制提供的真正保护，以及了解如何报告可以的活动，但是意外事故也可能会发生。
• 渗透测试的过程
  1. 发现（搜集和收集目标信息）
  2. 枚举（执行端口扫描和资源标识方法）
  3. 脆弱性映射（在确定的系统和资源中标识脆弱性）
  4. 利用（尝试利用脆弱性进行未授权访问）
  5. 报告（向管理层提交测试报告，并提供应对措施建议）

（3）战争拨号攻击

战争拨号允许攻击者和管理者拨打大量的电话号码，以搜索可用的调制解调器。

（4）其他脆弱性类型

• 内核缺陷
  操作系统内的问题
  对策：及时打补丁
• 缓冲区溢出
  糟糕的编程实践或库中bug使输入超出程序分配的存储配额。这会重写分配到缓冲区之后的数据或程序内存，有时允许攻击者注入程序代码，这样攻击者就拥有了与被攻击程序相同的访问权限。
  对策：良好的编程实践和开发人员教育、自动化源代码扫描器、改良的程序库以及防止缓冲区溢出的强类型语言等
• 符号链接
  软连接，攻击者入侵软连接获得未授权访问。
  对策：必须编写程序和特定脚本，确保无法绕开文件的完整路径
• 文件描述符攻击
  文件描述符是许多操作系统用于表示某个进程中的开放文件的编号。
  对策：良好的编程实践和开发人员教育、自动化的源代码扫描器以及应用程序安全测试都可以减少这种脆弱性
• 竞态条件
  如果一个程序的设计方式使它处于某种易受攻击的条件，而后再设法减少那些易受攻击的条件，就会出现竞态条件。
  对策：良好的编程实践和开发人员教育、自动化的源代码扫描器以及应用程序安全测试都可以减少这种脆弱性
• 文件和目录许可
  文件目录权限问题。
  对策：文件完整性检查

（5）事后检查

一旦完成测试、解释测试结果、标识脆弱性的分类分级等工作后，管理层就应准备一本“审判书”，说明许多可以向公司成功实施攻击的方法。这是进入补救战略下一个循环的入口。

（6）日志审查

日志审查通过检查系统的日志文件，以检测各种安全事件或验证各种安全控制的有效性。

• 确保所有联网设备时钟同步（NTP）
• 防止日志被篡改
  1. 远程日志，将日志存放在一个单独的“盒子”里
  2. 单向（工）通信，各报告设备与中央日志存储库之间使用单向通信
  3. 复制，多副本存储不同位置
  4. 一次性写入介质，如果你备份的日志文件位置之一是只能被一次性写入，那么攻击者将无法篡改该数据的副本
  5. 加密散列链，使用加密散列链可以确保事件被修改或删除能够容易的被发现。（例如SHA-256）

（7）代码审查

到目前为止，我们讨论的所有安全测试都将系统视为一个黑盒子。这意味着我们只评估了外部可见的特征，而没有见到系统的内部工作。所以我们需要代码审查。

（8）接口测试

接口测试对给定的一组交换点的系统进行评估。以确保系统在交换的两端能正常运行。我们可以参考许多测试用例，最重要的原则是：接口测试的主要任务是提前设想所有的测试用例，记录它们，然后将它们插入到一个可重复的且自动化的测试引擎中。

3、审计管理控制

（1）账户管理

攻击者的一种首选技巧是获取攻击系统的“正常”的特权用户。
第一种方式：盗用现有的特权账户（可通过强身份验证削减风险）
第二种方式：创建新的特权账户（密切监控账户的新建、修改和误用来削减风险）
第三种方式：提升常规用户账户权限（密切监控账户的新建、修改和误用来削减风险）

（2）备份验证

• 数据类型
  用户数据文件：大多数人熟悉的数据类型，如文档、表格等。
  数据库：数据库与常规文件不同，它们通常将整个数据库存储在具有专用文件系统的文件中。
  邮箱数据：据估计，在一般组织中有高达75%的数据存在邮箱中。
• 验证
  1. 验证这一能力的核心是理解可能出错的事务和哪些事务需要备份。
  2. 测试数据备份
     开发各种场景，以捕获那些代表组织所面临威胁的特定事件集；
     制定计划，测试每个场景中所有关键任务的数据备份；
     利用自动化，以最小化审计师所需的工作量，以确保定期进行测试；
     最小化数据备份测试计划对业务流程的影响，以便其可以被定期执行；
     确保覆盖面，以便测试每个系统，虽然那不一定在同一测试中；
     记录各种结果，以便你能知晓什么是有效的，而什么是需要加强的；
     修复和改进你记录的任何问题。

（3）灾难恢复和业务连续性

• 测试和修订业务连续性计划
  1. 检查性测试（又称桌面检验测试）
     BCP副本分发至不同部门和职能区接受审查，确保不会遗忘或确保一些问题。
  2. 结构化的排练性测
     试各部门和职能区代表聚在一起对计划进行检查，以确保准确性。
  3. 模拟测试
     这种测试需要指定更多计划，参与更多人员。根据特定场景练习执行灾难恢复计划，这个场景用于测试每个操作和支持部门代表的反应，能提高所有参与人员的意识。
  4. 并行测试
     并行测试用于确保特定系统在异地备用设施中能充分发挥其功能。
  5. 全中断测试
     对正常操作和业务生产影响最大，在所有类型测试都已成功完成再执行，并且需要得到高层授权。要将原站点关闭并将业务处理转移到备用站点完成。
  6. 其他类型的培训
     包括急救、心肺复苏术（CPR）、如何正确使用灭火器、疏散线路、人群控制方法、紧急通信程序以及在面临各种灾难实践时如何正确的关闭设备。
  7. 应急响应
     通常，对紧急事件的最初响应会影响到最终结果。
• 维护计划
  1. 各种计划随时间业务等动态变化，也许会过时，那么如果不定期维护计划，当灾难发生时，可能会造成破坏性后果。
  2. 组织需要使用下列动作使计划保持更新
     使业务连续性成为每个业务决策的一部分；
     将维护责任整合到职位描述中；
     将维护工作表现包含在个人评估中；
     执行包括灾难恢复、连续性文档与措施的内部审计；
     进行应用计划的常规演习；
     将BCP整合到当前的变更管理过程中；
     将实际事故中得到的经验教训整合到计划中。
• BCP生命周期多数组织都不是静止的，而是不断快速变化的，组织运营的环境也是如此。所以DRP和BCP都具有生命周期，需要应对不断出现的、不可避免的影响到组织的变化。

（4）安全培训和安全意识培训

• 社会工程
  1. 网络钓鱼被称为最流行的社会工程。
  2. 针对特定个人或人群被称为鱼叉式网络钓鱼。
  3. 针对目标为高级管理人员被称为捕鲸。
• 上网安全
  1. 通常不必诱骗用户去做错事，他们会自愿沿着那条路走。
  2. 上网安全行为的最重要元素之一就是正确的使用社交媒体。
  3. 有时威胁并非是信息流出到互联网上，而是由于用户的好奇导致的。
  4. 不被用户知晓或交互的情况下，使用户下载或安装未授权的可能具有风险的应用程序。
• 数据保护
  由于用户完全可以规避控制并使数据不受保护，因此安全意识是防止此类行为的关键。
• 文化
  测试一个组织在安全意识方面的最好方法就是评估其安全文化。

（5）关键绩效和风险指标

• 关键绩效指标（KPI，key performance indicator）
  运行一个没有充分度量标准的信息安全管理系统（ISMS）可能比根本不去管理安全更加危险。
  1. 因子（ISMS的一个属性，可以描述随时间变化的值）
  2. 测量（在一个特定时间上因子的值）
  3. 基线（一个因子的任意值，一个参考点）
  4. 度量标准（通过在多个测量之间，或与基线比较而生成的派生值）
  5. 指标（描述ISMS的某些有效性的一个或多个测量的解释）
• 关键风险指标（KRI，key risk indicator）
  关键绩效指标可以告诉我们当前相对目标的位置，而关键风险指标能告诉我们当前与风险偏好的关系。

4、报告

（1）技术报告

技术报告应该比自动扫描工具的输出具有更多内容。

以下是一份好的技术审计报告所需的各种要素：

• 威胁
• 漏洞
• 利用的可能性
• 利用后的影响
• 建议措施

（2）执行摘要

凭借审计报告进入技术殿堂对技术人员来说再好不过了，但对于业务人员来说却无任何好处。撰写具有影响力的报告的下一步是：将重要的发现和建议转化为对组织高层领导来说可以理解且有意义的言语。

• 量化风险的一种方法用货币数值表示
• 我们可以认为：
  风险 = 资产的价值 X 资产损失的概率

5、管理评审

管理评审是高级组织领导层的正式会议，用于确定管理系统是否有效的实现其目标。

（1）管理评审前

管理评审应该定期进行。

（2）审查输入

各种来源将产生管理评审的输入。如内外网相关的审计结果、评审的另一个重要输入是前一次管理评审的未决问题和执行项目的清单、除了审计师和执行人员的反馈，客户的反馈也是管理评审的一个重要输入。

管理评审的最终输入是基于所有其他输入的改进建议。

在高级管理层决策过程阶段，向他们提供一系列选项通常是非常有用的，根据问题的复杂性许多安全专业人员通常会提供三到五种选择。与此同时，我们还应该提供客观的评价标准，以供管理层考虑。

（3）管理层的行动

高级管理层在考虑所有投入时，通常会问及一些非常尖锐的问题，然后决定批准、拒绝或推迟建议。领导的决定最终证明了ISMS团队的建议有多少说服力。