1. 有种观点认为安全左移往往是把安全的责任转嫁给开发人员,对此大家怎么看待?
2. 安全左移趋势下,网络安全人员的工作侧重点会有哪些变化?
3. 对于应用系统重复出现的漏洞,你们会有什么处罚措施或者机制,能加强一下开发人员的重视度,避免相似漏洞的重复出现?
A1:
责任共担,不是转嫁,本身很多东西就不是安全能自己解决的,不一起担责推不动。
A2:
并不是转嫁给开发人员,业务出现安全问题,无论是上线检查是发现,还是事后发现,都是要修的。上线时发现再修复大概率影响上线进度;事后发现修复也可能安排业务停机,还不如开发时发现就修复,影响时最小的,还能养成好的开发习惯。
A3:
需要共同承担,从安全设计、安全编码阶段就实现可信。
A4:
开发问:有专门负责安全的,为什么还要担当你的责任?或者开发不能说你们就不能设计一套有安全韧性的防护手段吗?漏洞是肯定都有的,应该让安全容忍漏洞、控制漏洞。
A5:
开发人员反感的并不是安全人员找茬,而是报告了太多可能的漏洞,没有石锤。开发因为这些安全可能的漏洞,这些不影响功能的修复工作,在产品侧没有得到足够的价值认可。
A6:
安全又不是风险的生产者,左移也是提前预防风险的一种,同时也减少了后续修复的工作量的,开发人员没必要这么抵触的吧。
A7:
开发本来随心所欲的写,给他这个要求那个要求,自然就有意见了。
A8:
这么说吧,除了实现可用性,功能性,安全需求也是开发需求。
A9:
为什么不是安全右移,都扔给运维的人去搞呢?
A10:
统上线啥都不好搞了,能缓解部分,很多只剩下躺平。
A11:
据说有公司会考核开发人员的BUG数量,这种情况下开发人员才有动力左移吧。
A12:
把安全需求放到研发输入那边去,安全测试是测试。
A13:
如果在开发设计之初,有安全参与,并有安全政策的前提下, 被开发的系统再出问题,甩锅给开发人员没毛病。
A14:
如果是在需求分析设计阶段,安全人员未能发现潜在的安全隐患,上线生产后被发现了呢?
A15:
说明前期在风险评估时候缺少人员、服务、设备的投入。
A16:
理论上都可以这么说,但是实际落实到位的时候,很难落实到。所以后面分锅的时候,各种扯皮。
A17:
扯皮的时候约定排期呗,还有就是一直说的,手上不能只有安全,要有直接卡他们的手段,有求着你的时候。
A18:
我们开发也愿意左移,只要领导增加资源、拉长排期。但领导还是倾向于要优先保证业务功能需求能落地。
A19:
这个就看双方扯皮,最后妥协各退一步,紧急业务先上线,约定后补,也是一种策略。
A20:
安全左移不是上IAST这些吗?集成到IDE,开发的时候弹出告警进行修复。
A21:
左移更多是管理手段,技术辅助。
A22:
安全左移从需求设计部分就开始了,安全检测产品只是一部分。
A23:
本质上安全左移问题不是转嫁,而是把安全问题明确是谁导致的问题,转嫁的意思是是我们安全人员所导致的安全隐患,把安全隐患推卸给研发人员,而实际上大多数应用的问题并不是安全人员导致的。所以安全左移的核心是让开发人员更懂安全,要做一个懂安全的开发人员。
A24:
参与指标设计和验证。
A25:
懂安全开发,懂程序架构,懂需求设计,才能和开发人员友好交流。
A26:
我们在聚焦思路上的创新,业务特性与攻击手法结合的红军体系化防御模式。排头企业很久前开始做中台。说大了,叫因地制宜。说小了,叫跳出单点从业务与业务直接风险来看待。不仅仅要求员工对于漏洞和挖掘思路的理解,还要求理解业务,能够活学活用。
A27:
这个就好比锻炼(内修)让身体强壮,抵御疾病等入侵、破坏,合理搭配饮食(外护)等让身体更加健康,药物(应急处置)是扛不住了介入治疗,重新让身体恢复健康。
这个链条中,内修是研发干的活,代码要写的安全、健壮些,外护、应急处置是安全主要干的活。
A28:
现在企业首先要活下去,其次才安全,这样经济大环境下,安全左移,直接做Helpdesk或者运维,要么做审计。
A29:
在企业招聘中有专门的开发安全招聘岗位,一般都是l2级的安全人员,他们在l1级(会渗透、漏洞扫描、部署安全产品等)的基础上会做源代码审计等的工作,然后被编入研发团队,进行迭代,而传统的安全人员进行右移,以及做一些公司级安全事务,分的越来越明确。
A1:
能自动化发现吗,开发上线前扫描;邮件大领导,考核规范;安全培训。
A2:
如果可以的话部署自动漏扫工具,定期扫描,发送。
A3:
1.每个漏洞进行考核,对漏洞进行分类,多次出现的同类漏洞可以额外扣分;
2.SDL严格落实漏洞门禁,不修复不能上线;
3.建立各种安全漏洞指标,比如按照每千行代码漏洞数量,对各部门研发质量进行排名和通报。
A4:
DevSecOps搞起来啊,Test环境就给他搞出来,不修复不让上线Prod环境不就好了。
A5:
这谁能保证生产环境永无漏洞,测试环境发现率100%。
A6:
1.用生产漏洞对研发部门kpi进行考核;
2.建立漏洞逃逸率指标,生产漏洞数/(生产+测试漏洞数)
A7:
这个问题在制度上,没有考核权,没人会重视。安全漏洞第一责任人是研发,不是安全部。
A8:
现在无论测试还是生产发下去漏洞修复修复也快,但是点就在于头痛医头,脚痛医脚。
A9:
要分析漏洞数据,对漏洞多的应用做专项治理,有些全局性的问题,改不完,要安全和研发一起制定提升方案。
本期在讨论安全左移将责任转移的话题中,有群友认为认为这是责任共担而非转嫁,因为安全问题无法独立解决,需要团队共同承担,安全左移实际上是提前预防风险的一种方式,有助于减少后续修复工作量。总体而言,安全左移需要在需求设计阶段开始,让开发人员更了解安全,从而共同确保系统安全。在安全左移趋势下,网络安全人员的工作重心可能会转向参与指标设计和验证、培训开发人员懂安全开发等方面,以适应不断变化的安全需求。
而在讨论避免应用系统出现重复漏洞的问题上,提出了多种处罚措施和机制来加强开发人员对漏洞的重视度,包括自动化发现漏洞、定期扫描和发送报告、对漏洞进行考核并分类、实施严格的SDL流程、建立安全漏洞指标并对研发部门进行考核等,但最根本仍需要明确考核权等问题。
A1:
A2:
取决于你司网络带宽、老板要求等实际情况,没绝对的答案。
A3:
可以试试用户反应。
A4:
不用考虑用户反应,公司定的策略。主要怕大小设置不合适,影响网站的正常访问。普通网页,大概需要4Kb的上行流量,百度网盘大概需要30Kb的上行流量。
A5:
那直接断掉就好了。要不然你要看看实际业务场景,哪些是允许的,按照业务场景来定义上行或下行的量。
A6:
都不用考虑用户反应,蒙眼定策略就行了。
A1:
我觉得不算安全事件,先看造成问题的原因, 具体什么原因造成。
A2:
OA实施人员在导入人员档案数据“姓名”过程中,因工作失误,将原有的所本部组织架构姓名覆盖。导致OA、内部通信软件的通讯录中姓名出现了错乱。OA和内部通讯软件虽然已经上线运行,但整体大项目还在实施中,并未验收。
A3:
我觉得顶多算操作失误。这都不是锅,就是供应商操作失误的。
A:
看你的安全事件的定义如何,看上面的描述,似乎对系统的可用性造成了一定的破坏,归为误操作导致的安全事件,理论上也没啥问题,关键看你们内部如何定义。
A4:
这个是操作失误导致系统无法正常对外提供服务,应该算应用系统故障,不算安全事件吧。
A5:
这种就要具体评估事件影响范围,根据内部相关管理规范进行定基,然后进行整改(完善相关管理规范和技术手段相结合),最后根据事件级别对供应商追级。
A1:
安全和效率都是相对的,关键看什么单位,政府事业单位的合规要求要高些偏安全,私企偏效率。
A2:
说的没错,主要看行业在合规的基础上,摸索出来适合自己的数字化转型之路。
A3:
确实就是主要领导对安全重视程度,数字化都搞不明白,搞啥安全。
A4:
数字化转型属于中长期发展规划,还是要看菜下饭。
A1:
一般要求他们关掉页面。
A2:
弃用的关掉、在用的确定使用者IP段,做访问控制。
A3:
看什么业务,如果是测试系统,有漏洞很正常;如果是供应商的,就让他们强制修复;如果是研发环境,告知研发,然后让他们设置人员访问和ACL。
A4:
加身份验证,基本很难推动。看大家意思,这种老系统,ACL目前是最优解。
上期话题回顾:
活动预告:
议题征集&报名开启 | FreeBuf企业安全俱乐部·广州站起航
活动回顾:
CrowdStrike业绩、股价狂飙,“AI+网络安全”成为资本的新宠?
FreeBuf甲方社群每周开展不同的话题讨论,快来扫码加入我们吧!
【申请流程:扫码申请-后台审核(2-5个工作日)-邮件通知-加入社群】
注:目前1群、2群已满,如有疑问,也可添加Kiki群助手微信:freebuf1024,备注:甲方会员
“FreeBuf甲方群”帮会已建立,该帮会以三大甲方社群为基础,连接1300+甲方,持续不断输出、汇总各行业知识干货,打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口,让我们一同加入,共同建设帮会内容体系,丰富学习交流地。