《網絡安全體系結構》一2.3 安全系統的開發與運作概述

本節書摘來自異步社群《網絡安全體系結構》一書中的第2章，第2.3節，作者【美】sean convery，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視

網絡安全體系結構

現在你已經對安全政策的概念，以及實施這些規則的方式有了基本的了解，在這一節中，我們會把這些知識放到安全系統的開發與運作的環境進行讨論。首先，我們可以看到對這個過程的概括。圖2-1所示的是此過程及其各步驟之間互相關系的概述。

業務需求和風險分析是安全政策的主要來源。全部安全政策都是由三類不同的文檔構成的。

政策—是安全政策的基本要素，一般不是某種特定的技術，而是一些與網絡運作有關的更加宏觀的因素。

指導方針—組織機構的最佳做法。

标準—是一套針對某項技術或财産的最基本的操作準則。

注意 雖然在本節後面将對政策、指導方針和标準進行詳細的讨論，但要注意所有這些文檔的共同語境都是安全政策，總體政策涵蓋的每種文檔都稱為政策，這是很重要的。

總體安全政策要與業内的最佳做法相結合，以建立實際的安全系統。然後，将這個安全系統滲透到安全運作的過程中，這個過程應由意外事件響應、系統監控、系統維護和依從度檢查構成。最後，再将安全運作回報到安全系統和最初的政策中，這樣就形成了一個生命周期，它可以確定安全政策和安全系統不斷進行更新。

本章其餘的部分将對上述示意圖進行詳細的闡釋。首先将讨論安全政策的主要驅動因素。其次讨論如何指定出一個不僅考慮到核心驅動力，而且還考慮到技術基礎的安全政策。然後讨論如何将安全政策轉化成有效、安全的網絡設計方案。最後讨論如何通過安全系統的有效運作來改進安全政策和安全系統。

2.3.1 安全系統的開發

讓我們從一個組織機構如何按部就班地指定安全系統開始說起。這個過程包括3個主要步驟。

1．檢驗安全政策的驅動力。

2．制定安全政策。

3．設計安全系統。

下面幾節将概述上述步驟，重點放在此過程中每一點所需作出的主要決定上。

1．第1步：檢驗安全政策的驅動力

首先檢驗安全政策的兩大驅動力：業務需求和風險分析。在制定任何安全政策之前，必須對業務需求和風險進行分析，這樣才能確定制定出來的政策足以滿足組織機構的需要。沒有堅實的驅動力作為基礎，安全政策所解決的問題有可能壓根就不存在，甚至，以此制定出來的政策還有可能會對組織機構的日常功能産生損害。

下一節将重點從使政策可以完全滿足組織機構需要的角度對這兩大驅動力進行讨論。

業務需求

如圖2-1所示，業務需求是組織機構安全政策開發過程中兩大驅動力之一。第1章有一節的标題為“必須首先考慮業務的優先級”，在那一節中，我們已經對這一問題進行了概述。業務需求對安全政策的影響可分為兩個主要類别：

業務目标；

成本分析∕效益分析。

業務目标：首先必須了解這一組織機構的目标。在為電子商務零售商設計安全網絡而對該公司的職能進行調研時，你的腦中應該閃現出與要部署的系統相關的内容。例如，由于财務交易的敏感性，所有這些交易資訊必須跨越私有網絡的作法或許适合聯邦銀行的網絡系統，但這種做法對于線上零售商而言，在某種程度上就是滅頂之災。很難想像當使用者用浏覽器浏覽amazon.com的線上目錄時，發現自己必須與amazon建立一條專線線路連接配接才能購買上面的産品。當然，這是一個極端的例子，但其反例也同樣不大可能—聯邦銀行也不可能利用公共的internet網絡來處理金融事務。是以，這裡的關鍵在于透徹地了解業務目标，無論網絡在總體業務中充當什麼角色，都要確定那些目标可以得到滿足。

了解業務需求還可以發現安全政策的核心組成部分，以及那些可有可無的組成部分。例如，一家需要想要確定其果醬炸面圈能夠準時送達的炸面圈小店很可能不需要制定加密政策或遠端通路政策。但是，我們在前文中提到的聯邦銀行則必須考慮這些政策及其他政策。通過将業務需求轉化成政策方針，組織機構可以了解到它們的安全政策必須在多大程度上為其網絡提供保護。如果政策與網絡的業務需求很接近，那麼所采用的途徑就是正确的。

提示 如果您與安全政策開發團隊的其他人員在開展上述工作時遇到了困難，不妨先将資訊資産劃分為3類：低價值、中等價值和高價值。低價值目标是指一旦網絡遭到入侵或無法提供服務時，幾乎不會對組織機構産生任何負面影響的那一部分資産。對于中等價值資産和高價值資産，也可以采取相同的方式将它們分别替換為中等負面影響和嚴重負面影響。

作為一名安全系統設計人員，你在了解業務需求時主要扮演一個資訊接收者的作用。安全系統設計人員必須對目标擁有有足夠的了解，才能指定出可靠的安全決策。這應該不止是進階管理層的備忘錄。安全系統設計人員必須真正了解組織機構的目标，以作出有效的安全選擇。

成本/效益分析：安全系統設計人員必須了解與安全事件相關的成本。第3章将會對各類安全事件進行詳細的讨論。就本章的内容而言，可以将安全意外事件分為兩個主要類别：

安全入侵—攻擊者獲得或篡改了資料；

網絡不可用—攻擊導緻網絡所提供的一項或多項服務不可用。

從紅色代碼（code red）和尼姆達（nimda）蠕蟲，到分布式拒絕服務（ddos）攻擊和syn泛洪攻擊，這些攻擊方式都可以導緻網絡不可用。

鑒于本書全部内容都是圍繞确定和評估安全事件的成本展開的，是以本節的篇幅不必過長。在開始評估成本之前甚至有必要對資訊資産，及其可能将要受到的威脅進行了解。本章的下一主題—風險分析—就于此密切相關。設計者必須從全局的高度決定如何衡量成本。定量法依賴于盡可能精确地回答成本問題。定量法對于成本核算是有幫助的，但是這種方法需要進行太多書面工作，而所提供的價值與付出的努力相比卻很小，尤其是對規模非常大的組織機構而言。

另一方法則要主觀得多。該方法依賴于組織機構内的專家提供的資訊。請專家們傾其所能就特定安全事件對運作的影響進行評估。此方法的缺點在于，與定量研究相比，精确度有可能低很多，但其優點是相對直覺。要記住，評估意外事件的成本不但必須考慮基本成本，而且還必須考慮這個意外事件發生的幾率。無論選用哪種方法，成本∕效益分析都應該是一個協作的過程，以確定價值準确，也可以了解到自己面臨的威脅。

一旦了解安全事件的成本之後，還必須考慮到緩解威脅的成本。設計人員要確定不僅考慮到資金方面的成本，而且還要考慮到維護所有安全措施的支援成本。對于安全裝置來說尤其如此，其裝置成本往往是總擁有成本（total cost of ownership，tco）的一小部分。

在得出事件成本和處理成本之後就可以進行真正的成本∕效益分析了，這種分析的作用是搞清楚資源應該如何進行合理的配置設定。

提示 仔細研究上述低、中等和高價值資産的定義可以幫助讀者迅速取得工作進展。若要對資産進行有效的評估，必須在資産價值之外再建立一個與其相關的屬性：相關風險。我們可以将相關風險分為低風險、中等風險和高風險。低風險意味着由于其性質（其位置、及其所采取的安全措施）或其對于攻擊者的價值，系統受到成功攻擊的可能性很低或不存在。對中等風險資産和高風險資産的成功損害的可能性相應較高。影響系統風險級别還有一個原因，即儲存有這些資産的系統被曝光出安全漏洞與弱點的相關幾率。

例如，假設您正在營運jelliesoftheworld.com，這是一個著名的電子商務站點，它的目的是讓世界各地的不同美食愛好者都能買到果醬。您每天果醬的平均銷售額為2400美元，或大約每小時銷售價值100美元的果醬。根據您的判斷，ddos攻擊每年會使自己站點的可用性受到一次損害，而每次這樣的攻擊平均會持續8個小時。在不考慮大局的情況下情況下，您可能會得出這樣的結論：如果每年自己為了防止ddos攻擊所支出的費用多于800美元，那就會帶來經濟損失，讓自己得不償失。

成本∕效益分析也可以用來判斷一家組織機構是否有必要部署一項新的技術，這種方法可以權衡安全風險與新技術可以帶來的回報，進而得出相應的結論。對無線lan（wireless lan，wlan）和ip電話通訊之類的新興技術就有必要進行這種評估，因為人們之是以會推動這些新技術就是看中了它們有可能會提高生産力。第11章将從技術層面會對這一概念進行詳細的讨論。

風險分析

傳統的風險分析是指一種對組織機構的潛在風險進行評估以證明對策合理性的分析方式。對于本書而言，我們将傳統風險分析定義為成本∕效益分析，如上節所述。這種傳統的風險分析在安全政策的開發過程中是必要的組成部分，因為這種分析将重點放在一些特定的方面。不幸的是，傳統的風險分析往往會忽略許多類型的威脅，因為這種分析方式的重點在于攻擊的結果或目标。

例如，對于傳統的風險分析，攻擊者竊取客戶資訊可能會被認為是一種風險，若要降低這種風險，就必須保障客戶資料庫的安全。我們可以将此類分析稱為“自底向上”的風險分析：即從攻擊者的目标開始分析，然後确定必要的對策。

對于安全系統設計人員，以“自頂向下”的方式進行風險分析往往更有意思。這種風險分析始于“我最薄弱的部分在哪兒？”這類自問自答，這會引出“攻擊者如何才能發現我的弱點，并利用這些弱點來達到目的呢？”之類的問題。在安全系統就緒之前或之後均可進行這類的風險分析。

在先前保護客戶資料庫的例子中，自頂向下的風險分析方式将最終考慮到與使用者pc相連的數據機不安全的可能性。攻擊者利用不安全的數據機可以在連接配接的某些部分做好準備，以便發起arp欺騙攻擊（将在第3章闡釋），以竊取資料庫的認證資訊。此後，攻擊者就可以通過“安全的”資料庫的認證，并竊取伺服器中的資訊。

還有一種方法可以找到網絡的弱點，那就是觀察最近的攻擊工具是如何對網絡構成影響的。在一開始，先不要考慮攻擊者的目标，隻需檢視這些工具在網絡不同部分運作時能夠發揮什麼作用。這種方式往往可以發現一些平時為你所忽略的東西，使得自頂向下的分析得以應用到實踐當中而不是停留在理論層面。下列網站可以找到一些攻擊者們可以搞到手的工具：

<a href="http://www.packetstormsecurity.org">http://www.packetstormsecurity.org</a>

<a href="http://www.insecure.org">http://www.insecure.org</a>

提示 公正的視角往往能夠揭示出安全系統中需要加以注意的問題。是以，在可以負擔這種費用的情況下，不妨對網絡進行進行外部審計。

為了讓安全政策發揮作用，這兩種風險分析都是必要的。如果沒有自底向上的分析，那麼你制定的安全政策就很難防範最新的攻擊工具和攻擊手段。同樣，如果沒有自頂向下的分析方式，那麼你在制定政策時難免就會“一葉障目”，因為通過這種方式制定出來的政策隻會對資訊資産提供保護，而忽略掉安全系統遭受攻擊的這種可能性。在檢驗自頂向下風險分析結果時，不妨執行自底向上的風險分析（如前面“成本∕效益分析”一節所述），這可以在某種程度上暗示你哪些資訊是令攻擊者垂涎的關鍵資料。

取得成功的步驟

安全系統設計人員在評估組織機構業務需求、分析與網絡相關的風險過程中扮演着至關重要的角色。由于業務需求與風險分析息息相關，它們共同決定了安全政策的優先級，是以設計人員對安全政策的選取必須握有發言權。在此階段，有若幹事項可以使設計人員在實際的系統設計中更為輕松：

確定業務需求可以精确地反映出網絡的用途，以及政策中最重要的部分；

參與讨論各類威脅出現的頻率，以及組織機構需要支付的花銷；

通過自底向上和自頂向下兩種方式來執行風險分析。

2．第2步：開發安全政策

既然組織機構已經了解了業務需求，也進行了風險分析，下一步就該制定實際的安全政策了。這一步既是最關鍵的，也是最易于出錯的。說這一步是最重要的，是因為政策制定不當猶如手握一份不靠譜的地圖：雖然最終也有可能會達到目的地，但走彎路在所難免。說這一步是最易于出錯的，是因為安全政策的制定恰如登山，是一項艱苦卓絕的工作，每當業務需求和網絡風險發生變化時，這項工作就要經年累月地不斷重複。是以，設計者應該将政策視為一系列的任務，其中每項任務都有确定的起點與終點。

成功制定安全政策最容易的方法是将制定出300頁材料那一類的想法抛在腦後。對于安全政策，數量總會越來越多。制定一系列比較小的文檔可以使得安全政策更為靈活，而且在遇到業務需求和大範圍技術變化時也更友善進行修改。在下一節中，我們将重點讨論一些不容回避的重要安全政策。

關鍵安全政策

應該考慮對其制定安全政策的關鍵領域包括：

用于限定可接受使用的政策；

用于限制與遠端網絡連接配接的政策；

用于概述組織機構所擁有的各種資訊敏感級别的政策；

用于保護網絡使用者隐私和所有客戶資料的政策；

用于限定在與網絡相連之前各裝置必須達到的安全基準的政策。

本節将對這些政策類型進行詳細的闡述。

設計師必須要判斷出哪些關鍵政策可以幫助自己有效地開展工作。首先，要制定可接受的使用政策（acceptable use policy，aup）。這種政策的作用是限定使用者通路網絡的規則。這應該不僅包括内部和外部網絡通路的指導方針，而且還要包括允許傳輸的流量。附錄c中有關于這類政策及其他政策的例子。

其次，制定用于限制與遠端網絡連接配接的政策（無論是公共網絡還是私有網絡）。某些組織機構将它們分為若幹不同的政策。這些政策應該包括與自己網絡相連的那些遠端從業人員、合作夥伴和客戶的安全通信要求（如信任程度、機密性和認證等方面的考量因素），以及控制它們通路internet的方式。

第三，制定處理自己網絡内各類資料的大體方式。組織機構内的資訊具有不同級别的敏感度；比如，與企業行将與其他公司合并的資訊相比，公司排球隊日程表的敏感度就要低得多。這個政策旨在闡明哪種敏感度級别的通信必須進行加密或認證，以及可以采取哪些加密方法。除了企業使用者的流量之外，此政策還與安全設計之間有直接的關系，因為這項政策還應該說清在管理自己網絡的指令和控制信道時，都有哪些安全要求。

第四，了解組織機構對其使用者和客戶的私密性政策。這項政策的目的是定義保護客戶資料的需求（比如如何保護一個電子商務站點，或者如何保護一家醫院的資訊）。此外，某些公司的政策規定，所有網絡資源的使用都要受監控。不過，一所大學制定這個政策的可能性就不太大。作為設計人員，必須了解自己組織機構的政策，這樣才能保證網絡中所部署的安全架構是符合自己的機構政策的。還有一種方式可以進一步強化網絡的安全性，那就是一旦有人違反了公司公布的安全政策，就要讓其為此承擔責任。

最後，要搞清楚哪些措施可以保護網絡中不同部分的安全。換句話說，必須在将伺服器、路由器、交換機和終端系統連接配接到網絡之前，對它們有所了解。

為了協助組織機構制定上述各種政策，可以根據文檔的資訊類型，以不同的方式對文檔進行分類。如本書所述，安全政策屬于下列3種類型的文檔之一。

政策—政策是整個安全政策的基本要素，一般不是某種特定的技術，而是一些與網絡運作有關的更加宏觀的因素。政策的作用是定義整個安全政策符合标準的最低要求。政策的例子包括aup或遠端通路政策。

标準—标準用于規定一套針對某種技術或某項财産的最基本的操作準則。其他政策或指導方針往往會參考标準定義的準則。如果在不同的文檔中都有某一套推薦标準，比較好的做法是通過直接引用這個标準來對它們進行描述，比如路由器強化标準、密碼标準，或針對unix伺服器與網絡相連之前的安全設定方法。根據很多大型組織機構所采用的标準，主機軟體鏡像可以在許多情況下自動與終端系統标準保持一緻。

指導方針—指導方針用于規定組織機構的最佳做法。指導方針用于概述你真正更願意讓自己的組織機構沿用，但并不嚴格要求采用的方法。指導方針中比較适合描述那些由于時間不足和任務量太大，導緻有些規則無法應用的情形。指導方針的例子包括非武裝區伺服器的放置，或聯網的裝置中推薦使用的安全特性。

不要太在意這些文檔的名稱；涵蓋整個政策所有必要的方面才是最重要的。比如說，指導方針不一定要單獨起草文檔，有時可以将指導方針融入到政策或标準之中。例如，你可能在路由器強化文檔中規定了一些最低要求，同時也在這個文檔中說明了在人們有能力的情況下，推薦他們采取什麼行動。在這種情況下，這些推薦的做法就成了路由器強化标準中的指導方針。

附錄c中包含了某個公司安全政策中的3個示例文檔：一個可接受的使用政策、一個密碼政策和一個防病毒政策。從這些文檔中可以體會到這種文檔語言和内容的風格。切記要讓文檔盡可能簡單明了，這樣才能友善日後進行了解和修訂。

安全政策團隊

如前所述，網絡或安全團隊不應該在安全政策的開發過程中孤軍奮戰。sage目錄《a guide to developing computing policy documents》（由barbara l. diiker編輯）建議包括下列主要成員：

一位資深的管理者；

一位能夠實施政策的管理團隊成員；

一位法務部門的成員；

一位使用者團體代表；

一位文字功底優秀的員工。

在制定安全政策時，我會對上述清單進行一點細微的改動：将“資源管理者”分為兩個崗位：一位網絡操作人員和一位安全操作人員。如果指定政策這項工作還與另一個組織機構有關，那麼也應該吸收一位來自該方的代表。我還建議吸收多名使用者團體代表，此外，除了法務人員，還要吸收人力資源部門的代表。在政策制定完畢後，必須由管理層準許，因為管理層是負責實作和推行這些政策的。

安全與通路

是否還記得電影侏羅紀公園 中ian malcolm說“生命自會找到出路”時的字幕？他指的是即使通過基因技術把恐龍全都變成雌性，它們還是會進行繁殖。在設計安全政策時，設計人員不妨以同樣的方式看待使用者團體：“使用者自會找到出路”。這主要是指如果限制過于嚴格或保護得過于嚴密，使用者團體都會找到繞過這些政策的方法。

下面一個例子值得深思：我最近為阿姆斯特丹的一家公司做了一次安全設計的評估。這家公司的管理層堅信internet的風險太大，是以決定禁止所有人通路internet。這項政策讓我感到震驚，因為這件事發生在2002年，而不是常常應用這類政策的20世紀90年代。稍作詢問之後，我發現他們所有的資訊技術（it）人員都在使用安全性欠佳的模拟線路進行“測試”。實際上，這是有特權的人（it人員）繞過internet通路限制政策，在網上沖浪的方法。請仔細想想這對這個網絡的安全性意味着什麼。假設這家公司為了減少網絡帶來的威脅，提升公司的安全性，而禁止整個公司通路internet。那麼這家公司的确可以是以避免大多數蠕蟲、電子郵件特洛伊木馬（trojan horse）等帶來的危害。先别忙着高興，我們再來研究一下這些采用點到點協定（point-to-point protocol，ppp）與internet服務提供商（isp）建立的it模拟連接配接。由于這些連接配接是在沒有任何安全措施的情況下直接與internet相連的，而it人員又很可能同時與internet及其内部網絡建立連接配接，是以這些it使用者就有可能因為自己暴露在了全新的“後門（back door）”攻擊之下，而導緻整個安全系統遭到破壞。雖然每個組織機構所遇到的威脅各不相同，但是在這種情況下，與建立一條受到足夠保護的internet連接配接讓普通員工使用相比，我敢說這家公司的實際安全效果更差。

這種比較對于新型的技術同樣适用：由于wlan風險性比較高，就禁止大家使用wlan通路網絡，這樣隻會降低網絡的安全性，因為總有些使用者會在不進行任何安全防護的情況下私下部署wlan。與一概封殺wlan通路相比，通過安全最佳做法讓企業的wlan置于it部門的管理之下顯然更加安全（wlan安全将在第11章中進行論述）。記住，使用者自會找到出路。

最終評估

作為安全系統設計人員，必須要保證這些通過需求制定出來的安全政策既全面而又可行，尤其要注意這些政策中依賴網絡自動實施的那些部分。一定要能夠讓這些要求得到滿足，在無法滿足的情況下，要考慮對政策進行修改，讓它們變得更為實際。還要盡可能確定所有的政策都不會涉及到具體的技術。這樣，當網絡引入了不同的功能之後，實施這些政策的技術也可以随之修改。最後，政策越簡短（在合理範圍内），其推行、實作和修改也就越容易。

3．第3步：設計安全系統

在網絡投入運作之前，按政策文檔設計安全系統是最後一步。如果政策是明确的，那麼安全系統的設計就應該非常直覺。如本章前文所述，這一章我們隻對整個流程進行概述。在第12章中，我們還會将對其進行更加詳細的闡述。

為了說清楚如何将政策轉換為實施，我們以路由器強化标準為例。在本質上，這項工作其實就是在全網的所有路由器上配置專門的指令。但是，一旦我們的标準出現變化，它所帶來的各種衍生變化就會讓配置工作變得非常複雜。比如，有些标準中也許就沒有對下列問題提供回答。

在部署了備援的設計環境中，這些标準有什麼需要注意的嗎？

在高負荷環境中，這些标準對性能有何影響？需要是以更新裝置嗎？

除了标準規定的内容之外，對于連接配接到internet的路由器，我們還需要執行其他設定嗎？

即使是最精心設計的安全系統恐怕都無力回答這些問題。設計師有一種常見的誤區，他們往往覺得安全系統中唯一可以添加進去的東西就是政策。安全政策的确很關鍵，但你也不應該成為安全政策的奴隸。還有一種有必要添加到安全系統中的東西，它就是“最佳做法”。

最佳做法是internet集體智慧的結晶，利用這些最佳做法就能保證安全政策得到了最有效的利用。忽略最佳做法，你就隻得自己重新積累這些智慧，而且在積累過程中多番遭遇挫折。最簡單的例子是：你能隻用詳細的藍圖建成一座房子嗎？你可以盡力去嘗試，但恐怕不會特别成功。藍圖中并沒有指定在地基上建造第一層樓的最佳方法，隻是說明了必須完成的工作。同樣，安全政策所注重的往往是需求，而不是手段。

在很多地方都能找到推薦的最佳做法：

書籍；

新聞討論區；

同侪/同僚；

rfc；

網站（sysadmin、audit、network、security institute [sans]、cert、north american network operators’ group [nanog]）。

如需對自己的環境應用最佳做法，隻需遵循這些步驟。

第1步：本書中應該涵蓋了如何将你的政策轉換為安全系統的所有知識，這些知識言之有物而又上手簡單。如果這裡描述的最佳做法的确可行，而且還不與你的政策或組織機構使用網絡的方式相違背，那就請按照這種做法來實施。否則，跳到第2步。

第2步：如果本書所描述的最佳做法在你的網絡中并不可行，那就請在網絡或其他書籍中查找更多有關這方面的知識。找到另一個更具實際意義的推薦标準了嗎？如果找到了，那就采用該推薦标準。否則，執行第3步。

第3步：判斷出最佳做法的哪一部分與你的政策相沖突。把這個問題帶回政策設計團隊中進行讨論。找到不能實施這一最佳做法的原因。

第4步：為自己的組織機構量身定制一份最佳做法。一定要弄清楚它所涉及的方方面面（這是最佳實踐如此命名的原因之一）。

在安全政策中，通常無法直接找到有關最佳做法的資訊的主要原因是，最佳做法會導緻政策中包含了太多具體的技術。硬體和軟體的所有版本都會對安全政策的實作方式産生輕微的影響，進而引起某些最佳做法發生變化。每當發生這種情況時都要對政策進行修改可不是好的設計方案。能達到這種詳細程度的文檔一般是标準或指導方針文檔。即使這樣，這些文檔也往往不會含有所有具體的技術。

比如說，如果在政策中規定wlan通路應該處于有線等效保密（wired equivalent privacy，wep）的保護之下，那麼你會讓人感到有些可笑，因為wep已被證明不安全。正确的做法是，在政策中規定要通過機密性、完整性和認證措施對wlan通路進行保護，并向讀者提出你可以接受的加密标準。于是，在閱讀政策的要求之後，這個讀者就可以根據可接受的加密标準，并且重新審視那些其一貫認為在你的網絡中可以安全使用的協定。此後，如果某個加密方案出現問題，那就隻需更改一個可接受的加密标準，所有引用該标準的文檔也就會随之得到更新。

2.3.2 安全系統運作的生命周期

安全系統的運作是指網絡中發生安全事件時，安全系統對其進行複查、适應和響應的過程。安全事件的範圍很廣，從由于3次鍵入密碼有誤導緻賬戶被封，到工資管理系統遭到入侵，所有類似的事件都可以稱為安全事件。安全運作主要有3個方面，如圖2-1所示。

系統監控與維護；

依從度檢查；

意外事件響應。

本節将對這些主題進行概述，并闡釋安全運作對安全政策或安全系統本身的作用。有關安全運作最佳做法的讨論超出了本書的範圍。修改政策的目的是為了解決所有在整個系統中發現的缺陷，修改政策有助于解決系統未來有可能遇到的問題。根據圖2-1，還可以看到在某些情況下，安全生命周期這個階段（及安全系統運作階段）的結果可以直接回報到安全系統中，比如，若政策無誤，但實施不當，就會産生這種回報。

1．系統監控與維護

很多網絡連接配接并不需要進行太多的監控，或者隻需在特殊情況下進行監控。但大多數以安全為目的而部署的系統往往需要時常關照一下。雖然在小型網絡的内部不對路由選擇表進行監控這種做法完全合理，但隻将ids打開就期待它産生奇迹般的效果恐怕就不太可能—除非你所謂的奇迹就是為資料中心添加了一個價值30000美元的發熱元件。

在安全系統中，應該将一些登入技術、自動分析技術和人類智能技術結合起來使用，以處理大多安全事件，這一點是至關重要的。但這種處理機制會引起安全系統或基本政策的變化。試想：你是一位大型高校網絡的安全管理人員。在幾周的時間内，你發現招生辦公室中财務伺服器的登入失敗的次數大幅增多。在進一步調查之後，你發現登入失敗來自網絡其他部分的兩台受到了入侵的系統。最終你發現它們遭到入侵的原因在于，運作在其中的域名系統（dns）軟體berkeley internet name domain（bind）版本過期了。由于這個事件，你現在可能要執行幾項任務。

重建這個遭到了入侵的系統，根據自己為系統設定的維護政策來重新教育訓練相關操作人員。

追溯最初被入侵系統所受攻擊的來源。

對财務伺服器進行審計，以確定其沒有受到未經授權的更改。

要考慮修改與通路财務伺服器有關的安全政策，讓網上的任何人都可以嘗試登入這台伺服器的決策有失明智。

在上述例子中，讀者不難看出對于一些有問題的安全政策進行修改的時機，即有些修改工作往往是系統監控工作的最後一步。

注意 科技的進步日新月異。目前，很多系統聲稱自己可以将安全事件資料關聯到另一個系統，并向操作人員就如何修改安全系統提供建議。如果這類系統的自動化程度和精确度能夠得到提升，那麼組織機構就可以考慮置入這些系統，因為它們可以削減對系統監控這項工作的投入，前提是組織機構在部署了這個系統後需要監控的資料類型不會發生變化。實際上，許多組織機構将來都會利用這類系統來擴充自己能夠分析的資訊範圍，進而提高安全性，同時減少人力資源的投入。不過無論何時，各組織機構都要確定自己配備了充足的人手，這樣不僅是為了確定安全事件資料能夠得到檢控，同時也是為了保證有人會對它們作出響應。如果你認為對這些資料進行過濾鮮有樂趣可言，那并不是你的問題。整個行業都面臨着這個問題。第16章将進一步探讨這個主題。

系統維護是指確定系統能夠可以随時修複最新安全漏洞的過程。可以說，與系統監控相比，系統維護的實作工作更加容易。系統維護的主要步驟如下。

第1步：确定有必要進行哪些修複，以及進行修複的頻率。

第2步：在将其應用到目前系統之前對修複進行測試。

第3步：實施對目前系統進行的修複。

2．依從度檢查

依從度檢查往往是安全運作生命周期中最為有趣和最為實用的工作。主要原因在于，依從度檢查可以讓政策、标準和指導方針接受真正現實世界中的殘酷考驗。執行依從度檢查是為了確定下列兩件事情：

安全系統可以有效地滿足安全政策的要求；

安全政策足以排除環境中出現的威脅。

這是兩項獨立但互相關聯的任務。第一項任務很簡單。在本章前面“實施安全政策的考慮事項”一節中已經從安全政策的角度對這一點進行過讨論。在這裡，除了執行檢查的是技術而不是人員之外，其他的過程和方法基本相同。你制定的政策是規定所有内部web伺服器隻能在公司内部進行通路嗎？好極了！在安全生命周期的依從度檢查階段，可以通過内部掃描、主機審計等技術來檢查政策的落實情況。這些審計技術及執行這些技術的時間安排都是由組織機構決定的。每季度檢查一次往往是比較合理的時間間隔。

警告 在目前網絡中運作攻擊工具（即使是那些想必沒有負面影響的工具）時要非常謹慎。倘若使用不當，即使是端口掃描之類的簡單工具也可以導緻意外的後果。在運作中的網絡上進行“檢驗”之前要在實驗室中進行全面的測試。此外，aup必須始終規定員工們不得在網絡上使用任何攻擊工具—永遠禁止使用。

除了公司所采取的内部行動，定期請外部機構對自己環境的安全性進行評估也是非常有益的。一定要選擇那些能夠提供實際資料的機構，而不是那些“用紙宰人”的公司。外部評估的知情人越少越好。實際上，由網絡部門之外的人所安排的評估最為有效。這樣，包括本書讀者在内的任何人都不會知道攻擊是真實的還是模拟的。

無論内部檢查還是外部檢查的目的都是為了找到安全政策的漏洞，也就是找到那些你認為已經可以高枕無憂，但安全政策的漏洞卻仍讓虎視眈眈者有機可乘的地方。如果你的安全政策是在針對邊界網關協定（border gateway protocol，bgp）的新型工具開發出來之前制定的。那麼既然市面上出現了這種新型工具，你就必須重新考慮bgp部署方案及其所有的相關事宜。是以，你就要修改安全政策所涉及的路由選擇安全标準文檔，要求不但要對每條bgp消息進行md5認證，而且還要對入站和出站路由選擇分布清單進行md5認證。第6章中有更多關于路由選擇安全方面的知識。

3．意外事件響應

安全運作生命周期的意外事件響應是一種大家都想盡可能避免的措施。雖然誰也無法保證自己的系統100%安全，但必須對意外事件作出響應常常意味着政策、安全系統、運作團隊或基本的設想出了問題。實際上，安全意外事件可能發生得相當頻繁，是以準備好可靠的方法來應對這些事件是很重要的。雖然下面所列的因素遠不夠全面，但讀者可以從下列因素中可以了解到一些能夠導緻出現意外事件的狀況。

安全系統未能抵禦某種攻擊，于是發生了這種攻擊。

在業務需求中未能指出需要保護的關鍵系統，于是該系統受損。

新型攻擊（往往稱為零日攻擊）命中了你的組織機構，而目前的安全系統未能阻止。

所指定的使用者信任度有誤，是以某個内部人員在未對其設防的情況下發起了攻擊。

一台符合強化标準的主機遭到了外部組織機構的入侵。

如何執行意外事件響應不在本書的範圍之内。司法訴訟往往涉及采證，是以要看這家機構是否有決心為了獲得證據發起訴訟而停止系統營運，是以組織機構必須對整個問題有一個全盤的考慮。本章基本上将重點放在對意外事件作出響應所産生的結果對于整個網絡的影響。

來看一個例子：1999年，很少有人考慮到網站會受到大規模拒絕服務（dos）攻擊。當時盛行的觀點是，隻要自己的帶寬高于攻擊者就不會出現太大問題。2000年2月，由于大規模ddos攻擊，這一觀點随着使用者無法通路amazon、ebay、yahoo！和其他公司而得到了改變。此次攻擊不但對于所有受到泛洪攻擊的組織機構是一次意外事件，對于發起泛洪攻擊的傀儡系統同樣也是一次意外事件。各組織機構不得不提出對策，以應對ddos攻擊，并将其整合到自己現有的安全系統中。

提示 安全技術人員隻要時常更新自己的收件箱清單并且經常檢視安全技術網站，就可以了解我所說的“免費意外事件”。免費的意思是這些意外事件并沒有降臨到你的頭上，但你可以像真的發生了意外事件那樣從這些資訊中受益。就像我們在前面介紹的那樣，由于看到那些遭受了攻擊的公司所發生的事情，所有業務與網絡息息相關的公司對dos的态度全都發生了變化。

如第1章所述，安全系統的優劣在于其應對未知攻擊的能力。也就是說，無論安全性有多高，在職業生涯中的某個時刻（通常會遇到數次），你還是不得不面對一些意外事件。作為安全系統設計人員，訣竅就是了解意外事件會帶來哪些負面影響，以及如何有針對性地修改自己的設計，以在将來更好地處理這類事件。

如圖2-1所示，安全運作階段的變化會對安全系統及其下層的政策構成影響，而且往往會同時對它們構成影響。一般來說，在立刻對系統作出修改的同時也對政策進行修改往往對新的安全環境更為有利。作為安全系統設計人員，切忌隻對系統進行修改而不修改安全政策，否則安全系統就會日漸背離你制定的安全政策。