各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 232期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。
话题抢先看
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：
本质上安全左移问题不是转嫁，而是把安全问题明确是谁导致的问题，转嫁的意思是是我们安全人员所导致的安全隐患，把安全隐患推卸给研发人员，而实际上大多数应用的问题并不是安全人员导致的。所以安全左移的核心是让开发人员更懂安全，要做一个懂安全的开发人员。
Q：安全左移趋势下，网络安全人员的工作侧重点会有哪些变化？
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流程、建立安全漏洞指标并对研发部门进行考核等，但最根本仍需要明确考核权等问题。
近期群内答疑解惑
Q：禁止上传互联网权限，上行流量最大限制到多少合适？我看IPG默认100Kb，感觉太大了。
A1：
A2：
取决于你司网络带宽、老板要求等实际情况，没绝对的答案。
A3：
可以试试用户反应。
A4：
不用考虑用户反应，公司定的策略。主要怕大小设置不合适，影响网站的正常访问。普通网页，大概需要4Kb的上行流量，百度网盘大概需要30Kb的上行流量。
A5：
那直接断掉就好了。要不然你要看看实际业务场景，哪些是允许的，按照业务场景来定义上行或下行的量。
A6：
都不用考虑用户反应，蒙眼定策略就行了。
Q：OA导入通讯录时数据错误，造成了通讯录混乱，2个半小时恢复了，这是否属于人员误操作导致的安全事件？
A1：
我觉得不算安全事件，先看造成问题的原因, 具体什么原因造成。
A2：
OA实施人员在导入人员档案数据“姓名”过程中，因工作失误，将原有的所本部组织架构姓名覆盖。导致OA、内部通信软件的通讯录中姓名出现了错乱。OA和内部通讯软件虽然已经上线运行，但整体大项目还在实施中，并未验收。
A3：
我觉得顶多算操作失误。这都不是锅，就是供应商操作失误的。
A：
看你的安全事件的定义如何，看上面的描述，似乎对系统的可用性造成了一定的破坏，归为误操作导致的安全事件，理论上也没啥问题，关键看你们内部如何定义。
A4：
这个是操作失误导致系统无法正常对外提供服务，应该算应用系统故障，不算安全事件吧。
A5：
这种就要具体评估事件影响范围，根据内部相关管理规范进行定基，然后进行整改（完善相关管理规范和技术手段相结合），最后根据事件级别对供应商追级。
Q：数字转型发展中，如何明确数字服务者的责任，平衡安全与效率的关系？
A1：
安全和效率都是相对的，关键看什么单位，政府事业单位的合规要求要高些偏安全，私企偏效率。
A2：
说的没错，主要看行业在合规的基础上，摸索出来适合自己的数字化转型之路。
A3：
确实就是主要领导对安全重视程度，数字化都搞不明白，搞啥安全。
A4：
数字化转型属于中长期发展规划，还是要看菜下饭。
Q：内网有大量老系统存在未授权访问页面，像Docker、Api 这种，这个是找业务部门强制整改么？
A1：
一般要求他们关掉页面。
A2：
弃用的关掉、在用的确定使用者IP段，做访问控制。
A3：
看什么业务，如果是测试系统，有漏洞很正常；如果是供应商的，就让他们强制修复；如果是研发环境，告知研发，然后让他们设置人员访问和ACL。
A4：
加身份验证，基本很难推动。看大家意思，这种老系统，ACL目前是最优解。
甲方群最新动态
上期话题回顾：
活动预告：
议题征集&报名开启 | FreeBuf企业安全俱乐部·广州站起航
活动回顾：
近期热点资讯
CrowdStrike业绩、股价狂飙，“AI+网络安全”成为资本的新宠？
FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！
【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】
注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf1024，备注：甲方会员
“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1300+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。
本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！
程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）
