Sec Hotspot 首页  收藏本站  技术博客  RSS
统计信息
已收录文章数量:8499 篇
已收录公众号数量:89 个
本站文章为爬虫采集,如有侵权请告知
已收录微信公众号
网信中国 区块链大本营 白说区块链 区块链投资家 区块链官微 区块链铅笔Blockchain HACK学习呀 二道情报贩子 合天智汇 小白帽学习之路 小米安全中心 弥天安全实验室 SAINTSEC SecPulse安全脉搏 TideSec安全团队 360安全卫士 游侠安全网 计算机与网络安全 安全祖师爷 安全学习那些事 腾讯安全联合实验室 黑客技术与网络安全 安全圈 腾讯御见威胁情报中心 Python开发者 Python之禅 编程派 Python那些事 Python程序员 安全威胁情报 吾爱破解论坛 行长叠报 安在 i春秋 嘶吼专业版 E安全 MottoIN 网信防务 网安杂谈 数说安全 互联网安全内参 漏洞战争 安全分析与研究 邑安全 ChaMd5安全团队 天融信阿尔法实验室 安全牛 SecWiki 安全学术圈 信安之路 漏洞感知 浅黑科技 Secquan圈子社区 奇安信集团 奇安信 CERT 国舜股份 雷神众测 盘古实验室 美团安全应急响应中心 瓜子安全应急响应中心 顺丰安全应急响应中心 蚂蚁金服安全响应中心 携程安全应急响应中心 滴滴安全应急响应中心 字节跳动安全中心 百度安全应急响应中心 腾讯安全应急响应中心 网易安全应急响应中心 OPPO安全应急响应中心 京东安全应急响应中心 Bypass CNNVD安全动态 安恒应急响应中心 天融信每日安全简报 奇安信威胁情报中心 看雪学院 黑白之道 水滴安全实验室 安全客 木星安全实验室 云鼎实验室 绿盟科技安全预警 白帽汇 深信服千里目安全实验室 腾讯玄武实验室 长亭安全课堂 FreeBuf 绿盟科技 nmask
谈一谈安全运营工作是什么
本文来自公众号:美团安全应急响应中心   2019.09.29 18:30:27


文丨弼政(职业欠钱), 美团基础安全负责人


自从一年前写过《我理解的安全运营》( 点击阅读原文直达 )之后,这一年来,安全运营这个词有一种火了的感觉。有些乙方开始举办“安全运营”专场,大家坐一起探讨到底安全运营是个什么东西,以及有点什么“运营技巧”。甚至有一些乙方提供了“运营平台”、“运营服务”。


时间上的先后,有时候会让我有种错觉,仿佛自己点燃了这一轮创造新词的导火索。当然客观认知到上我个人肯定没有这么大的影响力,那到底是什么驱动了这一轮业界对“安全运营”的关注呢?


我理解可能有2个点:

1、安全的风险直观化

2、建设期已过,可以开始追求结果了


第一点的理解,其实是从 tk 教主某一次峰会分享得来的,大致的意思是,信息资产承载的价值,随着人类活动的发展,正越来越高。粗浅的理解,15 年前,我在大学宿舍的电脑中毒了,顶多就是我宿舍的同学不能打游戏了,存在上面的资料丢了就丢了,没什么影响。而前两年,Wannacry 的肆虐,让很多医院之类的基础设施系统崩坏。甚至有人弄过入侵心脏起搏器之类的活动,可以让移植了人工心脏的病人直接死去。


再加上大家的资金安全、个人隐私,几乎都在各种 App 上弄几下就可以捣鼓来捣鼓去。这里的风险其实是越来越直观的,只不过还不够有具象化,大家老以为是在电影、新闻里的,却跟自己无关。


一直到最近,国家层面举办的某些大型真人实战演练活动,把乌克兰、委内瑞拉电网之类的案例,在国内进行真实近似的呈现。很多组织的决策者发现,哎呀,原来安全不能只是雇 2,3 个人合规对付一下就行了,真出事影响还是挺大的啊。


所以,大家开始戳破了以前其乐融融的假象,不再因为买了几个安全设备往角落里一丢,半年出个报告对付一下合规检查就满足了。


一旦实实在在的去追求一些“应当可以实现的安全效果”,大多数人其实就会自觉走到“运营”这个方向上来。毕竟能力的建设只是第一步,用好它,迭代好它,才可能出结果。


第二点的理解更简单,安全从业者之前天天嚷嚷着,安全不受重视。有些企业要不是为了上市合规,真的自己业务层面都朝不保夕,肯定不会雇佣安全工程师。招俩安全工程师往往也是给业务拖后腿的,这不让干,那不让干,业务跑不快,企业生存都成问题。


但是客观的说,也有不少企业已经过了最初野蛮生长的时期,如今市值、体量、社会影响力已经不可小觑了。这个过程中,企业或多或少也招了点安全工程师来遮盖一些问题,只不过由于人数实在太少,所以大致上文档和技术沙盘图上,似乎可以假装自己做了很多工作,只是实际工作里,这些名词多数不管用(该出事还是出事)。


所以,在时代浪潮的推动下,基本的安全建设工作或多或少做完了,那安全团队也该实实在在的考虑一下,如何在日常工作中,从“有做过”,转向追求“本可以做到的更好的目标”了。这个过程,其实就是“运营”。


说到这里,我想虚构一些例子,给大家解释一下,行业里的安全工作可能是怎么迭代进化的。


比方说某一家互联网公司,已经有了不少的用户,业务模式也趋于稳定了。突然有一天被攻击,之前都是运维和开发捎带手的去解决,因为业务发展不错,他们不想自己亲自去处理了,就想干脆招个安全工程师吧。


这时候,一个人的安全部出现了。安全工程师初来乍到一看,公司啥都没有啊,文档制度上线发布流程服务器运维规范,办公网准入防病毒 SSO 双因子因素,反爬风控防作弊。。。


得了,这个工程师开始张罗一大堆的工作,写文档(拿行业里的模板素材换个公司的 LOGO),勉强算解决了文档制度,能执行多少暂且不论,聊胜于无吧,起码合规检查的时候有东东西了。


然后开始人肉去审核代码,也自己去黑一下公司的业务,发现点漏洞推动修复。日常有漏洞预警也知道开始响应了,同时张罗一些项目,逐步去解决防病毒、SDL、入侵检测、权限管理等数据安全相关的工作。


因为只有这么个把安全工程师(或者随着业务的发展,团队扩张到了 10 人以下),所以大部分的工作只能浅尝辄止,做完就算。这个阶段不追求什么最佳实践,能落地就算好的,更别说还有落地的时候被业务或者关联团队阻挠了,不配合了,无疾而终的项目呢。


当然公司因为规模也还小,没什么人盯着,所以那些事情即便不做很深,也没出啥大事(或者出不了啥大事)。被真人演习/某些对手盯上了另说……


可是,如果公司业务发展很快,成长的过程中,不断的成为垂直领域的明星。树大招风,一些典型的 case,都被行业主管部门甚至社会舆论给监督上了。老板觉得这些简单的问题怎么解决的不好,都被闹大了,安全团队就开始有压力了。


(嗯,潜台词就是,如果公司小,大概率是不会有这些压力的,所以安全团队可以相对舒服的继续干下去)


比如说,一个漏洞处理的不好,数据库被拖了,或者被入侵了,数据拿到暗网上去卖了。或者风控反爬之类的做的不好,竞对恶意的爬取数据做整合挖掘点东西呈现到了自己老板这。


老板就开始期待这一类的问题将来都得到一个好的治理。起码不能出现低级错误,本来很简单能做好的事,没尽力,漏了,这就很容易背上一些价值观不正确的锅。


我们从“有做一些事,以应对安全风险”变成了“基本功要做好,免得再出现这类风险不好解释”。大概率会发现,团队的资源和能力是不够的。


比如说,SDL,这是微软很多年前提出来的一个概念。从核心逻辑上就是把安全嵌入开发生命周期的每一个流程,这个思路帮助微软把 Windows 和 Office 系列的产品做到了后来的样子。这种思路是以项目为单位的,一个项目,从立项设计、架构评审、实现、测试、发布、运营的全周期都要安全工程师参与进去。


在国内,稍微大一点的公司,大家就知道,公司的项目多到可能成千上万甚至百万个。


而安全工程师,总共没多少人,分到 SDL 这个职责的可能更少,说不定就个把人。毕竟还有很多其它方向的安全工作要做,这几个人能整个扫描器把公司的每一个 Web 项目扫一遍,往往就对敢外宣称自己公司做了 SDL 了。更不用说白盒审计的时候那么多的误报,以及人工审查的不切实际了。


(这部分完全看公司实际情况,公司项目少,迭代少的时候,也有同行就可以每一行代码都自己人肉看过的。)


如果老板不在乎不重视(比如说偶尔出个漏洞,也没被大肆的 PR),其实这几个人也可以开开心心的做点自己喜欢的事情,有事应急一下,没事线上的漏洞就一直躺着。


但是如果老板就怕这里出事,希望因为安全工程师的存在,力所能及的减少外面能发现漏洞的可能性,每一个外部报告的漏洞都追究一下是不是真的技术上很难规避,SDL 团队就要发愁了。


一方面,人力 cover 不到全公司那么大的工作量,另一方面,不能混日子了。


这时候只能开动脑筋,抓主要矛盾啊。


分析一下历史过往案例,发现一般新项目上线的时候,没经验,被捅得最多,所以把有限的人力集中起来,新申请域名、项目上线,人工至少过一遍。一旦上线成功之后的项目再迭代(这个才是大头),团队就实在没办法了。


通过这种方法,还真是每一次新项目都能发现很多非常粗浅的漏洞,但是,毕竟覆盖率极其有限,那么多的其他项目成天的迭代,很难不出事啊。


这靠人终究不是个办法,咋办呢?整个扫描器吧,商业的还是开源的或者自研的无所谓,总而言之,有了一个扫描器,开起来,可能会被业务骂死:以前都没事的,你一扫我的业务挂了,监控告警刷屏了,数据脏了,你赶紧给我停了。


于是给业务解释:我不扫,以后黑客也会扫的啦,我会尽量规避 update/delete 相关的危险资产,有风险的 Poc 尽量不发啦。你也稍微处理一下告警监控,把我以后扫描触发的告警都屏蔽掉不要紧张啦。


好不容易达成一致,天天扫,SRC 还是天天报漏洞,尤其是一做活动就报漏洞。


以前不操心也就算了,现在每次 SRC 报的漏洞会琢磨一下,为什么扫描器就扫不出来呢?为什么人工当年看的时候就没看出来呢?


然后发现黑盒扫描器各种短板,比如 URL 不全拉(赶紧各种 NIDS、AccessLog 补救)、调度问题、POST 主动规避导致没检测到、爬虫引擎效率或者能力问题、某些资产 payload 积累问题……


这些问题以前不想管,现在老板重结果了,也不是不能解决,那就整呗。


随着自己能力的提升,某些类型的问题的确在逐渐减少,当主要矛盾解决掉之后,次要矛盾就上升为了主要矛盾,再继续解决。


这时候发现,还有很多漏洞,要是有源代码就能很轻松的扫出来。于是上个白盒审计的产品,一扫,乌压压的上万的告警,仔细一看,就 4 个有效的,还是低危的 XSS……


差点就崩溃了。


那也得整啊,跟扫描器一样,其实要弄自动化的时候,甲方就这几个人,这点时间,不可能追求解决世界上所有已知的漏洞不要出现在自己公司。追求把公司历史上出过、最常见的,而且解决起来成本不高的漏洞,做一个未来一劳永逸的控制,是更迫在眉睫的目标。


于是我们就把白盒审计自带的所有规则都干掉,从头开始,自己按照 OWASP Top 10,还有 SRC 历史数据上高频出现又很容易识别的规则开始,吭哧吭哧写了几十个规则。


根据自己的经验和人工的整理,不断迭代几个版本,这下好了,自研的白盒审计能力也有了。每次 SRC 漏报的时候,白盒的同学也开始要复盘,这事我从源码上是不是一定扫不到呢?


新项目人工审计、黑盒自动化例行化、白盒例行化,都整上来了,肯定比之前好多了。


可是,这样就好了么?


其实没有,越权这种逻辑漏洞如影随形,几乎成了各大 SRC 的心头病。如果你是个新的白帽子,不知道挖什么漏洞,你可以去试试越权,估计很快能有成就感。


而且越权漏洞这玩意吧,成本贼低,危害却高很多,比 XSS 什么的利用起来爽多了,动不动就能看别人数据,操作别人的资产。PR 风险也大。


老板咄咄逼人之后,这事也必须解决啊,黑盒白盒其实都搞不定。垂直越权黑盒相对还有点可行性,但是水平越权这种东西,有时候业务的逻辑介于公开和半公开之间,扫描器弄俩账号去看一个 ID,返回的结果是一样(证明 B 账号看到了 A 账号的数据),so what? 这事允不允许只有业务自己说了算,它是个业务逻辑强相关的。


虽然扫描器扫出一大堆的可疑 list,但是人工去闭环成本实在太高了(回到了老问题,人一个一个看是看不过来的),哪怕你临时找到了几个真的有问题的点,但是它不是个长久的事。


问题必须解决,自动化又解决不了,必须人工判断,安全工程师的人工又显然 cover 不了全公司。所以顺理成章的得出一个结论:这玩意得业务自己人工 check。


于是很开心的跟业务说:你们得交付安全的代码,这是你们自己的责任啊,越权漏洞这么难搞,风险又大,出了事不光是我们倒霉,你们也倒霉啊。你们不是有 QA 环节么,能不能每一次迭代,QA 动作把越权测试用例当成一个“必选项”啊?


业务听了听觉得也有道理,但是你怎么知道我做没做好呢?


安全工程师说,我也不知道啊,你要是做了,就在代码里留个暗号,我回头去源码仓库里扫这个暗号,谁做了就说明他知道了,没这个暗号我就发工单提醒他。


业务说,那要是有人恶意填这个暗号就是不干活呢?


安全工程师说,这我也没办法,但总比之前强点吧。


于是全公司开始吭哧吭哧照着这个办,一年之后,越权漏洞整体还真下降了 80%。(对,的确存在少部分不正直的人,或者没做好的人)但这真的是一个不错的成绩了对吧?


然而老板却仍然不满意,他觉得,剩下那 20%,难道就真的没办法了么?


安全工程师回答,有是有,就是成本贼高,得把业务直接访问数据库给拆开来,弄个中间层,中间层负责访问数据,业务每次请求都要带上用户的身份票据,根据票据权限来判断返回数据与否。这样一个数据加上中间层,大家都迁移改造出去,未来上新的业务,因为没有自由链接数据的权限,也没有自己设计权限的自由,所以就没机会再犯错误了。


微信的全程票据和 Google 的 Gmail 都是类似的思想。


那就整吧,于是吭哧吭哧开发票据服务,统一全局权限管理系统,一个一个接。


至于啥时候能接完就不知道了。


一边干啊干的,突然发现团队小伙伴越来越不开心,闹离职。原来,以前挖洞很爽的小伙伴,天天人肉看业务代码,审计出来的都是那些低级漏洞,实在是没劲。于是把能自动化的都交给黑白盒自动化审计平台,偏逻辑类的漏洞交给上面“水平越权治理”类的方法。


为了让业务可以多几个 QA 环节自测的必测项目,还得结合公司发布平台弄一些自动化的问卷,结合业务特性出推荐的必备测试项,于是一个“威胁建模平台”诞生了。


在这个平台上,结合业务历史漏洞、涉及到的敏感数据字段和流向,员工参加线上安全培训和考试成绩(尤其是某员工名下漏洞特别多的时候),综合给评分,建议对应的同学、管理者有针对性的提升自己的能力。


比如说,扫描器很多主动规避风险的 URL 资产不敢扫的,可以让业务自助授权强行扫,例行化,有些白盒审计出来不一定是漏洞(仅仅是不符合安全规范),提醒业务去按规范编码。


于是很多模糊地带的东西,通过打分评价激励体系,鼓励员工去做多一些配合让步,可能会进一步提升安全性。


但是这些都是一些运营的思路,如果老板还是不满意呢?


答案可能比较简单,招更多的人,做更多的自动化项目(比如 IAST),做更多的人工介入(比如 Google 的重点项目 Chrome,当年是有 4 个安全工程师直接在项目组内从头跟到尾,沙箱之类的安全架构设计和实现都是这几个安全工程师搞出来的)。


整套组合拳打下来,最终,公司的产品安全性一定是有提升的。而这就是一个典型的 SDL 运营套路。这个套路里有什么技术含量么?其实没有,只要站在“这个问题我依然不放过,我觉得其实是可以解决掉,哪怕是解决大部分也好”的角度,那很多团队都可以做到更好。


虽然我在过程中一直给这个团队增加难度(比如 SRC 的活动要求不间断的增加奖励的力度),但是每次大家通过分析新的问题聚集性,总能找到新的主要矛盾和解决方法。


我想,这就是我想表达的安全运营了。


它和技术无关,但又息息相关,每一次诊断的时候,没有扎实的技术基本功,其实是很难给出最合适的解决思路的。有很多次,小伙伴的诊断方向其实都可能有了偏差,也是有更多的小伙伴集思广益给拉了回来。


这样的安全运营理念,它会“产品化”么?可以被“平台化”么?


我觉得可能很难,但是基于这样务实的追求,做一些方便的辅助平台,或者外包服务,应该也是挺受欢迎的吧。


今天就到这,之后结合入侵检测、应急响应、IT 安全(BeyondCorp,你们有时候也叫做零信任或者无边界),我再分享一下个人的经验。


最 后,笔 者 如 是 说

嗯,最近团队在疯狂的招人。


如果你正经历着上述类似一个人的安全部的经历,有着不错的技术功底(能挖洞、会渗透、懂编程),也希望在一个相对大的平台(有挑战),做一些比较务实的安全防御工作,又或者哪怕是研究工作,可以试试来我们团队。


不看 JD 介绍,就看你个人匹配度,简历投递: zhaobizheng#meituan.com