桌面文件安全性与符合性

Wes Miller

作为 IT 专业人员,您的目标可能本是获得相得益彰的结果,但却经常产生抵触现象。安全性和符合性就是这样两个组织目标,其中一个目标的实现应该促进另一个目标的实现。但是,并非总是如此。本专栏旨在向您大概介绍这一问题:

为何保证安全性不一定表示符合所需的方案,以及为何符合性不一定能确保安全,或者如果符合性等同于安全性,为何没有获得至少应有的安全性。

安全性不是可有可无的

SDL 资源

符合性一般涉及外界强加于组织、行业、公司或产品的要求(人员、流程、基础结构和技术等)。有时,符合性需要遵守行业内部公布的标准(如支付卡行业数据安全标准,即 PCI-DSS)。理论上,这些方案至少在某种程度上与您的组织已经采用的方法是一致的。随着采用标准的日益普及,您会发现,只要还想继续开展业务,就无法再忽视它;最终,您必须严格实施和遵守这些标准,并获得最佳效果。

另一种符合性通常更为麻烦。在此,我指的是政府公布的方案,如健康保险流通与责任法案 (HIPAA) 和萨宾斯-奥克斯利法案。对这些方案,组织几乎无法自主选择是否实施和实施时间。

理解法规符合性的要点是它通常涉及到“自上而下”的方法。一般来说,有一个用于定义方案的“一刀切”模板,而您必须检查自己的产品和流程,并竭力让其符合这个交付给您的怪异模板。您不仅需要注意符合性方案的意图,更重要的是,如果不遵循它或未成功实施,可能招致法律或财务方面的后果(如果有的话)。

领会众多符合性方案的意图是我们理所应当的义务,但实施起来通常比较困难,并且可能无法达到预期目标。遗憾的是,许多方案意图并不具有强制意义(也就是说,不遵循这些方案,也不会直接导致法律或财务后果)。

我可以告诉您,作为患者,我很难描述 HIPAA 到底为我带来了哪些好处。我的感觉就是,每当我去看病时,都需要填写一大堆资料。更糟糕的是,它还可能带来意想不到的后果。是否有过需要将医疗信息从某个医生或机构转到另一处的经历?如果没有书面许可,则无论您是如何迫切需要获得这些信息,都不会提供给您!

关键是,从多方面来讲,一些符合性方案已成为可选方案。也就是说,您可以单独设计或修改您的流程或产品,以满足符合性方案要求。就像我经常问我的三岁孩子,“这个主意怎么样?”

相反,安全性是一种自下而上的方案(前提是要正确执行)。无论您是设计软件产品,还是设计组织的新网络体系结构,谨记三思而行。例如,设计产品体系结构时,良好的雏形不仅描述通信、本地化和版本等,还将描述从一开始就需要内置到应用程序的安全性元素(在整个开发过程中,您将继续对其调查和改进)。

如果使用继承的应用程序或体系结构(我相信大多数人都是这样做的),则执行此类深层安全检查同等重要,我在本专栏中也时常提及这一点。如果不了解其工作原理,怎么能了解它的安全级别呢?有关 Microsoft® 安全性开发周期 (SDL) 的详细信息,请参阅侧栏中的“SDL 资源”。

全局观念

记得在以前的有关培训中,我被告知安全性不仅仅是实施加密、访问控制列表 (ACL)、TLS 或公钥基础结构 (PKI)。真正的安全性在于从全局来了解:了解某协议的某版本为何被放弃甚至从不受支持;为何某项新探测可阻止中间人攻击;为何产品 v2 比 v1 安全得多,即使 v1 更快。此外,有必要了解您的基础结构的各个部分是如何组合的。

另一方面,符合性表示采用您的技术并确保您构建的基础结构符合特定标准。支付卡行业数据安全标准 (PCI-DSS) 或北美电力可靠性委员会 (NERC) 等部分方案的意图很好,可能会促进真正的安全性变革。但最后,面对可自由选择众多“符合性方案”,您需要调整自己的特定项目和有限的可用资源,从而削弱了安全性方案。

长期以来,安全性在软件开发中备受冷落。现在,我相信大多数组织仍未将安全性视为首要考虑因素。符合性方案之所以现在仍大行其道,就因为大家一致认为可以稍后再考虑安全性 — 以前这样,以后也很难改变。

足够好

最近,我换工作了。如今我为德克萨斯州奥斯汀市的一家小型创业公司工作,该公司正在开发一种应用程序白名单技术,与我们在 Winternals 通过 Protection Manager 产品开发的技术类似。我发现与客户交谈的一件非常有趣的事情,是他们认为自己当前技术的安全级别如何,或更具体地说,他们认为自己当前使用的技术使他们的基础结构处于怎样的安全级别。尽管一般来说多数基础结构是安全的,不会对安全漏洞敞开大门,但每次听到“系统足够安全”的评估,我都感到有点无话可说。

符合性方案比较有趣,您可以符合它们,也可以不符合它们。责任在您自己。不符合方案的后果通常为罚款、惩罚或从组织中除名。通常,这并不能完全确保发生实质性的改变。

如果是联邦强制要求的方案,我经常遇到这种态度,“只要使审核人员高兴即可”,或即使执行也不真正实现任何符合性框架,因为相关立法(如 HIPAA)并没有强制一定要实施 — 相当于不买保险就直接开车上路,虽然会省下一大笔开支,但后果难料。

安全性经常遇到同样的障碍,但依我所见,它至少更具体。作为开发人员或实施者,如果您主动告诉管理阶层在规范中不包含 foo 节会使产品更容易受到攻击,至少在交付产品后或完成部署后,您可以说“我已经告诉过您这种情况了”。对于符合性方案,我的经验是执行方案往往十万火急,而预算却非常有限。其目的只是符合方案的最低要求,因此,可能仅在形式上“达标”,实际上却完全不符合方案的精神。

定位

安全性和符合性资源

尽管听起来有点理想化,但我还是要说,您应该尽可能保证您的产品和组织的安全;事实上,许多符合性方案都是由于工程设计不佳(更多情况下是自鸣得意)导致的折衷结果。很多人都自我感觉良好。但是,在安全领域,“自我感觉良好”实在是太不明智了。我们 IT 专业人员应将符合性方案谨记于心,并尝试在精神和实施两个方面实现它们,还必须确保我们现在布置的基础结构不仅仅达到“可以达到”的安全级别,而是达到“必须达到”的安全级别。换句话说,符合真正的安全性,而不是仅仅符合方案。

后退一步,看看您构建的技术是一个商业软件还是一组您打算集成到大型系统的技术,这一点非常重要。我特别强调了解以下内容的重要性:系统的连锁部分、各个部分如何配合工作和带给系统的更大威胁。

根据您从事的行业,不同的符合性方案可能在您的工作中起到不同的作用。您可能在日常生活中涉及到符合性方案,也可能仅在设计新项目或开发新技术时才会有所涉及。或者,它们可能仅仅是您特别指定的符合性审查或审核工作的一部分。没关系。我并不认为应该忽略符合性方案,但是我希望您能够挑战现状,不是单纯地为了满足分配给您的符合性方案而工作;而是进行全面的安全性审查以完全了解您的技术,同时将其作为符合性审查的典范。

您会失去什么?

毕竟,关于未能满足符合性方案的惩罚似乎并不明确。缺乏符合性会给您带来风险,该方案恰恰就是要消除这种风险。后果有些飘渺而遥不可及,但它们都是真实存在的。这些后果也未必由您(个人)承担。我们的原则是要务实,但始终牢记最糟糕的情形。

如果从严格的安全角度来看同一事物,威胁是显而易见的 — 更重要的是,您应该能够立即判断出开放漏洞的潜在代价。

与我讨论此主题的许多人都强调过以下情况:由于符合性方案的解释经常模糊不清,因此有时执行不彻底。但是,执行安全审查之后,忽略安全就完全是另一回事了。忽略安全马上导致的威胁是显而易见的。如果看不到这些威胁,您可能要反思安全审查中涉及的人员;您可能缺少帮助发现解决方案中实际问题的关键团队成员。

去年主题再议

在去年以安全性为主题的专栏中,我讨论了“如何防止丢失数据”(technet.microsoft.com/magazine/cc162325)。一年过去了,更多的系统受到了危害,丢失了更多未加密的便携式计算机,还有更多个人信息落入了存在安全隐患的人手中。很难说是否取得了进步。为什么我们仍没有改进?项目的实施通常会拖延,预算拮据,资源几近透支,却试图在极短的时间内提供尽可能多的功能。

遗憾的是,这种环境使得最低工作要求成为标准。这当然不能确保解决方案的安全性或符合性,也不能确保该解决方案不会对项目的期限或成本带来严重危害。

从个人角度来讲,我坚信:

  1. 如果不愿意保护解决方案的安全,那么就不应该构建它。
  2. 每次增加新功能时,在开始之前就要设计安全性。
  3. 如果组织不愿意在工程设计过程中构建安全性(即作为设计中的一个步骤),您应该质问公司或组织的总体目标是什么。

组织拥有的客户或合作伙伴的个人数据越来越多,他们有责任保护这些数据的安全。遗憾的是,在我们生活的这个世界中,安全性往往不是公司的首要目标,员工也感觉不便质问组织在安全方面的努力。

如果安全性(而不是符合性)确实失败了,通常人们会惊呼“现在应该保护系统”了,“身份盗窃保险”成为一种标准责任策略,以安抚其个人数据和财务风险福利受到危害的客户、学员、患者和员工。

公司总是要求我们在极短的时间内完成太多的事情,但这些事情没有多大意义。但作为 IT 专业人员,我们有责任质问公司为什么不将安全性作为重点、管理阶层为什么总是仅在面临符合性方案或者安全性失败及其真实或潜在法律威胁(更可能是后者,因为它会为组织带来麻烦甚至是风险)时,才考虑安全性。

接受我的挑战

首先,我邀请您挑战现状。如果仅要求您实现符合性目标 — 请确保您的努力不应该只是浪费时间来符合别人所理解的安全性。务必确保您的目标是保护系统,同时,充分定义流程或您的基础结构以满足符合性方案。有关此主题的详细信息,请参阅“安全性和符合性资源”侧栏。

简而言之,请记住符合性通常不是实现安全性的途径。但是,如果能够合理实现和利用安全性,安全性却通常是实现符合性的一个途径。

Wes Miller 是位于德克萨斯州奥斯汀市的 CoreTrace 公司 (www.CoreTrace.com) 的高级技术产品经理。在此之前,他在 Winternals Software 公司任职,并曾在 Microsoft 担任项目经理。可通过电子邮件 technet@getwired.com 与 Wes 联系。

© 2008 Microsoft Corporation 和 CMP Media, LLC。保留所有权利;未经允许不得复制本文的部分或全部内容.