浅析从网络安全演练看软件安全问题

为了表示公众号还或者，版主用一篇2020年的稿件来充个数，请各位读者参考

通过网络安全演练根据某单位主要安全漏洞及渗透点发现，大量的安全问题源自于软件问题，综合分析主要包括以下几个方面：

1. 1.  代码缺陷带来的安全问题：

2. 2.  安全功能失效或不足

3. 3.  授权不良好

上述问题为某行业业务系统安全及数据保护带来极度的危害，如何有效的建立网络安全保护，降低和减轻由软件问题带来的安全性影响成为保护该行业的一项重点工作，本文将从软件安全开发过程控制的角度讨论由软件问题导致的网络安全防范手段。

1. 1.  软件安全开发与OWASP

国际OWASP（开源Web应用安全项目）组织提供的Web Top 10[1]漏洞描述常见的Web10大漏洞，分别是

1. 2.  从软件生命周期角度审视软件安全开发

从系统工程的角度来看，一个软件工程的完整流程应保含五个阶段，需求、设计、开发、测试、验收。SDLC从软件开发质量控制的角度增加了每个阶段中的质量要求；微软为了良好的解决软件安全开发问题，在传统软件工程的基础上增加了培训/教育和响应两个环节，并且在7个环节中以安全开发控制为主要元素，如图：

图1 微软SDL流程图

从我国软件开发过程中，由于开发公司对所开发业务的理解差异化，开发人员更多的强调于功能实现，缺乏软件安全开发的基础认识和技能，所以从目前软件问题而言，承担该行业开发的团队于公司必须能够满足定期的安全开发和安全攻防技术的基础培训，使开发者能够理解软件安全开发的价值和目的，并且能够从需求阶段将安全功能于应用功能相结合，符合《网络安全法》第3章第2节中，对于国家关键信息基础设施系统建设必须于安全建设“同步规划，同步建设，同步使用”的原则；

安全需求的创建是软件工程的第一阶段，本阶段需要组织建立软件安全愿景，通过文件化约定可接受的软件代码缺陷率，在具备足够的技术能力的前提下还应该提出软件代码红线-即针对缺陷带来的影响制定Bug栏，从而为软件验收提供一种可客观验证的度量指标。在需求阶段还应针对该行业特色的保密性制定相应的数据安全保护规则；

安全的设计是软件安全开发的前提和必要条件，开发必须覆盖设计，因此软件的安全设计成为软件安全开发的基础，本阶段需要开发团队根据相应的标准和准则，比如：网络安全等级保护标准。从本阶段开始建立威胁模型，微软提供了开源的轻量级威胁建模工具Microsoft Threat Modeling Tool 2014 (TMT)[2]，如图2：

图2 微软威胁建模工具图示

图3 Microsoft Threat Modeling Tool 2014 (TMT)报告示例

通过良好的威胁建模工具与业务需求相结合确定良好的安全设计，为软件安全开发奠定基础；

开发实施是对软件具体实现的阶段，大量的软件代码缺陷问题都产生于本阶段。针对本阶段应要求开发团队提供软件安全开发编码手册，例如：OWASP安全编码指南[3]；同时开发团队在开发前还应提供第三方安全函数库、SDK代码引用规范等手册或指南。从项目管理角度而言，开发团队应该能够严格遵照开发实例执行开发活动；

验证是对软件安全质量进行审视的重要环节，从单元测试到集成测试是贯穿于整个开发生命周期的活动，同时多元化的验证手段为软件安全控制提供必要的支撑，传统开发缺乏对软件源代码的审计，过多的依赖于渗透测试。渗透测试强调测试的深度，从而使的测试的效果更多的依赖于测试人员的水平和能力，很难为组织提供一种统一的准则；同时，渗透测试往往是在软件开发完成后才进行，这使得测试结果很难从软件代码角度形成纠正，组织必须为此付出额外的代价通过第三方产品进行纠正。因此，源代码审计、动态跟踪、业务穿行与渗透测试相辅相成，为验证活动提供客观的可度量凭证。

常见的源代码审计工具包括开源与商业版两类，商业版具有可跨平台审计，等优点，但价格昂贵，操作难度大，如：HP Fortify SCA。开源源代码审计工具无需付费，使用简单，轻量级，但仅能支持单一开发环境，比如：findBus。通过良好的测试环节可以有效发现软件代码存在的缺陷及功能错误，并在软件封装交付前进行纠正。从而降低诸如：访问控制失效和软件代码缺陷的概率和影响程度。

图4 Fortify SCA示例

图5 FindBugs示例

发布是软件完成验收后的部署过程，OWASP SAMM[4]中强调了软件安全开发的安全部署环节，强调通过环境强化、补丁加固和运营管理控制建立对软件的安全部署和运行提供指南。软件开发商应该提供软件安全部署手册及配置管理手册，对软件所依赖的操作系统、数据库DBMS系统以及应用支撑软件和数据库中间件提供明确的安全配置基线和手册；

响应是微软SDL最后一个阶段，本阶段要求开发商必须针对软件可能出现的问题预先制定应急预案，并在软件产生安全事件后能够及时响应，比如：应急补丁、软件修复等工作。并依据《网络安全法》“网络产品、服务的提供者应当为其产品、服务持续提供安全维护；在规定或者当事人约定的期限内，不得终止提供安全维护。”建立良好的SLA。

1. 3.  建立安全软件开发控制

软件安全开发流程是有效解决软件安全开发环节中的相关问题的手段和方法，本节基于软件开发生命周期提供了一种可行的软件安全开发解决方案蓝图。

• 构建该行业软件安全开发流程

根据软件开发通用瀑布模型; 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为系统需求、需求分析、软件设计（概要设计、详细设计）、代码和纠错、测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

本文所述软件安全开发流程是建立在软件开发模型基础之上，根据美国IATF《信息保障技术框架》所描述的ISSE与SE的对应关系中，我们将瀑布模型进行转换为软件安全开发生命周期流程：

图6 瀑布模型进行转换为软件安全开发生命周期流程

• 系统安全需求分析

系统安全需求分析是建立在业务需求基础之上，首先应该对业务所面临的安全风险进行识别和分析，基于应用风险以及软件所承载的业务使命、数据的重要性建立威胁模型，寻找接触点，以便为软件安全需求提供依据和参考。

• 软件安全需求

需求分析包含了获取客户需求与定义的信息，以及对需要解决的问题所能达到的最清晰的描述。包括理解产品必需实现的功能，必需达到的性能水平，以及必需实现兼容的外部系统。分析阶段的结果通常是一份正式的需求说明书，这也是下一阶段的起始信息资料。

软件安全需求是在需求分析基础上通过威胁模型分析组织所需的安全性功能和安全性保证，基于GB/T 25058 -2019《信息安全技术 网络安全等级保护实施指南》要求首先根据GB/T 22240-2020 《信息安全技术 网络安全等级保护定级指南》对待开发软件进行定级，然后根据所订等级增加安全控制功能，功能可参考GA/T 711-2007《信息安全技术 应用软件系统安全等级保护通用技术指南》相应等级下的安全功能要求建立描述。

• 安全概要设计与详细设计

“定义硬件和软件架构、组件、模块、界面和数据等来满足指定的需求。”安全概要设计是针对软件安全需求中所需要的安全控制组件及接口进行描述，软件概要设计可参考《GA/T 711-2007 信息安全技术 应用软件系统安全等级保护通用技术指南》设计安全功能与模块

• 代码安全和纠错

软件开发过程中编码安全问题是构成软件安全的重要环节，传统软件开发过程中并不会针对软件代码安全进行有效的控制与管理，致使软件在完成开发后面临巨大的代码构成风险，最常见的如：SQL注入、XSS跨站脚本、CSRF等多种软件缺陷，导致应用平台被入侵，国际非盈利性组织OWASP提供了完善的软件代码安全相关手册及测试指南作为最佳实践为全球软件安全开发带来极大的推动；因此，在常规开发中，该行业应根据自有的或者委外开发机构的开发人员的水平与能力，要求其参考类似标准编制自己的软件安全编码手册及测试指南，并在工作中具体应用，同时手册也作为验收测试用例及交付文档。

• 操作和维护

软件开发人员往往会忽视软件与硬件、通信及操作系统之间所形成的相互关系，没有百分之百安全的代码，因此通过安全部署与操作维护是弥补和降低软件安全风险的最后一道防线。OWASP在SAMM《软件保障成熟度模型》中提出，通过强化环境作业流程在软件发布前针对已知的漏洞进行环境加固，包括主机环境（操作系统安全配置、发布环境强化）、系统环境（安全初始化、基线管理）和通信环境（端口控制、协议控制、服务控制、边界隔离）。通过上述配置在运行维护阶段不断通过漏洞管理对相关资源和组件进行动态的风险管理，从而实现组织动态的软件安全。

图7 软件开发需求流程图

• 安全废弃

安全废弃是软件安全生命周期的终结，必须根据应用系统承载的数据的重要程度，为组织定义良好的安全废弃过程，不良的信息系统废弃过程会造成组织大量的数据丢失或者泄露，直接影响到组织的生产和无形资产的损失，通过有序的管理控制对信息系统废弃过程建立控制约束，降低信息在废弃阶段造成的损失或危害。

根据GB/T 25058-2010《国家信息安全等级保护实施指南》，我们将废弃过程通过下述流程进行控制。

图8 软件废弃流程

1. 4. 总结

应用安全的本质是软件安全问题，软件安全问题的根源是软件开发过程控制，系统化、工程化理论是降低软件安全风险的重要手段和途径。传统的软件安全控制往往过于关注代码缺陷的降低，但是人总是存在缺陷，再优秀的开发者也会存在Bug，因此，建立良好的软件安全开发过程控制是实现软件安全的必然途径。

[1] OWASP Top 10是针对开发人员和Web应用程序安全性的标准意识文档。它代表了对Web应用程序最严重的安全风险的广泛共识。被开发人员全球认可，是迈向更安全编码的第一步。-https://owasp.org/www-project-top-ten/

[2] http://microsoft.com/security/sdl.

[3] http://www.owasp.org.cn/owasp-project/secure-coding

[4] http://www.owasp.org.cn/owasp-project/OWASPSAMM2.0.pdf

原文始发于微信公众号（老烦的草根安全观）：浅析从网络安全演练看软件安全问题