【格式化文档】ISO 27001控制措施+ISO27002实施指南 【下】

A14 系统购置、开发和维护

A14.1 信息系统安全需求

目标：确保信息安全是信息系统整个生命周期的一部分，也包含了信息系统在公共网络上提供服务的要求；

序号	标识	类型	描述
14.1.1	信息安全需求分析和说明	控制类	信息系统安全相关要求，包含 购置新型信息系统或者增强已存在信息系统；
14.1.2	公共网络上安全应用服务	控制类	防护在公共网络上的应用服务，免受欺诈、合同争议、未授权泄漏和篡改；
14.1.3	保护应用服务交易	控制类	避免不完整传输、错误路由、未授权信息变更、未授权暴露、未授权信息重放。

A14.1.1-1 识别信息安全需求方法

1. 基于策略和法规，推出合规需求；
2. 威胁模型；
3. 事故回顾；
4. 脆弱性权重；
5. 商业价值；
6. 所有识别结果需要记录为文档并传达到利益相关者；

A14.1.1-2 信息安全需求

• 具有业务价值信息 缺乏足够的安全性可能导致潜在的负面业务影响。[详见8.2]；
• 尽早实现信息安全 应该在信息系统建立项目的早期阶段完成，可有效引领高收益的解决方法。
• 用户访问登记识别 为了保证机密等级，需要识别用户，作为获取用户认证的基础；
• 访问配置与授权过程 例如业务用户、技术用户、特权用户；
• 用户角色和职责 通知用户和操作员的角色和职责；
• 资产安全三要素 机密性、完整性、可用性；
• 审计业务规程 交易记录、监控和不可抵赖的需求；
• 安全控制措施 端口监控和记录，数据泄露检测系统；

A14.1.1-3 安全采购需求

• 定义安全标准 应该定义接受产品的标准，例如就其功能而言，这将确保满足已知的安全要求。
• 采购产品之前 应遵循正式的功能测试和购买过程，应重新考虑引入的风险和相关控制措施；
• 采购协议要求 与供应商的合同应包含已知的安全要求；
• 实施安全配置 应评估和实施与该系统的最终软件/服务堆栈一致的产品安全配置的可用指南；

ISO/IEC 27005 和 ISO 31000 提供了关于风险管理进程，识别满足信息安全控制需求的指南。

A14.1.2-1 公网应用服务的安全要求

• 用户身份标识 机密级别基于他们在认证时申明的身份标识；
• 授予访问权限 授权程序使用来绑定谁可以批准发行标准内容或者签署关键交易文件；
• 应用服务协议 合作伙伴之间的应用程序服务安排应得到书面协议的支持，该协议应使双方都遵守协议的服务条款；
• 传达使用权限 确保向通讯伙伴充分告知其授予权限和可使用的服务；
• 健壮服务网络应该考虑抵御攻击的弹性要求，其中可能包括保护相关应用服务器或确保交付服务所需的网络互连的可用性的要求。
• 详细风险评估 为了抵御欺诈、网络威胁、合同纠纷，需要详细的风险评估和正确选择控制措施；
• 需要控制措施 身份验证和保护数据传输的加密方法；
• 身份验证方法 受信任第三方授权机构、数字签名、数字证书、PKI 等；

A14.1.2-2 组织业务过程的信息安全

• 信息安全三要素确保满足机密性、完整性、派遣文件、关键收据文件、不可抵赖协议的安全需求，包括 招标文件、协商流程；
• 关键文件完整性 关键文件的完整性要求的信任等级；
• 机密信息控制任何机密信息的防护要求；
• 业务隐私信息 任何订单交易，付款信息，收货地址详细信息和收据确认的机密性和完整性；
• 安全交易环境 提供适合的验证等级，用于验证客户提供的付款信息，选择最合适的付款方式以防欺诈；
• ** 保护订单信息**维护订单信息的机密性和完整性所需的保护级别，避免丢失或交易信息重放；
• 需要应用加密 通过应用加密机制执行控制（详见第10章）；
• 合规与风险转移遵守法律要求（详见第18章，关于加密法律 18.1.5)，考虑保险要求，任何欺诈性交易有关的责任；

A14.1.3-1 应用服务交易的信息安全

• 使用电子签名 交易的整个过程和部分都需要使用电子签名，来确保身份认证是有效的；
• 保护用户隐私 交易环境必须是可信的，所有相关方的隐私都需要被保护；
• 验证用户身份 完成交易前需要验证用户认证信息是有效性，以避免伪造和欺诈；
• 传输过程安全 所有相关方的通讯路径、通讯协议，必须被具有加密功能；
• 交易记录安全 确保交易明细存储位置，不在公共访问环境之内，例如组织内网、存储设备不能保留公网直连通道；
• 外部认证机构 需要使用信任的认证机构，目的是维护数字证书和数字签名，嵌入完整端到端认证和鉴证管理过程；
• 风险等级控制 控制措施需要与应用服务交易的风险等级相符；
• 交易生命周期 交易的产生、处理、完成、归档都需要遵守监管机构的法律和法规。

A14.2 开发与运维过程的安全

目标：确保信息安全设计和实现符合信息系统开发生命周期；

序号	标识	类型	描述
14.2.1	安全开发策略	控制类	开发系统和软件规则，需要建立和应用到组织内部开发过程中；
14.2.2	系统变更控制规程	控制类	使用正式变更流程控制开发生命周期中的系统变更；
14.2.3	操作平台变更与技术审查	控制类	当操作平台发生变更时，业务关键应用需要执行审查和测试，确保没有对组织操作和安全造成不利影响；
14.2.4	软件包变更限制	控制类	修改软件包的行为必须严格控制或者只做必要修改，其它的都是不鼓励的行为
14.2.5	安全系统工程原理	控制类	工程安全系统的原则应建立，记录，维护并应用于任何信息系统实施工作。
14.2.6	安全开发环境	控制类	组织应建立适当的保护系统和整个系统开发生命周期的集成工作的开发环境；
14.2.7	外部开发安全	控制类	组织应该监管和监控外源开发系统的活动；
14.2.8	系统安全测试	控制类	安全特性的测试应该在开发过程中持续实施；
14.2.9	系统可接受测试	控制类	新的信息系统、升级、版本更新都应该建立可接受测试及其验证标准。

A14.2.1-1 安全开发策略

• 安全开发定义 基于安全开发策略构建安全服务、架构、软件和系统的需求；
• 安全生命周期 设计阶段需要考虑安全需求，项目里程碑中安全监测点；
• 安全编码标准 基于编程语言的安全编码指南，并在相关的使用条件下强制使用。
• 安全开发方法 开发者需要避免，发现，修复脆弱性，安全存储库，版本控制安全；
• 安全开发培训 开发人员应接受使用和培训方面的培训，代码审查应验证其使用。
• 开发外包规则 如果将开发外包，则组织应确保外部方遵守这些安全开发规则（请参阅14.2.7）。

A14.2.2-1 变更流程特征

• 流程持续时间 从早期设计阶段开始到后续的运维工作；
• 强制执行文档 为了确保系统，应用和产品的完整性 ，正式的变更控制规程需要强制执行且文档化；
• 重大变更规划 新系统和现有系统重大变更，应该遵从正式文档进程，规范，测试，质量控制，实施管理；
• 变更流程内容 风险评估，变更影响分析，安全控制规范；
• 有效变更流程 可行的，应用和操作变更控制规程都应该是完整的；

A14.2.2-2 如何变更处理

• 审批变更流程 确保安全和控制程序不被破坏，技术支持们只能访问关于他们工作那部分系统，并且确保所有变更都经过审批；
• 维护变更授权 维护商定的授权级别记录；
• 审核变更请求 确保授权用户在实施之前接受更改，变更应该由授权用户提交，保证审核跟踪所有变更请求；
• 确认变更影响 审查控制措施和完整性规程，以确保它们不会因变更而受到影响；
• 变更控制范围 识别所有需要修改的软件，信息，数据库实体和硬件；
• 回顾安全控制 识别和检查安全关键代码，以确保最小化已知安全漏洞的可能性；
• 审批变更建议 在工作开始之前，获得关于建议书的细节的正式批准&