|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
风险管理规划是定义如何实施风险管理活动的过程。风险管理规划非常重要，它可以确保风险管理的程度、类型和可见度与风险以及项目对组织的重要性相匹配。另外，风险管理规划还可为风险管理活动安排充足的资源和时间，并为评估风险奠定一个共同认可的基础。
|
|
|
|
风险管理规划在项目构思阶段就应开始，并在项目规划阶段的早期完成。
|
|
|
|
|
|
|
|
可能影响风险管理规划的企业环境因素包括组织对风险的态度和承受力。它们代表组织愿意和能够承受的风险的程度。
|
|
|
|
|
|
组织可能设有既定的风险管理方法，如风险分类、概念和术语的通用定义、标准模板、角色和职责、决策授权水平等。
|
|
|
|
|
|
项目范围说明书能让人们清楚地了解与项目及其可交付物有关的各种可能性，并建立一个框架，以便人们了解最终可能需要多大程度的风险管理。
|
|
|
|
|
|
|
|
|
|
项目团队需要举行规划会议来制订风险管理计划。参会者可包括项目经理、相关项目团队成员和干系人、组织中负责风险管理规划和应对活动的人员，以及其他相关人员。
|
|
|
|
|
|
|
|
.确定用于风险管理的成本种类和进度活动，并将其分别纳入项目的预算和进度计划中；
|
|
|
|
|
|
|
|
.根据具体项目需要来“剪裁”组织中有关风险种类和术语定义等的通用模板，如果组织中缺乏所需使用的模板，会议也可能要制订这些模板。
|
|
|
|
|
|
|
|
风险管理计划描述在项目中如何组织和执行风险管理活动，作为项目管理计划的一部分，包含以下内容：
|
|
|
|
|
|
.角色与职责。确定风险管理计划中每项活动的领导者和支持者以及风险管理团队成员，并明确其职责。
|
|
|
|
|
|
|
|
.风险类别。组织可使用预先准备好的分类框架，它可能是一个简易分类清单，或风险分解结构（RBS）。RBS是按风险类别和子类别来排列已识别的项目风险的一种层级结构，用来显示潜在风险的所属领域和产生原因。
|
|
|
|
.风险概率和影响的定义。需要对风险的概率和影响划分层次来确保实施定性风险分析过程的质量和可信度。
|
|
|
|
.概率影响矩阵。进行风险优先排序的典型方法是使用查询表或概率影响矩阵。根据概率和影响的各种组合，把风险划分为高、中、低级别，以便进行相应的风险应对规划。通常由组织设定概率影响矩阵。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
没有绝对安全的环境，每个环境都有一定程度的漏洞和风险。风险是指某种破坏或损失发生的可能性。潜在的风险有多种形式，并且不只同计算机有关。考虑信息安全时，必须重视的几种风险有：物理破坏；人为错误；设备故障；内、外部攻击；数据误用；数据丢失；程序错误，等等。在确定威胁的时候，不能只看到那些比较直接的容易分辨的外部威胁，来自内部的各种威胁也应该引起高度重视，很多时候来自内部的威胁由于具有极大的隐蔽性和透明性导致更加难以控制和防范。
|
|
|
|
风险管理是指识别、评估、降低风险到可以接受的程度，并实施适当机制控制风险保持在此程度之内的过程。风险评估的目的是确定信息系统的安全保护等级以及信息系统在现有条件下的安全保障能力级别，进而确定信息系统的安全保护需求；风险管理则根据风险评估的结果从管理（包括策略与组织）、技术、运行三个层面采取相应的安全控制措施，提高信息系统的安全保障能力级别，使得信息系统的安全保障能力级别高于或者等于信息系统的安全保护等级。
|
|
|
|
|
|
风险分析的方法与途径可以分为：定量分析和定性分析。定量分析是试图从数字上对安全风险进行分析评估的方法，通过定量分析可以对安全风险进行准确的分级，但实际上，定量分析所依靠的数据往往都是不可靠的，这就给分析带来了很大的困难。定性分析是被广泛采用的方法，通过列出各种威胁的清单，并对威胁的严重程度及资产的敏感程度进行分级。定性分析技术包括判断、直觉和经验，但可能由于直觉、经验的偏差而造成分析结果不准确。风险分析小组、管理者、风险分析工具、企业文化等决定了在进行风险分析时采用哪种方式或是两者的结合。风险分析的成功执行需要高级管理部门的支持和指导。管理部门需要确定风险分析的目的和范围，指定小组进行评估，并给予时间、资金的支持。风险小组应该由不同部门的人员组成，可以是管理者、程序开发人员、审计人员、系统集成人员、操作人员等。
|
|
|
|
|
|
进行风险评估时需要决定要保护的资产及要保护的程度，对于每一个明确要保护的资产，都应该考虑到可能面临的威胁以及威胁可能造成的影响，同时对已存在的或已规划的安全管制措施进行鉴定。仅仅确定资产是不够的，对有形资产（设备、应用软件等）及人（有形资产的用户或操作者、管理者）进行分类也是非常重要的，同时要在两者之间建立起对应关系。有形资产可以通过资产的价值进行分类，如：机密级、内部访问级、共享级、未保密级。对于人员的分类类似于有形资产的分类。信息安全风险评估的复杂程度将取决于风险的复杂程度和受保护资产的敏感程度，所采用的评估措施应该与组织对信息资产风险的保护需求相一致。
|
|
|
|
|
|
对风险进行了识别和评估后，可通过降低风险（例如安装防护措施）、避免风险、转嫁风险（例如买保险）、接受风险（基于投入／产出比考虑）等多种风险管理方式得到的结果来协助管理部门根据自身特点来制定安全策略。制定安全策略时，首先要识别当前的安全机制并评估它们的有效性。由于所面临的威胁不仅仅是病毒和攻击，对于每一种威胁类型要分别对待。在采取防护措施的时候要考虑如下一些方面：产品费用、设计／计划费用、实施费用、环境的改变、与其他防护措施的兼容性、维护需求、测试需求、修复、替换、更新费用、操作／支持费用。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
为了确保系统转换的万无一失，不仅要在前期做很多次的模拟测试，对于最后的转换过程，也需要制定周密的风险管理计划，一般至少要包括以下这些方面。
|
|
|
|
（1）系统环境转换。保证原来所有到旧系统的访问，都能被转换到新系统上，这不仅包括应用系统的前端，还包括各类周边的相关应用系统，必须要同时指向新的应用系统。如果这方面出现问题，则只好退回到原有系统上。通常这方面的问题在多次的测试过程中能够得到有效解决，但在向生产系统正式转换时，还是不可掉以轻心。
|
|
|
|
（2）数据迁移。原有的旧系统从启用到被新系统取代，在其使用期间往往积累了大量珍贵的历史数据，其中许多历史数据都是新系统顺利启用所必需的。另外，这些历史数据也是进行决策分析的重要依据。数据迁移，就是将这些历史数据进行清洗、转换，并装载到新系统中的过程。在银行、电信、税务、工商、保险以及销售等领域发生系统转换时，一般都需要进行数据迁移。数据迁移的质量不仅仅是新系统成功上线的重要前提，同时也是新系统今后稳定运行的有力保障。如果数据迁移失败，新系统将不能被正常启用；如果数据迁移的质量较差，没能屏蔽全部的垃圾数据，对新系统将会造成很大的隐患，新系统一旦访问这些垃圾数据，可能会由这些垃圾数据产生新的错误数据，严重时还会导致系统异常。相反，成功的数据迁移可以有效地保障新系统的顺利运行，能够继承珍贵的历史数据。
|
|
|
|
将业务数据从旧系统迁移到新的系统中，不仅要保证在数据转换过程中保持数据逻辑的一致性（如果新、旧系统的数据逻辑不同），而且在实际转换过程中，还要保证新旧系统之间数据的同步，保证在转换之前新旧系统的数据是一致的，在转换之后，新产生的业务数据都能反映到新的系统中，不会有任何遗漏。为了准备在出现意外时能够将新的业务数据传回到旧系统中，需要充分做好数据备份，做好数据从新系统向旧系统转换的准备，而且也要充分考虑到数据同步的问题。其实将新系统转换回旧系统，其面临的风险和需要解决的问题，基本上是相同的。在新旧系统之间的数据转换工作，可以在前期的测试中完成，但新旧系统之间的数据同步，只有在实际转换时才能完成，所以一般都会受到项目管理者的高度重视，成为大家关注的焦点。
|
|
|
|
（3）业务操作的转换。由于新旧系统在业务操作方面可能会存在较大的变化，无论对业务人员做多少前期的培训，也难以完全改变旧的操作习惯，所以在转换到新的系统之后，还可能出现人为的业务操作方面的问题，导致业务处理方面出现差错。所以在系统转换后的相当时期内，仍然需要对业务处理进行跟踪检查，及时发现由于业务操作可能导致的问题。
|
|
|
|
（4）防范意外风险。在风险管理中，除了计划内考虑到的可能的风险，还可能出现许多意料不到的风险，所以在风险管理计划中，不仅要有对已经识别的风险的应对措施，还要有防范其他意外的应对措施，这主要就是一种管理上的措施，一旦出现事先没有考虑到的情况，仍要能够有条不紊地应对，各种资源保持就位，随时注意发现异常情况，对于出现的问题及时报告，明确对各类问题做出判断和决策的责任归属。也就是说，要具备一套能够应对各种风险的报告、决策机制。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
IT服务生命周期由规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision）5个阶段组成，简称“PIOIS”。
|
|
|
|
（1）规划设计：从客户业务战略出发，以需求为中心，参照ITSS对IT服务进行全面系统的战略规划和设计，为IT服务的部署实施做好准备，以确保提供满足客户需求的IT服务。
|
|
|
|
（2）部署实施：在规划设计基础上，依据ITSS建立管理体系、部署专用工具及服务解决方案。
|
|
|
|
（3）服务运营：根据IT服务部署情况，依据ITSS，采用过程方法，全面管理基础设施、服务流程、人员和业务连续性，实现业务运营与IT服务运营的全面融合。
|
|
|
|
（4）持续改进：根据IT服务运营的实际情况，定期评审IT服务满足业务运营的情况，以及IT服务本身存在的缺陷，提出改进策略和方案，并对IT服务进行重新规划设计和部署实施，以提高IT服务质量。
|
|
|
|
（5）监督管理：本阶段主要依据ITSS对IT服务质量进行评价，并对IT服务供方的服务过程、交付结果实施监督和绩效评估。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（1）对软件计划的相关内容（重点是组织、技术标准、开发计划和进度要求等）、项目计划过程、项目计划组织和文档格式等进行审查，确认是否满足要求。
|
|
|
|
|
|
|
|
|
|
（1）承建单位制订了软件项目计划，同时该项目计划通过了正式的评审，软件项目计划对项目组织、进度计划、工程标准进行了承诺，项目的风险分析合理，风险管理方案可行。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
执行监理工作时，监理工程师的以下两种行为存在极大风险，也有可能造成监理项目的失败。
|
|
|
|
（1）失职行为。监理工程师未能全面正确地履行《监理委托合同》中规定的监理职责，或超出《监理委托合同》中规定的监理范围，从事自身职责之外的工作。
|
|
|
|
（2）过失行为。监理工程师由于主观上的无意行为未能严格履行监理职责。
|
|
|
|
为防范这种风险，总监理工程师应严格按照监理合同编制《监理规划》，并认真审核各监理工程师所编制的《监理实施细则》。监理工程师应严格执行经过批准的《监理规划》和《监理实施细则》，不要轻信承建单位的承诺，不要轻信个人的经验和直观判断，不要随意缩小监理范围并减少监理内容，也不要超越委托范围去做职责之外的工作（如不能参与承建方的工作）。
|
|
|
|
|
|
|
|
|
|
|
|
|
