浅谈漏洞修复的方法论


  • 序言mysql

  • 大人,时代变了linux

    • 面临的场景不一样web

    • 技术的不一样redis

  • 应该怎么作算法

    • 战略sql

    • 组织编程

    • 技术json

    • 策略windows

  • 将来的发展安全

  • 是不是创业的方向

序言

近日在看到安全牛发布的《漏洞管理的八大趋势》,其中提到了“大量数据和案例代表,虽然漏洞评估和管理工具不断丰富,可是漏洞管理重在“管理”,企业的漏洞管理或脆弱性风险相关管理依然存在很大的改进空间,例如,人才资金匮乏、缺少对漏洞风险和受影响资产的感知能力、企业孤岛和部门战争、漏洞修复效率低下等。”这里仅仅谈谈“漏洞修复”这一个小的环节,就有不少的发散点。

是的!闭环漏洞很辛苦,够了!别再让业务修复各类安全漏洞了。

市面上乙方的各类安全加固方案都谈到windows linux系统基线的操做,redis、mysql的加固,常见web漏洞修复方法,操做手册面面俱到,但鲜有对具体的修复工做开展起来的组织和策略的探讨。通过实战的同行必定知道像fastjson这样的高危漏洞,并非简单的响应就完事,若是安所有门仅仅给出业务“升级”两个字的修复方案,那真是“半天云里翻筋头 -- 迟早要跌跟头呢”。

看完本文但愿读者们认识到,实施漏洞修复时的组织规划和策略管理工做相当重要;还须要意识到以往的修复方案常常缺少系统性视角;最后,必须正确地认识到,在漏洞修复这个安全小闭环上,你们在各个方面仍是“愣头青”,也许是一个巨大的创业空间。

大人,时代变了

面临的场景不一样

作安全平常打交道的大量工做是找漏洞和修漏洞。笔者认为随着IT技术的发展,漏洞管理中涉及“漏洞修复”的这个动做能够粗略划分为四个阶段:

1、早期漏洞修复和补丁管理就是同一回事,以往的漏洞都是IT和操做系统层面。以“永恒之蓝”为例,就是IT和安全团队一块儿为达成安全这一目标实施打补丁。市面上已有的可靠的解决办法是完善资产管理和保障IT建设的成熟度。

二:近年来主要的问题是web类软件的安全漏洞,因此SDL和DevSecOps文化的思路强调关注尽可能在软件开发生命周期早期阶段集成漏洞扫描和修复。各类工单系统,黑白盒、高危端口扫描、工单系统,都是合适的解决方案,广义上SRC(应急响应中心)和威胁情报以后安全团队的内部流转也是属于这一类。

三:ImageMagick和fastjson这里的漏洞就是关注第三方软件在应急的时候可否快速准确的修复。近日闹得沸沸扬扬的Ripple20漏洞涉及全球数亿物联网设备受到影响。因为软件供应链复杂或未被跟踪,这类小型库不只被设备厂商直接使用,并且还被集成到其余软件套件中。这意味着许多公司甚至不知道他们正在使用漏洞代码,并且这个存在漏洞的库名甚至不会出如今它们的代码中。目前看到的有效修复办法是供应商审查和隔离方案。

四:预测将来3-5年会涉及数据安全风险的修复,如何在线上不影响业务到时候,解决一我的脸识别的数据安全漏洞?如何在知足隐私保护的前提下解决数据的加工制造过程当中的安全问题?如何对IOT万物互联的亿万台设备进行统一的漏洞升级?

技术的不一样

传统的安全政策仅仅为了企业合规和不出事,漏洞修复是公司内部的自闭环。如今必需要作出改变了。甲方正面临着外部要求、内部技术、社会环境、技术发展的多重变化。

  • 外部方面:有出海战略的企业适应GDPR要求(字节跳动禁止中国员工访问海外产品代码库,“内外有别”保平安);产品和用户逐步意识到将安全做为应该具有的默认属性(自主可控战略的本质是打破国外公司在互联网架构上的垄断,防范软硬件设施存在影响我国网络安全的后门和漏洞);国家监管要求(你懂得)。
  • 内部变化也随着而来,技术上的微服务、容器化,一个漏洞涉及千百万的服务器,动辄牵一发而动全身,比以往的打补丁更困难。业务的快速迭代需求的变化再也不须要卡点的漏洞扫描发版流程,但愿接入的基础设施默认安全,甚至自动缓解安全漏洞。
  • 社会环境的变化衍生了金融安全、区块链技术、人脸识别、隐私保护的新需求,对安全和对应的修复技术标准提出了新的挑战。

虽然漏洞修复是平常工做,可是目前缺乏新的方法论指导。SDL重视产品研发,DevSecOps重视安全的协同,都并无谈论漏洞修复这件事。实战中SDL只能解决产品发布前的漏洞发现、解决、管理,DevSecOps在现在极致专业化分工的时代,还想安全作业务的“修复”的事情,难度可太大了。

历史的成功经验不能解决问题,不能用过去来准备将来,要从将来的形态反推安全建设的要求。

应该怎么作

不像公众号里认识到的风风火火的大黑客,安全工做实际90%的基础工做就是治理漏洞。以上面的安全治理框架为例(且看笔者务虚=_=!),须要优先创建组织,搭建流程,匹配管理信息,以具体的战略为例:

战略

漏洞安全治理在战略上只能是模糊的方向,动态的安全战略。不可能一步到位,须要认知迭代,不断的试错失败。以季度\年为维度归零安全团队的目标,将公司内的有限资源不断转移到核心价值上

固然战略也取决于安全责任人进入的赛道,伴随企业业务的发展,符合CTO的市场规划。跑在好的赛道会很快从“一我的的安所有”到搭建草台班子。有人才才能执行战略,单独的有技术并不能。好的人才,瓶颈是中层。团队不能负担战略,也是很难持续成功的。不要吐槽人手不够,每一件事老是人手不够的,人手够了,还有战略和组织能力的缺失问题,须要懂权衡的团队领导带路,安全的方法论影响力也要跟上。对外安全的修复工做也讲究“矫枉过正”,“法于上,仅得为中,取法于中,故为其下”,同业务告知安全风险,反复树立安全意识,时时讲,日日讲。

好的工程化能力就是对修复方案有审美能力,知道什么问题重要,什么方向有价值,怎么作安全是优雅的。抉择漏洞修复、缓解、转移的几个安全方案没有好坏高低之分,只要组织满意就好。可是实现的路径和方法却有好坏之分,有的方法步骤效率高,一步一个台阶,很快逼近安全建设的目标;有的团队一直在原地打转,每天在救火,天生一个补锅匠,还自叹人手不足。双方的惟一差异不在大牛的配置,而在对目标和现状的理解水平有差距。例如全公司的IT编程技术的如今的状态是刚起步创业公司,所有是基于开源的一我的的安所有的方案,梦想目标状态是微软,你必须构造或描述一条从开源到自研的可行线路,而且是时间最短的,成本最低的,风险最小的,这将考验制定战略的耐心。不然不少漏洞修复的具体工做的执行者会急躁、搞僵和业务的关系,问题在于主要在对本身现状不清,不知现状是什么,同时对将来的对标对象每每只有一个模糊的概念,并无理解其内涵。

面对须要修复的漏洞太多了,制定战略的勇气在于选择不作什么。不要盲目追随新技术,不要妥协短时间的利益。其中的决策读者们只可意会不可言传。

组织

作事情的组织搭配从专业上分红四大块,战略;组织和计划;运营;监控。CISO比较偏重战略;安全总监比较偏重组织和计划;而修复数据、面向的业务催修比较偏重运营;漏洞复查时比较偏重监控。人不多是十项全能,只能有所偏重,略懂其余的内容。通常安全团队的构成也是有巨大的问题,懂安全人多,懂业务人少,固然通常公司的要求能找到人上手干活就行,安全团队的调整难度很是大,致使的后果是如今CISO最累,不只仅是要技术专家,业务专家,还得是管理专家。参考以前的文章《基层安全管理者须要具有的素质》。保证组织能力运转顺畅除了技术能力以外,更要有有持续改进的思惟,辅助不断组织的治理优化。

纵观近年安全团队的发展,还没有发现单纯由于安全入侵而垮台的公司,可是因管理混乱、向上管理不足和事多人少致使安全团队一盘散沙坊间却有活生生例子。谈具体修复哪一个漏洞,其实是会有和应急响应有混淆的时候,各位读者们所处的单位各有各的业务形态,事情须要人作,组织形态千差万别,干活的老是攻防对抗出身的安全工程师。执行漏洞修复和平常安全应急的能力要求的不一样在于前者要求如下五点:

  1. 工程系统能力

  2. 产品安全

  3. 威胁建模

  4. 安全编码

  5. 安全风险管理

对完美候选人的背景要求同时具有漏洞研究、开发能力,有产品线经历的会比较吃香。技术上千万不要为了技术创新而创新,工做是为了解决问题,只是解决问题的路上,顺带的有创新成果出现。

技术

某些涉及长期规划的漏洞修复工做必须吃透技术的红利。以往安全团队能够给出基于waf、防火墙技术的漏洞缓解方案,在数据安全,业务安全的崛起时,没有红利了。须要注意到企业零信任的场景仍然有巨大的发挥空间。笔者注意到金融行业从业人员已经认识到继续堆安全盒子已经不可行,提早布局云上安全,k8s等基础安全建设的团队,会享受到将来的技术红利。

威胁情报体现了另一个技术极端,掌握超前的技术和信息太多,不但不能提升咱们判断能力,反而面对一大堆互相矛盾的信息时,若是咱们没有足够的专业能力和辨别技术,绝对会不知所措,迷失方向,不能判断正确与否,犹如走入大雾弥漫的迷魂阵中,完全全靠朋友圈。也许一个高超的漏洞情报,彻底不用你去修复,随着时间的推移,会被认为仅仅是PR而已。

缺少思考的能力

笔者我的认为专业能力以外,有好奇心、关注创新、敢于接受新的挑战、愿意帮忙的就能够专职作SDL。但咱们技术人员广泛缺少的就是思考,更别提什么反思了,在不经思考的前提下就采起行动、当行动出现阻碍的时候又匆忙用另外一个行动去替换或掩盖,舍本逐末。常常出现的问题就是,给业务提供的修复方案不专业,说不清方案的价值。以ghostscript这个漏洞为例,须要思考为何一个脚本语言的逃逸反而要在imagemagick侧来修复缓解,理解思考清楚为何,才能给出稳定的解决路径,不断复盘,思考让节奏慢下来,不打扰业务。

策略

漏洞修复策略粗略能够划分为三种:

别人家产品对内的漏洞修复

这个流程通常很清晰了,通常是接受情报源,肯定漏洞级别,排查涉及的资产,拉人修复发工单便可。这里再也不赘述。

本身家产品对内的漏洞修复

假设我是google,我内部的GCP平台出现了安全风险能够影响所有用户,须要按照如下的流程,逐步发布,且注意,并非仅仅写个POC,照抄网上的修复方案就能解决,安全团队必需要同业务站在一块儿,懂得影响上下游范围,懂得跟进发布计划,懂得闭环此类型问题。不少时候并无合适的安全修复方案, 只能选择无奈给出临时缓解技术。

修复流程

本身家产品对外的漏洞修复

对外有客户发布的漏洞修复流程,须要处理的就更复杂了,业界对这类问题谈论的少。假设我是google,我对外发布的Chrome出现了反馈的安全风险,必须有复杂的评估流程和发版方案,下面是一个评估标准,读者们自行领会。

评估标准

诚然,读者们会有一个问题,若是有切实的安全漏洞,是否是客户必须得滞后受影响,没有知情权,答案是确定的。很无奈,虽然fastjson总出安全问题fastj,按照行业标准,在没有外部公布的可利用POC上,fastjson先内部全集团修复,再开源发版的作法是无可指责的。下面给出了一个评估的算法工具,有对外产品出售的公司,能够对号入座合理排期。





得分
客户影响数
小于10k
10k-100k
100k以上
1 2 3 2
发现难易度
困难
通常
简单
1 2 3 2
公开度
我的微博微信
微信公众号,技术网站
公开站点
1 2 3 1
对商业影响
影响客户对产品的信心
高价值客户流失
客户大量流失
1 2 3 2
后续风险
子产品有风险
同平台产品有风险
相关产品有相似风险
1 2 3 2
总得分(处置标准参考CVSS 3.0)


9

将来的发展

著名密码学家、图灵奖得到者Adi Shamir总结过三条定律:第一,绝对安全的系统不存在;第二,要想风险减半,开支就得翻倍;第三,密码每每是被绕过而不是被攻破的。而因为经历和能力限制,咱们不可能对全部信息和知识都有辨别能力,这就要求咱们限定本身的专业方向和特长,不能漫无目标贪大求全,要稳稳走路。漏洞是修不完的,攻击者的速度,变化愈来愈快。目标只能是--在合理的性价比下,完成相对安全的建设。这又回到战略上了--将公司内的有限资源不断转移到核心价值上。

是不是创业的方向

笔者我的以为一款漏洞管理和修复工具会是好的产品。《Gartner 2020九大安全与风险趋势》提出安全过程自动化的出现消除了重复的任务,漏洞管理属于SOAR的一部分,确实解决了企业大量不在面对漏洞新闻无所适从的局面,有但愿解放生产力。

从具体内容上,这是提供实际的客户价值。给业务进行一次黑客渗透测试只能引起对方好奇心,客户更但愿更多了解具体产品来验证产品是否有这样的能力。甲方愈来愈多安全专家,但愿乙方不只仅知道漏洞,并非驻场服务,而是客观解决企业产生的风险。一款能够修复安全漏洞的产品,是安全服务真正亮肌肉的时刻。

安全的细分领域早期的进入者较容易经过引领/教育市场创建领导品牌。目前的此类的产品为空。如今的大公司虽然能够包装资产管理+漏洞威胁评分,可是没有接地气的告知漏洞对于不一样的企业真正的风险是什么;漏洞修复方案都是一套模板文字,不能自动化的解决;没有联动内部的工单系统;关注安全的攻击视角,防守者的加固视角欠缺。

并且这个行业赛道足够宽,能够取代业务本身的SDL团队很大一部分工做。技术壁垒会是大量漏洞的自动化缓解修复。门槛是积累的运营数据。

一家之言,你们轻拍砖,欢迎留言探讨。



Fastjson究竟犯了哪些错?
零信任理念有望缓解fastjson软件漏洞
史上最全的zoom漏洞和修复方案介绍




本文分享自微信公众号 - WhITECat安全团队(WhITECat_007)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。

相关文章
相关标签/搜索