【CISSP学习笔记】6. 安全开发

该知识领域涉及如下考点，具体内容分布于如下各个子章节：

理解安全并将其融入软件开发生命周期 (SDLC) 中
在软件开发环境中识别和应用安全控制
评估软件安全的有效性
评估获得软件对安全的影响
定义并应用安全编码准则和标准

6.1. 系统开发控制

6.1.1. 软件开发

系统开发的每个阶段都应当考虑安全性，这些阶段涵盖整个软件开发过程。

6.1.1.1. 编程语言

编译后的代码通常不易被第三方操纵，然而用户也无法查看原始指令，所以恶意的(不熟练的)编程人员很容易在编译后的代码中嵌入后门和其他安全缺陷并绕过检测。
编程人员不易在解释弄代码中插入恶意代码，原因在于最终用户可以查看源码并检查代码的准确性。

6.1.1.1.1. 机器语言

计算机只能理解二进制代码，这些代码由一长串0、1组成。

6.1.1.1.2. 汇编语言

汇编语言使用一种助记符来表示CPU 指令，要求人们了解硬件专用的汇编指令。

6.1.1.1.3. 高级语言

6.1.1.1.3.1. 编译型语言

编程人员使用编译器工具将高级语言转为特定的OS 中可执行文件。
C/C++,Java,Fortran

6.1.1.1.4. 解释型语言

用户在系统中用解释器来执行源代码。
Python 、JS

6.1.1.2. 面向对象编程00P

6.1.1.2.1. 术语

消息
方法
行为
类
实例
继承
委托
多态
内聚
耦合

6.1.1.3. 库

开发者经常会引入开源或免费的软件库来提高开发效率(如0penSSL)。大部分库中会存在安全问题，比如知名的0penSSL的 “心脏出血”漏洞(CVE-2014-0160)。OpenSSL库是SSL (安全套接字层)和传输层安全性 (TLS) 协议，被用于成千上万的系统中，甚至很多用户都不知道自己用到了此漏洞组件。

6.1.1.4. 开发工具集

如帮助开发者提高开发效率的IDE,XCODE,Idea, 软件供应链攻击。比如2015年9月，非官方版本的Xcode(Mac OS系统的集成开发工具)被注入Xcode Ghost病毒，编译出的App 都将被注入病毒代码，12306、中兴银行等APP受到影响。

6.1.1.5. 保证

为确保在新应用程序构建的安全控制机制在系统的整个生命周期内能正确地实现安全策略，管理员会使用保证过程 (Assurance Procedures)。通用标准 (Common Criteria, 简称CC) 提供了一种标准化的方法，用于为政府采购提供保证。

6.1.1.6. 避免和缓解系统故障

无论开发团队经验多么丰富，都不能保证开发出的系统0缺陷。

6.1.1.6.1. 输入校验

6.1.1.6.2. 身份验证与会话管理

多因素身份验证
在安全、加密的信道上传输Cookie (随机标识符、过期时间)

6.1.1.6.3. 错误处理与日志记录

错误信息可能将敏感的内部信息暴露给攻击者，包括数据库的表结构、服务器 IP 地址等。应用程序应该被配置成将错误和其他妥全事徘的详细旨思记录发送到集中日志存储库。OWASP建议记录以下事件用于诊断安全问题和调查安全事件：

输入验证失败
认证失败
访问控制失败
篡改尝试
使用无效或过期的会话令牌
OS或APP引发的异常
管理特权的使用
TLS故障
加密错误

6.1.1.6.4. 故障防护和应急开放

故障不可预测，编程人员应该在代码中设计如何响应和处理故障，为系统故障做计划时有两个选择：

故障防护状态(fail-secure state)：系统进入高级别安全性(甚至可能完全禁用)直至管理员诊断问题并将系统还原至正常状态。【常用，能够防止未授权访问，如OS 蓝屏】
应急开放状态(fail-open state)：充许用户绕过失败的安全控制获得较高特权【罕见】。

6.1.2. SDLC

系统并发生命周期(System Development Lifeycle , 简称SDLC)，所有系统开发过程都包含一些相同活动，但可能名称各异。

6.1.2.1. 概念定义

项目用途以及系统大体需求

6.1.2.1.1. 功能需求确定

列出具体的系统功能

6.1.2.1.2. 三个主要特征

6.1.2.1.2.1. 输入

6.1.2.1.2.2. 行为

6.1.2.1.2.3. 输出

6.1.2.2. 控制规范开发

具有安全意识的组织会确保在系统中设计了合适的控制。将安全性设计到系统中不是一次性过程，必须主动例行。系统经常
在设计时缺乏安全性讦划，出漏洞后后开发人员才试图利用正确的安全机制更新系统。

确保只有授权用户才能访问系统，并且不允许他们超出授权级别。
系统必须通过正确的加密和数据保护技术来保护关键数据的保密性
系统需要提供审计跟踪来强制实施个人的问责性，还应当对提供非法活动的检测机制
必须解决可用性和容错问题

6.1.2.3. 设计评审

6.1.2.4. 编码

6.1.2.5. 编码评审

6.1.2.6. 系统测试

6.1.2.7. 维护和变更管理

6.1.3. 生命周期模型

6.1.3.1. 瀑布模型(Waterfall Model)

将SDLC 看作一系列反复活动(1970 Winston Royce提出)。传统瀑布模型分7个阶段，在一个阶段完成后，项目才进入下一个阶段。现代洁面模型允许开发者返回到之前的阶段，从而纠正后续阶段发现的错误。
在这里插入图片描述

6.1.3.2. 螺旋模型(Spiral Model)

允许瀑布类型的处理过程多次反复(1988 Barry Boehm 提出)。
在这里插入图片描述

可以看出螺旋模型封装了许多迭代瀑布模型。

6.1.3.2.1. 敏捷软件开发(Agile Software Development)

强调客户需求的和快速开发 (20世纪90年代中期) , 基本原则可以参阅链接

其他变种：Scrum (迭代式增量软件开发过程), Kanban, 极速应用开发(Rapid Application Development，RAD), 敏捷统一过程(Agile Unified Process,AUP),动态系统开发模型(Dynamic Systems Development Modei, DSDM),极限编程 (Extreme Programming,XP)

敏捷宣言包括软件开发的12条原则。其中三个被列为答案选择：

最大限度地增加未完成的工作量是至关重要的，
围绕有动力的个人构建项目，
并欢迎在整个开发过程中不断变化的需求。

敏捷并不认为清晰的文档是衡量进步的主要标准。相反，工作软件是衡量进步的主要标准。

6.1.3.2.2. SW-CMM

软件成熟能力成熟度模型。(Software Capabiltiy Maturity Model,简称 SW-CMM、CMM或SCMM) CMM背后的思想：软件的质量依赖于其开发过程的质量，具有以下阶段：

初始级 几乎或完全没有定义软件开发过程
可重复级 有基本的生命周期管理过程(代码复用)
定义级 标准化管理流程(需求管理、软件项目规划、质量保证和配置管理实践的使用)
管理级 定量衡量软件开发过程
优化级 持续改进(缺陷预防、变更管理)

6.1.3.2.3. 软件保证成熟度模型(Software Assurance Maturity Model，SAM)

SAMM 是 OWASP 维护的开源项目，它提供了将安全活动融入到软件开发与运营流程的框架，并提供能力帮忙企业评估成熟度。
SAMM主要有5个业务活动：

治理
设计
实现
验证
运营

在这里插入图片描述

Synopsys发布了软件安全构建成熟度模型 ( Building Security In Maturity Model,BSIMM) 用于评估组织的软件安全活动。

6.1.3.2.4. IDEAL 模型

SEI(Software Engineering Institute)开发了IDEAL模型，实现了多个 SW-CMM属性，包括以下5个阶段：

1、启动(对应SW-CMM 初始)
2、诊断(对应SW-CMM 可重复)
3、建立(对应SW-CMM 定义)
4、行动(对应SW-CMM 管理)
5、学习(对应SW-CMM 优化)

在这里插入图片描述

6.1.3.3. 甘特图与PERT

其特图是一种显示项目与进度之间相互关系的条形图，可帮助用户计划、协调和跟踪项目中的特定任务。
在这里插入图片描述

计划评审技术(Program Evaluation.Review Technique ,PERT)网络图来表达项目中各项活动的进度和它们之间的相互关系，并在此基础上进行网络分析和时间估计，用于协调整个计划的完成，它适合用于子任务很多，关系复杂的项目(区别于甘特图)

6.1.3.4. 变更和配置管理

变更管理流程：

1、请求控制
2、变更控制
3、发布控制

配置管理：

配置标识
配置控制
配置状态统计
配置审计

配置控制确保根据变更控制和配置管理过程对软件版本进行更改。
可以考虑将变更管理作为安全工具，如文件完整性监控工具Tripwire可监控系统发生的变化，可以将其集成到变更管理流程中。

6.1.3.5. Dev0ps方法

DevOps是开发与运营的组合，开发+运营团队一起合作才能满足业务需求。有三个要素：

软件开发
质量保证
IT运营

在这里插入图片描述

6.1.3.6. API

API 也会存在安全缺陷，可通过API Fuzz来发现安全问题。

6.1.3.7. 软件测试

按开发阶段划分：

单元测试
集成测试
系统测试

回归测试：修改了旧代码后，重新进行测试以确认修改没有引入新的错误
冒烟测试：开发人员开发完成后送给测试人员测试，测试人员先进行冒烟，用以保证基本功能正确，不阻碍后续测试
验收测试

按是否查看代码划分：

白盒测试
黑盒测试
灰盒测试

按是否运行划分：

静态测试
动态测试

6.1.3.8. 代码仓库

控制开发人员对仓库的访问，不要在公共代码仓库中包含敏感信息，尤其是API密钥、用户口令之类的信息。

6.1.3.9. SLA(Service Level Agreements)

服务水平协议是服务提供商和服务供应商都认同的保持适当服务水平的方法，会涉及：

系统正常运行时间(如总工作时间占比)：最大连续停机时间(以秒、分钟为单位)
高峰负荷
平均负荷
诊断责任
故障切换时间

6.1.3.10. 三方件采购

组织在购买和配置软件时，安全专业人员必须：

正确配置软件以满足安全目标
关注供应商安金公告和补丁，及时修复新漏洞

6.2. 创建数据库和数据仓库

6.2.1. 数据库管理系统DBMS 的体系结构

6.2.1.1. 层次式和分布式数据库

在分层数据库中，数据以树状结构组织。在这种结构中，所有数据记录最终都链接到单个父记录。也称为所有者记录。记录芝简的链接通常被播途为交孕买絮。
分布式数据库是用计算机网络将物理上分散的多个数据库单元连接起来组成的一个逻辑上统一的数据库。每个被连接起来的数据库单元称为站点或节点。分布式数据库有二个统一的数据库管理系统来进行管理，称为分布式数据库管理系统。分布式
数据库的基本特点包括：

物理分布性
逻辑整体性
站点自治性。

6.2.1.2. 关系数据库

行和列组成的平面二维表，每行表示一条记录，记录可以用多种建标识：
候选键：可唯一标识表中记录的属性子集

主键：从候选键中选出的用来唯一标识记录的键
外键：强制在两个表乏间建立关系”(参照完整性)

所有关系数据库采用结构化查询语言(SQL)来为用户存储、检索和更改数据。 SQL分为：
— 数据定义语言 DDL(CREATE)

数据操纵语言 DML(如ADD、DELETE)
数据控制语言 DCL( 如GRANT、Revoke)

6.2.2. 数据库事务

ACID:

原子性(Atomicity)

事务的任何一部分失败，整个事务都会回滚

一致性(Consistency)

数据库总是从一个一致性的状态转换到另外一个一致性的状态。事务成功提交则数据修改，事务错误则回滚到数据回到原来的状态

隔离性(Isolation)

事务之间彼此独立

持久性(Durability)

记录一旦提交给数据库，就会被保留下来，数据库通过备份机制(事务日志)确保持久性

丢失的更新 当一个事务向数据库写入的值覆盖了具有早期优先级的事务所需的值，导致这些事务读取的值不正确时
脏读取 当一个事务从数据库中读取由另一个未提交的事务写入的值时
不正确的汇总 当一个事务使用聚合函数对存储在数据库中的数据进行汇总，而另一个事务正在对数据库进行修改，导致汇总中包含不正确的信息时。