Kate Li (Taiwan)的部落格

首頁

下一座聖杯

作者 veca 時間 2020-04-03
all

今年的聖杯文章拖延很久,原因是筆者公司也在做這方向產品,所以故意押後幾個月才發:先看清市場有沒有跟隨者以及其理解程度。畢竟創業公司要辛苦謀生度日,競爭態勢也需要時刻注意。每年的聖杯文章預測兩年後初見成功的新安全產品。今年筆者挑選的方向註定是個紅海;初創公司要謹慎進入,因為必然會直面大廠發起的兇猛競爭。

應用安全的發展

最近十年,應用安全從未缺席行業熱點關注。公眾號留言希望筆者寫寫有關應用安全的要求也從未間斷過。還記得2015年關於安全新趨勢的文章嗎?數據是新中心、身份是新邊界、行為是新控制、情報是新服務。每一點都代表著創業公司的市場機會。唯獨沒有應用安全。應用安全不重要嗎?當然不是。軟件定義世界,沒有人會否認軟件自身安全性的重要程度。可惜的是,在2015年,筆者並沒看到應用安全出現新技術變革。基礎設施演進給應用安全市場帶來了新機會,也只是交付管道的改變,導致新增容量大部分被雲基礎設施大廠瓜分殆盡。過去數年間,缺乏科技變革,還要面對CSP逐步蠶食份額,應用安全廠商感覺壓力山大,都在發愁如何把乏善可陳的產品做出亮點。在此大環境下,專注技術創新的初創公司也很難孵化出藝員。

為了佐證此論斷,我們不妨對比2004年與2017年OWASP Top 10的變化。下圖中,筆者用箭頭畫出了相差十三年兩份清單的內容對應關係。透過表像看實質:仔細研究其詳細解釋,就會發現除了清單標題文字表達有些許差异外,具體安全控制點在兩份檔案中幾乎都可以一條不落地找到。

例如,2004 A10 Insecure Configuration Management具體解釋中第一點即明確提到unpatched security flaws in the server software,與2017 A9 Using Components with Known Vulnerabilities並無本質區別。2017 A4 XXE是新出現的條目,自然是由於XML廣泛應用所引起的,但是讓我們看一眼2004 A1 Unvalidated Input的解釋:Attackers can tamper with any part of an HTTP request,including the url,querystring,headers,cookies,form fields,and hidden fields,to try to bypass the site's security mechanisms.顯然,XXE只是其中一種表現,並不新鮮。而反序列化漏洞代替緩衝區溢位,揭示著應用系統架構的變遷,Java等開發語言逐漸佔據統治地位。消失在前十的2004 A9 Application Denial of Service,把它挪到2017 A11的位置,相信絕大部分讀者都沒有抗告。2017年真正意義上新出現的條目只有一個:A10 Insufficient Logging & Monitoring,而這正是整個安全業界對於防禦和檢測的心態發生了根本轉變才有的認識。

不知道各位看官有沒有像筆者當時一樣感到十分驚歎。假設2004年你已經掌握了Web攻擊的基礎知識並充分實踐,恭喜你,十幾年後,你即使並沒努力學習新技術,即使一直原地踏步,也不會被無情淘汰。這在飛速發展的電腦領域簡直太不可思議了。舉個例子做對比,同樣這十五年間,作業系統等軟件的安全性至少上了四五個大臺階,如果你不能持續跟進新技術發展,內網橫向移動必然舉步維艱。

回顧應用安全領域的標杆產品WAF的發展歷程,也可以看到類似現象。開源ModSecurity發佈於2002年,雖然易用性和支持性比不過商業產品,但事實上一直代表著此領域的科技發展水准。把時間撥回到2015年,筆者能看到的創新,也只有SQL注入的詞法分析,始於2012年開源的libinjection。這個現時WAF廠商還在重點文宣的新功能,ModSecurity在2013年初就已經集成並提供。題外話,libinjection的作者後來作為CTO共同創立了引人注目的Signal Sciences,成為WAF市場後起之秀。在此之後,ModSecurity於2014年引入模糊雜湊方法ssdeep檢測webshell,其所用科技CTPH早在2006年問世,實際效果差强人意,難以大張旗鼓文宣。從那時到現在,大家又記得WAF檢測科技出現了什麼新變化嗎?

筆者還觀察到一個有趣現象,無論美國亦或國內,如果你跟NGFW或其它產品方向的領先廠商的科技人員交流,總會有一種感覺,他們對WAF根本不重視,言談中隱隱流露出認為其科技老舊缺乏壁壘、市場規模有限、所以不願意投入的意思。

但筆者十分重視WAF市場。熟悉的朋友都知道我近幾年多次講到十分後悔2015年烦乱了半年時間最終沒有堅定投入WAF產品。那時候,我看到了WAF在國內市場的巨大潜力:少有的預算增速和預算份額遠超美國市場的安全產品,這是由於當時國內電商和線上業務發展速度已經顯露出全面超過美國的迹象。但是我也看到了缺乏技術革新帶來的產品同質化嚴重,同時高估了大廠的產品研發和市場進攻執行力,還有重金砸銷售與那時公司運營模式不同的挑戰,等等各種貌似正確的理由,最終錯失了一次市場爆發機會。每日三省吾身,交過學費的自然要牢記並且避免再犯錯。這幾年來,筆者一直念念不忘試圖尋找進入應用安全領域的切入點。

上文提及,雲增量被CSP吃掉。早在2015年,筆者就認為雲WAF位列雲安全產品收入前三,應是雲服務商重點投入方向,參見本公眾號文章《安全,是雲基礎設施的核心競爭力之一》。那年,業界還在爭論,雲服務商應不應該做安全、能不能做好安全。白駒過隙,四年後市場給出了强有力的答案:今年各路分析師報告,全球前十WAF廠商裏有一半是雲基礎設施服務商。新機會由交付管道改變而引發,並非科技變革,導致WAF市場發展不是創新驅動而是投資驅動,囙此頭部CSP能擁有巨大競爭優勢。

應用安全其它領域的需求亦很強勁,只是難以規模化成長,獨立支撐起一個上市公司的難度頗大。例如RASP,2015年RSAC創新沙箱冠軍Waratek,現在也轉向RASP與WAF結合,走Signal Sciences的道路;成立十年之久,規模卻落後太多。近兩年新趨勢,廠商同時提供RASP和WAF集成,彌補各自不足之處。Shape Security當年猛吹動態變形,究其原理也是RASP路數,想做到上市也困難重重,歷經轉換方向嘗試,到現在早已改成RASP+WAF+SDK。Imperva起家其實是靠資料庫安全。美國WAF市場啟動與國內同步甚至略慢,到現在也已經變成紅海,收購綜合一直在進行中。另外,今年創新沙箱入圍者ShiftLeft,數學方法輔助自動化程式碼漏洞挖掘,筆者雖然很喜歡其科技,但也知道很多美國投資者並不看好程式碼稽核類產品,因為他們投了近二十年的程式碼稽核初創公司,最好的結果是被收購。應用安全廠商面對窘境,無不積極尋找轉折機會。橫跨半步,已成為安全行業擴大規模的普遍策略,常見的有,威脅情報廠商銷售IDS,漏掃廠商通過DAST產品進入SDL,代表廠商如Rapid7,等等。

洋洋灑灑寫了兩千多字,顯然不是廢話去浪費大家時間,而是要為中心思想做鋪墊:雖然過去十年美國市場湧現出不少應用安全創業公司,但成功者十分稀少。就在眼下,應用安全領域出現了一個少見的擁有巨大市場空間的創業機會:API安全。新應用風險,新安全戰場。或許很多讀者已經猜到此答案,因為從去年底開始,筆者已經多次在小型沙龍和大型行業會議中公開介紹過API安全的基礎知識。新基礎設施必然會帶來新安全產品機遇。作為連接一切應用並交付數據和功能的管道,API已成為安全團隊不得不重視的關鍵風險控制點。

新形勢與新機遇

過去五年,云計算已經深入到數位化經濟基礎設施的方方面面,市場競爭態勢的巨大變革導致諸多廠商盛衰沉浮,不乏跟不上趨勢從此一蹶不振的。未來五年,影響深遠的科技架構變革會是什麼?一千個讀者心中有一千個哈姆雷特,不同解讀在所難免。但是,微服務、Serverless、邊緣計算,應該能覆蓋大部分讀者心中的答案。聽起來區別頗大的三個方向,卻都有一點共同特徵:API是必不可少的基礎模塊。

業內容易有個認知誤區,微服務常常被認為等同於容器,其實不然:容器只是提供了大規模部署的便捷管理方法,容器離開微服務架構就沒有大發展機會,而微服務離開容器仍將繼續快速前行。容器的易用性必然會帶來額外資源消耗、效能波動、治理複雜度、以及其它相對應的局限,囙此如今也有企業在部署微服務時,出現從容器回退到虛擬機器甚至物理機的現象。或相反方向,使用更抽象化更易管理的計算管道支持微服務,類似Serverless用於搭建Microservices,AWS已自成體系:Lambda、Fargate、Aurora Serverless、EventBridge、Kinesis等等。事實上,微服務架構的覈心是網格mesh,網格的連線採用API最易達成管理。囙此,沒有Kubernetes照樣可以使用微服務,沒有API就沒有微服務。業界有些專家堅稱,微服務不過是SOA舊瓶裝新酒,此論調與當年將云計算等同於虛擬化一說驚人雷同,遲早會被證誤。筆者認為,SOA所描述的數据總線已經過時,將被支持網狀通訊傳輸的數據平面所替代。原因有很多,既然是安全行業公眾號,本文就只講從安全角度出發的一點:SOA數据總線架構無法滿足資料安全合規要求。只有陞級到點對點的服務網格,使用分類分級的API,嚴格認證身份並充分鑒權,遵循最小限度使用數據的原則,才能靈活達成日趨嚴格的數據資產內控目標。下麵借用一張示意圖說明API在微服務架構中的無處不在。

閒扯兩句,近兩年來感覺國內雲廠商能力與AWS和Azure相比差距越來越大。很多人並不理解什麼是“跟隨者戰畧”。並不是友商今天發佈一項新產品,咱們自己10個月後也發個新聞稿寫頁ppt就能搞定。有些新產品需要起碼幾年時間去開發,大神再多的研發團隊也沒辦法創造奇跡。真正的跟隨者戰畧,要提前三五年識別友商的中期戰畧,還原其產品規劃路線圖,然後自己才能佈局資源投入,達成落後一年跟隨領導者推出新品的目標。不踏實做競爭分析的功課,等人家產品都發佈了,自己手忙腳亂硬上,頂多是學個皮毛,湊合做個介面,面子裡子本末倒置。還有人覺得AWS發佈Fargate是被Kubernetes逼迫的無奈之舉,App Mesh無法面對Istio,事實上只能說他根本不理解云計算和AWS戰畧,不過是鸚鵡學舌般喊名詞扯大旗。Kubernetes是很兇猛,Istio是很牛逼,但就像十年前大家還會聊起Xen和KVM,現在AWS雲上絕大多數客戶不會提及Hypervisor而只知道EC2一樣,五年後,客戶只要能在AWS上輕鬆跑起來容器並編排應用之間網絡連接就好,人家只需要知道Fargate和AppMesh,管你下麵用的K8s/Istio還是什麼其它架構。就連掌握K8s的Google也推出了相同產品Cloud Run。如果連行業領導者的戰畧都看不懂,就不要奢談什麼跟隨者策略。計算抽象化,自打電腦問世後就一直存在,無法阻擋也不可避免,在雲上也沒有例外,Serverless已經被公認為大勢所趨。

Serverless,或者有人叫Function-as-a-Service(其實範疇略有不同),本來就是構建於API之上且以API管道提供功能交付,所有後臺計算服務器都被抽象化,用戶看不見也不關心,自然不用多說API在其中扮演的重要角色。邊緣計算,也不可能有獨立的孤島設備,邊緣計算節點之間以及與雲上中心服務器的所有互動都是通過API實現。

讓我們再來看看更多熱門應用場景:人工智慧AI平臺能力都是通過API來交付的,無論是圖像識別還是反欺詐;今年炒得火熱的中台,實質上是把後端能力標準API化;供應鏈中的資料交換,毫無疑問也都是API;不一而足。在數位化轉型過程中,API已經成為不可或缺的基礎設施。

既然API應用廣泛是大趨勢,那做API管理平臺是不是比API安全更有前景呢?去年早些時候,筆者與幾個做投資的朋友聊起此創業方向時,狠狠潑了一盆冷水。首先,去年開始做明顯已經晚了,要做也必須在巨頭動手之前,先發才能有機會搶佔市場。早在三四年前,國外巨頭已經紛紛開始佈局,參見下錶。其次,API管理服務受客戶導流影響顯著,初創公司需要付出可觀的客戶獲取成本,而這方面巨頭擁有無可比擬的優勢,無論是私有化部署或者雲交付。第三,開源方案已經很成熟,Kong、WSO2、Ambassador、Tyk、Zuul等各有千秋,令業務自建門檻大幅降低,有一定自研能力的企業往往不會選擇外購。

國內市場還要面臨更多的挑戰。尤其難免會遇到拷問靈魂的問題:巨頭入場之後,創業公司的競爭優勢如何體現?此方向上,很難建立有效的技術壁壘,無論是效能還是功能,想突破Nginx衍生平臺的水准,真不是三五個覈心團隊成員一兩年能搞定的。想做開源發行版本定制?Hadoop生態的頹勢歷歷在目。此外,雲廠商的標準產品會吃掉絕大部分中小企業的市場份額。還有之前已經成功的業務系統開發廠商,他們坐擁前期積累的成本優勢,必定橫移半步正面競爭。API管理平臺由於與業務系統關聯緊密,客戶很高概率會要求定制開發,這對創業公司既是機會又是陷阱。一方面即使巨頭拿到訂單也可能不願意做,甩給小公司,不過這樣拿到的單子交付壓力大,毛利率較低,另一方面,直銷往往又需要付出高昂的獲客成本,非標準化且交付要求高的產品,走通路只是空想罷了。簡而言之,規模發展速度受限,利潤空間堪憂。

但凡存在基礎設施演進變革,安全創業的機會就少不了。隨著API迅速成為內外部人員和應用服務之間交換並使用數據的主要通道,管理層越來越擔心它所帶來的內外部威脅。API安全由於坐擁安全市場區隔的獨有特性,競爭態勢會遠遠好於通用API管理市場;而API管理廠商雖然會提供部分基礎安全能力,例如用量限制、抗DDoS、防bot、身份認證和鑒權等,但通常也沒有能力太過深入去搶安全廠商的飯碗。既然如此,接下來需要考慮的便是,API安全應該如何切入呢?

跨細分領域且跨基礎設施

雖然本文以應用安全開頭,不過API安全可不僅僅局限於應用安全,還橫跨資料安全和身份安全領域,這就令其切入點變得多且分散。任何只關注某一細分領域的API安全產品都不是完整的,客戶要求的是能處理此場景中盡可能多風險衝突的完整解决方案。創業公司可以根據自己歷史積累的競爭優勢,靈活選擇入場管道,然後再橫向移動至相鄰細分領域。例如筆者公司的API安全產品便是由資料安全入手,隨後引入認證和鑒權相關風險的檢測,現時在完善應用安全方面的覆蓋。

照此邏輯,WAF大廠Imperva從應用安全入手非常自然,API安全已經位列其應用安全類目下的頂級產品線,與WAF並列。之前在Web攻防領域積累頗多的廠商,自然首先文宣對API攻擊會造成巨大危害。Imperva產品彩頁包括四個要點:封锁API相關的嚴重攻擊、構建基於OpenAPI規範的積極安全模型、集成安全性至API生命週期管理、網站與API的統一安全解决方案。是不是感覺描述十分簡單?由此可見Imperva也才剛剛開始。

上圖說明了API安全在Imperva整個縱深防禦產品體系裏的位置。

Web安全已有超過15年時間的高强度對抗,而API對抗不過才剛剛開始,程式師們都沒經過實戰演練,很容易出現各種漏洞。囙此,在現時階段,攻擊API很容易達成滿意結果,利用已有滲透測試工具都能獲取可觀的產出,典型的a low-hanging fruit,年底沖業績的紅隊不妨一試。

說到這裡不能不提OWASP組織的API安全前十清單,如下圖所示。在筆者看來,此清單過於注重攻擊防守科技,缺少對業務風險的理解和支持,安全團隊難以使用類似口徑向管理層彙報,立項申請預算都要頗費一番周折。囙此,筆者從商業風險緯度出發,總結了五點管理層關心的、會造成明確業務損失的、並且有緩解措施落地的API安全威脅,在多個場合公開介紹過。限於篇幅,此處不展開細講了。

大家不妨對比一下OWASP Top 10與OWASP API Top 10之間的區別,篇幅所限這裡不展開詳細講了。

今年RSAC創新沙箱入圍廠商Salt Security是OWASP API Top 10的贊助商之一,號稱可以發現攻擊者偵查API的行為,從其思路來看也是應用安全方向。很遺憾的是,過去一年中筆者在各展會上四處尋覓卻都沒看到其產品演示,這情形也十分少見,令人不禁心生疑惑。

從身份安全邁入API安全也是一條可行之路。API離不開身份認證和鑒權,IAM廠商天生就有現成客戶群體沉澱,可交叉銷售的新產品線是許多管理層擴張戰畧的最愛。Ping Identity首先通過PingAccess為客戶提供API中的許可權管控能力,發現協同效應後,進一步收購Elastic Beam以完善API安全解决方案:打包成下圖中的PingIntelligence產品線。

上面的另一塊拼圖組成部分,便是對API使用過程中的數據流動的監控,產品線名稱為PingDataGovernance。筆者不願意過分誇大數據流動的風險,雖然五年前我們產品已經有了數據地圖的功能,但從來沒大張旗鼓文宣也沒必要去嚇唬用戶。原因很簡單,不分重點監測數據流量的工作,投資回報率ROI較低,不建議資源緊張的安全團隊超前考慮。安全行業中頗有一些貌似簡單直觀的概念,乍聽上去很有道理,人人都能理解並附和討論幾句,其實卻經不起推敲。安全發展到現在,再出現簡潔直觀的體系架構非常困難,至少很難發源於普通從業者。最近幾年火熱的諸如零信任和ATT&CK等新思路,有哪個是能輕易理解上手的,又有哪個是能快速落地的,又有哪個不是投入鉅資多年積累的?現實當中,企業大部分的數據流動場景的風險極低,盲目檢測與大海裏撈針沒什麼區別,短時間也許可以贏得一些讚譽,長期產出難以預測和衡量,無法得到管理層認可。試圖掌握大型企業中的數據流動?安全團隊不妨先分清預算,頻寬、存儲、算力是否足够支撐,最關鍵的是,要有足够的員工編制確保日常運營,再考慮檢測出的風險數量是不是足够多到能說服管理層進而持續支持如此之大的資金投入。以為是藍海創新,其實是高投入低產出的無底洞。幾十年來,安全預算首重邊界防護是非常有道理的,因為那裡是ROI最高的所在。延續這一思路,發現數據流動風險,想要出業績,最重要的是監控邊界處發生的惡意技戰術,辦公網自然是DLP,而業務系統領域API當仁不讓首當其衝。

API安全從數據防洩漏角度切入對管理層也擁有非常吸引力。2018年,由於API問題造成的知名資料安全事件發生了很多起,小額社交支付Venmo洩露了數十萬條交易細節,T-Mobile洩露了230萬用戶敏感數據,Facebook洩露了超過3000萬帳戶,USPS則洩露了約6000萬帳戶的數據。2019年,澳大利亞最大的房地產評估公司LandMarkWhite出現API漏洞,導致房地產估價細節和客戶資訊洩露;調查發現,出現的問題根源在於,最初設計只能在內部使用的API,被攻擊者從其域外部訪問;此事件嚴重損害了該公司聲譽,客戶和銀行合作夥伴爭相尋找替代方案,最終導致首席執行官辭職。不幸的是,此類API數據洩露問題十分常見,也不是許可權檢測就能發現的,往往需要依賴行為分析才能捕獲。

除了橫跨三個細分領域之外,API安全還有更多難點,需要適應多種不同時期不同架構的業務應用。傳統行業擁有大量歷史留存的基於SOAP的老舊業務系統,並不遵循OpenAPI,甚至不使用REST API,而是WebSockets傳輸XML數據。此外,JSON、Protobuf、GraphQL、RPC、HTTP/2等等,很多時候開發人員都是拿橘子跟蘋果對比,概念範疇都無法對齊,API安全產品處理起來更是複雜。大部分國外創業公司只專注於一種介面,但在國內恐怕行不通。

下圖的演講標題看著眼暈不?是不是有不忍直視的拉郎配般的酸爽?如果公司裏有個盲目崇拜大廠不停嘗試追趕實驗室科技的架構師,那安全團隊一定有種被無情架在火堆上炙烤的感覺。

此外,API使用場景廣泛,需要廠商有全面覆蓋多種不同基礎設施的產品能力。最簡單的部署管道自然是網路流量鏡像,還原HTTP流量中的REST API通訊,大家都覺得容易,但內部員工使用業務系統API的TLS加密流量,能正確應對還原的廠商就不多了。JSON能描述的數據格式簡單,業務系統需要傳輸大量PDF表單和Office檔案,內容是否敏感也需要篩查。使用S3相容對象存儲、CIFS/SMB、NFS等存儲設施中轉數據,也需要能進一步識別。微服務sidecar鏡像過來的流量得能接住,API閘道也需要提供挿件支持,分佈在全球各地的流量探針要考慮如何彙聚海量日誌,5萬正式員工加3萬外包電腦使用API的行為如何準確發現异常並定位,等等,各種各樣的複雜情况都需要考慮到,廠商產品化工程壓力山大。

只監視自己公司內部業務系統之間的數據流動?那頂多覆蓋了5%不到的風險區域。真正重要的風險不是簡單標記資料傳輸就能描述清楚的。例如,呼叫中心客服虛擬桌面系統和後臺業務訂單系統每天傳輸100萬條客戶數據,這倆系統之間本來就應該有數據流動且看起來完全正常,那就沒有風險了?真正的威脅隱藏於每一條API使用的過程中,可能只有1%的資料交換是風險,特權用戶惡意下載、帳號洩露盜用、用戶許可權提升、訪問鑒權缺失、敏感數據意外暴露、隱蔽後門介面等等,都可能造成嚴重後果,這可不是只看數據流動就能發現的,需要從身份、應用、數據三個角度出發綜合考慮才能有效檢出。

境况不佳的API安全初創公司

創業首先要選好方向,否則血淚一把。Chronicle被拋弃一點兒都不令人意外,就算是含著金湯匙出生的行業大佬,妄圖不顧市場規律逆勢而行,也都會撞到頭破血流慘澹收場,類似故事在各行業都是持續上演屢見不鮮。API安全並非新事物,歷史悠久,七八年前就有,但直到今年才初露崢嶸,剛需且市場潛力巨大,是創業的好機會。同時,API安全註定是紅海。若創業選擇此方向,必須認真考慮自身團隊的核心能力是不是有機會在千軍萬馬中跑出領先身比特。筆者注意到美國有兩家此領域創業公司已經解散關門,大部分團隊都出現了增長緩慢和融資困難的現象。所以,筆者去年底也斟酌良久才確定投入資源。創業維艱。過去幾年相對準確的預測,並不代表筆者這次不會犯錯誤,想進入此方向的讀者請自行認真考慮並承擔風險。

想做好API安全產品還是蠻難的,領域多且複雜,功能範圍分佈較廣,門檻較高。此處,我們粗略看看幾家被分析師提及的創業公司的產品方向,讀者可以感受一下不同廠商之間的區別有多大。另外也能得出不要盲目崇拜國外廠商的結論,因為大部分做得實在很一般,分析師地域偏見十分明顯。

42Crunch

已有4年歷史,專注於OpenAPI,總部位於倫敦,團隊經驗豐富,前Axway和IBM等經歷,但融資並不順利。其產品提供三種能力。首先,根據OpenAPI標準規範,檢查提交的API定義是不是滿足安全要求。其次,動態檢測API服務是否遵循API定義,報告總結掃描內容和管道,包括回應時間、收到的HTTP狀態程式碼、以及意外響應狀態程式碼等。最後,API防火牆,使用C編寫,Docker鏡像,sidecar牽引流量已經是標準配置,只能工作在Kubernetes環境下,必須連接42Crunch的平臺。筆者聽過其創始團隊的幾個議題,感覺他們確實對API實踐經驗豐富,只是這產品形態距離進入大規模推廣階段還有不少阻礙。筆者很難看好其未來發展,團隊還需要主動尋找轉捩點。

Aiculus

2017年10月成立,位於墨爾本,融資歷程慘不忍睹。其使用人工智慧AI自動檢測和封锁試圖盜取數據和欺詐性的API使用。下麵一段是Aiculus文宣的機器學習實際用例。

利用8000+用戶認證和訪問日誌的歷史資料對神經網路模型進行訓練。歷史資料由13個特性組成,包括用戶請求訪問系統或進入物理建築時收集的用戶内容參數。利用這些數據對機器學習引擎進行訓練,使其能够準確預測平臺上的訪問分配、訪問拒絕、再認證和用戶意圖。

“進入物理建築”?門禁確實勉强能跟API扯上關係吧。8000+用戶在澳大利亞算個不錯的案例了,在國內真不是能值得吹噓的規模。讀者可以看出,Aiculus從身份安全切入API安全的路徑選擇。

Data Theorem

業界一直有個傳說,不需要融資就能快速發展的創業公司才是真正生猛强大。大家聽聽笑笑也就算了,別當真。不燒錢還想高速增長,在今天的國內安全市場無異於天方夜譚,大部分企業服務公司燒錢還見不到增長呢。不過凡事必有例外,Data Theorem就很神奇,員工規模達到300人,卻沒看到任何公開的融資資訊。2013年成立,最初做移動安全,現時已轉向應用安全,API安全是業務重點。創始人為20年連續創業者,有兩家公司被收購的歷史。

Data Theorem提供兩款產品,API Discover和API Inspect。Discover能持續自動在客戶公有雲基礎設施中發現新的API、記錄已知API的更改、以及與這些API相關的其他雲服務。Discover產品還能讓安全和運營團隊發現Shadow API,基於雲的分析引擎不斷掃描Serverless應用程序,一旦發現就會生成警報並通知安全團隊。Inspect分析引擎持續對API的身份驗證、加密、源碼、和日誌進行安全評估,確保API操作功能與其定義相匹配,並報告關鍵漏洞警報。

下圖是Data Theorem建議的API安全實施步驟,沒有常見的諮詢機構的高大上體系,只能做落地實用參攷。

imVision

雖然融到錢但很少以至於日子過得十分慘澹的以色列廠商。其產品介紹無足稱道,筆者都提不起興趣多寫兩句。生搬硬套的人工智慧驅動,如下張幻燈片講自然語言處理識別API模式。

FX Labs / CyberSecuriti

落寞的矽谷公司,融不到錢,創始團隊已有變動。大家看到這裡是不是已經對API安全創業失去信心了?這個公司產品以漏洞掃描為主。

Sapience

類似的漏洞掃描方向。同樣沒錢的小團隊。

CloudVector / ArecaBay

今年RSAC上筆者就注意到此家,2018年正式成立,華裔創始人,行業經驗豐富,參與創辦過Netskope,再之前是一家被McAfee收購的團隊成員。直到今年11月才宣佈獲得500萬美元投資,公司改名,同時空降CEO和CFO。其產品主要包含三種能力:

API檢查模塊AIM:全自動微感測器模塊持續發現連接到企業資產的所有API,包括影子API。

深度API風險追踪器DART:深度監控模塊將經驗證過的機器學習應用於客戶特定的API藍圖,驅動API風險的自動識別,更重要的是還能實时檢測對手嘗試偵查的行為。

API響應模塊ARM:實时響應模塊能針對API濫用強制實施安全性原則,是完全解决OWASP API Top 10的唯一解決方案。

此處放一張今年3月ArecaBay文宣資料照片,限於篇幅就不放更多資料了。

各位看官有沒有很失望,以為分析師推薦廠商列表能讓人眼前一亮,實際看下來大部分都是三脚猫水准,要是拿這麼低完成度的產品去忽悠國內大甲方,還不得被口水噴到體無完膚。這也從另一個角度說明,現在安全行業需求水准日益提高,想做好一個企業級產品,最少投入的資金,在美國至少兩千萬美元,在國內至少四千萬人民幣,不融資幾乎不可能。想反駁的,請別用開源項目糊弄產品靠銷售硬塞的例子留言給筆者。如果吹牛巨額融資花了一個億重金精雕細琢出一個產品來,也請投資者擦亮眼睛避免入坑,原因很簡單,國內安全產品的毛利水准根本撐不起如此揮霍。

筆者研究後發現,論API安全產品品質,現時美國市場上的幾個大廠明顯優於大部分創業公司,恐怕國內也會面臨相同局面,至少頭部公有雲廠商肯定會自行研發,自用然後嘗試輸出。囙此,創業團隊要對潜在競爭有清醒認識,並擁有足够信心在產品上直面競爭。

市場大勢,此消彼長。五年前做API安全,毫無疑問會成為被拍在沙灘上的前浪,那時的契機是WAF。現在進入API安全,機會與風險並存。做好準備面對大額資金投入的一線廠商吧。小公司如果能過好產品關,即使身處激烈競爭的紅海,也許運氣會和你站在一起,成功可期。