给Twitter设计个安全修复方案
不要神化国外的安全建设
Twitter的苦衷
要解决的问题
设计安全方案的原则
访问控制架构
注意事项
不要神化国外的安全建设
安全做的不差的NetFlix(参考Netflix的DevSecOps最佳实践),因为财报不理想最近股价大跌,Twitter有高危漏洞但是股价并未受影响,更加说明了笔者的论断:企业业务发展远比安全风险给股价带来的长期影响重要.....
此类漏洞举一反三TSRC(参考企业安全建设 丨 当我们在谈论推特安全事件时,我们在谈论什么?)给出的解决办法是一、内部系统需要零信任;二、权限类收敛采用框架集成全链路票据,数据操作层集中验票的,想来在腾讯完全落地有难度,也不能让Twitter快速解决问题。笔者看到Twitter内部这么久还没闭环,作为美国股市精神股东真替他们捉急。:)
根据最新的媒体报告,Twitter认为此次漏洞原因是”公司检测到了一次协同式社交工程攻击,发动者成功锁定了一些具有访问内部系统和工具权限的Twitter员工。黑客利用这些访问权限控制了许多知名账号和密码,之后便使用其账号发布关于比特币的动态。“,属于内部的人为失误\蓄意破坏\信息窃取这一类风险。上一次出类似的事情是前亚马逊工程师Paige Thompson 被指控利用工作方便来访问Amazon云服务上的Capital One服务器。
Twitter的市值只是1/48个谷歌,1/2个百度,市值决定安全的投入,不能盲目崇拜国外科技公司的安全建设。从历史反复漏洞披露的信息看到,Twitter内部存在不少历史安全问题。黑客简单社工后即可完全控制内部系管理统,利用内部权限可以控制用户Twitter账户,无审核机制,直接修改邮件重置密码,用户信息无隐私保护和数据脱敏。
Twitter的苦衷
Twitter案例中关键突破点是内部系统的高权限被社工或收买了。内部应用通常会涉及敏感数据或功能,例如用于生产系统的调试面板、账户管理系统或具有敏感公司数据的数据流和机器学习模型。Twitter安全性做的不好,是因为:
一、现有的商用防护方案又难以覆盖,传统的基于网络、员工身份的隔离方案完全不适用。不能仅仅将这些内部应用程序通过防火墙隔离,网络隔离仍然有可能会被意外配置暴露在公网,而且外部攻击者仍可通过XSS+CSRF或SSRF组合拳攻击,或者通过内网环境中已经隐藏攻击者(黑客或内部人员)。
二、这类问题一般并视为运维安全和办公网安全和开发安全的三者责任间。与生产环境相比,内部应用程序通常会被安全团队有意无意的忽略,安全团队反馈的吐槽是两个大问题:这类系统太多了,属于历史遗留问题;开发语言多样,没有统一的解决方案。
三、安全人员不足:Twitter的安全招聘信息已经挂了两个月了,看来还是缺人惹的祸。
要解决的问题
所以说现在的攻防趋势是技术上直接攻击越来越难,黑客转而关注间接从内部获取权限,并不仅仅遵循从internert-dmz-db存储的方式,走向了internert-内部用户或内部系统-信任关系-db存储。线上的生产环境经过了白帽子反复蹂躏,基本做到了符合安全基线,背后的开发语言、应用框架、资产管理是相对完善的。但是内部的私搭乱建,各种员工机器的的CI|CD系统,重要的内部服务系统,就有五花八门的开发语言,技术和风险了。
设计安全方案的原则
风险是普遍了,问题是需要复盘的。假设我们要防御类似于Twitter这样的攻击,需要安全建设的理念是:
-
不是ServiceMesh架构不能照搬lstio方案 -
防御方案应该是可扩展的,并且兼容后端的技术栈。 -
结合软件开发和发布流程 -
设计出色的技术解决方案还不够,落地才是 -
应用防御措施时,安全团队和开发项目组都需要参与进来
访问控制架构
以上是成形的架构。具体的解决办法是分为五步走:
-
设置中间层代理,以往员工直接单独访问内部系统进行操作,危害性参考有:无网络隔离直接访问内部系统 里面可能包含未脱敏信息 缺少鉴权机制 这时候加个访问层的代理是解决问题的第一步。加入代理的好处多多,可以收敛入口,设置网络隔离,访问系统管理。一切的机制是在隔层的代理上做,代理的形式可以是api网关、统一portal。 -
传输层加密。在准备推进代理的时候,不用等系统开发完成,可以调研引入全链路的tls进行传输层的加密。这里的理由有两个:Twitter这样和客户隐私强相关的企业,必须要防止内部网络层的窃听,每一层的安全措施都要做到底。借鉴google自研的ALTS,参考https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security?hl=zh-cn 或者FaceBook的方案 https://engineering.fb.com/security/service-encryption/ ,保证应用传输的安全,借用pki证书或者Kerberos机制可以用来表示服务的身份模型,而且具备极强的架构伸缩性。 -
做到访问的统一收口,基于代理开发sso+u2f的机制做到访问的统一收口,逐步梳理系统让加入此机制。u2f机制一定层面上杜绝密码猜解、调用、离职员工访问的途径,后续添加FIDO等零信任访问控制措施。 -
收敛员工的使用新版浏览器,前后端加入监控,日志,埋点,行为检测等功能,由运营风险分析(ORA)团队处置审计。 -
代理添加通用CSRF保护(添加SameSitecookie标志)和XSS保护(Content-Security-Policy标头+随机数),设置内网waf。比如攻击者有个xss,可以使用csrf获取内部系统信息,这个时候在代理层设置csrf策略,对防护者成本极低,内部应用也无感知,但是收敛面向内部高权限人员xss的危害收益极高。内网的waf听起来会受到的接入阻力较多,但是内网场景固定,干扰项少,实际上内网waf的误报会很少,没有很多的噪音。
注意事项
拍脑袋出具安全方案不是问题,落地有防护效果才是,以下是几个要注意的点:
-
安全需联合技术团队合作开发维护代理层,并在出现问题随时响应。有数字取证,安全工程或隐私工程方面的技术经验很重要,有维护高可用、系统稳定性运营经验的团队更重要! -
基于存量系统增加安全防护系统首先要考虑可维护性,可用性高于安全性,一定要避免出case。 -
在不影响业务运营的时候同步进行开发和部署。理想情况下,如果代理服务器出现故障,背后存在关键系统,会阻止正常工作,假设如果代理后面有堡垒机,则如果代理发生故障,将再也无法再登录堡垒机故障排除...... -
推进的节奏不用全面收敛,优先关注高危的风险。 如何确定要收敛的风险范围做到不遗漏呢?内部多打就好了。 -
向上管理。这个框架可以帮助确定Twitter距离谷歌的差距在哪里,未来的安全投资方向是什么。有基于事件驱动的安全不可怕,没有将策略传达给高级管理层才可怕。笔者这里提供个简单的示例,点击可右移滑动:
定义 | 防御 | 检测 | 响应 | 恢复 | |
---|---|---|---|---|---|
需要让哪些团队参与 | 账户、运维 | 社会工程学 | 异地登录、xss、异常感知 | 应急流程、公关 | 恢复异常账户 |
必须构建什么技术 | 开发流程、数据安全技术 | 培训、邮件网关、零信任 | 身份认证、行为检测 | 工单、操作审计 | 私信、公告板 |
创建什么流程 | 背景调查,安全顾问理事会 | 培训机制 | 应急响应流程,知识库 | 应急响应流程 | 媒体应急发布流程 |
推荐阅读:
周年赠书福利
参与方式一:点击下方抽奖小程序,关注公众号 安全乐观主义,将本文转发到朋友圈和微信看一看即可参与!公众号后台将随机抽选取幸运用户,每人赠书一本!
参与方式二:为本公众号投稿一篇安全相关的文章,内容形式不限,即可获得赠书一本!赶快参与起来吧~
本文分享自微信公众号 - 安全乐观主义(gh_d6239d0bb816)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
金融科技的碎片化思考(上)
从事金融科技行业已久,也一直想写写金融科技相关的文字,又惶恐间,深觉如此大的话题hold不住而贻笑大方。偶然翻开束之高阁多年的《蚂蚁金服-从支付宝到新金融生态圈》,惊喜之余亦将自己碎片化的那点浅识愚见串联起不少。行文仓促,些许是经历,些许是总结,些许是念头,唯恐扭头就忘,权当流水记账给自己看也好。 又不是何样大家,可以著书警示世人,无须给自己压力,写到哪儿便是哪儿吧,看官您也担待一二。 金融是什么?科技是什么?合到一起的金融科技又是什么?让我们剥开浮躁的表面直指内心。 科技是第一生产力 先说科技,也就是科学技术,是第一生产力。科学是理论,技术是应用。作为生产力,科技理论上可以应用于人类已知或者未知的所有领域,而金融领域不过是科技可应用的领域之一而已。当然可不仅仅限用“应用”,还可以“驱动”“赋能”“普惠”“整合”“协同”、“数字化”“互联网化”“智能化”“生态化”、以及“金融3.0”“VUCA4.0”“工业5.0”“通证经济”“数字经济”“ABCD”等等 (金融科技领域不会用词,OUT一半!)。 对于大国来说,军事和金融是两个最最核心的支撑力量。而通常来说,最尖端的科技也是始于这两个领...
- 下一篇
DO,DTO,VO,POJO 你知道吗?
作为后端最常用的编程语言之一,Java 已经有很多年的历史了,在阿里内部,Java 也是使用最广泛的一门语言。在阿里实习的这段时间,规范一词是我感受最深的。没有规矩不成方圆,今天来说一下 Java 中的各种 O(bject)。 为什么会出现这些 O? 我们知道,这些 O 不管叫什么名字,其本质都还是对象(Object),既然本质都一样,为什么非要给他们套上各种马甲?个人认为原因有三:第一,随着编程工业化的发展,需要有一套合理的体系出现。中国人喜欢造神,外国人喜欢造概念,于是 MVC、MVP、MVVM 等编程模型就出现了,为了搭配这些编程模型的使用,需要对 Object 的功能进行划分,于是我们便看到了这些层出不穷的 Object。当然这里并没有批评这些概念的意思。其二,我认为在团队协作编码中,一个好的命名方式是可以节约很多时间成本的。就比如getItemById一眼看去就知道是通过 id 获取一个 item 对象,ItemVO一眼看去就知道是前端透出的 json 对应的对象。其三,如此划分,可以让项目结构更加清楚,不至于出现东一块西一块,对象乱扔的局面。尽可能避免了在多人协作时对象混乱...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Mario游戏-低调大师作品
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装