安全评估与测试
一.基本概念
1.基本目标
安全评估与测试实现以下目标：
- 衡量系统和能力开发进展；
- 专长就是对系统生命周期在开发过程提供系统强度和弱点的初期认知；
- 为协助在开发、生产、运营和维护系统能力过程中的风险管理提供相应的知识；
- 能够在部署系统之前识别技术的、操作的和系统缺陷以便开展适当的、及时的纠正行为。
安全评估和测试包含广泛的现行和基于时间点的测试方法用于确定脆弱性及其相关风险。
2.策略
测试和评估战略的内容是具有应用于获取/开发流程、所提供的能力要求以及技术驱动所需能力的功能。
二.审计策略
1.审计需求
1)法律法规需求
符合相关法律法规的要求
例如我国的等保要求（每年一次）、分级保护要求。
美国联邦信息安全法案（FISMA Federal Information Security Management Act）要求联邦机构每年至少对组织的信息安全体系进行一次自我审计和独立的第三方审计；
信息安全专家需要理解法律标准中所概述的要求以提供保护，但极少做到完全的保护或信息系统的风险管理；
信息安全专家必须确保恰当的范围和裁剪为目标系统在正确的级别上获得适当数量的控制
2)合规
等级保护、分级保护
3)业务驱动
提升核心竞争力、减少开支和更快速的部署应用新的应用功能。
组织常更新外包服务商的监控流程以及管理与外包的风险。
2.安全评估目标
确定测试的范围：评估的网络范围是多少？
是否需要查看用户的相关工作？如密码、文件和日志条目或用户行为
评估哪些信息的机密性、完整性和可用性
涉及哪些隐私问题
如何评估流程，以及评估到什么程度
3.流程
4.审计团队
1）内部审计
- 优点
- 熟悉组织的内部运转
- 工作效率高
- 评估工作更加灵活，随时开始工作
- 可实现持续改进安全态势
- 缺点
- 手段和技术受限
- 可能存在利益冲突，有些问题不愿意暴露
2)外部审计
- 优点
- 经验丰富
- 不了解内部组织目标和政治，客观，保持中立
- 缺点
- 成本高
- 对系统不了解，需要花费时间去了解
- 仍然需要处理增加的资源来组织他们并监督他们的工作
5.其他要求
必须执行审计的机构：保险业、托管数据中心、应用系统提供商。
必须执行审计和测试，以确保每一方持有的确实真实
相关法案
美国注册会计协和（AICPA)制订70号审计准则 SAS70，重点关注财务问题。
服务性组织控制审计标准 SOC
- SOC1 适用于财务控制
- 与SOC 2/SOC 3报告相反的地方是，SOC1 报告需要服务提供商描述他的系统并定义控制目标和控制 与财务报告内部控制有关；
- SOC1报告通常不覆盖那些与用户ICOFR报告无关的服务和控制。
- SOC1报告在2011年开始被许多服务商用于核心财务处理服务；
- SOC2 适用于信任服务，一般不面对公众
- SOC3 面对公众，报告细节少
SOC2和SOC3一般包括安全性、可用性、保密性、过程完整性和隐私
三.审计技术控制
1.T&E策略
管理风险所需认知
验证模型和仿真的经验数据
技术性能和系统成熟度的测试
运维效能、适应性和生存能力的确定。
2.脆弱性测试
脆弱性测试需要由具有资深安全背景、极其可靠的员工完成，可能存在误报的可能。
1)目标
- 评估一个环境的真实安全状态
- 标识尽可能多的脆弱性，对每个脆弱性进行公正的评估并排定优先顺序
- 测试系统如何应对攻击情况
- 测试前必须了解测试造成的后果
2)测试类别
人员测试：检查员工的任务（社会工程），审查员工策略和措施
物理测试：审查设施和周边保护机制
系统和网络测试：审查系统安全漏洞
3)系统测试类型
黑盒测试：被测试系统被视为完全不透明
白盒测试：了解被测试系统内部情况
灰盒测试：介于黑盒和白盒测试之间
3.漏洞扫描
- 识别网络中处于活动状态的主机
- 识别主机上处于活动状态和易攻击的服务
- 识别应用程序和其标识的捕获
- 识别操作系统
- 识别已发现的操作系统和应用程序的相关漏洞
- 识别错误的配置
- 测试主机上应用程序使用的安全策略
- 建立渗透测试基础
4.渗透测试
渗透测试一般由高级管理者发起并签署授权、明确测试范围，最终报告提交管理层审批。
测试团队应该从基本的用户级访问开始，适当地模拟各种攻击。
目的是评估组织机构抵御某种攻击的能力，以及暴露环境中存在的任何弱点。
不仅限于信息技术，包括物理安全、人员安全
针对性测试是外部顾问和内部员工共同对特别感兴趣的区域进行集中测试
1)渗透测试流程
a)发现：搜素和收集目标的相关信息
b)枚举：执行端口扫描和资源标识方法
c)脆弱性映射：在确定的系统和资源中标识脆弱性
d)利用：尝试利用脆弱性进行未授权访问
e)向管理层报告：向管理层提交测试结果报告文件，并提供应对措施建议
5.日志审查
1)日志作用
- 执行审计和取证调查；
- 支持内部调查；
- 建立基线；
- 识别运行趋势以及发现长期问题。
2)挑战
- 需要平衡有限的日志管理资源和持续增长的日志数据；
- 需要平衡日志分析实时要求和处理能力；
- 需要保护日志的完整性、机密性和可用性 ；
- 确保安全、系统和网络管理员定期有效的分析日志数据。
3)日志管理的方针和程序
定义日志需求和目标：开发清晰定义日志管理活动的强制要求和推荐要求，包括日志的生成、传递、存储、分析和废弃。
管理层应提供必要的支持
4)日志安全
首先关注日志的完整性，确保所有联网设备的时间标准化，确保时间源一致，做好日志防篡改。
日志防篡改技术
- 远程日志：将日志保存在远程
- 单工通道：单向隔离网闸，推荐方式
- 复制：多个副本
- 一次性写入介质
- 加密散列链
5)最佳实践
- 适当的优化日志管理
- 监理日志管理策略和程序
- 建立和维护安全日志管理基础设施
- 为所有员工的日志管理提供适当的支持
6)措施
建立和维护日志管理架构：日志管理架构包含硬件、软件、网络和介质用于生成、传输、存储、分析和处置日志。
设计日志管理框架时应考虑管理框架现在和未来的需求以及整个组织的独立日志源。
日志管理员/审计管理员职责
- 监视日志源状态
- 监视日志活动和归档过程
- 检查日志软件安全性
- 确保时钟同步
- 根据需要重新配置日志记录
- 记录和报告日志设置
- 日志整合管理
6.综合事务/合成交易
1)真实用户监控 （Real Transactions）
常适用于关键的系统，例如对外网站。是用户真实情况的监控。
Web监控方法，旨在捕获或分析Web或应用上每个用户的每笔交易，英文缩写RUM，又称为real-user measurement真实用户测量, real-user metrics真实用户指标, or end-user experience monitoring (EUM)最终用户体验监控
2)合成交易(Synthetic Transactions)
使用外部代理（agent）运行脚本交易的方式而不是Web应用。
综合监控是轻量级和低水平的代理方式。Web浏览器有必要运行发生在页面上处理JavaScript, CSS, and AJAX调用。
并不追踪真实的用户会话。
7.误用案例
用例：系统和环境间交互的抽象方法。
误用例：来自对系统怀有恶意的人员视角的用例。
正向测试方法：确定应用按照所期待的方式进行工作，如果在正向测试中发现错误则失败
负向测试：确保应用可以妥善处理无效输入或非预期用户行为。
8.代码审查
1)流程
- 识别要审查的代码
- 团队领导组织检查，确保每个人可以访问正确的源代码
- 每个人都准备好通过阅读代码和做记录进行检查
- 所有明显的错误都被离线整理
- 召开审查会议
- 修正代码
2）防御性编程
- 把所有内容都认为不可信
- 许多漏洞，都是因为缺少输入的验证造成的
3）代码评审和测试
软件漏洞的常见原因
- 不恰当的编程模式，如缺少检查影响用户的数据，SQL注入（输入验证）
- 安全基础设施的误配：访问控制权限过大或脆弱的加密配置；
- 安全基础设施的功能错误：访问控制强制设施本身不限制系统的访问；
- 实施流程的逻辑错误：比如用户下订单而不用支付
测试技术
- 白盒（结构性测试） vs. 黑盒测试（功能性测试）
- 动态测试 VS. 静态测试
- 手工 vs. 自动化
9.接口测试
检查应用或系统开发的不同组件彼此是否同步.
用于确定不同功能诸如数据在系统的不同元素中是否按照设计正确进行传输。
用于确保软件的质量
10.软件测试
软件维护过程中，补丁的测试非常重要：补丁需要进行彻底的安全测试
软件测试有其限制，不可能100%测试完成
测试计划和测试用例应尽可能早的在软件开发阶段进行开发
代码级别的测试：软件的安全测试一般起始于单元级别的测试和结束于系统级别测试
结构化测试 (“白盒”测试) 开箱测试
- 结构化测试主要是放在模块级别的测试
- 结构化测试级别可以用被测试的软件结构的百分比来作为指标来衡量
测试用例基于从源代码、细节设计规格说明和其他开发文档中获得的知识
回归分析：确定变更的影响，基于相关文档 （软件规格说明、设计规格、源代码等）的评审， 也是为识别运用必要的回归测试。
回归测试：运用之前程序执行正确的测试用例， 比对现有结果和以前的结果发现软件变化的非预期结果。
测试注意事项
- 系统测试将呈现在特定环境中软件产品的行为；
- 测试程序、测试数据和测试结果应以获得允许通过/失败决策的方式记录；
- 企业的软件产品是复杂的，软件产品的测试需要保持一致性、完整性和有效性；
- 软件维护任务和硬件维护不一样，硬件有预防性维护措施而软件没有；
- 需要有效验证变更
其他的维护任务
- 软件验证计划修订
- 异常验证
- 问题识别和解决跟踪
- 请求变更评估
- 任务迭代
- 文档更新
11.其他脆弱性类型
1）内核层存在漏洞
对策：确保安全补丁到操作系统足够的测试后，及时部署在环境中保持尽可能小的漏洞窗口。
2）缓冲区溢出
对策：良好的编程实践和开发教育，自动扫描器的源代码， 增强编程库，采用强语言类型不允许缓冲区溢出。
3）符号链接
黑客重新定向符号链接，从而达到非授权访问的目的。
对策：在编写程序（尤其是脚本）时，规避文件的完整路径
4）文件描述攻击
文件描述符是许多操作系统用来表示进程中打开文件的数字，某些文件描述符数是通用的，对所有程序都有相同的含义.。 如果程序不安全地使用文件描述符，可能会导致攻击者利用程序特权将意外的输入提供给程序，或导致输出到意外的地方
对策：良好的编程实践和开发教育，自动化源代码扫描仪和应用程序安全测试都是减少这种类型的漏洞的方法。
5）竞态条件 （多进程和多线程环境下）
在执行程序前未消除环境的脆弱性因素。会导致攻击者读取或写入意外数据或执行未经授权的命令。
对策：良好的编程实践和开发教育，自动化源代码扫描仪和应用程序安全测试
6）父进程创建子进程
文件和目录权限。不适当的文件或目录权限
对策：文件完整性检查，还应检查预期的文件和目录的权限
四.审计管理控制
1.账户管理
- 添加账户
- 修改账户
- 暂停账户
2.备份管理
不要将数据备份到存放原始数据的同一设备上
确保备份在我们需要时能按预定的方式运行
验证方法
- 测试数据备份情况
- 分析组织可能面临的威胁各种场景
- 开发一个计划来测试每个场景中所有关键任务数据备份
- 利用自动化，最大限度地减少审计人员的工作量，确保测试定期发生
- 尽量减少数据备份测试计划对业务流程的影响，以便它可以定期执行
- 确保覆盖范围，使每一个系统进行测试，但不一定在同一个测试中。
- 记录结果，这样你就知道什么是工作，什么是需要工作的
- 修正或完善你记录的任何问题。
3.灾难恢复和业务连续性
1）测试
核查性测试（Checklist Test ）：副本被分发至不同部门和职能区域接受审查，也称桌面检验测试
结构化排练测试（Structured Walk-Through Test）：各部门或职能区的代表聚在一起对计划进行检查，以保证它的准确性。
模拟测试（Simulation Test ）：根据一个特定的场景练习执行灾难恢复计划。确认关键系统是否能够在备用处理站点恢复。直到数据在备份站点恢复为止。
并行测试（Parallel Test ）：用于确保特定系统在异地备用设施中心能充分发挥功能，移到备用场所进行测试。备用站点的运行结果和主站点的运行结果进行比对。
全中断测试（Full-Interruption Test ）：将原始站点关闭将业务处理转移到备用站点。
2）应急响应
对紧急事件的最初响应会影响到最终结论，是指定好的行动计划，用于帮助人们在危急情况下更好地应付遭到的破坏
处理步骤：1.先抢救人员 2.顺序关闭系统 3.事态稳定后和新闻媒体交涉
3）维护计划
保持计划最新
4.安全培训和安全意识培训
安全培训：一种或一组技能，针对特定人群
安全意识培训：了解安全问题，面向所有人
5.关键绩效和风险指标
1）关键绩效指标（KPI）
- 衡量目前情况进展程度
- 当前相对目标的位置
- ISO 27004 概述了衡量安全控制和过程性能的流程
- 面向现在
2）关键风险指标（KRI）
- 衡量未来情况会差到什么程度
- 面向未来
6.报告
技术报告主要包括如下内容：
- 威胁
- 脆弱性
- 利用的可能性
- 建议措施
7.管理评审
管理评审是高级组织领导者决定信息安全管理系统是否有效地实现其目标的正式会议。
管理评审应周期性开展，否则将使检查风险变主动为被动。
会议的频率也应与执行前一次评审的决定所需时长同步。
审查的输入：
- 内、外部审计结果
- 前一次管理评审的未解决问题和执行项目清单
- 客户的反馈
五.收集日志
收集安全流程数据，信息安全持续监控
- 作为组织风险管理框架 Risk Management Framework (RMF) 的关键步骤；
- 提供组织官方按需访问安全相关信息的能力，进行及时风险管理决策包括授权决策；
- 用于定义现行信息安全、漏洞和危险的意识用于支持组织信息安全风险决策；
- 用于支持跨组织的信息安全监控的任何努力和过程必须开始与高层领导定义的复杂ISCM策略。
ISCM策略
- 是建立在清晰理解组织风险容忍度并帮助企业设置优先级和管理整个组织的风险一致性；
- 包含度量指标来提供在所有组织层面的安全状态的真实含义；
- 确保所有安全控制的持续有效;
- 验证由组织使命/业务职能、国家法律法规、指南、指南标准所驱动的信息安全要求的符合性;
- 所有组织的IT资产都被告知并协助维护资产安全的可见性;
- 确保组织系统和环境变更的知识和控制；
- 保持威胁和脆弱性的意识.
特点
- ISCM方案的建立收集依据预设测量指标的数据，部分通过已实施的安全控制来利用信息变更更加容易。
- 组织范围的风险监控不能有效的依靠单独的手工流程或单独的自动化流程来获得
开发ISCM策略流程
- 基于风险容忍度定义ISCM策略以维护资产的可见性、漏洞的意识、威胁信息的更新以及使命/业务影响；
- 建立ISCM方案确定测量指标、状态监控频率、控制评估频率并建立ISCM技术架构；
- 实施ISCM方案和收集用于测量、评估和报告所需的安全相关信息。尽可能的自动收集、分析和报告；
- 分析所有收集的数据并报告发现，确定恰当的响应。有必要收集其他信息来澄清或补充现有监控数据；
- 通过技术、管理和操作的活动来响应发现，这些活动包括削减活动或接受，转移/共享，或者避免/拒绝等.
- 评审和更新ISCM方案，调整ISCMC策略和成熟的测量能力来增加资产的可见性和脆弱性意识，更多的启用组织信息安全架构并以数据驱动的控制，增加组织的弹性。
测量指标 Metrics
测量指标定义及内容
- 测量指标包含所有来自评估和监控并由自动化工具以及手工程序所产生的安全相关信息，并组织成有意义的信息来支持决策和报告要求；
- 测量指标应由维持或改进安全态势的具体目标所驱动；
- 测量指标开发系统级别的数据使得使命/业务背景或组织风险管理变得有意义；
- 测量指标从不同时间获得的安全相关信息并带有不同级别的延迟。
测量指标建立原则 NIST SP 800-137
- 安全控制波动
- 系统分类/影响的水平
- 安全控制或特定评估对象所提供的关键功能
- 已识别弱点的安全控制
- 组织风险容忍度
- 威胁信息
- 漏洞信息
- 风险评估结果
- 通报要求
作为组织风险管理框架 Risk Management Framework (RMF) 的关键步骤。
提供组织官方按需访问安全相关信息的能力， 进行及时风险管理决策包括授权决策。
结合实践经验，收集日志并分析最难的几点：
- 日志不规则，定义的字段无规律，无论是字段的含义还是字段的类型、大小各个产品都没有统一的标准，带来数据收集后的清洗难度加大
- 大量的日志标识成为运维人员进行标识的另一个困境。大数据的分析的前提是对数据分类，而分类的需要高度抽象的知识
- 日志之间的关联性，需要非常高的综合认知技能，也就代理今天大部分SIEM系统实施不好的一个主要原因。
审计技术控制是通过使用IT资产来实现的安全控制。测试的是对那些我们在风险管理流程中所识别的风险的降低能力。
网络时间同步使用NTP协议，使用UDP的123端口，最多有16层，第0层最高，例如原子钟、GPS、无线电
审计管控控制主要是通过策略或流程来实现。
<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">
