本文來自微信公眾號“君哥的體歷”,作者聶君。36氪經授權發布。
引言
本文是根據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家電視臺,超過32,000臺電腦以及部分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)常委。好讀書,不求甚解。性格開朗,愛好足球。