服务项目

信息安全认证：ISO27000标准“A.14.2 开发和支持过程中的安全”条款讲解

文章录入：华道众合文章来源：华道众合添加时间：2021-1-30

【标准条款】

A.14.2 开发和支持过程中的安全

目的：确保信息安全在信息系统开发生命周期中得到设计和实现。

A.14.2.1安全的开发策略

针对组织内的开发，应建立软件和系统开发规则并应用。

【理解与应用】

安全开发是建立安全服务、架构、软件和系统的要求。宜在安全开发策略中考虑：

（1）开发环境的安全;

（2）软件开发生命周期中的安全指南：

——软件开发方法的安全;

——每种使用的编程语言的安全编码指南;

（3）设计阶段的安全要求;

（1）项目里程碑内的安全检查点;

（2）安全库;

（3）版本控制的安全;

（4）所需的应用安全知识;

（8）开发人员避免、发现和修复脆弱性的能力。

当开发所用的标准可能未知或与当前的最佳实践不一致时，新开发和代码复用时均宜使用安全的编程技术。宜考虑安全的编码标准，并在适当时强制使用。宜培训开发人员使用安全的编码标准，测试和代码评审宜验证其使用。

如开发外包时，组织宜获得外包方遵守安全开发规则的保障（见 A.14.2.7外包开发）。

也可能针对内部应用实现开发，如办公软件、脚本、浏览器和数据库。

【标准条款】

A.14.2.2 系统变更控制规程

应使用正式的变更控制规程来控制开发生命周期内的系统变更。

【理解与应用】

宜将正式的变更控制规程文件化，并强制实施，以确保从最初设计至后续维护中系统、应用和产品的整体性。引入新系统和对已有系统进行大的变更宜按照从文件、规范、测试、质量控制到实现管理这个正式的过程进行。

这个过程宜包括风险评估、变更影响分析和所需安全控制的规范。这一过程还宜确保不损害现有的安全和控制规程，确保支持程序员仅能访问系统中其工作中那些必要的部分，确保任何变更要获得正式商定和批准。

只要可行，应用和运行变更控制规程宜集成起来（见 A.12.1.2变更管理）。该变更控制规程宜包括但不限于∶

（1）维护所商定授权级别的记录;

（2）确保由授权的用户提交变更;

（3）评审控制和完整性规程，以确保它们不因变更而受到损害;

（4）识别需要修正的所有软件、信息、数据库实体和硬件;

（5）识别和检查安全关键代码以最小化已知安全弱点发生的可能性;

（6）在工作开始之前，获得对详细建议的正式批准;

（7）确保已授权的用户在实现之前接受变更;

（8）确保在每个变更完成之后更新系统文件设置，并将旧文件归档或丢弃;

（9）维护所有软件更新的版本控制;

（10）维护所有变更请求的审计踪迹;

（11）确保变更了操作文件（见 A.12.1.1文件化的操作规程）和用户规程，作为必要的合适保存;

（12）确保在正确的时间上进行了变更，并且不干扰所涉及的业务过程。

同时，也需要关注：

变更软件会影响运行环境，反之亦然。

良好的做法包括在一个与生产和开发环境隔离（见A.12.1.4开发、测试和运行环』境的分离）的环境中测试新软件。它提供了一种方法，可用于控制新软件，以及对被用于测试目的的运行信息进行额外保护。这宜包括补丁、服务填充和其他更新。

当考虑自动更新时，宜对系统完整性和可用性面临的风险与更新的快速部署的益处之间进行权衡。由于某些更新可导致关键应用失败，不宜在关键系统中使用自动更新。

【标准条款】

A.14.2.3 运行平台变更后对应用的技术评审

当运行平台发生变更时，应对业务的关键应用进行评审和测试，以确保对组织的运行和安全没有负面影响。

【理解与应用】

这一过程宜包括：

（1）评审应用控制和完整性规程，以确保它们不因运行平台变更而受到损害;

（2）确保及时提供运行平台变更的通知，以便于在实现前进行适当的测试和评审;

（3）确保对业务连续性计划进行适当的变更（见A.17）。

同时，要关注到运行平台包括操作系统、数据库和中间件平台。本控制也适用应用程序的变更。

【标准条款】

A.14.2.4 软件包变更的限制

应不鼓励对软件包进行修改，仅限于必要的变更，且对所有变更加以严格控制。

【理解与应用】

如果可能且可行，宜使用厂商提供的软件包，而无需修改。在需要修改软件包时，宜考虑下列要点∶

（1）内置控制和完整性过程被损害的风险;

（2）是否宜获得厂商的同意;

（3）当标准程序更新时，从厂商获得所需变更的可能性;

（4）作为变更的结果，组织需负责进一步维护此软件带来的影响;

（5）与其他在用软件的兼容性。

如果变更是必要的，宜保留原始软件，并将变更应用于指定的副本。宜实现软件更新管理过程，以确保最新批准的补丁和应用更新已经安装在所有的授权软件中（见 A.12.6.1技术脆弱性的管理）。宜充分测试所有变更并形成文件，以便必要时可以将其重新应用于将来的软件升级。如果必要，所有的修改宜由独立的评估机构进行测试和验证。

【标准条款】

A. 14.2.5 系统安全工程原则

应建立、文件化和维护系统安全工程原则，并应用到任何信息系统实现工作中。

【理解与应用】

宜建立基于安全工程原则的安全信息系统工程规程，形成文件并应用于内部信息系统的工程活动。安全宜审计到所有架构层（业务、数据、应用和技术）之中，以平衡信息安全需求和访问需求。宜针对安全风险，分析新技术，并针对已知的攻击模式，评审相应的设计。

宜定期评审这些原则和已建立的工程规程，以确保其有效地用于工程过程中的安全增强标准。还宜定期评审以确保其在对抗任何潜在的新威胁方面保持最新，并保持其对技术和解决方案发展的适用性。

适用时，宜通过组织与外包供应商间的合同以及其他绑定的协议，把已建立的安全工程原则应用到外包的信息系统。组织宜证实供应商的安全工程原则的严谨性与其自身的原则是可比的。

同时，需要关注应用开发规程宜适用于具有输入输出接口的应用开发中的安全工程技术。安全工程技术提供了用户鉴别技术、安全会话控制和数据确认、调试代码的净化和消除方面的指南。

【标准条款】

A. 14.2.6 安全的开发环境

组织应针对覆盖系统开发生命周期的系统开发和集成活动，建立安全开发环境，并予以适当保护。

【理解与应用】

安全的开发环境包括与系统开发和集成相关的人员、过程和技术。

组织宜评估与单个系统开发工作相关的风险，并为特定系统的开发工作建立安全的开发环境，考虑：

（1）系统所处理、存储和传输的数据的敏感性;

（2）适用的外部和内部要求，如法律法规或策略的要求;

（3）组织已实现的支持系统开发的安全控制;

（4）工作环境中人员的可信度（见 A.7.1.1审查）;

（5）系统开发的外包程度;

（6）分离不同开发环境的需求;

（7）访问开发环境的控制;

（8）监视环境及其所存储代码的变更;

（9）在安全的异地存储备份;

（10）控制数据移入移出环境的活动。

一旦特定开发环境的保护级别被确定，组织宜将相应的过程形成安全开发规程文件并提供给有需要的人员。

【标准条款】

A.14.2.7 外包开发

组织应督导和监视外包系统开发活动。

【理解与应用】

系统开发外包时，宜考虑组织所有外部供应链的以下方面∶

（1）与外包内容相关的许可证、代码所有权和知识产权（见 A.18.1.2知识产权）;

（2）安全设计、编码和测试的合同要求（见 A.14.2.1开发的安全策略）;

（3）向外部开发者提供已批准的威胁模型;

（4）交付件质量和准确性的验收测试;

（5）提供用以建立安全和隐私保护能力的最低可接受级别的安全阈值的证据;

（6）提供充分测试的证据，用以防范交付时包含有意和无意的恶意内容;

（7）提供充分测试的证据，用以防范已知的脆弱性;

（8）托管安排，如当源代码不可用时;

（9）对开发过程和控制进行审计的合同权利;

（10）生成交付件的编译环境有效的文件化;

（11）组织保有遵守相关法律法规和验证控制有效性的责任。有关供应商关系的更多信息参见ISO/IEC 27036。

【标准条款】

A.14.2.8 系统安全测试

应在开发过程中进行安全功能测试。

【理解与应用】

新系统和升级的系统要求在开发过程中进行全面的测试和验证，包括准备详细的│活动安排、各种条件范围下的测试输入和预期输出。对于内部开发，宜由开发团队进行最初测试。然后，宜进行独立地验收测试（包括内部和外包开发），以确保系统工作按预期且仅按预期（见 A.14.1.1信息安全要求分析和说明和 A.14.2.9系统验收测试）进行工作。测试范围宜与系统性质和重要性成正比。

【标准条款】

A.14.2.9 系统验收测试

应建立对新的信息系统、升级及新版本的验收测试方案和相关准则。

【理解与应用】

系统验收测试宜包括信息安全要求测试（见A.14.1.1信息安全要求分析和规范及A.14.1.2公共网络上应用服务的安全保护）和是否遵循安全系统开发实践测试（见A.14.2.1安全的开发策略）。该测试还宜在接收组件和集成系统上进行。组织可借助自动工具如代码分析工具或漏洞扫描器，并宜验证与安全有关的缺陷的修复。

宜在真实的测试环境中进行测试以确保系统不会将脆弱性引入组织环境，并确保测试是可靠的。

想了解更多的关于信息安全认证信息可以经常关注我们

【相关文章】