在线图片，重点见png。

1、基本概念

“Security Assessment and Testing”

• 安全评估和测试包含广泛的现行和基于时间点的测试方法用于确定脆弱性及其相关风险。

T&E的基本目标

• T&E能衡量系统和能力开发进展
  • T&E的专长就是中对系统生命周期在开发过程提供系统强度和弱点的初期认知
• 为协助在开发、生产、运营和维护系统能力过程中的风险管理提供相应的知识。
• 能够在部署系统之前识别技术的、操作的和系统缺陷以便开发适当的及时的纠正行为。

T&E策略

• 测试和评估战略的内容是具有应用于获取/开发流程、所提供的能力要求以及技术驱动所需能力的功能。
• 倾向于
  • 管理风险所需认知
  • 验证模型和仿真的经验数据
  • 技术性能和系统成熟度的测试
  • 运维效能、适应性和生存能力的确定
• 目标
  • 识别、管理和降低风险

2、评估和测试策略

T&E策略

• 策略的作用
  • 管理风险所需认知
  • 验证模型和仿真的经验数据
  • 技术性能和系统成熟度的测试
  • 运维效能、适应性和生存能力的确定。
• 系统工程师和安全专家需要做的事情
  • 与主办单位一块建立或评价用于支持程序获取/开发的T&E策略；
  • 提供能深度管理风险的T&E的方法；
  • 监控T&E流程以及可能需要的变更；
  • 评价测试计划和程序是否适用于开发测试或运行测试，并提供建议；
  • 进一步被希望理解获取/开发程序的背后的理由以用于建立和执行T&E策略；
  • 期望理解T&E测试的具体活动，如interoperability testing, 信息保障测试；
• 企业需要建立工作小组
  • 这个小组通常被称为T&E集成产品团队，由T&E专家、客户用户代表和其他利益相关者组成；
  • T&E策略是活动文档，该小组负责在需要时进行更新；
  • 该小组需要确保T&E流程包含获取策略以及系统满足基于用于能力的操作要求；

日志评审

• 日志概念
  • 日志就是发生在组织系统和网络中的事件记录。
• 日志与计算机安全有关
  • 如路由日志分析有利于识别安全事故、策略违背、欺诈行为和操作问题等。
• 日志作用
  • 执行审计和取证调查；
  • 支持内部调查；
  • 建立基线；
  • 识别运行趋势以及发现长期问题；
• 日志管理问题
  • 需要平衡有限的日志管理资源和持续产生的日志数据
  • 日志的生产和存储
    • 不同的日志来源
    • 不一致的日志内容、格式以及时间戳等
    • 日志数据的大量生成
  • 需要保护日志的完整性、机密性和可用性
  • 确保安全、系统和网络管理员定期有效的分析日志数据。
• 日志管理的方针和程序
  • 为建立和维护成功的日志管理活动，组织应开发执行日志管理的标准流程
  • 定义日志需求和目标
    • 开发清晰定义日志管理活动的强制要求和推荐要求
      • 包括日志的生成、传递、存储、分析和废弃
    • 集成和支持日志管理要求和推荐
    • 管理层应提供必要的支持
  • 日志需求和建议应与实施和维护日志所需的资源和细节分析技术一块生成
  • 原始日志的保护
    • 将网络流量日志的拷贝发送到中心设备
• 优化日志管理
  • 优化日志和需求，基于组织风险减少的感知以及执行日志管理所需资源和预期的时间。
  • 建立日志管理的职责和角色
• 建立和维护日志管理架构
  • 日志管理架构包含硬件、软件、网络和介质用于生成、传输、存储、分析和处置日志。
  • 设计日志管理框架时应考虑管理框架现在和未来的需求以及整个组织的独立日志源。
• 为所有员工的日志管理职责提供适当支持
  • 系统的管理员应获得足够的支持；
  • 包括信息传播、提供培训、提供问题解答的联系点、提供具体的技术指南、提供相应的工具和文档等。
• 标准日志管理流程
  • 日志管理员职责
    • 监控日志状态
    • 监控日志轮转和归档流程
    • 检查日志系统补丁，获得、测试及部署补丁
    • 确保日志来源系统保持时钟同步
    • 当策略或技术变更时，必要的话，重新配置日志
    • 记录和报告日志异常
    • 确保日志整合存储，例如安全信息和事件管理系统（SIME）
  • 日志管理流程
    • 配置日志源、执行日志分析、启动对识别的认知的响应和管理日志的长期存储。
  • 日志来源
    • 防病毒软件、IDS和IPS系统、远程访问软件、Web代理、漏洞管理软件、验证服务器、路由器、防火墙、网络访问控制NAC/网络访问保护NAP服务器、操作系统事件和审计记录
    • 基于应用的日志
      • 客户端请求和服务求响应
      • 账号信息
      • 使用信息
      • 重保的操作活动
  • 挑战
    • 日志的分布属性、日志格式的不一致以及日志的容量都构成日志管理的挑战
    • 必须保护日志的机密性、完整新和可用性
    • 系统和网络管理员
      • 需要分析日志
      • 无法有效进行日志分析
        • 没有收到良好的培训
        • 没有工具支撑
    • 日志分析常常是响应型的 reactive
    • 许多日志分析需要实时或近乎实时的

合约交易

(Synthetic Transactions)

• 真实用户监控Real User Monitoring (RUM)
  • Web监控方法，旨在捕获或分析Web或应用上每个用户的每笔交易
  • 又称为real-user measurement真实用户测量, real-user metrics真实用户指标, or end-user experience monitoring (EUM)最终用户体验监控
  • passive monitoring 被动监控的方式
    • 依赖于Web监控服务持续获得系统活动，追踪其可用性、功能和敏感度。
  • 监控模式
    • bottom-up forms
      • 为重新重构用户体验而捕获服务端信息；
    • top-down client-side RUM
      • 客户端RUM，能直接看到用户如何与应用进行交互及其体验方式
      • 关注站点速度和用户的满意度，提供关于优化应用组件和提升所有的性能的深入视角。
• 综合性能监控Synthetic performance monitoring
  • proactive monitoring 主动或预响应监控的方式
    • 包含使用外部代理（agent）运行脚本交易的方式而不是Web应用。
    • 这些脚本依照典型用户体验，如用户搜索、查看产品、登录和支付等方式来评估用户体验。
    • 综合监控是轻量级和低水平的代理方式，但很Web浏览器有必要运行发生在页面上处理JavaScript, CSS, and AJAX调用。
  • 并不追踪真实的用户会话
  • 完全控制客户端
    • 不像沙盒JAVA脚本方式驱动的RUM，细节的获得可以更客观
  • 监控方式
    • 站点监控
    • 数据库监控
    • TCP端口监控
• 合约交易的益处
  • 24 X 7的监控应用程序的可用性
  • 了解远程站点是否可达
  • 理解第三方服务对业务应用系统造成的性能影响
  • 监控Saas应用的性能和可用性
  • 测试使用SOAP、REST或其他Web服务的B2B Web站点
  • 监控关键数据库的可用性
  • 衡量服务级别协议SLAs
  • 再低业务流量时段作为对真实用户监控的补偿
  • 建立性能基线，进行性能趋势分析

代码审核和测试

• 多数漏洞来源
  • 不恰当的编程模式，如缺少检查影响用户的数据，SQL注入
  • 安全基础设施的误配：访问控制权限过大或脆弱的加密配置；
  • 安全基础设施的功能错误：访问控制强制设施本身不限制系统的访问；
  • 实施流程的逻辑错误：比如用户下订单而不用支付
• 测试技术
  • 黑盒测试 VS 白盒测试
  • 动态测试 VS. 静态测试
  • 手动测试 VS 自动测试
• 安全测试考虑
  • 攻击面
  • 申请类型
  • 结果质量和可用性
  • 支持的技术
  • 性能和资源利用
• 规划和设计阶段
  • 架构安全评审
    • 先决条件：架构模型
    • 优点：验证架构偏离安全标准
  • 威胁建模
    • 先决条件：业务用例或使用场景
    • 识别威胁、及其影响以及具体到软件产品开发过程中的潜在控制措施。
    • STRIDE模型
• 在应用程序开发期间
  • 静态代码分析和手动代码评审
    • 为寻找弱点而不执行应用而分析应用源代码。
    • 先决条件：应用源代码
    • 优点：检测不安全的编程、过时的代码库以及错误配置
  • 静态二进制代码分析和手工二进制审查
    • 对已编译的应用进行分析来发现弱点，并不执行应用。
    • 不精确且不提供修复建议。
• 可在测试环境中执行
  • 手动或自动渗透测试
    • 像攻击者一样发送数据并发现其行为。
    • 优点：在部署的应用上识别大量的弱点；
  • 自动漏洞扫描程序
    • 测试使用已知不安全的系统组件或配置的应用。
    • 设定预攻击模式，分析系统指纹。
    • 优点：检测已知漏洞
  • Fuzz Testing Tools模糊测试工具
    • 好处：检测可能对安全至关重要的应用程序崩溃（例如，由缓冲区溢出引起的）。
    • 发送随机数据（常常远比应用所期望的更大块）到应用输入渠道来引起应用的崩溃。

系统运维阶段

• 软件测试特点
  • 推荐使用被动安全测试技术监测系统行为和分析系统日志
  • 软件维护过程中，补丁的测试非常重要
    • 补丁需要进行彻底的安全测试
  • 软件测试有其限制，不可能100%测试完成
    • 测试所有程序功能和所有程序代码并不意味着程序 100% 正确！
  • 测试计划和测试用例应尽可能早的在软件开发阶段进行开发
• 软件测试原则
  • 预定义的预期测试结果。
  • 一个好的测试用例很可能会暴露一个错误。
  • 成功的测试是发现错误的测试。
  • 独立于编码。
  • 使用应用程序（用户）和软件（编程）专业知识。
  • 测试人员使用与编码人员不同的工具。
  • 不能只测试一般情况
  • 测试文档允许重复使用，并在后续审查期间独立确认测试结果的通过/失败状态。
• “白盒”测试 代码级别的测试 （Code-based testing）
  • 软件的安全测试一般起始于单元级别的测试和结束于系统级别测试
  • 结构测试水平
  • 结构化测试
    • 结构化测试用于测试“死亡”代码，这些代码在程序运行过程永远不会使用；
    • 结构化测试主要是放在模块级别的测试；
    • 结构化测试级别可以用被测试的软件结构的百分比来作为指标来衡量；
  • 测试用例基于从源代码、细节设计规格说明和其他开发文档中获得的知识；
  • 常见的结构覆盖
    • 语句覆盖率，
    • Decision (Branch) Coverage判断覆盖率
    • Condition Coverage 条件覆盖率，
    • Multi-Condition Coverage
    • Loop Coverage循环覆盖率
    • Path Coverage补丁覆盖率
    • Data Flow Coverage 数据流覆盖率
• 功能性测试 “黑盒”测试 （functional testing or blackbox testing）
  • 基于定义或基于规格的测试Definition-based or specification-based testing被称为功能性测试或黑盒测试
  • 测试用例基于软件产品具体要做什么来定义的；
  • 测试用例的主要挑战是预期用途和程序功能以及程序的内外部接口；
  • 功能性测试应用于任意级别的软件测试，从单元测试到系统级别的测试
  • 功能性测试类型
    • Normal Case普通用例
    • Output Forcing 输出要求，
    • Robustness 鲁棒性
    • Combinations of Inputs输入组合
    • 弱点
      • 很难将结构化和功能化测试的完成标准与软件产品的可靠性链接起来；
• 统计测试方法 statistical testing
  • 提供高结构化覆盖率
  • 从基于运行环境（软件产品的预期使用、危险使用或恶意使用）定义的分布来生成随机数据；
  • 生成大量测试数据并用于覆盖到特别领域或所关注的地方，提供增加识别单个和极其罕见的运行状况的可能性，这些运行状况没有被设计者和测试人员所预知；
• 软件变更测试
  • 原因
    • 调试发现的问题并进行纠正；
    • 新的或变化的需求；
    • 发现设计的修改能更高效或有效实施；
  • 目的
    • 更改已正确实施
    • 没有对其他部分产生不利影响
    • Regression analysis and testing 回归分析和测试能够提供共好的保障
      • 回归分析：确定变更的影响，基于相关文档（软件规格说明、设计规格、源代码等）的评审，也是为识别运用必要的回归测试；
      • 回归测试：运用之前程序执行正确的测试用例，比对现有结果和以前的结果发现软件变化的非预期结果。
• 严格和完整的测试
  • 单元测试
  • 集成测试
  • 系统级测试■ 安全和隐私性能（例如，加密功能、安全日志报告）； ■ 性能问题（例如，响应时间、可靠性测量）； ■ 对压力条件的响应（例如，在最大负载下的行为、 ■ 内部和外部安全功能的操作； ■ 恢复程序的有效性，包括灾难恢复； ■ 可用性； ■ 与其他软件产品的兼容性； ■ 每个定义的硬件配置中的行为； ■ 和文档的准确性。
• V字模型
  • 验收测试
  • 系统测试
  • 集成测试
  • 单元测试
• 测试注意事项
  • 系统测试将呈现在特定环境中软件产品的行为；
  • 测试程序、测试数据和测试结果应以获得允许通过/失败决策的方式记录；
  • 企业的软件产品是复杂的，软件产品的测试需要保持一致性、完整性和有效性；
  • 软件维护任务和硬件维护不一样，硬件有预防性维护措施而软件没有；
  • 需要有效验证变更
• 系统维护的其他的任务
  • Software Validation Plan Revision软件验证计划修订，
  • Anomaly Evaluation异常验证，
  • Problem Identification and Resolution Tracking问题识别和解决跟踪，
  • Proposed Change Assessment请求变更评估
  • Task Iteration任务迭代，
  • Documentation Updating文档更新

负向测试/滥用用例测试

• 正向测试方法
  • 确定您的应用程序按预期工作
  • 确定应用按照所期待的方式进行工作，如果在正向测试中发现错误则失败
• 负向测试
  • 确保您的应用程序可以优雅地处理无效输入或意外的用户行为。
  • 负向测试的典型场景
    • 填充所需字段
    • 数据和字段间的通信
    • 允许的字符数
    • 允许数据边界和限制
    • 合理数据
    • Web会话测试

接口测试

（interface test）

• 不同于集成测试
  • 主要检查应用或系统开发的不同组件彼此是否同步；
  • 从技术层面接口测试主要用于确定不同功能诸如数据在系统的不同元素中是否按照设计进行传输。
  • 用于确保软件的质量

渗透测试

• 应所有者的要求模拟攻击一个网络及其系统的过程
• 渗透测试类型屈居于组织机构、它的安全目标和管理层的目标
• 渗透测试报告应该提交给管理层
• 应签署授权测试范围的授权-免死金牌
• 步骤
  • 发现，搜集和收集目标的相关信息
    • 举例：发现系统的版本
    • 举例：dig
  • 枚举，之心端口扫描和资源标识方法
    • 举例:识别可用账号
  • 脆弱性映射，在确定的系统和资源中标识脆弱性
  • 利用，尝试利用脆弱性进行未授权访问
  • 向管理层报告，想管理层提交报告和安全建议
• 分类
  • 黑盒测试，零了解，渗透团队在不了了解测试目标的情况下测试
  • 灰盒测试，在了解一些与测试目标相关的信息上测试
  • 白盒测试，了解目标的本质的基础上测试

漏洞描述

• CVE
• CVSS
• SCAP
  • SCAP组件
    • 常见漏洞和纰漏 CVE
    • 通用配置枚举 CCE
    • 通用漏洞评分系统 CVSS
    • CPE
    • XCCDF
    • 子主题 6

3、收集安全流程数据

信息安全持续监控

Information security continuous monitoring（ISCM）

• ISCM
  • 用于定义现行信息安全、漏洞和危险的意识用于支持组织信息安全风险决策；
  • 用于支持跨组织的信息安全监控的任何努力和过程必须开始与高层领导定义的复杂ISCM策略；
• ICSM策略
  • 是建立在清晰理解组织风险容忍度并帮助企业设置优先级和管理整个组织的风险一致性；
  • 包含度量指标来提供在所有组织层面的安全状态的真实含义；
  • 确保所有安全控制的持续有效;
  • 验证由组织使命/业务职能、国家法律法规、指南、指南标准所驱动的信息安全要求的符合性;
  • 所有组织的IT资产都被告知并协助维护资产安全的可见性;
  • 确保组织系统和环境变更的知识和控制；
  • 保持威胁和脆弱性的意识.
• 推荐指南 (SP) 800-53r4,
  • 使用自动化工具和技术进行监控的良好候选者
• 特点
  • ISCM方案的建立收集依据预设测量指标的数据，部分通过已实施的安全控制来利用信息变更更加容易。
  • 组织范围的风险监控不能有效的依靠单独的手工流程或单独的自动化流程来获得：
• 开发ISCM策略流程
  • 基于风险容忍度定义ISCM策略以维护资产的可见性、漏洞的意识、威胁信息的更新以及使命/业务影响；
  • 建立ISCM方案确定测量指标、状态监控频率、控制评估频率并建立ISCM技术架构；
  • 实施ISCM方案和收集用于测量、评估和报告所需的安全相关信息。尽可能的自动收集、分析和报告；
  • 分析所有收集的数据并报告发现，确定恰当的响应。有必要收集其他信息来澄清或补充现有监控数据；
  • 通过技术、管理和操作的活动来响应发现，这些活动包括削减活动或接受，转移/共享，或者避免/拒绝等。
  • 评审和更新ISCM方案，调整ISCMC策略和成熟的测量能力来增加资产的可见性和脆弱性意识，更多的启用组织信息安全架构并以数据驱动的控制，增加组织的弹性。
• 测量指标定义及内容
  • 测量指标包含所有来自评估和监控并由自动化工具以及手工程序所产生的安全相关信息，并组织成有意义的信息来支持决策和报告要求。
  • 测量指标应由维持或改进安全态势的具体目标所驱动。
  • 测量指标开发系统级别的数据使得使命/业务背景或组织风险管理变得有意义；
  • 测量指标从不同时间获得的安全相关信息并带有不同级别的延迟。
  • 测量指标的例子■ 发现和修复的漏洞的数量和严重程度 ■ 未经授权的访问尝试次数 ■ 配置基线信息 ■ 应急计划测试日期和结果 ■ 目前正在接受意识培训要求的员工人数 ■ 组织的风险容忍度阈值 ■ 与给定项目相关的风险评分
• 测量指标建立原则 NIST SP 800-137
  • Security Control Volatility 安全控制波动
  • System Categorizations/Impact Levels 系统分类/影响的水平
  • Security Controls or Specific Assessment Objects Providing Critical Functions 安全控制或特定评估对象所提供的关键功能
  • Security Controls with Identified Weaknesses 已识别弱点的安全控制
  • Organizational Risk Tolerance 组织风险容忍度
  • Threat Information 威胁信息
  • Vulnerability Information 漏洞信息
  • Risk Assessment Results 风险评估结果
  • Reporting Requirements 通报要求
  • 测量指标变更的因素■ 核心任务或业务流程的变化； ■ 企业架构的重大变化（包括添加或删除系统）； ■ 组织风险承受能力的变化； ■ 威胁信息的变化； ■ 漏洞信息的变化； ■ 信息系统内的变化（包括分类/影响级别的变化）； ■ 状态报告输出趋势分析； ■ 新的法律或法规； 和 ■ 报告要求的变化。
• 作为组织风险管理框架 Risk Management Framework (RMF) 的关键步骤
  • 提供组织官方按需访问安全相关信息的能力，进行及时风险管理决策包括授权决策。

4、内部和第三方审计

审计需求

• 法律发规需求
  • 如美国联邦信息安全法案（FISMA Federal Information Security Management Act）要求联邦机构每年至少对组织的信息安全体系进行一次自我审计和独立的第三方审计；
  • 信息安全专家需要理解法律标准中所概述的要求以提供保护，但极少做到完全的保护或信息系统的风险管理；
  • 信息安全专家必须确保恰当的范围和裁剪为目标系统在正确的级别上获得适当数量的控制
• 业务的驱动
  • 组织常更新外包服务商的监控流程以及管理与外包的风险；
  • 历史上，许多组织常借鉴Statement on Auditing Standards (SAS) 70 reports 审计准则说明以获得对外包活动的安慰，然而SAS 70关注财务报告内部控制(ICOFR)，而不关注系统可用性和安全。
  • SAS 70报告已在2011退休，取而代之的是SOC（Service Organization Control)报告；
• 合规
  • 联邦信息安全管理法 (FISMA)

内部审计

• 组织内部自己的审计团队，以实现持续改进您的组织的安全态势
• 优点
  • 熟悉组织内部工作流
  • 工作效率高
  • 能够准确找出最有问题的点
  • 可以使审计工作灵活，管理层可不断变换审计团队对应审计方案
• 缺点
  • 存在利益冲突的可能，妨碍客观性

第三方审计

• 优点
  • 审计多种不同信息系统，经验丰富
  • 审计团队和组织内部不存在利益关系，更容易保持客观中立
• 缺点
  • 成本高
  • 即使签订了保密协议，仍需要增加资源来管理他们并监督他们的工作
  • 缺乏对组织内部运作了解，可能花费较长的时间进行测试

SOC 报告选项

• SOC 报告类型
  • “Type 2” reports
    • 一段时间内包含设计和运维有效性的报告
    • 来自服务提供商的该系统的类型 2 报告
    • 与用户对财务报告的内部控制有关。
  • “Type 1” reports
    • 涵盖设计的时间点报告
• SOC 2/SOC 3 原则
  • SOC 2/SOC 3 报告使用可信服务原则和准则
    • 由美国注册会计师协会AICPA 和加拿大特许会计师协会开发；
    • 提供超越财务报告内部控制（ICOFR）；
    • 原则和准则具体定义安全性、可用性、机密性、处理完整性和隐私；
    • 可以基于服务提供商及其用户的需求，采用模块化的方式便于SOC 2/SOC 3报告能够覆盖一个或多个原则；
  • SOC 1报告
    • 与SOC 1/SOC 2报告相反的地方是，SOC1 报告需要服务提供商描述他的系统并定义控制目标和控制，这些与财务报告内部控制有关；
    • SOC 1报告通常不覆盖那些与用户ICOFR报告无关的服务和控制。
• 审计阶段
  • 审计准备阶段■ 定义审计范围和总体项目时间表 ■ 通过与管理层讨论确定现有或所需的控制， 和审查可用的文件 ■ 执行准备情况审查以确定需要管理层关注的差距 ■ 传达优先建议以解决任何已识别的差距 ■ 在开始正式审计阶段之前确认差距已经消除 ■ 召开工作会议，讨论替代方案和补救计划 ■ 确定最有效的审计和报告方法来满足服务提供商的外部要求
  • 审计阶段■ 提供整体项目计划 ■ 现场作业前完成前期数据收集，加快审核流程 ■ 进行现场会议和测试 ■ 对收集到的信息进行完整的非现场分析 ■ 每周报告项目状态和任何已识别的问题 ■ 提供一份报告草稿以供管理审查以及最终报告的电子版和纸质版 ■ 向管理层提供一份内部报告，其中包含任何总体意见和建议以供考虑
• SOC 2/SOC 3 标准
  • 对于首次 SOC 2 报告，从安全原则开始通常是最实用的方法。
  • 安全准则■ IT 安全政策 ■ 安全意识与沟通 ■ 风险评估 ■ 逻辑访问 ■ 物理访问 ■ 安全监控 ■ 用户认证 ■ 事件管理 ■ 资产分类与管理 ■ 系统开发与维护 ■ 人员安全 ■ 配置管理 ■ 变更管理 ■ 监控和合规
  • 可用性准则■ 可用性政策 ■ 备份和恢复 ■ 环境控制 ■ 灾难恢复 ■ 业务连续性管理
  • 机密性准则■ 保密政策 ■ 输入的机密性 ■ 数据处理的保密性 ■ 输出的机密性 ■ 信息披露（包括第三方） ■ 系统开发中的信息保密
  • 完整性准则■ 系统处理完整性策略 ■ 输入、系统处理和输出的完整性、准确性、及时性和授权 ■ 信息溯源到处置
  • 隐私准则■ 选择和同意 ■ 收藏 ■ 使用和保留 ■ 访问 ■ 向第三方披露 ■ 质量 ■ 监控和执行
  • 安全专家需要对以下方面多关注
    • 基于云的ERP服务由于提供财务报告过去也能够提供SAS 70报告，就像持续提供SOC1 报告一样，可能也需要提供SOC2/SOC3安全和可用性报告；
    • 许多数据中心托管服务商受限于物理和环境安全控制过去完成SAS 70的检查，也需要提供SOC2报告；
    • 对于IT系统管理，包含对一组用户提供一般IT服务也和对具体用户提供定制化服务一样，SOC1/SOC2报告也能适用；
• SOC报告使用的观点
  • 过去，多数组织使用外包服务要求SAS 70报告，但是仅从财务角度出发，许多用户开始关注安全、可用性而后隐私；
  • 尽管有许多其他的关注IT/安全的保障工具（WebTrust, SysTrust, ISO 27001, etc）可以提供更好的保障，但是用户仍然持续要求SAS 70报告，而且服务提供商以及他们的审计人员也推荐；
  • 作为SAS 70报告的替代，使用SOC报告；
  • SOC1报告在2011年开始被许多服务商用于核心财务处理服务；
  • IT服务提供商没有影响或存在间接影响到用户的财务系统，则使用SOC2报告；
  • SOC3报告一般用于向大范围用户通报其保障级别而不需要披露细节控制和测试结果；
  • 一些组织可能联合使用SOC2/SOC3报告来面向不同的群体。

5、审计管理控制

账号管理

• 添加账号
• 修改账号
• 暂停账号

备份验证

• 用户文件
• 数据库
• 邮件数据

灾难恢复和业务连续性测试

• 测试和修改业务连续性计划

安全培训和安全意识培训

关键绩效和风险指标

报告

• 技术报告
• 行政摘要

管理评审

• 管理评审是高级组织领导者决定管理体系是否有效

战争拨号

• 管理员通过战争拨号的方式测试组织内未经授权安装的调制解调器，对组织中随意安装者进行在教育

6、评估软件安全的有效性

子主题 2

Swa