作者|陳峻
策劃|云昭
3月22日，360政企安全對外披露了美國國安局（NSA）針對中國境內目標采用的Quantum網絡攻擊平臺的技術特點，并證明了其無差別化網絡攻擊，不但能夠劫持世界任何角落的頁面流量，而且可以實施零日（0 day）漏洞利用攻擊，并遠程植入后門程序。
隔天24日，網上曝出微軟被黑客組織Lapsus$盜用了的一個賬戶，并獲得了有限訪問權限，并聲稱掌握部分源代碼。
即便是微軟這樣的巨頭，也不可避免的中招了！
對此次入侵，微軟表示，“我們的網絡安全響應團隊迅速參與修復受損帳戶，并防止黑客組織進一步活動?！?/p>
不到三天接料爆料出重大的安全新聞，相信國內各個企業的風控部門都會倒吸一口涼氣。有的已經開始組織安全人員，準備擼起袖子開展自身系統安全的檢查與整改工作。不過，常言道“磨刀不誤砍柴工”。我們與其在現有的生產環境中大海撈針，不如先靜下心來，從系統開發與運營兩個維度出發去思考。我這里結合以往的從業經歷，總結除了五大系統安全實踐參考要點：開發安全、系統梳理、權值分級、風險管理、監控響應。希望能幫助各位快速鎖定安全隱患，防患于未然。
開發安全相信大家對 DevSecOps一詞并不陌生，它由敏捷開發模式演變而來，旨在將安全性盡量“左移”到各個開發子周期的初始階段，以協助研發人員盡早獲悉應用代碼中可能存在的威脅與漏洞。對此，我們可以采用如下四種實踐模式：
未雨綢繆式：分割應用程序之間依賴性，以便隔離各個組件，將來漏洞和威脅限制在單個組件中，進而保證其他組件的持續運行。該模式的典型場景是微服務應用。
一票否定式：通過代碼邏輯和用戶場景的構建，在有惡意行為出現時，中斷其所有進程。例如：如果有用戶在訪問某個網站時，試圖進行跨站腳本注入攻擊，那么其任何操作行為及其會話就應當被直接阻止。
他山之石式：在缺乏安全專家的團隊中，可以通過業界常用的威脅模型與管控模型，來提前識別應用組件可能面臨的潛在風險，并選取最佳防護措施。
川流不息式：利用自動化監控手段和獲取的多種輸入參數，將對于運行環境與用例的風險評估，集成到軟件服務整個生命周期中。
此外，在軟件應用的構建中，我們也需要落實如下方面：
針對不同的應用服務，設置不同的用戶職能組別。
通過加密等方式，避免在應用數據的傳輸過程中，泄漏任何密碼、口令、證書或私鑰信息。
將多種應用程序的登錄方式統一為多因素認證（MFA）+單點登錄（SSO），以實現用戶賬號權限的自動匹配。
使用成熟的產品來管理密鑰，及時發現過期與注銷證書等情況。
檢查程序代碼，及時發現無效或過時的依賴項、代碼庫、潛在的內存泄漏、死循環、以及代碼漏洞。
系統梳理當然，除了提供軟件應用服務，我們也離不開承載著應用的系統架構。隨著企業的發展，其IT架構與平臺會呈現錯綜復雜的結構狀態。因此，我們需要通過鉆機房，登設備，查線路，測應用，跟業務，訪用戶等活動，梳理出日常IT服務所處的環境，以及所用到的資源。
在清點并填寫具體內容之前，我們需要事先做好條目的分類與定義，以保證生成的清單具有統一性和規范性。而在實踐中，我們需要以數據的特征與狀態為依據，去發現那些存儲著靜態數據的有形硬件設備，處理著實時數據的軟件應用，承載著動態數據的網絡，包含著結構化數據的數據庫，存放著非結構化數據的云平臺，以及被用于持續讀寫數據的文件服務器與用戶終端。
為了保證準確性，我們可以采用“自動化工具發現 + 人工錄入 + 二次審核”的方式，構建出全面、完整、直觀的系統基線。這將是我們后期進行整改的參考標準。
權值分級完成了系統的梳理，我們便可以從信息安全的經典理論出發，全面考慮各種組件與數據在其機密性（C）、完整性（I）和可用性（A）受到破壞時，可能給企業帶來的影響程度，并據此賦予三個維度相應的數值。有了賦值，我們便可以基于如下的公式，計算出資產的權重值（V）：
值得注意的是，我們不但可以給軟硬件資產賦值，也可以對數據分配權重值，以進步厘清有哪些數據需要被加密存放，哪些數據在使用需要立即清除，哪些數據僅能在內部被受限制地使用，以及哪些數據可以被直接對外開放。當然，精確的數字往往不便于界定，我們可以通過取值范圍來劃分出：“絕密、機密、隱私、敏感 、公開”等級。
同時，在一些機密性要求極其嚴格的場合，我們甚至需要對某些結構化數據表中的字段，非結構化數據域中的鍵/值（K/V），以及某個介質對應的屬性標簽里的元信息，進行不同安全級別的區分。當然，除了對數據予以邏輯分級，我們也需要以物理標簽的形式，來顯著標識設備部件的密級。
風險管控：運營風險識別及應對一些開發者或許會疑惑：有哪些影響C、I、A的因素呢？此時我們就需要來識別運營環境中針對組件與數據的外部威脅、內部弱點、以及組合到一起形成的風險了。通常，我們可以采取如下四步來識別風險：
1、收集與識別：根據過往的記錄、以及業界經驗，招集不同角色的人員，使用頭腦風暴、問卷訪談、矩陣圖表等方法，識別現有環境中的隱患。例如：
（1）技術層面上：軟、硬件介質的故障與損壞、應用系統的自身缺陷、惡意軟件的死鎖、以及網絡上的各種拒絕服務的攻擊等。
（2）支撐系統層面上 ：機房停電、漏水、以及運營商網絡中斷等。
（3）人為層面上：訪問掛馬的網站、各種操作性的失誤、以及文件數據被誤改或篡改等。
（4）管理層面上：人員意識的缺乏、處置方式的錯誤、以及規章制度的不完善等。
2、分析與評估：運用定性/定量等不同的方法，對已發現的風險從程度、范圍、以及可能性三個維度進行評估與排序，進而得出風險等級矩陣。在實際中，我們可以參考如下的界定標準進行風險的量化：
（2）損害的程度 – 輕微、一般、較大、嚴重、特大等。
（3）影響的范圍 - 整個企業、所有外部客戶、多個分站點、某個部門、部分系統、單個服務等。
（4）發生的可能性 – 可考慮物理與邏輯上所處的區域、自身的容錯能力、等級保護與合規的達標情況等。
3、應對與處置：我們需要根據本企業的風險偏好（即風險接受程度），在通用的風險減輕、轉移、規避、以及接受等處置方法中進行選擇，并予以應對。其中，我們需要對如下兩個方面引起重視：
（1）根據木桶原理，我們應當注意處置措施的一致性，以免出現局部“短板”。
（2）在分清風險的所有者、以及控制實施者的基礎上，兼顧時間、預算等成本，靈活調整各項管控策略。
監控響應：最小化安全事件目前，許多企業都通過建立主動監控和響應機制，來最小化安全事件對于業務運營的負面影響。例如，運營團隊可以設置可靠性工程師（SRE）崗位，在日常預防性例檢中，實時地監控關鍵設備的狀態，及時根據文檔發現并定位部件故障。同時，他們也可以通過部署諸如Zabbix等開源的日志與事件監控工具，以遠程和集中的方式，審查并跟蹤各項性能指標。
下面，我以某個云端業務環境為例，來討論如何在事件監控與響應的整個生命周期中，實施管理和控制。
檢測與識別階段：分別抓取和過濾來自各個虛擬機的系統事件、以及基于網絡的異常流量信息，然后持續將經過篩選的日志信息寫入HBase數據庫，為后期的各種關聯分析、以及必要的取證提供重要依據。
調查與分析階段：運用工具按照特征代碼，對事件的種類予以分組、對事件的發生頻率進行統計。同時，我們可以引入應用性能分析（APM）模塊，精確地定位是在應用服務的哪個URL處出現了訪問速度的驟降，或是用戶在提交哪個SQL語句時出現了延時，以便更快地定位根本問題。
抑制與補救階段：可以通過暫停出問題的虛機鏡像，來隔離它與其他系統及服務之間的邏輯聯系，此舉既不會破壞該虛機上的證據，又能夠阻止事態的惡化。
總的說來，我們可以參考如下流程，來有效應對突發事件。
結語綜上所述，我們從開發安全、系統梳理、權值分級、風險管理、以及監控響應五個方面，討論了可落地的系統安全實踐要點。
面對紛繁復雜的內外部網絡環境，我們應當秉承著“害人之心不可有，防人之心不可無”的樸素概念，積極主動地對本企業的IT系統，持續進行抽絲剝繭式的梳理、檢查與改進。我相信只要各個企業都能及時補齊安全短板，咱們國家的網絡安全整體態勢就會顯著提高。
X 關閉
X 關閉