代码安全系统性检测指导要求规范1109Word文档下载推荐.docx
《代码安全系统性检测指导要求规范1109Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《代码安全系统性检测指导要求规范1109Word文档下载推荐.docx（19页珍藏版）》请在冰点文库上搜索。
应用上线阶段
•新应用软件部署完毕之后，应组织对目标应用系统进行整体的安全性测评（根据安全测试方案）及整改。
（第三方应用安全整体测评）
•应用日常维护过程中，应根据应用安全等级，定期进行应用安全性评测和改进。
（例行应用安全测评）
2.应用安全性测试的范围与内容
应用安全性测试的范围与内容，应包括如下几个方面：
测评项
测评内容
部署与基础结构
•网络是否提供了安全的通信
•部署拓扑结构是否包括内部的防火墙
•部署拓扑结构中是否包括远程应用程序服务器
•基础结构安全性需求的限制是什么
•目标环境支持怎样的信任级别
输入/输出和编码
•如何验证输入
▫是否清楚入口点
▫是否清楚信任边界
▫是否验证Web页输入
▫是否对传递到组件或Web服务的参数进行验证
▫是否验证从数据库中检索的数据
▫是否将方法集中起来
▫是否依赖客户端的验证
▫应用程序是否易受SQL注入攻击
▫应用程序是否易受XSS攻击
▫应用程序是否易受OS注入攻击
▫应用程序是否易受Cookie定制/隐藏文件操纵攻击
•如何处理输入
•输出信息是否涉及泄密
•数据编码处理过程是否存在安全漏洞
身份验证
•是否区分公共访问和受限访问
•是否明确服务帐户要求
•如何验证调用者身份
•如何验证数据库的身份
•是否强制试用帐户管理措施
访问授权
•如何向最终用户授权
•如何在数据库中授权应用程序
•如何将访问限定于系统级资源
配置管理
•是否支持远程管理
•是否保证配置存储的安全
•是否隔离管理员特权
敏感数据
•是否存储机密信息
•如何存储敏感数据
•是否在网络中传递敏感数据
•是否记录敏感数据
会话管理
•如何交换会话标识符
•是否限制会话生存期
•如何确保会话存储状态的安全
加密
•为何使用特定的算法
•如何确保加密密钥的安全性
参数操作
•是否验证所有的输入参数
•是否在参数过程中传递敏感数据
•是否为了安全问题而使用HTTP头数据
异常管理
•是否使用结构化的异常处理
•是否向客户端公开了太多的信息
审核和日志记录
•是否明确了要审核的活动
•是否考虑如何流动原始调用这身份
源代码错误
•缓冲区溢出漏洞。
•字符串格式化漏洞。
•优先权提升漏洞。
3.应用安全性验收的流程与方法
3.1应用安全性验收的流程
应用安全性验收的流程图如下：
3.1.1IT项目安全测评保护要求管理
（1）《上海电信内部IT系统的分级安全保护要求》的编制与复审
规划处牵头，会同各应用域及信息中心、移动业务支撑中心共同编制《上海电信内部IT系统的分级安全保护要求》。
规划处负责定期组织对编制的《IT系统分级保护要求》进行评估和复审，确保该要求能反映业务需求的变化，并适应于当前的内部IT基础架构现状。
（2）《上海电信内部IT系统安全保护评估指南》的编制与复审
规划处负责牵头并会同相关的安全测评服务商，根据《IT系统分级保护要求》细化并制定《上海电信内部IT系统安全保护评估指南》，作为各IT项目验收环节系统安全保护能力测评与验收的参考基准。
规划处在《IT系统分级保护要求》变更后，应及时组织对《IT系统安全保护评估指南》文档做相应调整与更新。
3.1.2IT项目安全测评管理
（1）安全测评方案编制与评审
在IT项目的实施方案编制阶段，由电信项目经理牵头，组织相关应用域、IT项目承建方、第三方安全测评服务商依据《上海电信内部IT系统安全保护评估指南》共同编制该IT项目的安全测评方案。
项目安全测评方案编制完成后，应和项目实施方案一同进行实施方案的评审环节。
（2）IT项目安全测评
IT项目承建方在完成项目建设实施工作后，在正式提出项目验收请求之前，向第三方安全测评服务商申请进行项目安全测评。
第三方安全测评服务商将按照评审通过的项目安全测评方案，组织现场安全测评，汇总测评结果并提出安全整改意见给IT项目承建方和电信项目经理。
IT项目承建方在接到项目安全整改意见后，应及时组织针对性的安全整改工作，并向第三方测评服务商申请整改复审。
第三方测评服务商在收到整改复审申请后，针对整改意见进行复审测评，直至所有整改项均符合要求。
全部测评项通过后，第三方测评服务机构出具项目安全测评报告，并汇总测评相关技术文档提交至电信项目经理。
电信项目经理在收到项目安全测评报告后，组织常规的IT项目验收工作，并在项目验收时将安全测评相关文档并入项目技术文档保存。
（3）IT项目的移交
在IT项目建设完毕后的维护移交阶段，应同步将应用系统的安全要求和安全保护指南转换为相应的《应用系统安全维护指南》，作为应用维护阶段的安全维护基准。
3.1.3IT项目运维安全测评管理
（1）维护性开发的安全测评
在维护性开发工作启动阶段应参照《应用系统安全维护指南》确定维护性开发相关部分的安全保护评估指南，并细化为对应的安全测试方案，作为维护性开发结束的安全评估的基准。
维护性开发工作结束，由移动业务支撑中心牵头，组织相关应用域、维护服务提供商、第三方安全测评服务商共同完成维护性开发涉及部分系统的安全测评和整改，并作为维护性开发验收的必要条件之一。
（2）日常维护安全测评
移动业务支撑中心应根据《应用系统安全维护指南》，组织第三方安全测评服务商按照应用系统的分级安全保护要求进行定期的系统安全测评，并根据测评结果对IT基础架构、应用系统进行必要的安全改进。
应用系统的日常安全维护文档也纳入维护文档管理体系。
3.2应用安全性测试的方法
3.2.1测试方法概述
应用安全性测试与验收的方法主要包括：
•静态的代码安全测试（白盒法）：
主要通过对源代码进行安全扫描，根据程序中数据流、控制流、语义等信息与其特有软件安全规则库进行匹对，从中找出代码中潜在的安全漏洞。
该方法非常有用，可在编码阶段找出所有可能存在安全风险的代码，这样开发人员可以在早期解决潜在的安全问题。
静态代码测试更适用于早期的代码开发阶段，而不是测试阶段。
•动态的渗透测试（黑盒法）：
渗透测试也是常用的安全测试方法。
是使用自动化工具或者人工的方法模拟黑客的输入，对应用系统进行攻击性测试，从中找出运行时刻所存在的安全漏洞。
该测试方法的特点是真实有效，一般找出来的问题都是正确的，也是较为严重的。
但渗透测试一个致命的缺点是模拟的测试数据只能到达有限的测试点，覆盖率很低。
•程序数据扫描：
通常是进行内存测试，内存测试可以发现许多诸如缓冲区溢出之类的漏洞，而这类漏洞使用除此之外的测试手段都难以发现。
该测试方法主要用于确保有高安全性需求应用在运行过程中的数据安全性。
数据扫描通畅需要专门的工具来进行验证。
3.2.2应用安全测试的成功要素
成功的应用安全测试需要做好如下方面的充分准备：
•充分了解软件安全漏洞：
评估一个软件系统的安全程度，需要从设计、实现和部署三个环节同时着手。
这一点可参考通用评估准则（CommonCriteria）的软件系统安全评估方法来理解：
首先要确定软件产品对应的ProtectionProfile（PP,产品的安全特性模板），然后根据PP再提出具体的安全功能需求，最后确定安全对象以及是如何满足对应的安全功能需求的。
因此，一个安全软件的三个环节，哪个出问题都不行，需要充分了解各环节的软件安全漏洞。
•安全性测试的评估：
需要建立对测试后的安全性评估机制，一般可从如下两个方面进行评估：
▫安全性缺陷数据评估：
直接分析评估目标代码，如果发现软件的安全性缺陷和漏洞越多，可能遗留的缺陷也越多。
进行这类评估时，必须建立基线数据作为参照，否则评估起来没有依据就无法得到正确的结论。
▫采用漏洞植入法来进行评估：
通过在目标代码中植入一些有安全漏洞，然后测试可发现的植入漏洞，并以此来评估软件的安全性测试做得是否充分。
•采用安全测试技术和工具：
可使用专业的具有特定功能的安全扫描软件来寻找潜在的漏洞，将已经发生的缺陷纳入缺陷库，然后通过自动化测试方法来使用自动化缺陷库进行轰炸测试。
3.2.3反向安全测试与正向安全测试
（1）反向安全性测试过程
大部分软件的安全测试都是依据缺陷空间反向设计原则来进行的，即事先检查哪些地方可能存在安全隐患，然后针对这些可能的隐患进行测试。
因此，反向测试过程是从缺陷空间出发，建立缺陷威胁模型，通过威胁模型来寻找入侵点，对入侵点进行已知漏洞的扫描测试。
其优点是可对已知的缺陷进行分析，避免软件里存在已知类型的缺陷；
缺点是对未知的攻击手段和方法通常会无能为力。
反向安全性测试的常规过程将包括：
•建立缺陷威胁模型。
建立缺陷威胁模型主要是从已知的安全漏洞入手，检查软件中是否存在已知的漏洞。
建立威胁模型时，需要先确定软件牵涉到哪些专业领域，再根据各个专业领域所遇到的攻击手段来进行建模。
•寻找和扫描入侵点。
检查威胁模型里的哪些缺陷可能在本软件中发生，再将可能发生的威胁纳入入侵点矩阵进行管理。
如果有成熟的漏洞扫描工具，那么直接使用漏洞扫描工具进行扫描，然后将发现的可疑问题纳入入侵点矩阵进行管理。
•入侵矩阵的验证测试。
创建好入侵矩阵后，就可以针对入侵矩阵的具体条目设计对应的测试用例，然后进行测试验证。
（2）正向安全性测试过程
为了规避反向设计原则所带来的测试不完备性，需要一种正向的测试方法来对软件进行比较完备的测试，使测试过的软件能够预防未知的攻击手段和方法。
正向安全性测试过程通常包括：
•先标识测试空间。
对测试空间的所有的可变数据进行标识，由于进行安全性测试的代价高昂，其中要重点对外部输入层进行标识。
例如，需求分析、概要设计、详细设计、编码这几个阶段都要对测试空间进行标识，并建立测试空间跟踪矩阵。
•精确定义设计空间。
重点审查需求中对设计空间是否有明确定义，和需求牵涉到的数据是否都标识出了它的合法取值范围。
在这个步骤中，最需要注意的是精确二字，要严格按照安全性原则来对设计空间做精确的定义。
•标识安全隐患。
根据找出的测试空间和设计空间以及它们之间的转换规则，标识出哪些测试空间和哪些转换规则可能存在安全隐患。
例如,测试空间愈复杂，即测试空间划分越复杂或可变数据组合关系越多也越不安全。
还有转换规则愈复杂，则出问题的可能性也愈大，这些都属于安全隐患。
•建立和验证入侵矩阵。
安全隐患标识完成后，就可以根据标识出来的安全隐患建立入侵矩阵。
列出潜在安全隐患，标识出存在潜在安全隐患的可变数据，和标识出安全隐患的等级。
其中对于那些安全隐患等级高的可变数据，必须进行详尽的测试用例设计。
（3）正向和反向测试的区别
正向测试过程是以测试空间为依据寻找缺陷和漏洞，反向测试过程则是以已知的缺陷空间为依据去寻找软件中是否会发生同样的缺陷和漏洞，两者各有其优缺点。
反向测试过程主要的一个优点是成本较低，只要验证已知的可能发生的缺陷即可，但缺点是测试不完善，无法将测试空间覆盖完整，无法发现未知的攻击手段。
正向测试过程的优点是测试比较充分，但工作量相对来说较大。
因此，对安全性要求较低的软件，一般按反向测试过程来测试即可，对于安全性要求较高的软件，应以正向测试过程为主，反向测试过程为辅。
3.2.5软件生命周期中的应用安全保证机制*
（这部分属于最终要建立的覆盖软件生命周期的安全保证机制，供参考）
在保证应用安全的整个生命周期中，需要涉及多个基本任务，这些任务包括：
•设置安全需求（SetSecurityRequirements）：
由安全专家或相关人员指定在项目中哪些问题可以被定义为安全漏洞、每种安全漏洞对项目的影响程度。
•配置（Configure）：
针对不同的项目，进行必要的配置以扫描应用。
•扫描（Scan）：
扫描项目代码并返回结果。
•优选（Triage）：
根据扫描的结果进行排选，发现影响最大、需要立即修复漏洞的过程。
•解决（Resolve/Remediate）：
通过修改代码、增加安全函数、移出缺陷等方式修复发现的安全漏洞。
•验证（Verify）：
重新扫描代码以保证安全漏洞已经被正确修复。
企业可以根据规模、人力等因素将这些任务和不同的角色相结合，因此在软件开发的生命周期中保证应用安全，就会产生如下三种部署模式。
在具体应用时，可根据各项目组的实际情况来灵活选择。
（1）简易模式
简易模式下，相关角色的职责分别为：
•管理人员或者安全专家：
设置安全需求定义，同时建立验证标准；
在项目过程中查看报告，获知安全相关的信息；
•研发人员：
从源代码控制系统中检出代码进行开发；
在任何时候都可以自行配置扫描工具进行扫描，并分析扫描结果；
决定如何去修复，最后在修复完成后再次运行扫描，来验证是否修改正确，如果正确，则将代码检入到源代码控制系统，否则继续进行修改。
这种模式的优点是易于实现，仅涉及两种角色，管理人员和开发人员。
非常适合小规模的开发团队，以及需要进行审计的项目。
同时，由于产生交互的环节少，而且由写代码的开发人员自己发现问题，可以更有效的优选和解决安全漏洞。
该模式的缺点是不适合大规模部署，增大了开发人员的工作量，对开发人员也提出了更高的要求，他们需要了解一定的安全知识。
同时，很难将企业的流程和策略加到代码修复过程中。
（2）分布模式
该模式将质量管理人员和产品发布团队纳入到应用安全生命周期中。
分布模式下，相关角色的职责分别为：
•管理人员或安全专家：
设置安全需求定义；
连接到源代码控制系统了解开发进度；
审阅QA团队提供的评估数据或报告。
•QA团队或产品发布团队：
进行扫描配置，还可以选择将扫描工具和现有的Build系统集成，实现在构建过程中自动加入应用代码安全审计的目的；
在设定的里程碑时间点，从源代码控制系统中同步代码并对其进行安全扫描；
将扫描完成的源数据（源数据包括扫描出来的漏洞信息和源代码的正确版本）发送给开发人员；
并将扫描结果形成报告发送给管理团队。
•开发人员：
对发送给自己的安全扫描结果进行优选；
根据项目需要选择修复；
重新测试以验证并将正确的代码检入到源代码控制系统。
分布模式的优点是部署灵活，可以和build过程紧密结合，充分利用自动化的构建过程发现安全漏洞，提高了工作效率，而且QA和产品发布人员承担了一部分的安全诊断工作，减轻了开发人员工作量的同时，使更多的角色参与到应用安全的范畴中。
另外，由QA团队集中产生安全评估报告，也能方便管理团队全面了解企业的应用安全现状。
该模式适合中到大型企业以及希望加入一定控制措施的应用。
但是同样要求开发人员有较强的安全知识。
（3）集中模式
集中模式下，相关角色的职责分别为：
审阅安全分析团队或QA团队提供的评估数据或报告。
•安全分析团队或QA团队：
配置扫描工具，并可以选择和企业的build系统集成；
从源代码控制系统中获取最新的代码进行扫描；
对扫描结果进行优选；
将优选结果根据某种分类打包，提交到企业的缺陷跟踪系统中；
从缺陷跟踪系统中获得漏洞修复的最新情况，形成应用安全报告提交给管理团队；
从缺陷跟踪系统中接受任务，修复代码；
重新测试进行验证，并将正确结果检入到源代码控制系统。
集中模式和其它模式的区别主要是开发人员不需要承担多余的安全分析工作，只将注意力放在和修复其它缺陷一样进行代码修复，由安全分析团队或者QA团队集中承担安全诊断的工作。
这种模式的好处是职责分明，能够和企业现有的系统，如build系统、缺陷跟踪系统集成，很好的遵循了企业固有工作模式。
而且将安全分析工作集中起来，便于企业集中培训和指导安全人员，使得每个角色在参与到应用安全的同时，不用承担更多的工作。
同时，这种模式部署灵活，非常适合大型开发团队或者拥有安全专家的企业。
4.常用的安全检查手段与方法（参考）
测评方法
•网络/系统/数据库漏洞扫描
•渗透性测试
•代码安全性测试工具
•软件安全功能测试
•网络流量分析工具
•密码分析工具
•日志审计分析工具
升级会员 