創新沙盒，由開源商業模式說起 - RSAC2019之一
前言
前段時間微信群裡有朋友說起，今年RSAC創新沙盒入圍的企業，感覺毫無新意和亮點，平淡無奇；緊接著另一個朋友有感而發，說及最近看到的分析師文章，總覺得炒冷飯和譁眾取寵成分居多，也十分平庸；於是大家都紛紛聊起來，安全行業近兩年創新不夠。很有道理的觀察，筆者完全同意。不過要補充一點：不是因為別人變矮，而是因為我們的眼界變高：過去四年，筆者親眼目睹了國內安全技術的飛速發展，在某些領域，國內先進水平廠商至少能跟創新沙盒入圍者相提並論，甚至還有明顯勝出。即使國內行業大生態對創新並不友好，天量預算被巨頭把持，去年業界增長也令人失望，但革新與開拓並未被遏制，無論是大廠或是初創小公司均有耀眼貢獻。
於是，創新沙盒評論便愈發難寫，介紹入圍者的文章多到汗牛充棟，讀者並不感冒淺嘗即止的內容，堆砌華麗詞藻更會被嗤之以鼻，筆者亟需找到一些獨特的角度才能滿足眼界變高的讀者們的胃口。如果我們能拋棄吹捧，透過花哨探究本質，試圖不放過產品和業務的弱點，對提高自己獨立思考的能力便有莫大好處。
今年，讓我們以擁有或依賴開源專案的創業公司作為開局。
Duality Technologies
創新沙盒也有賽道一說：密碼學自然是一條，每年都會出現一家入圍。在筆者看來，還要加上一條Team8：安全創業孵化器，班底是前以色列網路安全部隊Unit 8200，每年必霸佔一席。16年是Illusive，17年是Claroty，18年是Hysolate，今年便是Duality，拭目以待Portshift明年會不會出現。
Duality使安全的資料協作成為可能，企業可以將高階分析和AI應用於加密資料，無需公開原始資料即可獲得對資料的洞察。沒有驚奇，技術方向是同態加密的應用，17年入圍公司Enveil也是。Duality，對偶，公司名字真是妙手天成，恰到好處地融合了應用場景與數學含義。
同態加密被正式廣泛研究已經有十年曆史，現有演算法都是基於格密碼(Lattice)理論的。Duality創始團隊有兩位大學教授，長期研究密碼學，建立了開源專案PALISADE，高度模組化的通用格密碼實現庫，包含同態加密演算法，有DARPA等政府機構的資金支援。這是個價值極高的基礎設施級別的開源專案。題外話，Lattice-based演算法是可以對抗量子計算機的，其實有很多加密演算法在理論上也是安全的，並沒有一般科普文章寫得那麼誇張；類似DH也可以用格密碼改造。
Duality的產品SecurePlus是個多方共用的中間平臺，官方設計了三種應用場景。
資料所有者可在不公開敏感資料的前提下利用第三方分析和AI，此過程中資料受到端到端加密保護。還可在不受信任的雲環境中操作。
分析模型所有者能安全地將其模型提供給資料所有者進行高階計算和分析，能確保其寶貴的AI演算法模型產權在整個過程中得到完全保護。
多方安全協作處理敏感資料。同態加密在連結和計算過程中保護每一方的資產，確保資料隱私和整個過程的法規遵從性。
請注意，上述三種場景對於演算法的要求是有區別的。在隱私和資料保護監管收緊的大環境下，安全多方計算目前也是個大熱點。大部分讀者可能會以為保護資料隱私就夠了；而實際情況是，分析函式的祕密性也要保護，這也是數學家們努力的方向之一。
格密碼體制由於其運算具有線性特性，比RSA等經典公鑰密碼體制具有更快的實現效率；又由於該類密碼體制安全性基於NP-Hard或NP-C問題，使其能抗量子攻擊。此外，格運算具有同態性，這也使格密碼演算法能適用於各種同態加密的應用場景。因此，有希望發展成下一代大範圍應用的標準密碼庫。
密碼學是資訊保安的重要基石。但在歷史上，除RSA成長為一家巨頭外，幾十年來專注加密的公司屢見不鮮，卻難有大作為。而Duality是一家安全行業極為少見的、對重要開源專案擁有話語權的創業公司，筆者抱有很高的期望。
開源專案的經濟原理與商業模式
過去二十年的網際網路創新與開源專案息息相關。免費開發程式碼且使用限制極少，聽起來美好到不像真實世界；因此，不少學者試圖用經濟學原理解釋其背後的原因。自然也有不少投資者衝進來試圖分一杯羹，不過理想豐滿現實殘酷，出現了很多失敗案例。那麼，創業公司和開源專案，應該是什麼樣的關係，才有成功機會呢？
如果我們仔細觀察RedHat這幾乎是唯一的巨頭成功案例，就會發現其除了大家熟知的開源許可外，還擁有大量商業授權許可。而這些商業許可所維護的，是眾多RedHat自研的核心程式碼，這才是其龐大帝國的根基。因此，衡量創業公司價值，無論是開源還是閉源，歸根結底都會回到技術壁壘這一基礎命題上。
有些投資者看專案，嘴上說的是看技術水平，其實內心深處對此不屑一顧，看的還是收入數字。聽起來沒問題啊，收入是不是衡量市場對技術認可程度的表現呢？賣開源發行版且銷售能力不錯的初創公司是不是值得競相追逐呢？
這背後的邏輯值得商榷。首先，在今天，服務的壁壘已經不能僅靠人員團隊了，資訊諮詢服務巨頭Accenture也擁有很多程式碼和系統的積累，正如RedHat依賴其自有智慧財產權模組一樣。安全行業裡的MSSP也是如此：如果想提供SOC服務，自己沒有一套先進的運營平臺系統，是沒有任何競爭能力的。其次，對開源專案的程式碼維護審批沒有話語權的，那並不是產品公司，那是整合商；應該按整合商的商業模式衡量其估值。原因很簡單，技術壁壘才有溢價，包裝發行版無法獲得溢價。第三，全球範圍內，已經出現多起開源專案運營公司增加商業使用限制的許可條款的案例，這對賣開源發行版的業務模式絕對是當頭重擊。最後，大部分開源專案是基礎通用型的，需要找到合適應用場景才能大規模商業化。
而Duality正是一家滿足上述邏輯的開源專案創業公司，筆者也希望其能挖掘在密碼領域和行業應用的發展潛力，做大做強。下面我們再來看看其它有開源專案的入圍者。
Capsule8
Capsule8是業界唯一專為Linux生產系統構建的實時零日漏洞檢測平臺，無論是容器、虛擬機器、還是裸物理機。官方宣傳口徑。你信嗎？反正我是直接忽略。國內就好多做的，更甭提全球範圍。創始人John Viega履歷光彩奪目，業界資深專家，團隊也有不少著名黑客。
主機防護，相信大部分讀者都很熟悉，筆者此處就不過多介紹了，撿些Capsule8特有的講講。其產品平臺強調的能力包括：可見、檢測、調查、瓦解、整合，花了濃重筆墨渲染自動化瓦解入侵。筆者在去年ISC會議上的演講議題是《免疫：智慧自動化響應瓦解攻擊鏈步驟》，現場也做了實際演示。這是行業發展趨勢共識，不乏類似的努力。
Capsule8的開源sensor用Go寫成，基於Kprobes，使用gRPC。筆者第一反應，看起來是Google派系的。果然，稍後就翻看到官方視訊專門演示與Google雲管理介面整合，技術路線就決定其它雲沒那麼容易集成了。當然，用Capsule8自身管理介面也可以支援AWS和Azure。多雲也是有技術壁壘要克服的。
技術路線選擇很費腦力，也必須認真，否則會導致事倍功半。Capsule8初創時的戰略瞄準容器，自然Go是第一選擇，因為容器世界底層是Go語言的天下。生產環境中效能十分重要，雖然Go效能比不上C，尤其是Regex處理速度差距較大，而Kprobes開銷也不小；但考慮到相容穩定與未來擴充套件，如此選擇還是蠻有道理的。
選擇部署哪個開源agent這事兒也兩難。Capsule8的sensor是輕，只採集跟安全相關的資料，主要有FileEvent、KernelFunctionCallEvent、NetworkEvent、PerformanceEvent、ProcessEvent、SyscallEvent、UserFunctionCallEvent、ContainerEvent等；部署一個agent只做0-day檢測感覺價效比不高。不過，osquery在核心呼叫檢測方面是短板，目前只支援auditd，Kprobes和eBPF的支援還在開發中，不知道要等到啥時候。甲方同學需要自己權衡。
採集主機資料之後，還要看看管理端是如何進行資料分析以實現檢測的。
說實話，成立兩年多的公司，這管理介面有些寒酸。大規模部署，看報警恐怕會瘋掉。有查詢介面也是題中應有之義，新產品需要支援威脅獵捕Threat Hunting。筆者最關心的檢測技術說明，居然找了半天找不到。不提機器學習，不提行為分析，不提Yara，不提資料分析，總不會報警全靠人看吧。比賽上臺面對評委時，難道也要回避這塊關鍵技術能力不說？就看到演示介面裡一堆Interactive Shell Executed了，貌似是基於一些預先定義的規則，不知道如何更新。
看過演示再對比這張安全運營能力圖，結論是產品團隊未來要走的路還很長。如此看來，Capsule8的開源專案也沒多高價值。筆者只能去RSAC展臺現場看看產品最新版本做到什麼程度。
Capsule8的投資者是美國兩個頻繁出手安全領域的VC：ClearSky和Bessemer (BVP)。有趣的是，他們與創新沙盒結緣頗深，在其投資名單上可以看到很多熟悉的公司，如這幾年的Axonius、BigID、Claroty、CloudKnox、CyberGRX、Hysolate。
ShiftLeft
ShiftLeft是應用安全的持續改進平臺，於自動化工作流中，將下一代靜態程式碼分析（以快速準確地識別漏洞）與應用插樁檢測（以保護生產環境應用）結合在一起。這種“理解執行狀態的程式碼分析”和“理解程式碼的執行時保護”的結合提供了精確、自動化、和覆蓋全面的應用安全解決方案。組合方案，前者是SAST，還有些許SCA，後者是部署在生產的IAST、以及RASP的混合體。官方宣傳後者是獨創，確實有些新意，能加快DevOps的速度。工作流如下圖所示：
公司名起得也不錯。Shift Left Testing，左移測試，是軟體領域歷史悠久的概念。這名詞也讓筆者回憶起小時候在微控制器上撥動二進位制開關輸入左移位運算指令的操作。左移的含義，跟現在業內宣傳的安全規劃前移至應用系統架構設計階段是類似的。將關鍵測試實踐前移到SDLC早期階段，尤其適用於敏捷開發、持續迭代、和DevOps場景。傳統上，測試活動多發生在研發後期，往往需要更長時間才能找出問題所在，並且需要花費更多的時間來修復。左移是指將程式碼缺陷的識別和預防轉移到更早的階段，否則如果後期測試出問題，往往能做的就只是修補，而非正確的修復。
應用安全是行業持久熱點，新方向新技術層出不窮。ShiftLeft吸引人的產品創新有兩處，一是在靜態程式碼分析時引入圖演算法，比之前傳統程式碼檢測演算法能更好地發現某些類別的漏洞；二是在靜態分析階段引入所謂安全DNA概念，用於指導生產環境中的IAST和RASP的執行。
首先，SAST的創新來自於學校研究，基於程式碼屬性圖CDG的漏洞發現，論文如下。
此研究成果誕生了開源專案Joern，可以掃描Java和C/C++程式碼，並生成三類屬性圖：抽象語法樹、控制流、和資料流。再使用圖演算法用自定義查詢就能發現潛在漏洞。值得吹噓的戰績，一次性發現Linux kernel裡的18個新漏洞。顯然是高價值的開源專案，吸引了很多眼球。ShiftLeft成立後，Joern得到繼續發展，現在的產品名稱為Ocular。官方稱目前OWASP基準測試成績最好。當然，沒有銀彈，圖演算法也不能通吃所有型別漏洞。下圖展示瞭如何用CDG發現程式碼中潛在資料洩漏的弱點，很有趣的思路。
而所謂安全DNA，是指容易出現弱點的程式碼位置，例如引入第三方開源庫、模組間傳遞引數、敏感資料使用等等。所謂MicroAgent，實質就是程式插樁，保證程式原有邏輯完整性的基礎上，插入一些探針進行資訊採集，還可以根據預定義策略做些簡單響應。有了開發階段靜態分析產生的安全DNA資訊，插樁可以更有的放矢，檢測效率更高，降低誤報。通常，快速開發迭代過程中，時間不夠用來修復所有潛在問題，必須有所取捨；而未修補之處是否存在風險，可以放到生產環境繼續監控。此種方式也加快了DevOps程序。
之後，將這些報警傳回控制檯，再用來反哺開發程式碼階段，於是便覆蓋大部分SDLC和DevOps流程。
延伸思考，Joern自然也可以用於紅隊。上面提到過，CDG可以繪製資料流，那麼自然而然地我們會想到，合法資料輸入可作為暴露在外的攻擊面，如果能梳理此輸入資料在程式中被處理的程式碼段有哪些，我們就可以有針對性地檢查，那些程式碼段中是否存在沒做好“消毒”的地方，例如記憶體越界。Heartbleed漏洞即屬於此型別。如果沒有資料流圖，在龐大程式碼量中，準確定位並發現潛在風險，只能靠運氣了。
這個例項說明，只有掌握了最新的技術，才能在對抗中獲取有利位置。再優秀的安全團隊，沒有先進工具的武裝，戰鬥力都會大打折扣。
篇幅所限，筆者就不深入解釋了。目前看產品完成度較高，在創業公司裡算出類拔萃的。與其兩輪大額融資也有關，畢竟錢多更容易擴大團隊完成更多工作。
上面講到的三家擁有開源專案的入圍者，讀者更喜歡哪個？
不知道大家有沒有注意到，ShiftLeft也符合筆者前面所講的開源商業模式。以開源Joern為基礎，識別巨大市場需求，補充整合優秀人才，繼續開發更先進的技術模組，組合成更復雜的產品，建立競爭壁壘。成熟完整的管理團隊，從開源專案中發現潛力新秀，用股份相邀所有者亦即學院派研究人員，強強攜手，再造商業公司，如此套路在今天已經屢見不鮮。Duality也是相同軌跡。
如果哪位讀者對自有研究成果信心十足，歡迎找筆者聊聊。我們在採用先進技術打造全球領先產品並服務好各行業頭部使用者這方面，積累了不少成功經驗。
DisruptOps
DisruptOps為多雲基礎設施提供持續自動化監控的最佳安全實踐，以提升雲業務運營的安全性並降低成本。讀者也許已經在朋友圈看過此公司的介紹文章，都是唬人的名詞：多雲、自動化、敏捷、編排、DevSecOps、持續評估、最佳實踐、雲原生等等，還發明瞭Guardrail護欄一詞的新用法。
多雲管理市場的商業機會與重要性，筆者在去年創新沙盒文章就強調過。然而，DisruptOps你是在逗我嘛？翻遍其網站，所有能力都是針對AWS的，說好的多雲呢？筆者開始時還不相信自己，以為漏掉重要內容，於是專門用了搜尋引擎：
未見任何Azure蹤影，確實只有AWS。目測DisruptOps平臺主要使用AWS原生安全產品的API來構造，如Config、CloudWatch等；Serverless架構，大量使用Lambda指令碼。若打算將介面設計和產品功能，原封不動從AWS移植到Azure，難度不小，工作量巨大。正如上面評論Capsule8時所指出，多雲也是有技術壁壘要克服的。
DisruptOps創始團隊包括安全諮詢公司Securosis核心班底，歷來產出的研究和文章質量很高，筆者進入安全行業之初便拜讀過。可想而知，他們深諳使用專有名詞忽悠客戶之道。我們看到國外初創公司也不容易，吹噓是為了生存。DisruptOps成立於2014年，時間不短了。當然，也是因為DisruptOps客戶群體看不到本文，所以筆者才會如此直接落筆。
說實話，筆者瀏覽此公司網站之後的第一反應：這不是個產品公司，羅列的都是內部安全運營規範。最佳實踐美則美矣，但如此定位的商業模式，能否持續增長是個大大的問號。讀者們肯定見過各大廠自建開源的GitHub內容掃描工具，但業內見過廠商推出類似的標準化產品嗎？做安全產品要有足夠的能力護城河，才能維護市場競爭優勢，靠些零散拼湊的配置核查指令碼集合，就能建立壁壘嗎？需求並不一定等於生意。
什麼產品能力可以做護城河？舉個簡單例子。檔案格式解析引擎，用於拆解並匯出各種格式文件中的文字圖片等內容。迄今，全球成熟商業化供應商只有兩家，一家是MicroFocus的KeyView（之前歸屬於Autonomy和HP），另一家是思睿嘉得。KeyView不支援匯出DWG等CAD圖紙中的文字，而後者的引擎可以；KeyView不支援百度網盤大檔案分捲上傳的還原，而後者可以；等等。全球絕大部分DLP廠商都是外購引擎，從而受制於供應商的緩慢更新延遲；而思睿嘉得掌握全部自研程式碼，擁有更低的成本、更優秀的效能實現、更靈活的介面控制、以及對終端使用者需求的快速響應。唯有多個類似的、友商難以複製的技術能力，再加以堆疊組合，才能有效鞏固產品優勢。
定期更改訪問金鑰AK是一種眾所周知的安全最佳實踐。縮短AK有效時間，即使洩露，業務受到的不利影響也能被緩解。DevSecOps的實施難點，是如何定期生成新AK並準確分發，令使用對應舊AK的所有應用程式自動更新，保證交接順暢，不會造成任何故障。而DisruptOps產品確實能發現老舊的AK，但之後提供行動的選擇只有區區四個：刪除、凍結、掛起等著手工操作、以及忽視。這怎麼嵌入到DevOps流程裡？隔靴搔癢的雞肋，到底是用還是不用？另一方面，Access key age屬性，可以直接去Console查，或者寫Lambda指令碼整合到自有DevSecOps平臺裡也易如反掌，讓大甲方花錢買這個短板明顯的功能有難度，而小企業有沒有人手跟隨最佳實踐也難說，還面臨著雲服務商不遠將來也提供類似功能的競爭，例如AWS Inspector或GuardDuty加入此類報警輕而易舉。
總體來看，產品成熟度很低，過於簡單，只提供初級安全基線檢測，且未見靈活配置和擴充套件功能。概念不錯，落地差得太遠，技術門檻低，甲方評估後恐怕會得出採購不如自研的結論。從另一個角度看，DisruptOps倒是提供了一組基礎安全範本，雲安全團隊初建時可以拿來作為起步參照。
未完待續。匆匆寫就，如有錯誤不妥之處，尚請各位讀者不吝指正。