[轉]互聯網企業安全建設(一)

這篇文章挺不錯的，拿來和你們分享一下。

摘自：http://www.secpulse.com/archives/34805.html

安全行業的第三流派-CSOs

目前在大多數行業後加入者的眼中「二進制」和「腳本」流派廣爲人知，雖然他們是安全行業的主力軍，但除了微觀對抗以外安全是一個很大的工程，好比企業安全管理，我把他們納入安全行裏的第三流派-CSOs，加了s跟scriptkids同樣表示他們是一個羣體，這個羣體從生態鏈的頂端連接着絕大多數從業者和安全廠商。

企業安全是否是發現漏洞而後修漏洞，再設置一下防火牆之類的？假如你的公司只有一個產品，只有2臺服務器，只有3個程序員寫代碼，我認爲這個說法不能算錯。不過在絕大多數狀況下，企業安全遠不止於此。滲透性測試和對抗能不能算企業安全？在一個過於紙上談兵的企業我以爲這是不錯的切入點，不過局部對抗發生於企業安全的各個場景中，他只能算是縮影，不是全貌。企業安全是什麼對傳統乙方安全公司，對新興的業務安全公司移動安全公司，對甲方的互聯網公司，對甲方的傳統公司，對諮詢顧問，對漏洞研究者，對活躍於各大SRC上的白帽子們的詮釋確定都不同。

先說一下我本身的經歷，以便了解我是從什麼角度來看待這一問題的，學生時代跟如今的不少白帽子同樣玩玩滲透，玩玩二進制，在過去那個叫幻影（Ph4nt0m）的組織裏，大學畢業後即進了綠盟作安全服務和諮詢，這是乙方中離甲方安全最近的職能，接受了綠盟對傳統安全體系和方法論教育，有些10年前的東西放到今天都還會以爲很高大上，如今的安全行業裏除了顯得有些空洞的安全標準的傳承，要麼就是很淺的木桶理論之類的外延的理解，尤爲在遇到互聯網崛起時，攻防受追捧，有些東西由於沒有收到金錢的承認不少人就直接把這一部分東西給扔了或自我否認了，其實有些思想跟技術表現形式一點關係都沒有，放到今天仍然是很實用的技能。在綠盟最大的便利並非下班路上隨便都能找到能聊exploit技術的大牛，而是視野：從金字塔視角看到安全的總體解決方案，囊括組織、管理和技術3方面的東西，覆蓋全行業全價值鏈過程的技術方案，算上第三方的話幾乎涵蓋市面上全部的安全產品和解決方案。有人看到這些會問這不是傳統安全那一套嗎？我說且不急，聽我慢慢講，並且我能夠劇透的說以後幾十篇都是圍繞互聯網企業安全的，並不打算在傳統安全上花不少篇幅，只是須要區分一下企業安全實際的情況和某些廠商爲了兜售本身的產品而宣揚的概念是有所不一樣的，大多數廠商都會避開本身的弱項而在市場活動及軟文上專一的強調本身擅長的概念。離開綠盟後我去了甲方，一家大型網遊公司，08年那時將近萬臺的物理服務器分佈於30多個IDC的規模彷佛比當時搜狐全站的IDC規模還要大一些，跟如今同樣那時候也是社會上的公司廣泛缺乏安全負責人的時代，我也有幸組建了一支屬於本身的安全團隊，成爲當時少數的安全總監之一，團隊的這些人如今遍及互聯網行業的半壁江山，且都是安所有門獨當一面的骨幹。在這段時間我身體力行了從乙方到甲方視角的過渡，從零開始創建安全體系，真正把乙方玩的東西在一家甲方公司落地了，個人方法思路過程跟某些互聯網公司不太同樣，由於那時候BAT的安全人員大可能是畢業後直接去的甲方，一開始就作甲方安全，而我是從乙方到甲方，因此實踐上更多了參考了乙方的方法論，除了攻防以外多線並行，直接創建較完整的安全體系，在遇到上海的網遊業被騰訊包抄總體沉淪的時候，我也失去了繼續深挖甲方安全建設的興趣。以後我去作了一家webgame公司的技術負責人，社會俗名CTO，由安全轉向全線技術管理，說實話在這段時間裏我並非特別重視安全，一方面跟本身是安全出身有關，另外一方面這確實是屁股決定腦殼的事情，不是安全不重要，而是有不少事情比安全更重要。安全這個事情說白了就是當你有100w的時候拿出2w買個保險箱裝它們你以爲值，但你只有2w的時候要拿出8k買保險箱大多數人都會囊中羞澀。這也是我在知乎上回答的那個問題，爲何作安全必定要去大公司的緣由之一。我竊覺得不少公司的CEO、CTO的對安全重視，翻譯過來應該是：被黑是一件很負面的事情，因此想找我的籌建團隊打包了，只要不出事他們就不會太想起這事，但不是心理真的認爲安全很是重要，也不會當成是一種競爭力，這句話並非在映射過去，而是當下國內那麼多對企業安全負責人的招聘在我看來也就是那麼回事。以後我去數字公司經歷了短暫的時光，再次以乙方的身份拜訪了企業級客戶，很偶然的發現大多數乙方的顧問或工程師其實都沒有真正作過企業安全管理的經驗，雖不能把這些直接等價於紙上談兵，不過確實是乙方的軟肋，在競爭性的銷售活動中，三下五除二就「把別人說沒了」。在甲方企業高層的眼中，攻防這檔子事能夠等價於我花點錢讓安全公司派幾個工程師給我作滲透測試而後修漏洞，不像大型互聯網公司那樣上升爲系統化和工程化的平常性活動。離開數字公司後我到了全球化的公司-菊花長從事產品線安全，第一個項目是雲計算，產品線安全屬於甲方安全又跟不少甲方安全不太同樣，他比傳統意義上的甲方安全介入的更深，覆蓋率更高的SDLC，直接導向產品設計的源頭，對絕大多數甲方而言你也許在用OS的Dep&ASLR，也許在用各類容器，但你不多會本身去發明輪子，你也許會本身造一個WAF這樣的工具，但你可能不多會像微軟那樣要本身去搞一個EMET這種涉及安全機制層面的東西，但在產品線安全裏，這一切都會更進一步，不僅是像互聯網公司那樣關注入侵檢測、漏洞掃描等而是從設計和威脅建模的角度去看總體和細節的安全。這又拓展了我從R&D的視角看待以及分析安全問題的眼界。至此，我既不屬於腳本二進制，我也不屬於乙方諮詢顧問派，也不單純屬於甲方CSO，而是站在一個較全面客觀中立的立場，我不會說某些方式屬於紙上談兵，也不會把攻防捧的至高無上，我認爲這些都屬於偏激的話。

好了，切入第一篇的正題，企業安全是什麼？我認爲它能夠歸納爲：從廣義的信息安全或狹義的網絡安全出發，根據企業自身所處的產業地位、IT總投入能力、商業模式和業務需求爲目標，而創建的安全解決方案以及爲保證方案實踐的有效性而進行的一系列系統化，工程化的平常安全活動的集合。怎麼感受有點咬文嚼字？好吧，這裏面的每個項都會決定你的安全總體方案式什麼，哪怕同是中國互聯網TOP10中的公司其安全需求也徹底不同。

有人也許會以爲CSO乾的活有點虛，但凡偏管理都是紙上談兵。我不直接回答這個問題，我只舉一個例子。大多數身在這個行業的人都知道社工庫遍地都是，入侵者甚至站在了大數據的維度，國內的數據庫絕大多數除了password字段加鹽值存儲，其他信息都是明文保存。而在歐美等地隱私保護是有明確的法律規定的，映射到數據持久化這個細節，就是須要知足必定強度以上的加密算法加密存儲，CSO就是須要制定這些策略的人，你難道說這些都是形而上學無用的安全措施麼？在互聯網公司，安全負責人是會較多的介入到平常的技術性活動中的，但隨着組織規模的擴大和官僚程度的加深，CSO再也不可能表現的像白帽子同樣專一於攻防對抗的細節也是一個沒法迴避的現實問題。是否是必定要說出諸如CSRF時IE和其餘瀏覽器的區別這樣的問題纔算是合格的CSO，我以爲這個看具體場景，對於國內排名TOP5之後的互聯網公司我以爲這個需求算合理範疇，但對於規模很是龐大的公司而言，這個需求顯然太苛刻了，好比我所在公司，CSO屬於法務類職位而不是技術類職位。

不想當將軍的士兵不是好士兵，雖然有技術路線，不過我估計這個行業裏至少有一半以上人想過要當CSO，可是CSO這個職業又跟某些大牛們表達的不徹底一致，因此下面的篇幅會繼續寫，至少在技術層面，CSO不會只停留在微觀對抗，而是會關注系統性建設更多一點。（http://www.ayazero.com/?p=8）

 

企業安全涵蓋哪些事情

從我在綠盟所受的安全教育來看大體分爲如下幾方面：
1. 網絡安全：基礎、狹義但核心的部分，以計算機（PC、服務器、小型機、BYOD……）和網絡爲主體的網絡安全，主要聚焦在純技術層面
2. 平臺和業務安全：跟所在行業和主營業務相關的安全管理，例如反欺詐，不是純技術層面的內容，是對基礎安全的拓展，目的性比較強，屬於特定領域的安全，不算廣義安全。
3. 廣義的信息安全：以IT兩個字爲核心，包括廣義上的「Information」載體：計算機數據庫意外還有包括紙質文檔、機要，市場戰略規劃等經營管理信息、客戶隱私、內部郵件、會議內容、運營數據、第三方的權益信息等但凡你想獲得的都在其中，加上泛「Technology」的大安全體系
4. IT風險管理、IT審計&內控：對於中大規模的海外上市公司而言，有諸如SOX-404這樣的合規性需求，財務以外就是IT，其中所要求的在流程和技術方面的約束性條款跟信息安全管理重疊，屬於外圍和相關領域，而信息安全管理自己從屬於IT風險管理，是CIO視角下的一個子領域
5. 業務持續性管理：BCM（Business Continuity Management）不屬於以上任何範疇、但又跟每一塊都有交集，若是你以爲3和4有點虛，那麼BCM絕對是面向實操的領域。最近前有網易、中有支付寶、後又攜程，由於各類各樣的緣由業務中斷，損失巨大都屬於BCM的範疇。有人會問這跟安全有什麼關係？安全是影響業務中斷的很大一部分可能因素，例如DDOS，入侵致使必須關閉服務自檢，數據丟失隱私泄露等。又會有人問這些納入安全管理便可，爲何要跟BCM扯上關係，作安全的人能夠無論這些嗎？答案天然是能夠無論，就好像說「我是個java程序員，JVM、dalvik（ART）運行原理不知道又有什麼關係，徹底不影響我寫代碼！」 事實上BCM提供了另外一種更高維度，更完整的視角來看待業務中斷的問題，對於安全事件，他的方法論也比單純的ISMS更具備可操做性，對業務團隊更有親和力，由於你知道任何以安全團隊自我爲中心的安全建設都難以落地，最終都不會作的很好
6. 安全品牌營銷、渠道維護：CSO有時候要作一些務虛的事情，例如爲品牌的安全形象出席一些市場宣介，presentation。籠統一點講如今SRC的活動基本也屬於這一類。
7. CXO們的其餘需求：俗稱打雜。這裏你不要理解爲讓安全團隊去攻擊一下競爭對手的企業這樣負面向的事情，而是有不少公司須要作，但運維開發都不幹，幹不了或者不適合乾的事情，安全團隊能力強大時能夠承包下來的部分，事實上個人職業生涯裏就作了很多這樣的事情。

基礎的網絡安全是絕大多數在甲方的安全團隊能cover的事情，無論你的安全團隊能力如何，在公司裏有無影響力，這個是必需要作的由於這是把你招過來的初衷。再日後的發展，是否止於此則看各人的想法，對於沉醉攻防技術的人其實不須要日後發展了這些足夠了，但若是你的安全團隊富有活力和想法，即使你想止於此他們也不幹，把部門作大作強是這些人的願望，只有這樣才能給安全團隊更大的空間，由於這點跟乙方是不同的：對於乙方而言你能夠在某個單點領域上無限深挖，而不會遇到天花板，由於你始終是在知足主營業務的需求，即便你成爲骨灰級的專家公司也會對你在某方面創新有所期待而給你持續發展的可能性，可是在甲方，安全不是主營業務，歸根結底是一個保值型的後臺職能，不是一個能創造收益的前臺職能，他是一個成本中心而非盈利中心，他的成本的大小跟業務規模以及公司盈利能力相關，公司發展時他的budget和headcount會發展，業務停滯時安全作的再好也不會追加投入，由於無此必要。反面的例子也有：作的很差反而追加投入的，那是一種政治技巧而非現實須要。若是你在乙方的研究部，不管你的漏洞挖掘技能多牛逼，公司都不會跳出來講「你已經超出咱們需求了，你仍是去更NB的公司吧」（一般狀況）。可是在甲方，假設是在一個國內排名大約TOP5-TOP10的互聯網公司，養一個漏洞挖掘的大牛也會以爲很奇怪，他是在給公司創造價值仍是在自娛自樂是會受到質疑的，CSO也會被質疑是否花了大價錢挖來的人不是出於業務須要而是用於擴大本身團隊在業內影響力這種務虛的事。假如公司到了google這種級別，有一大堆產品，儲備大牛則是順利成章的，業務上顯然是有這種需求的，不過仍是要看產出是否對主營業務有幫助，工做成果不能轉化爲主營業務競爭力的嘗試性活動在公司有錢的時候無所謂，在公司收緊腰帶時則其存在價值會受到質疑。

以狹義的安全垂直拓展去發展甲方安全團隊的思路本質上是個不可控的想法，籌碼不在CSO手中，甚至不在CTO手中，而是看主營業務的晴雨表，也就是我之前微博上說的，甲方安全是要看「臉」的，這個臉還不是指跨部門溝通合做，而是在最原始的需求出發點上受限於他們。所以有想法的安全團隊在（1）作的比較成熟時會轉向（2），（2）是一個很大的領域，發展的好安全團隊的規模會x2，x3，而且在企業價值鏈中的地位會逐漸前移，成爲運營性質的職能，結合BCM真正成爲一個和運維、開發並駕齊驅的大職能。

BCM在不少人眼裏就是DR（災難恢復），DR其實只是BCM中的一個點，屬於下層分支。不過這對技術領域的人而言是最直觀的部分，DR在互聯網公司裏由基礎架構部門或運維主導，不過對於強勢的甲方安全團隊其實也是能參與其中一部分的，我以前也主導過這些，固然也是受到了綠盟的教育以及個人「前輩們」的啓發。有興趣的能夠看一下BS25999

廣義的信息安全，比較直觀的映射就是ISO2700x系列，行業裏的絕大多數人都知道ISO27001和BS7799.不展開了，對真正有安全基礎的人而言都是很簡單的東西。在企業裏可否作到廣義的安全，主要看安全負責人和安全團隊在公司裏影響力，對上沒有影響力，沒有詮釋利害關係和游水的能力天然也就作不到這些，另外一方面，狹義安全主要對接運維開發等技術面公司同僚，可是廣義安全會對接整個公司的各個部門，對於溝通面的挑戰來講又上了一個新的臺階，彷佛在我看來這主要取決於安全的領隊人物本身擁有什麼樣的知識結構以及他的推進能力如何。

對於（4），若是你所在的組織有這方面的需求，安全職能天然也會參與其中，是否刻意去發展他則看本身需求，對我朋友中某些作過IT治理和風險諮詢的人相信是有能力一併吃下的，若是是技術派我就不建議你去搞了。

（6）屬於水到渠成的事情，到了那一步你天然須要考慮，就算你不想公司也會讓你去，就像我如今明明作技術活，卻也不知道爲啥會跟這一類事情掛上鉤。

（7）有人看時自動過濾了，不過安全負責人自身是否有瓶頸，可否在企業裏發展起來跟這條有很大關係，甚至有不少從（1）發展到（2）（3）的人都須要藉助（7）這個渠道，點到爲止很少說了。。。

對於互聯網公司，我建議作一、二、5；對於傳統行業，我建議作：一、三、四、5。

在互聯網行業安全包括哪些內容，我以爲能夠歸納爲：
信息安全管理（設計流程、總體策略等），這部分工做約佔總量的10%，比較總體，跨度大，但工做量很少。

基礎架構與網絡安全：IDC、生產網絡的各類鏈路和設備、服務器、大量的服務端程序和中間件，數據庫等，偏運維側，跟漏洞掃描，打補丁，ACL，安全配置，網絡和主機入侵檢測等這些事情相關性比較大，約佔不到30%的工做量。

應用與交付安全：對各BG，事業部，業務線自研的產品進行應用層面的安全評估，代碼審計，滲透測試，代碼框架的安全功能，應用層的防火牆，應用層的入侵檢測等，屬於有點「繁瑣」的工程，「撇不掉、理還亂」，大部分甲方團隊都沒有足夠的人力去應付產品線交付的數量龐大的代碼，沒有能力去實踐完整的SDL，這部分是當下比較有挑戰的安全業務，總體比重30%+，還在持續增加中。

業務安全：上面提到的（2），包括帳號安全、交易風控、徵信、反價格爬蟲，反做弊反bot程序、反欺詐、反釣魚、反垃圾信息、輿情監控（內容信息安全）、防遊戲外掛、打擊黑色產業鏈、安全情報等，是在「吃飽飯」以後「思淫慾」的進階需求，在基礎安全問題解決以後，愈來愈受到重視的領域。總體約佔30%左右的工做量，有的甚至大過50%。這裏也已經紛紛出現乙方的創業型公司試圖解決這些痛點。

對總體介紹的部分在前面的篇幅講的比較多，主要目的是但願「視野」部分不縮水，這些概念在後面篇幅都不打算再展開了，若是你遲遲沒看到技術篇，很正常，這只是一個開頭而已。下一篇談談互聯網企業安全管理和傳統行業安全管理的區別。（http://www.ayazero.com/?p=19）

互聯網企業安全管理和傳統行業的區別

整體來看，傳統安全偏重管理，「三分技術，七分管理」，互聯網行業偏重技術，我認爲應該倒過來。其實這種說法也是不許確的，到底什麼算技術，什麼算管理，這些都沒有明確的定義，安全領域大部分所謂管理不過是組織技術性的活動而已，充其量叫技術管理，若是你較真這些理論那你就掉坑裏了。

先說一下傳統安全和互聯網安全的建設需求上的差別：

傳統安全：

1. IT資產相對固定
2. 業務變動不頻繁
3. 網絡邊界比較固定
4. IDC規模不會很大甚至沒有
5. 使用基於傳統的資產威脅脆弱性的風險管理方法論加上購買和部署商業安全產品（解決方案）一般能夠搞定。

互聯網安全生態，對於大型互聯網而言，須要應對：

• 海量IDC和海量數據
• 徹底的分佈式架構
• 應對業務的頻繁發佈和變動

同時架構層面關注：

• 高性能
• 高可用性
• 擴展性
• TCO（ROI）

在規模不大的互聯網公司，傳統的風險管理方法論是能夠沿用的，但在大型互聯網公司傳統的方法論可能會失效，由於你可能連基礎架構上跑什麼業務都搞不清，你想理清全部的系統接口間的調用關係以及數據流去檢視設計風險以及設置細粒度的訪問控制就是件不現實的事情，產品線極多時業內沒有任何一個團隊敢說本身有能力支持全產品線，對於高速發展的業務，當你理清了你想要的說不定架構又發生變化了，只有對佔公司總體營收比較主要的以及培育性質的戰略級的核心業務纔有必要去深刻調研並隨之update，其餘的仍是要依靠自動化手段。

從安全建設上來看，傳統安全建設：

在邊界部署硬件防火牆、IPS/IDS、WAF、商業掃描器，堡壘機、在服務器上安裝防病毒軟件，集成各類設備、終端的安全日誌建設SOC，固然購買的安全硬件設備可能遠不止這些。在管理手段上比較重視ISMS（信息安全管理體系）的建設，重視制度流程、重視審計、有些行業也必須「等保合規」。

其實這裏還有一個很大的區別就是，互聯網有生產網絡和辦公網絡的概念，即使最近Google聲稱取消內網也是針對辦公網絡而非生產網絡，互聯網行業的大部分安全建設都圍繞生產網絡，而辦公網絡的安全一般只佔總體的較小比重。可是對於某些傳統公司，他可能徹底沒有生產網絡而只有辦公網絡，他的網絡安全也就變成了辦公網絡的網絡安全。但我推測隨着社會互聯網+進程的加速，不少傳統的公司也會有本身的生產網絡，最終都變成和互聯網公司同樣的形態。因此對於那些在給傳統企業客戶提供諮詢和解決方案的乙方的同窗，若是大家不學習互聯網安全，也會被淘汰。

互聯網的生產網絡的解決方案基本上都是以攻防爲驅動的，怕被黑、怕拖庫、怕被劫持就是安全建設的最直接的驅動力，互聯網公司基本不太會考慮等保、合規這種形而上的需求，只從最實際的角度出發，這一點是比傳統行業更務實的地方。最近也遇到一個例子，說要在服務器上裝防病毒軟件，一看就知道是傳統行業來的思路，不是沒有真正作過互聯網企業安全就是沒被業務線挑戰過，在大型互聯網，光是性能損耗、運維成本和軟件成本這幾條就能分分鐘把這種需求幹掉，更不用進入對於服務器防禦這種更實際的話題了。不少標準說到底都是各廠商參與編寫，博弈並達成妥協，有利於本身產品銷售的代言白皮書，並非徹底站在建設性的角度的，做爲乙方賣賣無腦客戶賺點錢天然無可厚非，但在真正的甲方作企業安全生搬硬套是會受到質疑並逐漸失去影響力的。

對於超過必定規模的大型互聯網公司，其IT建設開始進入本身發明輪子的時代，安全解決方案開始局部或進入所有自研的時代，例如不會購買硬件防火牆，而是用服務器+Netfilter的方式自建，不會部署硬件IDS/IPS，而是用其餘方式來解決這個問題。其實不難理解，規模小的時候買臺硬件防火牆放在最前面，省事。可是規模大了我去買1000臺硬防放在IDC機房？光￥就受不了啊。其次，基於CAP理論和Map-reduce衍生的一系列互聯網架構，本質上都具備「無限」水平擴展能力，而傳統的硬件盒子式的解決方案其設計大多源於對過去體系架構的理解，基本不具有擴展能力，徹底不能適應大規模的互聯網架構，整體上屬於相對封閉的單點式防禦。在這種狀況下甲方安全團隊本身動手去打造徹底圍繞自身業務的解決方案也就成了必然趨勢。

自研或對開源軟件進行二次開發+無限水平擴展的軟件架構+構建於普通中低端硬件之上（PC服務器甚至是白牌）+大數據機器學習的方式是目前大型互聯網公司用來應對業務的持續性增加的主流安全解決方案。是否真的到了機器學習階段這個有點難說，可是安全進入大數據時代則是很稀鬆日常的事了。

對辦公網絡和僱員信息安全管理而言，互聯網公司的文化比較open，通常不太會維持激進的安全政策，這點也是跟傳統行業差異比較大的地方（http://www.ayazero.com/?p=25）

 

針對中小企業的安全解決方案

爲了快速成文的無腦版本，基本沒去思考，趕工跡象嚴重，將就吧。。

 

大規模生產網絡的縱深防護架構

縱深防護這個在安全行業被用的很爛的詞，乙方的顧問寫方案時信手捏來，我想你們的理解可能並不一致。其實我比較贊同lake2用的「河防」以及數字公司用的「塔防」的概念，這些都是比較貼近實際的。下面的篇幅僅從本身的理解來展開，而且主題限定在大規模生產（服務）網絡而不是辦公網絡。當下各安全公司都偏心APT和大數據威脅情報之類的概念，在辦公網絡我想這些是他們圈地運動的戰場，不過生產網絡彷佛仍然遙遠。自動化運維的交互模型跟大幅度人機操做的辦公網絡徹底不一樣，並且如今號稱機器學習的方法在實操中表現的很通常，效果不如對攻防模型抽象後定義規則的方式。這裏並非在否認機器學習的方法，只是表達離成熟還尚有距離（我不是在說QVM，請不要對號入座）

         先說一下互聯網安全的一些理念性的東西，首先沒有漏洞是不可能的，互聯網追求快速交付，把安全作的太厚重是「不知足業務需求的」，爲追求極致的低缺陷率而大幅增長髮布成本是不切實際的，可是互聯網安全有幾個比較核心的需求：快速檢測、有限影響、快速溯源，快速恢復。通俗解釋一遍就是：容許帶着一些問題上線，可是有bug或入侵我能快速檢測到而不是無知無覺的狀態，就算髮生了攻擊或入侵，我能作到入侵者所獲取的權限和形成的影響儘量的小，而且我有途徑或快照還原入侵過程作根因分析，安全事件能在基本不響應不中斷業務的狀況下恢復到健康狀態。固然這個話題也太大，此次只討論其中關於「有限影響」的部分，在談及防護以前先看一下攻擊路徑：

 

Plan-A：一般路徑，從目標系統正面找漏洞，遠程直接rootshell在現代基本沒有了，大多數是從應用爲入口，先獲取上層應用的權限，而後經過上傳webshell等方式間接得到系統shell，最後提權得到rootshell，後面繼續擴大戰果的事情就不提了，安全建設的思路天然是要反過來，阻止你擴大戰果。

Plan-B：若是正面沒有明顯可利用的漏洞的話就須要曲折迂迴，從周圍信任域開始下手，這個信任域是廣義上的，包括可arp重定向的，可嗅探的，可會話中間人的，可鏈路劫持的，相同內網的，口令知足同一規律的，互聯互通訊任關係的，災備或鏡像站點等，獲取一個點後再折返，以後的路徑與A相似。

Plan-C：直接針對生產網絡不行的話，就須要考慮社會工程學了，針對管理員和辦公網絡的APT，水坑攻擊，針對應用後臺管理員的社會工程學技巧，搞定SA天然也就搞定了全部服務器。

 安全建設是反入侵視角，針對攻擊活動中的每一步「埋點」，埋點的寓意在於我假設攻擊者到了這一步，我要阻止他進入下一步或者不能帶着徹底的火力進入下一步還能全身而退。固然這裏只針對有限影響，入侵檢測之類的部分這裏先不展開，後續會有專門的話題。

 

第一層安全域劃分，這個安全域是對業務的抽象，並非對物理服務器的劃分，在大規模分佈式架構中，同一個安全域的機器可能並不必定位於同一個物理機房，可是他們對應相同的安全等級，共享一組相同的訪問控制策略，只對其餘安全域或Internet暴露有限的協議和接口，即便攻擊者滲透了其餘相鄰的服務器，也只能掃描和訪問這個安全域內有限的幾個端口，沒辦法自由滲透，這個問題主要解決Plan-B曲線救國時被入侵者「誤傷」，以及得到單點root後進一步滲透的擴散，但願能把安全事件爆發的最大範圍抑制在一個安全域中，而不是直接擴散到全網。

第二層是基於數據鏈路層的隔離，只有2層隔離了才能算真正隔離，不然只在3層以上作ACL也是不行的，仍然會被ARP。2層使用VPC，vxlan，vlan等方法至關於在安全域的基礎上對一組服務器以更細的粒度再畫一道圈，進一步抑制單點淪陷後受害源擴大的問題。在不是特別大的網絡中能夠直接跳過安全域到這一步。固然安全域的概念在任什麼時候候都是存在的，僅僅是在作劃分的事情但不去套這個名詞。

二層之上就是協議端口狀態過濾，這是絕大多數「防火牆」的場景。解決的仍是對黑客暴露的攻擊面的問題，即便個人加固作的不到位，沒必要要的服務沒有清理乾淨，開放了有問題的端口，甚至有些端口上跑着的服務還有漏洞，可是由於被防火牆過濾了，路由不可達，因此攻擊者利用不了，他只能在對外或對信任域暴露的端口上去想辦法。本質一點就是給攻擊者提供「窄帶」，有限的訪問通道。不過在有複雜嵌套引用關係的大規模生產網絡中，出於運維成本的考慮，有時候訪問控制策略不會作的很細粒度，由於那樣的話若是有臺機器掛了換個ip都麻煩。這也是安全的妥協，我以後會有單獨篇幅講作安全是否須要妥協，應該如何妥協，底線是什麼。

再往上一層是如今討論的最多的一層，其實從圖中也能夠看出你平日的工做都是聚焦於哪層。這一層單獨拆開均可以再建一個縱深防護的子體系。應用層一般是暴露在Internet上的攻擊面，這一層主要是解決認證鑑權、注入跨站上傳之類的應用層漏洞，儘量把入侵者堵在第一人口以外。若是你在開發WAF，那你對應的也是這一層的工做。

應用層上方是容器、運行時環境。這裏的目標是假設個人服務器上的應用程序有漏洞，且攻擊者找到了漏洞，我不但願這個漏洞能被成功利用直接跳轉到系統權限，而是但願能在這一步阻止他，辦法就是經過容器加固，好比阻止一些危險函數的運行，好比上傳了webshell可是不被解析執行，好比你想執行eval（）並用種種方法變形編碼字符竄拼接逃過了應用層的檢測，可是到了運行時實際上是相同的底層指令，那麼不管你在上層多麼努力的變形我都會但願在更底層把你揪出來，哪怕不直接阻斷我也至少報個警。在絕大多數入侵活動中，上傳或生成webshell是從應用權限向系統權限轉化的關鍵一步，因此這一層的防護也是比較重要的。之後若是有時間單獨篇幅講如何對抗webshell。

若是不幸以前的都沒阻止攻擊者，對方已經獲得了普通用戶的shell」$」，那麼我確定不但願你繼續獲得rootshell，對抗的辦法就是你們常見的那些系統加固項，那些文章洋洋灑灑寫了一大堆主要就是用在這個場景的，不過最主要的仍是對抗本地提權以及內核提權，攻擊免疫或稱攻擊緩解機制例如SMEP、SMAP、DEP、各類ASLR，stack-canay，read-only .PLT .GOT等都是在這裏「埋點」，其餘的諸如umask=022等也是在這裏埋點，彷佛看上去這些不太須要安全team的介入，好像都是OS默認的機制？其實否則，安全作到偏執的程度仍是有本身出手的地方，Android出手比標準的Linux更快一點，也許之後就真的沒太多須要本身出手的地方了。不過當下各類基於LXC的容器，愈來愈多的multi tenant的雲環境，隔離的機制徹底依賴於kernel的健壯性，這些場景下對抗這一層的攻擊都顯得尤其重要。

若是被拿走了root天然是很使人不爽的事，但還不是最使人不爽的。若是有一天當你的1萬臺服務器中有500臺被人搞了，並且還不能推斷是否是裝了kernel rootkit的狀況下，這種感受是最要命的，你生了個腫瘤手術摘掉也就算了，那種狀況就像你手術完都不肯定摘了沒，即使500臺服務器備份數據重裝系統都不完全，並且近似於你某個子業務要處於離線狀態這種極其影響可用性的事情業務部門會把你逼瘋掉。因此不是特別需求要幹掉LKM，/dev/kmem，限制/dev/mem的全地址空間讀寫，另外kernel MAC內核強制訪問控制也能限制root只能作有限的事情，儘管理論上內核提權仍是能控制一切，不過要在沒有開發環境的服務器上實現完整的kernel rootkit功能並保證不在用戶態留下蛛絲馬跡的機率仍是比較低。這樣作還有一個好處，把入侵檢測聚焦於用戶態，不要動不動就去裝一堆內核級別的重量級玩意兒，大規模高併發的生產環境傷不起。

在雲計算環境中，上面那步可能還不算是單點滲透的終結，更底層還有hypervisor，若是攻擊者逃逸出VM那就比較狼狽了，每一個廠商都須要考慮一下VMM的保護方案，如今hypervisor這一層很薄不會作的很重，彷佛尚未特別成熟和通用的辦法，不過確定會發展起來，會有更多相似於XSM這樣的方案。

在一個真正創建縱深防護的系統中，入侵者通常到不了root這一步就會被揪出來，只不過完整的縱深防護要之後的篇幅慢慢寫了，這裏只是選取了其中一個維度來試圖解讀這個概念。另外一方面，完整的縱深防護體系只有大型互聯網公司纔可能全覆蓋，由於跟安全建設成本有關，因此又涉及另外兩個話題：不一樣規模企業的安全需求和同一公司在不一樣安全建設階段的需求，之後再展開。(http://www.ayazero.com/?p=33)

 

不一樣規模企業下的安全管理

創業型公司

         對於創業型公司而言，安全不是第一位的，我在唱反調麼？應該只是大實話而已。安全建設的需求應該是：保障最基本的部分，追求最高性價比，不求大而全，映射到技術實現應該是：

• 基本的補丁管理要作
• 漏洞管理要作
• L3-L7的基本的訪問控制
• 沒有弱口令，管好密碼
• 帳號認證鑑權不求各類高大上的基於條件的實時風控，但求基本功能到位
• 辦公網絡作到統一集中管理（100人以上規模）和企業防病毒，幾我的的話就徹底不用考慮了，APT什麼的就聽一聽拉倒了
• 流程什麼的就比沒要去搞了，有什麼需求口頭約束一下
• 找兩篇用到的開發語言的安全編程規範扔給大家的程序員看看，安全專家們說的SDL就不要去追求了，那個東西沒有一堆安全「準」專家玩不起來
• 系統加固什麼的，網上找兩篇文章對一下，確保沒有root直接跑進程，chmod 777，管理後臺弱口令對外這種低級錯誤，固然有進一步需求也能夠參考後面的技術篇中的措施
• 實惠一點的，找個靠譜的白帽子兼職作一下測試，或者衆測也行

 

是否是以爲簡陋了一點？我估計不少乙方提供的服務除了賣產品以外也不會比這個效果更好了。不過呢如今很多創業公司是拿了不小的風投的，也沒那麼寒酸，另一個很重要的特徵，創業公司基本都上公有云了，不會本身再去折騰IDC那點事了，因此相對而言以上措施中的一部分能夠等價於：

1. 使用雲平臺提供的安全能力，包括各類抗Ddos，WAF，HIDS等
2. 使用marketplace中第三方安全廠商提供的安全能力

具體怎麼選怎麼用就不展開了，不過不要由於迷信雲平臺關於安全能力的廣告而本身再也不去設防，畢竟針對租戶級的通用型的安全方案其覆蓋面和防護的維度是有限的。

大中型企業

         這個層次對應市場上大多數公司的安全需求，他的典型特徵是，業務的營收的持續性須要安全來保障。公司願意在IT安全上投入固定的成本，一般小於IT總投入的10%，不過這已經不錯啦，這時候開始有專職的安全人員或安全團隊，建設上重視效果和ROI，會具有初步的縱深防護能力。對應技術上的需求爲：

1. L2-L7每一層擁有完整安全設計
2. 對全部的服務器、PC終端、移動設備具備統一集中的狀態感知、安全檢測及防禦能力
3. 應用層面細粒度控制
4. 全流量入侵檢測能力
5. 無死角1day漏洞發現能力
6. 在安全等級較高的區域創建縱深防護和必定的0day發現的能力
7. 初具規模的安全專職團隊
8. 對應用交付有自主的評估和修補能力
9. 從IT服務層面創建必要的流程，業務持續性以及風控應急措施
10. 對業務安全造成本身風控及安全管理方法論
11. 將難以本身實現的部分外包

好像跟前面的描述比一會兒抽象了？是的，這個層級的安全需求沒辦法很具體的量化。不一樣的業務模式對應的安全實現仍是有很大的不一樣，加上這個區間裏的公司營收規模能夠差很大，對應的安全投入也能夠差不少。那什麼樣的公司納入這個區間呢？好比四大行，國內TOP10甚至TOP5之後的互聯網公司，大量的電信、金融、政府、能源等企業都屬於這個區間，但我爲何不把BAT納入這個區間，這樣的分類豈不是不科學，我之因此這樣分類徹底是從安全建設的複雜度上去考量的，而不是從安全建設的資金投入上去歸類的。不少好比金融行業的安全投入很大，但這些解決方案大都是靠花錢就能買來的，而BAT的方案花錢不必定能買獲得，不少都須要本身動手去建立，對安全團隊的定位、能力和需求徹底不同。那BAT之外較大的互聯網公司呢，我以爲他們會玩些各自特色的小花樣，可是不會進入大範圍的複雜的安全建設，這是由公司的總體面和業務決定的，不須要過度保障和超前業務的安全建設。

在往上一層大型互聯網企業，這個留到後面的話題。(http://www.ayazero.com/?p=38)

安全建設需求：生態級公司vs平臺級公司

事實上並不存在我說的這種分類，即生態級公司和平臺級公司之間沒有必然須要這麼作，必然須要那麼作的條條框框，可是二者的安全建設需求之間確實不只僅是量的差異而是質的差異。

         主要差異表如今是否大量的進入本身發明輪子的時代，即安全建設須要依託於自研，而非採用商業解決方案或依賴於開源工具的實現。上一篇提到金融行業的高成本安全總體方案几乎全都依賴於商業方案，這是跟大型互聯網安全建設有很大的區別，假設金融行業的CSO去互聯網公司可能會比較吃力，反之在適應金融行業的BCM後則能輕鬆駕馭，這個觀點由於有明顯的傾向性，因此確定是會受到挑戰的，不過我寫這些的本意也並非爲了討好全部人，時代的浪潮總歸是有所指，不會全部的人都是受益者。

         那麼平臺級公司和生態級公司的區別又在哪裏，從表象上看，生態級公司的大型基礎架構若是用傳統的安全方案几乎都沒法知足，因此會大量的進入自研，而平臺級公司則會依賴開源工具更多一些，不會全線安全工具進人自研。若是有預算的話也會優先投在「業務安全」側，好比反欺詐平臺等等，而不會本身去搞入侵檢測，固然這有多是個僞命題，有可能當個人企業安全系列全篇寫完時，乙方公司也開始提供具備可擴展性，能應對分佈式架構的方案，或者當時間尺度拉的長一點，平臺級公司每一年在自研上投入一點點，多年以後也具有了BAT級別的安全能力也並不是徹底不可能，不過這些都是理想情況，現實老是受到多方面因素制約的。

         首先影響的第一因素是技術驅動的層次，在底層仍是在應用層驅動業務。表象上平臺級公司和生態級公司都是以pc端web服務爲入口的平臺應用和以移動端APP入口的移動應用，有的依賴於一些PC客戶端或移動端偏底層的APP，但在技術實現方式上，平臺級公司更多的直接使用或少許修改開源軟件，而生態級公司的IT基礎設施則會相似於Google的三篇論文同樣，不只僅停留在使用和少許修改，而是會進入本身造輪子的階段，其中所造的輪子是否對業界有意義這種問題暫時不去評價，但對應的安全建設則反映出平臺級公司的安全主要圍繞應用層面，而生態級公司的安全會覆蓋基礎架構和應用層面兩塊。直接使用開源工具的部分交給社區去處理，本身跟進打補丁就好了，但若是是本身開發的，那麼就須要本身去解決一攬子的安全問題，好比Google造了Android這個輪子，那Android一系列的安全問題Google須要本身解決，好比阿里本身去搞了一個ODPS，那阿里的牛人也須要解決這個，再好比我所在公司在物聯網領域造了LiteOS這個輪子，天然也要去處理對應的問題，而這些偏底層的問題顯然早已超出應用安全的範疇，也不是通常的甲方安全團隊有能力應對的。其實有些平臺級公司也是發明了一些輪子的，好比自動化運維工具，好比一些NOSQL，不過IDC規模二者之間仍然差的比較遠，上層的業務複雜度也有差距，支持的研發團隊的規模也有差距，對安全工具的自動化能力和數據處理規模仍然存在階梯級的差異，這一點也決定了爲何要自研。安全其實只是IT總體技術建設的一個子集，當總體技術架構和實現方式進入自產自銷階段時，安全建設也必然進入這個範疇。對於不少實際上依靠業務和線下資源驅動而非技術驅動的互聯網公司而言，安全建設去作太多高大上的事情顯然是沒有必要的。

第二因素是錢，錢也分爲兩個方面（1）成本（2）ROI。假設安全投入按IT總投入的固定10%算，又假設生態級公司的安全建設成本是平臺級公司的5-10倍，這個成本除了帶寬、IDC服務器軟硬件，還有技術團隊，加起來纔是總擁有成本TCO。10我的的安全團隊和100我的的安全團隊能作的事情相差太大，具體能夠參考我在知乎上的帖子《爲何從事信息安全行業必定要去大公司？》http://www.zhihu.com/question/27356955。還有一方面則相似於「去IOE」，上面提到目前對於大型互聯網沒有合適的安全解決方案，即便有，這個成本可能也會沒法接受，因此假如乙方公司能推出既能支撐業務規模，又具備性價比的方案的話，我認爲甲方安全團隊真的沒有必要再去造輪子了。

         第三個因素是人，安全團隊的人員數量也只是一個很表面的數字，安全團隊的構成纔是真實反映，能囤到大牛的安全團隊和由初級工程師組成的安全團隊顯然是不同的，一方面前者的成本不是全部的公司都能接受，其次，平臺不夠大即便大牛來了也未必有用武之地。大多數平臺級公司的安全團隊其知識和經驗集中在web/app，應用層協議，web容器，中間件和數據庫，生態級公司則擴展至系統底層，二進制，運行時環境和kernel級別，能力積累也存在差異。這裏並沒有褒貶之意，僅在說明業務對技術的需求不同。

         那平臺級公司是否是就沒有樂趣呢，其實他們也玩一些小花樣，好比修改sshd、LVS，加入一些安全特性。可能也會本身定製一個WAF，或者搞搞日誌的大數據分析。但好比涉及DPI，全流量入侵檢測，SDN，kernel level的安全機制基本上都不會介入。這些對一個規模不是特別大的平臺級公司的甲方安全團隊而言門檻仍是有點高。

         本身發明輪子是否是全領域進軍呢？也不是，主要仍是在入侵檢測、WAF、掃描器、anti-DDOS、日誌分析等領域。在SDL環節上可能也會本身研發些工具，但未必有直接使用商業工具來的短平快。阿里錢盾、騰訊管家、百度殺毒這些都跟360客戶端同樣跟生產網絡沒什麼關係，就不去講了。另外自研有一個原則：都限定在民用領域，不會本身去發明一個RSA算法這樣的東西。

國內的平臺級公司裏也有一個例外–數字公司，由於其主營業務是安全，因此就不會受到安全投資固定佔比理論的影響。(http://www.ayazero.com/?p=42)

 

創業型公司必定須要CSO嗎？

轉一個我在知乎上的帖子：http://www.zhihu.com/question/27560328

其中的abc輪並不表明企業發展的某種階段，只是一個象徵性描述，寫於2015/1/13

 

最近據說很多創業型公司都在找CSO，也有找到個人，就分享一下我對這個問題的思考。首先這個問題即使是對同一我的而言可能答案也會因時而變（例如我），其次CSO只是一個表明性的稱呼，你們不要過於糾結必定要作什麼事纔算CSO，CSO和CISO又有什麼區別之類的，在這個語境下用來指代招聘方想找一個擁有全局安全管理經驗的，經驗豐富的甚至最好是資深的從業者而且能帶一支哪怕是幾我的的安全團隊，事無鉅細能把安全相關的事所有攬過去這樣的人。

對於尚在天使融資階段，找個CSO大多就是去忽悠投資人的，通俗一點理解就是湊一支履歷光鮮的隊伍去「騙錢」，能不能作事情這個很難說，也不能說人家必定作不了事情，這種只能過後諸葛亮蓋棺定論，隨便說人不靠譜也是不負責任的，不過我想對於大多數有不錯崗崗位的人而言應該是不會去的。

 

第二種，拿到A輪，業務方向已被證實，業務量不大但進入快速成長期，問題層出不窮，CEO和CTO以爲頭疼而且想把這部分壓力轉嫁出去，理論上是應該找一個懂安全的人的，可是如今這個時間點也就是2015年真的不是一個好時間，在當下不少公司100-200w也常常找不到合適的CSO，創業型公司要在這個層面上爭奪安全人才真的是很累的一件事，取而代之應該找2-3個靠譜的安全工程師，而後CTO（技術總監），運維Leader，開發的架構師這幾個角色本身遇事應急性補一點安全的知識和方法論，哪怕是充當救火隊長趕鴨子上架的方式你們配合一下，累一點應該也能把安全撐起來，不必定非要找一個大牛級的CSO，由於有時候業務量沒那麼大規模，不必定須要很高level的人，且創業型公司爲了保持本身的鮮活也不須要套用大公司的流程和方法，作好基礎的運維安全，代碼安全，增強一些安全意識，不出問題的時候騰出時間來研究一下下一步怎麼作，跟時間和業務增加速度賽跑，跑着跑着，應該就會愈來愈輕鬆。固然了，做爲創業者，若是你有一個安全領域的朋友願意幫你出謀劃策，偶爾回答一下安全建設如何作這類問題，其實那CSO的需求也就解決了，代價只是請吃幾頓飯？呵呵

 

第三種拿到B輪，業務初具規模，開始朝更高的地方衝刺，同時能給人畫更多的「餅」，若是以前已經招到靠譜的安全工程師，那這個時候應該已經成長起來，承擔起leader的角色，一般也不須要從外部招CSO了，這個時候想從外部招CSO的都是以前主觀的或被迫的不過重視安全，被捅菊花了纔想要頭痛醫頭腳痛醫腳，這個時候的業務形態跟大公司比應該是「麻雀雖小五臟俱全」，安全管理上應該是有不少類似的地方了，對於出具規模的業務而言安全管理的經驗很重要，能夠直接從大公司挖人，固然了level較高的估計仍是挖不動的，主要就是骨幹那一層的人吧，一般你須要容忍他們業務上有深度但不必定面面俱到，極可能情商和管理能力也差強人意，不過能解決你的問題就行，面面俱到的畢竟仍是太貴了，呵呵

 

第四種拿到C輪衝IPO，這個時候想必不會囊中羞澀，若是看官你是這個區間公司的CXO，還爲找不到人感慨萬千，我想也許是心態還不夠開放，亦或許是給人的「誠意」還不夠，到這裏我也給不了太多建議了，畢竟市場上只有那麼一小撮人，來不來去不去也就是那一小撮人的意願而已，被打動了天然來，沒被打動的天然不去~

 

創業公司的那些事對選擇轉會的CSO是否有挑戰？有，也沒有。首先作的事情每每仍是從頭建團隊，把過去建設安全體系的過程從零開始再作一遍從這個角度講重複過去作的事情儘管業務有所不一樣但過程和結果上未必有挑戰，有「挑戰」的反而是如何在創業公司的條件下招募成員，維繫團隊和在不少流程及界限不分明的狀況下推進事情落地，僅此而已，對CSO本人而言獲得的實踐機會未必有大公司多而廣，由於安全是一個隨規模而複雜化的工做。可是，若是你是CSO的跟班小弟，那你多是成長最快獲得鍛鍊最多的人，由於你經歷了安全建設飛速發展從無到有，從簡單到自動化的過程，這個過程不是人人都能體驗，所謂的全局視野並非你進入BAT在一個很細的分支上耕耘幾年就能積累到的，相反是在這種環境下才能快速積累。因此除非公司IPO，CSO都不是團隊裏收益最大的人，但跟班小弟倒是最大的贏家，哈哈

 

甲方的同窗看了是否是以爲有不少場景很類似，是否是該珍惜當下，由於有些令你痛苦的事情，偏偏就是你成長的機會，區別只在於你選擇了什麼方法解決這類問題，你的解決問題的方法拿到業界算得上是最佳實踐麼(http://www.ayazero.com/?p=44)