![]()
0x1本周话题
话题一：不懂软件开发，做不好网络安全（一）
这篇是国外的。国内信创、脱钩、新质、私有云、甲方壮大这些大潮下，可能表现的会更加明显。我听过很多乙方“抢了”甲方点子做成垄断产品的故事，未来应该也会有很多甲方“抢了”乙方点子把乙方产品蚕食掉的故事。信息量很大，Janky这个月翻译时，分成三个帖子转载，我自己做了思考和笔记。感谢同行亮灯指路。原文是去年1月份的：
https://ventureinsecurity.net/p/the-rise-of-security-engineering
![]()
A1：只能说，不一定能做好，不是所有搞安全的都去做软件开发，最简单的例子就是系统运维的安全人员。
A2：安全的技术低下已经是一个普遍的事实了，之前hackone的年报里也提到这个问题。之前还记了这个报告的笔记。
![]()
A3：文中这句话我挺喜欢的。借这个话，批评安全人员技能低下/不懂软件开发，就像批评公司高管不懂技术。懂开发一定是做得更好，不论是工具化还是理解业务一定更优的，十几年前余弦就说，安全不懂开发就像海盗不会游泳，只招懂研发的人，并发布了技能树，我在学校里就看着技能树学习。但相比之下这个文就有点尖锐了，人才就是这么个情况，一个人/半个人的安全岗比比皆是，企业还得生存，也得竭尽所能，大谈未来并不解渴，不解决问题，未来肯定还是大部分并不懂软件开发，甚至必须在淡化软件开发的背景下做好网络安全数据安全供应链安全，喷完之后，得给解药。A4：文中说的开发应该是指“开发流程”吧？或者“开发生命周期”？这个开发应该是指编程吧？A6：没有，从这个目录看，我认为作者自己做得很棒，而且和余弦说的工具化是如出一辙的。安全就要自己造轮子，并给出实践。指望大家样样精通是不现实的。社会分工提升效率也是人只需要掌握一部分技能即可。A7：我仅从传播角度，批评这个文预设了立场与范围，虽然用了个很吸引眼球的题目，但反而可能难以得到传播，以及作者的底层架构不太清晰(当然也可能是我学识不足)。A8：这个话题很有意思，很多年前我们有任团队负责人，要求我们比产品还懂产品，比开发还懂开发，比测试还懂测试，反正就一句话，你要去治理某个领域，你就得比那个领域的人更专业，还是那个领域的专业。当个笑话听听就好了。换个场景，今年，一个即懂算法又懂安全的应届生，大概率也不会选安全作为自己的就业方向。A9：我比那个领域的人更专业，我直接替代他们得了。既然要求啥都懂，还要更专业，一个组织还搞啥部门和岗位区分呢。在团队规模小，内部安全建设初中期的时候，懂开发和业务是很重要的，特别是搞很多自查排查的时候。我就是受益者，之前在开发条线，很多时候能推进的原因也是懂之前一些业务。但是我没法寄希望其他人也这样，无力啊。A10：归根结底，还是提出这个观点的人没找准自己定位和专长，尤其没能跟这些部门有效协同，乱了方寸，甚至是自卑的表现。A11：审计就不这样，审计会老老实实说，我是典型的外行指导内行，但还得管，需要你们的帮助支持，借用你们的力量。外行领导内行并不是一无是处，有的时候还是有很多优点的。A12：开发可能会比业务还懂业务规则，因为业务定的是需求，开发知道逻辑，但开发不可能比业务还懂业务，一样的道理。所谓了解或者懂，其实就是经验积累，多沟通交流，多踩些坑，经验就有了，底气就更足了。A13：客观得讲，那得有试错空间才行，很多时候沟通没这么多余地，多数时候不被欺负就不错了。A14：要批评的是那些，不想去了解，不去调研，连开个会都懒得露面，就一直躲在自己角落里闭门造车出要求和方案的，这些人才是真正不了解更不会懂业务和开发的。一旦涉及到业务流程和系统的影响，就怂，不敢说话，更不敢提意见，习得行无助:不可能改变，安全无能也力，就这样将就将就吧。 做安全合规的法务，做基础安全的，很普遍。所以要把安全做好，是需要些理想和情怀的。A15：是的，有个度就行，如果精于业务、开发....等等，技能树点满那肯定是最好。话题二：请问数据安全风险监测中，一般都监测哪些维度？A1：办公侧？还是业务侧？监测目的是什么？是要防泄漏？还是其他用途？A2：可以监测是否有凭据泄露、是否有人在出售内部数据。业务侧服务端比较合适，这个有第三方做这些监控和告警。A4：很多是假的，上次有家印度公司说可以深入挖这些数据，我们试用了，效果极差，没太多意义。与其保证Credentials，还不如加强认证，比如MFA，浪费人力，如果有MFA，泄露了Credentials或者撞库都风险很低，我相信监管也会变。A5：现在监管确实变了，不相信纸面安全了，打一打出真章，合规检查都是带着渗透结果来，结果导向。监管最近会对 3000 家银行的边界安全做有效性验证，大概打 500 个攻击用例，拦截率低于 50%属于高风险漏洞，防御没有起到应有的效果，也属于漏洞，进一步拓展了漏洞的定义。A6：所以监管确实变了，但是变的方向是更穿透了。监管一直在提升自己的监管能力，你看看金监局推的行业态感平台。Q：比如我不是php，对php漏洞利用没拦截。它算漏洞吗？A8：在目前的监管要求里，不算漏洞。监管要求会不断增强的。A9：凭据范围太广，没办法完全用mfa覆盖掉。资产也一直在变化，这次没有 php，下次就不一定没有。还有可能自己认为没有，但其实有（开发和运维为了减少修漏洞，做了对抗）。A10：上次安全服务商推产品，专业的漏洞屏蔽器，对请求统一做劫持，若目的地涉及漏洞设施，会清除漏洞特征，比如低版本的返回信息等。仔细想，还是有一定安全价值，毕竟隐藏信息也算，但这种对抗。A11：这种对真实攻击者存在同样的效果。开发写了漏洞说明，接受风险，责任就转到开发了。如果真的可利用，没啥可说的。我指的是，有一个利用payload，如果要检测它会带来误报影响业务，我没利用场景，关了，这种情况没拦截算不算缺陷，我认为不算，安全不能只讲检出不讲误报，标准都是一定召回率下的准确率。A12：payload打出去了，也得根据返回信息判断是否漏洞存在吧，没有场景也没这漏洞，也不会返回什么有效的信息，所以不能算缺陷。A13：我是这样认为的，就看监管看的是整体防护比例，还是要扣到某一具体漏洞了，如果能沟通还好，不好沟通的会不会让你去调优规则。A14：关键基础设施不能自欺欺人，不能运动式。合规>实质对抗，防止老旧系统不好过。该做的升级替换还是要做。
由于微信修改了推送规则，需读者经常留言或点“在看”“点赞”，否则会逐渐收不到推送！如果你还想看到我们的推送，请点赞收藏周报，将【君哥的体历】加为星标或每次看完后点击一下页面下端的“在看”“点赞”。【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
如何进群？
