坚不可摧：Oracle的安全性承诺

　　为什么坚不可摧？
　　坚不可摧！是Oracle 从2001年11月开始展开的一场声势浩大的市场宣传活动的主题。其中的安全性部分涉及了Oracle的14个独立的安全性评估。
　　
　　这样粗线条的描述引伸出许多的问题：
　　 (1)如何断言坚不可摧！安全性专家经常说安全性是一个过程，而不是一个结果。而且，每一个软件产品都存在缺陷，其中也包括安全性缺陷。
　　 (2)为什么声称坚不可摧？安全性专家并不希望成为黑客的目标，一些黑客也认为这可能是Oracle的策略，以获得免费的”安全性研究”。
　　 (3)坚不可摧的真正含义是什么？如何使供应商和顾客了解一个产品的安全可靠性，以及这种安全性是否在每一次的版本升级中持续不变。提供安全可靠的软件是非常艰巨的任务，更不用说坚不可摧了。
　　什么是坚不可摧？
　　坚不可摧是Oracle对我们的客户群体在生产，分布和支持等各环节向企业提供最安全的关键性软件所做出的承诺。
　　 坚不可摧是我们在过去，现在和将来对我们的客户所做出的安全性承诺。
　　 坚不可摧不是三个星期，或者半年的市场宣传；坚不可摧是建立在经过十年考验的安全的数据库的基础之上的。
　　 坚不可摧将我们的核心产品的安全开发过程扩展到整个Oracle的产品系列中。
　　
　　坚不可摧的反义词是什么？
　　简单地看，“坚不可摧”似乎是市场部轻率的举动。毕竟，没有哪家企业希望成为黑客的目标，许多的黑客是非常聪明和坚韧不拔的。毕竟，没有哪个产品是完美的。
　　
　　愤世嫉俗者和持否定态度的人可能会为坚不可摧寻找一个代名词，它是许多供应商对于他们骗售给他们的客户群体的缺乏安全性的软件的满意度。
　　 (1)“有些安全性”并不足够好。
　　 (2)“我们所创造的并且作为产品每六个月发行的安全性”并不恰当。
　　 (3)“补打了12个最新的安全性补丁程序的安全性”是不光彩的。
　　
　　许多的供应商从没有梦想过它们是坚不可摧，因为他们在其产品的安全性上，甚至可扩展到在其客户的系统上付出的是最小的努力。他们并不关心，但它显示着。他们并不关心，但它从多个方面增加其客户的成本。
　　 (1)运行缺乏安全性软件增加“黑客保险”的保险费
　　 (2)忽视基本安全性机制所导致的由病毒引起的数十亿美元的损失
　　 (3)对于把安全性作为事后追加的补救措施的安全性产品，为它追加各种补丁程序所增加的成本
　　
　　坚不可摧是Oracle基于多种原因所做出的郑重承诺：
　　 (1)安全性的重要性。9.11唤起了人们对信息安全性如同物理安全性同样的重视。最终的恐怖袭击可能是隐藏在暗处的一些人通过某种设备对计算机系统发动的袭击，它可以彻底摧毁我们关键的基础实施。
　　 (2)企业信誉。Oracle的最初的客户都是那些在安全性方面在世界上久负盛名的企业。从公司成立至今二十五年来，我们的核心客户群体始终包括那些在世界上由于安全性而久负盛名的企业。我们在安全性上的良好声誉是我们的资产，如果我们不是坚不可摧，我们将失去这些资产。
　　 (3)节约成本。有人说“现在付款，或将来付出代价”对安全性是十分贴切的。不论是对客户还是对我们自己而言，如果Oracle从一开始就把安全性认真的解决好，而不是当既成事实之后再想办法补救，都是最划算的。
　　
　　对于那些嘲讽坚不可摧只不过是市场噱头的人应该自问一个问题：为什么并不是每个供应商都在安全性上承诺坚不可摧呢？
　　
　　坚不可摧为信息技术领域的所有供应商建立了一套必须遵守的标准：即使Oracle今天不能把所有事情做得很完美，但我们的安全性可以比竞争对手做得更完善，客户正是基于此决定购买我们的产品，安全性将在整个行业中得到改善。坚不可摧不仅是我们对我们的客户群体所做出的承诺，它还是我们的承诺，如果这样做，我们将在整个行业中改善安全性。
　　
　　坚不可摧包含那些因素？
　　坚不可摧软件的一个关键因素是对保证的独立评定，即通过一系列正式地安全性评估，一个第三方组织可以证明我们的产品安全性声明是有效的。对保证的独立评定是坚不可摧的关键因素，因为，从安全性的角度出发，你如何建立自己的产品比你建立了何种产品更为重要，而且，只有当你了解了“如何建立”，“何种产品”才是有效的。
　　坚不可摧的第二个因素是对安全产品生命周期的承诺。保证是生成和维护生命周期的重要部分；实际上，为了建立安全性的正确性，你必须保证安全产品的开发过程是可重复的，从而可以保证在追加新的功能的同时没有破化原有的安全性机制。正如Gartner Group的John Pescatore所说：安全性不在软件中“测试”，它应该在需求分析和计划等最初阶段就作为最优先的问题加以考虑。
　　
　　下面的章节将详细介绍Oracle的信息保证测定和安全产品的生命周期。
　　什么是信息保证？
　　随着互联网的发展，信息安全性的重要性也日益增长。企业信息的存储，管理，以及对数据库的访问都迅速增长，而且访问这些数据库的产品和工具也急剧增长。同时，随着客户将他们的企业推向网络，互联网增加了软件产品开发的速度。
　　
　　在这种环境中，许多供应商都力求尽可能快地在他们的产品中追加新的性能和功能，但他们几乎都忽略了这些性能的安全性。这些供应商可能会在推出产品之前进行一次粗略地安全性检测，但是产品发行的主要因素是在产品发行之前可以装填多少新的功能？而不是利用我的产品如何保证客户系统的安全。从反面看，对正确实施的强有力地安全性的需求也恰好在更多的进入市场的时间强制去迎合它时开始增长。网络化的企业增加了许多安全性的冒险，这是因为最新（而且可能是极少安全性）产品正在保护更加成熟的后台数据存储，而且因为进入市场的时间的压力对于面向网络的产品是空前巨大的。
　　
　　在这种环境中，对于信息保证的需求? 即，证明产品的安全性机制是正确的和形成良好的? 是极为重要的。不然，客户在供应商的市场部将显得不知所措：即使某些供应商可能每两天半就会发布一次安全性警告。所有的供应商始终都会声称他们的产品是安全的，能够证明供应商的安全性声明的主要手段是按照国际基准，采取独立的（即第三方）正式的安全性评估。这些基准可以被看作是下面问题的定义，即“你的安全性宣言的含义是什么？”只有一个独立的安全性评估才能证明供应商的安全性宣言的正当性，因为所有的供应商都会声称自己的产品是安全的。让它有所不同，正式的安全性评估是使供应商在安全性宣言的问题上做到“投入与宣传相符”的一个途径。
　　
　　正如许多消费者不会购买没有Underwriters’ Laboratory™(保险业实验室)评定或没有咨询顾问的消费者报告的产品或设备一样，消费者也不会购买没有独立安全性评估的关键的软件。
　　
　　历史上，曾由一些特定国家的评估基准，然而过去几年的趋势更趋向国际化。例如，共同基准是一个国际标准化组织（ISO）标准（15408），许多国家不仅同意共同基准，而且，通过相互认证还接纳在其他国家举行的共同基准评估。今天，Oracle只在我们的服务器产品上实行共同基准评估，和联邦信息处理标准（FIPS）-140评估，它对于暗号化模块有效。
　　
　　信息保证的独立测定也需要经过美国联邦政府的认可。联邦策略指示，即国家安全性电信信息系统安全性策略（NSTISSP）11号，需要涉及国家安全性的信息系统应具有独立测定的保证，如共同基准评估或FIPS-140评估。在后911时代，按照NSTISSP #11的要求，对于这种评估的放弃很难获得国家安全局的批准。
　　
　　在正式的安全性评估方面，Oracle无疑在该市场处于领先地维，在过去的十年中，对于每一个主要的世界级基准，它共经过十四次独立的安全性评估。坚不可摧的安全性宣言正是建立在Oracle数据服务器的十四次安全性评估所提供的独立测定保证的基础之上，它面向了每一个主要的世界级安全性评估基准，包括共同基准(ISO-15408)，该基准实际上是世界级的评估标准。
　　
　　这些正式的独立安全性评估为Oracle，同时也为我们的客户带来了许多益处。
　　 (1)更安全的产品。在评估过程中，安全性评估机构会发现安全性的薄弱环节，而作为完成评估的条件之一是这些薄弱环节必须得到改善。
　　 (2)可获得验证的安全性开发过程。一个正式的安全性评估包括对开发过程的回顾，其中包括产品安全性架构，功能规范，设计规范，测试规范以及实际的测试过程。安全性必须是这些过程的集成，而且是可重复的，以获得和维护安全性评估。
　　 (3)安全性文化。Oracle对安全性评估的义务的最有价值的结果最终是“安全性文化”。安全性不是一个功能的追加，它从一开始就植根于我们的产品，而且到现在经过十余年的时间，它始终坚持正式的安全性评估。
　　
　　正式的评估是我们的安全产品生命周期的一部分，在这十四次安全性评估当中，Oracle每次都要在安全性方面追加$1,000,000的投资，以保证其安全性机制是正确的。这些成本还不包括多年来在强化我们的产品过程中所追加的特性和功能。
　　
　　Oracle很少做正式的产品“风险评定”，该部分内容将在本文的以后章节介绍。随着时间的推移，当产品趋向更长产品生命周期的成熟时，我们希望“风险评定”的内容能够融合到与安全性相关的更正式的评估当中。
　　
　　安全的产品生命周期
　　除了前面提到的保证的评定之外，坚不可摧还包括一个Oracle范围内的对安全产品生命周期的承诺。安全性不是在产品完成之后“宣传”出来的，它必须镶嵌在产品的开发和交付过程的各个环节。安全性必须是一个企业DNA的一部分，应该在产品的开发和交付的各个环节融合到组织的结构当中。
　　
　　Oracle的安全开发过程包括下列所有因素：
　　 (1)安全的编程标准
　　 (2)对功能，设计，和测试规范的安全性模板
　　 (3)安全性复原检测
　　 (4)

查看本文来源