CISSP官方学习指南第7版#第20章

=Start=

缘由：

备考CISSP，学习、整理在看《CISSP官方学习指南（第7版）》时的一些知识点，方便以后快速复习。

正文：

参考解答：

第20章软件开发安全

本章中覆盖的CISSP考试大纲包含：
•A.在软件开发生命周期中理解应用安全
　　A.1 开发方法论(例如，敏捷开发、瀑布模型)
　　A.2 成熟度模型
　　A.3 运行和维护
　　A.4 变更管理
　　A.5 集成产品开发团队(如DevOps)
•B.在开发环境中执行安全控制
B.1 软件环境安全
B.3 安全编码中的配置管理
B.4 代码仓库的安全说明
B.5 API安全
•C.评估软件安全的有效性
C.1 审计和记录变更
C.2 风险分析和缓解
C.3 验收测试
•D.评估软件获取的安全性影响

软件开发是由许多拥有不同技能和不同安全意识的开发者实施的一项复杂和具有挑战性的任务。这些开发人员创建和修改的应用程序通常会使用敏感数据，还会和公众交互。这给企业安全带来了巨大的风险，并且信息安全专家必须理解这些风险，对风险和业务需求做出平衡，并且实施适当的风险缓解机制。

20.1 系统开发控制概述

为了实现灵活的操作目标，很多公司都使用定制开发的硬件和软件系统。由于恶意的和/或粗心的开发人员创建后门、缓冲区溢出漏洞或其他导致系统被恶意人员利用的弱点，因此这些定制解决方案可能存在巨大的安全漏洞。

为了防范这些漏洞，在整个系统开发的生命周期内引入安全性是至关重要的。有组织、有条理的过程可以帮助确保解决方案满足功能需求以及安全性指导原则。安全性关注应当是从事解决方案开发的信息安全专家的重点考虑事项，接下来将针对这些关注内容对一系列系统开发行为进行讨论。

20.1.1 软件开发

在系统开发的每个阶段都应当考虑安全性，这些阶段包括整个软件开发过程。开发人员应该力求在他们开发的所有应用程序中构建安全性，并且为关键的应用程序和拥有敏感信息的应用程序提供更高的安全级别。因为在软件开发项目的初期，给系统构建安全性比在现有系统中添加安全性容易得多，所以在初期就考虑安全性是极为重要的。

1.编程语言

在CISSP考试中，还应当熟悉编程语言的发展，各代编程语言的定义如下：
.第1代语言(1GL)包括所有机器语言。
·第2代语言(2GL)包括所有汇编语言。
.第3代语言(3GL)包括所有编译语言。
·第4代语言(4GL)试图接近于自然语言，包括数据库使用的SQL
·第5代语言(5GL)九许编程人员创建使用可视接口的代码。

2.面向对象编程

3.保证

4.避免和缓解系统故障(输入验证、故障防护和应急开放)

20.1.2 系统开发生命周期

如果在系统或应用程序的整个生命周期内都进行计划和管理，那么安全性是最有效的。管理员利用项目管理使项目的开发遵循目标，并且逐步实现整个产品的目的。通常，项目管理使用生命周期模型进行组织，以便指导开发过程。使用正规化的生命周期模型有助于确保良好的编程实践以及在产品开发的每个阶段都嵌入安全性。

所有系统开发过程都应当具有几个共用的活动。虽然可能没有必要共享相同的名字，但是这些核心的动作对于开发健全的、安全的系统来说都是必不可少的。下面列出了这些动作：
1.概念定义
2.功能需求确定
3.控制规范的开发
4.设计审查
5.代码审查走查
6.用户验收测试
7.维护和变更管理

20.1.3 生命周期模型

1.瀑布模型
瀑布模型最初是由 Winston Royce 在1970年开发的，它试图将系统开发的生命周期看作一系列反复活动。传统的瀑布模型有7个开发阶段。在每个阶段完成时，项目会进入下一个阶段。正如相反箭头所示，现代的瀑布模型准许开发返回到先前的阶段，从而纠正在后续阶段发现的错误。这通常被称为瀑布模型的反馈循环特征(feedback loop characteristic)。

系统需求 <=> 软件需求 <=> 初步设计 <=> 详细设计 <=> 编码及调试 <=> 测试 <=> 运行与维护

瀑布模型是在考虑返回先前阶段以纠正系统错误的必要性的情况下，建立软件开发过程的模型的第一次全面尝试。然而，这个（瀑布）模型受到的一个主要批评是：只准许开发人员后退一个阶段。瀑布模型并没有对开发周期后期发现错误做出相应规定。

2.螺旋模型
1988年，TRW的 Barry Boehm 提出了一种替代的生命周期模型，允许瀑布类型处理过程多次反复。因为螺旋模型封装了许多迭代的其他模型(也就是瀑布模型)，所以被称为元模型或”模型的模型”。

3.敏捷软件开发
最近，软件开发的敏捷模型己经在软件工程界越来越受欢迎。从20世纪90年代中期开始，开发者越来越接受避开过去僵化模式的软件开发方法，喜欢采用替代的、强调客户需求的和快速开发的新功能，并以代的方式满足这些需求。
敏捷开发方法在软件圈里有快速发展的势头，并且有很多变种，包括Scrum(迭代式增量软件开发过程)、敏捷统一过程(Agile Unified Process，AUP)、动态系统开发模型(Dynamic System Development Model，DSDM)和极限编程(Extreme Programming，XP)。

4.软件能力成熟度模型
Carnegie Mellon大学的软件工程学院(SEI)提出了软件能力成熟度模型(Software Capability Maturity Model，缩写为 SW-CMM 、CMM或SCMM)，这种模型主张所有从事软件开发的组织都依次经历不同的成熟阶段。 SW-CMM 描述了支持软件过程成熟度的原则与惯例，目的是：通过实现从特别混沌的过程到成熟的、有纪律的软件过程的发展路径，从而帮助软件组织改善软件过程的成熟度和质量。SW-CMM 背后的思想是软件的质量依赖于其开发过程的质量。
SW-CMM 具有下列阶段：

第1阶段：初始级在这个阶段，常常可以发现在无组织的工作模式中有很多努力工作的人。通常，这个阶段几乎没有或完全没有定义软件开发过程。
第2阶段：可重复级在这个阶段，出现基本的生命周期管理过程。开始有组织地重用代码，而且类似的项目期望具有可重复的结果。SEI将用于这个级别的主要处理范围定义为：需求管理、软件项目计划编制、软件项目跟踪和监督、软件转包合同管理、软件质量保证和软件配置管理。
第3阶段：定义级在这个阶段，软件开发人员依照一系列正式的、文档化的软件开发过程进
行操作。所有开发项目都在新的标准化管理模型的制约下进行。SEI将用于这个级别的主要处理范围定义为：组织处理中心、组织处理定义、培训计划、综合的软件管理、软件产品工程、团体之间的协调和对等复审。
第4阶段：管理级在这个阶段，软件处理过程的管理进入下一个级别。定量衡量被用来获得对开发过程的详细了解。SEI将用于这个级别的主要处理范固定义为：定量处理管理和软件质量管理。
第5阶段：优化级在优化的组织中，会采用一个继续改进的过程。成熟的软件开发过程已经确立，可以确保为了改善未来的结果将一个阶段的反馈返回给前一个阶段。SEI将用于这个级别的主要处理范围定义为：缺陷预防、技术更改管理和过程更改管理。

5.IDEAL模型
SEI还为软件开发确立了IDEAL模型，这种模型实现了许多SW-CMM属性。IDEAL模型具有下列5个阶段：

启动——在IDEAL模型的启动阶段，概述更改的业务原因，为举措提供支持，以及准备好恰当的基础设施。
诊断——在诊断阶段，工程师分析组织的当前状态，并且为更改给出一般性建议。
建立——在建立阶段，组织采用诊断阶段的一般建议，并且开发帮助实现这些更改的具体动作计划。
行动——在行动阶段，停止”讨论”开始”执行”。组织开发解决方案，随后测试、改进和实现解决方案。
学习——与任何质量改进过程一样，组织必须不断分析其努力的结果，从而确定是否己实现期望的目标，必要时建议采取新的行动，使组织重返正轨。

为了帮助记忆 SW-CMM 和 IDEAL 模型的10个级别名的首字母(IIDREDAMLO)，可以想象一下正坐在病医生办公室的长上说着：”I…I，Dr.Ed，am lo(w)”。如果能够记住这句，那么就可以抽取这些级别名的首字母。如果将这些字母排成两列，那么就可以按照顺序重构两个系统的级别名。

20.1.4 甘特图与PERT

甘特图是一种显示不同时间项目和调度之间相互关系的条形图，提供了帮助计划、协调和跟踪项目中特定任务的调度图表。

计划评审技术(Program Evaluation Review Technique，PERT)是一种项目调度工具，这种工具被用于在开发中判断软件产品的大小并且为风险评估计算标准偏差(StandardDeviation，SD)。PERT将估计的每个组件的最小可能大小、最可能的大小以及最大可能大小联系在一起。PERT被用于直接改进项目管理和软件编码，以便开发更有效的软件。随着编程和管理能力得到改善，软件的实际生成大小应当更小。

20.1.5 变更和配置管理

一旦软件发布到生产环境，用户必然会请求增加新功能、修正bug以及对代码的其他更改。正像组织开发软件的严密过程一样，同样也必须以有组织的方式管理所请求的更改。这些变更必须被记录到中央存储库，以支持将来的审计、调查和分析需求。这种变更管理流程有三个基本组件：

请求控制——请求控制过程提供了一个有组织的框架，在这个框架内，用户可以请求变更，管理者可以进行成本/效益分析，开发人员可以优化任务。
变更控制——开发人员使用变更控制过程来重新创建用户遭遇的特定情况并且分析能够进行弥补的适当变更。变更控制过程也提供了一个有组织的框架。在这个框架内，多个开发人员可以在部署到生产环境之前创建和测试某个解决方案。变更控制包括：遵守质量控制约束，开发用于更新或更改部署的工具，正确记录任何编码变化，以及将新代码对安全性的负面影响最小化。
发布控制——一旦完成变更，它们就必须通过发布控制过程来进行发布认可。发布控制过程中一个必不可少的步骤是：复核并确保更改过程中作为编程辅助设计插入的任何代码(例如，调试代码和/或后门)，在发布新软件产品之前都已被删除。发布控制还应当包括验收测试，从而确保对终端用户工作任务的任何更改都是可理解的和有用的。

除了更改控制过程之外，安全管理员还应当意识到配置管理的重要性。配置管理过程用于控制整个组织范围内使用的软件版本，并且正式跟踪和控制对软件配置的更改。这个过程具有下列4个主要组件：

配置标识——在配置标识过程中，管理员记录整个组织范围内的软件产品的配置。
配置控制——配置控制确保对软件版本的更改要与更改控制和配置管理策略一致。只有符合这些策略的授权分发才能够执行更新操作。
配置状态统计——用于跟踪所有发生的授权更改的正规过程。
配置审计——进行定期的配置审计能够确保实际的生产环境与统计记录一致，以及确保没有发生未授权的配置变更。

总之，变更控制与配置管理技术一起构成了软件工程体系的重要部分，并且能够防止组织遭遇与开发相关的安全性问题。

20.1.6 DevOps方法

最近，许多技术专业人士意识到，在软件开发、质量保证和技术操作这些主要的IT职能之间存在脱节的情况。这些职能，通常配备给不同类型的个人，并且还位于不同的组织，通常彼此冲突。这种冲突导致在创建代码、测试和部署到生产环境中的长时间延迟。当问题出现时，团队不是一起合作解决问题，而是经常”踢皮球”，这导致官僚作风。

DevOps方法通过将三种职能集中在一个操作模型中来解决这些问题。DevOps这个词是开发(Development)和操作(Operations)的组合，表示这些功能必须合井和合作才能满足业务需求。DevOps模型说明了软件开发、质量保证和IT操作的重叠性。DevOps模型与敏捷开发方法紧密配合，旨在显著地缩短开发、测试和部署软件更改所需的时间。

虽然传统方法常常导致主要软件部署很少，或许每年一次，但是使用DevOps模型的组织通常每天部署代码多次。一些组织甚至努力实现连续部署的目标，其中代码可以每天部署几十甚至几百次。

20.1.7 应用编程接口

尽管早期的Web应用程序通常是处理用户请求和提供输出的独立系统，但现代的Web应用程序越来越复杂，它们通常包括多个不同的Web服务之间的交互。例如，一个零售网站可能会利用一个外部信用卡处理服务，允许用户在社交媒体上分享他们的采购信息，与运输供应网站集成，并在其他网站上提供推荐计划。

为了使这些跨站点功能正确工作，网站必须相互交互。许多组织为了这个目标提供应用编程接口(API)。API允许应用程序开发人员绕过传统的网页，井通过函数调用直接与底层服务进行交互。

20.1.8 软件测试

作为开发过程的一部分，组织在内部分发(或市场发布)任何软件之前都应当对其进行彻底测试。

进行测试的最佳时间是设计模块之时。换句话说，用于测试某个产品的机制和用于研究该产品的数据集应当与产品本身同时进行设计。编程团队应当开发特殊的数据测试组以及预先知道正确的输出结果，通过这些数据测试组能够测试软件所有可能的执行路径。

20.1.9 代码仓库

软件开发需要共同的努力，大型软件项目需要开发人员团队可以同时承担代码的不同部分的工作。使情况进一步复杂化的事实是，这些开发者可能在地理上分散在世界各地。

代码仓库提供了支持这些协作的几个重要功能。首先，它们作为开发人员放置源代码的中心存储点。此外，代码仓库(如GitHub、Bitbucket和SourceForge)还提供版本控制、错误跟踪、Web托管、发布管理和支持软件开发的通信功能。

代码仓库是促进软件开发的出色的协作工具，但它们也有自己的安全风险。首先，开发人员必须适当地控制对仓库的访问。一些仓库，如支持开源软件开发的仓库，可能允许公众访问。其他仓库，如托管含有商业机密信息的代码，可能受到更多限制，并限制对授权开发者的访问。仓库所有者必须仔细设计访问控制，仅允许适当的用户读取和/或写入访问权限。

20.1.10 服务等级协议

使用服务等级协议(SLA)是越来越流行的方式，是被服务提供商和服务供应商都认同的确保组织向内部和/或外部客户提供服务，并保持适当服务水平的一种方法。对于组织的持续生存能力，把所有的数字电路，应用程序、信息处理系统、数据库或其他关键组件都置入SLA是明智的，也是至关重要的。SLA中通常涉及以下问题：
•系统正常运行时间(如总工作时间的百分比)
•最大连续停机时间(以秒/分钟为单位等)
•高峰负荷
•平均负荷
•责任诊断
•故障切换时间(如冗余到位)

如果不能维持协议，服务级别协议通常还包括财务和其他合约商讨好的补救措施。例如，如果关键电路停机超过15分钟，服务提供商可能同意放弃该电路上的所有费用一周。

20.1.11 软件采购

企业使用的大多数软件都不是内部开发的，而是从供应商那里采购。这些软件中的一些被购买并运行在组织管理的服务器上，无论是在内部还是在基础设施即服务(1坦白环境中。其他软件是以软件即服务(SaaS)方式通过Web浏览器从互联网购买和提供的。大多数组织根据业务需求和软件可用性，结合使用这些方法。

在任何一种情况下，安全都应该被关注。当组织购买和配置软件本身时，安全专业人员必须了解软件的正确配置以满足安全目标。他们还必须对安全公告和补丁保持警惕，以纠正新发现的漏洞。不履行这些义务可能会导致不安全的环境。

在SaaS环境中，大多数安全责任由供应商负责，但是组织的安全人员也不能逃脱责任。虽然他们可能不负责同样多的配置，但他们现在负责监控供应商的安全。这可能包括审计、评估、漏洞扫描和旨在验证供应商是否保持适当控制的其他措施。

20.2 创建数据库和数据仓储

20.2.1 数据库管理系统的体系结构

尽管目前存在多种可用的数据库管理系统(DBMS)，但当今的大多数系统都使用一种被称为关系型数据库管理系统(RDBMS)的技术。因此，下面的内容主要关注于关系数据库。不过，我们首先要讨论两个重要的DBMS体系结构：层次式数据库和分布式数据库。

1.层次式和分布式数据库
层次式数据模型将关联的记录和字段组合为一个逻辑树结构。运会导致一个”一对多”数据模型，其中的每个节点可能不具有子节点，也可能具有一个或多个子节点，但是都只具有一个父节点。
分布式数据模型将数据存储在多个数据库中，不过这些数据库是逻辑连接的。即使数据库由通过互联网相互连接的许多部分组成，用户也仍然将数据库理解为单个实体。每个字段都具有许多子字段和父字段。因此，分布式数据库的数据映射关系是多对多。

2.关系数据库
关系数据库是由行和列组成的平面二维表。实际上，每个表看起来类似一个电子表格文件。行列结构提供了一对一数据映射关系。关系数据库的主要构件是表(也被称为关系)。每个表都包含一组相关的记录。

主键：从表的这组候选键中选出的用来唯一标识表中记录的键被称为主键。每个表都只有一个主键，由数据库设计者从这组候选键中选出。通过不准许利用相同主键插入多个记录，RDBMS强制实施了主键的唯一性。
外键：外键被用于强制在两个表之间建立关系(也称为参照完整性)。参照完整性确保：如果一个表包含一个外键，那么它对应于关系中另一个表内仍然存在的主键。
候选键：可以被用于唯一标识表中记录的属性子集。在同一个表中，对于组成一个候选键的所有属性而言，任何两条记录的这些属性值都不完全相同。每个表都可能有一个或多个候选键，它们从列的头部选出。

20.2.2 数据库事务

关系数据库支持事务的显式和隐式使用，从而确保数据的完整性。每个事务都是SQL指令的离散集，作为一个组的这些SQL指令要么成功，要么失败。事务的一部分成功而另一部分失败的情况不可能出现。

所有的数据库事务都具有4个必需的特征：原子性、一致性、隔离性以及持久性。这些属性合称为ACID模型，这是数据库管理系统开发中的一个关键概念。下面简要介绍了这4种需求：

原子性——数据库事务必须是原子的，也就是说，必须是”要么全有，要么全无”的事务。如果事务的任何部分失败，那么整个事务都会被回攘，就像什么也没发生一样。
一致性——所有事务都必须在与数据库所有规则(例如所有记录都具有唯一的主键)一致的环境中开始操作。事务结束时，无论事务本身操作期间是否违反了数据库的规则，数据库都必须再次与这些规则一致。其他任何事务都不能利用某个事务执行期间可能产生的任何不一致数据。
隔离性——隔离性原则要求事务彼此之间独立操作。如果数据库接收到两个更改相同数据的SQL事务，那么在一个事务被允许更改相同数据之前，另一个事务必须完全结束。隔离性能够防止一个事务处理另一个事务中途生成的无效数据。
持久性——数据库事务必须是持久的，也就是说一旦被提交给数据库，就会被保留下来。数据库通过使用备份机制(例如事务日志)确保持久性。

20.2.3 多级数据库的安全性

你曾经在第1章学习过，基于分配给数据客体和单独用户的安全性标签，很多组织使用数据分类方案强制实施访问控制限制。当得到组织安全策略的委托授权时，这种分类概念还必须被延伸至组织的数据库。

多级安全性数据库包含大量不同分类级别的信息，它们必须对分配给用户的标签进行验证，并且根据用户的请求只提供适当的信息。然而，考虑到数据库的安全性，这种概念显得稍微复杂了一些。
要求多级安全性时，管理员和开发人员致力于使数据满足各种不同安全需求是必不可少的。将分类级别和刀或”知其所需”需求不同的数据混合在一起被称为数据库污染，这是一个重大的安全风险。通常，管理员会通过部署可信前端为旧式的或不安全的DBMS添加多级安全性。

20.2.4 ODBC

开放数据库互连(ODBC)是一种数据库特性，也就是在不必分别针对交互的每种数据库类型直接进行编程的情况下，允许应用程序与不同数据库类型通信。ODBC扮演了应用程序和后端数据库驱动程序之间代理的角色，使应用程序编程人员能够自由创建解决方案，而不必考虑后端的数据库系统。

20.3 存储数据和信息

数据库管理系统己经帮助加强了数据的力量，并且获得了对可以访问数据的人和可以对数据执行的操作所进行的少量控制。然而，安全专家必须记住的是，DBMS安全性只适用于通过传统的”前门”渠道访问信息。数据还通过计算机的存储资源(内存和物理介质)进行处理。为了确保这些基本的资源免受安全漏洞的威胁，就必须采取预防措施。毕竟，我们永远都不会将大量的时间和金钱花费在只保护前门而令后门大开，是吗?

20.3.1 存储器的类型

现代计算机系统使用几种类型的存储器来保存系统和用户的数据。为了满足组织对计算的要求，系统要在各种存储类型间进行平衡处理。目前常用的存储类型包括：
主存：
辅存：
虚拟内存：
虚拟存储器：
随机访问存储器：
顺序访问存储器：
易失性存储器：
非易失性存储器：

20.3.2 存储器威胁

信息安全专家应当意识到两种针对数据存储系统的威胁。第一种威胁是无论正在使用哪种类型的存储器，都存在对存储器资源的非法访问。如果管理员不实行恰当的文件系统访问控制，那么入侵者就可能通过浏览文件系统偶然发现敏感的数据。在更加敏感的环境中，管理员还应当防止绕过操作系统控制直接访问物理存储介质以检索数据的攻击行为。使用加密文件系统是最好的办法，只有通过主操作系统才可以被访问。此外，在多级安全性环境中运作的系统应当通过提供恰当的控制来确保共享内存和存储器资源时提供故障安全(fail-safe)控制，从而使某个分类级别的数据对于较低分类级别的使用者来说是不可读取的。

隐蔽通道攻击是对存储器资源的第二种主要威胁。隐敲存储通道准许通过直接或间接地操纵共享存储介质，在两个分类级别之间传输敏感的数据。这可能与向不经意间共享的内存或物理存储器的一部分写入敏感数据一样简单。更复杂的隐蔽存储通道可能操纵磁盘的可用空间或文件大小，在安全级别之间偷偷地传送信息。要了解隐蔽通道分析的更多信息，请参看第8章”安全模型的原则、设计和能力”。

20.4 理解基于知识的系统

20.4.1 专家系统

专家系统试图具体化人类在某个特殊学科累积的知识，并且以一致的方式将它们应用于将来的决定。一些研究己经表明：在正确开发和实现专家系统之后，专家系统常常能够做出比人类的常规决策更好的决定。每个专家系统都有两个主要的组件：知识库和推理引擎。

专家系统并非万无一失，它们的优劣完全取决于知识库中的数据和推理引擎实施的决策制订算法。不过，专家系统在紧迫的情况下有一个主要的优点，它们的决策不涉及情绪影响。专家系统可能在一些情况中扮演重要的角色，例如紧急事件、股票交易和其他有时因情绪因素妨碍做出合理决策的情况。由于这些原因，很多贷款机构现在采用专家系统来做出信用决策，而不是相信贷款主管所说的话”好，虽然Jim一直没有准时付账，但是他看起来是个相当不错的人。”

20.4.2 神经网络

在神经网络中，计算单元链被用来尝试模仿人脑的生物学推理过程。在专家系统中，一系列规则被存储在知识库中，而在神经网络中则建立了互相插入和最终合计生成预期输出结果的计算决策长链。

需要记住的是，所设计出的神经系统要想达到实际的人类推理能力还有待时日。尽管如此，神经网络仍然在推动人工智能领越当前的状态，在这方面显示出了巨大的潜力。神经网络的优点包括线型、输入-输出映射和自适应性。在用于语音识别、脸部识别、天气预报以及关于意识与思考模型研究的神经网络实现中，这些优点十分明显。

典型的神经网络涉及很多层次的合计，每一层的合计都需要加权信息以反映在整个决策制定过程中计算的相对重要性。针对期待神经网络做出的每种决策，这些权值必须是被定制的。这可以在培训阶段实现，在这个阶段，网络被提供正确决策己知的输入信息。这个算法随后进行这些决策的逆向工作，从而为计算链中的每个节点确定正确的权值。这种活动被称为Delta规则或学习规则。通过使用Delta规则，神经网络就能够从经验中学习知识。

20.4.3 决策支持系统

决策支持系统(DecisionSupportSystem，DSS)是一种知识型应用，它分析业务数据并且以更容易做出业务决策的形式提供给用户。决策支持系统更多被视为信息型应用而不是操作型应用。DSS常常被知识型员工(例如服务台人员或客户支持人员)和销售服务人员(例如电话推销员)所使用。

20.4.4 安全性应用

专家系统和神经网络都在计算机安全领域具有很多应用。这些系统提供的一个主要优点是它们快速做出一致决策的能力。计算机安全性方面的一个主要问题是，系统管理员没有能力为了寻找异常而对大量的日志记录和审计跟踪数据进行一致的、彻底的分析。这似乎是天生的一对矛盾！

20.5 本章小结

数据很快成为许多组织拥有的最有价值的资源。因此，信息安全从业人员了解保护数据自身以及有助于处理数据的应用程序和系统的必要性是十分重要的。在每个充分了解相关技术的组织中，都必须实现针对恶意代码、数据库脆弱性和系统/应用程序开发缺陷的防护。
恶意代码对象给组织的计算资源带来威胁。在非分布式环境中，这样的威胁包括病毒、逻辑炸弹、特洛伊木马和蠕虫。
此时，你一定认识到了为这些有价值的信息资源设置充分的访问控制和审计跟踪的重要性。数据库安全性是一个快速增长的领域，如果数据库在安全责任中扮演重要的角色，那么我们就应当花一些时间请教数据库管理员并学习相关课程、书籍和基础理论。这是一项颇有价值的投资。
最后，在系统和应用程序的开发过程中，为了确保这些过程的最终产品与安全环境中的操作兼容，可以使用多种控制手段。这些控制手段包括进程隔离、硬件划分抽象和服务等级协议。始终应当在所有开发项目的早期计划编制阶段引入安全性，并且在产品的设计、开发、部署和维护阶段持续进行监控。

20.6 考试要点

解释关系数据库管理系统(RDBMS)的基本体系结构。了解关系数据库的结构。能够解释表(关系)、行(记录/元组)和列(属性)的功能。知道如何在表和各种键类型的角色间定义关系。描述由聚合和推理形成的数据库安全威胁。
知道各种存储器类型。解释主存储器、虚拟存储器、辅助存储器和虚拟存储器、随机访问存储器和顺序访问存储器、易失性存储器和非易失性存储器之间的区别。
解释专家系统和神经网络如何工作。专家系统包括两个主要的组件：包含一系列”if/then”规则的知识库；使用知识库信息得到其他数据的推理引擎。神经网络模拟人类大脑的运作，在有限的范围内通过安排一系列的分层计算来解决问题。神经网络需要针对特定的问题进行大量的训练，才能够提供解决方案。
理解系统开发的模型。瀑布模型描述了一个连续的开发过程，导致最终产品的开发。如果发现错误，那么开发人员只能回退一个阶段。螺旋模型反复使用了几个瀑布模型，从而生成许多详细说明的和完全测试的原型。敏捷开发模型将重点放在客户的需求上，并快速开发新的功能，以迭代的方式满足这些需求。
描述软件开发成熟度模型。知道成熟度模型能帮助组织通过实施从临时的、混乱的过程到成熟的、有纪律的软件开发过程的进化路径，从而提高软件开发过程的成熟度和质量。能够描述 SW-CMM 和IDEAL模型。
理解变更和配置管理的重要性。知道变更控制的三个基本组件请求控制、变更控制、发布控制，以及它们对安全的贡献。解释配置管理如何控制在组织中使用的软件版本。
理解测试的重要性。软件测试应当被设计为软件开发过程的一部分。软件测试应当作为改善设计、开发和产品化过程的管理工具。

参考链接：

CISSP官方学习指南第7版（中文）-文字版带完整书签

=END=

29 12 月, 2017

Docker

KnowledgeBase, Security

CISSP, SDL, 专家系统, 成熟度模型, 瀑布模型