阿里资深专家杭特:十余年目睹国内安全之“怪现状 ”
本文转载自云栖社区,作者杭特,阿里安全资深专家,在安全行业从业十余年,甲方和乙方公司都有经历。亿欧智慧城市对文章进行二次编辑,供读者参考。
随着网络空间成为第五空间 、社会基础产业全面互联网化,网络安全(或称广义的信息安全)面临的威胁越来越大, 对网络安全的人才需求也呈现出井喷趋势。 即使目前很多人可以自学成才,“网络空间安全”也成为一级学科,但根据《第十一届网络空间安全学科专业建设与人才培养研讨会》得出的结论,“我国网络空间安全人才年培养规模在3万人左右,已培养的信息安全专业人才总量不足10万,离目前需要的70万差距巨大。”缺口不小,但目前安全人才的历史存量和每年的增量,其结构是不是合理,是否反映了产业的需求呢?
阿里安全资深专家杭特在安全行业从业十余年,甲方和乙方公司都有经历。他认为,相对于欧美等发达国家,国内人才培养在结构和技能方面,有几个“怪现状”。
阿里安全资深专家杭特
重视“攻”, 轻视“防”
攻防就如同硬币的两面,哪一方面都不可或缺, 因此才出现了“以攻促防”,“未知攻,焉知防”之类的金句。 但现实往往不尽如人意,这些金句实际上也只做到了前面一半,后一半则明显薄弱,最终成了“虎头蛇尾”,“强弩之末”。现在安全人才在总数不够的前提下,防守人才更是极其匮乏,比例严重失调。表现形式很多。
情形1、 对于搞Web漏洞和渗透的人,八成以上不知道怎么搞SDL;
情形2、 技术类的文章,大部分都是攻击挖洞类的文章,至于防护方案,通常只有短短几句,“已将问题提交厂商”、“不要使用弱口令”、“及时更新系统”等等。
情形3、 一个个基础系统被攻破,2G有伪基站、4G也能被降级劫持、Wi-Fi不可靠、蓝牙不安全,操作系统天天打补丁还能被控制。安全Geek们无所不能的同时,也得保护好自己,把自己武装到了牙齿,“我小心故我安全”,但想做到独善其身很难,你的爹妈和亲戚朋友可咋办?别说那些高大上的,密码太多记不住,这么现实的问题,让岁数大的人怎么解?
小结: 攻击技术很重要,相关人才也要占领高地,高价值漏洞这样的战略武器一定要有,但这绝不是网络安全的全部。打个比方,相对于目前多方都有“NUKE”(核武器)的现状,造十枚还是百枚核弹并没有区别,反而是类似于美国的TMD(战区导弹防御系统)更显重要。我们有如此多的系统需要建长城来守卫,期待更多防守人才的出现和贡献。
重视“攻防”, 轻视“数据”
大部分业界从业者认为,安全就是Security,但实际上对应的英文单词有两个,我们先来区别一下(根据NIST CPS Framework的定义)。
Safety:确保生命、健康、财产、权益人数据及物理环境等方面不存在灾难性后果;
Security:内外部的保护,以避免无意或者未授权的访问、改变、破坏或使用。
之前网络安全大部分都属于Security的范畴, 但随着IoT和ICS 的出现, 动动鼠标也能物理危害人身安全,从而扩展到了Safety的领域。 由于Safety更注重能影响物理世界的安全,因此作为争夺“EIP”控制权的“攻防”是最为重要的; 而Security要重点保护的,其实是“数据”的控制权。
可惜的是,绝大多数的安全人才都把精力放在“攻防”上,认为只要拿到控制权,就能拿到数据,但事实真的如此?举个反例,不考虑物理攻击,现在iOS的指纹数据貌似还没有人能拿到,即使能完美越狱又如何呢?在这里笔者再引申两个问题,供大家可以思考:
问题1、 不借助硬件,有哪些领域的数据安全需求是和漏洞一点关系都没有的?
问题2、 不考虑可用性问题,一个系统给你root/admin就真的非常可怕?
小结: 安全要搞清楚保护的对象是什么,而这些对象也随着产业发展不断变化。“EIP”控制权的争夺应该更多的面向与物理世界相连的设备,而其它的场景,则应该重点关注“数据”的控制权。 数据已经成为DT时代的石油,是产生价值的新能源 ,如果还是用传统的漏洞思维来谈数据安全,是肯定做不好的,密码学久违的春天已经到了。
重视“单点、破坏”, 轻视“体系、建设”
安全有一个著名的木桶理论,“系统安全性的整体水位与最脆弱的组件水位相同”,绝大多数的人都在“集中优势兵力,从系统最薄弱的地方突破”,可是破坏容易建设难。当要保护的对象足够多、足够复杂,如何能成体系地进行安全建设,如何能将安全威胁收敛到可控的程度,是一件非常有挑战的事情,下面列举几个:
反入侵: 对于所有的企业,这都是个令人头疼的挑战。有句笑话,“世界上只有两种企业,一种是知道自己被入侵的,一种是不知道自己被入侵的”。反入侵需要非常体系化的架构来控制风险。很多企业借助众筹或蓝军模拟渗透找到某些脆弱点并完成修复,认为这样就能高枕无忧,这种做法只是暴漏了很小的风险,连标都没治,更别说本了。实际上SDL只是标配,WAF、RASP、各种监控、各种数据、各种算法,安全建设的任务艰巨……
供应链安全: 前几年APT热火朝天,各种0day满天飞,门槛也快速提升,攻防双方的日子都不好过。东边不亮西边亮,随着XCodeGhost的爆发,xshell、CCleaner、pip、nodejs接连中招,原来还可以这么玩?目前发现的例子都是事后,还有多少掩藏在冰山之下?目前还没有特别有效的防护方案,要么太重型,要么太晚,面对连规则都没有的目标,希望渺茫。试问有哪个企业和组织可以置身事外?别以为有源码就安全了,pip和nodejs都是源码,更别说还有算法级后门了。
防止钓鱼: 安全培训天天讲,可是社工这一关很多人就是过不了。别看对手low,效果还异常的好,毕竟明枪易躲,暗箭难防。
小结: 安全本不是平等的对抗,打开恶魔的盒子不那么难,但灾后重建却异常艰难。相对于“千里之堤,溃于蚁穴”的蚂蚁,业界更需要的是为生态授粉、创造自然奇迹的蜜蜂。
重视“技术”, 轻视“业务”
安全是个技术对抗非常激烈的领域,但这并不代表技术高超就能把基本问题解决的很好,黑灰产对抗就是个非常好的例子。作为一个产业,现在的黑灰产已经形成了一个完整的链条,每个环节都有大量的从业者各司其职。相比较那些神奇的0day,除了极个别情况,黑灰产使用的技术都是相对基础的。即使如此仍然有大量网站被简单的注入或者弱口令攻破,无数个人信息都在地下黑市被贩卖,如果没有徐玉玉案件引起国家重拳,现在的情况可能更为糟糕。商业上的薅羊毛也让众多电商网站承受资损并搅乱了市场公平,但行业里相关的人才却很稀缺。
小结: 有数据表明,黑灰产的市场规模已经和网络安全市场的规模相当,都是千亿规模。整个业界的技术支持配比是否应该向1:1努力?
重视“反向能力”, 轻视“正向能力”
很多人都是从渗透、逆向、分析漏洞入门的,其实这些都是反向能力,如果要达到相反的目标,也就是防止渗透、防止逆向、设计没有漏洞的系统,一种是“反反向能力”,一种是“正向能力”,两者并不相同。其实这个和汽车工业有些类似,早期自主品牌造车都是逆向起家,买辆样车大卸八块,试图造出差不多的产品,吃夹生饭的结果就是动力、油耗、安全性都与原型相去甚远。下面再举几个例子。
逆向与混淆: 逆向是二进制安全的基础,但对于很多公司来说,防止产品被逆向进而保护知识产权,是个硬需求。业界目前采用的常见手段就是花指令、防调试、执行流混淆、普通壳、虚拟机壳、白盒密码。除了白盒密码,其它的都属于“反反向能力”,虽然在现实场景中大量应用,但首次分析和二次分析的强度及有效度无法用数字来度量,虚拟机壳效果好一些,但通俗点讲就是对小白很难,但对专家不难。白盒密码属于“正向能力”的初级阶段,强度至少可以通过数量级(比如2^40)来衡量,但不幸的是,目前最好的白盒密码也撑不过28天(参考CCS 2017白盒挑战赛的结论)!美国已经开始高级阶段,至少10万美金的挑战赛还没人成功,东西方差距明显。
可靠软件: 如果要开发一个功能,并确保安全可靠,很多人意识里就那么几招,功能测试、覆盖率测试、黑盒fuzz、白盒代码扫描,技术高级点的再加上个符号执行,这些也都偏“反反向能力”,因为这些测试全通过了,也不代表是安全的。有些人可能会说“本来就没有绝对的安全”,但这些测试本质上并没有说明哪些是应该的、哪些是不应该的。而“正向能力”就是要解决这些问题,这也就是为什么别人有信心造出“无法劫持的无人机”、“功能实现正常的加解密算法和协议”。
Chrome与NaCl: 如果要在浏览器上运行第三方插件,对性能要求高,必须得跑x86机器码,但如何保护安全性呢?“反方向能力”基本就是inline hook、调试器监控异常、DBI、虚拟机执行,属于哪里有问题就去堵哪里的策略;“正向能力”就如同NaCl这种,确保生成的代码必须符合规范,并利用x86的体系架构,在加载的时候,只要通过验证就能确保安全性,其强度远超虚拟机。
小结: 精通反向能力,未必能做好正向能力。国内的反向能力与世界水平相当,但正向能力却实打实的低下,我们也应该开始重视正规军的建设了。
重视“人肉”, 轻视“自动化”
虽说安全的本质是人性的斗争,人的因素不可或缺,但目前大量的工作都是低级重复性的。比如漏洞分析和逆向,除了少数特别复杂和高深的对象,大部分就是纯体力劳动,以下的场景很普遍。
小结: 对于企业,如何才能让安全从业者从繁重的分析中解脱出来,更多的聚焦更有价值和挑战性的工作?如何能将部分能力沉淀到平台而不强烈依赖个体,进而更好的规模化、易用化?
总结
网络安全产业就像一个江湖,各色人等聚集。相对于欧美国家基础扎实(懂加密、会防护、能挖洞、擅工程)的众多名门正派,我国的人才更多的属于旁门左道(很多白帽子可能会不服气),因此在未来的人才培养和建设上,需要调整结构,鼓励更多的人去做“正向”的、结合“业务”与“数据”、“自动化”的“体系、建设”,才能解人才之渴,真正的为社会全面互联网化提供安全保障。
本文已标注来源和出处,版权归原作者所有,如有侵权,请联系我们。