安全性

世紀大爭論：透過隱匿來實現安全

Jesper M. Johansson and Roger Grimes

簡介:

• 定義透過隱匿來實現安全
• 評估透過隱匿來實現安全的措施
• 評量重新命名系統管理員帳戶的價值
• 訂定明智的風險管理決策

「透過隱匿來實現安全」一詞常受到安全性人員 (特別是那些喜歡自稱專家的人) 的譏諷。那些譏諷幾乎與某些圈子所用的四個字母的字沒什麼兩樣，

根據 Wikipedia (en.wikipedia.org/wiki/Security_through_obscurity) 的描述，「透過隱匿來實現安全」所表現的，正是安全性真正引起爭論的一面。您常常會看到有些人的努力，因為被戲稱為「只不過是透過隱匿來實現安全」而遭到漠視。

簡而言之，透過隱匿來實現安全違反了科克霍夫法則 (Kerckhoffs' Principle)，這項法則認為系統應該是因為它本身的設計而受到保護，而不是因為攻擊者不知道它的設計而得到保護。科克霍夫法則的基本前提是，保密的時間根本維持不了多久。

其中一個非常貼切的例子就是 Windows NT® LAN Manager (NTLM) 驗證通訊協定，它最初是被視為設計秘密。為了針對 UNIX 作業系統實作 Samba 交互操作性產品，Samba 小組不得不對通訊協定進行反向工程。此舉不但產生出最完備的 NTLM 說明文件 (monyo.com/technical/samba/translation/ntlm.en.html)，同時也發現了許多問題。由於密碼編譯引發了這麼多的安全性考量，加上揭露了這麼多秘密設計，因此許多從事安全性的人深信，所有的資訊安全性都應該遵守科克霍夫法則。

但是透過隱匿來實現安全真的只是有害無益嗎？本文將解釋何謂透過隱匿來實現安全，嘗試點出為什麼許多人都認為它是浪費時間 (而其他人則不以為然) 的作法，並且向您說明為什麼答案總是比當初看起來的複雜得多。

透過隱匿來實現安全的簡介

Steve Riley 提出的「不要變更預設值」論點

對於重新命名的問題，我是站在「不要變更」這邊。因為這根本不是安全性的問題 — 而是系統管理的問題。我越是花時間思考系統管理空間 (因為管理和安全性已渾然一體)，越是贊同不做一些有可能增加系統脆弱度的作法。而變更預設值，肯定會增加脆弱度。人們變更預設設定的理由有二 (喔，好啦，有三)。

• 對於變更所提供的功能有所需求。
• 假定變更會提高安全性。
• (警告：純屬愚蠢)。有人在雜誌報導上讀到。

如果您是因為第一個理由而需要變更預設名稱的話，儘管放手去做。這類變更不太會造成系統的不穩定，因為它們通常已經經過測試了。

如果您是因為第二個理由而變更預設值的話，請務必三思而後行。這類變更大多未經軟體製造商的測試，因此製造商無法預測在您進行變更之後，系統會出現什麼反應。而且，通常還有更好的替代方案能夠提供真正的安全性。

如果不肖份子剛好知道帳戶名稱，那又怎麼樣？將不肖份子擋在系統之外的是密碼，以及密碼的強度。極力想把 Administrators 和 Guest 之類的預設帳戶名稱，改成不好猜測的名稱，往往只是不想使用強式密碼或通關密語的一種逃避作法。唯有直搗真正問題 (差勁的密碼) 所在，才能防止弱點 (變更預設名稱) 暴露。

透過隱匿來實現安全，並不是對問題視若無睹的措施。比方說，如果公司在邊緣路由器封鎖網路新聞傳輸通訊協定 (NNTP) 以防止員工閱讀新聞群組，但卻允許輸出安全殼層 (SSH) 的話，就不算是透過隱匿來實現安全。因為 SSH 可以接通每個通訊協定，所以問題很明顯；實作愚蠢的緩和措施，除了阻礙合法使用者在不違反安全性原則下完成合法的工作之外，其他什麼事都不能做。這類措施並不是透過隱匿來實現安全，而是愚蠢且毫無意義的行為。

如同「透過隱匿來實現安全」一詞中的「安全」一字所暗示，您確實可以從這種措施中獲得一些保護。不過，這也暗示您實際上並未採取任何行動來停止一或多個攻擊標的，而這也是問題所在 (攻擊標的基本上是攻擊者可以存取系統的管道)。

比方說，假設您的網頁伺服器相當脆弱，只要在 TCP 連接埠 80 公開入侵，就可以將它輕鬆攻陷。如果要關閉那個標的，可以修補網頁伺服器，或者把它關閉起來，兩者都可以徹底停止這個標的。您可以使用防火牆或 IPsec，來關閉除了幾部選定電腦以外所有電腦的連接埠 80，藉此停止部分攻擊。此舉雖然無法完全封鎖攻擊標的，卻可以明顯緩和問題。

另一方面，透過隱匿來實現安全還包括採取一些並非停止攻擊標的，而是隱藏攻擊標的作法。舉例來說，您可以把網頁伺服器移到連接埠 81 (而不是連接埠 80)，只讓那些知道網頁伺服器在哪裡的人存取。這就是爭論所在。在現實情況下，把網頁伺服器移到連接埠 81 只會阻止部分攻擊，而且多半只會造成使用者的不便。厲害的入侵者會直接對大量的連接埠執行連接埠掃描器和網路橫幅抓取器，來探索非標準連接埠上的網頁伺服器。只要他一找到網頁伺服器，就會對伺服器發動入侵，因為您實際上並沒有移除攻擊標的，只是 (暫時) 隱藏攻擊標的而已。

難道這就表示您連試都不該試嗎？答案要看情況而定。這與 [資訊安全性] 欄位裡面的所有一切一樣，全都與風險管理息息相關。為了瞭解值得考量的關鍵要素，我們將迅速查訪其他幾項透過隱匿來實現安全的措施，然後詳細討論其中一項 — 重新命名系統管理員帳戶。

評量安全性措施

透過隱匿來實現安全的範例有很多，它們可能是由系統和網路管理員採取的動作，也可能是由軟體開發人員發動的動作。但是兩者共通點都是將它隱藏起來，不讓潛在的攻擊者發現，企圖藉此減輕弱點。

難道在這些程序當中，真的找不到一絲有利的效果嗎？難道一口咬定所有透過隱匿來實現安全都是有害無益的作法，真的就公平嗎？其實，當中至少有部分措施還是有人支持的。例如，您可以在 Windows® 的 Windows 檔案總管隱藏磁碟機代號。許多環境 (尤其是學校電腦室) 都是利用這個方法，防止使用者將資料存到硬碟中。當然啦，大部分的應用程式還是能夠把資料存到硬碟當中，所以它也不能算是最佳的安全性措施。不過，實作這種措施的機構常常宣稱它硬碟上的資料的確因此變少了。

Windows 上另外一種經常實作的透過隱匿來實現安全作法，是關閉系統管理網路共用 (例如 C$、Admin$ 等等)。據說此舉可以防止攻擊者從遠端連接到電腦。其實這不僅不屬實，而且擁有可使用系統管理共用的帳戶的攻擊者，還可以從遠端重新啟用那些相同的共用。但是許多組織卻發誓停用這些共用，確實可以降低它們網路上發生惡意程式碼的頻率。

對於這種錯放精力的情況，我們最津津樂道的一個範例，就是 Windows 中 [允許卸除而不須登入] 設定。如果將它設為停用，登入畫面就會隱藏 [退出電腦] 按鈕，而讓攻擊者無法正常退出電腦。當然啦，不管那個按鈕看不看得見，入侵者大可把電腦跟基座一同塞到袋子裡面走人。這種可能性連透過隱匿來實現安全都搭不上邊。

另外一個明顯的範例是 [允許伺服器操作者排程工作] 設定，這個設定正如其名，它允許屬於 Server Operators 群組成員的使用者排定工作的時程。這種問題很敏感，因為這類工作可能會以本機系統身分執行，而且應該只有系統管理員能夠排定以本機系統身分執行的工作。當然啦，伺服器操作員有可能透過各種不同的標的讓他們成為系統管理員，因此預防他們透過這種方式排定工作，實際上所獲得的成效也是微乎其微。

但是有許多組織卻很喜歡這個設定，因為它容許工程師採用伺服器操作員而不是系統管理員的身分，也就是說，他們比較不可能意外摧毀伺服器。這本身多少有些好處。

那麼結論呢？很明顯地，這些問題有的可能非常複雜。我們花了不少時間痛快地爭論這類措施。Roger 堅持這類作法有其價值，而 Jesper 則認為這多半只是浪費時間而已。那麼就讓我們探索一下透過隱匿來實現安全其中一個最常引用 — 和爭論 — 的案例：重新命名系統管理員帳戶。Roger 代表這項措施的正方，而 Jesper 代表反方。安全性名人 Aaron Margosis 和 Steve Riley 也分別在「重新命名系統管理員帳戶」和「不要變更預設值」資訊看板中加入討論。

隱藏系統管理員帳戶

安全性專家常常建議將系統管理員帳戶 (相關識別元 (RID) 500) 改成一般大眾所不知道的名稱，有幾份 Microsoft 強化指南中也提及了這種作法。群組原則甚至還包含了一個用於重新命名系統管理員帳戶的設定，如 [圖 1] 所示。其構想是，要是重新命名系統管理員帳戶的話，攻擊者就比較不容易以真正的系統管理員身分登入了。當然囉，使用群組原則進行這項作業的問題很明顯，那就是經過重新命名的系統管理員帳戶，在套用這個群組原則物件的每一部電腦上，都是採用相同的名稱。此舉無疑就降低這個安全性措施的隱匿價值了。

[圖 1]** 重新命名系統管理員帳戶 **(按一下影像可放大檢視)

另外還有很重要的一點是，只要使用者具有合法的帳戶，無論系統管理員帳戶是否經過重新命名，都可以擷取到該帳戶的名稱。凡是系統管理員帳戶都有一個 RID ─ 500。只要簡單詢問一下含有 RID 500 的帳戶名稱，任何擁有帳戶的使用者都可以查看它的實際名稱，如 [圖 2] 所示。

[圖 2]** 尋找重新命名的系統管理員帳戶 **(按一下影像可放大檢視)

Roger 的申論

就我聽到反對重新命名系統管理員的主要論點是，要將任何安全性主體帳戶名稱轉換成其相關安全性識別元 (SID) 並找出它的 RID，根本就是易如反掌。而且只要是真正的系統管理員帳戶，都有一個 RID ─ 500。所以，若是攻擊者輕易就可以將使用者帳戶名稱轉換成 SID/RID 組合，並找出 RID 500，那又何苦來哉呢？

但是事情並沒那麼簡單。若要將使用者帳戶名稱轉譯成 SID/RID，必須能夠存取 NetBIOS 或 LDAP 連接埠才行。而大多數周邊防火牆都不允許在網際網路上進行這類存取，因此除非攻擊者完全略過防火牆，否則根本無法進行轉譯。再者，除了網域控制站 (DC) 以外，Windows XP 及之後的 Windows 版本並不能進行匿名 SID 轉譯。以大多數對外的電腦 (也就是風險最高的電腦) 來說，攻擊者必須具備驗證過的憑證，才能把名稱轉譯成 SID。

因此，若要發動轉譯攻擊，得繞過不少真正的深度防禦障礙才行。即便攻擊者克服了這些障礙，最後還是會陷入跟沒有改變帳戶名稱一樣的情況。所以重新命名系統管理員帳戶只會提高安全性，不會有任何害處。

另外一個秘密 假如攻擊者不知道系統管理員帳戶名稱，它就變成了另一個「秘密」標籤，跟密碼類似，攻擊者必須要知道才行。不可否認的，使用者帳戶名稱明顯不如系統管理密碼複雜，但它仍舊可以多建一道屏障，以指數方式將猜測/破解密碼的問題複雜化。如果您曾經做過密碼滲透測試，一定知道要猜中使用者名稱和密碼，需要下多少功夫。它結合了一項原本就很困難的工作，讓它難上加難。

阻撓自動化惡意程式碼和指令碼小子 我投入 Windows 安全性防禦至今已有 22 個年頭，過去 5 年來也執行了八個公開在網際網路上的 Windows 誘餌 (honeypot)。這段時間內，我從來沒看過自動化惡意程式碼 (絕大多數的攻擊都是由此構成) 使用除系統管理員 (或者在 *NIX 系統的情況下，稱為根) 以外的任何使用者帳戶標籤。如果您將系統管理員帳戶重新命名，等於是馬上殺了仰賴系統管理員名稱的所有惡意程式碼。換句話說，等於降低了安全性風險。

指令碼小子的情況也是一樣。就我所知，每本「暢銷」的 Windows 入侵手冊，都有提到將名稱轉譯成 SID 的方法，但是基於某些原因，要是我同時有個「假」的系統管理員帳戶來分散注意力的話，在誘餌上就完全看不到這種情況。只要是精明的駭客，就應該隨時確認他們找到的系統管理員帳戶是不是真正的系統管理員 (RID 500)，但他們經常不這麼做。我也不知道為什麼，要怪就怪駭客懶惰和人的本性吧。

連大多數高手也裹足不前 這實在讓大部分的人感到訝異。其實只要執行誘餌幾年的時間，很快就能區別自動化攻擊、指令碼小子和高手之間的差異。過去五年以來，我的誘餌報告了上百萬次的攻擊，卻從來沒看過高手在有假系統管理員帳戶的情況下進行 SID 轉譯。

我很肯定確實有犯罪高手在進行 SID 轉譯，但是我敢打賭那只佔少數，而且我從來不隨便記錄。為什麼高手不這麼做呢？我猜是他們覺得絕大部分的人都不這麼做，所以他們也沒有理由這麼做。

簡化警示 現在另一方爭議，若是重新命名系統管理員帳戶開始盛行的話，可能會失去它作為隱匿措施的價值。爭論點在於惡意程式碼、指令碼小子和高手會改變他們的預設戰術，改找系統管理員以外的名稱。而這樣的顧慮是有根據的。所幸，它並不會改變基本的情況。首先，若是 Windows 具備超級權限的帳戶並不是取名為 Administrator 的話，惡意駭客就必須多下點功夫。事實就是如此。而且若是惡意駭客必須多費心思的話，他就更不可能採取攻擊的途徑，也許因而讓其他彌補深度防禦的手段趁機更快速的偵測出惡意活動。

這也將主題帶到我贊同重新命名的最後一個觀點。如果您的系統管理員帳戶從來就不叫 Administrator，而且您也使用那個名稱建立了另外一個帳戶 (如 [圖 3] 所示)，那麼這個帳戶就是一個良好的警示機制。如果事件監視偵測到有登入嘗試使用預設名稱的話，就得馬上探究這個事件。

[圖 3]** 以名為 Administrator 的誘餌帳戶嘗試登入，可視為早期的警告 **(按一下影像可放大檢視)

我們的事件日誌充斥著一堆沒有任何意義的「不良」登入，這充其量不過代表使用者 (或 Windows) 是使用錯誤密碼或諸如此類的東西進行登入。如果您的系統管理員帳戶就叫做 Administrator 的話，您該如何輕易分辨這到底是正常登入還是惡意登入呢？如果您從來沒有一個登入帳戶叫做 Administrator，卻偵測到有人以該帳戶名稱登入，那麼大概就知道這不是善意的登入了。早期意義不大的警告，在如今的防禦環境下卻具有相當的價值。

Jesper 的反駁

Aaron Margosis 對重新命名系統管理員帳戶的論點

Jesper，在理想的世界中，您絕對沒有錯。密碼永遠固若金湯，暴力猜測根本別想得逞，而 -500 本機系統管理員帳戶也只有在緊急修復之時才會使用。但在真實的世界裡，情況並非如此。

不管您多麼宣揚安全性，尤其是您自編自導的絕妙通關密語 (《世紀大爭論：通關密語與密碼比較》，第 1、2 和 3 部，網址是 go.microsoft.com/fwlink/?LinkId=113157、go.microsoft.com/fwlink/?LinkId=113159 和 go.microsoft.com/fwlink/?LinkId=113160)，許多系統管理員對於什麼才算是強式密碼，多半沒有適當的了解。

才沒多久以前，從多字元集挑出八個隨機字元構成的密碼還被視為強式密碼呢，摩爾定律卻證明這種情況維持不了多久。其罪魁禍首不外乎就是欠缺使用者 (和系統管理員) 教育，而且這種情況未來很有可能持續下去，至少持續到密碼強度成為有線電視新聞頻道的熱門話題才會改變吧。

所以現在要猜中真實世界的密碼，不必花上 600 年時間，通常一頓午餐就夠了，只要加個 x1000 倍率器就可以得到真正的值。面對許多想要大力攻擊名叫 Administrator 的帳戶的自動化攻擊，只要將帳戶重新命名，即可使它刀槍不入。

要重新命名系統管理帳戶，一般所需投入的時間和精力通常不多，大概跟您注意到的一樣，只是個簡單的 GPO 設定而已。事實上，美國政府的聯邦桌上型電腦核心設定 (Federal Desktop Core Configuration，csrc.nist.gov/fdcc) 還規定必須重新命名 -500 帳戶呢。重新命名不過是許多必要的設定之一，而且並不會花太多時間或精神。也沒有人對於重新命名的價值因此產生錯誤的安全感 — 我還沒聽過有人這麼說：「我們不需要補充程式管理，因為我們已經把系統管理員帳戶重新命名了」。

如果整個組織把帳戶全部改成一樣的名稱時，重新命名還有什麼價值嗎？價值不大，但多少還是有：第一，它會封鎖料想系統管理員的自動化攻擊。第二，潛在攻擊者集合不見得隸屬於知道新名稱的「任何人」集合 (最大風險可能是發生在本機系統管理員帳戶 — 無論經過重新命名與否 — 在組織內共用共同密碼時。管理這些密碼一直都是很大而且很重要的問題。停用 -500 帳戶的確是解決這種問題的辦法之一，但是萬一無法使用網域帳戶時，這個做法反而會封鎖重要的修復管道)。在此我也要指出，長久以來我們的安全性指南就建議我們將預設帳戶重新命名，因此這種作法不僅已經經過測試，而且完全受到支援。

到目前為止，我想我們應該都知道，隱匿措施本身所構成的防禦能力並不充足，但是它們可以強化其他安全性措施，而 Roger 的資料也清楚闡明了這點。只要實作的成本不高，組織就不應該把它們排除在外。

至於我的論點是，反對重新命名系統管理員帳戶是有其根據的。不過，在繼續討論之前，我必須承認 Roger 最後一個論點是蠻有效的。但是在高度管理的環境當中，任何使用系統管理員帳戶進行的登入都應該接受調查，因為這個帳戶應該只用於緊急修復的情況。

多此一舉 重新命名系統管理員帳戶原本要減輕的主要風險，是預防有人從遠端猜測其密碼。但重新命名系統管理員帳戶只會阻撓在電腦上沒有其他授權帳戶的使用者。這類攻擊者通常會嘗試一連串隨機的密碼登入系統管理員帳戶。不過無論攻擊者是否猜錯帳戶名稱或密碼，他都會收到相同的錯誤訊息。

這就表示重新命名系統管理員帳戶的主要爭議 — 指令碼小子會消失 — 是有瑕疵的。他們並不會因為系統管理員帳戶有經過重新命名，而比在原始名稱時更快消失，因為他們根本無法分辨！無論如何，他們猜測的都是同一組隨機密碼，然後再移往下一個潛在的受害者。

這表示只要系統管理員帳戶的密碼強到足以擊退攻擊，那麼將帳戶重新命名就沒有多大意義了。假設我們的系統管理員帳戶密是 15 個字元，由整個鍵盤挑選出的大小寫字母、數字和符號所組成。在網路上要猜中那個密碼大概需要花上 591,310,404,907 年的時間，相較之下，大約是宇宙存在時間的 43 倍長。

現在，假設我們把系統管理員帳戶重新命名，然後改成 1,000 個可能的值之一。這麼一來，就可以把猜中密碼的時間延長到 591,310,404,906,787 年，或是宇宙存在時間的 43,161 倍長。這樣有比較安全嗎？當然啦，後者的安全度比起前者來說，是十的三次方倍。我們有降低攻擊者猜中密碼的可能性嗎？嗯，無論哪種情況都微乎其微。換句話說，用白話一點講，與原始系統管理員帳戶名稱比起來，我們得到的結果肯定沒有好到哪裡去。因為將帳戶重新命名會刪除嘗試使用它的惡意程式碼，並不表示您沒有將帳戶重新命名，就會讓惡意程式碼得逞。事實上，假如您使用強式密碼 (您是該這麼做) 的話，無論帳戶名稱為何，都可以確保惡意程式碼無法得逞。

重新命名系統管理員帳戶顯然是出於安全性指引的需求，但那並不表示它就是有用，甚或是有效的安全性措施，反而只會奪取您對安全性作出適當風險管理決策的能力。安全性指南時常要求您做出一些根本沒什麼差別的設定，而且在許多情況下，那些設定甚至根本不存在。最後，要在安全性領域裡面穩定前進，必須探視需求，並且實際分析問題，然後評估緩和措施是否合理。有一點必須特別注意 — 那就是攻擊者以功能作為目標這一點，並不足以構成修改該功能的充分理由。您只有在能夠合理預期不修改功能就會讓攻擊得逞的情況下，才能夠修改功能。

如果您設有強式密碼，那麼無論帳戶是否重新命名，攻擊成功的可能性實際上是零。因此，只要您設定強式密碼，就沒有特定的安全性理由需要把帳戶重新命名。再者，如果您像我一樣稟持這樣的原則操作：沒有東改西改的電腦上可能還比較穩定 (順帶一提，這是不爭的事實)，那麼就更沒有理由重新命名系統管理員帳戶了。

將焦點轉移到低價值緩和措施 低價值的透過隱匿來實現安全的緩和措施，其問題出在它們可能會轉移公司高價值緩和措施的焦點。比方說，投入重新命名系統管理員帳戶的時間和精力，並不能用於其他作業上。因此如果其他作業比重新命名系統管理員帳戶的價值還高的話，公司便錯失一個良機了。雖然聽起來不足以構成像樣的成本，但如果重新命名的系統管理員帳戶多達 50,000 個的話，您應該就可以意會了。

更糟的是，一旦實施低價值緩和措施之後，公司的領導階層可能就不管事了。管理階層不見得都能了解透過隱匿來實現安全的緩和措施，其最低價值在哪裡，因此可能不會採取其他行動。這麼一來可能會為公司帶來不小的風險，但是只要管理階層願意投入時間和精力來了解所實施的緩和措施的價值，就可以輕鬆避免這種風險。

高昂的管理成本 最後一點，管理成本可能相當高昂 (這要看緩和措施實作的好壞而定)。如果您是直接設定群組原則物件 (GPO)，來重新命名系統管理員帳戶的話，倒是可以把成本降得很低。因為每個人都知道名稱，而且部署的成本也幾近於零。不過，就像我之前所說的，只要擁有帳戶，都會知道改成什麼名稱，所以它也沒什麼價值就是了。因此，若要充分發揮這項緩和措施的價值，必須在不同的主機上使用不同的名稱，但是這類系統的管理成本就非常高昂了。

所以您最好還是使用像 passgen (protectyourwindowsnetwork.com/tools.htm) 這樣的工具，在網路上對所有系統管理員帳戶設定 100 個字元完全隨機的密碼，然後對日常管理工作改用不同的帳戶。由於系統管理員帳戶是專門用來修復嚴重損毀 (在 Windows Small Business Server 2003 上除外)，因此對您的網路管理系統應該不會有任何影響。再者，攻擊者要正確猜出任何一個系統管理員帳戶的密碼，可能比大海撈針還難。所以建議您還是專心構思獨特的強式密碼吧，至於指令碼小子要怎麼猜，就隨他們去猜嘍。

重點就是風險管理

實際上任何透過隱匿來實現安全的措施，都可以利用我們在本文所述的方法加以分析。每一種計畫都各有其優缺點，適合這家公司的策略，不見得就適合另一家。最後，這就變成了風險管理的問題。風險比實作解決方案的成本還重要嗎？您為保護資訊資產所作的每項決策都必須是明智的風險管理決策，抉擇很少是黑或白。

沒錯，您的確是有現成的決策可用。比方說，雖然您可以選擇不要加密信用卡資訊，或是儲存信用卡確認碼，但這兩種作法都可能使您無法接受信用卡付款。這項決策對您業務可能產生的負面影響是，您其實沒有其他選擇。換句話說，雖然這是風險管理的決策，但卻是很容易作出的決策。

同樣地，一般正常人也不會把開放式無線網路，連接到商店內部網路的後端。不過這並不表示這樣的決策不是風險管理的決策。它其實就是風險管理的決策。也許有人還是會選擇這麼做，但他就必須自行承擔這麼做的後果 (討厭的是，這種情況好像從來沒真正發生過)。

此處所要採取的重要步驟是，清楚表達您要解決的問題、針對該問題所提出的解決方案，以及各種方案的優缺點。這麼一來，您就擁有制定明智風險管理決策所需的資訊了。如果沒有這項資訊的話，只能根據直覺做決定，而在這種情況之下做出的決策多半不怎麼樣。

Jesper M. Johansson 是負責安全性軟體的軟體架構設計人員，也是《TechNet Magazine》的特約編輯之一。他擁有管理資訊系統 (MIS) 的博士學位，研究安全性長達 20 多年，是企業安全性領域的 Microsoft MVP。Jesper 最新著述為《Windows Server 2008 Security Resource Kit》。

Roger Grimes (CPA、CISSP、MCSE：安全性)，Microsoft ACE 小組的資深安全性顧問，著作或合著了八本關於電腦安全性的書籍，並且撰寫超過 200 篇雜誌文章。他經常發表安全性研討會的演說，並且是 InfoWorld 安全性專欄作家。

© 2008 Microsoft Corporation 和 CMP Media, LLC.保留所有權利；未經允許，嚴禁部分或全部複製.