前天，Verizon宣布收购2016年创新沙盒入围公司ProtectWise。上周，PANW以5.6亿美元收购Demisto，继2016年创新沙盒冠军Phantom被Splunk收购后又一自动化领域的成功实例。毫无疑问，自动化已经成为安全必备能力，正如笔者2016年下一座圣杯文章所写的趋势。如果2015年开始做自动化，执行得力，只需三年时间就可能成为收购目标。在成熟市场，创新公司被收购退出一般有两种原因，一是新技术或新产品在市场上领先，且与收购公司的能力形成互补加强，二是新产品已经相对成熟，规模明显超过第二三名许多，行业领头羊地位难以动摇；不管哪种收购，目标都是垄断细分市场以期未来增长。反观国内市场，以短期增加收入数字为目标，其中差距可见一斑。

上篇提到笔者看去年安全市场增长并不乐观；本篇发稿时已经实锤，上市公司增长放缓对行业是次重击。此时，健康的收购生态，对安全创新大有裨益，愈发显得重要。创新沙盒历史上也有很多成功收购，例如Phantom、Cylance、SkyHigh、Appthority等等。让我们一起来看看本届入围者有哪些存在被收购可能。

CloudKnox

CloudKnox提供统一的混合云身份特权生命周期管理平台，以显著降低凭证丢失、误操作、和内部威胁所造成的风险。最小化权限、自动化、基于风险、动态更新，一直是安全从业者努力的目标。

CloudKnox的产品思路有一条最根本的假设判断：基于角色的访问控制RBAC，会不可避免地造成用户获得比实际需要更多的特权。此判断是否正确，见仁见智。于是CloudKnox提出新概念Activity-based Authorization，基于活动的授权，持续监控权限使用活动来决定授权或注销。很高大上的创新是不是？读者一定听说过基于属性的访问控制ABAC，活动当然也算属性的一种，又回到ABAC范畴，很难说有什么创新。属性按照ABAC的定义，本就包罗万象，还可以是血液中酒精含量、体温度数。也许读者们会觉得太扯了，可现在宣传很猛的软件驱动汽车概念，醉酒者能开车门听音响，却不能点火发动机，就是ABAC的典型应用。软件迟早会定义一切，身份特权自然也无处不在。

ABAC最大的优势是支持动态授权，可以根据多个实时的用户属性和系统属性，计算在当前时点是否给予权限，正如上述安全驾驶的场景。近年来，RBAC也发展出有限的动态授权能力，例如临时增加用户的角色等等，这些办法也可以部分解决CloudKnox提出的问题。可见，模型和技术都是处于不断发展状态中，深刻理解其含义并加以灵活应用，远比死抱着名词侃侃而谈更有价值。

RBAC也是业界使用多年的最佳实践。最小权限原则当然能被RBAC所支持，只要将角色配置成完成任务所需的最小权限集。但在实际落地中还是会出现种种不足。首先，角色定义数量容易过少，单个角色职责过多，造成权限授予普遍过多。其次，授权与管理过程必然存在组织架构和岗位信息不流畅和调整不灵活的局限，导致实际操作中常见增加授权而几乎不做减少，而此类过度授权会产生本可避免的重大风险。管理严格且执行力强的企业，有能力通过制度流程避免类似问题出现。不过，相当部分企业的安全团队缺乏足够影响力，也就无法强制推行细粒度合适的严格RBAC落地实施。CloudKnox对这种场景拥有缓解权限滥用的实际价值。

在具体实施中，CloudKnox可能会存在些许不便。刚刚够特权的概念，JEP (Just Enough Privileges)，听上去很美，可是应该怎么规划特权的细粒度呢？举个最简单的例子，一个5人团队管理着800台服务器，是按群组还是按单台授权呢？如果一位成员管理200台服务器，而过去两周，他只登录了30台，剩余170台没有碰过，那是不是30台就是他刚刚够的权限？是不是应该剥夺他对那170台的权限？谁来判断什么是刚刚够的水平？剥夺或追加授权流程应该如何设计？实际情况会更加复杂，各种主机、容器、存储、中间件、Serverless、应用等等的组合，过细的权限控制容易造成日常工作举步维艰，会不会导致JEP形同虚设？没有银弹。没有包治百病的产品。安全团队需要的是能有效支持其运营的能力平台。

请读者花两分钟时间仔细观察上图界面。红框内有657个细分特权可供授予。一点也不夸张，在真实的生产和测试环境中，是会存在如此之多的任务权限。这也是为什么业界认为RBAC是目前最佳实践。角色方式已经是公认兼顾细分权限和实现代价的较优平衡点。ABAC概念提出很多年，迄今只在小范围内应用，原因只有一个，实现过于复杂，维护资源要求太高。Less is more. 如果能用RBAC完成的任务，千万不要炫技使用ABAC：简单的策略往往容易执行无误，而复杂的策略常常看起来美好，执行时错误百出，导致严重后果。

总体来看，CloudKnox作为单独的方案，适用性较窄，远不及IAM和PAM的市场需求规模，不增加新产品线的话很难独立发展壮大。其身份行为审计的功能，确实抓住了混合云的痛点之一。官方所说使用机器学习发现行为异常的能力，笔者本来想深入研究一下，然而并没有从产品界面中找到任何端倪，不过，检测规则积累也有一些，可以参考。其产品完善度和细节都还可以，未来也有扩充功能的潜力。所以，它还是有可能被发力混合云的巨头收购，用以快速补足能力欠缺。这也仅限于企业身份系统能力积累较弱的厂商。微软拥有强大的Active Directory产品、以及杰出的异常审计能力，并不会表露太多兴趣，即使要收购也是战术狙击其它CSP。

Axonius

Axonius是一个网络安全资产管理平台，它允许IT团队和安全团队看到设备并了解如何管理和保护所有设备。各厂商都有资产管理功能，例如终端有杀毒、EPP和EDR，网络有漏扫和NGFW等，虚拟化平台等等也都有，但都限于某个细分领域，没有全局资产库。所以，安全团队无法得知各个系统所管理的资产之间的关系，也无法整合以完善所有资产属性。Axonius拥有众多产品的适配器，可以通过API获取这些厂商的设备日志。

以色列公司技术就一定好吗？A轮1300万美元好吓人。官方宣传是资产管理，于是大家翻译英文介绍，就信以为真了。资产管理需求一直存在，动态管理尤其是个痛点，但是，只需采集其它设备日志这种取巧方式真得好吗？答案显然是否定的。其实，Axonius只能做个没有agent的阉割版桌管用。不信？让我们看看官方宣传的能力。

看看这个Windows 8终端上都装了多少agent。

终端基本信息。

安装的软件。

打过的安全补丁。

用户列表。

这些功能都是标准桌管必备的，装个agent轻松获取。即使没有桌管，使用思睿嘉得EDR唾手可得上面的信息。更重要的是，这只是EDR众多检测能力外附赠的一小部分。性价比高下立判。

更进一步，桌管和EDR拥有更多更强大的功能，例如准入、推送、检测、调查、响应等等，远远不是只会索引查询其它厂商设备日志的Axonius所能比拟的。

对于没装agent的设备呢？Axonius也可以从其它厂商产品那里抓数据。

然后就没了！没有任何下文！因为Axonius得不到这些设备的信息。说好的资产可视和理解呢？严重受制于其它厂商的资产发现能力，连多一步都不肯做。

产品经理有一项日常纠结：在眼前这个功能上，究竟是要多走一步，还是保持简洁？想回答好此问题，需要权衡用户需求是否为痛点，以及研发投入的边际效应。在笔者看来，Axonius固步于产品最初定义的狭窄范围，没有真正思考最终使用者日常工作场景，在功能上缺陷明显。

等等，是不是还差了一块资产？没错，万一存在其它厂商设备发现不了的新资产呢？你也不能指望Axonius能发现！

请原谅笔者忍不住用了太多的叹号，实在是遇到了匪夷所思的产品设计。Axonius就打算做某些安全设备日志的查询，这让企业里部署的SIEM情何以堪。

如果读者想发现内网中的未知设备资产，使用思睿嘉得NDR可以实现基于流量的资产发现，无需那些必须事先部署好并且拥有Axonius适配器的产品。而且，没有agent的设备，NDR也很努力地去发现详细信息，如下图所示。更重要的是，这只是NDR众多检测能力外附赠的一小部分。重复一次，性价比高下立判。

Axonius的产品过于简单，没有创新技术，没有竞争壁垒。查询做得再好，界面再易用，适配器再多，也并没有什么价值。有钱的企业，早就买过Splunk了，流行国外厂商产品都有forwarder适配。有人的企业，自己用Elastic Stack开发一个也在情理之中，还有自研业绩向领导汇报，去展会演讲，何乐而不为。即使是部署老旧SIEM的企业，恐怕上个资产管理模块也能达到相同效果。资产发现和管理是很重要的基础能力，但是一味取巧没有深入扎根的产品，正如沙砾上建城堡，经不起风浪拍打。

既没创新技术，又缺乏亮点能力，Axonius并无收购价值。

Salt Security

Salt的目标是保护SaaS、Web、移动、微服务、和物联网的核心组成的API。其官方宣称创造了首个拥有专利的解决方案，通过行为分析来防止迫在眉睫的针对API的威胁。核心检测能力是行为分析。

也许很多读者没有读过2015年笔者关于安全发展趋势的预测：数据是新中心，身份是新边界，行为是新控制。不出所料，本届入围者继续作出了验证。Duality和WireWheel核心业务是保护数据，而ShiftLeft这样做代码审计的也不遗余力主打宣传检测程序中的数据泄露风险，Salt也说要发现API中的敏感数据。CloudKnox检测混合云中的身份特权风险，正应了身份是新边界，而Arkose专注的也是设备的身份，当然此场景下读者听到的更多炒作是零信任架构。Salt和Capsule8都强调其使用了行为分析技术，本届RSAC中的热点演讲议题ATT&CK框架也是行为分析的杰出代表。

API商业大潮已经势不可当。如果觉得会止步于此，那还是低估其未来潜力了，目前显露的只不过是冰山一角。API经济将会是Serverless架构的支柱，而Serverless是云计算的下一代；计算能力抽象是大趋势。让我们拭目以待。

Salt显然不是第一家推出API安全产品的。早在四五年前，软件业界曾掀起一波API管理公司收购浪潮，众多巨头Oralce、Red Hat、CA、Salesforce等，都通过多次收购完善了自己的产品服务包，其中自然也包括API安全。所以，与大众想象不同，API安全市场并不是蓝海。如果API管理平台提供基础安全能力，客户会另行采购其它供应商吗？此问题答案显而易见，请参考云基础安全能力与云服务商的发展。因此，想在此领域发展壮大，唯一的机会是深入再深入，提供更加复杂的检测响应能力。

Salt的产品分为三部分，发现、阻断、补救，听上去中规中矩，做API安全都会如此设计。不幸的是，翻遍互联网，找不到任何有关其产品服务的更详细资料，连份部署方式说明都没有。通常来讲，这意味着其产品极度不成熟。笔者关心的技术点疑问一个都没有答案。例如，其宣称发现模块可以识别API使用中出现的PII数据；而API最佳实践要求加密传输数据，按Salt宣称的部署简易度，看起来是镜像网络流量，恐怕对加密束手无策。笔者公司的DLP也帮助用户监控API传输敏感数据甚或文件，不过，绝大部分时候，需要获取业务系统的证书并理解其特有加密方式，以解密流量并识别内容，或者使用其它手段。此外，如果只接入日志，其实并不够，因为无法深入获取传输内容。

Salt宣称使用AI，基于细粒度API合法行为建立正常行为基线，实时对API行为进行监控，一旦检测到API活动中出现偏离基线的行为，即作为可疑恶意行为评估，可以在攻击者的侦察阶段实时防止API攻击的发生。这句话跟没说一样，看来也是受了Darktrace宣传手段的启发。请给我们界面效果和算法实现证据，眼见为实。市面上很多批评国内厂商假大空宣传的声音，其实国外厂商也好不到哪里去。

Salt宣称，防护阶段对攻击者行为快速评估的结果，可向安全团队提供有价值情报，并向开发人员提供API源代码相关漏洞信息，以便从根源上阻止攻击，进而提高API安全性。笔者非常希望看到Salt的实现效果，目前还是没有任何资料。Salt如何判断某个API接口存在漏洞？出现的原因是什么？被利用的场景？如何给漏洞重要性排序？漏洞的分类模型？向开发团队提供那些漏洞内容才有帮助？如何能给出补救措施建议？这些都是关系到产品成败的核心问题。

笔者关注API安全已经有一段时间了，不过到目前为止，还没看到让人眼前一亮的解决方案。做API安全产品还有很多个疑问需要回答，方向性决策不容马虎，例如是否支持CSP的API网关会更有市场，是否支持OpenAPI标准，API流可视化是否重要，自动化测试的价值有多高，等等。这次笔者打算去RSAC展台上拍几张Salt产品界面照片再做进一步分析。Salt是否有被收购价值，关键因素还是看其产品实现程度。

剩下的入围者分析恐怕来不及写了。Arkose Labs挣扎许多年后并未拿出独特技术，感觉还不如国内反欺诈厂商积累深厚；而且在美国信用体系如此发达的环境下，反欺诈创业公司的生存空间极度有限；更甭提GDPR又是一座翻不过去的大山。Eclypsium，硬件是个新方向，但是产品不成体系，过于琐碎，目前市场空间有限，天花板明显，做出成绩来也难，指望收购的话估值也不会太高。WireWheel创始团队政治背景强大，奥巴马政府商业官员，投资者NEA有前商业部长，读者看官方介绍调子就知道其技术乏善可陈，本公众号是技术向的，就不做具体评论了。

本文只从技术产品角度讨论收购价值，这也是国外收购的主要关注点；并未考虑短期增加市场收入作为目标的影响。目前来看，这些评判标准并不适用于国内市场状况。

最后，自然是揭晓笔者心目中获胜者的时刻。从技术创新度来讲，Duality和ShiftLeft表现突出，再考虑产品成熟度和市场接受度因素的话，ShiftLeft最终胜出。正如大家所说，冠军是谁并不重要，创新沙盒比赛入围者所揭示的安全技术发展趋势和热点才是需要我们认真思考的方向，希望本次两篇系列文章能带给大家一些启示。

声明：本文来自DJ的札记，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。