SOC的幾點問題

1、如今的SOC是怎麼作的

現有市面上的SOC產品在功能上各有各的特色，可是總的說來，核心功能都是以統一收集日誌（主要是 syslog日誌，也有SNMP拿到的信息，有些還能收集NetFlow/NetStream/S-Flow等日誌）爲基礎，再將收集上來的日誌加以標準 化進行存儲，再對這些日誌進行一些處理（如歸併、根據策略進行關聯等），再加以呈現（能夠是實時呈如今屏幕上，也能夠生成報表）。

以上是SOC的核心功能，在此以外通常還會有工單管理功能，也即一條告警過來之後就造成工單，讓管理員和各級主管能夠跟蹤一個安全事件的處理過程。至關於集成了一個OA系統。

有些SOC還會集成一些工具，好比漏洞掃描工具或者集成IDS配套。事實上，不少SOC的原型都是廠家IDS的管理端，在IDS管理端上增長收集其餘廠家其餘類型產品的功能，再作關聯分析而成。

除了產品設計之外，現有SOC在實施過程當中還有一個很是重要的工做，就是作日誌接口的開發。因爲市面上的安 全產品種類繁多，品牌繁雜，又沒有統一的日誌標準，好比天融信的防火牆，其不一樣版本的日誌格式都不同。故此任何產品都不可能兼容全部產品，那麼在實施的 時候，爲了把客戶現有的產品都歸入進來就必須進行接口的二次開發。不然必然會有一部分產品的日誌收集不上來，或者收集上來之後識別不出。

2、SOC目前的問題

SOC在客戶那裏最大的問題就是用不起來，不少客戶也以爲SOC說的很好，實際用起來徹底不是那麼回事。我的分析，主要問題有如下幾個：

* 因爲日誌來源自己的可用性問題，致使SOC不適用於安全的事前和事中處理。
不管是IDS仍是防病毒又或者IPS的日誌，都存在誤報和漏報的問題。對於誤報，SOC其實沒有很好的方法 加以識別。沒有可信的來源，在此基礎上所給出的建議等也就成了無本之木。而另一些可信的日誌來源也存在問題，好比防火牆日誌儘管可信，可是信息量太少， 在出現問題後追查時卻是可用，可是用於事前判斷***每每沒什麼意義。而IPS報出的高危日誌（假設不是誤報）每每都已經直接進行過阻斷，不必對其進一步 處理。綜上，因爲日誌來源的問題，SOC基本上不適用於安全的事前和事中處理。
* 受限於客戶的技術水平和其餘因素，致使關聯分析很難用起來。
SOC的一個故事就是經過關聯分析發現***行爲，分析***結果並定位***路徑。可是關聯分析的使用是有不少 限制的。首先是要知道分析什麼，或者說監視什麼問題，不然都不知道該把哪些日誌關聯起來，這就決定了SOC的關聯分析不可能處理未知問題。其次定製管理分 析策略須要對整個系統的日誌有着詳細的瞭解，同一個問題在不一樣環境下關聯分析的策略是不一樣的。舉個例子，咱們曾經給客戶定製過發現ARP病毒的關聯分析模 板，其策略是利用Cisco交換機的MAC衝突日誌，具體策略是當10s內衝突超過3次即認爲網內有ARP病毒，可是若是當時客戶有防病毒系統的話，直接 引用防病毒系統的日誌就OK了。分析環境定製關聯策略是須要很是高的技術水平的，不要說客戶的工程師，即便是廠家工程師，也不可能將全部設備的日誌都研究 清楚。所以，關聯分析策略是須要有必定技術能力的工程師進行長期磨合和調整的，而受限於成本，廠家和客戶都不可能長期搞這種事情。
* 對SOC系統自己的定位不清
因爲廠家的忽悠或者其餘緣由，客戶常常會對SOC系統抱有太高的指望，這使得客戶見到實際產品時每每很失望。這是對SOC的功能定位不清。
另外，若是SOC牽扯了工單管理，也即進入了客戶的管理流程，這和客戶的部門職能，甚至組織架構都是有關係的，這也使得這部分功能要不須要從新作二次開發，要麼很難用起來。這是對SOC的應用定位不清。

以上是我分析SOC目前使用很差的主要問題，前兩條是主要的技術問題，其實技術問題還有不少，如NTP的問題等等，可是以上兩條是我認爲最主要的兩條。而對SOC系統自己的定位不清則是使用的問題。

3、技術的SOC和管理的SOC

SOC在剛推出時，主要理論依據是「三分技術、七分管理」理論，認爲SOC是技術和管理的結合點。而如前面分析，SOC其實即沒有解決技術問題，也沒有解決管理問題，這其實就是SOC的定位問題。

在定位方面，有技術的SOC和管理的SOC兩種。SOC究竟應該是技術的？仍是管理的？筆者認爲廠家的SOC產品應該是技術的，客戶的SOC系統應該是管理的。聽起來有點和稀泥，可是倒是最符合現實的。

從廠家角度說，以及從客戶對廠家提供的SOC產品的指望角度來講，SOC產品應該是技術的，主要提供的應該 是對系統日誌的統一收集管理，若是有可能則作一點安全設備的集中配置管理。也就是說在解決方案中，SOC應該提供的應該是日誌審計+配置管理的職能，若是 作不到配置管理，那就作純粹的日誌審計使用。這也是SOC實施成功的第一要件，下降客戶指望。

從客戶應用角度說，SOC應該爲客戶的安全管理起到做用，也就應該起到安全OA的做用，可是如前所述，這可 能牽扯到客戶部門職能和組織架構的問題，所以應該和其餘OA系統同樣，根據實際狀況作定製開發。不排除能夠先提供一個比較普適性原型，而後在這個原型上作 開發，可是這部分的定製開發能夠說是必要的。

經過標準性的日誌審計+配置管理，結合定製開發的安全OA系統，最終能夠給客戶提供一個管理的SOC。

4、一個簡單的SOC的模型

安全事件的處理流程能夠簡化爲：「觸發」-》「決策」-》「處理」的循環，在加上一個全過程的「審計」或者「監控」。

其中「觸發」不僅是靠日誌收集和告警，緣由就是前面說的日誌源的可用性問題，應是人工觸發和SOC日誌觸發相結合。可是「觸發」之後，須要在SOC系統裏面快速彙總相關日誌，分析事件緣由，並造成處理意見提供給「決策」。

「決策」主要是根據SOC系統分析出的事件緣由和處理意見進行決策。由於可能須要多部門配合（好比網絡管理部門和系統管理部門配合），所以「決策」其實是一個協調過程。

「處理」就是根據「決策」的結論，各個部門進行技術操做，化解安全事件，恢復系統到正常狀態。

而對「觸發」、「決策」和「處理」的全過程應該有一個「監控」和「審計」的部分，留存證據，分清責任。

5、誰來使用SOC

這實際上是SOC可否起到做用的關鍵。一萬個客戶就會有一萬個不一樣的SOC，搞清楚誰來使用SOC也是決定一個SOC成敗的關鍵。筆者認爲能夠分爲如下幾種：

* 客戶的安全管理部門
這是要達到目前咱們宣稱的SOC做用的最佳使用者。這個部門的權限必定要高，才能將SOC系統的最大效能發揮。此時SOC能夠實現「觸發」、「決策」、「處理」和「監控」的所有內容。
順便說一下我對客戶IT部門架構的理解。隨着CIO地位的提高，CIO下屬應該有三個主要的部門，需求分析 部門（主要負責和業務部門溝通，分析IT需求），IT維護部門（負責平常的運維），IT審計部門，有能力的大型企業可能還有本身的開發部門，負責通常性的 業務系統的開發。安全管理部門應該隸屬於審計部門，不負責安全設備的維護。而安全設備的管理和運維則應該根據設備形態歸屬於不一樣的IT維護部門，好比防火 牆應該屬於網絡運維，CA和主機加固軟件則應該屬於系統管理等。
這種狀況應該是理想狀況，但實際上好像沒有任何一個地方是這麼作的，應該是很是高的IT應用水平纔會出現這種架構，呵呵！若是是另一個極端，客戶IT水平很低，IT部門甚至沒有下屬分支，其實也屬於這種狀況，也能夠這麼用，只不過系統自己會簡單的多。
* 客戶的運維部門
有些客戶有專門的安所有，負責防火牆等設備的運維。有些則是將安全劃分在網絡下面，屬於網絡運維的一個分 支。無論哪一種狀況，這種SOC每每不須要「決策」，甚至沒法有效的「處理」。緣由很簡單，由於這個部門沒有足夠的權限去驅動其餘部門（如系統管理部門）去 動做。此時要作的，是推進一個可以統管全局的領導（分管IT的副總）做爲一個獨立的決策點，這樣也能實現SOC的全過程，只不過這時，非重大的安全事件其 實也不能走這個流程，畢竟沒人願意處理個終端病毒問題而去麻煩副總。所以，這種狀況下，事件的分級處理就顯得很是重要。若是連推進分管領導都很難作到，那 麼SOC主要的做用，其實就是造成報表，並在出現安全事件時可以輔助分析事件緣由。
* IT外包的運維
此時SOC便可以做爲IT外包的服務工具（功能與狀況一基本相似），也能夠做爲對IT外包的管理工具。後者的功能就主要是對安全事件的整個處理過程加以監控了。

6、SOC的實施

前面提到，如今的SOC在實施過程當中，都須要對接口進行開發，這是繞不過去的。除此之外，應該對集成的安全 OA進行基於原型的二次開發。這樣才能造成一套客戶用起來還比較順手的SOC。除此之外，SOC在實施過程當中還有一個重要的內容就是關聯策略的定製，在收 取必定費用的前提下，廠家能夠派一個有經驗的工程師對客戶現網設備日誌進行一次比較全面的分析，並和客戶溝通其所關心的問題，定製出一套客戶所須要的關聯 策略。這個過程不可能過短，至少須要1個月，要想真正作好甚至可能須要2個月。這其實也是考驗廠家能力的地方。可是最重要的是，在SOC實施以前，要告訴 客戶在它的環境下，SOC究竟能作到什麼樣子，讓客戶對SOC有一個合理的預期是SOC實施成敗的關鍵。

經過這樣的一個SOC的實施過程，對前面所提到的SOC所存在的問題能夠基本上作到規避。好比，不讓客戶以 爲經過SOC能夠發現未知***，而把 SOC做爲過後處理的工具就能夠規避日誌來源可用性的問題。經過收費的策略定製服務，也能夠規避關聯分析所帶來的問題。而根據客戶部門的職能和組織架構提 出的針對性的SOC功能和二次開發則能夠明晰SOC的定位。

【小結】

總的說來，要想用好SOC，不能把SOC只當成一個和其餘安全設備配套造成解決方案的產品來看。相比於配套 解決方案，其實SOC其實更適合做爲安全諮詢服務的後續工做來作。如今客戶每每分不清安全諮詢服務和風險評估服務的緣由，其實就是二者的輸出太接近了，都 是一套相似的解決方案。而有SOC做爲基礎，安全諮詢在解決方案以外的不少東西就能夠落地了。