AI遇见SIEM 白山ATD革新企业安全大脑

2018-04-23 20:46

  摘要:SIEM是企业安全的核心中枢,负责收集汇总所有的数据,并结合情报对进行准确的判断和预警。但传统的SIEM过度依靠人工定制安全策略,不仅仅增加了人力成本,而且整个SIEM的识别准确率和使用效果也都大打折扣。而目前附带AI功能的SIEM系统也只是把AI当成算法插件作为集成,无法在没有安全人员介入的情况下的智能工作。

  本文将从传统SIEM组件构成入手,介绍AI对于下一代SIEM的适用性和重要性,并重点阐述当前主流SIEM&AI平台和全新一代SIEM@AI平台的区别;随后将结合实际案例深入讨论SIEM@AI的两个核心技术原理:数据分析和数据关联;在最后的篇幅,文章会探讨SIEM@AI的发展和研究方向。

  SIEM是SecurityInformationEventManagement的缩写,又名安全信息事件管理平台,作为企业的安全大脑,它可以为企业提供安全数据的收集、整合、分析、关联、处置和展现等功能,是企业业务安全运营的核心和基础。

  早在10年前,SIEM的概念就已经被提出。SIEM作为企业内部涉及安全的日志管理平台,提供日志的采集、存储、分析查询功能。经过十多年的发展,如今SIEM的产品形态已得到丰富拓展,包括支持数据源输入、情报中心(ThreatIntelligence)、策略脚本库(Playbook)等,同时外部数据的共享和获取也使得SIEM系统不断被完善。

  SIEM在美国一直保持着较快发展,根据Gartner相关市场报告,SIEM在全球(主要是美国)最近每年都保持着10%的增长速度,预计在2020年市场规模可达200亿人民币。然而在中国,SIEM还处于比较初级的阶段,很多企业对自身安全问题并没有系统性的管理。2017年整个中国市场只有3.17亿人民币的规模,这个数字相比中国经济对全球经济的占比是不相符的。不过可喜的是,SIEM中国市场最近每年都保持着近20%的增长速度,说明越来越多的中国企业已经意识到了SIEM的重要性。

  但并非所有企业都需要SIEM,处于初期发展阶段的企业数据流和业务量单一,面临的安全较少,安全设备和软件的需求也相对较小,依靠的安全产品即可满足基本需求。当企业发展到中大型规模时,业务线增多,内外网安全变得复杂,同时前期使用的安全产品也达到了一定数量,这时就有必要接入SIEM来实现统一的安全运营管理。

  采集层:系统数据入口。SIEM大多支持多种数据输入,这些数据从来源划分,包括终端用户设备、网络设备、服务器、存储设备等;从OSI模型划分,包括了数据链层、网络层、传输层、应用层的网络流量;从系统角色划分,包括不同的业务系统、中间件系统、负载均衡系统等。这些数据或以推送的方式或以拉取的方式向SIEM平台输送,供SIEM进行后续的分析计算。

  采集层使用的技术主要分为两类:“侵入式”和“无侵入式”。“侵入式”一般采用部署Agent程序,或者用户在自身代码逻辑中添加程序探针等方式采集数据;“无侵入式”一般则采用旁镜像流量或者输入日志等方式采集数据。两种模式各有优缺点,“侵入式”有利于企业增加定制化功能,并结合SIEM平台的特性深入贴合业务,但弊端在于外挂式的Agent一旦不稳定,就会影响用户自身业务,甚至导致系统宕机,我自己就遇到过好几个客户向我抱怨自身的服务被厂商的嵌入SDK搞的不稳定。“无侵入式”则可以完全避免对业务系统的影响,一方面提升系统稳定性,另一方面系统数据安全。在技术成熟的情况下,对用户来说,“无入侵式”采集方式显然更加友好。

  存储层:采集后的数据除了供给后面的计算分析外,还会进行存储。存储层有两个目的:一是对原始采集数据进行存储,二是对计算分析完成的结果进行存储。

  存储可选择的技术栈一般包括数据管道(中间数据传输),热存储(存储常用数据查询、更新),冷存储(存储不常用的数据)。严格说,数据管道不算是存储,但在实际上为了防范后端数据丢失或堆积,一般也会将经过管道的数据进行临时存储,比如互联网公司最常用的Kafka队列就是将中间数据落地在磁盘上。

  冷热分级存储的目的在于,热数据操作速度的同时,在一定程度上降低企业存储成本。对于冷存储而言,比性能更大的技术挑战是可靠性和可用性,支持多IDC、甚至多Zone的大型分布式存储技术系统是企业首选;而对于热存储,更关注的是读写速度以及如何被计算单元使用,所以一般会选择带有Sharding能力的分布式存储。

  计算层:SIEM平台的核心。分析准不准、全不全、快不快都依赖这层的计算单元。目前主流的计算模式包括实时计算平台和离线计算平台。

  海量数据的离线计算平台起源较早,早在10多年前就出现在Google的MapReduce系统中,MapReduce底层先利用GFS将海量数据分片存储,解决了单点设备的IO吞吐瓶颈。每个计算节点再依赖调度器或执行Map任务或执行Reduce任务,不断将海量计算任务分解、归并,最终输出期望的计算结果。实时计算平台算是海量数据计算的后起之秀,包括了以Storm为代表的实时流处理和以Sparksteaming为代表的微批次处理两种技术实现方式。

  在实时性上,实时流处理模式的处理速度更快,但从实际的使用经验来看,这种模式也要求更高的技术运维经验。无论是实时计算平台还是离线计算平台,都要求支持任务的Partition,这样可以在某些主机宕机的情况下,仍然计算顺利完成。

  计算平台最核心的并不是计算框架,而是算法部分的计算逻辑。计算逻辑对流量、用户请求、系统交互信息等不同类型的数据进行计算。目前绝大部分SIEM平台的实现都是基于规则引擎,如Drools,这就需要依赖使用者制定大量的规则,一旦使用者制定的规则有错误或者有遗漏,就会造成错判漏判。

  输出层:计算层分析的结果最终传导至输出层。传统SIEM的输出方式有很多,包括展现层面、报表层面、报警通知层面、实时阻断层面等,企业可以根据不同业务部门的不同需求选择合适的输出方式。SIEM的输出结果不仅仅和门或业务部门有关,还可能涉及到其他业务单元,比如资产管理、组织管理等。

  从事件处理的生命周期来看,处理方式可以分成自动方式和手动方式,自动方式可以对计算层分析出的安全事件进行自动处理,包括通知、预警、甚至阻断,而对于不能自动处理的情况,就需要手动方式,这时可以借助工单系统进行后续处理,最终安全被处理。

  情报中心:情报中心为SIEM计算层提供额外的数据支撑,从而提高和异常行为识别的准确率。情报中心的数据来源一般有三种渠道,第一种是来自公开输出的情报,如X-ForceExchange、ThreatBook、Shodan等;第二种是来自自身搜集的情据,如通过蜜罐采集、API调取或者交换购买等方式取得有价值的情报;第三种就是来自跟业务自身相关的辅助数据,如用户注册信息,企业资产信息、组织信息等等,这些信息看似和安全关联不大,但是当多种数据联合分析时,就可以为最终的结果输出提供有效参考。

  情报中心数据的内容包含多种形式,常用的如IP库、设备指纹库、黑卡库、漏洞库等。使用或依赖情报中心要注意情报的实时性,因为目前云化和共(zu)享(yong)经济的普及,很多资源并不是独占的,而是在一定时间后就被回收,并交由其他用途,这样的话如果情报更新不及时就会适得其反。

  SIEM、态势和SOC安全运营中心有着紧密关系。其中态势范围很广,主要聚焦在过去、理解现在、预测未来三个层面,这和SIEM的采集并计算分析给出结果进而预测是高度吻合的。一些企业发布的态势系统其实就是简化的SIEM或者是SIEM的超集。SOC安全运营中心则在SIEM的基础上突出了人的作用,强调了人和平台以及软件之间的联动,通过类似Ticket系统的任务追踪机制,配合SIEM提供的数据分析结果,用人对业务和资产进行全面的安全管理。

  总之,SIEM对于企业的整体安全分析常重要的,通过SIEM可以打通多种数据流的信息,形成对于安全的事前、事中、事后处理,最终企业的整体资产及业务安全。

  如果说IT技术有风口的话,那么AI无疑是最前沿并且最落地的,AI整体发展分为三个阶段:

  识别阶段:解决What的问题,这是最基础的AI问题。目前的AI通过大量有监督学习,提取标注样本的或内在特征,形成一个或多个分类器,分类器对样本数据特征进行学习训练,最终对新的输入进行准确识别,从而解决什么是什么的问题。比如什么是小狗、什么是图片等。

  典型的应用包括验证码识别、语音识别、垃圾邮件识别等。人们熟知的AlphaGo也是识别问题,深度学习通过对成千上万个已经标注好输赢的棋局进行训练,利用头几层的神经元网络,越过特征挖掘出人都很难理解的深层次特征,形成了对于棋局的“”能力,从而对某个棋局是更有利于黑方还是白方做出判断,再结合search或MCTS等算法,给出下一步走法的最优解。应该说识别是应用AI最成熟的领域。

  理解阶段:解决Why的问题,这是在识别的基础上进一步的AI问题。比如一段文字想表达的情感是什么?一个电影讲述的故事是什么?一段语音的问题是问什么等等。最典型的应用场景就是人机对话,其基础是理解人说的是什么,想表达什么意思。

  理解问题最原始的解决办法就是构造各种语义模板,用来做情感标注,变相把理解问题转换成识别问题。但随着深度学习的普及,已经出现了很多新的技术以突破模板定义的进而试图真正理解内在含义。但是通过苹果手机Siri的例子就可以看出,目前的AI对于理解问题的能力还远远没有到成熟的阶段。

  反馈阶段:解决How的问题。How本质是在识别的基础上,理解了对方的信息内容后,做出恰当的反馈。反馈是AI的最高境界,是实现真正人机互动的关键,有了反馈互动的能力,AI就可以像真人一样在一些领域部分代替人类,甚至完全代替人类。但很明显,目前AI的发展阶段离这个目标还相距甚远。

  从AI的三个发展阶段看,目前AI还主要处于“识别”和“理解”的初期,离真正的“代替人类”还有很长远的要走,当下真正已经成熟使用的技术基本集中在“识别”问题。同时我们观察安全领域就会发现,安全领域里的问题恰恰就常典型的识别问题,通过SIEM里的各种输入数据进行分析,只需要识别这个事件或这个用户是否存在即可,整个过程无关理解也无关反馈。

  应该看到,目前的新型SIEM已经集成了AI的能力,比如有的SIEM平台,集成了常用的AI算法,比如异常检测、线性预测,这些算法以插件的方式集成进平台,用户可以基于这些算法分析自身的数据。

  目前主流SIEM平台的最大缺点是:他们仅仅是SIEM&AI(以AI作为工具),把AI仅仅当成是SIEM平台的一个附属插件或工具,而没有把整个SIEM平台构建在AI技术。这样带来的影响是,企业使用SIEM时需要花费大量的时间、精力、人力去学习、配置和使用这些AI工具,另外,SIEM&AI还要求企业具有一定的特征工程经验,而这对于很多企业而言是不现实的。我见过很多企业客户,当我问到他们使用SIEM&AI类产品的的AI部分的体验时,都是一脸茫然,仿佛花了大价钱买了高级玩具却没玩起来。

  而企业真正需要的是:SIEM@AI(以AI作为平台),无需很多成本甚至完全无需学习成本,即可使用AI技术从海量的输入数据流信息中发掘事件,并自动使用AI技术对不同业务、不同维度的数据进行智能关联,建立内在联系,并最终自动的对事件进行处置处理。

  如前所述,在安全领域,大部分问题都是“识别”问题,从数据分析的角度,可以将问题最终归为分类问题。通过建立算法模型,预测进行中的事件甚至还未到来的事件是否存在,也就是把它们分成有和无两类。但是安全领域在使用AI时存在一个巨大的困难,即样本标注难。对于经典的图片识别问题,企业可以使用较低的人力成本批量制作标注样本,然后送入深度神经网络训练。但是安全问题则不同,从大量杂乱的信息数据中识别是否存在、是何种,需要专业的安全人员,甚至多个部门跨部门协作才能完成。

  标注难问题可解吗?答案是肯定的,那就是利用无监督学习。无监督学习可以将正常事件聚在一起,同时也会将异常事件聚在一起,从而方便算法识别出异常。而整个识别的过程无需标注样本,也大大降低了人工参与的程度。

  无监督学习是机器学习中一个非常重要的分支,不同于有监督学习需要依赖大量标注好的样本才能让分类器进行学习,无监督学习可以在没有任何标注样本的情况下由分类器自主学习。只不过目前市场上绝大多数产品都集中在有监督学习上,导致无监督被长期忽略了。

  白山ATD(AdvancedThreatDetection,深度识别,新一代的SIEM@AI系统)产品大量使用了无监督学习技术来进行事件识别,无监督学习的本质是将数据进行聚类,而根据聚类实现的过程不同又主要分为三种算法:距离聚类、核密度聚类、层次聚类

  距离聚类是最常见的聚类算法,本质是EM算法,通过对于距离中心点的不断迭代修正,最终将所有事件进行归类,那么有的事件自然会被归到一簇或者几簇,而正常的事件也会因为更相似的距离而归到一簇或者几簇。当然这是理想情况,在现实场景中实施算法还需要做很多的加工工作。距离聚类的最大困难一是距离计算方式的选择,二是聚类簇数量的选择。

  -如何事件边界:繁杂的海量数据输入中,一个事件的边界从哪里开始,到哪里结束,包含哪些数据。这需要按照不同的应用场景做不同的处理,常见的方式有按照时间段,也有按照事件切分点。

  -如何制定事件间距离:事件有很多不同的描述维度,对于最常见的维度时间、地点而言,记录时间有可能是UNIX时间戳,记录地点有能是GEOIP或者MAC地址,那么如何把UNIX时间戳和IP地址放在一个向量空间模型里比较距离就是一个问题了。这里ATD采用的Z-Score算法进行距离映射,使得映射后的数据具有完全的正太分布特征。

  簇的数量选择对于无监督学习的算法效果至关重要,一旦初始簇的数量选择不合适,就有可能导致聚类的结果完全错误。

  如上图,红色异常点是我们需要识别出来的,显然聚类簇数为2的效果比聚类簇数为3的效果要好,因为3将正常的事件点也分为了两类。ATD使用一系列算法在聚类前预判准确的聚类簇数量,最好的情况下可以提升200%的聚类效果。

  核密度聚类不需要事先指定聚类的簇数,而是根据初始的密度值进行聚类选择,所有与核距离过远的事件都会被标记为离群点,这些离群点从安全角度看可能就是事件。

  密度聚类的前提是需要选择合适的初始密度值,如果选择不当将导致离群点错误,最终使事件误判。另一方面,控制离群点的数量和纯度对最终的识别效果也很重要,因为在实际生产中,很有可能出现大量的离散点其实也是正常的事件。所以有时候也需要在第一次聚类后,调整事件的特征选择算法,针对离群点进行二次聚类。

  层次聚类的原理是先将所有事件看成树的叶子节点,每个叶子节点自成一类,然后根据相互的距离,自下而上逐层合并,最终形成一个根。

  层次聚类可以根据需要,按照最终聚类的簇数进行层层归并,最终聚成的小簇我们可以认为是某种离群点,即有可能是一些事件。可以看出,层次聚类的核心仍然是距离计算模型的选择。

  利用无监督学习,可以在无需标注样本和无人工介入的前提下,发现很多异常的风险。下图是一个被ATD系统识别出的实际例子:

  这是一个ATD对企业电商业务无监督学习的实际案例,案例显示大部分用户的访问径集中在

  登录页=》授权页=》订单页的访问趋势,通过无监督学习就可以将正常用户的行为聚在一起。反观刷单的恶意行为则会绕过授权页直接访问订单页,这样在无监督学习过程中就自然形成了离群点,这样我们就可以帮助企业识别出刷单的风险。

  纵向分析指的是对于事件群体按照时间轴学习规律,以此进行对于已有的识别和对于未来的态势。横向关联指对空间上不直接相关的不同事件群体,通过算法挖掘它们的深层次关联关系,最终形成更准确的识别或者便于对事件进行更全面的回溯。

  对于大多数SIEM产品,只要附带AI工具功能的,便可以完成诸如异常点检查、趋势预测等任务(尽管他们当中绝大多数都是有监督学习,这也就意味着客户需要提供大量标注好的事件和正常事件的样本),不过这些任务都是纵向分析,并不是横向关联。因此,对于新一代SIEM@AI系统来说,比起无监督学习进行纵向分析,更有挑战的任务是在表层不相关的海量数据中建立潜在关联,从而实现真正的深度识别。

  A、某一作用域(如某一时间段内)的事件集合,挖掘事件之间的关联关系,如:

  上图就是两个完全由不同系统统计输出的事件,我们需要用算法分析是否存在关联,这个过程实际可以转换为:按行分析相关性。

  上图所示,全部“ERP系统不能访问”的事件中,各个因素间是否存在关联,这个过程实际可以转换为:按列分析相关性。

  由此可以看出,无论是不同事件的关联分析,还是同一类事件的内在因素关联,本质可以转换为矩阵的行相关或列相关。对于列相关,通过对于矩阵转置运算,也可以转换为行相关,即:

  对于这种关联分析,最常见的方式是用类似KNN算法中,通过计算两个事件元素的夹角来判断相关性:

  当夹角越小时,表示两个事件越相关,而当夹角互相垂直(即正交)时,表示两个事件完全无关。

  夹角距离计算方式更适用数值型的事件向量,而Jaccard距离计算方式更适合枚举字符串类型的事件向量。当然事实上,我们可以把任何字符串类型的事件,通过word2vec或者simhash等算法方式转变为数值型事件向量,然后再进行夹角计算。

  说到数据关联,不得不提的经典故事就是“啤酒与尿布”了,沃尔玛在做数据关联分析时发现啤酒和尿布在购物单上是相关的,这是怎么回事?原来妻子经常会嘱咐丈夫下班以后要为孩子买尿布。而丈夫在买完尿布之后又要顺手买回自己爱喝的啤酒,因此啤酒和尿布的销售行为上具有相关性。

  从数据关联算法复杂性的角度看,啤酒和尿布的关联属于比较简单也相对直接一些的关联,Apriori算法就是解决这个问题的简单可实现的算法之一。Apriori算法通过不断的筛选频繁项并且不断的产生新关联规则的方式,最终得到关联性最强的事件元素。

  深入Apriori算法的过程就会发现,其实Apriori整个计算过程和计算事件间的Jaccard距离十分类似,本质都是比较两个事件的相似因素后进行筛选。不过Apriori算法在实现上比两两比较效率更高,因为在其中有剪枝缩小范围的过程。

  其实,在ATD给客户服务的实际应用场景中,上文提到的“啤酒,尿布”还都算是比较简单的事件关联模型。更为复杂的是,如何发现从人的认识角度看并不是那么直接的关联关系。比如空气的雾霾指数和城市用电量的关系,从人的角度,这两个并不是特别的直接相关。但当我们在两个事件中引入一个桥梁,即室内人数占比,就会发现这样的概率关系:

  P(用电量/雾霾)=P(室内人数增加/雾霾)*P(用电量增加/室内人口增加),其中P(A/B)表示B事件发生情况下发生A事件的概率

  如果可以列举出雾霾导致的所有核心事件,就可以使用全概率公式推导出雾霾和用电量的关系(所以这里我并没有使用等号=而是使用了=)。

  从识别的角度,通过这种中间的桥梁事件,同理也可以构建出两个看似不相关的事件之间的关系。比如在我们给某家电企业部署的ATD运行中,就发现了一次疑似的CC实际是和后端某业务线数据库变更操作有关:

  P(疑似CC/业务线数据库变更)=P(疑似CC/接口访问飙升)*P(接口访问飙升/504占比)*P(504占比/请求阻塞)*P(请求阻塞/数据库阻塞)*P(数据库阻塞/数据库变更)

  解决这种复杂隐晦的事件关联的前提是首先要把所有信息(不管认为是否相关)都收集进来(这也是文章开始阶段提到的SIEM的采集层需要解决的),尽可能多的采集各种数据,因为只有采集到数据才有可能建立关联。当海量的数据采集进来后,我们往往在做下一步相关分析时会发现一个难题,即:因为数据太多,导致分析的性能很低。如果事件分析的不及时,很可能会影响后续的处理,所以整个分析过程的低延迟至关重要。

  如何处理速度呢?那就需要对数据进行降维分解,从而降低计算空间,这里面有两种做法:

  如果企业本身有大量标注数据,那就可以使用有监督降维,最经典的有监督降维就是PCA(PrincipalComponentAnalysis,主成分分析),其原理是选择一种最优的数据投射方式,从高维空间投射到低维空间,并且投射后有较好的区分度。

  在没有大量标注数据的情况下就可以使用无监督降维,这也正是ATD所使用的数据降维方式。有很多种算法都可以进行无监督降维,ATD最早使用的是LDA(LatentDirichletAllocation)主题发现模型进行降维,通过LDA先将数据按照主题相关性聚类,降低每一类中数据的数量和维度,从而减少后续计算的复杂度。

  上图所示,我们先对于一个海量的事件集进行了SVD分解,分解的结果是三个矩阵的乘积,然后通过对于中间矩阵的元素进行筛选,就可以降低整个事件集群的复杂度,同时找到同一个隐含主题下的关联事件和关联因素。隐含主题的数量本质上就是事件矩阵的秩。

  从更深的角度讲,无论是LDA还是SVD,其实本质都是去寻找事件矩阵的秩,利用秩找到构成事件的最核心因素,比如对于一个入侵事件,可能的核心因素是用户的属性(内/外部用户、是否授权、相应职级等等)、入侵时间、侵入的业务类型,而其他的因素,诸如员工的年龄、当时的服务器负载等等其他因素有可能就会被算法自动识别为非关键因素而忽略掉。通过这种方式就可以在茫茫信息中发现关键因素,从而为后面的事件关联大大降低运算量。

  总之,数据的横向关联是一个极富挑战性的任务,其中最重要的先决条件是通过SIEM的采集层收集足够的数据,其次是选择合适的算法对数据进行加工处理,最后是通过AI算法对数据进行关联分析。在ATD客户的实际使用中,我们成功地发现了外网的接口和内网数据库变更之间的关系,也发现了某邮件系统的Exchange日志事件和内网SSH事件之间的关系。这种关联分析不仅仅对于已知的回溯有帮助,也对未来的安全态势有重大意义。

  从SIEM&AI模式到SIEM@AI模式,我们不再将AI看成是插件或者工具,而是将系统运行在一个完全由AI驱动的智能平台上。在这个平台上,我们无需标注数据,无需大量人工介入,也无需定制规则,而是通过以无监督学习为主导的机器学习算法自动对异常事件进行识别,自动的为各个复杂事件建立内在关联,提高识别的准确率和召回率的同时,解放安全工程师的人力并提高其效率,最终实现对于企业外网、业务、内网的三层智能防御。

  白山ATD产品就是一套全新的SIEM@AI系统,我们过去花费了大量时间和精力去研发基于无监督学习的AI算法来代替目前的传统企业安全产品,这种模式的有效性在企业实践中已经得到了验证。未来,ATD还会在两个方向做进一步探索研究:

  引入无监督学习的目的是不依赖标注的样本,因为在安全领域,标注样本的获取成本非常大,但是这并不代表可以完全不依靠人工。在可预见的时间范围内,有经验的安全专家对风险的识别、对于算法的修正以及对于整个AI系统的鲁棒性都常重要的。但是,安全专家的时间精力毕竟有限,如何在准确全面识别安全的前提下,降低安全专家的时间成本就显得十分关键。

  对此,我们引入主动学习算法,它是一种特殊的半监督学习,依靠安全专家对少量的AI识别出的结果进行人工校验,从而不断对原有算法进行微调,直到最终。主动学习里有两个因素非常重要,一是如何挑选供给人工校验的识别结果,二是对于识别结果的纠正如何反馈到算法模型中。通过主动学习,我们就可以构建不断学习、不断演变的SIEM系统,进而随着与人的磨合,系统会变得越来越智能,越来越准确。

  有些或者异常本身不具备直观表述性,甚至不能被向量化、离散化,最直接的例子就是加密流量。加密后的流量本身是人不可表述的,只是一层二进制输入流。还有些安全事件由于关联业务太多,很难用语言来表述为什么当初这个问题被判定为异常。对于这些问题,都可以尝试使用深度学习的算法来解决,不过深度学习要求有大量的标注样本,只有在这个前提下,才能算法的效果。这就要求企业在平时的SIEM系统运行中,就不断增加对于事件判定的积累,当数据积累到一定程度后,就可以使用深度学习算法进行分析。

  AI作为安全领域的性技术,与SIEM的结合将构建一个完全基于AI的、充分智能的、低人工甚至无需人工介入的新一代SIEM@AI平台,这将改变目前安全产品依靠策略设定的固有模式,成为新一代企业安全大脑。

  2006年至2015年就职于新浪,原SAE(SinaAppEngine)创始人,曾任总负责人兼首席架构师,2010年起,带领新浪云计算团队从事云相关领域的技术研发工作。