创新沙盒，罕见领域分布的背后 - RSAC 2020 (1)
远离聚光灯低调登场，乍然亮相已占据舞台中心，形容可怖却拥有致命吸引力，令所有观众心怀惊惧无法直视仍全神贯注。黑天鹅，终于还是以出乎所有人意料的方式悄然来临又震动全世界。这个词被滥用做推广宣传已经颇久，炒作多了往往让大家误以为尽在掌握；然而其真正到来之时，市场依然表现出充溢的彷徨无助。
当然，对企业安全团队来说，并不需要投入一分钱预算去准备应对黑天鹅事件，因为投资回报率低到可以忽略。安全行业也可以从过去两个月的历程中汲取许多经验教训：例如，应急响应体系需如何完善，才能在面临突发大规模事件时，不至于被瞬间打趴并持续瘫痪；又如，快速果断隔离以阻止威胁蔓延，决策流程和措施是否必要，阻断点如何设置，被隔离的区域是否能实现局部自洽，或是必须有外部输入才能纠正等等。这些可借鉴的知识和诀窍便是热词Resilience所包含的内容，对高度网络化社会化的数字商业的安全都极其宝贵。此外，奢望侥幸躲过大势影响终究不现实，目前经济环境下，安全行业的发展也将承受重击。无论如何，自己多做一些功课，应对未来挑战便能更加从容。因此，今年RSAC系列文章还将继续，希望能给读者带来帮助和启发。
创新沙盒比赛，因为浓缩了高质量的众多安全创业公司而备受瞩目，入选者所代表的热点方向也被行业人士趋之若鹜。今年的十强名单公布后，各家报道都纷纷加以分析，指出从榜单构成数目来看，应用安全和SaaS安全占据绝大多数。虽然赛事组织者不满固步自封，努力创新求变，套路明显发生改变也是正常的，但市场趋势真的是应用安全要占据半壁江山吗？
过去五年的创新沙盒，评委会精心选择覆盖多个代表行业热点的赛道，几乎没有单一细分领域同时出现两家入围的现象发生，力求全面展示当前行业聚焦关注。拿去年做例子，我们可以看到的包括：密码学（同态）、主机安全、应用安全（代码审计）、云安全（审计）、身份安全、资产管理、API安全、数据安全（隐私）、固件安全、业务安全（反欺诈），典型的每个细分方向只有一家。而今年，如果只看媒体宣传文章，会发现除了一家钓鱼邮件检测、一家安全意识教育、和一家隐私保护延续之前的分布路数之外，居然同时有两家SaaS安全，而余下五家都在做应用安全。
当真如此吗？我们应该如何看待此变化？也许我们不应该急于作出结论，而是透过表象看本质，忽略每个公司两句话的简介，去深入观察各公司的具体产品特征，进一步思考他们是如何解决具体难题的，再来评判属于哪个赛道。
1
BluBracket
成立只有一年时间的安全行业新公司，往往很难看出其产品特点和优势。这些年来，特定安全问题的解决之道变得愈加复杂，直接导致研发和工程周期延长，才孵化仅一年就能推向市场的产品往往功能单一且竞争壁垒过低。BluBracket的创始团队在2018年离开了创立于2013年的Veradocs。Vera提供文档加密以达成权限控制，这个方向创业结果都不太令人满意。看来之前公司发展并不理想所以另起炉灶。
BluBracket的产品资料极少，官网介绍口号大而空洞：“BluBracket是软件驱动世界中第一个针对代码的企业安全解决方案。”这句话不知道美国同行中做了几十年代码管理和安全审计的从业人士会作何感想。产品的目标也是所有程序员团队管理者梦寐以求的终极愿望：“BluBracket让公司能看到源代码引入安全风险的位置，同时也能在不改变开发人员工作流程且不影响效率的情况下完全保护代码。”之前有位管理经验丰富的企业领导写道，每当听到有人给他描述过于美好的未来时，他总能感受到骨缝里不受控制油然而生的凛冽寒意和随之而来的战栗恐惧。
还是让我们脚踏实地看看其产品功能和界面吧。简而言之，BluBracket提供了两种能力：第一个模块CodeInsights可以认为是代码资产管理的一个子集；另一个模块CodeSecure描述有些混乱，包括发现代码中出现的各种硬编码的秘密secrets（密码和token之类）和防止代码泄漏，逻辑上有点八竿子打不着的感觉，临时拼凑痕迹明显。从其产品界面图中看不到两个模块的明显界线。
上图界面中，蓝图菜单可以让公司知道自己的代码分布在哪里，包括云和私有代码仓库。警告一栏有代码中发现的秘密和对外公开权限的代码库风险。以及拥有访问权限的用户列表。后台应该是通过服务提供商公开API获取的信息。
上图界面列出了代码库的详细信息，代码库的分类标签，拥有者账户信息。并没有看到BluBracket如何实现其宣称的“识别、避免、甚至阻止代码意外泄露或恶意盗取”的能力。从现有资料来看，产品功能有限，缺乏技术壁垒，成熟程度相对初级，支撑不起创始团队声称的愿景。
或许创始团队产品思路的萌生是受安全资产管理需求的启发，但笔者很难判断是不是伪需求。因为代码仓库都自带项目管理和权限控制，托管服务还会提供更多增值功能。如果是分开在不同区域和不同供应商的代码库，往往也是出于安全考虑而有意为之。这与传统天生散乱分布的服务器和端点资产有天壤之别，后者若有统一资产风险平台则能极大地提高效率。目前的代码托管与新计算能力平台有些类似，诸如Kubernetes，在设计之初便充分考虑到这些资产运维和安全运营因素。大型软件项目的代码管理十分复杂，效率和安全时刻需要平衡，所谓最佳实践也经过很长时间演化发展。代码安全性一直是研发企业关注焦点，但其安全保障职责严重依赖于组织架构、内部制度流程、以及管理条线，安全团队需做好长期运营规划和资源投入的准备。因此，BluBracket目标客户恐怕主要是重度依赖公有云并有小规模研发团队的中小企业群体，还要面临代码托管服务商的强有力正面竞争。不过在美国和欧洲市场，中小企业的购买力和付费意愿很不错，如果能微调产品发展方向，市场规模也有潜力。毕竟只有一年历史，武断一个创业公司的新产品是否前途光明实在是太早，或许BluBracket后劲十足也未可知。
读完上面的简介，让我们一起再反思把这家归属到应用安全类别里是否合适？显然，BluBracket的方向处于多领域交界的模糊地带，笔者认为其资产管理属性更强一些，肯定不能算应用安全厂商。
2
Vulcan Cyber
顺着资产管理的话题，接下来我们就看看另一个无法回避资产管理的场景：漏洞修补。听起来简单的打补丁任务，是安全运营中十分尴尬的工作，人力物力投入多不说，做得出色也难以用来炫耀绩效，出了纰漏可能会直接导致CISO下台。Vulcan正是致力要改善漏洞修复难题：“我们使用现代化的方式降低企业网络风险。从检测到解决，我们动态协调漏洞修复流程，实现大规模自动化。”
有意思的是，这家公司打算怎么做呢？从应用安全的范畴来看，它不做很多事情：首先，它不挖漏洞，别指望能早一步发现自有漏洞；其次，它也不扫描漏洞，已知漏洞得靠其它工具和产品去发现；第三，它也不维护漏洞库，不研究漏洞原理、级别和影响，自然也查询不到关于漏洞利用的独有信息；第四，它也没有阴影资产发现能力，私搭乱建的应用里的漏洞管不了；最后，它也不负责打补丁，不管是什么资产都得使用自己系统平台独有的更新体系。所以，不能简单去理解公司官方宣传中的“从检测到解决”这句话，事实上，它既不检测也不解决，只帮助客户把流程管理好，价值贡献在于提高效率。关于提高安全运营效率的重要性，请参见本公众号2017年初文章《从创新沙盒看“效率”将成为评估安全产品的首要标准》。
所以，Vulcan不应该算作应用安全类别，它实属自动化编排方向的创业公司，竞争对手是SOAR厂商。是的，应用安全入围者又少一家。
让我们来看一张其产品支撑自动化的Playbook界面。很多发送报警通知和工单的，沟通流程必不可少，但是能多自动化一步也比没有强，积少成多就能显著提高效率。
上图中Vuln Source来源是什么呢？如下图界面所示，Vulcan内置提供很多产品的接口，检测有Qualys、Tenable等，解决有Ivanti、ServiceNow等。
不得不羡慕美国对创业公司友好的2B生态环境。上届冠军Axonius自己没有网络探针或端点Agent，而是通过其它产品API获取资产信息，意味着客户想用好其产品必须已经购买大量其它厂商的设备或软件，还能有额外预算去购买整合各方日志的专用资产管理产品。国内现状，从有限的安全预算中争取自己产品的合理份额，是每个创业公司销售团队都担负的艰巨任务，僧多粥少是行业普遍感慨。严重依赖其它已部署安全产品才能提供价值的市场策略，现实中的推广销售难免会遇到巨大阻力。在有些企业中，多雇两个员工去盯着资产管理和漏洞修补之类任务，比花钱采购辅助用的标准化产品，更容易得到领导的认可与批准。
笔者十分赞同Vulcan Cyber所宣传的理念，一些常见的行业误区需避免。漏洞修补只盯着最新最热的头条显然是不够的，突击打补丁是有效的，但持续监控也必不可少，老旧漏洞就算之前排查过再出现在新业务系统版本中也不稀奇，而此现象会持续增加安全运营团队的工作负荷，如果能有预算购买部署明显提高效率的流程自动化平台，自然帮助巨大。不过大家也别期望过高，传统行业的线下项目管理团队也会面临类似问题，每次变革都需要反复评估风险、沟通执行策略、确定验收标准等，调整好心态没必要发牢骚抱怨。打补丁通常被认为是变更管理的一个组成，牵涉到复杂业务的变更管理有史以来都是老大难问题，无论是在什么行业，即使上了自动化平台，也要考虑风险和回报，不可能免除沟通和评估等重要环节。
我们继续看些Vulcan Cyber的产品界面，下面是漏洞相关的。
SaaS服务的好处之一就是可以集中处理漏洞信息库，多个来源汇总由Vulcan做了，否则每个用户自己维护更新也是工作量相当可观。不过有好处自然也有问题，某些大型企业自有漏洞研究或外购其它厂商的独有漏洞数据，受各种规章制度限制以及保密协议约束，就没法加进系统里统一查询了。
下面是资产相关的用户界面，可以看到从不同厂商处采集汇总而来的数字。有意思的是，Chef和ServiceNow登记的资产，还没有被扫过漏洞，其实漏洞扫描大厂的产品也有接口导入资产数据的，不知道是不是Vulcan故意弄成这样以显示其优势。
无从得知Vulcan公司名称的来源，是StarTrek还是希腊神话？自己长得丑有残疾还娶了美貌女神维纳斯的Vulcan伏尔甘，靠才智和勤奋帮众神打造装备，还有那著名的拴住普罗米修斯的锁链，这很容易被当成个典型的励志故事，其婚后生活也为艺术史上众多璀璨的传世画作贡献了香艳素材。
3
Tala Security
我们来看万众瞩目的创新沙盒究竟希望找到什么？类似这种拷问灵魂的问题，很容易给出貌似正确但浮于表面的答案，喧嚣热闹总是被津津乐道，公司宣传标语也朗朗上口，产品方向拿来做热点追捧，主办方也有意推波助澜成市场部门的盛筵。但对于管理者和技术人员来说，嘈杂内容往往会变成影响决策的纷扰，买椟还珠正是此场景的传神写照，我们需要抽丝剥茧找到真正值得关注的创新价值点，才能不虚此行满载而归。
每次坐在RSAC会场中，笔者最希望看到厂商三个创新之处：发明了让人眼前一亮的创新技术？使用了与众不同的创新方法去解决问题？创新了异乎寻常的经营壁垒用以巩固竞争优势？例如，去年的ShiftLeft使用代码属性图CDG标示控制流和数据流以发现漏洞就是创新技术，而大前年的Phantom依靠通行即插即用playbook自动化响应流程以提高效率就是解决问题的创新方法。
带着这三个问题去分析Tala Security的产品，结论就是它可以归入让笔者十分失望的入围者那个类别。它的技术没有任何创新，Content Security Policy和Subresource Integrity实质都是白名单，对抗某些Web攻击的效果不错，但目前已被广泛支持和使用，无法当作独立新安全手段向大型企业客户推广。它号称使用了先进AI技术和威胁情报，可技术现实是，SRI不需要AI和威胁情报，CSP用不上威胁情报，而AI辅助生成CSP恐怕也是基于简单的统计，谈不上什么独创高深算法。运营任何白名单手段，需要处理的难点就是例外权限，与使用场景紧密相关，目前技术上也没什么特别合适的好办法。至于经营壁垒，任何一个做Web安全的公司，无论是WAF还是RASP还是代码审计，都可以在现有产品中轻易加入类似功能。当然，这类公司并不是没可能成功，如果销售能力出众也有机会，但那并不是笔者想在创新沙盒里学习的对象。
过去三年，Magecart已经成为包含支付功能网页的第一号威胁，PCI等合规机构也专门给出了防范指引。每一个国外的Web安全厂商都拿阻止Magecart攻击作为宣传重点，但每个厂商解决问题的思路和落地手段都不尽相同，如果用户轻易相信存在银弹一劳永逸那免不了持续中招。常见的Magecart攻击表现手法PII Skimming、Card Skimming、Ad Injection、Formjacking、Clickjacking、Screen Scraping、Keylogging也许会被某一种浏览器保护技术所屏蔽，但是黑产组织总是想方设法找到新途径。例如去年夏天，大量S3存储桶被扫描是否为public权限，里面的JavaScript都被添加了恶意代码，此时即使上了严格CSP也有概率被污染。随着serverless等新架构愈发流行，问题暴露得还会更多。Tala的产品思路过去两年没有升级，紧抱着CSP和SRI不放的同时没有任何横向扩充，这是个很危险的信号：IT领域创业的一个大坑就是大厂出来的产品经理墨守成规不知与时俱进，吃老本的后果便是三四年后发现已被技术革新所抛弃，安全行业尤为突出。
Tala产品主要依靠分析网站元素来生成CSP和SRI，如下图界面所示。坦白讲，这种方法自动构建白名单，如果强行启用block功能，往往会造成一定数量的误杀，是不是能承受就看业务了。
启用CSP违例报告功能实时分析和警报。
过去五年，我们也在创新沙盒中看到过一些吸引力不高的十强入围者。笔者一直的观点都是，为了全面体现安全行业多个细分领域的发展状况，安排每个小赛道领先者出场是有必要的，即使拉低了整体竞争水平也在所不惜，这状况也是受不少观众认可并欢迎的。但Tala在应用安全已经有明显更好厂商入围状况下还能占一席之位，委实令人大跌眼镜，它在竞争激烈的应用安全市场中注定是个凑数的角色。
4
Sqreen
继续上面的内容，为了佐证CSP是很容易实现的保护措施，没有技术壁垒，让我们分析Sqreen之前先看一眼其包含CSP配置的界面。
上图的Sqreen界面概括展示了其产品提供的防护功能选择。必须要注意的是，Sqreen在不同平台不同模块中提供的功能有区别，上述列表并非全部覆盖。
本公众号去年圣杯文章写过，2015年RSAC创新沙盒冠军Waratek，早已转向RASP与WAF结合，类似厂商还有Signal Sciences以及最近被收购的Shape Security。而Sqreen于2015年成立后一直做RASP，去年10月份才正式推出In-App WAF。读者也许已经读过一些关于今年创新沙盒的文章，了解到In-App WAF是Sqreen大卖点，但大家知道什么是in-app WAF吗？笔者不知道也不懂这个新名词。也许此公司创造了解决问题的新方法？最直接的学习办法就是去研究其产品界面。
上图是In-App WAF的配置界面，从功能上看起来与传统WAF并无区别。而下面是RASP的配置界面，也与其它厂商RASP并无不同。
所以看起来Sqreen也同样面临美国市场应用安全厂商高度同质化的尴尬局面。接下来具体看看其in-app WAF的内置规则，以SQL注入和NoSQL注入为例：
很传统的正则表达式规则组，没看到什么特殊的创新。大家也许注意到了，Sqreen也集成了libinjection。
看下来感觉所谓In-App WAF这个名称颇为突兀奇怪。在某些场景下，传统主机WAF也可以算是in-app WAF，例如之前跟Apache HTTP Server集成紧密的ModSecurity，或者是基于OpenResty的各种WAF，因为应用就是Nginx+Lua写的，算是应用内部的一个模块。为什么要创造这样一个名词呢？另外，这些列出的in-app WAF能力，也可以直接集成到RASP里，有必要单独搞一个模块名称出来吗？也许是受到其它应用安全厂商RASP+WAF解决方案的挤压，又无法很快推出独立WAF？后来突然间笔者恍然大悟，有分析师造了个类别名词in-app protection还开始发报告，于是一切线索便自动串联起来，这种互相配合的对双方都有利的生态动作在市场上也是屡见不鲜。
感兴趣的读者不妨亲自去试用Sqreen的产品，至少目前看来不过是中规中矩，功能亮点不多。笔者希望在展会现场能亲手试用并仔细问问其团队成员所谓in-app WAF到底有何技术壁垒值得大书特书。
受目前工作状况的影响，笔者抽不出更多时间在本篇文章中详细分析Sqreen的具体功能了，以后有机会再写。下次再加上主要竞争厂商的横向功能对比，阅读效果应该不错。
每年创新沙盒入围者都有几家让笔者十分推崇，可惜的是，本文写的这四家并没有令人惊艳的感觉。
深入分析创新沙盒入围者，大家总是会觉得产品未尽全功，有各种能力上的缺失，遗憾为什么不能做到更好。这想法未免冤枉了创业团队，资源总是有限的，做到近乎完美的产品是不可能的。安全产品研发更像马拉松长跑，光有个好主意显然还差得很远，需要长期持续迭代优化的工程能力；按照规划路线合理分配体力，比昙花一现般的短距离冲刺更加重要。由于时间和篇幅的限制，本文只是浅尝即止。敬请各位读者关注本公众号后续RSAC 2020文章。
