十四章
今天由于有点事情,没有完成既定今天的通读任务,本来准备在三十一日之前至少读完一遍,今天本来得把第三部分读完,虽然不能像之前那样对于每一个细节进行研究,但是明天天必须把全书通读一遍。对于遗留问题在之后的复读中进行问题解决,首先要建立一个至少还行的软件工程理论体系。这一章叫做信息安全工程,主要是介绍有关安全的应用系统设计中所需要考虑的诸多问题,需要了解应用级信息安全和基础设施级信息安全之间的区别,另外要知道使用生命周期的风险评估和运行的风险评估来理解影响系统设计的信息安全性问题,了解信息安全软件开发的软件体系结构和设计准则,了解系统生存力概念, 以及为什么对于复杂软件系统来说生存力分析很重要。
随着互联网的广泛使用,需要设计和实现能保证信息安全的系统,设计能抵抗外部攻击并在遭受攻击后成功恢复的系统是十分必要的,信息安全工程关系到系统开发和进化的过程,这样的系统要能抵御恶意的攻击,保护系统以及它的数据。
这里提到了有专门讲计算机信息安全的教科书,后期可以去看看。
研究信息安全这根话题的手,需要考虑应用软件包括控制系统和信息系统,和支撑这种系统的基础设施的两方面。
对于复杂应用来说,基础设施包括1操作系统平台,例如linux 和windows
2系统上运行的其他通用应用,比如Web浏览器和电子邮件客户端2数据库管理系统,4支持分布式计算和数据库访问的中间件5用于应用软件开发的可复用组件库。
下面有一个关于各个基础实施的分层,需要重点记忆一下。
绝大多数的攻击都是集中在对系统基础设施的攻击上,因为基础设施组件时公开个非常容易得到的。
另外,在实践中,应用级信息安全 和基础设施级的安全是有很大区别的1应用级信息安全是个软件工程问题,可以确保系统是按照抵御攻击的要求去 设计,2基础设施级信息安全是管理问题,系统管理者对基础设施进行配置以抵御攻击,系统管理者需要设置基础设施,使得绝大多数对任何基础设施的信息安全特性的有效使用都能够很好地满足。他们也需要修补基础设施在信息安全上的漏洞,以便应用团建不会受到这些漏洞的影响。
信息安全管理不是一个鼓励的任务,它包括了用户和权限管理、系统软件部署和维护以及攻击监控、测试和恢复。
由上面我发现,其实应用级主要是指单单的一个软件,而基础设施级别,包括基础操作系统,比如Linux或Windows,还包括硬件。当然这个是我目前看法。
对于要求极高的控制系统和嵌入式系统,通常的做法是选择一个合适的基础设施来支持应用系统。因为机构中的应用系统通常使用已存在的基础设施来实现,所以,使用基础设施和它的的信息安全特效的风险必须考虑在内,作为系统设计过程的一部分。
对于有效的信息安全工程来说信息安全的评估和管理是分层必要的,风险管理主要是评估系统资产在攻击中的可能损失,并在这些损失和降低这些损失的成本之间选择一个平衡。风险管理是一种管理问题,所以软件工程师应该觉得哪些控制应该包含在系统内,高级管理者要决定是接受信息安全的代价还是接受缺乏安全流程的后果,软件工程师是 重要的参与者,
对于风险评估和管理过程来说,关键是机构的信息安全策略,机构的信息安全策略是要贯彻到所有的系统中的,风险评估要在做出系统决策之前开始,并贯穿整个系统开发过程和系统投入使用之后。
风险评估分为不同的阶段,1初步风险评估2生存期风险评估3运行风险评估。
进行风险性评估,我们需要明确对系统有可能产生的危险主要可以使用集中方法,其中一种是开发一个“误用案例”集,误用案例是表现与系统进行恶意交互的脚本,我们可以使用这些用例来讨论和明确可能的威胁,因此也就能够确定系统的信息安全需求,当要导出系统需求时,这些案例 同样可以和用例结合在一起使用。
这里我的理解就是,实际上使用一种事前预设的可能出现错误的方式运行导致出现错误,那么就可以避免错误从而形成需求描述。
在识别可能的误用案例时可以作为出发点的四个方面1拦截威胁2中断威胁3修改威胁4伪造威胁
误用案例不仅仅在初步风险中有用,在生存期风险分析和运行风险分析的信息安全分析中也会被使用到,这些用例对于针对系统的所有的假设攻击和对于所做出的的设计决定的信息安全影响的评估提供了有用的根据。
下面几个小节是分不同方面内进行了总结,
基于机构的信息安全策略,初步风险评估应当明确系统最重要的信息安全需求,生存期风险评估明确影响信息安全的设计和实现希捷,在生存期评估风险时,我们会有更多关于需要保护哪些部分的详细信息,我们也会摸清系统中漏洞的有关情况,信息安全的风险评估应该是系统的从需求工程到系统部署全生存期活动中的一部分,相较于初步风险评估过程,只是增加有关漏洞识别和评估活动,风险评估的成功是一系列工程决断,它们影响系统设计或者是限制其使用范围和方式。
漏洞一旦被发现,我们就必须决定采取哪些措施来降低相应的风险,这一般要考虑要不要添加额外的系统安全需求或者是其他的系统使用的操作过程,关于安全需求有这么一些1口令检查程序应该是可用的且每天运行,等级在系统紫癜中的拥护口令会被识别并报告给系统管理员2对系统的访问只能安装一个由系统管理员所认可的Web浏览器。
关于运行风险评估,识别出现的风险和可能需要应对这些风险的系统变更,叫做运行风险评估,因为系统需求的改变,系统基础设施的改变或者是系统使用环境的改变,新风险可能出现,
运行风险评估过程和生命期风险评估过程类似,但是有很多的关于系统运行环境的信息,因为环境的特性能够导致系统产生新风险,所以环境很重要。
一般来说,在一个系统已经实现后,要想将信息安全性再加入系统是很困难的,因此我们需要在系统设计过程中就要将信息安全问题考虑在内,信息安全设计必须考虑到应用的用途、临界状态和操作环境,在可靠性和信息安全之间有紧密的联系,冗余性和多样性的使用,对于达到可靠性是很重要的,这里又两点,我觉得很重要1,设计一个系统要爆炸安全,要做出取舍,增加信息安全方案会影响效率,2信息安全和系统可用性之间有制约关系,比较简单的例子就是忘掉密码,打不开电脑。
体系结构的选择对系统特性有深刻的影响,如果使用不恰当的体系结构,维护系统信息的信息安全性和晚自习或是保证系统有一定的实用性就是不可行的。这里需要考虑两个问题1保护,如何组织系统使其关键资产能在外部攻击时得到保护2分布,如何对系统资产进行分布使攻击数减到最小。
这里提到的几个层次保护,让我想起了网上银行的动态密码,以前没看书,不是很理解,现在有一种豁然开朗的感觉。
对于任何一个应用来说,保护层的数量依赖于数据的危险程度,不是所有的应用都需要记录级的保护,因此通常使用大粒度的访问控制。对于数据的保护是一个关键性需求,那么应该使用在服务器端包含有保护机制的客户-服务器体系结构。这个结构需要主要看一下,理解一下,
这里我感觉主要是在信息安全和系统性能之间寻找平衡点。
并不存在一个如何达到系统安全性的硬性固定。不同类型的系统需要不同的技术措施来达到系统拥有者所不能接受的安全等级。对于一般性的设计准则,主要用途在于1提高软件工程团队对信息安全问题的重视。2它们能够在系统有效性验证过程中的复查清单中得到试用。
下面提到了十个准则,这些需要记忆和经常查询。做一个重点符号。
对系统的部署设计诸多方面,包括配置软件使之适应运行环境,安装系统到此环境中的计算机上,然后是为这些计算机配置好所安装的系统,但是,在上面一个思维导图的软件过程阶段,通常意外地导入软件漏洞。
人们通常将配置和部署看成是系统管理问题,而没有将其看成是软件工程过程范围内的事。
有四种可以在系统中加入部署支持的 方法:1包含对配置的观察和分析的支持2最小化缺省特权3局部化配置设定。
除开应用开发角度,系统获得者和开发者对有可能受到攻击的系统的所有方面都能够进行控制。现在的分布式系统(这里我不是很理解分布式系统,通过查询分布式系统(distributed system)是建立在网络之上的软件系统。正是因为软件的特性,所以分布式系统具有高度的内聚性和透明性。)
不可避免地依赖于基础设施,包括商业现货系统(之前提到过,买软件的)和可复用组件,这些商业现货或者是组件都是分别开发的,这些系统的信息安全特性不仅仅依靠局部设计决策,同样受到外部应用的信息安全,Web服务和网络基础设施的影响。
由于不能保证系统不受攻击,所以需要系统有弹性。在最差情况下为用户提供基本服务,生存能力是系统作为一个整体所表现出来的总体特性,由于现代社会对于计算机系统要求很高,依赖很强,所以生存能力至关重要。
维护要求极高的服务的可用性是生存能力的基本内容,提到了几点需要了解的点。
可生存系统分析,主要是用来评估系统中的漏洞并支持对系统体系结构和能提升系统生存能力的特征的设计,主要是三个策略1抵抗力2识别3恢复。而对于每个阶段的关键活动分别是1系统累计2关键服务识别3攻击方针4生存能力分析
提高系统的生存能力和恢复能力是需要付出代价的,生存能力分析还不是绝大多数软件工程过程的一部分。
今天由于一些事情,导致看书时长不够,明天需要补齐,虽然在31日之前不能像之前那样能够细致读书读完本书,但是能够把握其中要点,之后还要有几遍的精读过程,毕竟软件行业注重规则,31日之前至少得全部看一遍。