银行软件安全测试技术建议方案.docVIP

目录 TOC \o 1-5 \h \z HYPERLINK ——Gartnor Grouo 2008 92% of reported vulnerabilities are in applications, not networks0%1% 2% 92% of reported vulnerabilities are in applications, not networks 0%1% 2% 2% 3% Source: NIST Encryption Module Network Protocol Stack Other Communication Protocol Hardware Operating System Non-Server ApplicationsServer Applications 对于应用安全性的检测戸前大多数是通过测试的方式来实现。测试大体上分 为黑盒测试和白盒测试两种。黑盒测试一般使用的是渗透的方法，这种方法仍然 带有明显的黑盒测试本身的不足，需要大量的测试用例来进行覆盖，且测试完成 后仍无法保证软件是否仍然存在风险。现在白盒测试屮源代码扫描越來越成为一 种流行的技术，使用源代码扫描产品对软件进行代码扫描，i方面可以找出潜在 的风险，从内对软件进行检测，提高代码的安全性，另i方面也可以进一步提高 代码的质量。黑盒的渗透测试和白盒的源代码扫描内外结合，可以使得软件的安 全性得到很大程度的提高。 因此，应用软件的自身的安全问题是我们信息安全领域最为关心的问题，也 是我们面临的一个新的领域，需要我们所有的在应用软件开发和管理的各个层面 的成员共同的努力来完成。 2银行业源代码检测的相关标准和要求 2」《信息安全等级保护基本要求》 根据《基本要求》屮关于外包软件开发的相关要求，一级要求开始就对外包 开发软件在上线前进行恶意代码检测，“应在软件安装之前检测软件包屮可能存 在的恶意代码”。在测试验收屮，提出了对系统进行安全性测试，“应对系统进行 安全性测试验收”。在二级要求屮，増加了对源代码进行后门检查的要求，“应要 求开发单位提供软件源代码，并审查软件屮可能存在的后门”。三级要求屮明确 指出要求由第三方测试单位实施系统安全性测试，“应委托公正的第三方测试单 位对系统进行安全性测试，并出具安全性测试报告”。四级要求屮增加了对源代 码隐蔽信道的安全检査耍求， 从《基本要求》关于系统安全性测试要求的变化可以看出，系统安全性测试 强度不断提高，在四级要求屮增加了对“隐蔽信道”的安全检查，测试机构从无 要求转向了三级要求屮明确规定的第三方测试单位。一级要求屮的恶意代码检测 和安全性测试，未明确要求进行源代码层面的安全测试，《基本要求》要求在测 试验收时进行必要的软件安全性测试，代码审查可以作为软件安全性测试i项其 重要手段，但未进行明确的规定。在二级要求屮增加了对源代码进行后门检查及 四级要求屮对源代码进行隐蔽信道检查，提供了源代码检测的必要依据。 2.2信息安全管理体系要求(IDTISO/IEC27001： 2005) 根据《信息安全管理系统要求》小控制H标“防范恶意代码和移动代码”，“应 用屮正确处理”，“技术脆弱性管理”的要求，应用系统必须以相应的控制措施提 供相应的功能。为验证安全功能的实现，在IT审计工程屮，必然需要相应的测 试结论提供和应的支持。其屮“防范恶意代码和移动代码”，“应用屮正确处理”, “技术脆弱性管理”等要求均可以利用代码审查进行控制H标的验证。 2.3支付卡行业数据库安全标准(PCIDSS) PCI DSSP 6.3.7 “在发布生产以前检查自定义代码，以识别所有潜在的编 码漏洞”，及6.6“对于面向公众的Web应用程序，经常解决新的威胁和漏洞, 并确保保护这些应用程序不受到以下任一方法的攻击”，此项要求屮明确提出了 由独立于开发团队的内部组织或第三方专业机构进行代码安全审查。对于银行业 及金融业来说，此项业务需求将比较大。 2.4网上银行系统信息安全通用规范 网上银行系统信息安全通用规范（试行）屮明确要求由外色方开发 的客户端程序要进行代码安全测试并须通过第三方小立测试机构的安全检测， P WEB应用安全对编码规范约束、防止SQL注入攻击、防止跨站脚本 攻击等对软件安全及代码安全做出了明确要求，而且指定了要求第三方机构出具 相应的测评报告。 2.5电子银行业务管理办法及电子银行安全评估指引 《屯子银行业务管理办法》对电子银行系统的安全性进行了规范，指出在申 请电子银行业务吋需要提交电子银行安全性评估报告。FI前《电子银行安全评估 指引》是电子银行安全性评估的准则，其第三十一条明确规定电子银行系统的安 全性评估须包括应用系统安全性评估内容，但未对应用系统安全性评估方法进行 明确规范，