在上一個討論中，提及了SOC，于是，zeroflag也發表了一個文章，下面還有很多相關討論。各位SOC同仁可以一看。zeroflag稱自己并不做SOC，只是以前研究過一年而已，足見SOC之熱。呵呵。
這里也留存一份快照：
關于SOC的一點討論
作者 zeroflag | 2011-01-02 21:02
一、現在的SOC是怎么做的

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

以上是SOC的核心功能，在此之外一般還會有工單管理功能，也即一條告警過來以后就形成工單，讓管理員和各級主管可以跟蹤一個安全事件的處理過程。相當于集成了一個OA系統。

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

除了產品設計以外，現有SOC在實施過程中還有一個非常重要的工作，就是做日志接口的開發。由于市面上的安全產品種類繁多，品牌繁雜，又沒有統一的日志標準，比如天融信的防火墻，其不同版本的日志格式都不一樣。故此任何產品都不可能兼容所有產品，那么在實施的時候，為了把客戶現有的產品都納入進來就必須進行接口的二次開發。否則必然會有一部分產品的日志收集不上來，或者收集上來以后識別不出。

二、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系統本身的定位不清則是使用的問題。

三、技術的SOC和管理的SOC

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

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

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

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

通過標準性的日志審計+配置管理，結合定制開發的安全OA系統，最終可以給客戶提供一個管理的SOC。

四、一個簡單的SOC的模型

安全事件的處理流程可以簡化為：“觸發”-》“決策”-》“處理”的循環，在加上一個全過程的“審計”或者“監控”。

其中“觸發”不只是靠日志收集和告警，原因就是前面說的日志源的可用性問題，應是人工觸發和SOC日志觸發相結合。但是“觸發”以后，需要在SOC系統里面快速匯總相關日志，分析事件原因，并形成處理意見提供給“決策”。

“決策”主要是根據SOC系統分析出的事件原因和處理意見進行決策。因為可能需要多部門配合（比如網絡管理部門和系統管理部門配合），因此“決策”實際上是一個協調過程。

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

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

五、誰來使用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外包的管理工具。后者的功能就主要是對安全事件的整個處理過程加以監控了。

六、SOC的實施

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

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

【小結】

總的說來，要想用好SOC，不能把SOC只當成一個和其他安全設備配套形成解決方案的產品來看。相比于配套解決方案，其實SOC其實更適合作為安全咨詢服務的后續工作來做。現在客戶往往分不清安全咨詢服務和風險評估服務的原因，其實就是兩者的輸出太接近了，都是一套類似的解決方案。而有SOC作為基礎，安全咨詢在解決方案之外的很多東西就可以落地了。

【最后】

本文只是筆者自己對SOC大約一年左右的研究所得出的一些觀點，又是偶然受到激發寫出來的，行文比較倉促。總之，一家之言，說得對不對請大家批評指正。

行文的最后發現本文犯了互聯網文章的兩大忌，一太長，二沒有圖，不過也不改了，愿意看完的自會看完，不愿意看完的也就不強求了。

祝大家元旦快樂。

?

總結

以上是生活随笔為你收集整理的再转弯曲评论上的一篇关于SOC的文章的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。