应用程序「设计安全守则」

应用程序「设计安全守则」


Foundstone亚太总监 陈彦铭　　2004/02/09


在上周提到，应用程序的安全问题应该要从整个开发流程着手才能根本解决问题。现在，我们更仔细思考在开始一个系统开发之前所应该要作的准备工作，以及在设计阶段所需要注意的问题。
软件开发流程中，在流程后期所发现的问题修补起来所花的代价，将比在流程前期所发现的问题修补代价来的高。现今许多国外企业已经知道产品开发后要透过不同的测试方法，已找出安全问题，即便如此，还是有不少企业并未重视将安全融入整个开发流程的观念。因为许多企业可能连产品的开发质量与时程都已不易掌控，更遑论谈安全性的考虑。
随着软件委外开发的盛行，这类的问题只可能会更严重而已。安全的软件开发流程是可以经由适当的教育训练之后，再加入现有的软件开发流程，或是由专业人士协助改进现有流程以达成目的。
准备
在准备开始产品开发前，企业除了计划好所需的产品开发资源，包括人力、任务编组、财务预算以及时程之外，也应就此产品的特性，以及所可能带来的风险进行分类与评估，以决定应该投入于安全方面的资源数量，然后再决定所要执行的步骤。此类的安全评估通常需要依赖专业人士的经验与知识，并融合企业本身文化与产品需求来达成共识与结论。
举例来说，一个在线银行系统所需要投入的安全资源就会比同一家银行内部的人事系统来的多，因为在线银行隐含的风险可能比内部的人事系统更高(例如：企业声誉损失)。因此事前建立适当的系统与数据分级制度和风险评估是很重要的第一步。
设计
设计阶段等于是替整个产品制作一份开发蓝图。在这个阶段中，产品开发者需要事先收集各项要求，再将要求集合成为设计文件然后开始定义产品所需的各项功能，以及接下来的开发方式与进度等。到目前为止，市面上已有不少工具协助软件设计，但是还没有一项工具能协助开发者设计安全的软件或产品。因此，这个阶段还是得透过经验累积的知识与方法。比较被接受的方法是所谓的 「Threat Modeling」－也就是「威胁模型分析」。
「威胁模型分析」基本上是在产品设计好之后，利用其所产生的「Data Flow Diagram」观察产品里的数据流，同时根据几项原则 (STRIDE) 找出可能的潜在威胁，然后再一项项根据重要性进行修正。举例来说，先前微软在推动产品安全项目时，即采用这项原则并依此再开发出一系列其它的方法，以增强软件开发时的安全性。大多关于威胁模型分析方法的使用都可以在 "Writing Secure Code 2nd ed." 这本书里面找到，今年初可能会有另一本书专门描述这项分相方法，且让我们拭目以待。
我们另可以利用现有的软件开发辅助工具，在软件设计阶段增加安全度。UML 是常用的辅助软件设计开发的工具。前述的威胁模型分析里面用的 「DFD」也是 UML 的一部分。另一项常用的是建立 「Use Case」。本来 Use Case 是在描述产品的使用情境，但是若从攻击者的角度来想，Use Case 可以变成 「Attack Case」，用以描述可能发生的攻击与攻击者的角色。
另外，若针对所谓的「CIA」原则来作考虑，就已可以大大改进产品设计时，因为不注重安全问题所造成的瑕疵。CIA 原则内含Confidentiality (机密性) 、Integrity(完整性) ，以及 Availability
(存活性)等核心。在完成产品设计初阶段后，开发小组应该自行或是经由专业顾问协助，进而对整体设计拟定一个全盘评估计划。检查设计的每一个环节是否有考虑到「CIA」原则，如果有，那设计时要如何实现？等到实现完成后又要怎么验证？在产品开发完成且进行配置时，又要如何确保安全？这些问题与之后开发流程中，各个阶段的步骤与评估方法都是应该在设计阶段时构思好，以便由接下来的开发（development）流程接手。
结语
开发流程纳入安全考虑，就好比开餐厅时必须达到一定安全需求，不管是环境 (逃生安全) ，抑或是烹煮步骤与食材(卫生安全)，当有了这些要求，才能确保餐厅在每个环节都达到标准，并且制造出安全、美味的食物。同样的，如果可以在产品或软件开发流程中，加入安全性方面的考虑，才得以帮助企业开发安全的软件与产品，消灭可能潜藏的安全风险。安全问题就像生病一样，如果能及早发现，治愈的机会也就越大。