吐槽系列(二):安全行业近五年之怪现状

阅读量    253023 | 评论 2

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

转载:安全村 作者:Lancer

印象中大概是16年前后,安全行业迎来了名副其实的春天:4.19讲话后,嗅觉敏锐的风投资本纷纷挥舞着钞票,开启了安全“淘金热”,大量资金的涌入,让整个安全行业被动地迎来了“创业潮”和“创新潮”。同时,VC资本对安全企业及其核心团队的考量,以及给安全行业带来的“互联网玩法”,例如流量为王,例如裂变推广等,也刷新了安全产业界的认知:原来自己错过了这么多暴富的机会。于是乎,安全有了“实现一千个小目标,赶超小龙虾”的雄心和愿景。

几年过去了,安全产业看着形势一片大好,政策利好、产业升级、领导视察、央媒报道、投资纷现、上市圆梦、会议刷屏、人才济济,可谓“日有一新、月有一进”。特别是这两年的“HW”这个大IP,乙方各尽其能,堪称盛宴。

然而,繁花之下,小龙虾却离我们越来越远。(注:16年小龙虾总产值1466亿,19年已达4110亿,单养殖小龙虾就有710亿,而安全产业貌似仍在向700亿目标努力。)经过近5年政策推动下的野蛮生长,安全行业似乎并没有像其他行业那样引来爆发,相反却有些乱象纷呈、浮躁不堪。

一年前,笔者在村里发了一篇《吐槽系列(1):安全热词造词填词姿势大全》,算是吐槽了一把。然后就窝在单位专心搞事,在经历了被各种产品坑到欲仙欲死、头发日益稀疏的一年后,趁着Bruce总的大魔王花式催稿,在原文的基础上再来吐槽一把,以发泄下心中的怨念,挽救下我的头发。文中所述种种吐槽,如果真有雷同,肯定不是巧合,欢迎对号入座,大家心照不宣。

 

一、造词车祸现场:追热度频造新词,运用之妙,存乎一心

造词这个事,实际源于早期(当然现在也是)国内向国外同行学习先进理念和技术的时候,连皮带骨做复刻的顺带产物。一个好词,既能清晰地表达自身产品的功能定位,又能从骨子里透出一股国际范,还可以表达自身处于某一个时代浪潮的顶峰,一举多得。

然而,当安全界风向标Gartner和RSA开始打造安全业的“热词”榜,诞生诸如年度N大安全技术,年度安全热词之后,国内追热度、造热词、强行挤风口(名义或故事上的)的情况就愈演愈烈,甚至于Gartner或者RSA前脚刚发布一个热词,后脚就有一堆类似的新词如雨后春笋般地涌出,而且还都有对应的产品一条龙。这足以让远隔千里的国外产商对我们的产品创新能力和研发能力叹为观止,更是让大大小小的投资人和领导感慨安全产业未来可期。而Gartner和RSA貌似也受到了国内追捧和推崇的激励,打鸡血一般地刷新各种新名词、新概念,走在了概念创新和名词创新的最前列。(实际大多是换汤不换药,甚至前后矛盾。)

于是乎,在近几年大大小小的安全会议上,笔者总能在大屏幕的PPT中看到一连串的大写英文、大小写英文,甚至中英双语的新名词,如果旁边不加上解释,你都猜不出来是啥意思。而且,越是高端,越是人多的会议,PPT上的新名词越多,以至于都没有足够的空间留给名词解释了。甚至于,出现了不同厂商之间造词重合却词义不同的“撞车”事件,其尴尬程度堪比国内女星红毯“撞衫”,其中姿势,令人瞠目。以下就重点讲几个栗子,博君一笑。

说到造词,X系列是最常见的手法。一般来说,X大多是N(Network)、H(Host-based)、E(Endpoint)这些,后面挂接类似DLP、IDS、IPS这些常见产品或技术的缩写词时,大致都能明白说的是啥。但是,最近看到不少碉堡的新产品和新技术,其缩写名词堪称魔幻现实主义,生搬硬套之经典。比如:

1、XBAC系列

我们都知道RBAC(基于角色的权限控制)和ABAC(基于属性的权限控制),当然还有IBM的LBAC(基于标签的权限控制)。虽然,个人认为标签(Label)实际也是属性(Attribute),但是IBM爸爸说了算。因此,国内不少厂商在设计、宣传自身权限控制产品和技术时,基于中文语义,诞生了不少XBAC类名词,例如:

1)基于流程的权限控制—PBAC;

2)基于任务的权限控制—TBAC;

3)基于本体的权限控制—OBAC;

4)基于行为的权限控制—BBAC;

5)基于数据分类的权限控制—CBAC。

但是,英文单词只有26个啊,XBAC多了总会有撞车的,加上英文的同义词也蛮多的,于是乎,在我们的PPT中,就可能出现以下几种情况:

基于标签的权限控制既可以是LBAC(Label)也可能是TBAC(Tag);

基于行为的权限控制既可以是BBAC(Behavior),也可能是ABAC(Action);

TBAC既可以是基于任务(Task)的,也可能是基于标签(Tag)的;

RBAC既可以是基于角色(Role)的,也可能是基于规则(Rule)的;

PBAC既可以是基于流程(Process)的,也可能是基于特权(Privilege)的,或者是基于策略(Policy)的;

ABAC既可以是基于属性(Attribute)的,也可能是基于资产(Asset)的,还可能是是基于动作(Action)的,更魔幻的可能会是基于授权(Authorization)的。

当然,可以尝试更长的前缀,这样的话可用空间就更大了。比如这个,eIDBAC—基于公民电子身份标识的权限控制,或者是这个,AIBAC—基于人工智能的权限控制,还有这个FaceBAC—基于人脸识别的权限控制,最新见到的是ZTBAC—基于零信任的权限控制…像笔者这种记忆力差的,真的记不住。

2、XDR系列

这个系列最早,也是最为人熟知的就是EDR( Endpoint Detection and Response)。记得在14年的时候,Gartner就将EDR列为年度十大安全技术了,也算是XDR中最早出来混的。DR=检测与响应,这等天赐的万能造词组合,大家怎能错过?最开始呢,还是比较矜持,EDR也就变成NDR(Network),也算说得过去。到后面,出现了TDR(Threat)、MDR(Managed)、CDR(Cloud)、ADR(Attack)、DDR(Docker)、IDR(incident)、AIDR(AI- driven)、HDR(Host-based)、ZDR(Zerotrust)…哦,对了,还有两个新EDR:一个是邮件检测与响应(Email),一个是突发事件检测与响应(Emergency)。

有鉴于XDR的超级适配性,在各类产品宣传材料或会议PPT中,产品矩阵图或是技术创新介绍中都充斥着大量的新造“XDR”。当然,从实际来看,只要对应产品有告警界面和“处置”按钮,“XDR”之名也算是“名副其实”。

笔者见过最多的是某厂凑齐的“十八罗汉”XDR产品矩阵,上述举例中大部分素材均来源于此。而且个人觉得,只要我还能在安全行业活得再久一些,总能见到“三十六天罡”和“七十二地煞”XDR。

 

二、安全填词游戏:论如何强行适配热词并做到包治百病

先说下造词和填词的区别。造词,可以看做是基于一个已成行业共识的缩写词,根据语义(英文的,或中文的)做延伸创造新的缩写词,并期望着这个新词能成为一个热词。而填词,则是将行业兴起的热词引进到自身的技术体系和产品理念中,并使之融会贯通。因此,相对于纯粹基于语义的造词,填词对产品经理和售前专家们的要求更高,一是要有足够的知识广度与深度,较强的技术理解能力,才能从简单的定义和介绍材料中快速地理解热词的技术本质和核心理念;二是要有丰富的从业经验和前瞻性,能判断某个技术热词是否真会成为未来的趋势,而不是某个昙花一现的“天坑”;同时,还要有一套逻辑自洽的理论,将热词与自家产品紧密结合,以体现自身产品的先进性和前瞻性。这就是我们常说的要:看得明白,想得通透,说得清楚。

然而,理想很丰满,现实很骨感。随着业务的快速扩张,资本方的造势压力,老一批技术骨干的隐居幕后,新晋专家们的拎包入行等等因素,加之安全行业在“向互联网企业学习”热潮中学到了一些简单粗暴的市场推广和品牌营销手段,“填词”已经变成了安全技术热词的无限制滥用。下面就是几个典型例子。

1、态势感知SA(Situational Awareness)

如果统计这四五年中,哪个安全技术热词被“填”的次数最多,无疑就是“态势感知”了。大大当年一篇讲话,彻底带火了SA。直至今日,你能数的出来的安全厂商,十个里面有九个有一款主打的态势感知产品,剩下一个有不止一款。

然而,深入去研究这些产品后你会发现,这些产品大多只是披着“态势感知”这层皮的检测产品,实际还是老一套的检测探针加可以做统计的管理后台。而在交流后,你还会发现,大部分厂商的售前根本说不清楚什么是态势感知,什么是认知、理解、预测模型,还有笔者从未听到专家们提及的,最重要的反馈机制。专家们只会向你反复强调:我能发现资产,我能统计漏洞,我能看到告警,我能接别家的日志,我绝对能帮助你感知所有的安全风险和攻击事件…

此外,还有某些厂商,将NTA类产品冠以“态势感知”之名,一副只要有流量即可包打天下的神情,也是令人哭笑不得。更有甚者,把基于redash或Kibana改的告警Dashboard,最多再加个地图图层和biubiu地图炮展现,也叫做“态势感知”。

而随着某年度大型线上真人匿名交友活动的逐年升级,“态势感知产品”更是在专家口中变为“神器”级别的产品。然而,据笔者所知,多数被抓到的小伙伴们,大抵用的都是盘外招,“态势感知产品”到底如何,没人说得清楚。

2、安全编排与自动化响应SOAR(Security Orchestration, Automation and Response)

SOAR是Gartner在2017年重点推的概念之一,而在更早的Arcsight当道的时候,SOAR技术实际已有较成熟的应用和理论基础。而SOAR成为热词的原因,一是Splunk用3.5亿美元收购了Phantom,刺激了大家的神经。二是Gartner分析师对SOAR做了相当出色的理论包装。三是国内近年来对Gartner各项排名和报告的追捧,很多甲方也很买Gartner的账。于是乎,各家厂商纷纷上马SOAR,或是单独产品,或是与SOC/SIEM集成。

但是,就笔者接触过的几家最早推出SOAR产品的厂商来看,SOAR也被“填词”地厉害。很普遍的一种做法,就是把原来产品的自定义规则功能模块改了个看似是工作流的页面展现形式。看上去的确高大上,但只要问细一点,或是上手操作一下,模拟下可编排的复杂场景,基本就麻爪了。

此外,建议厂商的产品经理们先好好理解一下Phantom官网对编排的官方介绍的第一句话:“Phantom 灵活的应用程序模型支持数百个应用程序和数千个 API”。就冲这句话,推销自家SOAR产品时,先想想自家产品有没做到全面支持,自家产品是不是做到了API化再说吧。连自家同一产品线的产品都能做到因版本不同而数据格式互不兼容的,或是一个端点产品无法对外提供API接口输出告警和日志的,谈什么SOAR?

当然,还有抑制不住自己的发散思维的。比如,有将各种算法也加入到自家所谓SOAR模块中的,不但可以选择一大堆的“算法”,而且可以选择一大堆的“算子”。当问到怎么用,用于什么场景,效果如何时,答曰:只是给自己工程师用的而不是给客户用的,很少会用到,效果棒棒的。这种回答蕴含的猫腻和语气中透露的无奈,其真实情况不言而喻。

从笔者看来,对于SOAR这种极度考验行业或企业生态化水平的安全产品而言,国内安全行业这种以“零和博弈”为主的产业现状,除非监管机构或是两大云巨头出手整合,否则几乎不可能做到类似国外IACD、Splunk、Qradar、AWS、Azure等SOAR类产品的成效。而在大型互联网与金融企业中,SOAR的根基—安全的自动化编排,其中的“剧本”大多都是面对各不一样的定制化场景,“动作”则要面对的是外购与自研混杂的工具体系,以及各不相同的安全权责分工。
这种情况下,外部通用产品很难适用,即使是用也有一定的使用门槛和习惯培育周期,强行推广过程中可预见地得踩无数的坑,这还不算后续产品自身的和关联安全工具的维护和运营成本。因此,个人觉得,如果SOAR所需的各个基础条件都能梳理清楚,那么,有能力的甲方宁可自己开发,还能捞点创新绩效,干嘛在经济寒冬期花口舌去说服老板掏钱买产品呢。

3、网络威胁情报CTI(Cyber Threat Intelligence)

除了前面2个,CTI也是近几年的“填词”热门。相对前面2个词填起来还要些基础能力和想象力外,CTI的填词方法更为简单粗暴。

最典型的方法就是“换皮肤”,把产品中普遍存在的黑名单的名字改为CTI或IOC,瞬间就变成了支持CTI的厂商和产品。至于什么情报的采集机制、传输机制、数据模型、聚合机制、分发机制什么的,安全村、安全内参、FreeBuf等都有大量材料,随便摘一点理论,抄个架构图,加上一句“这些都是内置的”,就能对付过去。反正对于不太懂CTI的用户而言,最终输出的到底是IOC还是黑名单,看上去真的没啥区别。

另外很有意思的一件事,我碰过某厂商的售前,说自己的SOC产品接入了自身独有的IOA指标。然而,在我详细了解后才发现,所谓的IOA指标,实际就是一个snort规则库加Yara规则库,而其中的规则与网上可公开下载的相关规则库重合度极高。这种对IOA的换皮大法,也算给笔者开了眼界。

顺便说个题外话,恰巧行文前,在某年度大型线上真人匿名交友活动中,见识了如何被恶意标识的社区情报曲折离奇地误伤到,有点哭笑不得,又有点怨气。辛苦努力,差点清零,难道这年头,做情报的都不审核了么?另外,也正好看到瘦总讲情报的一篇文章,有提到IOC注水的事。这个槽点,后文讲POC时再说。

4、MITRE ATT&CK™

说到最近安全技术热词的当红炸子鸡,那当属ATT&CK。在我理解,ATT&CK并不是一项技术,而是更接近于与NIST提出的SCAP体系类似的一个知识体系,里面应该会包含语言类、枚举类和度量类的内容、定义和方法,以模型、机制为主。同事,ATT&CK提供了一个开放社区,让学术、产业界每个感兴趣的人都能参与进来。这种体系建设与运作机制是鹰酱的惯用方法。

然而,在近一两年不少安全会议中,笔者碰到的很多厂商,甚至某些甲方,都在宣称自己采用了ATT&CK技术,并在自身的产品宣讲PPT中将ATT&CK作为一项关键功能模块大书特书,大谈自己完全采用了ATT&CK技术,因此任何AP攻击都能检测出来,绝不会有遗漏。自谦曰国内检测能力我认第二,看谁敢认第一。且不论大家对APT的定义仍是众说纷纭,单这种歪曲ATT&CK本意的填词方式,也算是让人哭笑不得。

忍不住开个地图炮:真心希望各家厂商好好培养和锻炼自家的售前和专家们,很多概念、理论、技术并没有太多门槛,介绍和分析文章网上到处都有,看都不看一下就出来瞎吹胡吹的,不仅丢自己的人,也败东家的脸。

 

三、安全战忽局:安全专家在线忽悠,以小博大,紧张刺激

战忽局,按照知乎上看到的说法,是“以国家安全为目标,通过忽悠,误导,渗透等手段促使敌对势力对我方实力与格局进行错误判断,从而占据战场主动地位,潜伏实力,蛊惑敌心。发展至当代,其作战理论有了显著发展,搭配因果律武器(天火降航母),灵活运用天象学(雾霾防激光),生物学(海草缠潜艇)等当代基础学科,可谓我军克敌制胜的法宝。”如今,笔者在大大小小的安全会议和技术交流中,深刻感受了安全战忽局的威力:感觉就像在线菠菜一样,循循善诱,步步惊心,一朝不慎,就成了被忽悠、蛊惑的对象。

1、我说有的并不代表着它真的有

近几年,笔者前后大约收集近千份讲产品、讲理念的PPT,和多个厂商也交流过近百场。因为几份工作都需要对接和测试产品,或是做集成架构设计,所以常常抓着产品架构图看,或者追着问些架构设计上的问题。于是乎,由于过于“好学”,经常不经意地发现一些架构上的小“猫腻”,并因此踩坑无数。

一种“猫腻”是宣传的架构图上画着Kafka、Flink、InfluxDB、ES、Neo4j等等,甚至为了体现研发能力的强大,宣称自己定制开发了一个绝对牛逼过原版的XXlink、XXDB、XXSQL、XXES…然而,当你信以为真并真的开始用起来的时候,kafka消息堆积、Flink作业异常、InfluDB数据丢失、ES数据倾斜、Neo4j节点值为空等各种让人无语的问题接踵而至,而且大多需要研发排期修改,一拖就是几周、几月,甚至大半年,让你不禁疑惑,到底甲方是爸爸,还是小白鼠

此外,笔者还碰到过架构图胡画一气,明显就有问题的。比如,将Flink画在ES后面的,让人好奇Flink到底用来干啥;。又或者一张架构图里Kafka、Redis、RabbitMQ、Spark、Flink、ES、MongoDB、MySQL、InfluxDB、Neo4j全家福的,让你惊讶这是何等复杂的产品和架构,是要造个卫星上天吗?

当然,这还算好的,见过最夸张的就是架构图里画着有,售前过来也说有,产品部署也貌似有,等到真正要去用的时候(比如kakfa),那就是真的没有,或者说无法对外开放,让你忍受时断时续、老丢数据的syslog,或是一用就挂的API接口。这种做法,与菠菜网站套现后跑路又有啥区别?

2、走过最深的路,就是POC的套路

说到POC的套路,很多甲方都会想起一幕幕的血泪史。产品测试的时候各种牛逼,各种OK,无论是你拿什么指标,什么功能去测试,总能让你满意。但一到正式使用,各种不行,让你怀疑人生,感觉像是进入了一个“杀猪盘”。为啥频频甲方会中套路?安全POC为啥测不出真实效果?在笔者看来,核心就在于:信息不对称。

绝大多数情况下,一个安全产品就是一个黑盒,盒子里有啥,实际你是不知道的。而由于安全领域的特殊性,大部分安全产品的核心不在于功能,而在于知识。这些知识在很多情况下都是非公开的,导致甲乙双方的信息不对称。而安全产品的POC套路,大多源于在产品测试中如何有效地利用这种信息不对称优势。

典型的例子,就有情报的测试。瘦总的《从IOC的一些真相谈对其的评价标准 》一文中,提到IOCs的几个参考指标中,日均更新量、条目数量都很容易注水,建议用发生命中的独立IOC数、命中的总次数、非开源IOC的占比这三个指标来衡量情报IOCs的全面性。然而,在笔者获知的某个真实测试案例中,某厂商居然在自己的测试系统中用随机碰撞命中再随机标记威胁类型的方式来刷命中数,并被竞对当场抓到。由此可见黑盒模式下,我们以为有用的测试方法,也不见得躲得过各种套路。此外,还听说过为了保证威胁检出率,让自家或甲方小伙伴在模拟攻击流量时,于payload中暗藏特定的tag,确保一抓一个准的。或是有专门的测试机,实际性能比宣称性能高上数倍的,等等等等,诸如此类,防不胜防。

最后,只能提醒一下甲方同学,最好是自己写测试用例且用例尽量全(正反向用例都要考虑),尽量做到测试时间、过程和内容对参测厂商黑盒,用套路反套路,方有可能避免被套路。

 

四、这是一个“比烂”的时代:不需要做好,只需要证明别人更烂

最后这节,是吐槽产品的。此文写成时,正值某年度大型线上真人匿名交友活动第二阶段如火如荼之时,笔者所在单位虽不在活动名单中,却也从各个渠道获得了各种信息。其中最多的,就是每天的安全产品花式爆洞环节,以及后续的在线撕逼和飞翔的小道消息。在吃瓜的同时,作为一个安全从业者,却又深感悲哀。

从何时起,安全行业变成了一个“比烂”的行业?从何时起,安全产品成为整个甲方安全体系里面最不安全、最不可控的环节?从何时起,一个安全产品的好坏和口碑,是靠证明别人的产品更烂来评价的?明明各个厂商有着大量的攻防专家,有着丰富的理论基础,还到处指导、协助甲方去规划安全体系、做安全攻防演练和测试、建SDLC和Devsecops,却搞不定自家产品一个简单的SQL注入或是越权?除此之外,肆无忌惮地爆竞对的产品漏洞,将用对方产品的甲方置于无防护状态,心惊胆战。用这种方法来证明自己能力强,别人烂,又怎么能让甲方对乙方能报以更多的信任?

这或许就是为什么阿里、腾讯、华为、百度、美团等大厂在大部分情况下宁可招高水平的人自研大部分安全工具,也不愿用外部产品的原因之一吧。

 

写在最后

造词、填词和忽悠,在当前安全行业厂商所面临的生存、资本压力下,从商业角度,笔者表示很能理解,毕竟十多年混迹乙方,自己也干过这些事。然而,比烂这件事,算是与“安全为国,不忘初心”的宗旨相违背的。

安全,和芯片、机床这些东西一样,无论外表如何花团锦簇,如何粉饰太平,最终是要拉到战场上见真章,对外打硬仗的。无论热词怎么造,怎么填,也无论怎么忽悠,内功修炼还是得扎实,该干的事还是得干好,比烂是千万要不得。真不希望等到真需要我们为国效力时,却只能喊一句“臣妾做不到”。

所以,希望大家少一点浮躁,多一点踏实。这个行业,毕竟我们还是要待很久的。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多