安全運營中心專業筆記

轉載了別人,初步看來下,應該是機翻的,看起來有些難懂,但是可以初步瞭解下。
轉載的地址:https://www.jianshu.com/p/f7d9b9f8fc4c

一、SOC 定義

安全運營中心(SOC)對不同的人有不同的含義。有些人說他們“運行安全平臺”,別人說“他們處理事件”,還有人說“他們監控網絡的安全”。BTHb:SOCTH中SOC的定義爲:

一個集中在單一組織中的團隊,負責監控信息技術環境中的漏洞、未經授權的活動、可接受的使用/策略/程序違規、網絡入.侵和向網絡外入.侵,併爲網絡事件響應過程提供直接支持。

簡而言之,SOC是第一道防線。這個定義包含了成功SOC的幾個重要策略。首先,SOC必須處於單一的管理和報告結構下,這樣它就有了清晰的權限、資金、報告和責任。其次,SOC必須瞭解業務和IT環境的所有方面,從最小的工作站到雲中的最大超級集羣。第三,SOC需要了解其運營領域(AO)、它們將如何支持業務、監視業務應用程序和基礎設施。這些標準必須包括在SOC憲章中。第四,SOC預算需要足夠大,以持續投資於人員和支持交叉培訓,而不是超級複雜的軟件。這一概念引出了第五個策略:訓練並鼓勵分析師保持冷靜,正確解讀警報及其支持數據。這要求SOC分析人員受過良好的培訓。

有一點值得詳細說明。SOC團隊可以通過幾種不同的方法來建立它的AO。SOC可以使用IT通用控制程序、公司政策/程序、來自ISO 2700X系列等標準的指導,或者遵循互聯網安全中心的20個關鍵控制。在設計、構建、配置和操作SOC時,您需要開發一個章程和任務聲明。

爲了實現這些不同的策略,SOC需要知道網絡、應用程序到服務器的關係、網絡上正在發生的事情,並且能夠確定該活動是否對組織構成了需要有效處理的足夠大的風險。SOC團隊不使用複雜的SIEM軟件解決安全問題。他們用知識、技能和能力解決問題。複雜的SIEM工具有所幫助——但它們不是技術上的萬能藥。

二、SOC章程

每個安全運營中心都需要一個“章程”。SOC章程定義了SOC如何服務於業務、任務以及定義治理和操作規則,它的操作領域是什麼,以及組織需要如何響應警報條件和監視SOC的執行。

請注意SOC章程與項目章程並不相同。SOC項目實施章程是授權項目開發SOC、可能實現SIEM並授權項目經理應用資源和創建SOC的正式文件。

SOC章程通常與SOC/SIEM項目實施章程同時制定。SOC章程的範圍應該適當,而實現章程是項目管理協會(PMI)定義的文檔。這個術語來自作爲“項目構件”類型的項目知識管理主體(PMBOK)。不要混淆這兩者。

三、業務價值鏈緊密相連

IT人員通常不接受的一個概念是業務“價值鏈”。價值鏈是一組活動,這些活動接受輸入並將其轉換爲輸出,從而爲市場帶來有價值的服務或產品。價值鏈包括:資源生成器、入站物流、製造或服務運營、營銷、出站物流或服務交付,以及售後服務和支持運營。今天,價值鏈中很少有不依賴於某種形式的信息技術的方面,而這些信息技術必須按照IT一般控制程序進行監視和完全保護。

對於SOC,以及一般的IT,爲了與業務相關並與業務溝通,他們必須瞭解業務如何表述,以及業務的上下文和運營概念。從形式上講,價值鏈應該在市場上創造某種形式的競爭優勢。

四、識別SOC的服務

安全運營中心可以爲業務和IT提供許多服務。當您考慮這些服務中的每一個時,請確保將它們合併到您的SOC規劃過程以及支持技能、數據源、響應模式和人員配置中,以在SOC的生命週期內實現該服務。

此外,當您的組織考慮它將爲業務提供的服務時,請小心構建那些僅通過採用您能夠成功交付的服務就能夠成功的服務。SOC運營團隊的核心服務如下所示。您的組織肯定會基於您自己的能力、資金和人員水平來實現這些服務。

監視安全狀態:這是SOC的主要角色:監視安全條件、警報、安全平臺的健康狀況的環境,並通過組織提供各種技術解決方案進行響應。

命令功能:這可能是一個重複的活動,因爲SOC協調警報響應、事件響應和取證過程。事件指揮可以是一個非常密集的過程。事件指揮意味着SOC將識別事件,與處理程序合作,協調遏制行動,協助根除工作,從事件中獲取信息,並根據新發現的情報更好地實現內部系統,還可能支持推出更新或其他修復。

發起和管理事件響應(識別和補救支持):SOC的活動和檢測的一個重要部分集中於基於警報和NSM工作發現和驗證安全事件。SOC可能被授權從供應商、承包商、二級業務單位(SOC和IR職能之外的各種人員)發起特定的IR支持。在這些情況下,需要使用一組提供給SOC/IR團隊外部的可發佈數據來定義操作流程。不要做自由撰稿人,也不要在旅途中編造這些觀點——要提前計劃。要開始計劃,請檢查應用程序清單,並確定是否可以在內部處理IR支持,或者是否需要聘請第三方。如果你已經計劃好了,那就用桌面練習的形式,每年至少鍛鍊兩次。一旦穩定下來,將各種真實數據或活動組件集成到IR計劃的測試中。逐步加入外部***測試團隊,勾勒出參與結構,並對藍隊進行測試。

漏洞管理:SOC管理器可能被要求幫助甚至運行一個漏洞管理程序。SOC管理人員應該非常謹慎,不要承擔SOC可能無法處理的任務:開發和部署一個雙向的、全面的VA/VM程序。通過安全查找、通知、跟蹤和嘗試識別系統所有者和管理員,然後及時獲得系統管理員和數據所有者對補救漏洞的支持,這可能是一個勞動密集型的過程。此外,一個有效的VA/VM程序需要在業務上下文和概念層中執行,這意味着程序的焦點應該遵循業務臨界模型。這些都是複雜的運行一個程序,可以拉伸SOC。

取證/eDiscovery:根據SOC的規模,取證支持可以在內部進行,或者SOC可以與第三方協調和支持取證檢查。組織內的eDiscovery通常使用相同或類似的工具,在收集特定於案例的信息時需要進行鏈託管,並且還將分析數據收集的結果。一個關鍵的不同之處在於,eDiscovery專注於從活動中收集特定的搜索信息,使用由人們生成和使用的數據和信息存儲庫。取證技術更深入,檢查來自文件系統的系統構件,這些構件顯示了用戶與文件和數據、駐留在內存中的惡意軟件或從磁盤刪除的數據交互的意圖。

報告:運行報告以支持遵從性需求和IT一般控制監視。運行報告以支持警報、事件和其他報告需求。響應其他數據請求。

惡意軟件分析:如果SOC分析人員能夠安全地恢復惡意軟件樣本,那麼他們可能傾向於使用VirusTotal、JoeSandbox或ThreatExpert等服務執行一些輕量級的惡意軟件分析。這個建議在十年前是有用的,現在已經不再被認爲是最佳實踐。2017年,更好的做法是通過一個建在Cuckoo沙箱上的本地惡意軟件分析引擎運行樣本,以防止通知攻.擊者,攻.擊者可能正在監視在線服務如何找到他們的惡意軟件。這些工具允許用戶上傳可疑的二進制文件,然後通知是否已知錯誤,並提供不同級別的活動分析,如註冊表更改、新服務、文件系統更改、正在使用的IP地址或查找的域名。如果分析揭示了一些可疑的東西,那麼SOC分析人員將獲得運營情報並能夠更好地搜索安全數據。更復雜的逆向工程是一項非常專業的技能,需要爲此目的設置環境。

入.侵檢測:在網絡或主機上可以部署多個檢測系統。這些檢測系統(Snort、Suricata、Bro、PassiveDNS等)都需要護理和餵養,以確保正常運行。贏得預算但不維護規則集的NIDS平臺並不是最佳解決方案。

通知完善和改進:對於被認爲有效的警報條件,創建通知併爲接收方提供足夠的支持信息。

網絡安全監控:NSM是基於網絡級數據收集、檢測、分析和升級表示入.侵的指示和警告。

威脅搜索:威脅搜索是一個主動的過程,它從本質上假定存在某種形式的入.侵或入.侵。威脅狩獵首先產生一個破壞的假設,然後檢驗這個假設。它包括從縱向和總體上對流程、賬戶活動和事件的系統審查。威脅搜索用於檢測數據挖掘帶來的安全威脅、入.侵、誤用和破壞。

平臺健康監控:監控SIEM儀表板和警報流,根據優先級對警報進行審查和處理。監控SIEM平臺和其他支持數據源,以發現問題並與數據保管人合作,確保數據的可生存性。隨着環境的變化,更新平臺定義(資產、網絡、特權用戶、警報等)。包括通過檢查確保事件被解析並創建新的或改進的警報來維護源數據的可用性和質量。

網絡威脅情報:分析對手的能力、動機和目標。網絡威脅情報(CTI)是分析對手如何利用網絡領域來實現他們的目標。在考慮CTI時,應該使用多個源。並非所有的CTI來源都是相同的或提供相同程度的覆蓋。此外,CTI(在我看來)還包括瞭解軟件漏洞和現成的攻.擊者功能。例如,本週添加了哪些新的Metasploit漏洞?Metasploit大大簡化了漏洞利用的過程,因爲漏洞被封裝在可重用的代碼中,在您所依賴的技術中宣佈#漏洞之後,新漏洞出現的速度有多快?通過了解來自IR社區(如SANS、TrustWave、IANS、FireEye、CrowdStrilce、AlienVault和EMC/RSA)的攻.擊工具、供應商公告和帖子,您可以構建一個非常低成本的CTI程序,然後做出購買決策。

威脅情報集成:這是一個仔細選擇並將威脅情報feeds引入系統的過程,以改進警報和更好地識別可疑或惡意源、目標、域和其他模式。威脅情報來源及其提供的信息應該在檢測路線圖上。

策略和過程支持:許多監視控制和功能應該直接與已建立的策略和過程相關聯。在實現用例時,確保SOC將如何支持PnP強制執行。更具體地說,隨着這個服務領域的成熟,確保編寫SoP來定義SOC將如何正確地與用戶、主管、HR和法律打交道,以應對違反PnP的情況。

內部培訓:鐵器必須磨鐵,所以SOC管理團隊必須確保,當SOC發生變化時,必須對生產線人員進行培訓並保持最新。例如,當一個新的數據源集成到SOC中時,所有成員都需要對數據源以及如何正確使用數據源進行簡要說明。

四、SOC項目規劃大綱和專業說明

“如果你計劃失敗,你就計劃失敗。”

-通常認爲是本傑明·富蘭克林

而不是重複BTHB:SOCTH中的任何內容,這是一個基於PMI PMBOK規劃SOC的濃縮大綱。此外,不要回避使用PMI PMBOK,因爲“項目經理很煩人”、“項目管理毫無用處”或“沒有那麼難”。一個瞭解如何在預算之內按時完成項目的可靠的PM是一個非常好的夥伴。這部分提供了一個沒有多餘的,只是事實,討論SOC和SIEM計劃。

1、開發關鍵業務重點是理解組織以及SOC如何支持其目標。

(1)理解組織對SOC的需求,這意味着您需要理解組織的目標和目的,通過能夠闡明SOC如何保護組織生產、銷售或向他人提供的服務,SOC將具有更高的可信度,與業務相關,並支持組織的使命聲明。

(2)瞭解SOC需要解決的業務問題,以及SOC需要監控的價值鏈資源。您可能需要更多的以“遵從性”爲重點的SOC、戰術SOC、以事件爲重點的SOC,或者這些的一些組合。除了一般的IT資源外,SOC還將監視價值鏈的幾個組件。智能地針對價值鏈進行監控的SOC將更加成功,並且與業務相關。

(3)確定SOC的支持者。發起、構建和部署SOC可能會遇到困難。SOC經理必須確保支持者關係得到良好維護。“客戶”應該想要SOC服務,而不是把它們扔到他們的膝蓋上。其他業務角色將需要配備良好的人員。評估人員和監管者是“外部利益相關者”的例子,這些角色將由具有不同技能水平的審計人員擔任,他們試圖衡量和報告組織內的風險和合規程度。瞭解涉衆可能會提出的問題,將爲向SIEM平臺報告應該實現的用例、報告和數據源提供信息。

(4)確保SOC及其支持的日誌基礎設施有實際的需求。準備好闡明需求,並解釋員工和技術能力如何滿足需求。在這裏,您應該開發一個正式的業務案例。準備好證明構建SOC所需的人員、資源、訪問和軟件的合理性。

(5)開發關鍵的“安全狀態”理解(“現狀”與“未來”狀態)。這種理解本質上是技術性的,並且與傳統IT視角下的各種用例和監視需求相對應。在可能的情況下,將安全狀態監視功能與價值鏈組件和IT General Controls程序連接起來。請參考您所在行業最適用的標準,如ISO 27002。更多信息見第241頁。)

2、構建您最初的業務案例、章程、項目計劃、預算請求和支持構建SOC的理由。這個過程可能需要三到八個月的努力。設計階段,確定每個階段的關鍵投入和產出,以及誰將支持每個項目階段。

(1)定義組織的所有權、職責和SOC位置。試着找到一個能容納兩倍於第一年人數的空間,這樣你就不用在第三年搬家了。

(2)確定SOC的關鍵角色:“架構師”、“工程師”、“分析師”、“經理”、“customer”、“sponsor”和“利益相關者”。其中一些角色幾乎與PMTs PMBOK(腳註中的定義)定義的角色相同。

(3)確定相關的策略、過程和治理。審查現有的PPG並確定它們是否支持SOC。確保SOC功能集成到ITIL流程中,特別是變更管理流程中。SOC將需要使用變更的遠期計劃、維護窗口更新和變更成功的通知5。作爲一個監控服務,SOC團隊需要了解變更,這樣他們就不會在變更失敗時過度反應。

(4)編制必要的人員編制、培訓和教育程序文件。具體的第一年計劃。一旦這樣做了,制定一個三年計劃,並假設您將擁有高於平均水平的SOC分析師的高需求,而事件響應往往會耗盡人們的精力。注意,一個人的SOC不是SOC。通常是一個極有動力的人,他會做出英勇的行爲,但最終卻會精疲力竭,或者是一個人在管理一個SIEM。

(5)進行當前數據源調查。識別數據源、它們的日誌配置、資產、應用程序、資產映射的應用程序、數據或日誌是否適合SOC。您不應該假設每個候選數據源都得到了很好的工具化,並且具有審計SOC所需的級別。

在準備數據源調查時,請保存描述日誌工作方式及其值含義的供應商和產品文檔。稍後您將需要這個細節。在此過程中,您需要了解每個數據源如何向將來的SIEM提供信息:syslog (UDP或TCP)、文件寫入、數據庫表、SNMP陷阱等。

(6)進行環境數據庫存調查(EDIS):您不僅需要源系統數據,還需要關於網絡、組織、用戶和應用程序的元數據。數據包括用戶及其人員統計、網絡地圖、地址範圍、正在使用的應用程序、應用程序到服務器的映射以及組織結構圖。這些數據源中的許多將通過自動化向SOC和SIEM提供信息,因此確保至少爲存儲這些信息的系統獲得“只讀”憑證。

(7)在EDIS審查過程中,估計合併用例數據源的時間。

(8)在EDIS評審過程中,包括項目特定的行項目,爲SOC團隊開發一個簡要說明,解釋每個數據源字段集和字段值。

(9)支持SIEM的技術供應過程。計劃兩倍於你認爲第一年需要的數據。

a、硬件:包括磁盤和磁盤控制器架構,受日誌記錄需求和SIEM平臺的影響。

b、虛擬化層:現代虛擬化技術使您的SIEM虛擬化成爲一個非常有吸引力的選項。在考慮此選項時,根據數據庫和/或數據存儲所需的IOPS來明確表示數據速度非常重要——不要假設這將由您的基礎設施團隊來處理。

c、日誌存儲體系結構、腳本和長期存儲需求。對於長期存儲,您確實需要空間超過速度,因爲您很少會返回超過90天閾值的數據。可靠、安全、大容量的長期儲存比驚人的速度更重要。高速度需要針對過去三天的日誌。

d、SIEM和支持軟件。請注意,大多數主要供應商都有自己的預定義項目計劃來實現他們的軟件,您應該充分利用這些計劃。

(10)花時間在預算過程上。SIEM實際上是企業範圍內的一個主要應用程序,它與任何企業項目一樣需要嚴格的預算。這意味着先建立一個第一年的模型,然後是3年的預測,然後是5年的預測。預算開發過程的重要組成部分是開發所有權的總成本模型。您需要了解組織的技術更新模式,以便計劃系統替換。您應該假設日誌存儲每年增長50%。

(11)應用程序和IT資源數據供應和可能的開發。在這個階段,您將設計如何將每個應用程序和數據源集成到SOC和SIEM中。它通常涉及一些重要的定製開發工作。每個數據源都有自己的功能,需要某種形式的報警支持。

(12)爲了使這個過程很好地工作,找出組織安全狀態中的漏洞,並對風險進行量化。要做到這一點,請找到您的風險管理主題專家(SME)或聯繫人(POC),並與他們合作。

3、審查收集第27頁的主要數據來源。對於每個數據源,您都需要以下規劃和實現元素:

a.識別PoC。

b.決定如何收集數據源。

c.檢查當前的審計和日誌配置是否合適。

d.儘可能估計數據量。

e.確定數據是否可以被修剪。

f.從數據源中整理數據字段,並制定內部SOC培訓計劃,使SOC所有人員都能理解數據源。

g.根據需要,實現必要的變更控制,以配置數據源向SIEM報告。

  1. 構建日誌體系結構、源數據收集交付、SIEM和日誌部署計劃。有關SIEM部署檢查表的更多信息,請參見第194頁。同時,簡要:

a.根據與您的業務模型、獨特的數據源、遵從性需求和InfoSec程序相關的用例構建的評分模型,執行軟件和供應商選擇。

b.審查審計立場,併爲環境中提供數據的每個系統構建每秒事件(EPS)評級。然後計劃50%的增長,這樣你的解決方案就能經受住“事件風暴”。在配置了源系統的審計級別之後,確定EPS是非常重要的!

c.提供硬件和存儲平臺並實現。

d.監控數據提要、報告和系統響應時間。

e.爲商品源構建數據集成計劃,並仔細選擇定製源。例如,ERP應用程序可能不受支持,因此您可能需要開發一個數據庫查詢來從審計表中提取數據、實現審計、測試、開發一種方法來將當前數據存檔到歷史表,並進行監視,以確保查詢過程對系統的影響最小。

  1. 構建用例:

a.在這本書中有整整一章是關於構建用例的。回顧所有這些材料,並將其與您選擇的平臺中的用例進行比較。

b.計劃如何實現供應商定義的用例,因爲這些用例應該提供基線覆蓋率。

c.預測實現您自己的自定義用例所需的工作量和數據源。

d.從那裏,對實現進行優先級排序,這樣您就有了支持定義掙值的項目度量。

  1. 構建您的響應流程,該流程由到達的各種數據和您的需求所支持。

a.響應過程將由您的安全程序和您正在遵循的適用標準驅動。

b.規劃過程的這一部分應該回答這樣的事件解決問題:“當我們從系統B獲得條件A時,分析人員要做什麼,系統管理員需要什麼數據來解決事件?”

c.實際上,將數據拉入SIEM的過程將爲SOC功能提供許多需要處理的場景。當您構建這些過程時,確保您關注的是結果——需要實現的目標是什麼。

  1. 構建SOC指標,如第38頁SOC指標中定義的那樣。

  2. 建立並實施你的持續培訓計劃。

a.培訓是一個持續的過程。SOC技能需要隨着攻.擊者技能和判定能力的提高而提高。確保至少有兩級教育的預算。爲高級員工提供優質的教育,然後爲初級員工提供OTJ培訓,包括知識轉移、短期課程和以工作技能爲重點的教育。調查當地社區大學的勞動力教育計劃和能力。

b.有幾種開源或非常低成本的選擇。考慮一下ENISA, SecurityTube, SANS Cyber Aces, Cybrary, local BSides conferences, DerbyCon, and the annual Security Onion conference作爲更便宜的教育選擇。

五、思考並準備好回答棘手的問題

爲了資助SecOps、SIEM和SOC,您無疑將面臨許多問題。以下是我多年來被問到的一些問題,經過壓縮後將發表。在建立資金請求時確定答案。

  1. 什麼也沒有發生。我們爲什麼要這麼做?你怎麼能肯定什麼也沒發生呢?作爲一個可能的答案,試試這些。不是如果,而是什麼時候。”

  2. 團隊將如何檢測和響應安全問題、事件和數據泄漏?我們以前是怎麼做的?這不正是系統管理員所做的嗎?

3.該組織去年發生的事件是否產生了任何費用?病毒爆發?我們的同行和競爭對手爲此付出了什麼代價?

  1. 有多少處於哪個“級別”的用戶受到某個事件的負面影響(比如生產力下降)?

  2. 你將如何衡量自己,並獲得IT平衡計分卡?作爲一種可能的方法,詢問您是否可以在SOC charter開發過程中使用業務記分卡。

  3. 團隊將如何確定哪些警報條件優先於其他條件——誰贏了?(提示:與關鍵業務流程和收入流保護相關的資產價值)。

  4. 我以爲我們去年在安全上花了X。你爲什麼想要更多?

  5. 我知道我們沒有任何值得偷的東西。爲什麼我們需要做越來越多的安全“存根”?

  6. 這些東西不是花了幾百萬嗎?

  7. 我們正在進行脆弱性評估。難道這還不夠嗎?如果你沒有積極及時地進行補救,那麼就沒有。

  8. 那些安全人員一直在說不,所以這次我要對他們說不。所以在那裏。

  9. 我們可以成功地以1/8的成本外包出去,對吧?畢竟,供應商就是這麼說的。你爲什麼不同意他們?他們不是專家嗎?

  10. SOC將如何爲我們解決業務問題?

  11. SOC是什麼樣子的,第1年,第3年,第5年?

  12. 我不想買更貴的安全人員,只讓他們辭職。你打算如何留住員工?倦怠?摩擦?內部轉移?我最近在一個安全會議上聽說,當人們接受SOC工作時,他們計劃在18個月內辭職。

  13. 你怎麼知道你已經成功了呢?SOC的成功和失敗是什麼樣子的?(或者是大筆的證券購買?)

  14. 你又和審計員談過了嗎?他們去年說過一些關於這個的事情。我買了一個新的防火牆。

  15. 先給我看看劇本——你能做到嗎?完成後再回來。

  16. 這是外包的,是“X公司”的責任,不是我們的。我們沒有責任,因爲這是外包供應商的責任,而且是在雲/供應商合同中。

20.你能用三分之一的錢做什麼?因爲我們只有這些。

  1. 去年我們在SOX法案上花了350萬美元。沒有更多!

六、收集重要的數據源

有許多基線系統需要監控,因爲它們代表了在事件中需要的關鍵數據源,並且支持遵從性。這是EDIS過程的一部分。這些需要收集的資料系統和數據來源至少是:

  1. DNS活動,首先關注內部到外部活動(約佔網絡DNS請求/響應流量的8%到10%)。

  2. Windows域控制器安全日誌。

3.大多數(如果不是全部)Windows成員服務器。

4.工作站上的帳戶生命週期、流程執行和狀態指示器。此項目最好使用Windows事件轉發和事件訂閱來完成,因爲這是Windows中內置的本機功能,可以防止部署另一個代理。

  1. 邊界防火牆。至少,任何出站“拒絕”、接受和拒絕DMZ的流量以及平臺更改。如果您有容量,也可以收集出站接受事件,前提是不能爲通信流獲得更好的數據源。例如,如果您有一個代理,如果您可以獲得代理日誌,您可以考慮不記錄防火牆數據到/從代理。代理日誌優於防火牆日誌,因爲它們是應用程序感知的,並且是用戶可歸屬的,而防火牆數據通常不是用戶可歸屬的。

  2. 數據庫帳戶活動和帳戶管理。

  3. 對於Linux,至少要收集sudo、auth和authpriv日誌。

  4. 防病毒集中控制檯數據。

  5. 轉發(出站)代理數據。對於代理,驗證系統是否記錄了用戶代理、引用者、URI查詢字符串和允許/拒絕決策。如果代理理解站點類型,這也很有用。

  6. “在雲中”編輯文檔,比如谷歌的GSuite或Office 365。這意味着誰觸摸了哪個文件以及如何觸摸。

  7. 共享存儲文件系統活動,如誰觸摸了哪個文件以及如何爲用戶和進程公開共享。

  8. VP.N的活動。

  9. DHCP的事務。

  10. 網絡設備認證通常通過RADIUS或TACACS+進行。此外,網絡更改檢測通常來自Syslog事件。

一旦您將自己的“必須擁有”添加到此列表中,您的下一個任務就是獲取每個源的每日數據量。成交量有三個因素:每天事件的平均事件寬度,以及典型的峯值或峯值時間。

七、有用的MBA概念:SWOT和PESTL

在設計、規劃和構建SOC時,有兩個業務管理概念可以提供幫助:SWOT和PESTL。

SWOT分析

SWOT是一種戰略規劃技術,用於幫助組織識別優勢、劣勢、機會和威脅,每個經理都應該瞭解這些,並準備在戰略規劃練習中使用。構建SOC是一項內部業務風險,受到內部和外部壓力的雙重影響。SWOT分析將改進您的SOC業務案例,也將幫助您進行計劃,如果做得好,還可以幫助確定將對組織發起攻.擊的對手。下面是一個非常簡短的例子,讓您瞭解SOC項目的SWOT分析是什麼樣子的。

表1 SWOT分析實例

PESTL分析

PESTL(政治、經濟、社會文化、技術和法律)分析是宏觀經濟和宏觀環境因素推動組織的框架。戰略管理、市場營銷和業務開發團隊都需要使用它,他們需要對組織在特定的業務風險中如何執行有堅實的理解。PESTL分析將幫助SOC從兩個維度進行規劃:組織消耗或生產的技術的變化和速度,以及組織運行和存在需要監視的立法或監管環境。

八、資助SOC

永遠記住,一個組織有一個特定的使命或目標,它在使命聲明中闡明瞭一組目標來實現它的目標。由於SOC團隊很少是利潤中心,它應該確保資金請求與組織和支持業務的應用程序保持一致。

理解應用程序堆棧。SOC領導團隊需要了解組織是如何從其價值鏈中獲得資金的,並相應地瞭解SOC可能從資本支出(CapEx)和運營支出(OpEx)中獲得多少IT支出。實際上,這意味着您的團隊需要一個業務應用程序的臨界性清單,然後是服務器、數據庫、存儲和支持這些應用程序的網絡連接的映射。有了這個模型,您就可以調整監控控制、功能和工具,以支持這些應用程序的可用性、完整性和安全性。您的災難恢復計劃/業務連續性計劃(DRP/BCP)團隊可能非常有價值,因爲他們對應用程序堆棧有一個基於關鍵度的視圖。如果你沒有一個DRP/BCP團隊,你可以自己構建應用程序清單,目的是將工作用於SecOps,因爲它將在需要恢復事件時提供幫助。

例如,您的組織可能有一個電子商務的存在。電子商務鏈上有幾個組件:數字店面、訂單處理、向客戶和供應商發送消息、WAN鏈接、後端數據存儲、管理所有這些IT組件的員工,以及保護信用卡交易。僅在該列表中,就有數十個服務器、技術、人員和流程。因此,如果安全團隊能夠將監視和事件響應置於適當的位置,以便它能夠在基線中檢測違規行爲,並確保組件正在工作,那麼它就支持了公司的使命和業務銷售商品和服務的能力。

確定資助SecOps的原因:資助安全操作和soc和SIEM平臺所需的日誌基礎設施的原因有很多很多。

1、法規遵從性(HIPAA/HITECH、Sarbanes Oxley和其他)。

2、先前的事件可能會引發資金事件。

3、出於真實的願望或恐懼反應的管理指令。

  1. 您選擇的標準定義了它的結構,並因此被審計,可能需要SOC和一個日誌平臺。

  2. 給定系統中的日誌是易變的。有些系統,比如Windows域控制器,只保存幾個小時的日誌數據,然後數據滾動並永遠丟失。有些系統將數據保存在內存中、緩衝區中,當電源或電源丟失時,數據也會丟失。

  3. 沒有日誌,你沒有能力回到歷史,發現問題一安全,操作,或改變有關。

  4. 事實上,這是“正確的做法”。

九、安全操作中心需要成本

在構建安全操作中心時,需要考慮許多成本組件。下面是許多常見的成本組成部分。對於每種成本,在開發“構建vs.購買”分析時,請仔細分析您當前的環境。

直接成本——在這個列表下面有更多的信息。

  1. 內部人員編制。一年365天,每週7天,每天24小時,至少需要5個人,使用最簡單的人員配置模式。目標9名員工和1名SOC經理。

  2. 廠商中立的訓練。例如SANS、Security University、CompTiA CASP和ISC2 SSCP。

3.產品培訓:SIEM解決方案有供應商提供的培訓。

  1. 工具:桌面基礎設施、操作系統、Office、SIEM許可證和調查工具。

  2. 訂閱:soc將有幾個訂閱服務,特別是威脅情報服務。

  3. 硬件:服務器、存儲和網絡基礎設施。注意典型的硬件更新週期——通常是4年。

  4. 取證硬件:取證硬件有獨特的要求,因爲這些系統通常被隔離在一個鎖着的房間裏的小局域網中。例如,一個名爲FRED的自定義取證工作站可能要花費5000美元以上,在中央存儲上存儲圖像可能要花費很多tb,而寫阻止程序包很容易花費1000美元以上。

  5. 包括年度維護的軟件許可費用:軟件包括SOC支持、各種管理控制檯的附加許可、SIEM平臺、攝取成本、取證包、PDF生成應用程序、Bl7工具和eDiscovery功能。

  6. 設施:SOC室,傢俱,共享大格式顯示器或投影儀,和接近卡或可能的生物特徵門控制。此外,取證分析空間應該有自己獨立的鎖和接近卡控制。

  7. 升級:每年升級一經常在SoW的基礎上由供應商處理。

  8. 供應商幫助:隨着時間的推移,您將需要供應商幫助提供新的內容、改進的報告、更多的培訓以及可能的升級。

間接成本:

  1. 招聘成本,如構建團隊,招聘和員工加薪。

  2. 初始項目的SIEM選擇成本,包括特定的、審查和選擇主要SOC工具集的勞動成本。

3.開展對SOC人員的工作培訓。注意,這將佔用關鍵的中小企業和時間的承諾不能低估。

  1. 集成新的數據源,這可能需要在平臺中創建定製的數據解析器、警報和報告。

  2. 定期的內部或外部審計支持。

人員成本考慮:安全操作中心需要由熟練的信息安全分析師組成。閃亮的SIEM解決方案不能解決問題,受過教育和經驗豐富的人可以。自從2001年參加了InfoSec,我可以確定它就是這麼簡單。高技能的人可以用一個適中的產品集產生比新手用一個超級昂貴的閃亮的工具集更準確和及時的結果。

基本工資、福利和不可避免的員工流動打亂了成本模型。美國勞工統計局(US Bureau of Labor Statistics)的數據顯示,信息安全分析師2016年的基本工資爲92,500美元,2017年爲95,510美元。如果你的內部管理費用是管理費用的30%,那麼一個負擔過重的職位每年的費用是124,163美元。按照這個速度,以2017年的美元計算,五個人每年需要620815美元。glassdoor.com網站2016年發佈的一項研究可以幫助瞭解招聘環境:公司花費4000美元通過公開招聘填補一個職位空缺,有52天的空缺期,47%的候選人會拒絕最初的報價。進一步的分析發現,50%的員工離職是因爲他們的經理。這些數字有助於定義如果您找不到FTE或需要替換FTE,臨時承包商的成本是多少。爲了將成本降至最低,應集中精力讓SOC人員通過投資期,並通過儘快讓他們開始處理特定SOC服務和IR任務,使他們進入回報期。

人員成本進一步受到覆蓋模型的影響。如果團隊使用24/7/365,那就需要4.52人,或者至少5個FTE來配備SOC的人員,並由一個人來配備設施。確實是一份孤獨的工作。這一數值是基於每年8760小時、兩週帶薪休假和8天假期得出的,其中48.4周是工作時間,即1936年的人均工作時間。實際上,任何24小時運作的團隊都應該至少安排9個人來適應假期、病假和員工流動。五個人將負責輪班,剩下的三個人將在高活動時間提供額外的保險,比如早上7點到晚上7點和週六的部分時間。這一估計中缺少的是“管理”時間的百分比。管理時間包括所有其他公司需要完成的任務,這些任務會減少實際的工作任務。

與其他技術行業相比,事故響應的燃盡率非常高。因此,通過不同的SOC服務來補償你的SOC前線,使他們在工作職責上有差異。此外,尋找那些渴望升職,而不是每天都做同一件事的分析師。爲了留住人才,SOC經理應該經常評估改變工作職責的機會。

設施/空間:大多數組織的辦公空間都有每平方英尺的價格,這應該在成本結構中。例如,2016年佐治亞州亞特蘭大市每平方英尺的平均成本爲A類空間20.01美元,B類空間16.36美元。如果假設共享工作組區域有90平方英尺,並且有兩個工作空間可供五人輪轉團隊使用,那麼對於兩個人SOC,每月的辦公空間成本爲2944.80美元。然而,還有其他的單個購買成本。例如,你可能想要兩個大屏幕顯示器和個人電腦來運行它們,所有的東西都掛在牆上。這可能是一個簡單的$4,000事件成本項目。

廠商中立的正規教育:假設您能找到安全人員,您仍然可能需要在SOC操作方面對他們進行培訓。截至2018年8月,SANS研究所的最佳課程之一是“SEC511:持續監控和安全操作”(Continuous Monitoring and Security Operations),並獲得GIAC GMON認證。本課程涵蓋了每個SOC工作人員所需的實踐技能。我可以證明,完成本課程和相應驗證的每個分析師的質量和速度都有可衡量的改進。2018年8月的成本爲6939美元。另外,在考慮培訓成本時,確保將差旅和酒店費用包括在內,並估計爲18009美元。留在第六天,爲SEC511硬幣競爭!

產品培訓:各大SIEM供應商都有一系列的產品培訓課程。這些通常包括在最初的建議和實現中。新員工入職時將會有成本。爲了支付費用,我申請了一個培訓學分,包括升級,系統增強活動,或者添加新產品組件。

組織專項培訓:在職培訓是一個持續的過程。有許多研究對開發健壯的和可重用的培訓的成本進行了量化。英國人才發展協會(Association for Talent development)的數據列出了43至185小時的教學演示(一門正式課程)所需的一小時授課時間,影響這一時間的因素很多。不要輕視它,也不要忽視它。爲了對學習型組織及其對公司的價值有一個簡明的認識,請回顧大衛·戈德史密斯在《付費思考》一書中的第七章。

桌面:分析師硬件、顯示器(越多,越快樂!),監控武器,客戶端軟件,幾十個應用程序的分析師許可證,傢俱,照明。想想Quad 24”或IT顯示,和Ergotron類型的Quad手臂。好了!

供應商支持:爲安全產品套件、用例實現和持續升級過程提供專門的供應商支持。這些支持關係通常以每小時爲基礎定價,每週的小時數最少。如果您的SIEM供應商收取每小時225美元的費用,並以最少4小時的時間銷售這種支持安排,則每年的支持成本爲46,800美元。

基礎設施:後端服務器、傳感器平臺、網絡儀表(如TAP)和多層存儲。在服務器維護之前3-4個月計劃一次服務器硬件更新,以確保您不會爲服務器維護窗口之外的在線服務器支付額外費用。如果你需要六臺服務器,每臺8000美元,那麼僅硬件就需要48000美元的初始資本支出。計劃每年20%的維護,並在四年後更新技術。我完成的大多數SIEM實現都是使用VMware 5和6進行虛擬化的。這個模型可能非常成功——但是您需要增加管理程序的成本。當涉及到實際容量時,爲您認爲需要的CPU和內存分別增加2和4 GB,並僅在該服務器上虛擬化您的平臺。你將獲得巨大的長期利益。這些功能包括卷快照、在技術更新期間複製到新平臺,以及更輕鬆地匹配驅動器配置的能力。

集成新的數據源:爲了在新系統上線時將影響降到最低,請將SOC工程人員合併到IT供應流程中。目標是確保新的系統或主要的系統更新能夠向SIEM/SOC團隊提供相關的日誌數據。這個人工費用應該分配給應用程序或系統,而不是SecOps,並且是SI EM生命週期中的一個循環成本項目。

內容開發:在SIEM解決方案中開發新的和細化當前用例。當前的用例也將根據來自威脅搜索團隊的改進進行更新。您對輸入數據、所需內容、分析、規則、通知、SOC操作和期望結果的定義越好,成本就越準確,成功的機會就越大。

SIEM軟件:SIEM平臺許可證通常是由規模因素驅動的。典型的因素是每秒事件(EPS)、每天GB或監控設備計數的“攝取率”。您將發現有一類與安全無關的事件,它們與真正需要的數據一起到達SIEM。根據許多因素(事件成本、處理能力、日誌存儲、事件寬度),您可能希望開發分層日誌記錄方法。這裏的成本差別很大,從每年2萬美元到更高。您定義的環境越好,您從供應商那裏得到的評估就越好。

SIEM軟件升級:企業系統的某些升級可以通過更新過程執行,而有些則不能。根據我在5個不同平臺上的經驗,我建議將複雜的升級(如重大升級)外包給SIEM供應商可能更好。一個典型的SoW將是40到80個小時,按照供應商的價格加上旅行和費用。確保您與您的供應商充分研究這一點,並將至少一個年度升級事件集成到您的平臺上。

審計證據支持:SOC經常被要求支持安全事件數據和事件的報告,以直接支持內部或外部審計。這一特定角色的人員配備與監管環境和審計人員提出要求的頻率密切相關。要估計這一點,請確定您的組織每年響應多少次審計以及支持這些審計所需的報告。SOC團隊應該始終記錄他們的時間來支持審計,因爲這是對業務的一種服務。如果你有重複審計與一個特定的單位,然後要求會計費用代碼,以證明成本的SOC,以支持業務單位。

十、內部、外包、混合SOC

現在您已經對構建安全操作中心的成本和大多數長期因素有了一個結構化的輪廓,您可以更好地考慮外包部分或全部SOC功能的利弊。以下是一些基於經驗的有關聘用外判管理保安服務供應商(Managed Security Service Provider (MSSP's))的意見:

  1. 啓動時間會有影響。MSSPs實際上在您的網絡上部署了部分到完整的SIEM解決方案。每個數據源都需要集成到平臺中,需要部署硬件,您的組織:仍然需要定義自己的事件響應流程。

  2. 一個MSSP在調查警報時只能走這麼遠,如果你幸運的話,MSSP可以很好地覆蓋50%到70%的警報情況,並將使你的組織參與到15%的觀察警報中。

3.mssp永遠不會像您那樣瞭解您的網絡,而且您無法輕鬆量化這對其服務提供質量的影響。mssp也不太可能知道網絡上發生了什麼變化,因爲他們很少參與更改控制。

  1. mssp通過定義的SLA和報告關係與您一起工作。他們不能代替你自己的員工可以直接接觸到一個系統託管一這是一個寶貴的好處有內部人員運行在一個安全操作的角色。

  2. 他們對警報靈敏度和配置的看法與您不同,因爲他們傾向於關注“真正的威脅”條件,而忽略或忽略許多其他條件。您對SOC的使用應該包括策略問題、威脅捕獲、審計報告,以及從SIEM將消耗的大量數據中收集操作價值。

  3. 如果任務不經常發生,那麼有些任務應該外包,比如系統分析。然而,今天的戰場空間告訴我們,我們需要的是內存映像,而不是磁盤映像。這是幾乎不可能的第三方外包MSSP收集,但可能在他們的能力分析。

  4. 您不能將您組織所關心的資產的安全性的責任委託給第三方,不管別人如何試圖說服您您可以這麼做。您可以授權進行操作,但不承擔系統安全的責任。

  5. 7/24/365由第三方監控比建立自己的6-8人團隊的勞動力成本更低。這是無法迴避的事實,如果你是被迫外包的,意識到這個論點,並想出方法來回應這個論點。

  6. MSSP也可以執行系統升級,並且很可能比你做了更多的升級。將執行年度升級的一兩個星期的部署成本考慮在內。

  7. 最後,你從一個MSSP關係中得到了你投入到MSSP關係中的東西。如果你不投入時間,那麼不要認爲他們會給你一流的結果。

十一、開始狩獵

從歷史上看,SOC將監視各種面向預防的系統,如果其中一個或多個平臺向團隊發出警報,則進行響應。然後,他們將花時間驗證警報,與系統管理員、所有者或最終用戶進行通信,如果情況是突發事件,他們將作出響應。

從2000年開始的“被動或被動的模式或姿勢”在今天已經不再有效。今天的SOC團隊需要改變他們的關注點,假設存在可能的破壞方案,變得面向檢測,並主動挖掘進入他們系統的大量數據,並主動尋找入.侵和不當行爲的模式。先發制人的威脅搜索是SOC分析員的理想職業和技能發展路徑。一旦他們瞭解了組織的所有數據源,知道如何處理警報,並證明他們已經建立了研究技能,利用這一點,讓他們參與到威脅捕獲中。根據SOC團隊的操作方式,您可以讓SOC分析師每週執行一天、每月執行一週,或者採取特定的狩獵路徑。威脅搜索在第167頁有進一步的定義,許多用例從第60頁開始。

十二、SOC直接支持CSIRT功能

今天,需要開發某種形式的計算機安全事件響應小組(CSIRT)功能是不能忽視的。在許多組織或行業中,CSIRT是由特定的法規規定的。現代惡意軟件猖獗、自動勒索軟件、工業間諜、犯罪分子、國家一級***團隊以及基於數字的非對稱戰爭的其他方面,對CSIRT的需求尤其迫切。聽起來很聳人聽聞,不是嗎?今天的網絡罪犯會利用他們發現的任何弱點,從任何潛在的受害者那裏提取無法追蹤的數字加密貨幣。不管聳人聽聞的程度如何,都有幾個理由在您的組織中提倡和構建CSIRT功能,而這又得到了SOC功能的支持。

  1. SOC提供了一種主動檢測能力,應該能夠及早響應並限制事件的長期影響。然後,CSIRT可以協調響應事件,以確定、控制和減少事件影響爲目標。此外,CSIRT功能可以將破壞或loCs的指標返回給SOC,以便SOC可以執行歷史數據分析,例如搜索與找到的IP或域名通信的內部系統。因此,一個更成熟的CSIRT和SOC團隊可以利用威脅搜索功能來尋找並發現最近出現在網絡上的惡意代理。

  2. CSIRT影響、支持並充分利用安全支出。它有助於確保SOC工具的到位將支持事件響應和安全操作。或者換一種說法,擁有一個單一的CSIRT應該確保環境的最佳工具已經到位,可以被利用,而其他工具則可以退役,以實現美元投資的最大化。

3.與內部員工溝通時保持客觀,對事件進行分類,並對響應過程進行優先排序。CSIRT需要處理的挑戰之一是人員關係和保持客觀性。與負責以統一和一致的方式執行公司政策和程序的人力資源職能一樣,CSIRT需要客觀、執行其工作以保護業務,並避免偏袒。

  1. 最後,監管。業務環境中有許多方面要求具備事件響應能力。這些包括但不限於:HIPAA/HITECH# PCI DSS 3.2,以及Sarbanes Oxley合規。

十三、SOC的指標

成熟的經營單位和企業運用各種方法來衡量經營單位的效益。SOC也不例外。問題是,你如何做到這一點,並避免讓員工失去動力的有害指標?

在《實用的安全度量標準》一書中。W. Krag Brotby和Gary Hinson提出了關於度量的幾個關鍵點。它們的一些關鍵定義列於第1.6章:

  1. 儀器:是“測量儀器”的簡稱,即測量儀器。

  2. 測量:(動詞)確定某物的一個或多個參數。

  3. 度量:與一個或多個參考點有關的度量。

在第2.6節中,他們指出“擁有有效的度量標準使業務經理能夠對信息安全做出理性的、明智的、甚至是站得住腳的決策。他們再也不能完全依賴信息安全專業.人士或通用的良好實踐標準、法律、法規的建議。”

在第3.2節中,他們聲明“度量標準主要是管理的決策支持工具。好的度量標準提供了有用的、相關的信息來幫助人們——主要是,但不完全是,經理們——根據歷史事件(背景)、現在正在發生的事情(包括可用的資源和約束)以及將來可能發生的事情(變化的必要性)的組合來做出決策。

有許多指標和測量,可以開發和應用於SOC。在設計度量時,有幾個標準。

在開發度量標準時考慮這些標準。

  1. 度量標準應該與作爲業務單元的SOC的目標、目的和使命相關。這意味着你應該能夠用數字描述你所做的事情,並解釋你沒有測量的東西。

  2. 當您評估您的數據、安全用例和度量時,請確保開發一個路線圖,其中包括您將度量的內容、如何捕獲這些度量、與IT常規控制和安全程序的聯繫,以及可能的業務價值鏈。然後,指標可以爲決策提供指導。

3.確保你所衡量的將會是一個可衡量的結果。不要爲了測量而測量。每一個指標都應該告知消費者,並設法改變他們的行爲,或者證明當前的行爲在既定的程序中運行良好。在這裏,您應該清楚地瞭解您期望度量的使用者基於度量所採取的任何操作。

  1. 度量應該支持“控件”,因此應該與ITGC程序匹配。如果沒有的話,可以參考ISO 27002之類的標準。

  2. 壞數據比沒有數據要好一點點。如果您沒有爲需要測量的數據收集任何源數據,那麼就從那裏開始,但不要停止。充分利用好數據。

  3. 避免給分析人員帶來負擔,使他們需要記錄過多的數據,使用一些人爲的方法來跟蹤他們的工作,比如使用複雜的電子表格。相反,開發方法來挖掘SIEM平臺、工作流系統、開放調查編碼和警報結束代碼,因爲它們通過警報工作。這些方法提供了一種機制經濟(EoM),因爲分析人員正在使用它們自己的工具。此外,遵循EoM原則可以促使您始終利用SIEM平臺的內部功能,從而降低出錯的可能性。

  4. 從你的業務/組織的角度講述你的故事。講故事時,記住聽衆並使用他們能理解的術語和定義是非常重要的。

  5. 我想到了兩個關鍵的縮寫詞:

A :聰明一點:具體、可衡量;切實可行、有時限

B: KISS,要麼保持簡單,山姆/蘇珊。這並不意味着可愛。相反,要確保度量的名稱和度量尺度是明顯的。需要解釋的度量標準不太可能是有效的度量標準。

  1. 確定如何構建一個記分卡來度量組織的信息和技術安全狀況。只要有可能,就構建一個工具來演示技術工具的工作效率。您可能不會將此工具展示給管理層,但您應該準備好展示。

表2一般SOC指標示例

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章