企业安全解决方案大致分为4种类型:事件驱动类型、合规驱动类型、技术驱动类型以及风险驱动类型。事件驱动类型即“救火队”类型;合规驱动类型即企业开发遵循安全基线,使安全工作有迹可循;技术驱动类型即采购或部署更多的网络安全产品或服务以抵制安全攻击,从而形成纵深防御;风险驱动类型即将安全风险考虑在软件开发过程中,将安全融于体系,从根源上避免或降低安全风险。
SDL无疑是基于风险驱动提出的概念,其核心理念是将安全集成在软件开发的每一个阶段,从而实现安全左移和安全管理的过程化控制。但企业缺乏体系化安全意识、软件开发体系成熟度低等诸多问题可能导致SDL的落地存在一定难度。SDL体系建设是一项包含管理体系、组织架构、工具及平台、知识积累、人才培养等多方面建设的长期性工作。接下来我们将从安全开发团队建设、安全开发管理体系建设、安全开发工具建设和SDL体系建设实施技巧几方面展开介绍,以便更好地将SDL体系融入企业。
在一个安全开发团队建设之初,基于企业目标,选择合适的人才进行团队搭建,虽然可能存在一些高级人才覆盖职能较多的情况,但是随着企业逐渐成熟,逐渐纵向分级和专业化,团队和人员的职能会逐步横向细化。
在安全开发团队建设时,我们需要解决以下问题:
1)确定团队成员和角色;
2)制定团队章程;
3)建立严重性和优先级模型;
4)确定团队合作的运营参数;
5)制订相应计划;
6)创建详细的行动手册;
7)确保访问和更新机制就位。
安全团队建设是关于“人”的事务,需要考虑两个问题:谁为安全负责?如何将安全整合到组织当中?据微软的经验,安全团队必须和软件设计和开发人员进行频繁交互,并且必须被开发团队所信任,以获得敏感的技术和业务信息。出于这些原因,首选的解决方案是在软件开发组织中建立一个安全团队,当然也可以聘请顾问来帮助建立和培训团队。
安全团队建设主要分两个阶段。
第一阶段:此阶段属于人员紧缺阶段,要求人员覆盖能力强(建议招聘资深专业人员),因此本阶段的人员构成及岗位职责均以“精干高效”为主要原则,涉及的相关人员的团队角色、岗位职责如表2-2所示。
表2-2 人员紧缺阶段
第二阶段:此阶段人员充足(可考虑招聘有基础的应届生),安全团队建设走向专业化和精细化。本阶段涉及的相关人员的团队角色和岗位职责如表2-3所示。
表2-3 人员充足阶段
传统的安全开发管理体系建设思路是将SDL流程看作一套独立的安全管理系统,与企业开发管理系统平行,如图2-5所示。这种传统建设存在成本较高、见效较慢、收益周期较长且落地困难等缺点。当下,如何将SDL流程融入企业开发管理是安全开发管理的关键问题。当然,并不是一次性地将SDL流程与企业开发管理系统打通,而是基于企业建设好的开发管理系统,融入安全活动,让安全活动成为开发管理系统的一部分,打造出一个融合安全的企业开发管理系统,如图2-6所示。
图2-5 企业开发管理系统与SDL流程平行
图2-6 融合安全的企业开发管理系统
将安全融入企业开发管理系统涉及两个方面。
1)SDL流程规范制定。各项安全活动的内容及其对应岗位的职责分工、有序执行都需要有效定义,并通过管理制度和技术规范,实现开发安全管理和技术落地。安全开发管理办法用于规范各个角色人员在各个阶段具体的安全活动及相应的安全活动输出交付物。但SDL流程配置也要保持一定的灵活性,因为并不是所有的软件开发项目都一定遵循完整的SDL流程。不同类型的软件项目由于紧急程度、业务场景等情况不同,SDL流程也会有所不同。
SDL流程规范的制定包括管理制度、技术规范、流程安全培训、代码安全规范等的建立。其中,管理制度的建立是指通过了解企业应用系统开发流程和SDL流程实施的痛点,制定和完善应用系统安全开发管理办法、上线安全管理办法和流程表单、报告模板等工具;技术规范的建立是指制定和完善企业应用系统安全威胁库、安全设计库、安全编码和安全测试等技术规范,用于指导开发过程中的相关具体工作,还包括一些安全需求调研表、安全需求设计跟踪表等相应落地表单工具的制定和完善;流程安全培训是指对相应角色人员进行培训,包括产品、开发、架构、测试等人员,以帮助他们加强安全开发意识,使得SDL体系更好地落地;代码安全规范的建立是指通过直接选用OWASP等安全组织发布的通用安全编码规范,或者参考上述通用安全编码规范以及借鉴相同或相近行业的行业安全编码规范,制定符合自身需求的编码规范,以规范开发人员编码,加强安全编码管理,减少相关安全漏洞。
2)SDL流程管理系统的建设。SDL流程管理系统的建设包括两方面,一方面是SDL流程配置问题。不同类型的软件项目,SDL流程也会有所不同。在平台上建立软件项目的时候,企业可根据自身业务情况,配置该软件项目的类别属性和时间节点等。然后,平台根据企业对该类项目定义的安全流程模板,自动建立并分发相应的安全任务给该项目的所有负责人。另一方面是人员统筹问题。不同软件开发项目的参与人员和角色也有所不同,通常包括但不限于产品经理、项目经理、研发工程师、测试工程师、安全人员等。不同角色的权限也是不同的。SDL流程管理针对这些人员和角色进行定义和关联,形成“项目—角色—人员”的匹配模式,而且同一人员在不同项目中的职责可能会有所不同,或者在同一项目中身兼数职。此外,现在很多企业的软件开发项目也会有外部人员参与,因此在SDL流程管理系统上企业需要针对这种情况做出一定的考量和设计。
传统的安全开发中,由于早期技术发展的限制,使用的工具主要分为以下几种:在需求分析和设计阶段采用的威胁建模工具、在编码实现阶段采用的代码审计工具、在测试和验证阶段采用的模糊测试工具、在上线和运营阶段采用的渗透测试工具等。这些工具可以有效地发现一些可能导致安全漏洞的编码错误,也是SDL体系建设不可分割的一部分。然而,鉴于传统安全技术本身和应用场景的限制,早期的安全开发工具在漏洞检测覆盖率、检测精度、自动化程度等方面都有非常大的改进空间。
威胁建模是针对某分析对象可能面临的威胁进行识别、量化和解决的一种结构化方法。在安全开发中,威胁建模通常定义在需求分析和设计阶段,通过建立一个可落地的检查清单和安全基线,在系统的各环节进行风险识别和管理。威胁建模强调系统化和结构化,需要安全人员主动站在攻击者的角度评估软件产品的安全性,带着例如:“不同类型的网络对攻击者而言有多脆弱?”“攻击者可以利用并且能够用来获取高价值资产的最薄弱环节是什么?”“防范这些威胁的最有效方式是什么?”等问题,分析软件产品可能被攻击的切入点,尽可能多地发现软件产品中存在的安全威胁,并制定相应的措施争取消除或最大化缓解威胁,规避风险,确保软件产品的安全性。
实施威胁建模时,安全人员可以采取一种系统的方法,例如根据系统的性质、可能的攻击者的概况、可能的攻击向量和企业的风险概况等信息,分析在软件开发过程中需要进行哪些防御。在软件开发周期的早期进行威胁建模等安全活动不仅能够有效减少安全风险问题,降低修复成本,还可以使企业在管理自己的网络安全方面发挥积极和有效的作用。到目前为止,威胁建模依旧被广泛认为是提高软件安全性的最佳方法。
当前较为流行的威胁识别模型是由微软提出的基于面向过程的STRIDE安全威胁模型。STRIDE安全威胁模型基于数据流图(Date Flow Diagram,DFD)来实现,首先通过数据流关系图将系统分解成各个部件,并证明每个部件都不容易受到相关威胁的攻击,然后对部件中识别出来的威胁进行归类。STRIDE模型将威胁主要分为6个类别,分别是Spooling(仿冒)、Tampering(篡改)、Repudiation(抵赖)、Information Disclosure(信息泄露)、Dos(拒绝服务)和Elevation of privilege(权限提升)。随着全球对隐私安全越来越重视,STRIDE安全模型中又增加了隐私(Privacy)威胁,更新为ASTRIDE(A表示Advanced)。STRIDE安全威胁模型与信息安全三要素(保密性、可用性、完整性)和信息安全三属性(认证、鉴权、审计)一一对应,几乎涵盖了目前绝大部分的安全问题,如表2-4所示。
表2-4 STRIDE安全威胁模型与信息安全三要素和信息安全三属性的关系
STRIDE安全威胁模型的一般构建流程为绘制数据流图、识别威胁、提出缓解威胁措施、安全验证,如图2-7所示。
图2-7 STRIDE威胁建模的流程
第一步:分析业务场景,绘制数据流图。数据流图包含四大核心元素:外部实体、处理过程、数据存储、数据流。在绘制数据流图时,我们需要标出可信边界,即与数据流相交的信任边界。正确的数据流图是确保威胁模型正确的关键,这就要求安全人员对业务场景足够了解和熟悉,一旦数据流图绘制错误或有遗漏就有可能导致威胁分析不正确或不全。
第二步:依据STRIDE模型识别威胁。STRIDE模型划分出的6种威胁类型为威胁识别分析人员提供了较好的参考价值。但并不是每个数据流图元素都覆盖到这6种威胁。如表2-5所示,外部实体可能会受到仿冒和抵赖威胁;处理过程可能会受到仿冒、篡改、抵赖、信息泄露、拒绝服务和权限提升这6种威胁;数据流和数据存储均有可能会受到篡改、信息泄露和拒绝服务威胁。识别威胁阶段不仅需要安全人员具有较高的安全专业能力,也需要非安全人员具有较高的安全能力,例如产品经理在产品设计阶段同样需要完成识别威胁。除此之外还需注意的是,威胁并不是独立存在的,有些威胁一旦被利用,就有可能引发其他威胁,例如攻击者仿冒用户登录网站就有可能导致用户个人信息泄露。
表2-5 数据流图元素对应的不同威胁
第三步:提出威胁缓解措施。威胁建模不仅仅是分析、识别威胁,还需要提出威胁缓解措施。通常,模型在第二步识别出潜在威胁后会生成一个威胁列表。威胁列表内容包括威胁攻击目标、威胁描述、威胁类别、攻击方法、缓解措施以及危险评级,如表2-6所示。其中,危险评级通常采用DREAD、CVSS、OWASP、SRC等威胁评估模型,以量化出威胁的级别(低危、中危、高危和严重),帮助企业确认哪些风险可以忽略、哪些风险可以缓解,以及哪些风险可以规避。
表2-6 威胁列表模板
针对不同的数据流图元素和威胁,缓解措施是不一样的。而且在不同场景下,实现威胁缓解的措施也是不同的。相关的通用威胁缓解措施如表2-7所示。
表2-7 相关的通用威胁缓解措施
(续)
第四步:安全验证。针对威胁缓解措施的落地效果进行验证,即确认威胁缓解措施是否真正起到作用,验证数据流图是否符合设计要求,以及所有的威胁是否都有相应的缓解措施,最终输出一份威胁建模报告,作为后续在开发阶段实现安全需求的参考依据。
威胁建模可以说是安全开发中最基础的工具,除了STRIDE还有其他工具,例如Mozilla提供的开源威胁建模工具Sea Sponge、OWASP提供的开源威胁建模工具Threat Dragon等。
代码审计的目的在于挖掘软件项目源码中存在的安全缺陷以及规范性缺陷,输出漏洞报告和修复意见,帮助开发人员了解可能会面临的威胁、正确修复代码缺陷,以防出现重大漏洞或事故,提升代码质量,提升应用系统的安全性。在实际应用中,我们通常采用“工具+人工”的方式对源代码进行审计,即先通过工具审计并获取检测结果,然后通过人工对检测结果进行复查,从而更准确地发现漏洞、缺陷等问题。
代码审计一般采用静态分析的方式。对于通过工具实现代码审计,通常采用前面提到的SAST工具。SAST工具的优势在于:能够在编码阶段就识别出代码漏洞,进而从源头快速修复,不会破坏构建成果或将漏洞传递到最终应用版本。SAST工具的主要缺陷在于漏洞检测误报率非常高。当前,业内此类商用工具的漏洞检测误报率高达30%~40%,需要用户花费大量时间来做误报排查工作,难以推动开发安全测试自动化,大大降低了实用性。
下面列举几个常用的代码审计工具,包括开源和商用工具。
1)Cobra:一款支持多种开发语言、多种漏洞类型检测的源码审计工具。
2)Upsource:JetBrain部署的git/mercurial/perforce/svn代码审查工具。
3)Fortify:Micro Focus旗下一款静态应用安全测试工具。
4)Checkmarx CxSAST:以色列Checkmarx公司研发的静态源代码安全扫描和管理工具。
5)Synopsys Coverity:Synopsys公司提供的一款静态应用安全测试工具,可发现并消除源代码中的漏洞和缺陷。
6)SonarQube:一款通过检查代码来查找错误和安全漏洞的静态代码质量分析工具。
7)CodeQL:GitHub安全实验室推出的一款静态代码分析工具。
除前面列举的工具外,软件安全市场还涌现出功能各异的代码审计工具,企业可以根据自身情况和安全需要选择合适的工具。
模糊测试的核心思想是向目标程序输入定向构造的随机坏数据,根据程序异常分析与之相关的漏洞、缺陷。虽然通过手动输入无效或非预期的数据也可以触发程序异常,实现模糊测试的效果,但人工构造随机坏数据并手动输入的效率显然是无法接受的。因此,通常由模糊测试工具实现模糊测试。其中,用于模糊测试的随机坏数据通常是由模糊测试工具中的生成器生成的。而且,模糊测试工具通常还提供自动或半自动的生成随机坏数据并输入目标程序的功能。
虽然模糊测试工具在某些特殊场景下(如工业协议)检测异常的准确度高、效果好,但检测效率低,对后台算法引擎的性能要求高。测试数据是自动生成的,不免会产生大量无效测试数据,导致大部分时间都在执行重复和无效的用例。随着对模糊测试工具的研究不断深入,涌现出不少优秀的模糊测试工具,比如基于代码覆盖率的AFL Fuzz、libFuzzer、Honggfuzz,基于数据定义的Peach Fuzz、针对Linux内核进行模糊测试的Syzkaller等。
通过前面章节对渗透测试技术的介绍,我们可以将渗透测试理解为一种站在黑客角度对目标软件和系统进行模拟攻击的安全测试技术。
渗透测试一般流程如图2-8所示,即模拟黑客的思维方式对目标服务系统进行入侵,识别目标服务存在的安全风险。其中,在漏洞发现阶段,我们主要应用DAST技术。其优势在于误报率较低、执行速度较快,服务人员既无须具备编程能力也无须区分目标服务实现的语言,因此可以用来测试各种服务漏洞,如配置管理类(HTTP方法测试、应用中间件测试等)、会话类(Cookie测试、会话测试等)、授权类(未授权访问等)服务,甚至可以发现其他测试方法遗漏的问题,如身份验证或服务器配置问题。DAST也存在一定局限:虽然可以发现问题,但无法定位问题代码的位置和产生问题的原因。开发者单靠DAST工具解决安全问题是非常困难的,在发现问题后需要回溯并修复代码。因此,渗透测试过程中的漏洞验证和后续分析才是关键,而这部分通常是通过渗透测试工具完成的。
以下是几种常见的渗透测试工具。
图2-8 渗透测试一般流程
1)灵脉BAS:悬镜安全开发的一款基于深度学习的新一代持续威胁模拟与安全验证平台,功能相对强大且性能出色,适合红蓝对抗、安全体系持续验证、黑盒Web应用安全测试等场景。
2)AppScan:IBM开发的一款比较好用且功能强大的黑盒Web应用安全测试工具,扫描速度中等、误报率低。
3)AWVS:一款知名的网络漏洞扫描工具,漏洞库全、扫描速度快且误报率低,功能相对强大且性能出色。
4)Nessus:一款拥有全球最多用户的系统漏洞扫描与分析软件。
5)OpenVas:一款开放式漏洞评估系统,常被用来评估目标主机中的漏洞,是Nessus独立出来的一个开源分支。
6)Nmap:一款用于网络发现和安全审计的网络安全工具,可以检测目标主机是否在线、端口开放情况,侦测运行的服务类型及版本,侦测操作系统与设备类型等信息。
7)Metasploit:一款开源且强大的渗透测试框架,涵盖渗透测试全流程,集成大量专业级漏洞攻击工具,偏手动操作。
8)Canvas:ImmunitySec出品的一款专业的自动化漏洞利用工具,包含大量普通漏洞利用库及“军工级”武器库,可为渗透测试人员提供高质量漏洞利用样例、自动化漏洞利用系统、漏洞利用开发框架。
9)Cobalt Strike(CS):一款综合型红队渗透工具,分为客户端与服务端,集成了大量自动化漏洞利用及攻击技术,偏自动化与团队作战。
SDL本质上仍然只是一种安全开发方法论。不同组织、不同场景的SDL体系建设肯定是不同的。从传统的安全测试、安全响应发展到开发全生命周期安全管控,从必须解决的问题发展到应满足的最低要求,代表了软件行业对安全需求的了解愈加深入。不同类型的企业因其安全实施方式不同、安全成熟度不同或安全侧重点不同,SDL体系布局也是不同的。
安全管理工作主要分为两类:一类是具体实施的安全工作,主要包括安全培训规范、安全需求分析、安全设计、安全编码测试、安全部署等;另一类是安全质量管控工作,主要包括安全评审、代码安全审计等。其中,安全质量管控工作是SDL体系顺利实施的关键点。通常,安全管理工作内容如图2-9所示。
图2-9 安全管理工作内容
为保证SDL体系顺利实施,企业应当在SDL体系构建过程中着重做好以下工作。
1)做好充足的准备工作。该阶段活动主要包括网络安全人才准备、开发流程和开发管理调研、安全现状评审。其中,网络安全人才准备包括网络安全管理体系人才、开发安全人才、安全测试人才的准备;开发流程和开发管理调研是指对企业现有的开发流程和开发管理进行梳理;安全现状评审是指对现阶段的系统进行安全分析与安全问题统计。
2)建立开发安全管理制度体系。做好安全现状评审再进行体系建设是一个关键点。只有实时安全评审才能够帮助企业梳理清楚开发过程中的安全目标,厘清各团队在安全活动中的分工和职责。
3)设计安全评审流程。安全评审是保证安全需求分析、安全设计等具体安全活动质量的关键。该阶段的活动主要包括梳理并制定评审流程、确定安全评审的组织架构以及规定安全评审的输入和输出。
4)人员培训。对企业开发人员进行安全培训是保证安全管理工作实施的关键。开发和测试团队对安全管理工作的理解和支持是SDL体系顺利实施的基础,因此必须重视人员培训,精心开展相关人员培训工作。
5)SDL体系试运行及运行。SDL体系最终需要在企业内部推广和运行,因此对于不满足企业业务特点的方面,企业需要及时调整,以适配业务。
6)SDL体系运行有效性评估。为保证SDL体系的成功实施和持续改进,企业必须定期对SDL体系运行效果进行针对性评估,根据评估结果,进行整改。该阶段的活动主要包括确认体系评估内容、选取或建立有效评估方法。