[ppt学习]快手安全沙龙


=Start=

缘由:

好久没有主动学习提高了,最近公司的事情太多,人也变懒了很多,所以博客也不像之前一样经常更新和打理了。

个人感觉不能老是这样,浑浑噩噩没有个目标,还是要逼自己一把,用输出的flag倒逼自己多去输入、多去整理、多去思考然后落笔记录下来,才有可能取得提高和进步。

这里整理一下前段时间利用闲暇看的快手安全沙龙的PPT的内容框架,方便以后参考和回顾。

正文:

参考解答:

个人觉得,在这些分享里面腾讯的lake2(分享的内容广泛全面且不缺深度)、长亭的崔勤(分享的内容对我来说是比较新的)还有小米的fenggou(「消防员」和「二向箔」的解构和概念)这3个对我的帮助会更多一点。比如:小米IoT自动化审计那里的「二向箔」的概念,我刚好前段时间看完了《三体》丛书,也”记住了”这个概念,但没有往安全扫描、审计这里面套,经过他这么一讲之后,感觉我书真的是读的太浅了,还是缺少思考和泛化,以后还要多看看其它人的分享,应该能获得类似的收获。


以攻促防——企业红蓝对抗体系建设 – 腾讯·胡珀

企业安全体系建设思路——SDL
企业安全体系建设思路——DevSecOps
一个问题——做了这么多(搭建安全团队、建立安全规范/系统/流程、进行安全运营),现在我们足够「安全」了吗?
如何验证安全体系是否有效?实战是检验安全防护能力的唯一标准。

RedTeam与红蓝对抗的概念
渗透测试与红蓝对抗

腾讯蓝军体系建设实践——从单一Web漏洞挖掘到整体安全体系验证,覆盖APT攻击、DDoS、AIoT、风控安全、办公室窃听等场景,衍生出专门的战略支援团队及平台,引入外部白帽子及众测,为腾讯云大客户提供服务

系统安全蓝军(黑客攻防)
网络安全蓝军(DDOS攻防)
业务安全蓝军(风控攻防)
物理安全蓝军(”窃听风云”)
泛蓝军(SRC与众测)
泛蓝军(支援部队——工具平台研发、安全技术研究支持)

红蓝对抗实战案例一
红蓝对抗实战案例二
蓝军经验沉淀——蓝军平台建设

各蓝军团队的分工与协作——腾讯经验,开源协同

总结

  • 关注安全风险,更要关注安全防御体系的缺陷
  • 不止是渗透,红蓝对抗领域应该是全方位的
  • 不要依赖单兵作战,红蓝对抗能力需要沉淀为自动化平台
  • 在HW推动下,红蓝对抗将飞速发展,不论是技术还是商业化
  • 关注法律风险,一切行动都需要在合法合规条件下进行

==

快手业务安全 – 快手·陈成

  1. 初识黑灰产
    黑色产业链
    灰色产业链
    短视频下的黑灰产——账号安全
    短视频下的黑灰产——引流
    短视频下的黑灰产——流量作弊
    短视频下的黑灰产——活动”薅羊毛”

    黑灰产特点
  2. 走进风控
    黑灰产治理的特点——持续对抗的过程
    黑灰产治理的难点——平衡安全和体验
    黑灰产治理的难点——业务沟通
    黑灰产治理的难点——木桶效应
  3. 核心打法
    业务架构——中台化
    核心打法——根据挑战提出核心解法
    策略对抗——平台化
    策略对抗——从人工到半自动化
    策略对抗——无监督和半监督的广泛应用
    业务联动——产品手段(奖励延时发放、风险提示、专属文案)
    业务联动——统一收口、联防联控
    业务联动——风控流程
    基础能力建设
    情报体系
    治理效果——内部数据(反作弊-资损、资损率、客诉率;恶意引流-拦截数量、漏报率、客诉率)
    治理效果——外部评价

==

攻防演练中的攻击战术演进 – 长亭·崔勤

变化与机会
监管(增强)
甲方(变化)——更重视服务、更重视安全效果、新的采购模式
乙方(机会)——产品机会、高端服务获得认可、深度参与安全建设

“实战”标准下的安全效果更真实

  1. 结果导向,不限制手法。
  2. 攻防两端深度参与,不再仅仅是一份检测报告,体验感更足。
  3. 低危漏洞?安全意识不重要?

实战标准的特点和挑战

  • 不确定性 -> 人的能力更重要
  • 动态变化 -> 学习速度
  • 结果导向 -> 木桶短板问题更明显

攻防演练
早期依赖个人能力(经验),近两年更为体系化、专业化、团队作战优势更明显。

攻防演练(红队)

  1. 能力象限
  2. 框架的演进
  3. 决策及思考,攻击战术

攻防演练(框架演进)
信息 -> 漏洞 -> 工具

核心要素

  1. 信息 是APT攻击的第一生产力,贯穿APT攻击的整个生命周期,优秀的情报能力可以令攻击事半功倍;
  2. 漏洞 是撕开防线的武器,需要依靠信息精确制导;
  3. 工具 是潜伏敌线、刺探情报的间谍:主要包括远控,日志、流量、密码窃取等后渗透工具。

战术总结及思考 – 高效的信息收集(自动化)
爬虫 -> 扫描 -> 漏洞

战术总结及思考 – 应用漏洞vs基础设施漏洞
优势
劣势
使用范围

战术总结及思考 – 供应链安全

  1. 外包(驻场)对客户人员架构不熟悉导致被钓鱼。
  2. 同一外包开发写出相似漏洞(更可怕的逻辑漏洞)。
  3. 软硬件产品(VPN、虚拟化平台、堡垒机、OA、邮箱等)。
  4. 网络(专线)与合作方打通。
  5. 供应商的开发依赖存在安全隐患。

战术总结及思考 – 安全厂商对抗

  • 安全产品的自身安全性问题
  • 安全产品的能力失效问题

安全/运维/监控设备:

  • 提前储备相关0Day或1day,可供内网横纵向扩展利用;
  • 一般以server端控agent端,或者先从agent打到server,再打其他agent的形式;
  • 安全设备不安全。

战术总结及思考 – 有效权限
简单粗暴——拿开源工具直接内网扫描
白名单权限——入侵系统后,通过漏洞利用转变对系统进行控制的方式为常规运维访问,提升隐蔽性以维持权限
绕过黑名单——加密传输、端口复用;代码混淆、免杀处理;优先利用企业内部已有信息进行横向扩展

攻防演练 – 展望
攻防演练中的某些问题或环节可能会演变成产品,进一步提升普适度,覆盖越来越多的客户,提高整体安全水平。
人 -> 工具 -> 产品
可解问题 -> 已知问题 -> 未知问题

==

快手纵深攻防体系建设 – 快手·黄浩

一、四维时空红蓝对抗推演

“纵深”这个词,空间换取时间,提到空间、时间,又会联想到爱因斯坦的“相对论”,四维时空,你可以洞察过去、预见未来。红蓝对抗演练,更像是四维时空的产物,将未来可能发生的威胁和风险提前感知,所以蓝军更像是未来部队!

二、面对面的纵深攻击演练

面对面的红蓝对抗要关注哪些空间:网络空间[互联网、办公网、生产网]、物理空间、意识空间

三、背对背的目标斩首行动

背对背的红蓝对抗,目的是为了验证安全防御体系在真实的攻击场景下所表现出的威胁的发现能力、告警能力、阻断能力、应急处置能力、分析溯源能力等,检验安全产品有效性的同时,也检验安全服务的质量。同时攻击角色不仅包括内部安全蓝军,也应该包括泛蓝军(外部安全能力),往往不分时间、不分地点、不分方式,目标明确,我们称之为“斩首行动”。

背对背的红蓝对抗往往是实战方式,适用4种场景:
1、由外到内入侵渗透;
2、线上产品漏洞挖掘;
3、移动安全防护逆向;
4、业务安全分析溯源。

四、自适应的纵深防御体系

1、自适应安全架构
2、纵深攻防体系推演大盘
3、红蓝对抗攻防双方共建指标

==

IoT 自动化安全平台体系建设 – 小米·孟卓

我是谁?从哪里来?要做什么?
团队任务如何达成?
  • 消:消除隐患
  • 防:防患于未燃
  • 员:人员的成长
消除隐患

技术难-技术栈复杂
团队难-人才缺失
压力大-产品量激增
无体系-行业经验

初步尝试
团队能力交叉
AIoT 消费级物联网产品安全基线
误入歧途 – 实验室变流水线工厂

二向箔 – IoT自动化审计的突破
将三维化/立体的IoT设备,通过数据化的方式二维化到机器、算法可处理的层面,然后进行自动化的审计。

修完漏洞就安全了?
这是一个巨大的误区,安全是动态的。随着技术的迭代,品类的多样化,开发者的交替、供应的风险以及用户要求的提升,很难找到一个「基点」来说明产品的安全。

防患于未燃

人无远虑,必有近忧。

==

快手应用安全演进之路 – 快手·廖新喜

01 – 作坊阶段
编码规范
知识积累
管控手段/能力
评价指标

指标体系建设
漏洞属性

SRC
众测
自测漏洞
漏洞等级
业务属性

评价指标

按期修复率
自检率
高危自检率
对外自检率

建设目标

外部SRC
内部SOC
漏洞扫描器
重大活动保障

02 – 自动化阶段

静态代码扫描能力建设
三方库漏洞收敛

03 – BP阶段

业务迅速发展-安全诉求高
漏洞发现靠后-修复成本高
业务漏洞突出-发现难度高
新型漏洞突出-治理难度高
……

静态扫描
动态扫描
IAST
DevSecOps

参考链接:

快手『攻防无界』沙龙 PPT回放已就绪,老铁们久等了~

直播回放
https://lpb3f7ev.7r14atyi40.com/f/X-1uA35uWIc8p1cT
或 打开快手,搜索【快手中学】查看直播精彩回放

=END=


《“[ppt学习]快手安全沙龙”》 有 2 条评论

  1. 红蓝对抗服务之攻击队约束条款、业务首次上云避坑讨论暨sudo账户管理问题 | 总第131周
    https://mp.weixin.qq.com/s/VrI7A2XKC_jOTUVJieCcdw
    `
    # 话题1:大家购买演习服务,攻击队会提供清楚的攻击步骤吗?在演习完毕后提供验证修复服务吗?是比较显然的服务内容,还是说得单独明确、额外写在合同里才可以提供?

    A1:目前合作的蓝军只提供攻击结果和结果相关的一些漏洞细节,具体步骤不会提供,如果合同具体写明应该可以。

    个人觉得详细的攻击步骤意义不大,不管采用什么攻击步骤,最终都归结到利用的漏洞。

    **A2:确实主要是利用漏洞,而且很多公司的报告都有意不写这些细节。至于为何不写,可能是他们手上有一些私货不方便说,怕你抓到。真正交流的时候,通常给一个攻击流程图,你得问他们细节、工具、步骤,要不然白交流。**

    A3:问就是用的挖掘的0day,不方便透露,所以我都是私下来和红队的几个朋友交流攻击细节,然后自己处置。红队很多都是买的,后面一大帮人给他们做技术支撑,如工具平台建设team,包括魔改的cs;典型一点的像数字公司的bugclub就是收集购买各种漏洞的。

    Q:现在对攻击队都是录屏的,有人对录屏进行分析过么?感觉这就是详细步骤,除非用外围打下的,并没有用指定平台来操作。

    A4:很多操作都是在外围打,操作机录屏只有必要的操作,而且录屏基本按周起步,一周的录屏分析起来脑袋都大了,工作量也太大了。

    Q:除了保密协议啥的?目前还没有什么好办法吗?最近我正在写红蓝的合同,没想清楚怎么写要求。

    **A5:可以让红队记录攻击时间点,然后根据攻击时间点去找视频,并结合当时和指挥部报备时间、要素等情况。相对于之前盲目的翻视频,工作量小了很多。**

    A6:这个意义不大,因为乙方红队在做项目时碰到关键漏洞也不是他们自己打的,都是去买。当然,关键漏洞还是要自己操作录屏的,不然就属于违反保密协议和合同内容了。

    A7:确实可能不是,因为乙方一般挖漏洞和打红队的属于两个部门,部门之间也不想分享漏洞细节,甚至有一部分是红队自己去购买漏洞的,没有用公司挖掘漏洞团队的东西。

    Q:如果买那岂不是违反合同了?

    A8:是这样子的,红队探测出了甲方的资产有哪些东西,然后看自己手上有没有这部分的洞,没有的话就去找周围做代码审计或者漏洞挖掘的业内人士购买。这儿的资产不局限于公网资产,还有内网资产。

    总之这个特别复杂,有红队自己挖的,红队从朋友那借的,自己公司研究院挖的,漏洞平台收的,还有骗来的,比如通过弱口令等登进某个系统,然后让有漏洞的打,抓流量自己分析。

    A9:我觉得红队大部分还是要靠个人的经验和手里掌握的漏洞来得分,买漏洞的有可能存在,但比较少存在这种情况,主要是存在于小乙方想拿名次的。

    A10:这个不同设备不同厂商不同类型的day价格差距挺大的,现在0day都泛滥了。一是因为挖漏洞的收入高还能卖,一大堆人去挖漏洞,从提供设备的-破解代码的-代码审计的都成产业链了;二是漏洞一直在那,结果就形成分布式代码扫描器,挖的基数大了,漏洞就更多了。

    **A11:回到正题,关于怎么从签合同的红队里面找出来攻击细节,通常在复盘的时候,请红队分享经验,提供细节。这需要甲方在签合同里定义好红队的职责,要求提供详细的报告,在招标的时候写在标书里。**

    # 话题2:公司主营业务是数据服务,目前IT设施主要以自建为主,每年投入好几千万(不含人力成本),可用性这块也不理想(如出现多次通信线路故障),业务上云也是一种行业趋势,CTO提出技术部去调研下业务上云的可能性(采用业务分拆上云,核心数据类服务不会上云),但公司无业务体系化上云的经验。对此,个人理解需要搞清楚几个问题:

    调研的维度:除技术改造成本,费用,迁移上云辅助技术工具,云设施安全性,云服务多样性,用户案例等之外还有其他维度吗?
    是否有主流供应商的竞品分析可以分享一下?
    选择云供应商应该遵循哪些原则?

    A1:内部支持方面,可以让技术部了解一下k8s,之后对自身的技术架构和业务架构进行评估,如先搭建开源k8s环境试试水。

    外部支持方面,可以厂商先做个咨询,让厂商出一些参考方案。云服务提供商和云安全提供商应该是不同的厂商。调研维度建议增加信创相关维度调研,至于选型可以网上搜一下相关厂商,知名大企业,技术实力强,能扛事最好。

    A2:这个问题本质上是一个基于领域模型的业务架构问题,上面说的3个问题还只是怎么上,更前置的是能不能上,上什么。

    A3:我们18年开始上云,从早期的aws到现在国内的三大云厂商等云,迁移到公有云上觉得有个额外要考虑的几个建议:
    0、必须考虑清楚为何要上云,主要目的是什么?不要为了上云而上云,别忘记初衷。
    1、该公有云gg后应用怎么使用,怎么持续可用,毕竟公有云的故障也不少,别听他们销售吹。
    2、公有云数据备份需要考虑,建议异云或者本地数据中心,需要考虑专线带宽。
    3、迁移到公有云的系统和本地数据中心的耦合性如何,需要考虑之间的依赖成本。
    4、迁移到公有云的数据做合规风险评估,数据是否涉密,建议征询监管机构意见,是否可以放到该上面。
    5、注意做好数据流/网络规划,比如:云上左下系统间数据交互走向、用户访问走向(含内外网用户使用方式)。
    6、公有云的网络安全怎么规划,选型的时候需要一起和业务一起综合考虑好,不然后期投入成本也不少。

    Q:核心数据业务不上云,两者云上业务依赖的数据,来自公司自建IDC的大数据服务生产的,所以架构应该会是混合云,K8S技术栈公司用了有几年了,也接触了相关公司,领导比较担心就是上云了,后面会被绑架了。

    A4:要考虑用某云的云服务后的代替方案,不然有可能在迁移到其他地方的时候掉层皮。一般非必要不用云的专业服务,一旦用了,绑架是必然的,你得把云当组装商一样管理供应链,这对自己的业务架构要求很高,否则就是换不掉。

    # 话题3:关于堡垒机的账户管理,堡垒机托管的普通账户可以sudo到root权限吗?或者可接受什么方式提权到root权限?

    A1:不建直接sudo,一用就收不回来了,可以配合命令审计功能,sudo命令触发审批。堡垒机自身就有这个功能,可把sudo加入审批,提权审批后再回来还得输普通账号密码。

    A2:sudo可以配置能执行的命令,但还是不建议给sudo权限,太危险了,提权的话我最喜欢suid和uid提,而且建议对root的命令做复核。

    A3:如果给cap(capabilities)权限应该也可以,权限更加细分,这更多的用在应用程序上,如果如果是用户直接登录操作,可能不适合。
    `

  2. 以攻促防:Google的红队是怎么做的?
    EP71 Attacking Google to Defend Google: How Google Does Red Team
    https://cloud.withgoogle.com/cloudsecurity/podcast/ep71-attacking-google-to-defend-google-how-google-does-red-team/
    `
    Topics covered:

    谷歌的“红队”测试理念和方法是什么? What is our “red team” testing philosophy and approach at Google?
    我们是如何进化到这种方法的? How did we evolve to this approach?
    从测试到让谷歌和我们的用户更安全的途径是什么?我们的测试如何推动我们所做的改进? What is the path from testing to making Google and our users more secure? How does our testing power the improvements we make?
    谷歌的红队有什么独特之处? What is unique about red teaming at Google?
    愿意分享一些你经验中有趣的测试故事或例子吗? Care to share some fun testing stories or examples from your experience?
    `

发表评论

您的电子邮箱地址不会被公开。