freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

开源软件的引入安全性;老旧漏洞为何难以修补 | FB甲方群话题讨论
2023-02-24 13:58:32
所属地 上海
各位 Buffer 晚上好,FreeBuf 甲方群话题讨论第 207期来了!FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论,Kiki 群助手每周整理精华、干货讨论内容,为您提供一手价值信息。

上期精彩内容请点击:信息泄露渠道及风险感知;数据脱敏规则探讨

话题抢先看

1. 开源软件的引入流程是怎样的,有哪些安全评估机制?

2.《上海市企业数据合规指引》中提到,企业不得使用风险不可控的开源软件开发工具包等工具。,如何理解其中的“不可控”?

3. 调查显示,2022年勒索软件利用的漏洞中,76%来自 2019 年及之前的旧漏洞。如何看待企业冒着被攻击的风险,长时间未修补这些旧漏洞?

4. 《网络产品安全漏洞管理规定》等法规下的漏洞安全管理。

话题一:大家的企业对开源软件引入流程是怎样的,有哪些安全评估机制?

A1:

感觉小企业可以无脑用,大企业自己分析源码自己开发适合自己的。

A2:

一、明确非必要不引入、谁引入谁负责;
二、制定管理办法和引入流程指引;
三、安全评估机制主要有:
1.病毒、木马扫描;
2.源代码扫描;
3.SCA工具检测报告;
4.漏洞库检索(NVD、CNVD、CNNVD);
5.准入指标(开源协议类型、MD5校验、开源社区活跃程度等等)。

A3:

1.评估开源协议;
2.评估版本更新时间;
3.评估行为,是否需要账号登录,同步数据,文件上传;
4.代码审计不评估,用的人多知名度高就用。

A4:

1.管理类:许可证合规评审,针对合法商用,法律义务及使用风险;
2.技术类:病毒扫描、漏洞扫描、静态扫描/开源组件扫描、沙箱测试等。

A5:

1.有规范,有执行人;
2.引入前评估开源软件在网络架构中可能带来的风险(从产品架构,网络架构各方面评估);
3.安全测试,把可能存在的安全问题找出来进行定制化的优化修改;
4.符合要求后,走发起部门走引入流程,通过技术架构,安全,以及CTO的审批。

对了,还有个开源许可协议。

A6:

说的有道理,理论上是需要有的,比如SCA其实就是对于三方开源组件的安全管理运营。

A7:

主要就是开源威胁治理,核心工具是SCA,做得好可以上DevSecOps,做好开源数据源监测,资产开源清单,线上应急响应。

A8:

开源软件理想化是引入前做卡点,形成SBOM,联动漏洞库信息引入没有漏洞的版本(这是事前);漏洞预警和版本联动,做漏洞响应(这是事中)。
但是大多数公司安全都是落后于业务发展进行建设的,建议还是先从SBOM先开始做,做到底账清晰,这个可以和CI流程集成,然后再按照版本进行漏洞修复(这样存量风险和增量风险都可以感知到)。

A9:

我们主要通过SCA检测,后续会搞SBOM清单建设。

A10:

开发新增了一个Pypi的第三方库,这个不和安全团队报备吧?

A11:

这个建议报备下,不过看你们是啥的公司,如果对于访问的黑白名单控制不是很严格,且对于三方组件仓库未做相对应的管控,报备了也没啥用。有管控还是报备好,不然估计你都访问不通。

Q:在去年出台的《上海市企业数据合规指引》中提到,企业不得使用风险不可控的开源软件开发工具包等工具。对于这个“不可控”,大家如何理解,如何做到可控?

A12:

不在国家某机构的目录中,即为不可控?

A13:

主要是来源不可控,维护不可控,管理不可控,威胁不可控。

A14:

还可以补充一下:软件供应链不可控、许可证协议变更不可控。

A15:

不可控:
1.是否具备熟悉掌握其技术原理和使用经验的人员;
2.是否依赖第三方厂商:如果依赖厂商,其是否有实施经验、能否在合同中承诺维护职责;
3.是否有100%的源代码;
4.使用何种开源许可证,是否影响后续的应用。

A16:

说到底:一问三不知就是不可控,可控就是底账清晰同步变化。

A17:

再加两个,可持续性,开源社区稳定,能够持续维护。可替代性,万一出现断供,有可替代产品。

A18:

如果只是做个插件,跟进主线,那是自主,但不可控。硬Fork,肯定可控,能不能自主不好说。所以这应该是鼓励大家硬Fork,自己维护自己的版本。

A19:

Fork之后还要自己维护?

A20:

我说一下这个理由,如果不是硬Fork后自己维护,那么你需要跟进主线(我相信没几个人能跟得起),如果主线搞了点啥东西你不敢跟或者跟不上,这绝对算不上可控。你想跟主线提PR也不一定都能接收的。所以只有硬Fork然后自己维护,那才叫可控,这代码真的你想咋搞就咋搞了。

A21:

Log4j大家用之前检测出漏洞了吗?

A22:

这种深层漏洞肯定很难啊,而且是未知漏洞,能把已知漏洞搞清楚掌握住都很不错。出现漏洞第一时间能知道对应到哪些资产上,有应急措施,就成功了一大半。

Q:引申一下,最近ChatGPT很火,就是不清楚怎么用到安全里面来,大家有好的思路不?

A23:

ChatGPT和其他深度学习模型一下,有一个大问题,就是不可控。你不知道他会不会给出一个错误的答案,在安全的特定场景下他的准召率是多少。多少安全的AI模型,实验室搞到99.99%的准确率,在生产环境还是不敢开。

A24:

不是都有误报的么,现在大家都要搞ChatGPT类似的产品了。

A25:

发现漏扫出来的一些修复建议存在误差,不能直接给业务派单,目前是准备人工运营一些常见的漏洞描述和修复建议的信息,大家有什么好的实践么?

A26:

边写边调整吧,发出去就跟业务说有建议或者反馈直接反应更正。然后维护知识库,常见的都放里面,直接点击看,案例、相关风险,都可以整进去。

A27:

知识库可以,能把日常运营的东西沉淀下来。你们的知识库和Wiki类似?

A28:

区分内部和全公司可看。内部包含事件处理报告、事件处理SOP、其他操作等。给业务看的包含常见漏洞说明和案例、风险,以及一些可能业务不熟悉的安全知识。

话题二:最近,Ivanti 的一项调查显示,2022年勒索软件利用的漏洞中,76%来自 2019 年及之前的旧漏洞。如何看待企业冒着被攻击的风险,长时间未修补这些旧漏洞?

A1:

相关企业可能不知道自己有哪些老旧漏洞未修补,也不知道有哪些老旧漏洞暴露在互联网。可以用一些厂商的漏洞管理系统。

A2:

安全的漏洞管理系统最好还是不要和功能测试的BUG系统进行共用。

A3:

最大的问题是修复版本的影响太大,稳定性或者工作量风险,造成不能按时修复,只能带病上线。

A4:

那些对业务连续性要求不高的某些系统或者某台主机,往往不重视,认为即使重装这些主机的损失,也不及自己银行卡或者单位账户少了一毛钱。

A5:

跑着的业务不敢动。各种依赖兼容性问题,修复没那么简单。

A6:

说到底还是拉通运维和开发的一个事情,这块最好是有一个运营系统方便一些,你总嘴上沟通,无论是效率还是扯皮都是事情,以工单的形式推动,感觉对开发和运维也公平些,至少算他们的KPI统计吧,不是人家默默无闻的配合。

A7:

大部分不去改动都是一些老旧系统,兼容性差,修复风险极高,大部分都会选择不修复,然后进行加固处理。对于一些单位来说,出现安全风险还能接受,但是出现业务风险,那就是不可接受了。

A8:

核心还是安全漏洞修复有时候不可控,举例Fastjson升级为V2避免漏洞,关闭Autotype影响业务功能,漏洞修复不能破坏兼容性,一两个系统还好,面对上百个系统做的完全修复很不容易。而且防勒索病毒不一定一定要修漏洞。

A9:

还是业务和人力成本问题,看老大话语权了,能从WAF拦就从WAF拦。

A10:

其实该说的大佬们都说的差不多了,我觉得从勒索现象本身来看,这个冒着被攻击风险不修补漏洞其实不是根本问题。可能回答超纲了,其实我觉得应该问如果看到勒索软件可以利用旧漏洞这件事更合理。我觉得,其实主要就是任性,勒索软件一般都是批量攻击的,说白了就是捏软柿子。那么他喜欢攻击什么人呢,就是安全意识薄弱,未修复漏洞或者懒得修复的人。

如何看待这种现象呢?我其实觉得很大一部分是公司性质、规模和业务本身来决定的。比如小公司没有专门的安全人员,他们都不知道系统有啥漏洞,也不知道怎么修复,更加不会关注漏洞。大公司被攻击一般都是人员意识差,某个部门被当软柿子捏了。至于修复难度大这个,一般都有临时和永久解决方案,如果有专业团队来操作至少会有临时解决方案。所以究其根本就是思想上不重视、安全意识差。

Q:说到底,在推动漏洞修复时会有哪些问题,是否有来自业务等部门的阻力?

A11:

推动漏洞修复的时候问题可多了。业务部门阻力算是里边相当大的一个问题了。推动漏洞修复的时候需要关注的点是漏洞评估,定级。修复方案和闭环。前两个还好做,修复方案和闭环是两个较难的问题,这里要评估业务、修复难度、修复周期和闭环。每个环节都可能成为卡点。一般最优解决方案,就是下发工单抄送部门负责人,以漏洞不修复会造成什么样的业务影响为由限定时间修复。另外还得平衡部门利益跟兼顾员工KPI,反正是相当艰难。

A12:

推动困难一方面是业务责任部门不了解相关安全问题的严重程度,甚至于不知道安全是什么,另一方面是认为业务稳定性压倒一切,不愿意进行变更,还有可能是修复业务存在成本,在小型业务上,存在无人承担成本,导致不修复的情况。

A13:

把安全纳入KPI就好了。

A14:

这个是个方法,但是要业务部门认,其实没有危险发生的时候,人总会觉得是安全的。纳入KPI如何去考核也是问题,业务部门经常会怼过来,这就体现出最后一个闭环问题你不限定时间他们永远不修复,你限定时间他们不停的让你不好过,任何修复点都来问你怎么搞。如果不找到利益共同点,KPI强压可能适得其反,互相不痛快,效率更低。

Q:在《网络产品安全漏洞管理规定》等法规下,大家漏洞安全管理是怎么做的,有无实践分享?

A15:

首先要培训好安全人员,开发人员,发现漏洞先内部通报,绝对不得发往任何论坛。再是分析是内部漏洞还是外部的。内部的内部消化,外部的沟通确认。

A16:

有安全设备的可以打虚拟补丁,没有的按照漏洞严重程度,严重的是能修就修,不严重的一概不修复,我是这样干的。

A17:

基于漏洞的严重性,根据系统的重要程度(业务重要性、数据敏感度等)及利用难度(隔离区、内网或公网可利用等)综合判断风险程度,根据风险程度判定修复时效,如果有安全防护则根据安全防护情况来对风险进行降级,然后按照降级后的风险等级判定时效。

A18:

中危以上级别的漏洞我们要求在上线前修复,已上线的项目限期整改或临时用虚拟补丁、WAF等手段防护,漏洞修复和绩效挂钩。

FreeBuf 观点总结

许多企业都离不开开源软件,对于开源软件的安全引入与评估,有群友认为要从版本、开源协议以及具体行为(是否需要账号登录,同步数据,文件上传)等进行评估,涉及技术类的还需要进行病毒扫描、漏洞扫描、静态扫描/开源组件扫描、沙箱测试等操作。也有群友认为核心就是开源威胁治理,主要工具是SCA,做得好可以上DevSecOps,做好开源数据源监测,资产开源清单,线上应急响应。

对于企业不得使用风险不可控的开源软件开发工具包等工具中“不可控”的理解,大家结合实际,归纳为来源、维护、管理、威胁、软件供应链、可持续性不可控等方面。

在企业为何难以修复一些老旧漏洞的讨论中,大家众说纷纭,最主要的声音源于会对一些连续性较强的业务带来影响,可能存在兼容性差、修复风险高等问题,这与公司的规模及性质、安全水平,甚至部门之间利益及职责、矛盾也息息相关。在漏洞安全管理方面,可基于漏洞的严重性,根据系统的重要程度及利用难度综合判断风险程度,确立修复策略。

本期话题讨论到此结束啦~此外,FreeBuf甲方社群每周开展不同的话题讨论,快来扫码加入我们吧!

1637910517_61a087f564a8754ee18be.png!small

【申请流程:扫码申请-后台审核(2-5个工作日)-邮件通知-加入社群】

注:目前1群、2群已满,如有疑问,也可添加Kiki群助手微信:freebuf2022,备注:甲方会员

“FreeBuf甲方群”帮会已建立,该帮会以三大甲方社群为基础,连接1100+甲方,持续不断输出、汇总各行业知识干货,打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口,让我们一同加入,共同建设帮会内容体系,丰富学习交流地。

本文作者:, 转载请注明来自FreeBuf.COM

# events
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者
文章目录