《 “2020滴滴网络安全峰会-PPT学习” 》 有 7 条评论

1. 2021西湖论剑·网络安全大会 安全：数字化改革之根基 / 数字时代下的电信网络诈骗及防范
   https://vipread.com/library/topic/3489
   `
   一切网络诈骗发生的条件，都是信息对称逆转

   快递信息泄露 – 四通一达等各类快递数据
   社交论坛 – 朋友圈、微博等发送当天的状态、未来的计划等
   公共Wi-Fi – 星巴克、餐厅的免费Wi-Fi等
   通讯录泄露 – 非法、违规APK获取手机通讯录等
   账单票据 – 丢弃的车票、机票等
   问卷抽奖 – 街头抽奖问卷，朋友圈测试问卷
   黑客入侵窃取泄露 – 历年数据泄露事件，例如开房数据、肯德基数据、外卖数据等
   电商卖家信息泄露 – 京东、淘宝店，房产、汽车销售，医院、妇产科等等

   隐私窃取+数据泄露

   ==

   在电信网络诈骗面前

   我们每个人都不能置身事外

   遇到骗局如何才能不上当

   最简单有效的办法就是

   不予理会并及时报警

   希望大家一定要提高警惕

   从随手标记诈骗

   到守护家人安全

   多一个人

   就少一个人受骗
   `

   回复

2. 在线图片转文字
   http://www.imagetotxt.com/

   在线文字识别转换
   https://ocr.wdku.net/

   回复

3. MicroMDM – a devops friendly MDM server
   https://github.com/micromdm/micromdm

   在 Mac 电脑上使用配置描述文件以标准化设置
   https://support.apple.com/zh-cn/guide/mac-help/mh35561/mac

   解锁macOS安全与隐私允许【任何来源】
   https://blog.csdn.net/lxyoucan/article/details/111994328

   回复

4. Controlling “Screen Capture” using MDM
   https://developer.apple.com/forums/thread/122414
   `
   “Screen Capture” can only be denied using an Configuration Profile over MDM, never allowed.
   `

   PrivacyPreferencesPolicyControl.Services
   https://developer.apple.com/documentation/devicemanagement/privacypreferencespolicycontrol/services
   `
   ScreenCapture
   [PrivacyPreferencesPolicyControl.Services.Identity]
   Allows the application to capture (read) the contents of the system display. Access to the contents cannot be given in a profile; it can only be denied.

   # ScreenCapture – 屏幕录制
   此隐私权限仅能通过MDM对特定app拒绝，而不能通过MDM给app主动赋予此能力。
   `

   The payload for configuring restrictions on a device.
   https://developer.apple.com/documentation/devicemanagement/restrictions

   回复

5. 杜中伟：贝壳黑灰产识别与溯源
   https://mp.weixin.qq.com/s/-jvt7elrDrsBqT7GCUis3g
   `
   看了一下文章，大概了解了居住服务行业的服务模式以及黑灰产现状。除了常规的互联网黑灰产（流量攻击-勒索/信息爬虫-敏感信息爬取，影响成交量和市场占比/虚拟账号注册-薅平台羊毛）之外，还有行业特有的情况：经纪人为达成KPI来买拉新/带看虚假数据，薅平台羊毛，私单飞单，竞对窃取。

   常规互联网黑产那肯定是用互联网的那些成熟方法来解决，行业特有的一般可以求助于【业务方】来获取行业潜规则/不为人知的操作手法，因为安全人员不可能比业务方更了解业务的实际情况，这个时候提供举报途径和奖励会很有帮助。再一个就是在打击之初其实就明确了3个罪名方向，简单直接但有效。

   ==
   导读：贝壳黑灰产实验室，主要偏向研究和溯源。业务与策略对抗，由其他部门进行。因此这里主要介绍贝壳在居住服务行业，黑灰产情报和溯源相关的内容。主要内容包括：① 介绍居住服务行业黑灰产的场景；② 黑灰产情报建设；③ 溯源体系和溯源能力建设；④ 打击取证。

   # 黑灰产现状
   1. 行业服务模式
   2. 行业灰黑产

   居住服务行业的黑灰产，包括传统的互联网黑灰产，也包括一些行业特有的类型。
   ## 传统灰黑产，可以分为以下几类：
   * 流量层：流量攻击、爬虫导致的流量风险、重大活动时的勒索（游戏行业比较常见）；
   * 设备层：对抗非常激烈，包括虚拟设备、群控、云控设备等；
   * 账号层：垃圾注册、养号扫号、人机对抗等；
   * 业务层：通用的薅羊毛、拉新等；
   * 数据层：针对信息的对抗，例如竞对盗取平台上的客户信息和商机等，例如竞对爬取了新上房源信息。

   ## 行业特有的黑灰产，主要围绕人（经纪人）、房（房源）、客（客源）三点来展开：
   * 虚假房源、客源；
   * 私单飞单：成交转移到线下，私自成交；
   * 窃取平台上的房源或者客源；
   * 经纪人绩效造假：经纪人为了达成KPI指标，进行经营绩效作弊；
   * 体外经营：品牌加盟到平台后，实际经营都在其他平台进行，仅仅通过平台来获取资源信息。

   3. 典型场景1：C端虚假注册
   4. 典型场景2：爬虫软件

   # 情报体系建设
   1. 情报使用流程

   情报采集的架构分为三层：
   第一层是情报采集，一类来自城市举报，包括泄露case、违规工单、专门采集的线索。另一类来自外部监控，比如羊毛论坛、贴吧等，了解外部黑灰产在技术、工具、数据上的情况。还有一类是内部监控，SRC的白帽子情报，反爬部门的情报信息，终端采集的数据等。中间涉及的业务类型，都通过情报采集层进行了覆盖。
   第二层是溯源处理，我们更多专注在经纪人的账号、设备、业务操作层面的数据。对这些信息进行加工，进行情报溯源。最终我们的输出是，情报高危黑名单，以及手机号、设备的黑库，和作弊工具库。
   第三层是使用运营，主要联动的业务方是执法部门，例如联动职业道德进行打击，或者进行专项的治理、规则优化。另一类是联动风控和产品部门，对典型的风控产品和策略，进行迭代和优化。

   # 溯源能力建设建设
   1. 武器库
   2. 溯源技术架构

   # 打击和取证
   我们把整个打击分为溯源、分析、报案、取证、打击五个阶段。

   * 溯源阶段：需要通过日志、行为、样本，明确作弊手法、作弊工具。

   * 分析阶段：明确罪名，目前主要3个罪名，一个是侵犯公民个人信息，第二个是非法获取计算机系统，第三个是破坏计算机系统。可以看一下具体的司法解释，贴合条款写方案材料。

   * 报案阶段：需要一些有法务工作经验的同事，写作方案书。与警方进行初步的沟通，尽量用通俗的语言解释作弊情况。并提交相应材料。

   * 取证阶段：警方会指定第三方鉴定所，进行取证。基本的取证流程有固定的时间和地点，进行录屏。

   * 抓捕阶段：关键的是需要技术人员配合，现场抓捕，需要当场抓获一些工具和数据。需要的话，在抓捕后的审讯阶段，也要配合警方诉讼。
   `

   回复

6. 攻防技术创新探究
   https://sm0nk.com/2023/01/10/%E6%94%BB%E9%98%B2%E6%8A%80%E6%9C%AF%E5%88%9B%E6%96%B0%E6%8E%A2%E7%A9%B6/
   `
   # 红队实战创新

   ## 实战几个问题，算不算创新？
   1. 实战攻防中，在内外网信息收集上花费了多少时间？还有没有提升效率的空间？
   2. 漏洞挖掘-0day储备，在储备的质量和数量，除了投入更多的研究员，还有哪些方法？
   3. 社工钓鱼，除了常规的邮件、社交、功能等形式 还有哪些可以提高准度和效率的点？
   4. 如何让自己的木马免杀持久性更好？而不是成为一个消耗品？（APT的马子）
   5. 内网过程，除了扫描还有没有更精准快速的扩大战果的手段？
   6. 破隔离、拿靶标？如何更高提升效率？
   7. 二进制在攻防实战有哪些更好的应用？

   ## 红队创新点梳理：
   1. 信息收集，基于业务资产的偏门资产组合拳，例如接口资产自动化、业务虚拟目录+Fuzz；
   2. 代码审计，利用多类型漏洞组合拳组合Getshell链；
   3. 打点，钓鱼自动化+人性化闭环；
   4. 木马&免杀，基于业务流向的泛木马、基于自定义加密算法的魔改；
   5. 内网横向，基于集权的维权与发包、专有协议、业务白名单、基于协议的认证突破；
   6. 隔离突破&靶标，基于集权&边界设备的自动化精准发掘、认证突破

   # 红队vsAPT组织 重点差异-隐匿

   ## 重点体现下靶标侧：
   1. 隔离突破：重点关注集权设备（AD k8s vcenter …）、边界设备(VPN、FW、SW)、Web应用-跨段（https 隐匿效果更佳）
   2. 漏洞系列：1day&nday（相对比感知明显）、0day储备、临时挖day（基于临时源码&闭源代码），总体来看漏洞打过后尤其RCE效果在端侧还是有动静被监测。（也要看防守人员是否针对告警做处置，例如佯装攻击批量告警后的专项攻击）
   3. 口令系列：密码提取&复用、规律提取、密码&验证码欺骗、基于社工的猜测推理
   4. 认证系列：基于协议、票据、认证类的突破。相对无感，毕竟都是正常行为，管理员也是这个业务流量。
   5. 手工渗透，组合拳。（top10类组合、 web&系统&组件的渗透组合）
   6. 基于社会工程（搞人），二次钓鱼&精准钓鱼，运维管理、业务管理等

   # 攻防业务创新

   赛道领域非常的多（据不完全统计，2022年投资的细分领域20多个： 工控安全、隐私计算、开发安全、零信任、安全运营、物联网安全、区块链、公共安全、智能网联汽车、身份安全、大数据安全、云安全、密码、API安全、渗透测试、软件安全、安全合规、安全验证、威胁检测、威胁情报、攻击面管理、网络靶场、网络空间测绘、网络安全芯片、异构大数据、IP数据库等），但具体红队攻防赛道哪些可以更好的落地？

   1. 攻防演练类，目前红队检测服务相对比较为成熟，还可以拓展红队专项评估，例如域安全评估、集权类专项评估（k8s、vcenter…）
   2. 入侵与模拟攻击BAS
   3. 云安全专项检测，本身对红队渗透有帮助，且可单独形成服务
   4. 红队中，移动端的暴露面自动化探测
   5. 红队中，借用api进行数据权限的获取，借助业务资产&表单构造寻找偏门资产，助力信息收集的最大化，实现ASM类的增值
   6. 规划建议类，红队攻防咨询、沙盘推演；
   ____1. 攻防咨询，基于红队检测结果，进行根因挖掘形成有效性检测建议（咨询类公司不一定好做，因为没有实际做，红队类没做总归是概念，做了就能得到验证）
   ____2. 沙盘推演，企业类不一定好组织，需要的资源相对较多。但的确能够发掘更广泛的风险及影响，进而佐证价值点
   ____3. 攻防咨询先执行了红队，基于结果来建议并推动；沙盘要假设成分，逻辑可行，不一定真打，重在证明影响和危害。
   `

   回复

7. 深度探讨安全左移 SDL问题 | 总第199周
   https://mp.weixin.qq.com/s/6IK6kcyBBBoDgO6q8l89NA
   `
   避免低级问题、已知问题、历史问题重复出现，提升基本的安全水位。风险永远是存在的。通过安全左移，一方面是可以直接看到的安全架构、卡点、自助安全扫描、安全修复建议等显性的内容，还有一点就是可以让安全打通整体信息流，有信息的时候可以及时同步到安全侧，这样安全可以做的更主动。

   ==
   0x1本周话题

   各位大佬，大家在做互联网系统上线前和上线后的安全风险把控上是如何做的呢？我们现在是互联网系统上线前要求进行渗透测试，但是还是有上了生产后因为配置错误的原因引入了新的安全风险，我们也定期在做渗透测试，但是不是每天都做，风险就会存在敞口。

   A1： 风险永远存在的，需要定期做。上线前必须渗透测试，上线后众测。靠渗透测试就把漏洞全找出，安全公司就得失业了哈哈。配置的话，我觉得得做基线。所有动到基线的都要评估才能动，应用程序的配置只能靠变更的复核。

   A2： 持续性基线+DAST+SBOM+漏洞情报，或者直接ASM。
   A3： 安全要左移，不能等到最后做渗透测试。首先要在需求阶段介入安全，把安全需求提到需求里去，在设计阶段安全架构、安全设计要看，代码扫描，组件扫描都要做，最后才是渗透测试。渗透要跟上系统迭代的节奏，当然成本比较高。

   Q：安全左移这块儿，我们正在做，确实能解决一些问题，但是始终没法实现收口。
   A4： **从安全动态发展的本质来说是收口就是个伪命题，不过低级错误还是能管得住。上线前提测发现的漏洞还好，卡点、红黑榜……似乎没有更好的办法了。**
   A5： 能把sast+iast+dast这一套全搞下来的企业真不多，而且sast这个如果没有把工具用好误报率高，得花很长的时间调整，iast现在感觉误报率也挺高的。

   Q：这样的安全左移，预计需要投入多少安全人员来做？甲方自己还是外包服务？
   A6： 看业务线和产品线的迭代情况，对人员的要求很高，要到安全架构师的基本。比如能解释清楚assess token和fresh token某个场景下多少时间合适，日志脱敏方案，一般来说目前快速双周一个迭代的开发周期，一个人也只能盯3-4个产品。
   A7： 如果SDL人员不足，也可以考虑建设的轻量些，把自动化扫描工具嵌入到研发效能平台，作为研发环节的自服务，业务部门根据报告和安全文档自行修复，安全部门在构建和发布环节只卡一些特别高危的红线规则。
   A8： 自动化扫描容易实现，就是误报率这个问题不好解决，必须把规则设置得很优化，减少人工分析的频率。

   Q：现在SDL人员配置比例一般多少，有这方面数据吗？
   A9： 有些公司专门有一个团队负责的，有些就是几个人负责。SDL参与者岗位应该是没有界限的，开发、运维、安全都是参与者。跟开发对象或产品绑定在一起。不好确定比例。
   A10： 我知道的金融行业好像sdl做的比较重，投入也比较大，中大行比较有条件，小行比较难，人少，外包多，很难执行。互联网一般做法比较轻，敏捷开发节奏下sdl也几乎无法落地/落全，sdl roi也不好衡量，有些公司sdl团队都做没了。

   A11： 安全左移一般都是右边的事儿做的比较好了，如果右边的事儿没做好，先做右边的，然后再考虑左移。人都要饿死的时候，就不能考虑种地的事儿。目前看，安全的最初最有效的切入点还是渗透测试，以及从渗透测试向左向右的慢慢移动。左的话主要的提升漏洞的发现自动化能力和覆盖能力，右的话主要是威胁的即时识别、发现、阻断、响应和及时处置。
   SDL 其实主要解决的问题是业务发展与安全发展的后期不均衡的矛盾问题，以及“一边擦屁股一边拉”的问题。

   A12： 往往右边的事做成熟了，左边的事就慢慢变得没有话语权了。最后是安全测试兜底，做好环境安全控制域监测。
   A13： 同意，左移的安全价值要长期才能看到，如果研发平台都没有用起来，就不要轻易左移，安全团队还得管研发流程。
   A14：sdl阶段一大家关注和解决编码漏洞，相对来说用各种工具上相对来说还是有一定标准化解决方案，到阶段二的情况完全偏向于业务逻辑和实现相关，这块自动化和工具化很难，导致要做就要投入人，产出和衡量不确定性因素比较大。
   尤其现在还嵌入了PbD，privacy by Design，SDL流程更加臃肿了。
   A15：业务逻辑的自动化很难搞，这个只能靠人工测试，QA培训也就只能测最简单的。现在搞得也就越权算是抽象了标准化方案，其他的基本上还没有看见。
   A16： 安全组件化可以保证基础的安全能力，标准化，快速复用，但业务安全这个确实只能根据需求来逐一分析了。
   A17： 越权这类业务逻辑测试，我们是安全这边给点测试用例培训，研发给测试提测自测 不然QA不接，然后QA也要测试一遍，有这个记录才能到安全这边走流程，安全抽查。
   A18： 除了越权，通用功能场景，比如账号注册登录找回密码，账号管理，授权三方登录（oauth2）、短信邮箱验证码、文件上传这些过去经常出问题的地方都可以沉淀成场景和方案。我们现在做在了平台上，产品或开发选他们要做的功能场景，直接生成安全评审报告，有争议的地方在报告下面补充说明。流程上强卡，产品指定排期，到期提醒研发check是否全部按照评审报告的安全要求实现。
   A19： 只能是应用安全培训+合理的指标设置（作为基线），作为遵循性要求；最后系统上线前做现场基线审计（不卡点）；将审计报告全通报。如果因为没有按照安全要求实现，产生了问题，可以追溯，被发现了记录故障。

   Q： 我理解相当于场景的安全威胁建模和风险规避方案，业务威胁建模到业务最终落地，这2块有关联起来吗，自动化测试可以同步实现吗？
   A20：checklist一定要站在产品的角度写，让产品开发能看懂，不能站在安全的角度写。不追求大而全，解决主要矛盾。QA测试、安全测试都是和安全评审报告关联的，自动化验证做不到。
   A21： 安全首先梳理出通用场景，然后整理一份最佳实践手册，最后业务评审时进行场景评估，研发按照最佳实践编码，最后QA验收。我们目前正在这么做，基于人工，自动化只能作为补充，扫描组件漏洞。

   Q： 威胁建模我们也做了，但是有点设计与实现脱离，还没有想到怎么验证是否按实际进行落地？
   A22： 我觉得最终要的是流程能先跑起来，各个环节能从过去完全不考虑安全，开始考虑安全问题，就是比较大的进步。追求完美闭环，需要的人力成本太高了。通用场景的建模也挺有必要，就是成本也挺高。
   自动化的，目前iast、dast、sast、sca也都上了。devops强卡发布的是sast和sca，iast暂时还没做到强卡发布。
   A23： 我们基金和银行、证券还是有区别，能够投入的人和资源有限，所以会考虑工具需要各方投入的成本，工具和流程严格执行可能最终结果就是导致进行不下去，目前倾向于iast的原因就是误报比sast低，然后也不会对测试带来额外太多的工作负担，只是没法像sast容易做到在devops平台上做卡点。
   A24：SAST可以用，集成IDE插件。这样安全团队投入人力会少点，负责工具推广和规则维护就行。开发自己判断。虽然粗糙了点，但是总比没有要强。缺点就是不算卡点。

   Q：sast误报的收敛时间可能会有点久，前期怎么度过这个时期，误报需研发进行确认，比较担心研发会抵触，处理误报的工作量感觉也不小，是通过厂商驻场服务的模式来进行协助处理误报？
   A25： 一点点开规则，我们现在开的都是误报率低的规则，误报率高的也不敢开。
   A26： 我倒觉得这是好事，不是臃肿了，安全可以借力，让开发在一个流程里把多个要求都搞定，开发最怕一遍一遍翻烧饼，但不怕to-do-list。

   Q：各位大佬在代码审计工具选择上iast，sast两种类型能分享一些使用经验么，两种类型的工具使用体验如何？
   A27：iast、dast、sast等我们都有用，漏洞检出有重叠部分，也有不重叠的部分，然后再多产品横向对比（优化检出规则），工具的特性来看，**都有自己存在的价值和意义，不可或缺**。
   `

   回复