安全评估基础

概念、作用、安全评估标准

安全评估基本概念

什么是安全评估
针对潜在影响资产正常执行其职能的行为产生干扰或者破坏的因素进行识别、评价的过程

对安全评估的理解
狭义指对一个具有特定功能的工作系统中固有的或潜在的危险及其严重程度所进行的分析与评估，并以既定指数、等级或概率值作出定量的表示，最后根据定量值决定采取的预防或防护对策。
广义指利用系统工程原理和方法对拟建或已有工程、系统可能存在的危险性及其可能产生的后果进行综合评价和预测，并根据可能导致的事故风险的大小，提出相应的安全对策措施，以达到工程、系统安全目标的过程

风险评估是确定安全需求的重要途径！

安全评估工作内容

风险评估工作包括以下方面：

 资产梳理，资产赋值
 威胁识别
 脆弱性识别
 风险分析
 不可接受风险处置计划

确定保护的对象（保护资产）是什么？它们直接和间接价值？
资产面临哪些潜在威胁？导致威胁的问题所在？威胁发生的可能性有多大？
资产中存在哪里弱点可能会被威胁所利用？利用的容易程度又如何？
一旦威胁事件发生，组织会遭受怎样的损失或者面临怎样的负面影响？
组织应该采取怎样的安全措施才能将风险带来的损失降低到最低程序。

安全评估的价值

安全建设的起点和基础（规避、 减少、转移、接受间做正确判断）
信息安全建设和管理的科学方法（管理层和决策层得以了解组织信息安全，再去做决策）
倡导适度安全
保护网络空间安全的核心要素和重要手段
提高安全针对性。
降低安全成本。
提供适度的安全。

风险评估工具

风险评估与管理工具（基于信息安全标准，知识，模型）
一套集成了风险评估各类知识和判据的管理信息系统，以规范风险评估的过程和操作方法；或者是用于收集评估所需要的数据和资料，基于专家经验，对输入输出进行模型分析

系统基础平台风险评估工具（脆弱性扫描工具和渗透测试工具）
主要用于对信息系统的主要部件（如操作系统、数据库系统、网络设备等）的脆弱性进行分析，或实施基于脆弱性的攻击

风险评估辅助工具（入侵检测，安全审计，拓扑发现，资产收集）
实现对数据的采集、现状分析和趋势分析等单项功能，为风险评估各要素的赋值、定级提供依据

安全评估标准

• 1985年，美国国防部率先推出了《可信计算机系统评估准则》(TCSEC) ，该标准事实上成了美国国家信息安全评估标准，对世界各国也产生了广泛影响。
• 1991年欧洲英法德荷四国国防部门信息安全机构联合制定《信息技术安全评估准则》 (ITSEC)
• 1992年美国《联邦 (最低安全要求)评估准则》 (FC) ，但是不完善，没有被推行
• 1993年加拿大制定了符合本国的国情的信息安全评估标准CTCPEC
• 1996年美国倡议欧美六国七方共同制定CC标准
最新我国标准：GB/T 18336-2015
最新国际标准：ISO/IEC 15408-2013

TCSEC（可信计算机系统评估标准）

美国政府国防部（DoD）标准，为评估计算机系统内置的计算机安全功能
的有效性设定了基本要求
TCSEC用于评估，分类和选择被认为是处理，存储和检索的敏感计算机系统或分类信息。
国家安全局的国家计算机安全中心（NCSC）于1983年发布，1985年更新，作为国防部彩虹系列出版物的核心，TCSEC经常被称为橙皮书。
TCSEC已被2005年最初公布的国际标准《通用准则（CC）》所取代。

基本目标和要求
策略:强制安全策略；标记（完整性鉴别）；自由安全策略
问责:识别用户；验证用户；审核信息，追溯到人
保证:操作保证（系统架构、系统完整性等）；生命周期保证；持续保护保证，即信任机制（如防篡改）
文档:实施手册、测试文档、设计方案等

分级
D-最小保护
C-选择保护（C1、C2）
B-强制保护（B1、B2、B3）
A-验证保护（A1）

信息技术安全评估标准ITSEC

信息技术安全评估标准（Information Technology Security Evaluation Criteria ，ITSEC）
评估信息技术产品或系统安全性的一套结构化的标准
首次提出信息安全的保密性、完整性和可用性。
1990年5月首先在法国，德国，荷兰和英国出版，基于其各自国家的现有工作。经过广泛的国际审查，于1991年6月由欧洲共同体委员会在评估和认证计划中运作使用。

以超越TCSEC为目的，将安全概念分为功能与功能评估两部分
功能准则：在测定上分F1-F10共10级
1－5级对应于TCSEC的D到A
6－10级加上了以下概念：
F6：数据和程序的完整性 F7：系统可用性
F8：数据通信完整性 F9：数据通信保密性
F10：包括机密性和完整性的网络安全

评估准则：分为6级：
E1：提供功能测试 E2：配置控制和可控的分配
E3：能访问详细设计和源码 E4：详细的脆弱性分析
E5：设计与源码明显对应 E6：设计与源码在形式上一致

FC（联邦（最低安全要求）评估准则）

美国信息技术安全联邦准则(FC)
1992年12月公布，是对TCSEC的升级
引入了**保护轮廓（PP）**这一重要概念

保护轮廓包括
功能部分
开发保证部分
测评部分
分级方式与TCSEC不同，吸取了ITSEC、CTCPEC中的优点
供美国政府用，民用和商用。（不完备，没推行，但是部分被CC采纳）

CC(信息技术安全评估通用标准)

目前最全面的信息技术安全评估准则
主要思想和框架取自ITSEC和FC，充分突出“保护轮廓”，将评估过程分“功能”和“保证”两部分
CC强调将安全的功能与保障分离，并将功能需求分为九类63族，将保障分为七类29族。
**基于ISO/IEC 15408-1:2009（ GB/T 18336-1：2015）**简介和一般模型。
基于ISO/IEC 15408-2:2008（ GB/T 18336-2：2015）将安全功能分为11类67族（子类）。
基于ISO/IEC 15408-3:2008（ GB/T 18336-3：2015）将安全保证分为6类27族（子类）。

国际标准组织于1999年批准CC标准以“ISO/IEC15408-1999”编号正式列入国际标准系列！(GB/T2015年为准或15408的2013版本的为准)

GB/T 18336（CC）

我国在2008年等同采用《ISO/IEC 15408：2005 信息技术-安全技术-信息技术安全
评估标准》形成的国家标准，标准编号为GB/T 18336

结构
GB/T 18336.1-2008 简介和一般模型
定义了IT 安全评估的一般概念和原理，并提出了评估的一般模型

GB/T 18336.2-2008 安全功能要求
建立一系列功能组件作为表达TOE功能要求的标准方法

GB/T 18336.3-2008 安全保证要求
• 建立一系列保证组件作为表达TOE保证要求的标准方法，第3部分定义了PP和ST评估准则，并提出一些评估保证级别通常称为评估保证级（EAL）。

通用标准CC-通用性

国际上认同的表达IT安全的体系结构
开发者、评估者、使用者是通用的
一种评估方法评估结果国际互认的通用性
所有信息技术产品或系统均可使用的通用性
通用测试方法（CEM）
已有安全准则的总结和兼容
通用的表达方式，便于理解
灵活的架构
可以定义自己的要求扩展CC要求

GB/T 18336（CC）的目标读者

TOE（评估对象）的客户
CC从写作安排上确保评估满足用户的需求，因为这是评估过程的根本目的和理由。

TOE的开发者
为开发者在准备和协助评估产品或系统以及确定每种产品和系统要满足的安全需求方面提供支持。

TOE的评估者（第三方测评机构）
CC 包含评估者判定TOE 与其安全需求一致时所使用的准则。

通用标准CC-组成部分

CC的关键概念

评估对象（Target of Evaluation，TOE）
作为评估主体（产品、系统、子系统等）的IT产品及系统以及相关的指导性文档。

保护轮廓（PP）【（用户需求说明书，需要什么？）】
满足特定用户需求的、一类TOE的、一组与实现无关的安全要求。

安全目标（ST）【“提供什么？”、“如何实现？”】
作为指定的TOE评估基础的一组安全要求和规范。

通用标准CC-主要概念（TOE）

评估对象（Target of Evaluation，TOE）
作为评估主体的IT产品及系统以及相关的管理员和用户指南文档。
• 产品：防火墙、IDS、芯片等
• 系统：OA、操作系统、数据库、邮件系统、云平台
• 子系统：产品或系统的组成部分
• 有关文档：产品或系统的开发过程文档等。
• 有关环境等：产品或系统的运行物理、网络环境等

通用标准CC-主要概念（保护轮廓PP）

保护轮廓（ Protection Profile，PP）
满足用户需求，与实现无关的一组安全要求
表达一类产品或系统的用户需求
组合安全功能要求和安全保证要求
技术与需求之间的内在完备性
提高安全保护的针对性、有效性
安全标准
有助于以后的兼容性

通用标准CC-主要概念（保护轮廓PP）

示例

通用标准CC-主要概念（安全目标ST）
安全目标（Security Target，ST）
作为指定的TOE评估基础的一组安全要求和规范。
• IT安全目的和要求
• 要求的具体实现方案
• 一个PP（保护轮廓）可以通过多个ST（安全目标）来进行实现
• 适用于产品和系统
• 与ITSEC ST 类似

示例

通用标准CC-功能的组织结构

功能
规范IT产品和系统的安全行为，应做的事。
结构:类、族、组件

类（如用户数据保护——FDP）
类是安全要求的最高层次组合。一个类中所有成员关注同一个安全焦点，但覆盖的安全目的范围不同

子类(如访问控制——FDP_ACC）
子类是若干组安全要求的组合，这些要求共享同样的安全目的，但在侧重点和严格性上有所区别

组件（如子集访问控制——FDP_ACC.1)
组件描述一个特定的安全要求集，它是CC结构中最小的可选安全要求集

元素（如子集访问控制——FDP_ACC.1.1)
元素是安全要求组件的最小单元，也是安全机制的最小组成部分，具有原子性的特点，最低层次表达不能再分的安全要求

通用标准CC-主要概念（包，EAL）

包：为了满足一组确定的安全目的组合在一起的一组可重用的功能或保证组件（如EAL）。
IT安全目的和要求
功能或保证要求（如EAL）
适用于产品和系统

评估保证级（EAL）
第3部分中保证组件构成的包，该包代表了CC 预先定义的保证尺度上的要求的集合。
• 预定义的保证包
• 公认的广泛适用的一组保证要求
• EAL1-EAL7

通用标准CC-主要概念（EAL）

基于ISO/IEC 15408-2008（ GB/T 18336-2015）

通用标准CC-基本过程-主要因素

评估流程
pp 评估是依照 GB/T 18336.3 中的 pp 评估准则进行的 ，pp 的评估结果为"通过"或"不通过"。评估结果为"通过"的 pp 应当列入 pp 注册表中。
针对 TOE 的 ST 评估是依照 GB/T 18336.3 中的 ST 评估准则进行的。此类评估具有双重目的:首先是为了证明该 ST 是完备的、一致的、技术合理的，因而适合用来作为相应 TOE 评估的基础；其次，当某个 ST 宣称与一个 pp 一致时，证明该 ST 完全满足该要求。 ST 评估将产生在 TOE 评估框架中使用的中间结果。
TOE 评估是以一个充分完善的 ST 作为基础，依照 GB/T 18336.3 中的评估准则进行的。
TOE 的评估结果为"通过"或"不 通过"。评估结果为"通过"的 TOE 应当列入一个注册表中

CC的意义和优势

CC的意义
通过评估有助于增强用户对于IT产品的安全信心
促进IT产品和系统的安全性
消除重复的评估

优势
国际标准化组织统一现有多种准则的努力结果；
已有安全准则的总结和兼容，是目前最全面的评价准则；
通用的表达方式，便于理解
灵活的架构，可以定义自己的要求扩展CC要求

CC的局限性

CC标准采用半形式化语言，比较难以理解；
CC不包括那些与IT安全措施没有直接关联的、属于行政性管理安全措施的评估准则，即该标准并不关注于组织、人员、环境、设备、网络等方面的具体的安全措施；
CC重点关注人为的威胁，对于其他威胁源并没有考虑；
并不针对IT安全性的物理方面的评估（如电磁干扰）；
CC并不涉及评估方法学；
CC不包括密码算法固有质量的评估

信息系统安全等级保护测评

信息系统安全等级测评重要性
检测评估信息系统安全等级保护状况是否达到相应等级基本要求的过程

落实信息安全等级保护制度的重要环节
等级测评过程
测评准备活动
方案编制活动
现场测评活动
分析与报告编制活动

安全评估实施

威胁、脆弱性、资产等评估重要概念

风险评估相关要素-资产

定义：是建立对组织具有价值的信息或资源，是安全策略保护的对象。
理解：资产的价值不是以资产的经济价值来衡量， 而是由资产在这三个安全属性上的达成程度或者其属性未达成时所造成的影响来决定的。
资产价值与业务属性有关
资产价值与安全属性有关
资产价值与分类方法有关
物理 VS 逻辑；静态 VS 动态；硬件 VS 软件；有形 VS 无形；技术 VS 管理。

风险评估相关要素-威胁

可能导致对系统或组织危害的不希望事故潜在定义：可能导致对系统或组织危害的事故的外部原因。威胁可以通过威胁主体、资源、动机、途径等多种属性来描述。

要素：威胁源、动机、方式、对象、频率、程度。

分类：
人为因素和环境因素。
人为因素分为故意和非故意两种。
环境因素包括自然因素和物理因素

风险评估相关要素-脆弱性

定义：可能被威胁所利用的资产的薄弱环节。脆弱性是资产本身存在的，如果没有被相应的威胁利用，单纯的脆弱性本身不会对资产造成损害。
威胁与脆弱性关系：威胁总是要利用资产的脆弱性才可能造成危害。脆弱性识别数据应来自于资产的所有者与使用者。
脆弱性分类：包括技术或管理等方面的脆弱性。

思考：只有威胁，或只有脆弱性，能否产生风险或事件？
答案：只有威胁和脆弱性相互作用才会产生风险或事件。

风险评估相关要素-信息安全风险、安全措施

安全风险
人为或自然的威胁利用资产及管理体系中存在的脆弱性导致安全事件的发生及其对组织造成的影响。
信息安全风险只考虑那些对组织有负面影响的事件

安全措施
保护资产、抵御威胁、减少脆弱性，或降低事件影响，及打击信息犯罪的各种实践、规程和机制。
预防性措施、检测性措施、纠正性措施、威慑性措施

残余风险
采取安全措施后仍存在的风险，需要跟踪监视

风险评估要素之间的关系

风险评估途径与方式

风险评估途径
基线评估：基于基线指标要求的评估。
详细评估：基于资产及环境细节及有关方面评估。
组合评估：基线、详细评估及其他评估的综合。

安全评估方式
分 类：自评估（自查）和检查评估。
使用要求：以自评估为主，自评估和检查评估结合。
技术支持：自评估和检查评估可依托自身力量进行，也可委托第三方机构提供支持。

风险评估的常用方法【重要】

知识分析：依赖理论、知识、方法等形成等知识库。
经验方法，最重要的是信息的采集，信息源
会议讨论；
对当前的信息安全策略和相关文档进行复查；
制作问卷，进行调查；
对相关人员进行访谈；
进行实地考察。
模型分析：依据具体模型，例如，CORAS等。
定量分析：风险要素及风险值量化的风险分析。
定性分析：基于理论经验综合风险性质判定。

风险评估常用方法-定量分析

财务定量法：基于经济财务数据分析。

风险计算要素
资产价值（Asset Value，AV）
暴露因子（Exposure Factor, EF）:特定威胁对特定资产靠损失的百分比，或者说损失的程度。
单一预期损失（Single Loss Expectancy, SLE）:也称SOC（Single Occurrence Costs）,即特定威胁可能造成的潜在损失总量.
**年度发生率（ARO）
年度预期损失（Annualized Loss Expectancy, ALE）**或称作EAC（Estimated Annual Cost），表示特定资产在一年内遭受损失预期值

概念的关系
首先，识别资产并为资产赋值
通过威胁和弱点评估，评价特定威胁作用于特定资产所造成的影响，即
EF（取值在0%~100%之间）
计算特定威胁发生的频率，即ARO
计算资产的SLE；一次安全事件的资产损失。
计算资产的ALE；一年周期内风险所造成的资产损失。

定量风险分析的一种方法就是计算年度损失预期值（ALE）。计算公式如下：
年度损失预期值（ALE） = SLE x 年度发生率（ARO）
单次损失预期值（SLE） = 暴露因素（EF）x 资产价值（AV）

定量评估计算案例
§ 计算由于人员疏忽或设备老化对一个计算机机房所造成火灾的风险。
§ 假设：
• 组织在3年前计算机机房资产价值100万，当年曾经发生过一次火灾导致损失10万；
• 组织目前计算机机房资产价值为1000万；
• 经过和当地消防部门沟通以及组织历史安全事件记录发现，组织所在地及周边在5年来发生过3次火灾；
• 该组织额定的财务投资收益比是30%
§ 由上述条件可计算风险组织的年度预期损失及ROSI，为组织提供一个良好的风险管理财务清单

根据历史数据获得EF：
§ 10万÷100万×100%=10%

v 根据EF计算目前组织的SLE
§ 1000万×10%=100万

v 根据历史数据中ARO计算ALE
§ 100万×（3÷5）=60万

v 此时获得年度预期损失值，组织需根据该损失衡量风险可接受度，如果风险不可接受则需进一步计算风险的处置成本及安全收益；
§ ROSI = (实施控制前的ALE）–（实施控制后的ALE）–（年控制成本）

v 组织定义安全目标，假如组织希望火灾发生后对组织的损失降低70%，则，实施控制后
的ALE应为：
§ 60万×（1-70%）=18万
§ 年控制成本=（60-18）×30%=12.6万
§ 则：ROSI=60-18-12.8=29.4万
v 至此，组织通过年投入12.6万获得每年29.4万的安全投资收益

数据类比法：风险值类比到数据的方法
v根据风险评估矩阵图获得风险能力，故：
陨石袭击虽然损失严重，但由于属于低概率事件，因此可列为低风险，接受风险
电动车碰撞产生的影响远远低于陨石袭击，但由于属于高概率事件，因此被评价为严重风险，需要资产（受体）关注，不可接受

风险评估常用方法-定性分析

目前采用最为广泛的一种方法，基于知识、方法论、经验、能力、标准进行风险性质和程度的判定。
带有很强的主观性，往往凭借分析者的经验和直觉，或者业界的标准和惯例，为风险管理诸要素的大小或高低程度定性分级

风险分析方法—定量VS定性

风险评估实施流程及方法

风险评估的基本过程

风险评估是组织确定信息安全需求的过程，包括资产识别与评价、威
胁和弱点评估、控制措施评估、风险认定在内的一系列活动。

风险评估准备

风险评估准备是整个风险评估过程有效性的保证
组织实施风险评估是一种战略性的考虑，其结果将受到组织的业务战略、业务流程、安全需求、系统规模和结构等方面的影响。

风险评估准备工作
确定风险评估的目标
确定风险评估的范围
组建适当的评估管理与实施团队
进行系统调研
确定评估依据和方法
制定风险评估方案
获得最高管理者对风险评估工作的支持

确定风险评估的目标
根据满足组织业务持续发展在安全方面的需要、 法律法规的规定等内容，识别现有信息系统及管理上的不足，以及可能造成的风险大小。

确定风险评估的范围
风险评估范围可能是组织全部的信息及与信息处理相关的各类资产、管理机构，也可能是某个独立的信息系统、关键业务流程、与客户知识产权相关的系统或部门等。

组建适当的评估管理与实施团队
风险评估实施团队，由管理层、相关业务骨干、IT技术等人员组成风险评估小组。
评估实施团队应做好评估前的表格、文档、检测工具等各项准备工作，进行风险评估技术培训和保密教育，制定风险评估过程管理相关规定。

进行系统调研；
系统调研是确定被评估对象的过程，风险评估小组应进行充分的系统调研，为风险评估依据和方法的选择、评估内容的实施奠定基础。
调研内容至少应包括：业务战略及管理制度；主要的业务功能和要求；网络结构与网络环境，包括内部连接和外部连接；系统边界；主要的硬件、软件；数据和信息；系统和数据的敏感性；支持和使用系统的人员。
系统调研可以采取问卷调查、 现场面谈相结合的方式进行。

确定评估依据和方法
根据系统调研结果，确定评估依据和评估方法。
评估依据包括（但不仅限于）：现有国际标准、国家标准、行业标准；行业主管机关的业务系统的要求和制度；系统安全保护等级要求；系统互联单位的安全要求；系统本身的实时性或性能要求等。
据组织机构自身的业务特点、信息系统特点，选择适当的风险分析方法并加以明确，如定性风险分析、定量风险分析，或是半定量风险分析。
根据评估依据，应考虑评估的目的、范围、时间、效果、人员素质等因素来选择具体的风险计算方法，并依据业务实施对系统安全运行的需求，确定相关的判断依据，使之能够与组织环境和安全要求相适应。

制定风险评估方案
风险评估方案的目的是为后面的风险评估实施活动提供一个总体计划， 用于指导实施方开展后续工作。
风险评估方案的内容一般包括（但不仅限于）：
• 团队组织：包括评估团队成员、组织结构、角色、责任等内容；
• 工作计划：风险评估各阶段的工作计划，包括工作内容、工作形式、工
作成果等内容；
• 时间进度安排：项目实施的时间进度安排。
获得最高管理者对风险评估工作的支持
上述所有内容确定后，应形成较为完整的风险评估实施方案，得到组织最高管理者的支持、批准；
对管理层和技术人员进行传达， 在组织范围就风险评估相关内容进行培训，以明确有关人员在风险评估中的任务

资产识别

资产分类、分级、形态及资产价值评估

资产分类
标准分类：数据、软件、硬件、服务、人员、其他（ （ GB/T 20984《信息安全风险评估规范》 ） ）
维度分类：有形VS无形，物理VS逻辑，硬件VS软件，技术VS管理，静态
VS动态

资产分级
属性分级：保密性分级、完整性分级、可用性分级
业务分级：资产重要性分级

制定资产重要性分级准则
依据资产价值大小对资产的重要性划分不同的等级。资产价值依据资产在保密性、完整性和可用性上的赋值等级，经过综合评定得出。

威胁识别

类型
人为因素（故意、非故意）
环境因素（自然、物理）
要素：来源、动机、对象、方式、程度、频率。

脆弱性识别

脆弱性识别与威胁识别是何关系？
验证：以资产为对象，对威胁识别进行验证

脆弱性识别难点
三性：隐蔽性、欺骗性、复杂性

脆弱性基本分类
技术脆弱性
管理脆弱性
脆弱性要素：主体、程度、分布规模（抽样）等

确认已有的控制措施

依据三个报告
《信息系统的描述报告》、《信息系统的分析报息告》和《信系统的安全要求报告》

确认已有的安全措施，包括：
技术层面（物理、系统、网络和应用平台）的安全功能
管理层面（策略、规章和制度）的安全对策
组织层面（组织结构、岗位和人员）的安全控制
形成《已有安全措施列表》。

控制措施类型
预防性、检测性、纠正性、威慑性。举例各类措施？
在识别脆弱性的同时，评估人员应对已采取的安全措施的有效性进行确认。安全
措施的确认应评估其有效性，对有效的安全措施继续保持，以避免不必要的工作
和费用，防止重复实施。

风险分析

GB/T 20984-2007《信息安全风险评估规范》给出信息安全风险分析思路

风险值 = R（A，T，V）= R（L（T，V），F（Ia，Va ））【明确各个值表示什么】
R表示安全风险计算函数
A表示资产
T表示威胁
V表示脆弱性
Ia表示安全事件所作用的资产价值
Va表示脆弱性严重程度
L表示威胁利用资产的脆弱性导致安全事件的可能性
F表示安全事件发生后造成的损失

计算安全事件发生的可能性
安全事件的可能性=L(威胁出现频率，脆弱性)＝L(T，V )

计算安全事件发生后造成的损失
安全事件造成的损失=F(资产价值，脆弱性严重程度)＝F(Ia，Va )

计算风险值
风险值=R(安全事件的可能性，安全事件造成的损失)＝R(L(T，V)
，F(Ia，Va ))

风险结果判定（风险报告）

评估风险的等级
评估风险的等级依据《风险计算报告》，根据已经制定的风险分级准则，对所有风险计算结果进行等级处理，形成《风险程度等级列表》。
综合评估风险状况
汇总各项输出文档和《风险程度等级列表》，综合评价风险状况，形成《风险评估报告》
风险报告要素：4W要素，What风险，What等级，What影响，What处理建议。

风险处理计划

处理方式：降低、规避、转移、接受。
处理措施：对不可接受的风险应根据导致该风险的脆弱性制定风险处理计划
和选择安全措施

管理措施
技术措施

残余风险评估

实施安全措施后对措施有效性进行再评估
对于不可接受的风险选择适当安全措施后，为确保安全措施有效性，可进行再评估，以判断实施安全措施后的残余风险是否已经降低到可接受的水平。
某些风险可能在选择了适当的安全措施后， 残余风险的结果仍处于不可接受的风险范围内， 应考虑是否接受此风险或进一步增加相应的安全措施

**残余风险类型：
经过客观评价后，可接受的残余风险。
经过可行性分析，无法处理的残余风险。

残余风险处理：需进行监视、跟踪。**

风险评估文档

信息系统审计

信息系统审计概念

信息系统审计的定义
内部审计具体准则第28号—信息系统审计：第二条 本准则所称信息系统审计，是指由组织内部审计机构及人员对信息系统及其相关的信息技术内部控制和流程开展的一系列综合检查、评价与报告活动。
国家审计署的定义：计算机审计实务公告第34号，第三条 本指南所称信息系统审计，是指国家审计机关依法对被审计单位信息系统的真实性、合法性、效益性和安全性进行检查监督的活动。
国际信息系统和控制协会（ISACA）：“是一个获取并评价证据，以判断计算机系统是否能够保证资产的安全、数据的完整以及有效率的利用组织的资源并有效果的实现组织目标的过程

信息系统审计的内容
信息系统审计为了提高信息系统建设、运行过程的质量和水平。
信息系统审计为了更好的落实国家关于信息系统有关在监督管理的政策、法规和
标准的要求。
信息系统审计提高企业的竞争力。
信息系统审计中的一般控制审计包括总体审计、信息安全技术控制审计和信息安
全管理控制审计；项目审计包括建设经济评价、建设管理评价、效益评价。

信息系统审计的作用
从审计目标看，信息系统审计主要是检查和促进被审计单位信息系统及其内部控
制的真实性、正确性、完整性、安全性、可靠性和经济性等各类目标要素。
审计内容看，信息系统审计中的一般控制审计包括信息安全技术控制审计和信息
安全管理控制审计。

信息系统审计工作流程

计划：确定审计的目标和范围
现场工作和文件：收集数据并进行访谈以帮助分析潜在风险
问题发现和验证：潜在问题清单并验证
开发解决方案：与客户合作制定解决每个问题的行动计划
报告起草和执行
问题跟踪

信息系统审计流程

S1:确定审计目的
S2:确定审计范围
S3:明确审计依据
S4:组建审计小组
S5:实施现场审计
S6:报告审计发现
S7:后续审计活动
或参考：《计算机审计实务公告第34号的通知》第9条

第一步骤：确定审计目的

审计目的：审计工作的出发点
满足监管部门的要求
满足信息安全国际国内标准的要求
满足机构自身信息安全工作要求

第二步骤：确定审计范围

审计范围：影响审计工作量的一个重要因素
从组织机构考虑，如仅对个别部门实施审计，或者在组织全部范围实施审计
从业务和系统角度考虑，如仅对核心业务系统实施审计，或者仅对某业务实施审计等

第三步骤：明确审计依据

审计目的和范围不同，依据就不同

第四步骤：组建审计小组

审计组长：由审计组织的管理者任命。
审计组成员：包括正式成员和审计助理成员。
审计决策或决定：由组长和正式成员共同决定，人员总数为奇数，不能为偶数，最好不用超过7个人（经验值）。
审计人员：避免关联性、进行培训。
参考：审计署关于印发信息系统审计指南—计算机审计实务公告第 34 号的通知

第五步骤：实施现场审计

依据审计方案和计划执行，审计过程中好要做好变更控制

现场审计
访谈、查看、审阅、检查和测试等

文档化
对所发现的审计证据应进行详细记录，并与被审计单位人员进行
现场确认。
工作底稿等

第六步骤：报告审计发现

审计依据和现场收集的审计证据对比后的结果
正面结果：符合了审计依据的要求
负面结果：被审计对象尚未满足审计依据要求

审计发现报告
与被审计单位沟通审计发现，并达成一致
形成书面报告

第七步骤：后续审计活动

审计建议书
风险提醒函
在规定的时间为对不符合项进行跟踪审计

审计类型与报告

专业人员了解信息系统安全在更广泛的业务环境中的作用，并能够将其传达给技术和非技术观众

SAS70
由美国注册会计师协会（AICPA）制定的用于处理服务机构的审计标准
提供了一套基于服务组织（如提供IT服务）标准可以展示其内部控制的有效性

SOC
取代SAS70并解决更广泛的特定用户需求，例如解决安全性，隐私保护和可用性问题

SAS70
2002年实施“萨班斯法案”404条款以来，SAS 70报告变得尤为重要，因为公司可以将其作为内部控制有效性的证明。
SAS70服务审核员报告有两种类型：类型1和类型2.两种类型都包括对服务组织的内部控制在某个时间点的审计的描述和意见。但只有第2类报告包含服务审计人员在本报告所述期间控制是否有效运行的结果，以确保实现控制目标。

SOC
SOC报告最常见地涵盖了12个月的活动的设计和有效性，每年持续的覆盖率从财务报告或治理的角度来满足用户需求。
报告涵盖设计和运行有效性的时间段通常被称为**“类型2”报告**，而涉及设计的时间报告通常被称为**“类型1”报告**

审计技术控制

脆弱性测试
渗透测试
战争驾驶
其他漏洞类型
日志
合成交易
滥用案例测试
代码审查
接口测试

审计管理控制

账户管理
备份验证
灾难恢复和业务连续性
安全培训和安全意识培训
关键绩效和风险指标