引言

本文是根據2016.10.28在某證券基金行業交流會的發言的整理稿，從業十餘年，除了接到一些工作任務安排外，我沒有上臺演講的經歷，這次算是我的第一次。分享了我對金融行業企業安全運營之路的經歷和理解，包括面臨的問題、安全運營架構、支撐工具和所需資源，對安全運營的難點，安全檢測為什麼會失效，安全運營成熟度，做了一些探討。對企業安全灰色地帶、白名單還是黑名單等問題做了一些思考。受限於本人自身的從業經歷和所處行業，可能不具有普遍代表性，個人能力和視野也有限，希望大家責備指正，要是能給有需要的同仁一些參攷幫助，善莫大焉。

面臨的問題

1. 安全需求

在企業資訊安全建設初期，安全工作的主要內容是購買安全設備和部署安全管控系統並進行日常維護。從網路層、虛擬層、系統層到應用層、數據層、用戶層部署了一系列安全設備或軟件並確保其穩定運行，但發現安全狀況並沒有得到有效改善，安全問題頻發，其根本原因是沒有進行有效安全運營。如何建設企業有效的安全運營體系，本文抛磚引玉，做一些分享探討。

金融行業是牌照行業，接受嚴格的監管，典型特徵是業務的持續穩健發展需要安全來保障，有專職的安全團隊和安全人員，每年安全預算和投入有保障且逐年增加。企業的安全需求表現為：

2.  面臨的問題

在企業安全需求下，面的問題主要是三個方面：

（1）企業安全的全貌

企業安全的全貌是什麼？我們拿著顯微鏡，看看安全管理員每天的工作內容，包括：每天查看各類安全設備和軟件是不是正常運行，硬體告警、應用程序和行程，效能容量，表空間，存儲空間，系統和應用日誌；安全設備和系統的安全告警查看和響應處理，包括防病毒日誌和告警、防火牆日誌和告警、入侵偵測日誌和告警、互聯網監測告警、蜜罐系統、防數據洩密系統日誌和告警，各類稽核系統如資料庫稽核、防火牆規則稽核報表和日誌，外部協力廠商漏洞報告平臺資訊；處理各類安全檢測需求和工單；各類安全性漏洞修補和覆核檢查，有分支機搆管理職責的還要督促分支機搆的安全管理工作；填報各類安全報表和報告，彙報各類可疑情况並進一步追查；推進各類安全項目，有管理的，有科技的；有的還要付出大量精力應對各類安全檢查和內外部稽核。做過基層安全運維的人對上述場景都會很熟悉，這是企業安全各個場景的縮影，但不是全貌。如果一個企業只有少量人員，服務器和產品，那麼上述內容就是企業安全工作的全部，我定義上述工作是安全防護框架。如果是有萬臺服務器，幾百個程式師，數以百計的系統，企業安全除了漏洞檢測和漏洞修復，安全檢測和攻防外，還要考慮安全運營的問題，從工作量上看，安全防護和安全運營各占50%。

（2）安全服務質量保持在穩定區間

在安全防護框架建設中，會部署大量的安全防護設備和措施，在顯著提升安全檢測能力的同時帶來問題：各類安全性記錄檔和告警如何有效響應處置？安全設備數量急劇增多的同時，如何解决安全設備有效性的問題？安全人員在應對安全設備數量和安全性記錄檔告警急劇增多的同時，如何確保人員工作質量的穩定輸出？這裡指的是人員工作質量的穩定性，我們的目標是要盡可能消除單個人員對安全團隊對外提供安全服務質量的影響。舉個例子，就像大餐和速食的區別，大餐靠的是名廚名師的發揮，如果今天這個名廚心情不好或者換個新人，可能做出的產品品質就有非常大的下降。而速食如肯德基，所有的操作都標準化和流程化，就是初中畢業沒學過烹飪，沒練過的人經過短期培訓和嚴格管理，也能確保炸出的薯條味道一模一樣。速食的標準化流程和管理幾乎完全消除了人的因素，確保對外提供的服務質量能够始終穩定，不會出現大起大落的情况。安全運營的目標或者說需要解决的問題就是在企業變大，業務和系統日趨變複雜的情况下，在資源投入保持沒有大的變化情况下，儘量確保安全服務質量保持在穩定區間。

（3）安全工程化能力提升

安全運營還需要解决的一個問題是安全工程化能力提升的問題。舉個例子，企業內很多有經驗的安全工程師能够對懷疑一臺服務器被黑進行排查溯源，查看服務器行程和各種日誌記錄，這是工程師的個人能力。如果能將安全工程師的這種能力轉變成自動化的安全監測能力，並通過安全平臺進行應急回應和處理，讓不具備這種能力的安全人員也能成為對抗攻擊者的力量，這是安全工程化能力提升的收益，也是安全運營需要解决的問題。

安全運營的思路

1. 架構

為確保安全運營架構能够靈活擴展，推薦按功能模組劃分成四個模塊：安全防護框架、安全運維框架、安全驗證框架、安全度量框架。安全防護框架的主要功能是通過不斷的部署安全監測系統，提供實时檢測的能力，稱為安全感知器“Sensor”，為安全運維框架提供“天眼”。時下流行的態勢告知、入侵感知我理解為主要靠安全防護框架來保障。安全運維框架的主要功能是統一採集安全防護框架各Sensor的監測資訊，並通過黑白灰名單處理和關聯分析（有很多廠商號稱大數據智慧分析，我理解為只是基於規則的資料挖掘）處理監測資訊並通過統一展示平臺輸出告警，進入事件處理平臺和流程，人工介入處理。安全運維框架還包括安全事件的定期review和向管理層彙報，這部分可能比單個單個的事件處理還要重要。安全驗證框架主要功能是綜合通過黑盒白盒驗證措施，確保安全防護框架和安全運維框架有效性。安全度量框架主要功能是通過一系列安全度量名額，衡量評估安全運營質量水准，並針對性持續過程改進，實現質量的螺旋上升。

（1）安全防護框架

安全防護框架的目的是部署盡可能多和有效的安全感知器Sensor，這些安全感知器構成了資訊安全的“天網”，這部分是基礎工作，也是傳統安全的主戰場，需要歷經多年的持續投入積累。安全Sensor的部署遵循縱深防禦的理念，見以下示意圖：

實際中可能遠遠不止上述這些Sensor。比如網路層，可以把防火牆監測資訊特別是Deny資訊採集了，有些防火牆還自帶IPS功能如CheckPoint的SmartDefense，就是特別好用的安全Sensor，交換機、路由器的ACS服務器資訊、堡壘機登入資訊、虛擬層虛擬主機操作資訊、Windows、Linux主機日誌、有在主機部署安全用戶端的監測資訊、資料庫稽核系統監測資訊、AD系統資訊、存儲備份系統操作資訊、KVM、ILO等帶外管理系統資訊、ITIL系統工單資訊、應用系統應用資訊如OA系統應用日誌、SAP系統應用資訊、公文傳輸系統日誌、FTP資料傳輸日誌。企業基礎安全的很大內容就是建設各類安全Sensor，解决點狀的安全問題和需求。比如企業防火牆多了，如何管理防火牆規則的有效性和合規性，可能需要部署諸如Algosec、firemon等防火牆規則稽核工具，稽核發現的資訊就可以作為安全運維框架的輸入。如果想監測企業內網或服務器訪問了哪些惡意地址，可以採集類似ArcOSI這樣的開源惡意地址庫。

安全防護框架建設，需要考慮兩個問題。一是發送原始監測資訊還是Sensor處理後的監測告警資訊給安全運維框架？如果是防火牆、IPS等安全防護系統，儘量是全量原始資訊。如果是Windows、linux主機日誌、合規檢測、登入登出等資訊，考慮對原始資訊做過濾，只和安全相關的資訊才作為安全運維框架的輸入。二是要不要做業務安全監測。華為Ayazero認為企業安全涵蓋7大領域，①網路安全，②平臺和業務安全，③廣義的資訊安全，④IT風險管理、IT審計&內控，⑤業務持續性管理，⑥安全品牌行銷、通路維護，⑦CXO們的其他需求。對於傳統行業，建議做①③④⑤，對於互聯網公司，建議做①②⑤，對於金融行業，我建議做①③④，能力强的安全團隊，建議做①③④⑥⑦。

（2）安全運維框架

安全運維框架的建設目標是成為企業安全的大腦、神經中樞、耳目和手脚。在軍隊現代化作戰體系中，美軍創造性的提出了C4ISR作戰指揮系統，即指揮、控制、通信、電腦與情報、監視、偵察。一個完整的資訊安全作戰指揮自動化系統應包括以下幾個分系統：

“大腦”-基礎架構平臺。基礎架構平臺是構成指揮自動化系統的科技基礎，指揮自動化系統要求容量大、速度快，相容性强。“耳目”-安全情報、安全監視、偵察系統。主要是對安全防護框架中各安全Sensor的安全資訊的收集和處理，實現异常行為的實时安全監測。“神經中樞”-資料分析系統。綜合運用各類智慧分析算灋和資料挖掘分析科技，實現安全資訊處理的自動化和決策方法的科學化，以保障對安全控制設備的高效管理，主要科技是智慧分析算灋和模型及其實現。“手脚”—安全控制系統。安全檢測和控制系統是用來收集與顯示安全資訊、實施作戰指揮系統發出安全控制指令的工具，主要是各類安全控制科技和設備，如防病毒和主機安全用戶端、防火牆等，主要實現异常行為的實時安全控制。

安全運維框架實際落地時，企業會部署SIEM或SOC等類似平臺實現安全檢測資訊統一採集和存儲，大部分SIEM或SOC平臺支持內寘或自定義的黑名單檢測規則進行實施檢測，也有結合智慧分析平臺進行安全大資料挖掘的案例，以解决SIEM和SOC平臺智慧分析不足的短板。遵循事件處理標準化流程，納入ITIL事件管理流程，通過下發工單和發送告警郵件、簡訊等管道進行安全提醒。安全事件確認和溯源分析主要通過人工分析和確認的管道進行。對於100%確定异常的安全攻擊通過自動化管道進行阻斷。通過安全事件日例會和週報、月報等管道對安全事件進行閉環管理。

（3）安全驗證框架

安全驗證框架解决安全有效性的問題，承擔對安全防護和安全運維兩個框架的功能驗證。安全驗證框架是企業安全的藍軍，在和平時期，藍軍扮演著對手角色，利於及時發現、評估、修復、確認和改進安全防護和運維框架中的脆弱點。包括白盒檢測（過程驗證）和黑盒檢測（結果驗證）兩部分。

白盒檢測（過程驗證）是指建立自動化驗證平臺，對安全防護框架的管控措施實現100%的全面驗證，並視覺化集成至安全運維平臺中，管控措施失效能够在24小時內發現。通過自動化驗證平臺達到：

基於上述目標，自動化驗證要求所有的驗證事件必須為自動化類比真實事件產生，不能使用插入記錄的管道產生，同時自動化驗證事件應提供判斷是否為驗證事件的唯一標識，驗證事件產生時間需統一安排，防止集中觸發。安全運維平臺應能够監測到安全驗證未通過的系統和規則，並產生告警資訊，通知安全運維人員介入處理。

黑盒檢測（結果驗證）是通過多管道安全滲透機制和紅藍對抗演習等，先於對手發現自己的漏洞和弱點。多管道安全滲透機制現時常見的就是安全眾測，紅藍對抗演習需要企業具有較高攻防技能的安全人員，也可外聘外部專業機构完成，用於檢測安全防護框架和安全運維框架的有效性。

（4）安全度量框架

安全度量框架主要用於衡量評估安全有效性，這是挺難的一件事，做些探討。我覺得可以分成幾個層次：

一是科技維度。包括防病毒安裝率、正常率，入侵偵測檢出率、誤報率，安全事件響應時長、處理時長，高危預警漏洞排查所需時間和完全修復時間。還可以考慮安全運維平臺可用性、事件收斂率等。合規性方面可以設定合規率、不合規項數量、內外部稽核發現數量和嚴重度等；

二是安全運營成效。包括覆蓋率、檢出率、攻防對抗成功率。有多少業務和系統處於安全保護之下，有多少無人問津的灰色地帶，安全能在企業內部推動的多深入，多快速，這是需要綜合科技和軟性技能的，成敗主要系於安全團隊負責人。檢出率和攻防對抗成功率都是衡量安全有效性的有效名額，安全團隊即使不能拍著胸脯保證不出事，也不能靠運氣和概率活，那持續提升檢出率和攻防對抗成功率就是努力的方向；

三是安全滿意度和安全價值。安全價值反映在安全對業務支撐的能力，TCO/ROI，安全用多少資源，支撐了多少業務，支撐的程度。安全價值還體現在內部的影響力以及對業務的影響力，是做微觀安全還是廣義安全，是為業務帶來正面影響還是負分扯後腿。安全滿意度是綜合維度名額，我理解為是對安全團隊和人員的最高要求，既要滿足上級領導和業務部門對安全的利益訴求，又要滿足同級橫向其他IT團隊對安全的利益訴求，還要滿足團隊內部成員的利益訴求，要提供最佳的安全服務，讓安全的用戶成為安全的客戶，讓使用者滿意，真的是非常非常有挑戰的一件事情。

2. 工具

安全運營工具包括支撐安全運維框架實現的SIEM平臺、安全事件處理標準化流程工具ITIL、安全控制自動化工具三部分。SIEM平臺負責安全資訊的統一收集和存儲、基於檢測規則的异常檢測和告警。ITIL平臺負責接收SIEM平臺發送過來的安全事件資訊並據此產生ITIL工單，推送到安全運營人員處理和關閉。安全控制自動化工具負責根據SIEM平臺下發的安全控制指令進行自動化操作，比如檢測發現有外部攻擊源，通過下發自動化指令實現防火牆或IPS封禁該攻擊源。檢測發現某主機有可疑行程，通過安全用戶端收集該行程檔案樣本資訊進一步手動分析。檢測發現辦公內網某用戶電腦上有個可疑操作非人工操作，疑似程式自動操作，可通過安全用戶端提示用戶手工確認等。安全控制自動化工具現時商業化程度不高。

（1）SIEM檢測規則

如果有合適的檢測規則，SIEM是個非常强大的工具，可以檢測其他安全工具無法捕獲的安全事件。通常SIEM的檢測規則有三類：

①單一檢測條件規則 

滿足單一特定檢測條件則觸發告警。如服務器主機登入來源非堡壘機地址。滿足該條件則告警，該類型規則最簡單，主要依靠安全Sensor的監測能力和規則過濾能力。是攻擊就一定有异常，關鍵是怎麼總結提煉出异常的特徵加以檢測，比如Ayazero在《互聯網企業高級安全》中提到的檢測攻擊提權（某個高許可權（system？uid=0）行程（bash？cmd.exe？）的父行程為低許可權）是一個總結提煉异常特徵加以檢測的很好案例。

②跨平臺安全監測資訊關聯檢測 

最典型的規則為基於資產脆弱性的攻擊告警，關聯分析漏洞掃描和入侵偵測告警資訊進行關聯檢測。還比如防火牆permit日誌中有連接ArcOSI中定義的惡意IP地址資訊。該類型規則在跨平臺系統監測資訊之間進行關聯，可以衍生出很多腦洞打開的檢測規則。比如檢測安全違規行為，檢測數據洩密，甚至人員可能離職等。這類規則檢測效果的好壞取決於兩點：一是安全Sensor的類型盡可能多和單個Sensor能監測維度盡可能廣；二是規則設計者的檢測思維，就像攻擊者思維一樣，需要腦洞大開，需要猥瑣。③針對長時間緩慢低頻度攻擊的檢測規則

③針對長時間緩慢低頻度攻擊的檢測規則

大部分的安全工具是以孤立管道識別潜在的安全事件，如IDS監測到某臺工作站發出的可疑流量，然後從其他20臺工作站上監測到同類流量，在IDS管理面板上，每個事件被當作單獨事件處理（有些IDS廠商有高級功能），在SIEM中可以編寫規則，根據事件發生的頻率觸發不同的告警，如果在幾分鐘內從IDS傳來21次類似的事件可以觸發一條規則。如果攻擊者採取長時間緩慢低頻度攻擊入侵企業內網，可以編寫一條SIEM規則，在較長時間內蒐索特定事件，並在該事件範圍內發生次數達到某個閾值時告警。更進一步，這種檢測規則對於不是即時安全事件形式出現的日誌也同樣有效。如檢測DNS Tunnel為例，DNS Tunnel用於將C&C流量編碼為DNS請求，從被感染機器發出，通過被感染企業的DNS伺服器到達C&C服務器，然後再將響應返回給企業的DNS伺服器，由其轉發給受感染的內網機器。正常的DNS査詢都有一定頻率，DNS Tunnel需要咋網絡上發送許多DNS數据包，那麼製定內網單臺機器對同一個功能變數名稱的査詢達到某個閾值（如10分鐘內1000個査詢）的規則可以有效檢測DNS Tunnel。SIEM的檢測規則還可以配寘為在流量來源與舊模式不同時發出告警，也可以配寘為在合法和以往正確的流量突然呈現指數上升或者下降時發出告警，如過去90天內產生一定數量日誌的Web服務器突然開始產生於10倍於正常數量的日誌，這可能是被入侵主機用於向其他主機發動攻擊的迹象。通過SIEM規則，安全團隊可以根據流量的標準差製定告警，如達到10個標準差閾值就告警。

（2）SIEM健康度監控

從很多攻防案例中，防禦方失敗的原因主要歸結於安全防護失效，其中SIEM平臺工具健康度出了問題是比較常見的，包括：安全Sensor安全監測資訊採集器失效、SIEM檢測規則失效、安全告警失效、安全告警處理失效。安全檢測資訊採集器失效的原因主要是未對採集器的物理機器效能監控、採集數據正常監控、採集數據日誌解析和映射入庫（Parser）异常等。SIEM檢測規則失效包括設定條件無效、閾值無效、規則未生效等，有時告警閾值設定不合理頻繁告警，SIEM平臺會自動禁用規則導致規則無效。安全告警失效，包括郵件、短信閘道配寘無效，配寘用戶失效、網絡失效、配寘變更异常、手機號碼設定錯誤等等。安全告警處理失效主要是人的因素，比如多條告警簡訊，選擇性的忽略，假陽性告警太多淹沒了真正有威脅告警等。

值的一提的是安全Sensor的安全性。韓國在2013年3月20日下午2點，包括新韓、農協和濟洲等3家銀行與KBS（韓國廣播公司）、MBC（韓國文化廣播公司）等2家電視臺，超過32000臺電腦以及部分ATM提款機，都在同一時間當機，無法重新啟動。駭客首先入侵了韓國防病毒軟體廠商AhnLab（安博士）的病毒定義更新服務器，利用病毒庫定義陞級機制，將惡意軟件分發到用戶的電腦，在用戶的電腦上安裝執行惡意程式。調查發現，另一家防毒軟體公司ViRobot也被駭客利用。如果你在企業內部部署的安全Sensor接受更新的是惡意軟件……，不寒而慄。做好安全Sensor的安全性的重要性，不用再強調吧。幾個原則：控制指令僅允許固化的指令，嚴禁在Sensor端預留執行系統命令介面；更新包必須經過稽核之後上傳至更新Server保存，更新僅允許選擇更新Server上以後的安裝包，最好校驗更新包的MD5；控制指令下發時必須人工稽核確認後才執行。為可用性起見，更新最好分批分區域完成，否則由於大量更新包的下載導致生產網被堵塞，老大也饒不了你吧。

3. 所需資源

（1）流程與機制

有效、高效的安全運營流程與機制是非常非常非常重要的。安全運營流程一般做好兩個標準化的流程：安全事件處理流程、安全運營持續改進流程。安全事件處理流程是定義什麼級別的事件該由什麼樣的人，在什麼時間按什麼標準處理完成。一個外部攻擊掃描和內部發現的分支機搆過來的持續不斷的高許可權帳戶猜解安全級別肯定不同。前者最多為普通或關注事件，由安全一線工程師下發一個指令，在防火牆上自動封禁該外部IP地址一段時間即可。後者需要定義為高風險事件，需立即由有經驗的安全二線工程師或安全專家聯系分支機搆進行溯源排查，有可能是中金融行業的特種木馬，也極有可能是網絡藍軍在偷襲，還可能真的是有攻擊者進來了，不管如何，你的安全感知能力已經往前進步了，安全終於不再是靠運氣和概率活著。安全運營持續改進流程是安全事件的閉環管理，每筆安全事件的處理結果最終必須為誤報、屬實，二選一。如果是誤報，必須改進SIEM安全檢測規則或安全Sensor監測措施。如果屬實，好的一面是安全檢測能力有效，壞的一面是壞人已經進來了。根據壞人已經突破的層進行針對性的改進。安全運營持續改進要求每天、每週、每月都堅持進行安全事件review，有可能重要事件被一時大意的一線人員放過，也可能是其他原因。安全運營持續改進流程的質量可能决定了整個安全運營質量。

（2）組織與人員

我們期望的大型安全部門組織架構圖應該是這樣子：

實際工作中安全部門組織架構圖是這樣子：

理想很豐滿、現實很骨幹，理想和現實總是有差距的。團隊規模方面，互聯網公司阿裡和騰訊，其安全團隊的規模大約在2000人左右，總員工數約30000多人，安全團隊人員占總員工人數約7%左右，金融行業和這個比例差距還比較大。國內股份制銀行總行安全團隊規模一般約10-20人，總行IT人員從幾百到幾千不等。券商普遍安全團隊人數在2-5人之間，華泰安全團隊有7人，算是比較多的了。安全運營的實現肯定離不開組織與人員，證券公司安全運營人員建議按1:2:3比例配寘，一個安全運營平臺運維人員，包括服務器和應用運維，該部分可以交給IT部門的運維團隊代為運維。2個安全人員互備，一個負責安全Sensor建設，一個負責安全檢測規則和安全二線，事件調查、回顧與彙報、持續改進。3個外包安全一線，負責7*12事件響應和初步調查確認。股份制銀行安全運營人員數量為2-3倍，外包人員還可視事件類型和數量新增。

安全運營的思考

1.  安全運營建設的難點

互聯網行業和公司的安全建設引領全行業的發展，原因是什麼呢？人財物資源投入大？自由市場競爭充分？我認為最重要的原因是面臨解决實際安全問題的壓力和需求，採用了最快最有效的解决問題的安全方案。如果採用傳統行業的傳統安全解决方案解决互聯網行業的安全問題和需求，無疑是行不通的。所以互聯網行業做安全的關鍵字是有效解決實際問題。在2010年以前，我們和國內金融行業同仁交流的時候，做安全的思路普遍還在監管合規+設備部署的階段。我認為這是合理的。安全是和需求相匹配的，金融行業是牌照行業，監管合規是安全的首要和最重要需求，安全團隊在這個階段最大化的滿足監管合規的目標。同時由於國家對金融業的法律保護等客觀因素，金融行業的業務系統面臨的風險遠沒有互聯網行業高。2010年後，由於網上銀行、移動金融的快速發展，以及國內互聯網安全環境的進一步惡化，金融行業的安全需求開始發生深刻變化，需要有效解決實際安全問題。監管合規和設備部署經過歷年不斷的持續改進提升，但還是會不斷的出現安全事件，方向在哪？我的理解是從設備部署運營向安全有效性方向轉變是個不錯的思路。

安全運營的覈心是安全運維框架，承載安全運維框架的是SIEM平臺或SOC平臺，我在金融行業微信群裏經常遇到一個問題，為什麼SOC容易失敗？這個問題我理解為等同於安全運營的難點在哪？有三點。

（1）企業自身基礎設施成熟度不高

安全運營質量高低和企業自身基礎設施成熟度有很大關聯。如果一個企業自身的資產管理、IP管理、功能變數名稱管理、基礎安全設備運維管理、流程管理、績效管理等方面不完善，甚至一團糟，安全運營能獨善其身、一枝獨秀嗎？防病毒用戶端、安全用戶端的安裝率、正常率慘不忍睹，檢測出某個IP有問題結果始終找不到該IP和資產，檢測發現的安全事件沒有合理的事件管理流程工具支撐運轉，檢測發現內部員工不遵循規範導致安全性漏洞結果無任何約束，那安全運營能做什麼呢？還是把點的安全做好，再考慮安全運營比較合適，比如首先把防病毒用戶端運營好。

（2）安全運維不能包治百病

安全運維不能包治百病。由於安全運維框架並不自身具有安全監測能力，安全監測依靠安全防護框架，SOC平臺自身不產生資訊，需要通過安全防護框架建設一系列安全Sensor，才能具備較强的安全監測能力，才能在企業內部具有一雙雙安全之眼，所以安全運維建設不能代替安全防護建設，該部署的安全系統、安全設備還是要建。

（3）難以堅持

這個難點寫出來讓我烦乱很久，不過既然是體曆，我覺得還是有必要寫出來。我們樸素的願望總是希望能有一雙上帝之手，幫我們解决所有的問題。安全問題，往往都很棘手，我們的直觀反映總是希望能有一個成本比較低，時間消耗比較少的安全解决方案。可總是事與願違，安全沒有速成，沒有捷徑。但凡和運營相關的，其實都不是高大上的事情，往往是和瑣碎、棘手、平淡相關，甚至讓人沮喪，所以安全運營難以堅持。堅持把每個告警跟踪到底，堅持每天的安全日例會，堅持每週的安全分析，堅持把每件事每天都做好，是最難的。

2.  安全檢測為什麼會失效

單點檢測和防禦和企業內規模化檢測和防禦是兩個概念，很多單點檢測和防禦很有效，但在企業內上了規模後就會出現安全檢測失效的問題，嚴重的甚至導致無法推廣和部署，最終不得不取消。

實踐中如果某次安全攻擊沒有檢測到，是非常好的提升企業安全運營能力的一次機會，這意味著一定是某個環節弱化以致安全檢測失效了。一般排查的順序是：單點檢測深度不足->覆蓋率不足->安全運維平臺可用性出了問題->告警品質問題->人的問題。

首先是單點檢測手段不足導致，可能是檢測的規則運算式寫的不好，或者是攻擊者使用的管道沒有預先考慮到，也可能現有的安全防護框架的安全監測根本就監測不到。針對性的改進提升就可以了。

第二是覆蓋率不足導致。出現問題的機器或網絡區域就沒有部署安全監測產品，即使有監測能力，也會因為沒有部署而導致檢測失效。比如防病毒用戶端安裝率和正常率只有80%，那即使針對已知惡意程式，也只有60%的概率能够監測發現。這個問題其實是現時很多企業安全問題的現狀，有監測設備和能力，但安全檢測失效。更要命的是大家往往不重視這些灰色地帶，投入重金和重精去測試引入部署那些安全概念產品，防APT、威脅情報、態勢感知等等，其實這幾樣哪能離得開那些安全監測設備呢？所以這個問題的解決方案就是把部署率、正常率提升上去。關於企業安全灰色地帶，有幾個值得關注的地方：（1）無人關注的資產，特別是互聯網資產。烏雲報的很多安全性漏洞，後面廠商的回復很多是：這是一臺我們（測試/即將下線/無人使用/外包人員使用……）的設備，我們已關閉。這些資產除了服務器，還有分配了的互聯網IP、功能變數名稱，不在安全監測裏的系統和應用；（2）開放在互聯網上的管理後臺、高危埠、文件上傳點；（3）各種已被爆漏洞的協力廠商應用；（4）弱口令，各種弱口令，系統弱口令、應用弱口令、用戶弱口令，如果解决好了口令的問題，我認為可以解决企業至少50%的安全問題。

第三是安全運維平臺可用性出了問題，在前面介紹了SIEM健康度監控的問題，這塊也是安全檢測失效的重要原因之一。

第四是告警質量的問題。SOC被詬病最多的是採集了大量數據，但往往不能判斷哪些是真正需要關注的告警。告警有效性較低，導致大量需要人工確認，管理成本太高。安全檢測規則的設計不足導致告警數量太多，從而導致安全運營人員選擇性的忽略。

第五是人的問題。機制流程我理解為也是人的問題。如果前述原因排除，還是有安全檢測失效的問題，那應歸結於人的問題。比如人的責任性問題，快到下班時間了，匆匆把告警確認關閉敷衍了事，或者人的安全技能不足，不能有效調查判斷實際安全問題。

3.  白名單還是黑名單

現時絕大多數安全防護措施、安全檢測規則，無論吹的多高大上，基本都還是基於黑名單原則，滿足黑名單規則的則告警。黑名單的優點顯而易見，假陽性較低，認知理解容易，缺點是漏報率高，能不能檢測到安全威脅難聽點，需要靠概率和運氣。如果從安全有效性角度出發，白名單可能會越來越受到重視。白名單的缺點是假陽性較高，運營成本高，所以需要安全檢測具有自學習能力（姑且稱為人工智慧），形成自動或半自動可收斂的安全檢測規則。這塊希望能儘快有成熟的商業產品，解决企業的痛點。

4.  需要什麼樣的安全和安全運營

企業需要什麼樣的安全和安全運營？適合自己的就是最好的，或者說投入和收益比最大比。企業的安全投入跟公司的規模和盈利能力相關，公司規模大，盈利能力强，處於發展期時，預算和人員編制都會新增，業務停滯時安全做的再好也不會追加投入。因為在甲方，安全不是主營業務，資訊技術部門已經是公司的中後臺職能型部門，安全團隊是資訊技術部門中的中後臺，謂之後臺中的後臺。所以適合自己就是最好的。企業安全建設有個階段論。第一階段：如果基本的安全體系尚不完備，處於救火階段或者安全體系化建設捉襟見肘，APT攻擊可以先放一邊不管，先把安全中需要快速止血的工作做好，這就是基礎安全工作，這部分工作遠沒有高大上，但卻是最基礎最有用的“保命”工作，不需要太多額外投入就可以規避80%的安全問題，讓企業有一個最基礎的安全保障。第二階段是系統建設階段，建設各種安全監測防護手段，以及各類安全規範和安全流程，一般採用27001體系+商業解決方案+少量自研可以實現。第三階段是安全高階建設，這階段基本商業產品很難滿足企業安全需求了，以自我研發和自動化智能化為特徵，覈心還是以解决企業遇到的安全問題，解决實際安全問題為目標。能進入這個階段的企業不多，但基本代表了該行業的未來發展方向。

個人理解安全運營有個成熟度問題：

（1）一級：自發級。部署了一些較為基礎的安全措施和管控，單點防禦投入了較多人力財力，比較依賴於廠商，對於企業安全沒有整體把控。（2）二級：基礎級。具有安全運營的理念並付諸行動，建立了較為完善的安全防護體系，並通過安全運營保障安全有效性，具有攻防能力的個人或團隊，能够解决實際安全問題。（3）三級：自動化級。具有自動化監測、響應、處理甚至反擊能力，對企業自身安全現狀和能力具有全域掌控力，具有入侵感知能力，能進行一定級別的攻防對抗。（4）四級：智慧級。採用了白名單的安全防護原則，具有真正意義的智慧安全檢測，能够對偏離正常行為模式的行為進行識別。（5）五級：天網級。天網恢恢疏而不漏，讓所有惡意行為無所遁形。這級別的安全是什麼樣，我不知道，也沒見過。

無論怎樣，還是堅持適合自己就是最好的原則。如果需求是一輛自行車，結果來了一輛專機，結果也未必好吧。

人生最美好的莫過於各種經歷和難忘的體驗，過程比較痛苦的，結果都還比較好。如果大家和我一樣，在企業做安全中遇到各種頗為“痛苦”的體曆，過後你一定會感謝和懷念這份體曆的。

部分觀點和內容參攷以下文章，表示感謝。1.《互聯網企業安全高級指南》，趙彥江虎胡乾威編著2.《防患未然：實施情報先導的信息安全方法與實踐》，Allan Liska著3.《網絡安全監控：收集、檢測和分析》，Chris Sanders、Jason Smith著。

附注：

• 聶君，資訊安全從業人員，十餘年金融行業資訊安全從業經歷，默默無聞。從業經歷包括資訊安全、ITIL、銀行內控，擔任國際災難恢復協會中國區（DRI China）常委。好讀書，不求甚解。性格開朗，愛好足球。

聶君，資訊安全從業人員，十餘年金融行業資訊安全從業經歷，默默無聞。從業經歷包括資訊安全、ITIL、銀行內控，擔任國際災難恢復協會中國區（DRI China）常委。好讀書，不求甚解。性格開朗，愛好足球。

• 本公眾號是個人對工作生活的一些體驗和經歷分享，站在不同角度和立場解讀會有偏差，見仁見智，不求正確統一，但求真、善、美。

本公眾號是個人對工作生活的一些體驗和經歷分享，站在不同角度和立場解讀會有偏差，見仁見智，不求正確統一，但求真、善、美。

長按識別二維碼，和我交流