话题1：李斌致歉蔚来数据泄露：称不会妥协，不影响驾乘或远程控制。
https://m.thepaper.cn/newsDetail_forward_21251192
A1:加强数据安全建设与检查。安全是最后的底线，安全内保无法衡量产出。
A2:你这个还是老问题：安全的投入产出怎么算。应该是衡量下泄露后悔产生多大影响和损失，愿意花多少钱去降低这个风险。
A3:如果一定要算，那么可以算10%的营收是最大损失，法规定义的最大罚金值，但这个算法不含商誉损失。例如蔚来这次，最大的损失是商誉损失。
A4:数据安全向大佬们自荐下我这个-数据安全风险枚举 https://dsre.jd.army/。
A5:监管罚金，资产价值，商誉损失。说服老板预算增加200万美元？
A6:最大的，数据那些怎么估值都无法比不过商誉的损失，而且是股价直接跌给你看。
A7:直接经济损失就是被处罚， 间接损失就多了，包括用户的质疑，竞对的挖角。
A9:车主数据都不是秘密吧 每年车险到期都接到某某家电话。
A10:最核心是国人对隐私数据的重视和一些体制。感觉咱们老百姓要操的心太多，这个事没那么上心。
A11:我之前期望的是跟老板说有这事的时候，能够把后续的代价也说的更清晰一些，让老板听了之后，对这类风险的认知更直观一点。 但是似乎目前这个代价谁都说不清。
A13:要是真的执行GDPR的罚款啥的，监管来问责，消费者信心损失影响销量（怎么证明相关性）。
A14:一般一个应用上线之前，会评估出系统失败造成相应级别的数据流失，中断多少服务，影响多少交易，一些列因素，从而算出损失，包含商誉，但是不一定很具体，只会给个大海评估。出了事就应急了。我见过顺带给当地生态或者工业 教育界一笔很大投资，从而促成签个大单。系统整改招人都是小钱。不过确实因为黑客入侵造成的损失会比某乙方产品缺陷造成的损失影响更大。
A15:很多事情都有方法，但是置信程度不同。不直接的都不太置信。
A16:个人觉得新能源汽车制造企业的核心竞争力不是用户信息数据，只要不被控车影响人身安全都是可以接受的风险。泄露数据出来实际损失的是用户的利益，如果有监管处罚这是最大损失，商誉或是竞对购买估计对业务真没有太实质的影响。
A17:同样问题，系统没被攻击不能说明安全做的好，所以系统数据价值不是安全产出价值。
A18:做企业的不需要在乎伪不伪，做好定义就行。泄漏了不一定说明安全做的不好，不泄漏也不一定说明做的好。但是你写个定义做个目标，达成了，就值得说。太多企业数据被泄漏，不代表不能追求0泄漏，这是budget的来源，是champion security的直接理解，甚至是企业的根基。
A19:短期内你是可以这么说，也可以这么定目标或者向上汇报，长期你就会被这个连累甚至是陷入进退两难的困境。
A20:我们坚持了14年了。还处在短期试错，再坚持个几十年也许进入中期会调整，但是没必要过早放弃。
A21:倒不是说这种目标不好，只是这种目标虽然高层好理解但是不可控因素比较多，容易造成付出很多却没有回报的窘境，且一旦出现某个环节的问题也可能影响你未来的budget或者在高层的置信度。
A22:把数据风险地图做好，相关风险责任方捋清楚。数据安全不如应用安全那么好搞，就放在那里。数据流经谁，谁就是风险。
A2:被白帽子挖了洞数据都泄漏了，只是安全负责人不会正面说，另外就是有些数据泄露了确实风险也是可控的。这里有个注意点，出了信息泄露事件后，需要及时和网信办等机构保持沟通，各种PR稿最好能和监管部门保持一致。
A5:应该先所在地通管局吧 还有网安。在公司内 肯定是有gr参与的。
A7:事情还在“发酵”中。洗地感有点明显啊。“而这距离蔚来年度发布会NIO Day，仅剩下4天时间。”这句话还给加黑了，看来在作者心里发布会比用户信息安全重要的多。
A8:“但这必然意味着，我们需要将自己的社会信息、行为数据乃至生物数据交给汽车企业。而这些数据，也就同样面对着被泄露的风险。也就是说，用户需要控制自己的预期，车企也要守住自己的边界。建立这个意识，对于我们中国人民来说尤其重要。”
A9:昨天还看到个截图：揭露蔚来虚伪，对其进行惩罚，保护用户 近日，我们破解了蔚来大量数据，同时，给了蔚来两次机会，但是蔚来宁愿花费千万请歌手，也不愿意买断这部分数据来保护各位车主和用户，因此我们决定有偿曝光。这种的pr稿，只能是将大众推向对面。当然，也有可能是竞对搞的，低级红高级黑。
A10:那你得先梳理数据防泄漏要做哪些，怎么定义好不好，这跟自己安全做得水平怎样是一样的 按照昨天某大佬所说，我估计他全球化后，远程运维，权限，互联网信息暴露这方面做得很散，内部则没什么监测，外面通过一个合法身份进入，内部再进一步找凭据，你上啥安全设备都没用。
A11:换个角度，用户怎么评价呢，用户评价的依据可能就是一个出没出事。出事了再说我们做的比别人好，别人那是运气好才没事，用户会认可么。用户会用脚投票。
A12:不要忽视监管，企业可以不重视，但是监管来搞就重视了。本来监管就九龙治水，一直在想着找个龙头企业立标杆打一打。你撞到枪口，态度不好整改不到位，那后面麻烦事多了，从这个角度，对企业也是成本。
A13:是的，所以gdpr的按照收入的4%处罚很合理啊，小公司资源少、业务盘子没有那么大，罚款也对应少，大公司盘子大，处罚的多。
A14:从业者一方面不能让这种事情轻易过去，一方面也应该在防范和建设领域发挥专业特长，这样行业才能有更好发展和持续的投入。安全得为自己发声。
A15:企业没法为客户信息安全完全兜底，但是应该通过一些渠道让客户了解企业为了客户信息安全付出了巨大努力。这样及时发送了信息安全事件，客户也能理解企业的处境。同时，如果在事件发生后有效正确应对，会更加凸显以客户为中心的价值观，而不是先急着“推锅”。
A17:这番炒作后各路监管应该会进入了，按照现在的网安法和数安法真不好说有没有后续的监管政策和处罚
A18:这几天了吧，各路监管应该已经都到了。估计蔚来正在拼命溯源写报告中。
A19:监管已经有的有反馈了。据我了解。有的都已经写报告上去了。
A20:嗯，那看起来以后这个套路是固定动作了的。我觉得有法可依之后，就不会看态度来处罚了。态度好不等于造成的损害不存在了。当然本身这个事件就是一个典型案例，监管处罚是对三法执法力度的一个风向标。
A21:态度是个不太严谨的词吧，这里的含义是指你有没有尽职，有没有建立对应的管理组织体系，有无技术投入，这次泄露本身的事件过程之类。
A22:尽职是合规的第一步，尽职了被搞透也正常，要看攻击面有多大，建设成熟度有多高，投入资源能否覆盖，不过这些现场检查估计也检查不出来。
A23:这篇比原始的SLSA博客的内容多很多，是很好的综述文章。亮点1是讽刺了4个常任理事国的魔之操作，亮点2是包含了很多引用和合作项目的链接，现在发力点应该是数据模型的统一上。
-
李总博文【从BAB到SLSA——谈Google的软件供应链风险治理】
-
陈总6.24的分享【陈曦：信息系统供应链安全管理入门】
-
刚刚想到，蔚来如果买了安全设备，只是安全设备没告警或者只是普通告警，被忽略了，是不是该安全厂商的锅了
A1:关键是自己运营，还是厂商派人运营。看协议怎么签的。
A2:如果买了设备没有买对方驻场服务的话，比较难甩吧。安全责任不能外包。
A3:就算自己运营，但是设备也没有发出失陷告警呀。除了扣钱，终止合作，合理赔偿，主体责任不能外包。
A4:关键设备都没有告警，人咋知道。肯定不会背锅呀 微软一堆的安全bug 也没有承担过什么责任呀。现在是个边界防护设备，每天的告警都是上万条，哪跟踪过来。等于承认安全运营存在单点薄弱环节，这不是甩锅是招黑。
A5:该买的设备我也买了，也部署在合适的位置了，但就是没告警，这人也不能未卜先知呀。
A6:有没有人每天检查日志，日志的交叉匹配分析有没有做？安全一旦出了事故，监管部门一定有办法追究你责任。安全有效性验证能解决绝大多数这类“幸存者偏差”的问题，发现：应拦截未拦截、应告警未告警的这部分问题。没告警，其实我们区分不出来是没攻击没告警，还是有攻击没告警。
A7:比如护网的时候，有多少单位买了那么多安全设备，但还是失陷了，丢分了，安全设备的虚警、漏警应该是比比皆是的问题吧。
A8:所以其实就是，从基础设备购置，过渡到安全运营的一个灵魂之问，实际情况到底咋样。
A10:曾经在边界部署过三类nta，同一份流量，有些攻击就是同步的未告警。
A11:设备是自己招标测试充分后再采买的，也不是别人硬塞的，所以就算设备某些功能无效当然也是自己的首锅。都是国内顶级nta，还有覆盖度和资产不清的问题。
A12:事后证明，攻击就在那些流量里。能不能收集到，ssl的有没有卸载，那就是另一回事儿了。
A13:安全效果，不等同于就是安全设备，即使买的最好的安全设备，由于安全策略和日常运营维护保养不当，也是发挥不出安全设备的实际效果的，往往这种设备买了最好的，但由于安全配置和维护保养不当导致没告警没拦截，才是对甲方安全团队比较致命和尴尬的威胁。
A14:我还做过三家nta，分别抽取一些攻击事件告警，在另外两家比对，发现10-20%告警在别的设备是查不到的。
A16:cyber eng和cyber def在我们这里是两个团队，eng里面是engineer，负责build up和tunning，def里面是analyst，负责soc/investigation/intelligence。
因为有误报，有情报，有特批，所以要及时反馈到tools上，由cyber eng进行进一步调优。两个团队的各自的安全运营形成cyber security ops整体运营的螺旋前进。
A17:我拿pcap包测试各家的，几家还是大差不差。
A18:我指的是纵深防御的情况下，你在很多环节都可以有告警，每一个设备在整个生命周期中有多次机会进行enrich。
话题二：请教一个小问题，SAST白盒扫描如果要做业务上线卡点，大家是在构建环节卡点还是部署阶段卡点呢？遵循左移的思路最好能在构建环节拦截带病上线，用Jenkins构建的场景下怎么实现旁路挂载白盒呢，通过Jenkins组件调用白盒扫描估计只能留出几秒到十几秒的时间给白盒扫描，白盒扫描任务无法扫完，卡点也就做不到了。如果在研发上传git commit就触发扫描，再在构建环节实现卡点，能留出扫描时间会多一些，但是会扫描很多不经过构建的commit，需要大量的扫描资源支撑。
A4:构建到部署预留的时间充裕点，你们一个任务一般多久可以扫完。
A5:完整的扫描一般需要几分钟到十几分钟不等，卡点可以扫描策略开少些，如果代码量不大一般几分钟内就够了，但是也达不到十几秒的程度，光下载代码就要好几秒了。
A6:确实是 只能根据Top10或者更少的扫描规则来做些裁剪。
A7:主要是代码要扫描一遍，就会变成构建流程里面耗时最长的。
A9:构建本身会花一些时间，但是Jenkins插件貌似无法直接改变已经开始构建过程的状态，不然可以尝试利用Jenkins本身构建所花费的这段时间。
A11:有误报的规则不开启，卡点咋敢开有误报的。只开比如组件版本扫描和sql注入强制编码规范这类的规则。
A13:你们开的是异步的模式吗，发起扫描任务后，Jenkins流程继续跑？
A14:我感觉SAST高误报率是通病，不知道各位一般是怎么解决的。
A17:如果是构建的时候触发部署的时候卡点的话，能卡到大部分，只要安全扫描时间快于构建部署的时间，不可能做到100%卡点。
同步的也存在很多git代码量大导致超时的情况，而且拉长了构建时间。
A19:改一点就commit一次，有个异步队列收请求但是还是很多重复的。
A20:但是给了时间太短了，是说git commit阶段触发扫描么。
A21:merge的时候卡可能可行。很多业务构建不是用的master分支，没有merge，这时候需要关注所有分支，成本瞬间攀升。
A22:但一般都是feature 往release合，最后才是master吧，白盒卡点我一直没明白怎么处理这么多并发。
A23:终极方案就是加机器，每个机器同时少跑几个任务就能扛住，但是需要的机器资源就很多很多。
A24:扫半天开的策略还特别小，感觉收益效果也不好，有时觉得就是为了合规动作。
A25:卡点对业务而言一般可以作为安全能力和安全权威的形象。作用实际上不小，这时候要业务干活最配合。也是业务团队的安全感的重要来源。
A26:卡点还有一个问题，就是整改效率一下子提的很高，开发团队不一定能扛住。
A28:用卡点的话，尽量左移之后，就变成每次提交代码都会被拦下来，没法提交。我们还是先推的整改。
A29:所以卡在构建上线的环节业务比较能接受一些。卡点政策可以类比疫情封控政策，有的业务支持有的不支持。但是出现0day应急的时候，卡点处理的效率是最高的。
话题三：请教各位老师一个问题的解决思路， 针对内部https流量问题。对于流量检测设备来说告警无法还影响设备的处理性能，有无办法解决这个问题呢？
A2:内部https流量处理本身损耗就大，交换设备上取流量，再分析，获得威胁信息，对于安全设备来说太勉强了。建议通过其他方式汇集安全事件，或者基础设施上做好流量处置。内部开https的理念，挺符合潮流的，但也阻断了流量侧安全检测的思路，所以，可不可以尝试终端型检测？
A3:其他方式汇聚安全事件，除了终端检测，有无其他思路？
A4:统一做https卸载的话监管的要求：端到端加密就做不到了呀。
A5:sdn给你做导流和解密，不要压到安全设备上，安全设备自己做解密，证书管理都是问题。
A7:一般行业内部https感觉没必要了，通过物理安全控制足够了。
A8:流量分成两类，外部发起的尽量边界转掉，没办法的比如有流量编排类产品可以导出，内部发起的感觉还是不要有加密流量好
A9:求一份文档 有每季度的网络安全工作报告模板么？给党委做汇报的。
A10:实践情况，监管和等保测评都会看内部有没有敏感内容加密，但是不强调是https，只是大家为了方便直接做了https。我们是几个方式：
-
-
局部有条件的，上https，到数据中心后统一在一个地方解密，再转明文给应用服务器。
-
无上述条件的，就明文吧 上面大佬用xdr的我们没尝试过。
-
A11:https还是有必要的，不光是加密，还有完整性、服务端身份认证，这些密码功能都要依赖于https。
A12:完整性和验证都有其他http的方案，所以这倒还好。你的站点身份验证就少不了，pki体系已经是标准了。
A13:我们这边也是，内部也有部分HTTPS流量也不好卸载后给到NTA，针对内部的https流量目前只是简单借助NTA基于解析出的2-4层的五元组等信息再结合业务访问特性做些违规访问、异常请求的监测，检测上与原包分析上确实有点鸡肋，如果内部确有攻击，目前还是得再结合HIDS与ELK中的应用日志联合分析定位了；
端到端这个只是监管有个文件中作为一项有提及，但是实际现场检查还是偏重于重要业务出口往外的https,中间如果做了SSL卸载不太关注，之多也就是提供些补偿措施做好访问控制、授权等。
A14:其实说到密码的问题，里面的技术细节是非常复杂的，比如说敏感字段加密，其实应该就是前端js加密那一套，那么你必然涉及到密钥的传输，对称加密就把密钥写在js里，非对称就从后端拿，但无论哪种，这些最开始的敏感信息，你都要靠https保证互联网链路中传输的保密性。
nta怎么旁路，旁路在哪些区域是个相当麻烦的问题，好多厂商推产品时候就说旁在核心交换，有些单位的三层架构不标准的话很多流量压根就不进核心。
A15:这个就说细掉了，单说取密钥这个环节，密钥是可以统一管理，直接请求https。由于请求内容比较固定和简单，只用服务端监测就行。其他应用系统接口还是http，除了密钥这样的关键且固定的接口用https。我的观念是，在内网接触范围比较可控的情况下，在现在应急、阻断和监管的压力情况下，选择监控和分析比选择https收益更大。
A16:嗯，只是说两种技术发挥的作用维度不同，有了https依然可以上字段加密提高攻击成本，我还遇到过让供应商整改sql注入或者越权漏洞的，他们整改方案居然是用前端加密那套把http body给加密了，害的我还要把js研究一翻重新封装数据去证明他的漏洞没改。
A17:是的内部的比较乱，我们目前就是取汇聚再加上核心上联到出口，二层的接入来不了，老的架构互相打洞分区混乱，后续想着新机房统一规划通过TAP灵活调整镜像，但也做不全。
从BAB到SLSA——谈Google的软件供应链风险治理https://zhuanlan.zhihu.com/p/382721804?utm_source=wechat_session&utm_medium=social&utm_oi=647822373387112448&wechatShare=2&s_r=0&utm_id=0
-------------------------------------------------------------------------------
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
如何进群？
原文始发于微信公众号（君哥的体历）：关于蔚来数据泄露的思考，以及SAST白盒扫描做业务上线卡点的探讨，针对内部https流量问题的解决方法等...| 总第178周
评论