如信息处理系统的其它方面一样，如果安全的计划和管理工作贯穿于整个计算机系统生命周期中从最初的计划到设计、实施和运行以至废弃的全过程，那么它将是最有效和最有效率的。生命周期中会发生很多安全相关事件和分析工作。本章介绍它们之间的关系，以及如何将其整合在一起。还要讨论安全计划在帮助确保安全问题得到完全处理中的重要作用。
本章考察：
- 系统安全计划，
- 计算机系统生命周期的组件，
- 将安全整合到计算机系统生命周期中的好处，以及
- 处理生命周期中安全问题的技术。
8.1 联邦系统有关计算机安全法案的相关问题
计划用于协助确保安全问题在整个生命周期中得到完全的处理。对于联邦系统，1987年计算机安全法案对所有敏感系统的计算机安全计划的准备提出了法定需求。法案的本意和精神是改善联邦政府的计算机安全状况，而不仅仅是增加文案工作。为了达成这种意图，行政管理与预算局（OMB）和NIST负责指导机构的计划过程，并强调计算机安全计划和管理在机构和每一个计算机系统中的重要性。正如本章强调的那样，计算机安全管理应该做为计算机系统管理的一部分。拥有专门的计算机安全计划的好处是确保不会忽视计算机安全。
法案要求将计划提交给NIST和国家安全局（NSA）以便对所完成的工作进行检查和评价。实施法案的当前指导方针要求机构将其计算机安全计划交付独立检查。根据机构的情况，这种检查可以是内部的或外部的。
“典型的”计划简要描述系统重要的安全考虑事项，并提供更详尽文档如系统安全计划、应急计划、培训计划、审批意见、事件处理计划或审计结果的索引。这样就可以使计划在无需重复已有文件的条件下做为管理工具使用。对于较小的系统，计划可能包含所有的安全文档。与其它的安全文档一样，如果计划涉及到可能破坏系统的具体缺陷或其它信息，它就应该是保密的。它还应该保持更新状态。
8.2 将安全集成到计算机系统生命周期中的益处
虽然可以在系统生命周期的任何时刻制定计算机安全计划，但是建议在计算机系统生命周期的开始阶段制定计划。安全与计算机系统的其它方面一样，对整个计算机系统生命周期各阶段都进行计划是最好的管理方式。计算机界长期以来认同的原则就是，系统设计完成后在其中增加特性比在系统初始的设计阶段包含该特性要多花费十倍的时间。在系统开发期间进行安全部署主要是因为在其后部署更困难（通常这样做的成本更高）。它还很可能打断系统的持续运行。安全也需要融入到计算机系统生命周期的后期，以协助确保安全能够跟得上系统环境、技术、规程和人员的变化。它还确保在系统升级时考虑到安全问题，包括采购新的部件或设计新的模块时。在安全入侵、灾难或审计后对系统增加新的安全控制会造成无计划的安全实施，这种实施比一开始就将安全集成到系统中要更昂贵和缺乏效率。它还会严重地降低系统的性能。当然，事先考虑到系统生命期中所有的问题实际上也是不可能的。所以，通常至少应该在生命周期每个阶段结束时，或每次重新审批后更新计算机安全计划。对于许多系统，可能需要更频繁地更新。
生命周期管理除了帮助确保管理活动在所有阶段都充分考虑到安全问题以外，还可以帮助记录安全相关决策。这种记录文档对于系统管理人员以及督察和独立审计人员是有用的。系统管理人员将文档用于自我检查和决策理由的提示，这样就可以更容易地对环境更改的影响进行评估。督察和独立审计人员在检查中使用文档来验证系统管理工作的充分性，并用来突出安全可能被忽视的领域。这包括检查文档是否正确地反映了系统的实际运行情况。
在联邦政府中，1987年计算机安全法案及其实施的指令提供了计算机安全计划的需求。这些计划是一种文档形式，它帮助确保不仅在系统设计和开发阶段，而且在生命周期的其它阶段考虑安全问题。计划也可被用于满足OMB A－130规章中附录III的需求，以及其它所涉及到的相关需求。
8.3 计算机系统生命周期概述
计算机系统生命周期模型有很多，但是大多包含图8.1中描绘的五个基本阶段。
- 起始 在起始阶段，表述系统的需要并记录系统的目的。
- 开发/采购 在这个阶段对系统进行设计、购买、编程、开发或其它形式的构建。这个阶段经常包含所定义的其它周期，如系统开发周期或采购周期。
- 实施 在初期的系统测试后，系统被安装到位。
- 运行/维护 在这个阶段系统执行其工作。几乎总是要对系统进行修改，增加硬件、软件或发生其它大量的事情。
- 废弃 当完成向新计算机系统转移的工作后，计算机系统被废弃。
每个阶段都可以适用于整个系统、一个新的组件或模块，或一次系统升级。与系统管理的其它方面一样，这里描述的每一个活动的具体情况取决于许多因素，包括规模、复杂度、系统成本和敏感性。
许多人发现计算机系统生命周期的概念令人迷惑，因为整个计算机系统生命周期的大框架下有很多周期。例如，一个机构可以使用系统开发生命周期开发一个系统。在系统生命中，机构可能使用采购生命周期购买新的组件。另外，计算机系统生命周期本身只是其它生命周期的一部分。例如，考虑一下信息生命周期。通常如人事数据之类信息的使用年限比一个计算机系统要长。如果一个员工为机构工作了三十年，并且还要工作二十年才能退休，该员工的自动化人事记录将可能经历公司拥有的很多不同的计算机管理系统。另外，一部分信息还会被用于其它计算机系统，如美国国内税局和美国社会保障总署的系统。
8.4 计算机系统生命周期中的安全活动
本节考察计算机系统生命周期（参见图8.1）每个阶段发生的安全活动。
8.4.1 起始
确定系统概念和早期设计过程涉及到新系统需求的发现，或对现有系统的增强；系统特征的初期建议和所推荐的功能；关于体系结构、性能或功能系统方面的自由讨论会；以及环境、财政、政治或其它方面的约束。同时，系统安全方面的主要问题应该在系统设计早期一并予以考虑。这可以通过敏感性评估来进行。
8.4.1.1 进行敏感性评估
敏感性评估既考察所处理信息的敏感性，也考察系统本身的敏感性。评估应考虑法规要求、机构政策（如果是联邦系统则要包括联邦和机构的政策）、以及系统的功能需要。敏感性通常以完整性、可用性和机密性来表示。在评估敏感性时需要考察系统对机构使命的重要性，系统或数据的非受权更改、泄漏或无法使用的影响这类因素。为了处理这些问题，使用或拥有系统或信息的人应该参与评估。
敏感性评估应该回答以下问题：
- 系统处理什么信息？
- 数据或系统的错误、非受权泄漏、更改或无法使用会造成什么样的潜在损害？
- 影响安全的法律或法规（如隐私法案或公平贸易行为法案）有哪些？
- 系统或信息对于什么威胁特别脆弱？
- 是否有需要特别考虑的环境因素（如系统处于危险的位置）？
- 用户群体有什么安全相关的特点（如技术掌握和培训水平或安全许可证）？
- 适用于系统的安全标准、法规或指导方针有哪些？
敏感性评估是安全分析的开始并贯穿于整个生命周期。评估协助确定项目是否需要特殊的安全督察，在决定开始系统开发前是否需要进一步的分析（以确保在合理成本上的可行性），或者在少数情况下，由于安全要求过于苛刻和昂贵以至于不能继续系统的开发或采购。敏感性评估可以被包括在系统起始的文档中，或者是其它计划文档的一部分。安全特性、规程以及下一章描述的保证的制定是基于敏感性评估的。
敏感性评估也可以在系统升级（可以是通过采购或者自主开发进行的升级）的计划阶段进行。在这种情况下，评估集中于受到影响的领域。如果升级很大程度上影响到原来的评估，可能就要分析它对系统其它领域的影响。例如，是否需要新的控制？有些控制是否变得没有必要？
8.4.2 开发/采购
对于大多数系统来说，开发/采购阶段比起始阶段更复杂。安全活动可以被分为三个部分：
- 确定安全特性、保证和运行措施；
- 将这些安全需求纳入设计规格说明；以及
- 实际获得这些内容。
这些内容适用于自主设计和构建的系统、购买的系统，以及使用混合模式开发的系统。
在这个阶段，技术人员和系统发起人应该经常在一起工作以确保技术设计反映系统的安全需要。为了与其它系统需求协调一致，这个过程需要在技术人员和系统发起人之间进行开放式的对话。这对于在整个系统的开发过程中同步和有效地解决安全需求是很重要的。
8.4.2.1 确定安全需求
在开发/采购阶段的初期，系统计划者定义系统的需求。安全需求应该与此同时制定。可以使用技术特性（如访问控制）、保证（如对系统开发者的背景调查）或运行措施（如意识培养和培训）来体现这些需求。系统安全需求与其它系统需求一样，是从法律、政策、适用的标准和指导方针、系统的功能需要，以及成本效益的平衡取舍等方面导出的。
法律 除了涉及到信息安全需求的特定法律以外，诸如1974年隐私法案、法律案件、司法意见和其它类似的法律资料都可能直接或间接地影响到安全。
政策 如第5章论述的那样，管理官员发表不同类型的政策。系统安全需求经常由专题政策导出。
标准和指导方针 国际、国家和机构的标准和指导方针是确定安全特性、保证和运行措施的另一个来源。标准和指导方针经常以“如果…则”的形式（例如，如果系统对数据进行加密，则应该使用特定的加密算法）书写。许多机构设定了不同系统类型的基线控制，如行政的、任务或业务关键的、或专利的。根据需要，应该特别注意互操作性标准。
系统的功能需要 安全的目的是支持系统的功能，而不是破坏它。所以，系统功能的许多方面与安全需求有关。
成本效益分析 当涉及到安全时，成本效益分析是通过风险评估进行的，评估考察系统的资产、威胁和缺陷以便确定最合适和具有成本效益的防范措施（符合相关法律、政策、标准和系统功能需要）。适当的防范措施通常是收益高于成本的。收益和成本包括金钱或非金钱的，如所避免的损失、维护机构的声誉、降低用户友好性，或增加系统管理工作。
风险评估与成本效益分析一样是支持决策的。它帮助管理者选择具有成本效益的防范措施。风险评估的程度与其它成本效益分析一样，应该与系统的复杂度和费用指标以及评估的预期收益相当。分析评估在第7章有更详细论述。
风险评估可以在采购需求分析阶段或系统开发周期的设计阶段进行。通常也在系统升级的开发/采购阶段评估风险。依据项目的方法体系，可以进行一次或多次风险评估。
应该注意区分安全风险评估和项目风险评估的差别。许多系统开发和采购项目要分析无法成功完成项目的风险，这是与安全风险评估不同的活动。
8.4.2.2 将安全需求纳入规格说明
确定安全特性、保证和运行措施可以获得大量的安全信息以及通常是众多的需求。需要对这些信息进行确认、更新并将其整理为系统设计者或购买者使用的、详细的安全保护需求和规格说明。依据开发系统的方法体系不同，如全部或是部分采购成品系统，规格说明可以具有完全不同的形式。
在制定规格说明时，可能需要更新初始的风险评估。风险评估建议的防范措施可能与其它需求不兼容，或者控制措施难以实施。例如，安全需求禁止拨号访问可能阻止员工离开办公室后查看其电子邮件。
除了系统的技术运行控制以外，还要涉及到保证。应该在早期确定所需的保证（以便安全特性和措施可以并且正确、有效地工作）程度。一旦确定了所需的保证级别，就有必要指明系统将得到怎样的测试和检查以便确定是否满足规格说明（以获得所需的保证）。这适用于系统开发和采购。例如，如果需要严格的保证，就需要将测试系统或提供其它形式初始和持续保证的能力设计到系统中，或通过其它方式提供。更多信息参见第9章。
8.4.2.3 获得系统和安全相关活动
在这个阶段，系统被实际构建或购买。如果构建系统，安全活动可能包括开发系统安全方面的内容、监视开发过程本身以防范安全问题、响应更改、以及监视威胁。在开发阶段可能遇到的威胁或缺陷包括木马、不正确的代码、功能低劣的开发工具、对代码的操纵和恶意的内部人员。
如果是采购成品的系统，安全活动可能包括监视以确保在市场调查、合同洽商文件，以及候选系统的评测中考虑到安全问题。许多系统采用开发和采购的混合模式。这种情况下，安全活动包括上述两个方面的内容。
在系统构建或采购时，对系统的选择可以影响到安全。这些选择包括特定成品的选择、最终对体系机构的确定，或选择处理站点或平台。可能需要更多的安全分析。
除了获得系统以外，还需要制定运行措施。这是指围绕系统发生的人的活动，如应急计划、意识培养和培训，以及准备文档。本书运行控制部分的章节论述了这些内容。这需要与系统一起开发，但是通常由不同的人来完成。这些内容与技术规格说明一样应该在开发和采购阶段的初期加以考虑。
8.4.3 实施
在一些生命周期计划中可能没有特定的实施阶段。（它通常被纳入开发和采购的后期或运行和维护的前期。）但是，从安全的角度出发，一项关键的安全活动－审批在开发和系统开始运行之间发生。本节描述的其它活动，开启控制和测试，经常被纳入开发/采购阶段的后期。
8.4.3.1 安装/开启控制
虽然很明显，但是这个活动还是经常被忽略。系统在获得时经常处于安全特性禁止状态。这就需要开启和配置。对于许多系统来说，这是需要很高技巧的复杂工作。定制开发的系统也可能需要类似的工作。
8.4.3.2 安全测试
系统安全测试包括对所开发或采购的系统特定部分的测试和整个系统的测试。安全管理、物理设施、人事、规程、商业或内部服务（如网络服务）的使用，以及应急计划是对整体系统安全产生影响但可能处于开发或采购周期之外的领域的例子。因为只有在开发或采购周期之内的部分才会在系统接收测试中得到测试，所以可能需要对这些额外的安全组件进行独立的测试或审查。
安全认证是对部署在计算机系统中的安全防范措施的正式测试以确定其是否满足相关的需求和规格说明70。为了提供更可靠的技术信息，认证通常由独立的审查者而不是由设计系统的人进行。
8.4.3.3 审批
系统安全审批是审批（管理）官员对系统运行的正式授权和对风险的明确接受。它通常由对系统管理、运行和技术控制等的检查支持。此检查可以包括详细的技术评测（如特别针对复杂、关键或高风险系统的联邦信息处理标准102认证）、安全评测、风险评估、审计或其它此类检查。如果生命周期过程被用于管理一个项目（如系统升级），认识到审批是针对整个系统而不仅是新增部分是很重要的。
看待计算机安全审批的最佳方式是将其作为质量控制的一种形式。它强迫管理者和技术人员一起工作，以发现在给定技术约束、运行约束和使命需求下的最佳安全方法。审批过程迫使管理者作出提供充分安全防范措施的关键决定。基于技术和非技术防范措施的有效性以及残留风险的可靠信息所作出的的决定更可能是个好决定。
在决定安全防范措施和残留风险的可接受性后，审批官员应该发表正式的审批意见。当系统安全中的大多数缺点没有严重到足以使运行的系统停止服务或阻止新的系统进入运行状态时，缺点可能要求对运行进行一些限制（如限制拨号访问或与其它机构的电子连接）。在一些情况下，可能会执行临时审批，允许系统运行并在过渡期结束时接受检查，这时应该完成了安全升级。
8.4.4 运行和维护
许多安全活动发生在系统生命的运行阶段。通常，这被分为三部分：（1）安全运行和管理；（2）运行的保证；以及（3）定期对安全的重新分析。图8.2用图表方式描述了运行阶段安全活动的流程。
8.4.4.1 安全运行和管理
系统运行涉及到本手册讨论的许多安全活动。执行备份、举办培训课程、管理密钥、更新用户管理和访问特权、以及更新安全软件就是一些例子。
8.4.4.2 运行保证
运行的系统没有完美的安全。另外，系统用户和操作员发现新的方法来有意无意地绕过或颠覆安全。系统或环境的更改可能产生缺陷。一贯严格坚持规程的情况很少见，规程会变得过时。认为风险很小，用户可能会想要绕过安全措施和规程。
如图8.2所示，有更改发生。运行保证是了解这些更改是否是新的缺陷（或未被更正的老缺陷）、系统更改、或环境更改的一种方式。运行保证是检查运行系统来了解自动的或人工的安全控制是否运行正确和有效的过程。
为了维护运行保证，机构使用两种基本的方法：系统审计和监视。这些术语在计算机安全界的使用比较模糊并且经常重叠。系统审计是一次性或定期的评测安全的事件。监视是指检查系统或用户的持续活动。通常，活动越是“实时”，越是被归为监视类型。（参见第9章）
8.4.4.3 管理更改
计算机系统及其运行的环境会发生持续的更改。为了响应诸如用户的抱怨、出现新的特性和服务、或发现新的威胁和缺陷，系统管理者和用户修改系统并增加新的特性、新的规程和对软件进行升级。
系统运行的环境也会更改。网络和网络互连有增加的趋势。可能会增加新的用户组，这可能是外部用户组或匿名用户组。新的威胁可能会出现，如网络入侵的增加或个人计算机病毒的扩散。如果系统有配置控制委员会或其它管理系统技术更改的机构，可以安排安全专家在委员会中工作以便就更改是否（如果有，如何）影响安全作出决定。
在系统升级（以及计划的更改）和决定计划外更改影响的过程中也应该考虑安全问题。如图8.2所示，当发生或计划更改时，要决定更改是重大的还是较小的。重大的更改，如重新设计系统的结构，会极大影响到系统。重大更改经常涉及到购买新的硬件、软件、服务或对新的软件模块进行开发。
机构无需设定决定重大－较小更改的界线。使用以下方法的组合可以构成具有弹性的辨别两种更改的标准。
重大更改 重大更改需要进行分析以确定安全需求。可以使用上面描述的过程，当然分析可能仅仅集中在发生或将要发生更改的领域。如果在整个生命周期中原来的分析和系统的更改都被记录在文档中，分析一般会很容易。因为这种更改源自重要系统的获得、开发工作，或政策的更改，所以应该重新审批系统以确保残留风险仍然是可接受的。
较小更改 对系统的许多更改无需进行像对重大更改那样的深入分析，但是还是需要一些分析。每一个更改都可以进行有限的分析来衡量优点（收益）和缺点（成本），这甚至可以在会议上当场进行。即使进行非正式的分析，决定还是应该被适当地记录在文档中。在这个过程中，即使是“很小”的决定也最好是基于风险作出的。
8.4.4.4 定期重新审批
从整体上对系统安全进行定期的重新检查是有益的。为重新审批而进行的分析应该涉及到这种问题：安全仍然是充分的吗？需要重大更改吗？
重新审批应该涉及到高级别的安全和管理层的关注以及安全的实施。并不总是需要在重新审批时进行新的风险评估或认证，但是这些活动是互相支持的（并且都需要定期执行）。系统进行更改的范围越广，所要进行分析（如风险评估或重新认证）的范围也就越广泛。风险分析可能发现与系统更改有关的安全问题。系统被更改后，可能需要对其进行测试（包括认证）。然后如果风险是可接受的，管理层就重新批准系统的运行。
8.4.5 废弃
计算机系统生命周期的废弃阶段涉及到信息、硬件和软件的处置。信息可以转移到其它系统、存档、丢弃或销毁。当存档信息时应该考虑未来取回信息的方法。用于创建记录的技术在未来可能无法随时获得。
硬件和软件可以被出售，赠送或丢弃。除了一些包含保密信息的存储介质只有用销毁的方式清除以外，很少有硬件需要被销毁。如果有必要的话，软件的处置应遵循许可证和其它与开发商的协议。一些许可证是针对站点的或包含防止软件被转移的其它协议。也可能要采取措施对数据进行加密以便将来使用，如采取适当的步骤确保对密钥的长期和安全存储。
8.5 相互关系
与许多管理控制一样，对生命周期的计划依赖于其它控制。三个联系紧密的控制领域是政策、保证和风险管理。
政策 针对系统的政策制定是确定安全需求的重要一环。
保证 良好的生命周期管理为在系统设计和运行中正确考虑安全问题提供保证。
风险管理 在系统的运行阶段对安全的维护是一种风险管理过程：分析风险、消减风险和监视防范措施。风险评估是设计系统安全和重新审批的关键部分。
8.6 费用考虑
安全是系统整个生命周期的一个要素。有时安全选择是很随意作出的，没有人分析选择的原因；有时安全选择是基于分析谨慎作出的。第一种情况可能造成系统处于恶劣的安全状态而容易遭受各种损失。第二种情况下，生命周期管理的花费要远远小于所避免的损失。生命周期管理的主要费用是人员费用和在生命周期中系统为了完成分析、检查和获得管理层批准而造成的延迟。
有可能对系统进行了过度管理：不必要地花费大量时间用于计划、设计和分析风险。计划本身不会推进机构的使命或业务。所以，虽然安全生命周期管理可以获得可观的收益，但是工作量还是要与系统的规模、复杂度、敏感性以及系统相关的风险相称。通常，系统的价值越高，系统的体系、技术和措施越新、系统安全失效后的影响越严重，越要花费更多的精力在生命周期管理上。
参考书目
Communications Security Establishment. A Framework for Security Risk Management in Information Technology Systems. Canada.
Dykman, Charlene A. ed., and Charles K. Davis, asc. ed. Control Objectives Controls in an Information Systems Environment: Objectives, Guidelines, and Audit Procedures. (fourth edition). Carol Stream, IL: The EDP Auditors Foundation, Inc., April 1992.
Guttman, Barbara. Computer Security Considerations in Federal Procurements: A Guide for Procurement Initiators, Contracting Officers, and Computer Security Officials. Special Publication 800-4. Gaithersburg, MD: National Institute of Standards and Technology, March 1992.
Institute of Internal Auditors Research Foundation. System Auditability and Control Report. Altamonte Springs, FL: The Institute of Internal Auditors, 1991.
Murphy, Michael, and Xenia Ley Parker. Handbook of EDP Auditing, especially Chapter 2 "The Auditing Profession," and Chapter 3, "The EDP Auditing Profession." Boston, MA: Warren, Gorham & Lamont, 1989.
National Bureau of Standards. Guideline for Computer Security Certification and Accreditation. Federal Information Processing Standard Publication 102. September 1983.
National Institute of Standards and Technology. "Disposition of Sensitive Automated Information." Computer Systems Laboratory Bulletin. October 1992.
National Institute of Standards and Technology. "Sensitivity of Information." Computer Systems Laboratory Bulletin. November 1992.
Office of Management and Budget. "Guidance for Preparation of Security Plans for Federal Computer Systems That Contain Sensitive Information." OMB Bulletin 90-08. 1990.
Ruthberg, Zella G, Bonnie T. Fisher and John W. Lainhart IV. System Development Auditor. Oxford, England: Elsevier Advanced Technology, 1991.
Ruthberg, Z., et al. Guide to Auditing for Controls and Security: A System Development Life Cycle Approach. Special Publication 500-153. Gaithersburg, MD: National Bureau of Standards. April 1988.
Vickers Benzel, T. C. Developing Trusted Systems Using DOD-STD-2167A. Oakland, CA: IEEE Computer Society Press, 1990.
Wood, C. "Building Security Into Your System Reduces the Risk of a Breach." LAN Times, 10(3), 1993. p 47