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