|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
风险识别是试图系统化地确定对项目计划的威胁。风险识别的一个方法是建立风险条目检查表。该检查表可以用于识别风险，并使得人们集中来识别下列常见的、已知的及可预测的风险：产品规模、商业影响、客户特性、过程定义、开发环境等。
|
|
|
|
|
|
风险预测又称为风险估算，它从两个方面评估一个风险：风险发生的可能性或概率；以及如果风险发生所产生的后果。通常项目计划人员与管理人员、技术人员一起，进行4种风险预测活动：建立一个尺度或标准，以反映风险发生的可能性；描述风险的后果；估计风险对项目和产品的影响；标注风险预测的整体精确度，以免产生误解。
|
|
|
|
|
|
|
|
|
|
式中：ri为风险；li为风险发生的概率；xi为风险产生的影响。
|
|
|
|
一个对风险评估很有用的技术就是定义风险参照水准。对于大多数软件项目来说，成本、进度和性能就是3种典型的风险参照水准。
|
|
|
|
在风险评估过程中，需要执行下面步骤：①定义项目的风险参考水平值；②建立每一组与每一个参考水平值之间的关系；③预测一组临界点以定义项目终止区域；④预测什么样的风险组合会影响参考水平值。
|
|
|
|
|
|
一个有效的策略必须考虑3个问题：①风险避免；②风险监控；③风险管理及意外事件计划。如果软件项目组对于风险采取主动的方法，则避免是最好的策略。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
没有绝对安全的环境，每个环境都有一定程度的漏洞和风险。风险是指某种破坏或损失发生的可能性。潜在的风险有多种形式，并且不只同计算机有关。考虑信息安全时，必须重视的几种风险有：物理破坏；人为错误；设备故障；内、外部攻击；数据误用；数据丢失；程序错误，等等。在确定威胁的时候，不能只看到那些比较直接的容易分辨的外部威胁，来自内部的各种威胁也应该引起高度重视，很多时候来自内部的威胁由于具有极大的隐蔽性和透明性导致更加难以控制和防范。
|
|
|
|
风险管理是指识别、评估、降低风险到可以接受的程度，并实施适当机制控制风险保持在此程度之内的过程。风险评估的目的是确定信息系统的安全保护等级以及信息系统在现有条件下的安全保障能力级别，进而确定信息系统的安全保护需求；风险管理则根据风险评估的结果从管理（包括策略与组织）、技术、运行三个层面采取相应的安全控制措施，提高信息系统的安全保障能力级别，使得信息系统的安全保障能力级别高于或者等于信息系统的安全保护等级。
|
|
|
|
|
|
风险分析的方法与途径可以分为：定量分析和定性分析。定量分析是试图从数字上对安全风险进行分析评估的方法，通过定量分析可以对安全风险进行准确的分级，但实际上，定量分析所依靠的数据往往都是不可靠的，这就给分析带来了很大的困难。定性分析是被广泛采用的方法，通过列出各种威胁的清单，并对威胁的严重程度及资产的敏感程度进行分级。定性分析技术包括判断、直觉和经验，但可能由于直觉、经验的偏差而造成分析结果不准确。风险分析小组、管理者、风险分析工具、企业文化等决定了在进行风险分析时采用哪种方式或是两者的结合。风险分析的成功执行需要高级管理部门的支持和指导。管理部门需要确定风险分析的目的和范围，指定小组进行评估，并给予时间、资金的支持。风险小组应该由不同部门的人员组成，可以是管理者、程序开发人员、审计人员、系统集成人员、操作人员等。
|
|
|
|
|
|
进行风险评估时需要决定要保护的资产及要保护的程度，对于每一个明确要保护的资产，都应该考虑到可能面临的威胁以及威胁可能造成的影响，同时对已存在的或已规划的安全管制措施进行鉴定。仅仅确定资产是不够的，对有形资产（设备、应用软件等）及人（有形资产的用户或操作者、管理者）进行分类也是非常重要的，同时要在两者之间建立起对应关系。有形资产可以通过资产的价值进行分类，如：机密级、内部访问级、共享级、未保密级。对于人员的分类类似于有形资产的分类。信息安全风险评估的复杂程度将取决于风险的复杂程度和受保护资产的敏感程度，所采用的评估措施应该与组织对信息资产风险的保护需求相一致。
|
|
|
|
|
|
对风险进行了识别和评估后，可通过降低风险（例如安装防护措施）、避免风险、转嫁风险（例如买保险）、接受风险（基于投入／产出比考虑）等多种风险管理方式得到的结果来协助管理部门根据自身特点来制定安全策略。制定安全策略时，首先要识别当前的安全机制并评估它们的有效性。由于所面临的威胁不仅仅是病毒和攻击，对于每一种威胁类型要分别对待。在采取防护措施的时候要考虑如下一些方面：产品费用、设计／计划费用、实施费用、环境的改变、与其他防护措施的兼容性、维护需求、测试需求、修复、替换、更新费用、操作／支持费用。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
应该在项目生命周期中实施项目管理计划中所列的风险应对措施，还应该持续监督项目工作，以便发现新风险、风险变化以及过时的风险。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
绩效报告从绩效测量中提取信息并进行分析来提供各种项目绩效信息，包括偏差分析、挣值数据和预测数据等。
|
|
|
|
|
|
|
|
|
|
风险监控经常需要识别新风险，对现有风险进行再评估以及删除已过时的风险。应该定期进行项目风险再评估，反复进行再评估的次数和详细水平，应根据相对于项目目标的项目进展情况而定。
|
|
|
|
|
|
通过风险审计，检查并记录风险应对措施在处理已识别风险及其根源方面的有效性，以及风险管理过程的有效性。
|
|
|
|
|
|
很多控制过程都会借助偏差分析来比较计划结果与实际结果。为了监控风险事件，应该利用绩效信息对项目执行的趋势进行审查。可使用挣值分析以及项目偏差与趋势分析的其他方法对项目总体绩效进行监控。与基准计划的偏差可能表明威胁或机会的潜在影响。
|
|
|
|
|
|
技术绩效测量是把项目执行期间所取得的技术成果与项目管理计划所要求的技术成果进行比较。技术绩效测量指标可包括处理时间、缺陷数量和存储容量等。偏差值有助于预测项目范围方面的成功程度，还能揭示项目面临的技术风险程度。
|
|
|
|
|
|
在项目执行过程中，有可能发生某些风险，会对预算和进度的应急储备产生正面的或负面的影响。储备分析是指通过比较剩余应急储备和剩余风险量，从而确定剩余储备是否仍然合理。
|
|
|
|
|
|
项目风险管理应该是项目定期状态审查会的一项议程。经常就风险进行讨论，可促使人们更充分地识别风险和机会。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
建议的纠正措施包括应急计划和权变措施。权变措施是针对以往未曾识别或被动接受的、目前正在发生的风险而采取的未经事先计划的应对措施。
|
|
|
|
|
|
采用建议的预防措施，使项目执行符合项目管理计划的要求。
|
|
|
|
|
|
|
|
.风险管理计划的模板，包括概率影响矩阵，风险登记册。
|
|
|
|
|
|
|
|
|
|
如果批准的变更请求对风险管理过程存在影响，则应对项目管理计划的相应组成部分进行更新并重新签发，以反映批准的变更。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行及潜在问题的及时发现与干预。
|
|
|
|
（1）服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端Web Server，就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否崩溃、通过ICMP包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，这些只是一部分，还有多种监控方式，依应用特点而定。还有一些问题需解决，如集群过大，如何高性能地进行监控也是一个现实问题。
|
|
|
|
（2）集群状态类的监控或统计，为合理管理调优集群提供数据参考，包括服务瓶颈、性能问题、异常流量、攻击等问题。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
信息安全风险评估的复杂程度将取决于风险的复杂程度和受保护资产的敏感程度，所采用的评估措施应该与组织对信息资产风险的保护需求相一致。
|
|
|
|
资产评估是企业制定信息安全策略的前提条件，只有确定企业需要重点保护的资源，才能够制定出相应的切合实际的策略。公司首先要确定对公司目前成功和长期生存至关重要的数据、系统和网络，因为这些元素对企业而言兼具货币价值和内在价值。货币价值指起重要作用的关键、敏感数据设计资料、应用系统和网络，以及如果这些元素无法提供适当的功能，公司将遭受多大的损失。内在价值指各机构必须认真考虑安全问题可能带来的对信誉、声誉和与投资者关系的损害。
|
|
|
|
在评估过程，企业要采用能够充分利用结合优秀的传统方法及联网计算的新业务模式，才能获得竞争优势。而且对许多企业来讲，问题不在于数据安全是否必要，而在于怎样在预算范围内以安全的方式管理复杂计算机环境、多种计算机平台和众多集成式计算机网络上的数据。各机构必须独立确定所需的安全程度，以及哪种安全能最有效地满足其特殊业务需求。所以，有效的评估方法就是要根据不同企业特殊条件有针对性地进行操作。
|
|
|
|
组织在进行信息资产风险评估时，不可有侥幸心理，必须将直接后果和潜在后果一并考虑。对信息安全管理体系范围内的信息资产进行鉴定和估价，然后对信息资产面对的各种威胁和脆弱性进行评估，同时对已存在的或规划的安全管制措施进行鉴定，这就是一个风险评估的过程。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
|
|
|
|
项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。
|
|
|
|
：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。
|
|
|
|
程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。
|
|
|
|
最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。
|
|
|
|
|
|
|
|
|
|
|
|
|
