isms深度解析之信息系统获取开发和维护

1、Ver20101130ISO 27002:2007深度之八信息系统获取开发和Information Systems Acquisition, development and maenance控制目标和控制措施27002在本管理类中，提供了6个控制目标和16项控制措施 信息系统的安全要求（目标1） 应用中的正确处理（目标2）控制（目标3） 系统文件安全（目标4） 开发和支持过程的安全（目标5） 技术脆弱性管理（目标6）12.1 信息系统的安全要求Security Requirements of Information Systems12.1控制目标及措施信息系统的安全要求12.1控制目标及措施信

2、息系统的安全要求解读：信息系统的安全要求27002建议将业务需求和安全需求同步考虑，将安全控制作为信息系统的有机组成部分安全需求的来源主要有3方面： 风险分析的结果的合规要求 业务自身的特点27002要求，建立管理制度，指导特定信息系统在具体设计阶段，能够规范地进行安全需求的分析，以及技术方案的设计12.2 应用中的正确处理Correct Prosing in Applications12.2控制目标及措施应用中的正确处理12.2控制目标及措施应用中的正确处理解读：应用中的正确处理由于过去参与系统开发的经验不多，次看到这部分时候，都觉得有些东西不直观、难理解，只能反复看，反复思考，先把我所能理

3、解的东西阐述一下吧12.2把应用中的安全性控制分为两个不同层次： 确保最基本的正确信息处理所需的控制 其它由业务应用产生的安全需求所要求的额外控制解读：应用中的正确处理12.2.1输入数据确认，目的为确保输入的数据是正确的，每个系统在开发和测试过程中，对于输入数据的校验或确认，都要参照相关的制度要求完成，典型输入确认例子包括： 双重输入，这个没啥说的，关键字段不能输入错误，比如修改账户转帐目的账户等，都能看到两次输入确认的控制实例，或者 输入数据长度检查，这是防止溢出 关键字检测和过滤，这是防止注入的必要措施的必要措施 输入数据规则检查，这是确保输入数据符合系统规则的措施，比如口令格式复杂度检

4、查 操作的实例，就是一个人操作，另一个人审核，在柜面系统中很多这样27002要求管理制度中，不仅包括输入数据确认的控制内容，还要包括差错处理的要求，以及对措施有效性进试的要求，制度无非几个要素，谁、什么情况下、该做什么、怎么做等等，一是形成文件，二是保留（可以是操作日志等）解读：应用中的正确处理12.2.2处理的控制，纠结的部分就来了，“核查宜整合到应用中”，这说的到底是啥意思呢里面提到的核查，看说法应该是人工完成的一个管理过程，不太理解，比较直观的实例来帮助理解么里面提到的“平衡控制措施”，真的没有经验，需要看看别的辅助材料了理解起来，可能是要求在系统开发和测试过程中，对应用处理过程的正确性

5、进行验证？因为这块有一些还没理解透彻，所以在本PPT前面加了一个版本号，用于区别以后可能的更新版本解读：应用中的正确处理12.2.3消息完整性，这个好理解，通过风险分析和评估，确认是否存在消息完整性的安全需求通常采用一些 HMAC机制等技术实现消息完整性验证，例如SSL，例如27002要求应当建立这方面的管理制度，并形成文件，以指导特定信息系统的具体分析、设计、实施解读：应用中的正确处理12.2.4输出数据确认，这是另一个比较纠结的部分，我缺乏这方面的经验积累和知识储备，所以总似天书一般这是指在系统开发和测试过程中，对输出情况进行检查确认么？将来去听27001 LA的培训时候，要把12.2和1

6、2.4作为一个重点去向高手请教了控制12.3Cryptographic Controls12.3控制目标及措施控制12.3控制目标及措施控制解读：控制使用控制措施，可以确保敏感信息的真实性、性、完整性、不可否认性等属性是否采用控制措施，依据于信息的敏感级别和信息处理设施的重要程度，要根据风险分析结果，来确定方案保护的需求国内等同标准22081在12.3.1中，增加了若干符合我国理规定的内容管27002要求建立使用的策略和制度，管理职责、具体的管理过程步骤（风险分析、算法和强度、密钥管理等）、以及使用控制的合规性要求需明的是，加密控制会影响到检测性控制措施的有效性，如IPS/IDS、网关等设备无

7、法分析加密流量解读：控制12.3.2密钥管理，主要相关的算法（对称加密或非对称加密），都涉及到密钥的管理，密钥如何产生、如何交换和分发、如何使用、如何保存、如何销毁，都属于密钥管理的范畴，如果密钥管理存在缺陷，那么证因此密钥管理的目的在于确整性和可用性控制措施的有效性将无法保钥数据的真实性、性、完27002要求建立密钥管理的管理制度，指导特定信息系统中的具体密钥管理实现12.4系统文件安全Security of System Files12.4控制目标及措施系统文件安全12.4控制目标及措施系统文件安全解读：系统文件安全12.4.1运行的控制，主要还是跟运行的发布和变更有关的控制要求，要求建立

8、相关的管理规程，其要点包括： 发布和变更的决策过程 发布和变更的测试过程 发布和变更的实施过程 发布和变更的异常回退过程 对运行的版本控制 对发布和变更的控制 发布和变更过程中的第最主要的目的是为了控制运行的完整性和可用性解读：系统文件安全12.4.2系统测试数据的保护，提出了系统测试阶段的安全控制要求，主要是关注所使用的测试数据的性属性由于测试时，通常要求与运行系统尽可能真实的数据，因此为防止数据转移和使用过程中的信息规程，要点包括：，应当建立相关的管理 数据转移的控制 对测试数据中敏感信息的筛选和剔除 测试数据使用过程中的 测试数据使用结束后的清除控制整个管理过程中的过程解读：系统文件安全

9、12.4.3对源代码的完整性的保护控制，主要关注对于源代码及相关文档应当建立对于源代码的相关控制规程，要点包括： 合法的和 使用配置管理工具 合法的操作 操作审计和源代码12.5 开发和支持过程的安全Security in Development and Support Proses12.5控制目标及措施开发和支持过程的安全12.5控制目标及措施开发和支持过程的安全解读：开发和支持过程的安全严格控制的变更是信息系统可用性受损的一大风险来源，因此本部分主要是围绕变更控制来提出安全要求的针对12.5.1的要求，应当建立信息系统变更控制规程，确保该规程得到严格执行，并过程其实12.5.2是被包含在1

10、2.5.1中的，这部分与12.6的技术脆弱性管理关系更加紧密，但是有点疑问，把OS变更单独弄出来，那网络层的变更呢？可能还是因为OS层面的布更加频繁，所以它占据了变更管理很大一部分和补丁发吧12.5.3阐述了包变更的控制要求12.5.4要求建立控制措施，对通过隐蔽通道造成信息险进行控制，建议的措施包括： 木马检测工具的风 网络控制解读：开发和支持过程的安全其实信息系统中可能的信息的途径是很多的，12.5.4既提到了泄密的风险，也提到了窃密的风险。以前写过一个关于信息的PPT，也一起发出来，供大家参考12.5.5关注外包开发的管理，现实中很大比例的信息系统都是通过开发外包服务获得的，尤其是一些业

11、务应用系统，在采购基础上，必须客户化定制开发才能使用。外包方风险的控制包括： 工作进度和质量 知识相关 代码安全性 脆弱性检测12.6 技术脆弱性管理Technical Vulnerability Management12.6控制目标及措施技术脆弱性管理12.6控制目标及措施技术脆弱性管理解读：技术脆弱性管理脆弱性和补丁管理，是运维阶段中与安全关系紧密的一部分工作，27002所提到的技术脆弱性管理，主要是指系统布的技术脆弱性所公在实际工作中，操作系统、数据库、运行环境（如Web服务器、应用服务环境Tomcat、Weblogic之类）是脆弱性管理主要关注的内容记得以前在中过脆弱性是否区分技术脆弱性和管理脆弱性，管理又没有脆弱性等问题，如果管理没有脆弱性，那27002在这里还有必要专门在脆弱性前面加一个定语“技术”来专门限定么？脆弱性和补丁管理，与另一个管理过程“变更管理”，两者需要综合考虑关解读：技术脆弱性管理与技术脆弱性管理有关的过程，包括了指定岗位和职责，建立信息资产，获取脆弱性信息，影响和风险分析，采取应对措施（如打补丁、关服务、