长亭百川云 - 文章详情

基于研发过程的漏洞治理及经验

我的安全视界观

58

2024-07-18

很久以前,就想写一篇关于SDL与DevSecOps的文章,但疏于实践一直未能动笔。想写的原因很简单,因为总是听到有人说SDL落后、DevSecOps相关技术更高超。一提到研发安全建设,不分研发模式都在赶时髦一样地说DevSecOps。从我的观察来看,不结合研发模式来做研发安全,都是不成功的。

在数字化浪潮的推动下,一些公司已经完全步入DevOps模式,有的则出现瀑布、敏捷或DevOps并存,且后者是居多的。所以如何在多种研发模式下进行有效的研发安全建设,成为一个必须解决的难题。经过近十年的实践,终于在探索解法上有一点点收获与经验,于是有了“深耕研发安全”这一系列文章。

在上一篇中,找到了研发安全的切入点,按照常规思路就应该想出对应的解决之道。本文将深入“架构-编码-配置 + 应急响应”,针对漏洞生产源,提出治理的实践方法及经验。

01 架构设计缺陷

      ————————

在设计阶段要关注安全需求是否在设计中体现,对设计进行评审以发现其他潜在的安全风险,涉及的安全活动主要是:

  • 安全需求纳入检视:部分安全性需求检查的第一道关卡,需要在设计中体现出来。通过Excel表格反馈+word证据截图或问卷调研的方式,对项目中的安全需求落实情况进行review。可以采取业务方收集证据反馈,架构师或跨业务方架构师检查,安全团队抽查的方式(前提是安全团队联动公司级架构师团队或技术委员会,将安全检查融入日常工作中,让其承担一部分安全的职责);

  • 产品架构安全评审:对于重要产品、产品的高危功能等应该特别关注的产品,额外进行架构安全评审。通常可以使用攻击树的分析方法(安全人员更加擅长,更高效发现可能的攻击点),与业务方开发等人员进行安全评审,重点在发现安全风险并治理、以及阻断攻击链。

02 编码忽略安全

      ————————

在代码层面引入的安全问题,有比较多的治理方式。比如从检查方面来说,可以对引入的第三方组件进行漏洞和后门检查,对自研的代码进行漏洞扫描;从预防或左移的角度来说,可以制定并推广安全编码规范、安全组件,想办法让开发避免引入漏洞。以下是一些常见做法及经验:


  • 编码安全规范:网上有不少公开的安全编码规范,比如一些互联网大厂、云平台及开发社区。如果解决合规(过检查),可以完全照搬;但要是想真正解决问题,则应该进行部分参考,大概占比可达20%~30%。剩余部分应该根据历史安全测试的结果、日常运营过程中遇到的安全问题等实际已发生的风险进行制定,类似输出OWASP Top 10类别,因为多了不一定能够落地,先出一个版本再优化迭代;

  • 静态代码扫描:理论上可以联动编码安全规范,检查其是否落地及闭环。将规范中的内容逐一落到SAST工具的检测规则上,从技术层面真正的做到规范检查,效果要比安全培训、培训后考试更好。但很多公司的代码扫描还是先关注高危漏洞,规范规则的扫描可以排在第二顺位。第二想介绍的是自动化,静态代码扫描是比较好与研发工具(如gitlab、jenkins)联动,开发提交代码就触发扫描,扫完就推动漏洞给研发并提醒修复。第三是误报,所有工具的检测规则都需要调优,常见的有结合业务特点写增强型规则、普适性规则在一些场景中误报则要加白…,一定是要投人运营才能降低误报率及提升检测能力。此外,研发安全团队一定要先优化规则,再要求或推动业务方修复漏洞,因为SAST误报真的是非常多,业务方会认为安全不专业、是麻烦事儿,以至于产生抵触情绪、不便开展后续的工作;

  • 开源组件扫描:主要存在两个安全问题。第一个是漏洞,开源组件的CVE漏洞特别多,但是目前市面上的检测工具基本上都是先拆包、然后根据指纹和CVE漏洞库碰撞,只要版本匹配就会报存在漏洞,所以带来的误报会非常多,真正受影响的情况特别少。不过在一些监管属性比较强的行业,只要是工具报的高危漏洞都要求处理。如果是误报给出依据,若是真的漏洞则要去修复;相比在互联网这种宽松的氛围下,基本都是实际带来了可利用风险,才会去处理。无论什么行业,对于SCA工具扫描的进一步研判,都是行业中所需要的安全能力。第二个问题是开源组件投毒,如 Python或npm源管理比较松散,就会出现组件包伪造、源账号攻击等方式进行投毒。最佳方法是对源进行统一管控,但大多数公司都做不到。不过即使做到了,当首次引入时同样会面临检测的问题,然而这是绝大多数公司缺少(静态特征检测、动态跑沙箱做行为分析),基本只能依靠威胁情报进行响应;

  • 安全组件建设:不仅是单纯的指实现安全效果的CBB,也可以是经过安全性改良/定制的开发框架。这项活动的实施难度最大,一是要有懂安全的开发人员或会开发的安全人员支撑,能够将常见的文件操作、输入输出处理、数据库操作等常规操作会发生的安全问题梳理清楚,结合开发框架或开发语言来写组件或改良框架;二是推广应用的问题,基本只是适合于新的项目,因为已上线系统发现漏洞后去改框架或换实现方法非常麻烦,不会有业务同意这么干。所以就只能瞄准新系统,亦可以把该项前置到需求或设计阶段,要求业务方使用。    


03 配置发生错误

      ————————

在产品发布与部署阶段,不合规的方式或不良操作习惯,可能带来一些安全问题。不过如果具备统一的发布和部署能力,则可以规避很多潜在风险,只需关注“源头”。尤其是针对PASS层的软件:


  • 安全配置基线:属于基础安全的范畴,但基础不牢真会地动山摇。去年之前我们集中力量投入到应用层的安全性检测,默认了业务线给出的内部微服务有gateway管控、内部数据库、大数据组件服务有iptables的说辞,尤其是对基础服务投入很少。随之而来从SRC收到很多关于pg硬编码、版本过低可提权、redis未授权获取root权限等漏洞,从而导致产品被攻陷。比较有效的治理方式是基于攻击视角的安全基线,众所周知CIS安全基线比较全,但实施的时候就会比较麻烦,所以需要按照攻击思路来精简。如针对Redis,关注启动服务不使用root权限、设置账密验证或在配置文件中指定访问IP源、禁用可以执行系统命令的函数,这并非绝对或死板执行,需要根据业务实际情况进行调整,原则就是常说的最小化(服务最小访问、权限最小)等;   

  • 黑盒漏洞扫描:定期对操作系统镜像模板、最小化容器模板、数据库模板、大数据开源组件模板等进行黑盒扫描并修复漏洞,以检验默认配置执行情况;在测试阶段再次进行主机漏洞扫描和web漏洞扫描,发现近期暴露出的漏洞及配置类漏洞,以保证基础软件默认安全。

04 应急响应托底

      ————————

上述内容都做好了,是不是产品就没有漏洞呢?答案是否定的,就如没有绝对的安全一样,投入的资源越多、被外部发现的概率就会越小,但永远不会出现无漏洞。其中,有两个主要的原因:

  • 漏洞是动态的:产品使用到的开源组件现在没有漏洞,但在未来可能被爆出存在可利用的漏洞,故此产品也会受到牵连;

  • SDL并不是万能的:通常在研发安全体系中,会出现安全工具能力不足或被bypass、安全测试或开发人员出现纰漏等问题,导致漏洞未被发现。

所以需要建设预警和响应机制,进行托底式的快速响应。在预警部分,通过资产管理摸清产品中使用到开源软件和组件,对外部情报源如开源软件官网、安全公司威胁情报、安全微信群、安全媒介等进行监控并告警;在响应部分,需要设置跨组织的应急响应团队(如安全、业务线、公关、法务、交付等)、流程和响应要求,以应对突发的产品安全事件。由此保障这些组织、流程、机制等的正常运转,才能做到相对可控。


长按识别二维码,和我交流

More...

-- 深耕研发安全 --

-- SDL 100问 --

-- 软件供应链对抗探索 --

--------- 实战演习 ---------

--------- 安全运营 ---------

--------- 软件安全 --------- 

--------- 企业安全 ---------

--------- 渗透测试 ---------

--------- 安全开发 ---------

--------- 个人体验 ---------

相关推荐
关注或联系我们
添加百川云公众号,移动管理云安全产品
咨询热线:
4000-327-707
百川公众号
百川公众号
百川云客服
百川云客服

Copyright ©2024 北京长亭科技有限公司
icon
京ICP备 2024055124号-2