nginx Firefox java centos apache Windows Ubuntu linux 微软 Python Android google php wordpress 编程 mysql 程序员 云计算 shell 开源

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

2.3 安全系統的開發與運行概述

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

image

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

策略—是安全策略的基本要素,一般不是某種特定的技術,而是一些與網絡運行有關的更加宏觀的因素。
指導方針—組織機構的最佳做法。
標準—是一套針對某項技術或財產的最基本的操作準則。
註意 雖然在本節後面將對策略、指導方針和標準進行詳細的討論,但要註意所有這些文檔的共同語境都是安全策略,總體策略涵蓋的每種文檔都稱為策略,這是很重要的。

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

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

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

1.檢驗安全策略的驅動力。

2.制定安全策略。

3.設計安全系統。

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

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

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

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

業務目標;
成本分析∕效益分析。
業務目標:首先必須了解這一組織機構的目標。在為電子商務零售商設計安全網絡而對該公司的職能進行調研時,你的腦中應該閃現出與要部署的系統相關的內容。例如,由於財務交易的敏感性,所有這些交易信息必須跨越私有網絡的作法或許適合聯邦銀行的網絡系統,但這種做法對於在線零售商而言,在某種程度上就是滅頂之災。很難想像當用戶用瀏覽器瀏覽Amazon.com的在線目錄時,發現自己必須與Amazon建立一條專線線路連接才能購買上面的產品。當然,這是一個極端的例子,但其反例也同樣不大可能—聯邦銀行也不可能利用公共的Internet網絡來處理金融事務。因此,這裏的關鍵在於透徹地了解業務目標,無論網絡在總體業務中充當什麽角色,都要確保那些目標可以得到滿足。

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

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

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

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

安全入侵—攻擊者獲得或篡改了數據;
網絡不可用—攻擊導致網絡所提供的一項或多項服務不可用。
1988年紐約時報網站受到攻擊就是一個安全入侵的例子。攻擊者能夠修改服務器上的數據,而且有可能破壞已歸檔的新聞。讀者可以通過下面的URL,來了解更多有關NYT攻擊的詳細信息:http://www.cnn.com/TECH/computing/9809/13/nyt.hacked/。

從紅色代碼(Code Red)和尼姆達(Nimda)蠕蟲,到分布式拒絕服務(DDoS)攻擊和SYN泛洪攻擊,這些攻擊方式都可以導致網絡不可用。

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

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

一旦了解安全事件的成本之後,還必須考慮到緩解威脅的成本。設計人員要確保不僅考慮到資金方面的成本,而且還要考慮到維護所有安全措施的支持成本。對於安全設備來說尤其如此,其設備成本往往是總擁有成本(Total Cost of Ownership,TCO)的一小部分。

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

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

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

不幸的是,事情並不那麽簡單。您還必須考慮DDoS攻擊對用戶所造成的影響。JamIndustryNews.com(果醬產業新聞)會在頭版刊登文章,對您站點的安全性發出質疑嗎?如果這樣,我們假設10%的客戶投奔了您的主要競爭對手JamIndustryNews.com。那麽你每天就會因此再損失240美元,一年共計損失87600美元。雖然一次持續8小時的DDoS攻擊可能不會導致客戶離你而去的這種情況,但您內部銷售數據庫服務器的受損,以及客戶信用卡數據的泄密卻會導致這種情況。Egghead.com受到類似攻擊就導致了這樣的後果(請參見http://zdnet.com.com/2100-11-527001.html以了解更多細節)。清理成本是另一種“隱性”成本,也應該考慮在內,還有一種需要考慮的成本,即攻擊者利用你被入侵的站點去攻擊其他站點所造成的成本。

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

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

例如,對於傳統的風險分析,攻擊者竊取客戶信息可能會被認為是一種風險,若要降低這種風險,就必須保障客戶數據庫的安全。我們可以將此類分析稱為“自底向上”的風險分析:即從攻擊者的目標開始分析,然後確定必要的對策。

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

在先前保護客戶數據庫的例子中,自頂向下的風險分析方式將最終考慮到與用戶PC相連的調制解調器不安全的可能性。攻擊者利用不安全的調制解調器可以在連接的某些部分做好準備,以便發起arp欺騙攻擊(將在第3章闡釋),以竊取數據庫的認證信息。此後,攻擊者就可以通過“安全的”數據庫的認證,並竊取服務器中的信息。

註意 讀者如需了解有關自頂向下風險分析的詳細信息,可以訪問http://www.cert.org/ archive/pdf/01tn001.pdf並查看計算機緊急應變小組(Computer Emergency Response Team,CERT)標題為“Attack Modeling for Information Security and Survivability”的文檔。

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

http://www.packetstormsecurity.org

http://www.insecure.org

http://www.insecure.org

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

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

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

確保業務需求可以精確地反映出網絡的用途,以及策略中最重要的部分;
參與討論各類威脅出現的頻率,以及組織機構需要支付的花銷;
通過自底向上和自頂向下兩種方式來執行風險分析。
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服務器只能在公司內部進行訪問嗎?好極了!在安全生命周期的依從度檢查階段,可以通過內部掃描、主機審計等技術來檢查策略的落實情況。這些審計技術及執行這些技術的時間安排都是由組織機構決定的。每季度檢查一次往往是比較合理的時間間隔。

對於安全操作團隊來說,第二項任務往往比較有趣,但也會令人無地自容。這與前面詳細討論過的風險分析過程非常相似。安全操作團隊必須盡力確保安全系統是最新版本的,而且已經修補了所有攻擊者能夠利用的最新漏洞。若要達到此要求,安全團隊必須時刻留意攻擊者的動向。即使資源有限,在SecurityFocus.com網站上訂閱vuln-dev和BugTraq也不是什麽難事。進一步說,定期瀏覽Insecure.org和PacketStormSecurity.org,然後估計一下這些網站所列出的攻擊工具會對自己的環境產生怎樣的危害。還需要定期在自己的網絡中運行弱點掃描軟件,如Nessus(http://www.nessus.org)。

警告 在當前網絡中運行攻擊工具(即使是那些想必沒有負面影響的工具)時要非常謹慎。倘若使用不當,即使是端口掃描之類的簡單工具也可以導致意外的後果。在運行中的網絡上進行“檢驗”之前要在實驗室中進行全面的測試。此外,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所示,安全運行階段的變化會對安全系統及其下層的策略構成影響,而且往往會同時對它們構成影響。一般來說,在立刻對系統作出修改的同時也對策略進行修改往往對新的安全環境更為有利。作為安全系統設計人員,切忌只對系統進行修改而不修改安全策略,否則安全系統就會日漸背離你制定的安全策略。

延伸阅读

    评论