Gartner 2017调研报告:DevSecOps应当做好的十件事(下)

前文:《Gartner 2017调研报告:DevSecOps应当做好的十件事(上)

(4)不要固守传统的静态/动态分析方法,应当适应新的变化

在上一节中,我们强调了识别已知的组件、库和框架中的已知漏洞的重要性,但是对于应用程序中那些实际存在的10%~40%的自定义代码该如何处置呢?执行DevSecOps,意味着你应该寻找自定义代码的未知漏洞。但是,不要固守那些传统的针对应用程序安全测试的静态和动态分析工具和服务,要明白这些传统的测试解决方案需要被重构、调整或更换,具体步骤如下所示:

  • 可以从把简单的测试直接集成到IDE开始。一些开发者提出基于IDE的安全扫描的指标无法被跟踪和报告,这可能成为与DevOps建立合作伙伴关系的契机。
  • 所有的扫描工作应该是完全自动化的,在开发者的CI/CD工具链和诸如代码提交之类的事件处理过程中自动的通过APIs的方式触发,通过API引发开发商的CI / CD的工具链和过程事件像提交代码。第三方产品(如Cybric和BMC)可以帮助开发者实现安全检测自动化。
  • 扫描不应该要求安全专家运行、配置或解释结果,开发者就可以做到。
  • 扫描应该不断调整,以减少误报,即使是牺牲假阴性(漏报增多)。
  • 扫描结果应直接运送到bug跟踪系统或开发者面板,这依赖于开发者使用的CI / CD工具和方法。

无论执行哪种安全扫描,SRM负责人都应该按风险把发现的漏洞进行优先级的排序,并提供给开发者。工作重点应放在减少误报,在充分信任开发者的基础上指导他们优先修复严重的漏洞。正是因为这个原因,几个AST供应商正在尝试使用机器学习来修正扫描结果。接受较低风险的漏洞是可以的,这些漏洞可以通过运行时的保护控制来减轻,或者在将来的软件迭代中加以解决。

考虑交互式应用安全测试(IAST)替代传统的静态应用安全测试(SAST)和动态应用安全测试(DAST)是可行的,我们建议这么做。IAST是在DAST基础上的一种该进形式,测试过程更加可视化,包括内部和外部的。IAST综合了DAST和SAST的优势,在确保测试代码覆盖率的基础上尽可能的做到了减少误报。然而,目前支持IAST的平台有限,需要应用程序在运行状态下才能执行IAST。如果IAST工具被用作开发者进行扫描的诱导工具,那么之后需要一套完善的全回归测试(而且最好是自动化的)进行配合。

一些AST供应商提供“测试即为服务”。可以将其融入DevSecOps中,但运作时间限于双方严格的服务水平协议(SLA)约定,使用IDE进行轻量级的、近实时的扫描。例如双方可以约定,四小时内扫描50%,八小时内扫描80%, 24小时内扫描90%,SLA还包括一些服务有效性的保障,不符合条件的话可能就会被罚款。注意,即使SLA约定的条款“时间紧迫”,以致于可能不适合极为迅速的DevOps周期,但供应商也应该通过API提供测试服务,确保开发人员仍能使用相同的应用程序“提交”代码进行测试或检索结果。

(5)培训所有开发人员基本的安全编码知识,但不要期望他们成为安全专家

DevOps产品团队的每个人都应该接收安全培训,培训内容因角色不同而有所不同。开发人员应当获得最多的培训,测试人员和产品负责人相对少一些。注意,尽管应当向所有开发人员培训基本的安全编码知识,但却无法让这些团队成员成为安全专家。例如,大多数应用层漏洞可以通过设置输入白名单和过滤掉多余的字符进行处理;SQL注入和跨站点脚本攻击的根本原因是在输入时缺乏适当的检测;同样的原则也适用于数据库和配置文件以及网络流量的输入检测。

重点推荐OWASP Top10和类似的公开可用的安全测试指南。培训应包括:

  • 如何构建并维护简单的威胁建模场景(像坏人一样思考)
  • 设置输入白名单,对用户的输入和文件进行过滤和消毒
    • SQL注入
    • XSS
    • CSRF
  • 注射
  • 破坏认证和会话管理
  • 不安全的直接对象引用
  • 安全性的配置错误
  • 基本的安全防护
    • 为什么不能在应用程序代码或脚本中嵌入密钥或凭据?
    • 打补丁的重要性
    • 为什么黑客专注于盗窃管理员的凭据?如何避免此类攻击?

理想情况下,第一次培训时应当由相关人员当面进行,之后定期进行年度培训,同时运用线上培训的方式加以强化。此外,如果在开发中发现了安全问题,则可以根据需要对开发人员或团队进行进一步的具体培训。例如,如果在开发人员的代码中发现了一个严重漏洞,则可就该问题上进行进一步的培训,避免问题再次发生。

(6)采用安全捍卫者模型,并实现简单的安全需求收集工具

在《DevOps Security Champions Help Organizations Gain Leverage Without Training Everyone 》一文中,我们建议企业使用安全捍卫者模型,将有效的信息安全团队资源充分应用于开发组织。将安全捍卫者的头衔授予组织中能够担当现场顾问和专家的员工,他们可以在开发过程的早期就预见到可能存在的潜在的设计或实现问题。

安全捍卫者可以有效提高复杂的安全编码问题的感知度,他们能够提供及时的、针对团队编码过程中遇到的实际问题提出修复方案,而不是抽象的、不可靠的问题。例如,对于风险为低级或中级的新应用程序开发项目,安全捍卫者可以作为安全需求收集和威胁建模的起点。推荐企业使用一个简单的安全需求收集和威胁建模工具,使得开发人员尽可能地轻松完成任务。对于风险级别高的应用程序,目标应该尽可能的提高,建议直接联络信息安全团队进行全面地威胁建模和安全需求收集。

SRM负责人应该识别那些对安全感兴趣的开发人员,并为他们提供一个扩展的角色,即安全捍卫者。这样做会使有限的安全培训的效果更佳,为敏捷开发过程和DevOps团队成员提供一定级别的安全监督。

(7)禁用源代码中已知的易受攻击的组件

前文已经提及,现代应用程序的大多数风险是由于使用已知的易受攻击的组件、库和框架导致的。与其等到应用程序组装好之后在扫描环节才被识别出这些已知漏洞,提前警告开发人员不要下载和使用这些已知的易受攻击的组件可能是更好的解决问题的办法,尤其是当存在严重漏洞时,可以选择提前阻止开发人员下载。

实际开发环境中,是否允许开发者从互联网上下载代码的问题应由安全和开发架构师共同协商处理。某些组织认为这样做的风险很高,因此开发人员被阻止直接从Internet下载这些风险组件;还有一些组织,会限制用户将代码托管到公共代码平台上(如GitHub)。

开发人员下载的代码库中可能包含较老的、已知的易受攻击的软件版本。为了解决这个问题,一些提供商提供了“开放源码软件防火墙”,以便向开发人员披露这些代码库的安全态势,便于更好的决策使用哪个版本的软件。通过这种方法,开发人员可以明确的清楚那些组件和代码库存在严重漏洞,避免下载并使用(例如,可以使用漏洞的CVE评分来判断该漏洞的严重程度)。

对于那些不允许开发人员直接从公共Internet下载代码的组织,需要考虑使用安全的代码存储库模型,此时,需要信息安全团队与开发团队协同合作,建立、审查并维护这些组织内部托管的组件存储库,在这个过程中,开发架构师和信息安全工程师之间应保持联系,随时更新开发人员请求使用的新框架和代码库。此外,一些机构会要求使用符合安全需求的、预先批准的、标准化的代码库或组件(如认证、授权、密钥管理、加密、点击劫持和输入过滤),以便于进一步降低风险。

(8)使用自动化脚本确保并践行操作的规范化

不要对基础设施和运营平台的安全管控。想要实践“基础设施作为代码”的话,针对基础设施也应当有类似源代码控制一样的措施,包括所有的软件项目的版本控制(如配置脚本和可执行文件)。应确保这些控件使用了正确的脚本版本,平台控制和配置脚本不应包含机密信息(如凭据、密钥或其他公开的漏洞)。可能的话,需要针对这些工具进行专门的安全扫描。

对于这些自动化代码、脚本、方法或生成脚本的工具等基础设施和平台构件,应看作具有特定附加风险的有价值的源代码,因此,有必要对它们使用源代码相关的安全管控,包括审计、保护、数字签名、变更控制和版本控制,以保护这些基础设施和平台构件。

容器和容器管理系统必须具有记录并留存变更控制信息的功能,确保所有已知的漏洞已经被妥善处理。

总而言之,所有变更都应当有明确的记录。

(9)使用强大的版本控制措施管理所有代码和组件

在软件开发的整个生命周期中,使用适当的工具(如分布式版本控制系统[DVCS]和应用程序生命周期管理[ALM]工具)进行恰当的源代码版本控制。

在快速更迭的开发环境中,捕捉变更的每一个细节至关重要,包括代码的出处、更改的内容、时间和操作者,以及是否已经获得了相关授权(例如,其他产品经理的产品可能受到变更的影响)。在大多数情况下,并没有一个明确的权限模型,但是这种情况可以适用“信任和验证”的原则,使用一些方法获知某人调用了某个API或使用了某些代码。明确使用的代码与生产中实际使用的代码之间的区别,这样做有利用在将来的迭代中通过删除未使用的组件来降低风险,或者删除那些存在漏洞但却未实际使用到的代码。

代码从预发布到生产,检测代码的数字签名,并确保最终的版本是最后一次扫描过的版本。注意,在代码运行时不要实例化,无需确认它是否被篡改,代码配置即防篡改确认是“防护”阶段的功能。平台运营团队将使用传统的变更控制技术(包括ITIL方法)为产品团队提供底层的基础设施和平台。

(10)默认的基础架构应当是“不可变的”

对于经常更新的现代化应用程序而言,维护这些应用程序需要采用一种更安全的操作方式。在可能的情况下,不允许任何人直接对生产系统进行更改。基础设施应当是“不可变的”。当需要更新时(包括安全补丁和配置更改),这些需求应该返回到开发阶段并由自动化工具进行部署。

生产的镜像(包括库、组件和OS)应当保存在安全的存储库中。如果某个文件需要修补,请在安全的存储库中进行,而不是直接在生产系统上修改。此外还需要确保新修补的应用程序可以使用现有的DevOps流程进行部署。要知道大多数的安全事故和操作不当导致的事故产生的根本原因是管理不删或未打补丁,流程规范化可以带来安全和操作上的益处。

从操作和安全的角度来看,许多现代容器和工作流程系统都包含自动化的健康监测功能,当偏离预期状态时会发出警报。如果工作流程行为怪异或与正常状态相比偏移过多,则可以从活动资源池中删除它,用清洗后的良好状态的工作流程取代它。

从安全的角度来看,这种模式是先进的,并且有可能从根本上提高安全性,通过主动“杀掉”目前的工作流程,并用已知的良好状态替换它们,即使它们看起来是“健康的”。假设一个聪明的黑客以某种意想不到的方式在系统中获得了立足点,通过周期性地、随机的杀死工作中的进程,可以使得攻击者的立足点丢失,无法获得持久性。五年前,曾提出过一种“利用系统的工作流程作为一种对抗对抗高级持续性威胁的策略”的概念,那时候还只是一种愿景,但现在技术的发展使得这种方法成为可能。

更多资料

  1. 完美是好的敌人”—维基百科
  2. Equifax发布的网络安全事件的细节,及高管人事变动”—Equifax
  3. 基本的安全培训框架(示例)

OWASP Top10

安全代码编写指南”—微软

  1. Truffle Hog:Github上的密钥狩猎工具:链接1链接2
  2. 软件组成分析服务
  • ANX (Positive Networks)
  • Black Duck
  • Flexera Software (acquired Palamida)
  • Lexumo
  • Sonatype
  • SourceClear
  • Synopsys (acquired Protecode)
  • Veracode
  • WhiteSource
  1. 提供将简单测试直接集成到集成开发环境中的供应商(示例):
  • Checkmarx
  • MicroFocus DevInspect (并购HP Fortify)
  • Synopsys SecureAssist (收购 Cigital)
  • Veracode Greenlight
  • WhiteHat Security
  1. 简单的安全需求收集和威胁建模工具(示例)
  • Continuum Security
  • Foreseeti
  • Microsoft Threat Modeling Tool
  • OWASP
  • Security Compass
  • ThreatModeler

原创文章,作者:M0tto1n,如若转载,请注明出处:http://www.mottoin.com/107436.html

发表评论

登录后才能评论

联系我们

021-62666911

在线咨询:点击这里给我发消息

邮件:root@mottoin.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code