資訊安全新知我剛收到資訊安全佈告欄，接下來該怎麼辦？
Christopher Budd
Microsoft 應客戶要求，於 2003 年 10 月確立資訊安全佈告欄的每月發行程序。客戶的主要要求之一是希望能預知資訊安全佈告欄的發行排程。到目前為止，我們都能善用該定期性和可預知性來調整及改進我們的程序。
Microsoft 資訊安全佈告欄網站 (英文) 是您可以在其中尋找最新的資訊安全佈告欄和搜尋過期佈告欄之處，如 [圖 1] 所示。[圖 2] 則顯示範例佈告欄，此例為 2006 年 8 月份的佈告欄。
圖 1** Microsoft 資訊安全佈告欄網站 **(按影像可放大)
對大多數的客戶而言，Microsoft 的每月資訊安全佈告欄對於 Microsoft 安全性更新的部署，扮演著提升程序完整性的推手角色。由於資訊安全佈告欄會在可預期的日期發行，因此客戶也可以利用此機會來自行建立處理這些佈告欄的定期程序。這些客戶已在其本身的安全性更新評估及部署程序中建立了時間表和步驟，根據 Microsoft 的每月資訊安全佈告欄發行來整合可預期的時間表。客戶使用該項程序以系統性的方式來分析、測試和部署更新，不但有助於提升其整體安全性狀況，也可減少當機時間和作業中斷的情況。
圖 2** 2006 年 8 月資訊安全佈告欄 **(按影像可放大)
不過，有些客戶會在沒有既定程序的情況下進行安全性更新評估和部署。雖然可以透過未系統化的方式部署更新而不發生任何問題，但基本上這與我們認定的安全性更新管理最佳作法是衝突的。
我們已針對佈告欄發行的方式和時間提供了有用的相關資訊，但尚未針對佈告欄可以使用的對象以及如何在您自身的程序中整合這些佈告欄提供足夠的指引。有些客戶可能並不清楚對其有益的程序，或者建立這些程序的最佳方式。
因此，在本專欄中將列出在評估和部署安全性更新時，我們所推薦的步驟和程序。任何規模的組織都可以遵循這些步驟。如果是規模較大的組織，可能需要根據內部結構，在不同的群組之間切割這些步驟。如果是規模較小的組織，則可以由單一群組或甚至單一人員來執行所有步驟。不論職責的分配如何，在評估和部署的程序中都必須明確地說明所有這些步驟。[圖 3] 提供程序的概觀。
圖 3** 資訊安全佈告欄的評估和部署程序 **
1. 接收進階通知
每月資訊安全佈告欄程序的第一個步驟，應該是確保您收到最新安全性更新的進階通知。Microsoft 會在標準的每月發行日 (每月的第二個星期二) 的前三個工作天，於太平洋時間 (GST -8) 上午 10 點左右在網站上公佈資訊；因此，進階通知資訊會在前一個星期四公佈。
進階通知的目的是在實際發行之前，提供有助於部署規劃的資訊。其中所含資訊的詳細程度，是在發行安全性更新之前，根據保護客戶的需求，藉由不揭露任何可能構成攻擊之資訊加以平衡所得。進階通知會整合即將發行之更新的相關資訊，並依產品名稱提供，但不揭露任何特定版本的資訊 (例如，Microsoft® Windows® 或 Microsoft Office)。其中每個項目都會詳細列出將針對該產品所發行的佈告欄數、這些佈告欄的最高嚴重性、是否有任何更新需要進行重新啟動，以及適用於這些佈告欄的偵測工具等。
為了確保不發生任何意外並盡可能降低混淆情況，進階通知也會針對將於同日發行，但與資訊安全佈告欄不相關的其他更新提供相關資訊。尤其，它還會詳列會透過 Microsoft Update (MU) 和 Windows Update (WU) 發行多少高優先順序的非安全性更新，以及 Microsoft Windows 惡意軟體移除工具是否有任何更新。
最後，我們會針對可能導致部署延誤的問題提供相關資訊，如同我們在 MS06-019 中，針對 "Send as" 權限變更所提供的資訊。
新的進階通知會於每月發佈 (英文)，此時會透過「安全性通報服務：完整版」(Security Notification Service Comprehensive Edition，SNSCE) 傳送通知。您可以在此註冊 SNSCE (英文)。
2. 評估潛在影響
一旦接到進階通知，第一個步驟應該是評估即將發行的佈告欄與您環境的相關性。即使進階通知只會針對受影響的產品提供有限的資料，仍具有足夠的資訊，可以用來評估即將發行的佈告欄是否與您的環境相關。
例如，假設進階通知指出有兩個具有最高嚴重性等級而且需要重新啟動的 Microsoft Exchange 佈告欄。如果沒有執行該程式，您就會立刻知道這些佈告欄並不適用於您的環境。相反地，如果有執行 Exchange Server 2003，則您會知道在星期二最多可能會收到兩個具有嚴重等級且需要重新啟動的佈告欄。.
在進行規劃用途時，請將進階通知視為一項工具，可協助您就佈告欄數目、嚴重性以及與重新啟動相關的部署影響，來判斷組織所受到的最大可能影響。一旦評估了更新的相關性和最大可能影響，就可以建立排程，其中應該包含下列動作項目：
- 進行風險評估、測試和部署的人員
- 測試計畫和測試實驗時間
- 部署計畫和排定的重新啟動作業 (視需求)
此時所有的排程都應該是暫時性的，因為進階通知中的資訊有可能隨時變更。此外，由於進階通知的資訊有限，所以您可能會在擁有完整詳細資料時變更計畫。
最後，如果有任何其他資訊 (例如功能變更)，則應該使用進階通知和實際的資訊安全佈告欄發佈之間的時間來研究問題，並評估該問題對環境的可能影響。您可能需要根據研究而修改您暫時性的排程。
3. 接收 Microsoft 資訊安全佈告欄
Microsoft 會在每個月第二個星期二發佈其資訊安全佈告欄。太平洋時間上午 10 點是預定的發佈時間，但由於這項發佈與一個龐大而複雜的程序相連，所以可能會因多種原因而延遲。在此項發佈中，資訊安全佈告欄、安全性更新、偵測和部署工具 (例如，Microsoft Baseline Security Analyzer (MBSA) 和 Windows Server® Update Services (WSUS)) 的更新，以及新增的偵測工具 (例如新版的 Enterprise Scan Tool (EST)) 全都會發佈到 Microsoft 網站。
Microsoft 資訊安全佈告欄網頁會啟用對 RSS 摘要的支援。當資訊安全佈告欄包含更新時，我們的 RSS 摘要也會更新，而這會接著更新 RSS 彙總程式和檢視器。此外，也會使用安全性通報服務 (Security Notification Service，SNS) 和 SNSCE 傳送通知。通報會同時透過電子郵件和 MSN® Alert 傳送。
若要獲知新資訊安全佈告欄的可用性資訊，應該在所有可用的通知機制中註冊。您可以訂閱 RSS 摘要 (英文) 以及 SNS 和 SNSCE (英文) 兩項服務。
4. 評估資訊安全佈告欄的相關性
您要清楚指派檢視新資訊安全佈告欄的職責並評估這些佈告欄與您環境的相關性，這是很重要的。在進行此項評估作業時，可以從資訊安全佈告欄中擷取完整的特定資訊，並依需要來修改及調整您的暫時排程。回到前面的範例，如果您通知 Exchange 管理團隊可能會有重要的安瞿性更新，但接著又發現 Exchange Server 並不受影響，就可以針對這些資源的排程進行調整。
一旦評估過資訊安全佈告欄與組織的相關性之後，就可以在程序中使用那些相關的佈告欄繼續作業。
5. 執行風險評估並為佈告欄評訂等級
現在您需要執行相關的風險評估。在有劃分職責的組織中，這個步驟常會由安全性群組來執行。雖然每個 Microsoft 資訊安全佈告欄都包含最高嚴重性等級，但該等級只反映出所有受影響產品中全部弱點的最高嚴重性。套用於貴組織的 Microsoft 嚴重性等級，可能與列出的最高安全性等級不同，這是根據您環境中版本的問題嚴重性而定。請在資訊安全佈告欄的＜提要＞下方，查看完整的「嚴重性等級和弱點識別碼」表格，並針對您的特定版本取得特定的弱點資訊，這點很重要。
在那之後，您應該檢視其他的技術資訊，例如「緩和因素」和 FAQ 中每個弱點的技術詳細資料，並根據您的環境和原則來調整風險評估。您的原則也可能要求評估中要說明非技術的環境因素，例如威脅環境或者特定應用程式對貴組織的關鍵性為何。
在本程序結束後，您應該會有每個佈告欄的風險等級以及與其相關的更新。現在繼續我們的範例，Exchange 管理群組可能會根據資訊安全佈告欄中詳細說明的變更，將安全性更新評比為「中等風險」。您應該根據原則，依需要來更新和變更排程。例如，您的原則可能會要求中等風險更新需要比低風險更新多一到兩天的測試。
在某些情況下，您的原則可能還會要求，需要針對特定風險等級的佈告欄考量實作的因應措施。例如，貴組織的原則可能會指出，應該針對評比為重要的所有安全性更新儘快地檢視和部署因應措施。在這種情況下，您要對因應措施執行額外的風險評估，以判斷要實作什麼以及何時要進行實作。
在本程序結束後，您應該會有要在環境中部署的更新清單，其中每項更新都具有相關的風險等級。此外，您還應該有要進行實作的因應措施清單，這項清單會用來更新您的測試和部署排程。對排程所做的變更應該反映原則所指定的時間軸。例如，您的原則可能會指出，對於所有重要的安全性更新，都必須在 24 小時內部署因應措施，並在 7 日 (非工作日) 內部署更新。
6. 判斷安全性更新和/或因應措施對組織的可能影響
瞭解安全性更新或因應措施對環境的影響，是評估程序中的一個重要步驟。在有劃分職責的組織中，這個步驟常是由管理直接受到安全性更新或因應措施影響之系統的群組來執行。
瞭解可能的影響，有助於瞭解和判斷安全性更新或因應措施本身所造成的風險。您可以在資訊安全佈告欄的＜與本安全性更新相關的常見問題集 (FAQ)＞一節中找到相關資訊。關於安全性更新如何解決弱點的方法，則位於＜弱點詳細資料＞下的弱點常見問題集內。
本步驟的目標是判斷更新和因應措施的風險等級。現在繼續前述的範例，Exchange 管理群組可能會根據資訊安全佈告欄中詳細說明的變更，將安全性更新評比為「中等風險」。您應該根據原則，依需要來修訂排程。例如，您的原則可能會要求「中等風險」更新需要比「低風險」更新多一天的測試。
您可能也需要根據風險等級對排程的影響，重新檢討部署因應措施的相關決策。例如，您可能會發現需要多兩天的測試時間，而這會使系統未受保護的時間超出原則所允許的期限。在這種情況下，可能要重新檢討因應措施的部署，以求符合原則。
最後，在進一步開始發展更新的測試計畫時，您要使用此步驟所產生的資訊。
7. 定義測試計畫
測試若要有效，則必須系統化，而且必須使用有意義的計畫建立。您的測試應該針對最可能在環境中造成問題的區域進行。由於每個環境都不同，所以我們不能提供有效測試計畫的標準範本。
在有劃分職責的組織中，測試計畫常會由一個以上的群組來設計。負責管理直接受到安全性更新或因應措施影響之技術或系統的群組，可以提供其特定專業。測試群組可以提供建立測試案例的專業、測試工具的選項，以及對實際時間軸的瞭解。
在此階段，您應該注意測試計畫對於安全性更新或因應措施的風險等級會有什麼影響，並依此對測試和部署排程進行變更。例如，如果您判斷開發出的測試計畫，並不能完全照您的規劃測試更新，則可以增加其風險等級、選擇延後部署，並在此期間實作解決方法。
8. 開發部署計畫
部署是實際實作安全性更新或解決方法所提供之防護的程序。因為部署是本程序實際的終極目標，所以瞭解可用的部署方法，並將其當作考量因素而列入評估，與安全性風險評估一樣重要。在有劃分職責的組織中，判斷安全性更新的可能部署方法，常是由負責管理軟體更新基礎結構的群組 (例如維護 Systems Management Server (SMS) 的群組) 來執行。監督組態管理技術 (例如 Active Directory) 的群組可能需要判斷因應措施的可能部署方法。
在此步驟中，您的目標是瞭解可能的部署方法，並從其建立用來部署安全性更新或因應措施的計畫。在此步驟中，您必須瞭解部署的可能方法將如何影響您的排程以及進行任何必要的變更。例如，如果某安全性變更不受 WSUS 的支援，而這是主要的部署方法，則您可能會決定部署更新所需的時間會比原先計畫的多兩天，而且決定實作在此部署期間提供必要防護的因應措施。
您可以在資訊安全佈告欄的＜與本安全性更新相關的常見問題集 (FAQ)＞一節中，找到部署方法的相關資訊。實作因應措施的相關方式會列於每個解決方法中；每個弱點都有相關的個別因應措施。
這包含規劃階段。在此階段，您擁有的排程，應該要反映出有關安全性風險、安全性更新風險等級以及因應措施、測試和部署之評估及規劃的所有項目。如您在這些階段中所見，這些階段彼此之間的關聯複雜，而且不一定呈線性關係。在某些組織中這些階段會同時發生，在其他組織中則是循序發生。您應該根據組織的原則、需求和資源，決定這些步驟的實作。這些步驟最重要的並不是特定的結構和順序，而是要確保這些不同的階段可以彼此通知和回應。任何實作的關鍵都在於保持彈性和變通。
9. 測試更新和因應措施
在測試階段中，要透過稍早在測試環境中定義的測試計畫來施行安全性更新和因應措施。測試環境的目標是在生產環境中複寫重要項目。在測試安全性更新或因應措施時，要努力找出在部署到生產環境之前所可能發行的任何問題。
在測試中辨識出問題時，應該判斷問題的嚴重性，以及解決問題的步驟。您可能會發現，有些小問題的影響等級尚可接受，而其他的問題則需要在部署更新之前加以解決。如果選擇接受問題，則請加以記錄，以供支援人員參考。
若要解決問題，可以向 Microsoft 產品支援服務 (PSS) 提報，此單位提供安全性更新相關問題的免費支援。您可以在下列網站找到 PSS 的連絡方式：support.microsoft.com/security。由於解決問題可能會增加測試的時間，並因此延誤部署，所以在選擇解決問題的方式之前，應該考慮對排程的可能影響。
當測試完成且所有問題都已解決或記錄時，接著可以證明要在生產環境中部署之安全性更新或因應措施。
10. 部署更新和因應措施
在安全性更新或因應措施都經過測試的証明後，就可以繼續部署程序。在部署期間要將安全性更新或組態變更實際套用至系統時，請使用計畫來指引您。參與計畫開發的群組通常也負責實際的部署。
如果在部署時遭遇問題，例如，安全性更新無法透過更新管理基礎結構而正確安裝，則您需要仔細檢查該問題。如果問題造成延誤，則可能需要重新檢查選項和/或考量因應措施以保護您的系統。
在理想狀況下，測試程序會在部署之前識別出所有在生產中可能發生的問題。不過，如果在部署到生產環境之後真的遇到問題，則應該遵照在測試中遭遇問題時會遵循的相同步驟處理。請評估問題並決定要接受還是解決該問題。
如果安全性更新成功地套用，則保護機制已經就位，而這些程序的終極目標也已達成；不過，如果沒有成功套用，則您的系統仍可能受到攻擊。
由於某些系統可能尚未成功更新，所以佈署程序的最後步驟十分重要 - 也就是對系統進行稽核，以確認部署成功。在某些組織中，稽核會由個別的稽核群組執行，此群組常與安全性小組相關連。WSUS、MBSA 和 SMS 之類的 Microsoft 工具可以用來稽核安全性更新是否成功套用。此外，在資訊安全佈告欄的＜安全性更新資訊＞章節中，也會提供如何確認安全性更新是否成功套用的相關資訊。
結論
藉由 Microsoft 每月發行的資訊安全佈告欄，您可以針對安全性更新的管理實作更為定期的規劃和程序。建立定期的程序和過程，有助於提供更佳的系統防護，同時也可以將干擾和可能的停機時間減至最少。
雖然每個組織都應該建立本身獨特的程序來管理安全性更新，貴組織的程序應該包含本專欄中所建議的步驟。您不需要擁有個別的安全性和更新小組，但應該要執行安全性風險評估並開發部署計畫。
此篇文章的重要概念在於規劃的重要性。有了良好的規劃，涉及實際活動的步驟 (例如測試和部署階段) 在進行時就會順利許多，而這也使安全性更新的程序順利成功。
Christopher Budd 是 Microsoft 安全性回應中心 (Microsoft Security Response Center，MSRC) 的資訊安全方案經理，擅長與 IT 和安全性專業人員以及其他的軟體使用者進行技術方面的溝通。
© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.