一、SDLC中集成安全
系统开发生命周期
1. 开发过程中的核心活动
尽管各开发周期模型不同，但都会包含这些核心活动
概念定义(项目用途和系统大致需求) -- 需求确定 -- 设计及评审 - 编码 - 编码评审 - 测试 - 维护与变更管理
2. SDLC模型
3. 项目管理工具
甘特图： 能清晰地描述每个任务从什么时候开始，到什么时候结束，以及任务之间的并行关系。但它不能清晰地反应出任务之间的依赖关系
PERT：描绘出项目包含的各种活动的先后次序，标明每项活动的时间或相关的成本，能清晰地描述子任务之间的依赖关系
4. 变更与配置管理
软件发布到生产环境后，用户必然要求增加新需求，这类变更需要一个变更管理流程来支持
5. DevOps
通过将软件开发、质量保证和IT运维职能集中到一个操作模型中，防止不同职能人员之间踢皮球，进而大幅缩短软件开发、测试和部署所需的时间。
使用DevOps模型和CI/CD，组织希望实现连续部署目标，每日部署几十到几百次(这么高的频率真的有必要？)
二、开发环境安全
代码仓库-code repository
代码仓库存储代码并支持协作，常见的有GitHub, GitLab, SourceForge, SVN等。代码仓库需要实现合适的访问控制。如果是公开代码库，必须注意不能包含敏感信息。
真实故事：前同事因为将公司数据库配置文件拷贝到个人在GitHub上的公开库，被安全人员扫描发现，隔天就被解除了合同。
三、软件测试
代码审查-Code Review
代码审查也被称为同行评审-peer review， 开发人员编写的代码交给其他开发人员检查是否有缺陷。
最正式的代码审查是 范根检查法-Fagan inspection， 它有严格的审查和测试过程。步骤为： 1-规划， 2-概述， 3-准备，4-审查， 5-返工， 6-追查。
其他代码审查方式： 1）会议上团队走查-walk through代码； 2）资深人员手动代码审查，并批准代码； 3）使用自动化代码审查工具。
测试
1. 静态测试
在不运行代码的情况下，对源代码或编译后的程序进行检查， 一般使用自动化检测工具
2. 动态测试
在软件运行环境下进行检测，比如常规的功能测试，也包含漏洞扫描，渗透测试。
3. 模糊测试- Fuzz Testing
动态测试的一种，向软件提供不同类型的输入来测试软件功能与性能
突变模糊测试-Mutation/Dumb：通过实际操作作为输入，然后自动生成模糊输入，进行功能测试
智能模糊测试： 设计数据模型来创建新的输入值
工具： zzuf， 可以实现突变模糊测试的自动化
4. 接口测试
包括三类： API测试，UI测试，物理接口测试。 请注意 网络接口测试不属于该系列。
5. 误用例测试
测试错误的使用场景
6. 白盒测试
检查代码内部逻辑结构，并逐行执行代码，发现缺陷
7. 黑盒测试
从用户角度来检查程序，不访问内部代码。 用户验收测试与回归测试都是黑盒测试的一种
回归测试：验证新引入的功能或修改是否导致原有功能出现缺陷
8. 灰盒测试
结合源代码从用户角度进行软件测试
9. 测试覆盖率
测试覆盖率 = 已完成测试的用例数量 / 全部测试用例的数量
1）分支覆盖率-branch：每个If语句都有被执行。并不包含满足if条件下的具体逻辑，只要验证了if条件语句有行。
2）条件覆盖率-condition：每个输入条件下的逻辑都有被测试到
3）函数覆盖率-function: 每个函数都有被调用和执行
4）循环覆盖率-Loop： 代码中的循环都有被执行，一次或多次
5）语句覆盖率-statement： 每行代码都有被执行
网站监测
1. 被动监测： 捕获网站的实际流量进行分析。 RUM-Real User Monitoring 真实用户监控 追踪单个用户与网站的互动
2. 综合监测(主动监测)： 执行复杂的脚本来对网站执行伪造的事务活动，评估其性能
四、评估软件安全
保证流程-Assurance
用于确保在系统的整个生命周期内都能通过构建的安全控制机制正确实现安全策略
通用标准(CC-Common Criteria)是一种适用于政府采购的标准化保证方法
SLA-服务水平协议
采购外部服务时，需要通过SLA约定关键组件的服务能力，通常包括： 系统正常运行时间，最大连续停机时间，性能负载，故障切换时间等
五、编码指南
避免系统故障的方法
1. 输入验证(Input Validation): 对用户输入进行检查，合适是否符合系统期望，并且可改变输入替换成安全值。 输入验证应该在服务器端进行，用户端的验证代码可被用户轻易绕过。输入验证可用于缓解 SQL注入，XSS，CSRF，缓冲区溢出等攻击风险
2. 身份验证与会话管理(Authentication and Session Management)：利用身份验证来确保用户只能执行被授权的操作，针对敏感信息和关键业务活动，需要使用MFA。会话管理要满足1-通过只在安全加密信道传输Cookie，2-使用随机且足够长的标识符，3-会话令牌有过期机制
3. 错误处理(Error Handling): 错误信息对调试代码很重要，调试模式的详细信息不能对外公开提供，避免暴露给攻击者。如下几种事件应该被记录并发送到SIEM： 1-输入验证失败； 2-认证尝试失败； 3-访问控制失败；4-篡改尝试； 5-使用无效或过期的会话令牌； 6-操作系统或应用程序异常； 7-特权账号的使用； 8-TLS错误； 9-加密错误
4. 系统故障保护计划： 有两种选择，1-故障防护(fail-secure/fail-closed) 将系统锁住或禁用，知道管理员修复系统， 比如Windows蓝屏机制。 2-应急开放(fail-safe/fail-open) 故障情况下允许用户绕过失败的安全控制，比如火灾报警触发后所有门禁系统自动失效，用户可以自由进出。
API & SDK安全
API接口可以实现不同服务间的交互。 API需要用安全密钥来实现身份验证和授权，并且需要象Web应用一样在上线前执行安全测试。
SDK是软件开发工具包，一般是就是第三方服务商提供的实现产品软件某项功能的工具包，它可以包括多个API，功能更齐全
数据库安全
1. 关系数据库
候选键：可用于唯一标识表中记录的字段及字段组合
主键：从候选键中选中用来做当前数据表的唯一标识。每个表都只有一个主键，主键唯一性会被强制检查
外键：一个表的外键对应的是另一个表的主键，通过这个方式来建立表之间的关系(参照完整性)。
元组-tuple：数据表的行
基数-cardinality： 数据表中行的数量
度-degree：数据表中列的数量
域-domain：一组属性可用的允许值
2. 数据库事务
所有数据库事务都要满足ACID模型
原子性：事务满足“要么全有，要么全无”
一致性： 所有事务都必须在与数据库所有规则一致的环境中操作
隔离性：事务之间彼此隔离
持久性：事务一旦提交给数据库，就会被保留下来
3. 数据库安全性
1） 使用数据库视图限制访问，允许用户只与受限的视图交互，而非原始表
2） 并发控制 - 更新时锁定数据库表。否则，多进程同时更新数据库会导致更新丢失；进程从未成功提交的事务中读取数据会导致 脏读
3）通过添加时间戳维护数据的完整性和可用性
4）细粒度的对象控制： 包括单元抑制（对数据库字段或单元进行隐藏或masking）和上下文相关的访问控制
5）数据库分区：将数据分拆到多个数据库实例，防止聚合和推理攻击
6）多实例-polyinstantiation: 对同一个cell，在不同的安全分级下使用不同的值，防止推理攻击。比如员工薪资字段，HR看到的是真实值，而数据库运维人员看到的是虚假值。
7）噪音添加与扰动：在数据表中使用错误或欺骗性的数据，保护机密性。有影响业务正常使用的风险。
4. NoSQL
1）保存键值类(key-value)的数据库： Redis, Memcached. 适合于有大量写操作需求的场景。
2）图数据库： Neo4j，NebulaGraph， 存储实体和实体间的关系，适合知识图谱类的数据
3）文档数据库，保存xml或JSON，能提供快速查询。常见的有MongoDB， Azure Cosmos， AWS DynamoDB。
参考资料：
CISSP Official Study Guide - 第九版英文版 及 第八版中文版
