【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独家译稿，非经授权谢绝转载！合作媒体转载请注明原文出处及出处！】
【编辑推荐】
