《ITSS认证IT服务工程师培训教材》_试用版_2011_0311--信息安全与技术（7）
干货推荐：ITSS题库
中国ITSS白皮书2.0【第二版】PDF
ITSS服务项目经理培训
ITSS服务项目经理培训——2-基本概念及方法
ITSS服务项目经理培训——3-IT服务设计
ITSS服务项目经理培训——4-IT服务转换
ITSS服务项目经理培训——5-IT服务运营(3)
ITSS服务项目经理培训——6-IT服务改进
ITSS服务项目经理培训——7-IT服务项目类别
ITSS服务项目经理培训——9-IT服务项目管理知识体系(1)
ITSS服务项目经理培训——10-IT服务项目群管理
3.7 风险评估
3.7.1 风险评估基础
风险评估（Risk Assessment） 是指在风险事件发生之前或之后（但还没有结束），该事件给人们的生活、生命、财产等各个方面造成的影响和损失的可能性进行量化评估的工作。即，风险评估就是量化测评某一事件或事物带来的影响或损失的可能程度。
风险评估的主要任务包括：
[*] 识别组织面临的各种风险
[*] 评估风险概率和可能带来的负面影响
[*] 确定组织承受风险的能力
[*] 确定风险消减和控制的优先等级
[*] 推荐风险消减对策
在风险评估过程中，有几个关键的问题需要考虑：
[*] 要确定保护的对象（或者资产）是什么？它的直接和间接价值如何？
[*] 资产面临哪些潜在威胁？导致威胁的问题所在？威胁发生的可能性有多大？
[*] 资产中存在哪些弱点可能会被威胁所利用？利用的容易程度又如何？
[*] 一旦威胁事件发生，组织会遭受怎样的损失或者面临怎样的负面影响？
[*] 组织应该采取怎样的安全措施才能将风险带来的损失降低到最低程度？
解决以上问题的过程，就是风险评估的过程。
3.7.2 如何进行风险评估
风险评估的三种可行途径
在风险管理的前期准备阶段，组织已经根据安全目标确定了自己的安全战略，其中就包括对风险评估战略的考虑。所谓风险评估战略，其实就是进行风险评估的途径，也就是规定风险评估应该延续的操作过程和方式。
风险评估的操作范围可以是整个组织，也可以是组织中的某一部门，或者独立的信息系统、特定系统组件和服务。影响风险评估进展的某些因素，包括评估时间、力度、展开幅度和深度，都应与组织的环境和安全要求相符合。组织应该针对不同的情况来选择恰当的风险评估途径。目前，实际工作中经常使用的风险评估途径包括基线评估、详细评估和组合评估三种。
基线评估
如果组织的商业运作不是很复杂，并且组织对信息处理和网络的依赖程度不是很高，或者组织信息系统多采用普遍且标准化的模式，基线风险评估（Baseline Risk Assessment）就可以直接而简单地实现基本的安全水平，并且满足组织及其商业环境的所有要求。
采用基线风险评估，组织根据自己的实际情况（所在行业、业务环境与性质等），对信息系统进行安全基线检查（拿现有的安全措施与安全基线规定的措施进行比较，找出其中的差距），得出基本的安全需求，通过选择并实施标准的安全措施来消减和控制风险。所谓的安全基线，是在诸多标准规范中规定的一组安全控制措施或者惯例，这些措施和惯例适用于特定环境下的所有系统，可以满足基本的安全需求，能使系统达到一定的安全防护水平。组织可以根据以下资源来选择安全基线：
[*] 国际标准和国家标准，例如BS 7799-1、ISO 13335-4；
[*] 行业标准或推荐，例如德国联邦安全局IT 基线保护手册；
[*] 来自其他有类似商务目标和规模的组织的惯例。
当然，如果环境和商务目标较为典型，组织也可以自行建立基线。
基线评估的优点是需要的资源少，周期短，操作简单，对于环境相似且安全需求相当的诸多组织，基线评估显然是最经济有效的风险评估途径。当然，基线评估也有其难以避免的缺点，比如基线水平的高低难以设定，如果过高，可能导致资源浪费和限制过度，如果过低，可能难以达到充分的安全，此外，在管理安全相关的变化方面，基线评估比较困难。
基线评估的目标是建立一套满足信息安全基本目标的最小的对策集合，它可以在全组织范围内实行，如果有特殊需要，应该在此基础上，对特定系统进行更详细的评估。
详细评估
详细风险评估要求对资产进行详细识别和评价，对可能引起风险的威胁和弱点水平进行评估，根据风险评估的结果来识别和选择安全措施。这种评估途径集中体现了风险管理的思想，即识别资产的风险并将风险降低到可接受的水平，以此证明管理者所采用的安全控制措施是恰当的。
详细评估的优点在于：
[*] 组织可以通过详细的风险评估而对信息安全风险有一个精确的认识，并且准确定义出组织目前的安全水平和安全需求；
[*] 详细评估的结果可用来管理安全变化。当然，详细的风险评估可能是非常耗费资源的过程，包括时间、精力和技术，因此，组织应该仔细设定待评估的信息系统范围，明确商务环境、操作和信息资产的边界。
组合评估
基线风险评估耗费资源少、周期短、操作简单，但不够准确，适合一般环境的评估；详细风险评估准确而细致，但耗费资源较多，适合严格限定边界的较小范围内的评估。基于此实践当中，组织多是采用二者结合的组合评估方式。
为了决定选择哪种风险评估途径，组织首先对所有的系统进行一次初步的高级风险评估，着眼于信息系统的商务价值和可能面临的风险，识别出组织内具有高风险的或者对其商务运作极为关键的信息资产（或系统），这些资产或系统应该划入详细风险评估的范围，而其他系统则可以通过基线风险评估直接选择安全措施。
这种评估途径将基线和详细风险评估的优势结合起来，既节省了评估所耗费的资源，又能确保获得一个全面系统的评估结果，而且，组织的资源和资金能够应用到最能发挥作用的地方，具有高风险的信息系统能够被预先关注。当然，组合评估也有缺点：如果初步的高级风险评估不够准确，某些本来需要详细评估的系统也许会被忽略，最终导致结果失准。
风险评估的常用方法
在风险评估过程中，可以采用多种操作方法，包括基于知识（Knowledge-based）的分析方法、基于模型（Model-based）的分析方法、定性（Qualitative）分析和定量（Quantitative）分析，无论何种方法，共同的目标都是找出组织信息资产面临的风险及其影响，以及目前安全水平与组织安全需求之间的差距。
在基线风险评估时，组织可以采用基于知识的分析方法来找出目前的安全状况和基线安全标准之间的差距。
基于知识的分析方法又称作经验方法，它牵涉到对来自类似组织（包括规模、商务目标和市场等）的“最佳惯例”的重用，适合一般性的信息安全社团。采用基于知识的分析方法，组织不需要付出很多精力、时间和资源，只要通过多种途径采集相关信息，识别组织的风险所在和当前的安全措施，与特定的标准或最佳惯例进行比较，从中找出不符合的地方，并按照标准或最佳惯例的推荐选择安全措施，最终达到消减和控制风险的目的。
3.7.3 风险评估应贯穿于信息系统整个生命周期
风险评估应贯穿于信息系统生命周期的各阶段中，以便各阶段进行风险的防范和处置。信息系统生命周期各阶段中涉及的风险评估的原则和方法是一致的，但由于各阶段实施的内容、对象、安全需求不同，使得风险评估的对象、目的、要求等各方面也有所不同。具体而言，在规划设计阶段，通过风险评估以确定系统的安全目标；在建设验收阶段，通过风险评估以确定系统的安全目标达成与否；在运行维护阶段，要不断地实施风险评估以识别系统面临的不断变化的风险和脆弱性，从而确定安全措施的有效性，确保安全目标得以实现。因此，每个阶段风险评估的具体实施应根据该阶段的特点有所侧重地进行。有条件时，应采用风险评估工具开展风险评估活动。
规划阶段的风险评估
规划阶段风险评估的目的是识别系统的业务战略，以支撑系统安全需求及安全战略等。规划阶段的评估应能够描述信息系统建成后对现有业务模式的作用，包括技术、管理等方面，并根据其作用确定系统建设应达到的安全目标。
本阶段评估中，资产、脆弱性不需要识别；威胁应根据未来系统的应用对象、应用环境、业务状况、操作要求等方面进行分析。评估着重在以下几方面：
[*] 是否依据相关规则，建立了与业务战略相一致的信息系统安全规划，并得到最高管理者的认可；
[*] 系统规划中是否明确信息系统开发的组织、业务变更的管理、开发优先级；
[*] 系统规划中是否考虑信息系统的威胁、环境，并制定总体的安全方针；
[*] 系统规划中是否描述信息系统预期使用的信息，包括预期的应用、信息资产的重要性、潜在的价值、可能的使用限制、对业务的支持程度等；
[*] 系统规划中是否描述所有与信息系统安全相关的运行环境，包括物理和人员的安全配置，以及明确相关的法规、组织安全策略、专门技术和知识等。
[*] 规划阶段的评估结果应体现在信息系统整体规划或项目建议书中。
设计阶段的风险评估
设计阶段的风险评估需要根据规划阶段所明确的系统运行环境、资产重要性，提出安全功能需求。设计阶段的风险评估结果应对设计方案中所提供的安全功能符合性进行判断，作为采购过程风险控制的依据。
本阶段评估中，应详细评估设计方案中对系统面临威胁的描述，将使用的具体设备、软件等资产列表，以及这些资产的安全功能需求。对设计方案的评估着重在以下几方面：
[*] 设计方案是否符合系统建设规划，并得到最高管理者的认可；
[*] 设计方案是否对系统建设后面临的威胁进行了分析，重点分析来自物理环境和自然的威胁，以及由于内、外部入侵等造成的威胁；
[*] 设计方案中的安全需求是否符合规划阶段的安全目标，并基于威胁的分析，制定信息系统的总体安全策略；
[*] 设计方案是否采取了一定的手段来应对系统可能的故障；
[*] 设计方案是否对设计原型中的技术实现以及人员、组织管理等方面的脆弱性进行评估，包括设计过程中的管理脆弱性和技术平台固有的脆弱性；
[*] 设计方案是否考虑随着其他系统接入而可能产生的风险；
[*] 系统性能是否满足用户需求，并考虑到峰值的影响，是否在技术上考虑了满足系统性能要求的方法；
[*] 应用系统（含数据库）是否根据业务需要进行了安全设计；
[*] 设计方案是否根据开发的规模、时间及系统的特点选择开发方法，并根据设计开发计划及用户需求，对系统涉及的软件、硬件与网络进行分析和选型；
[*] 设计活动中所采用的安全控制措施、安全技术保障手段对风险的影响。在安全需求变更和设计变更后，也需要重复这项评估。
设计阶段的评估可以以安全建设方案评审的方式进行，判定方案所提供的安全功能与信息技术安全技术标准的符合性。评估结果应体现在信息系统需求分析报告或建设实施方案中。
实施阶段的风险评估
实施阶段风险评估的目的是根据系统安全需求和运行环境对系统开发、实施过程进行风险识别，并对系统建成后的安全功能进行验证。根据设计阶段分析的威胁和制定的安全措施，在实施及验收时进行质量控制。
基于设计阶段的资产列表、安全措施，实施阶段应对规划阶段的安全威胁进行进一步细分，同时评估安全措施的实现程度，从而确定安全措施能否抵御现有威胁、脆弱性的影响。实施阶段风险评估主要对系统的开发与技术/产品获取、系统交付实施两个过程进行评估。
开发与技术/产品获取过程的评估要点包括：
[*] 法律、政策、适用标准和指导方针：直接或间接影响信息系统安全需求的特定法律；影响信息系统安全需求、产品选择的政府政策、国际或国家标准；
[*] 信息系统的功能需要：安全需求是否有效地支持系统的功能；
[*] 成本效益风险：是否根据信息系统的资产、威胁和脆弱性的分析结果，确定在符合相关法律、政策、标准和功能需要的前提下选择最合适的安全措施；
[*] 评估保证级别：是否明确系统建设后应进行怎样的测试和检查，从而确定是否满足项目建设、实施规范的要求。
[*] 系统交付实施过程的评估要点包括：
[*] 根据实际建设的系统，详细分析资产、面临的威胁和脆弱性；
[*] 根据系统建设目标和安全需求，对系统的安全功能进行验收测试；评价安全措施能否抵御安全威胁；
[*] 评估是否建立了与整体安全策略一致的组织管理制度；
[*] 对系统实现的风险控制效果与预期设计的符合性进行判断，如存在较大的不符合，应重新进行信息系统安全策略的设计与调整。
本阶段风险评估可以采取对照实施方案和标准要求的方式，对实际建设结果进行测试、分析。
运行维护阶段的风险评估
运行维护阶段风险评估的目的是了解和控制运行过程中的安全风险，是一种较为全面的风险评估。评估内容包括对真实运行的信息系统、资产、威胁、脆弱性等各方面，分别介绍如下：
[*] 资产评估：在真实环境下较为细致的评估。包括实施阶段采购的软硬件资产、系统运行过程中生成的信息资产、相关的人员与服务等，本阶段资产识别是前期资产识别的补充与增加；
[*] 威胁评估：应全面地分析威胁的可能性和影响程度。对非故意威胁导致安全事件的评估可以参照安全事件的发生频率；对故意威胁导致安全事件的评估主要就威胁的各个影响因素做出专业判断；
[*] 脆弱性评估：是全面的脆弱性评估。包括运行环境中物理、网络、系统、应用、安全保障设备、管理等各方面的脆弱性。技术脆弱性评估可以采取核查、扫描、案例验证、渗透性测试的方式实施；安全保障设备的脆弱性评估，应考虑安全功能的实现情况和安全保障设备本身的脆弱性；管理脆弱性评估可以采取文档、记录核查等方式进行验证；
[*] 风险计算：根据本标准的相关方法，对重要资产的风险进行定性或定量的风险分析，描述不同资产的风险高低状况。
运行维护阶段的风险评估应定期执行；当组织的业务流程、系统状况发生重大变更时，也应进行风险评估。重大变更包括以下情况（但不限于）：
[*] 增加新的应用或应用发生较大变更；
[*] 网络结构和连接状况发生较大变更；
[*] 技术平台大规模的更新；
[*] 系统扩容或改造；
[*] 发生重大安全事件后，或基于某些运行记录怀疑将发生重大安全事件；
[*] 组织结构发生重大变动对系统产生了影响。
废弃阶段的风险评估
当信息系统不能满足现有要求时，信息系统进入废弃阶段。根据废弃的程度，又分为部分废弃和全部废弃两种。
废弃阶段风险评估着重在以下几方面：
[*] 确保硬件和软件等资产及残留信息得到了适当的处置，并确保系统组件被合理地丢弃或更换；
[*] 如果被废弃的系统是某个系统的一部分，或与其他系统存在物理或逻辑上的连接，还应考虑系统废弃后与其他系统的连接是否被关闭；
[*] 如果在系统变更中废弃，除对废弃部分外，还应对变更的部分进行评估，以确定是否会增加风险或引入新的风险；
[*] 是否建立了流程，确保更新过程在一个安全、系统化的状态下完成。
本阶段应重点对废弃资产对组织的影响进行分析，并根据不同的影响制定不同的处理方式。对由于系统废弃可能带来的新的威胁进行分析，并改进新系统或管理模式。对废弃资产的处理过程应在有效的监督之下实施，同时对废弃的执行人员进行安全教育。 信息系统的维护技术人员和管理人员均应该参与此阶段的评估。
3.7.4 风险处理
风险处理是风险评估之后的风险管理的主要步骤之一，它是选择和实施合适的安全措施，防范和降低风险，将风险始终控制在可接受的范围内。
风险处理方式主要有规避、转移、降低和接受四种方式：
[*] 规避方式。通过不使用面临风险的资产来避免风险。比如，在没有足够安全保障的信息系统中，不处理特别敏感的信息，从而防止敏感信息的泄漏。再如，对于只处理内部业务的信息系统，不使用互联网，从而避免外部的有害入侵和不良攻击；
[*] 转移方式。通过将面临风险的资产或其价值转移更安全的地方来避免或降低风险。比如，在本机构不具备足够的安全保障的技术能力时，将信息系统的技术体系（即信息载体部分）外包给满足安全保障要求的第三方机构，从而避免技术风险。再如，通过给昂贵的设备上保险，将设备损失的风险转移给保险公司，从而降低资产价值的损失；
[*] 降低方式。通过对面临风险的资产采取保护措施来降低风险。保护措施可以从构成风险的五个方面（即威胁源、威胁行为、脆弱性、资产和影响）来降低风险。比如，采用法律的手段制裁计算机犯罪（包括窃取机密信息，攻击关键的信息系统基础设施，传播病毒、不健康信息和垃圾邮件等），发挥法律的威慑作用，从而有效遏制威胁源的动机；采取身份认证措施，从而抵制身份假冒这种威胁行为的能力；及时给系统打补丁（特别是针对安全漏洞的补丁），关闭无用的网络服务端口，从而减少系统的脆弱性，降低被利用的可能性；
[*] 接受方式。接受风险是选择对脆弱性不采取任何主动措施，接受风险可能带来的结果。采取不对风险进行处理的前提是：确定了信息系统的风险等级，评估了风险发生的可能性以及带来的潜在破坏，分析了使用每种处理措施的可行性，并进行了较全面的成本效益分析，认定某些功能、服务、信息或资产不值得保护。
在风险处理阶段，针对评估所发现的安全风险及改进意见，按照高风险优先处置的原则，结合已有安全措施制定风险处置计划、改进方案并推动实施：
[*] 由风险评估项目责任主体或者被评估单位组织实施；
[*] 根据安全性和经济性平衡原则，并考虑现有技术、人员等条件限制，确定可以改进的风险要点；
[*] 制定改进工作计划，明确工作目标、任务描述，任务分解，明确相关部门职责和具体责任人、时间安排、项目风险及规避措施；
[*] 将处置计划、改进方案报上级审核、审批和备案，风险处置计划和改进方案核准下达后，予以实施，并将实施结果进行备案。
[*] 风险处置工作完成后，进行改进工作有效性评估，找出残余风险，确定所需要的安全管理措施，并监督执行。
本章从物理层、网络层、系统层、应用层、数据层和管理层等不同层次分别介绍了不同的信息安全技术来进行安全保护。主要例举的安全技术包括：密码技术和应用、常见网络安全技术、恶意代码防护技术、系统和应用安全、数据备份和恢复风险评估等。但要真正实现信息安全，三分技术七分管理，更重要的是加强信息安全意识的培养。IT服务工程师应在加强理论知识的同时，结合案例场景，加强信息安全能力和技能，为客户建立安全的运维服务同时，为公司赢得信誉和满意度。
返回到首页 《ITSS认证IT服务工程师培训教材》_试用版_2011_0311连载http://ITIL-foundation.cn/thread-36464-1-1.html
ITSS、培训、服务、资格、评估、ITSS培训师、ITSS评估师、实施ITSS、ITSS符合性、ITSS服务工程师、ITSS服务项目经理、ITSS标准、ITSS咨询、ITSS工具、IT服务监理、ITSS体系、ITSS服务质量、评价、指标、运维、治理、咨询、ITSS出版物、ITSS产品、服务监理工具、服务质量评价工具、标准符合性评估工具、服务管理工具、服务治理工具、系统监控工具、辅助决策分析、服务支持管理、基础设施监控、ITSS基础教材、ITSS标准、ITSS服务人员培训教材、标准化、专业化、人员（People）、流程（Process）、技术（Technology）和资源（Resource），简称PPTR、规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision），简称PIOIS、服务交付规范、资源要求、外包管理、服务交付、分类、代码、服务指南、通用要求、指标体系、ITSS落地实践交流-QQ群：21542747
页:
[1]