《软件安全读书报告》由会员分享，可在线阅读，更多相关《软件安全读书报告（3页珍藏版）》请在金锄头文库上搜索。
1、如何确保软件安全通过对software-how do we know it is safe的阅读，经过分析和总结，得出了一些想法。简介根据现阶段微处理器在故障安全系统中的应用情况，列举了一系其在列轨道和非轨道应用中的故障实例，具体包括：轨道交通软件故障实例：1. 由于缓存溢出，火车头没有响应制动指令。具体原因为在程序访问一个20个字节的缓存时，由于线上出现干扰，指针超过20个字节。软件没有清空缓存，导致数据一直存入缓存直到系统崩溃。此例中本有一个用来重启系统的看门狗定时器，但是它也没有正常工作。2. 一个自动控制系统在某个场合工作的很好，但到了另外一个场合却试图让两车相撞。这是因为代码在两个场
2、合使用的不同导致的。3. 一辆火车有火车头和客车车厢，结果不听任何控制室的指挥。因为两个控制室的参考速度不同，导致在加速过程中两个控制室同时放弃了控制权限。4. 记录器空间越来越少，因为每次在写入时关电都会将区块标记位错块。5. 驾驶系统允许列车驶入失去联系的列车停留的区域，原因是软件认为列车已经离开了那片区域。其它应用软件故障实例：1. F16战斗机无法在死海附近降落因为其海拔小于零。2. 在美国使用良好的飞机控制系统无法在英国使用因为没有考虑到零度经线。3. 放射性治疗设备测试使用良好，但是应用时导致病人死亡，因为操作者输入字符过快。4. 747外部引擎失灵，但自动调整系统一直未通知驾驶员
3、。5. 双子五号因为没有考虑地表移动，偏离航线100公里6. 飞行器上的CMOS存储器发送错误信号。真正的安全隐患由软件故障的实例引出，主要分析在安全苛求系统中真正的安全隐患，主要分为硬件隐患和软件隐患，具体如下：硬件隐患包括：微处理器的硬件故障可能导致软件出错，比如错误的数据存储可能导致系统记录错误的列车实时速度。另外还可能导致系统无法跳出循环，甚至出现错误结果，导致系统的锁死（有时还会有部分功能未锁死，比如桌面和鼠标）。软件隐患包括：1. 软件的BUG，主要是软件设计者的失误；2. 软件的应用环境改变，导致预期的结果不适用于新的环境。这种隐患也很难排除；3. 语言和开发工具的选择，比如“C
4、”“C+”“ADA”由于执行代码的“表现”能力不强，被认为不应该出现在安全软件设计中；4. 一些听起来很不错的流行语（快速模型、重复、螺旋、瀑布）等并没有提高软件安全性，但降低了人们的安全意识。同时，指出了软件的安全审查表面化。具体的说，很多软件检查和测试过程趋于书面化，主要工作都用在了代码格式、文档名称这样的形式整理上，而对于代码的逻辑等的检查和测试并没有做到位。另外，由于软件工程师常常需要对整个系统进行了解，很多时候软件和系统的联系都由同一个人完成，这就导致了软件编写的所谓“个人英雄主义”模式。这样只有一个人知道软件是如何工作的，没有对软件的相关文档说明。如何解决安全隐患根据安全系统的隐患
5、，提出了安全隐患的解决办法。由于安全系统的安全性体现在整体上，任何部分出错都可能导致整个系统的不安全，所以只能通过一些方法提高每一个部分的安全性，从而提高系统的安全性。从硬件方面来说：1. 首先是硬件测试，比如对RAM、ROM、watchdog的测试；2. 独立的系统做表决，只有独立的系统同时成立才通过表决；3. 多处理器表决；4. 数字化许可，即用一个大的特殊数值表示通过的决议，此数值是通过合并其他安全苛求系统的特殊数值决定的；5. 硬件内部锁定。即从硬件上监督处理器保证不会处于不安全状态，或者说固有故障安全。从软件方面来说：1. 首先，明确系统的安全功能，比如系统如何对外部的作用等；2.
6、其次，制定明确的软件开发计划，包括安全功能定义，接口定义，质量控制，验证和审核等；3. 第三，独立系统表决。和硬件的独立系统表决一样，这可以减少逻辑错误，但是需要做好两个系统的同步；4. 第四，同一个功能通过不同的程序进行冗余表决；5. 第五，无法进行安全保证的程序只能通过安全硬件进行保证。6. 第六，软件故障树分析；7. 第七，软件覆盖测试，即白盒测试；8. 第八，形式化语言编程；9. 第九，软件防火墙，即将安全的和不安全的功能隔离；10. 第十，选择合适的编程语言，对编译器生成的汇编语言进行审查。结论根据上面的分析，保证软件安全的一系列措施，具体包括：1. 对系统如何保证安全做出明确详尽的定义；2. 保持代码简单易懂，好的软件代码只有一部分需要安全分析；3. 有一个可接受的方式来减轻硬件错误的影响；4. 有一个经得起检验的软件开发计划，包括足够的文档支持；5. 独立机构的严格测试。
