微軟十年安全備忘錄：個人經歷訪談
譯文【51CTO.com 1月17日外電頭條】我至今還清晰記得微軟在2001至2002年期間的安全狀態，一切仿佛就發生在昨天。也許不會再有另一段時光能像這兩年一般在我腦海中留下如此深刻的印象。2001年并不盡如人意，但2002年則有了大幅度改善。可以說正是前一年的困境才造就了接下來的飛躍！因此，讓我們共同追憶往昔……
在1999年底，我們幾位同事共同建立了一個規模有限的安全團隊（著眼點為處理'威脅'而非開發'功能'），旨在幫助整個公司提高軟件安全意識。在很長一段時間中我們連個像樣的名頭都沒有，直到有一天當時的Windows系統產品副總裁Dave Thompson放出話來，將團隊命名為Windows自發性安全小組（簡稱SWI）。那一陣子我們的著眼點主要在于深入檢查Windows代碼并搜尋安全漏洞，不過以這么微薄的力量應對Windows那般龐大的系統，工作成果實在是乏善可陳。因此，我們決定將重心轉向"安全漏洞清除"模式，也就是每天早上為Windows部門的一個小型開發團隊（例如網絡、終端服務、IIS、IE等）提供安全教育；在剩下的時間里我們則與該工程小組一起尋找該范疇內可能存在的漏洞。這種方式相當有趣，我們也確實揪出了不少問題，但其中最重要的意義是將安全意識逐漸滲透到企業的每一個角度。到底找出多少漏洞其實并不打緊--關鍵之處在于喚起人家對安全問題的重視程度并減少未來出現疏漏的可能性。
盡管比起初始狀態，SWI在漏洞清除方面已經頗有成效，但規模上的固有問題仍然使得工作進展舉步維艱，而且無法徹底擺脫勞動密集型這一根本屬性。不過安全漏洞清除工作在各種困擾之下仍然維持了十八個月之久。
2001年對于微軟的安全事業來說算得上是一次考驗，而其中的主要原因則是CodeRed與Nimda。這兩種蠕蟲病毒對Internet Information Server 4.0與5.0兩個版本產生了極其惡劣的影響。CodeRed利用的是默認存在于IIS4與IIS5中的某行代碼錯誤，現在回想起來，代碼實在不應該以默認形式進行安裝。Nimda則相對更為復雜，因為它在危害系統時利用到了不只一項漏洞。
雖然沒能阻止這一切的發生，但David LeBlanc和我還是在此期間寫出第一版《編寫代碼安全》一書。我們撰寫此書的目的是為了給大家一些有益的參考，以免被同樣的安全問題一次又一次絆倒。但我們真的沒想到編寫安全代碼在日后會成為如此暢銷的書籍。
隨著《編寫安全代碼》一書完稿付梓，2001年也漸漸接近尾聲。這時我收到一封來自Loren Kohnfelder這位.NET框架安全領域頂尖人物的電子郵件。Loren最杰出的貢獻是定義了如今人們常常提到的公共密鑰基礎設施（簡稱PKI）。大家不妨閱讀他于1978年就這一專題發表的論文，同時Loren也是STRIDE威脅模型的主要推手之一。
Loren告訴我，.NET通用語言運行（簡稱CLR）團隊在該項目的最終開發階段發現了一些安全漏洞，這讓他頗為憂心。我們決定組織一個規模更大的漏洞清除小組；但這一次我們希望整個小組無論存在時間有多長，至少應該在組建起來之后能及時發揮預期作用。所謂"預期作用"是指令產品的安全漏洞數量盡可能趨近于零。這就是日后小有名氣的".NET安全檢查站"，我們甚至根據團隊啟動的日期定做了紀念T恤。然而可能是為了先抑后揚吧，小組成立的當天來自西北太平洋的巨大暴風雪席卷各地，而微軟雷蒙德園區也被迫暫時關閉，因此我們的"檢查站"也只好延期啟動。
"檢查站"獲得了巨大的成功，這要多虧了Brian Harry與他的團隊，他們在管理方面的輔助讓我們受益匪淺。我們對.NET工程團隊實施安全再教育、發現并修復漏洞，但對我個人而言，最重要的是我們推廣了縮小攻擊面這一概念（即限制暴露在不受信用戶面前的代碼數量）。正是從這里衍生出了允許特定受信訪客屬性（簡稱APTCA），另外使ASP.NET運行在低權限環境下的想法也由此而來。
2001年12月《編寫安全代碼》一書問世，而Doug Bayer和我則與比爾·蓋茨在一次無比冗長的會議上詳細討論安全漏洞問題。顯然他對于2001年到處肆虐的蠕蟲病毒非常關注，并希望了解更多信息。在會議結束時，我送給比爾一本《編寫安全代碼》。
2001年12月末，.NET檢查站小組的歷史使命也宣告結束。在此期間，我們了解到如此將隊伍凝聚起來，共同解決通用型安全案例。但這還不夠，未來的路上仍有更多工作等待著我們！
鑒于在.NET方面的成功，我們決定將工作重心放在Windows .NET Server上（當時該項目就叫這個名字）。根據.NET模型，我們于次年二月開始行動，并仍然貫徹及時發揮作用這一理念。與Windows各項目小組的合作基本于三月末結束。
這就是名為"Windows安全推動計劃"的項目。
正如當下大家所熟悉的，比爾在2002年1月向全公司推出了著名的可信賴計算（簡稱TwC）備忘錄，當時我們正在為Windows系統籌備安全工作。他很少發表備忘錄，因此這也標志著企業內部將開展一次大規模行動。
在推動計劃中，我們將教育流程分為三塊：我負責所有Windows開發人員、Jason Garms負責全部程序主管及架構師，而Chris Walker則培訓各位測試人員。Steve Lipner與Glenn Pittaway引導每日流程管理，并不斷與高層管理人員彼此溝通。
我們借鑒自安全漏洞清除項目的一大方案是讓某位來自管理層的資深人士出席培訓活動。 例如在某次培訓的開幕會議上，我就請到了Windows基礎設施（包括內核到設備等）部門副總裁Rob Short。Rob身形高大瘦削，帶著濃濃的愛爾蘭口音，他當時的發言至今仍回響在我的腦海中。他指出，"不要把安全事務當成什么特殊問題，這只是我們完成工作的一項常規組成部分。"每當我與微軟內部的新任工程師或是現場的客戶討論安全話題時，總會引用Rob的這句名言，其簡潔精要的總結性令人難忘。
Windows安全推動計劃作為元祖項目，衍生出了SQL Server安全推動計劃、Exchange安全推動計劃乃至Office安全推動計劃等諸多產物。盡管緩慢，但這一系列項目確確實實改變了企業的固有觀念。工程師與經理已經逐漸將安全融入日常工作當中。
貫穿所有推動計劃的關鍵因素在于降低產品的默認攻擊面。這也是Windows Server 2003（請注意名稱的變動）中采用了一款功能精簡過的瀏覽器且沒有安裝默認Web服務器的原因。
推動計劃中不太為人所熟知的情況是，我們針對各種技術自身存在的安全隱患制作了大量書面文檔。其中大部分都歸入了第二版《編寫安全代碼》一書；這使得此書由過去的500頁增至800多頁，大部分新增內容都源自我們在2002年的調整工作中獲得的心得體會與經驗教訓。就拿關于國際化與全球化安全隱患這一章來說，書中的相關文字主要來自Windows全球化小組撰寫的白皮書。該小組不僅認真執行了整個安全推動流程，同時從自身的獨特視角出發，為我們帶來不少頗具新鮮感的安全審視思路。
推動計劃本身只能算是一種起步，真正的改變在我們實行安全開發周期（簡稱SDL）時方露端倪。我曾強調過多次，先埋頭搞軟件開發再一次性進行安全推動的想法根本不可行。坦率地講，在項目接近尾聲時再關注安全已經于事無補了。我們需要讓安全成為"生產流程的一部分"，這也正是SDL誕生的原因。
不過事情也很難始終一帆風順。2003年我們的SQL Server遭遇了蠕蟲王，Windows也被沖擊波搞得焦頭爛額。由于沖擊波有可能造成計算機藍屏，因此產品支持部門收到的電話反饋迅速增多，連我們這個團隊也不得不抽調部分人手處理電話接聽工作。Windows shell團隊的開發主管Raymond Chen當時就坐在我旁邊，并在我的注視下寫出這篇博文：
沖擊波的出現引發了一項持久且高強度的安全項目，這就是眾所周知的"Springboard"，由Rebecca Norlander、Matt Thomlinson以及John Lambert共同主持。而努力的成果就是Windows XP SP2，我們不僅發現并修復了大量安全漏洞，同時為其IE瀏覽器、DCOM以及RPC添加了許多關鍵性防御機制。我們還啟用并強化了Windows防火墻，并新增了數據執行保護（簡稱DEP）系統；同時我們將這套體系與安裝流程綁定，使得用戶能更方便地設定自動更新功能。
微軟在過去的十年中經歷了經歷了無數考驗與坎坷，而令人自豪的是我一直與這家企業并肩同行。如今情況有所不同，SDL被視為業界領先的安全機制，并為微軟之外的許多軟件開發人員所使用。我個人的工作角色也已經發生變化：我現在與微軟北美網絡安全團隊協作，幫助合作伙伴與客戶部署SDL方案。因為大家都已經清醒地意識到在安全領域提高關注度的重要性。
過去的十年發展之快令人驚愕，但我們仍然在努力緊跟乃至引領時代的腳步。微軟公司中那些才能卓著的員工在自己、合作伙伴以及客戶的產品中傾注了大量心力，盡管人們可能并不了解，但這些努力為我們帶來的安全保障卻始終來之不易且彌足珍貴。
原文鏈接：http://www.zdnet.com/blog/security/10-years-since-the-bill-gates-security-memo-a-personal-journey/10083
【51CTO.com獨家譯稿，非經授權謝絕轉載！合作媒體轉載請注明原文出處及出處！】
【編輯推薦】
