安全管理人员对以下情景一定不会陌生：尽管企业要求安全管理人员保护企业业务，以防受到应用程序安全漏洞的威胁，但在企业部署的数百个甚至数千个应用程序中，很少有应用程序进行了充分的安全评估。

　　面对大量可能不安全的应用程序、有限的评估资源和难以承受的压力，在对企业的应用程序进行安全评估这一问题上，许多安全管理人员只能疲于应付。随着应用程序迅速成为最受恶意攻击者青睐的载体，攻击者试图利用应用程序中的漏洞破坏企业的日常业务活动，或者渗透企业的防御体系以窃取敏感数据。因此，安全管理人员应该确保对应用程序进行安全评估。

　　本文将对几种应用程序安全评估技术进行分析，并对应用程序评估的策略范例进行比较，以进一步阐明企业应用程序安全评估流程。

　　专业的应用程序安全评估方法

　　对于不熟悉应用程序安全性的人来说，下面的三种评估方法可能会令他们晕头转向。不过，每种方法都有其值得称道的地方，适用于不同的评估类型。

　　运行时漏洞评估(Runtime Vulnerability Assessment)——运行时漏洞评估有三种方式：自动、手动和两者结合。一般来说，与手动评估相比，自动评估的速度更快，评估的范围更广。但是，自动评估往往会漏掉不明显的漏洞，也不能发现业务逻辑缺陷。因此，大多数经验丰富的应用程序安全专家通常倾向于采用自动和手动相结合的方式。

　　源代码审查(Source-Code Review)——利用源代码审查，评估人员可以发现应用程序中存在的各种漏洞，但该方法要求评估人员具有深厚的编程语言和安全功底，而且通常需要比运行时漏洞评估更长的时间。与运行时漏洞评估一样，源代码审查也有自动、手动和两者结合三种方式。这些方式各有利弊，类似于运行时漏洞评估的三种方式。

　　威胁建模技术(Threat-Modeling Technique)——威胁建模技术主要是从设计的角度评估相关的、理论性的应用程序威胁。通常情况下，威胁建模先于源代码审查和运行时漏洞评估进行。

　　然而，选择适当的评估方法组合并不容易。许多企业都深受这一问题的困扰。下面我们将介绍几种方法，以帮助企业确定适当的应用程序安全评估流程：

　　1、重点论法：或许，最传统的方法是集中测试资源评估公开程度最高的应用程序，例如使用最为广泛的面向Internet的Web应用程序。一旦确定了公开程度最高的应用程序，评估人员就可以对其执行全面的自动和手动运行时漏洞评估。然而，这种方法忽略了其他虽不显眼但却重要的应用程序，例如企业外部网应用程序、内部财务应用程序和关键的内部网站应用程序。

　　需要指出的是，尽管面向Internet的应用程序十分流行，但也往往容易受到外部攻击。而且，由内部威胁和客户端漏洞引起的风险也与日俱增。因此，忽略内部应用程序的安全性将会导致巨大的风险。此外，许多应用程序安全专家认为，单纯的黑盒测试的效果不如源代码审查与黑盒/灰盒评估相结合的方式。

　　2、两点论法：通常情况下，当认识到重点论法带来的风险以后，企业便会改弦更张，在较长的一段时间内将全面的测试计划扩展到更多的应用程序上。我们已经看到，有些企业聘请了渗透测试团队，对企业的每个Web应用程序进行测试。可以想像的到，只有少数企业有实力采用这种方法。更为重要的是，对于那些尚未被立即测试的应用程序来说，在完成测试和漏洞修复之前，它们可能会受到攻击，而测试和漏洞修复往往需要一年甚至更长的时间。

　　3、应用程序风险程度分级法：一个可取的方法是根据多个因素对应用程序的风险程度进行分级，这些因素包括基于应用程序风险程度的各种评估技术。在开始介绍该方法之前，我们先来看一下每个应用程序的以下方面：

　　应用程序的目的：该应用程序要用来干什么?有多少人使用它?显然，一个电话簿应用程序的风险程度不会高于一个财务应用程序。

　　数据风险：该应用程序是否有机密性和完整性要求?该应用程序或运行该应用程序的服务器是否需要提供99.999%的可用性?该应用程序是否受任何合规性法规(例如支付卡行业数据安全标准PCI DSS、健康保险流通与责任法案HIPAA等)的影响?

　　架构与设计：该应用程序属于Web应用程序还是Web服务，是运行在客户端/服务器、大型机、中间层、台式机还是其他地方?该应用程序是面向Internet还是企业内网的?该应用程序是使用何种程序设计语言、在什么框架下开发的?该应用程序是否使用了任何已知的高风险组件(例如Ajax或PHP)?该应用程序的规模大约有多大(以源代码的行数计)?

　　现有安全功能：该应用程序已经具有哪些安全功能?例如，该应用程序如何执行身份验证、授权、输入验证等?

　　采用这种方法，确立为上述各个因素赋以相应的风险值的准则至关重要。例如，“面向Internet的应用程序加25分”，“不共享数据和不与任何其他应用程序交互的应用程序减5分”，等等。最终的结果是，每个应用程序获得一个表示其风险程度的数值，你可以根据该数值对应用程序的风险程度进行分级。需要记住的是，分析应用程序往往十分耗时，而且难以完全准确。因此，你应该尝试设定一个采集应用程序信息花费时间的上限，而不是强迫自己采集所有应用程序的所有信息。你的评分方法应该接受不完全准确的信息，并能够将这些应用程序的风险程度区分开来，即使你对这些应用程序的安全性有比较透彻的了解。不要过分迷信评分系统——如果安全专家认为一个应用程序的风险程度很高，而评分系统的结果与安全专家的意见不一致，则应以安全专家的意见为准。

　　对于高风险等级的应用程序，首先应该对其进行威胁建模，然后进行手动和自动运行时漏洞评估与源代码审查。对于中度风险等级的应用程序，应该对其进行手动和自动运行时漏洞评估与源代码审查。对于低风险等级的应用程序，可能只需对其进行自动运行时漏洞评估。如果时间允许，还可以对其执行手动运行时漏洞评估。如果低风险等级应用程序的测试结果特别糟糕，则应该对该应用程序进行更加全面的测试。

　　4、健康检查法：一种替代常规风险程度分级法的方法是，采用手动和自动相结合的方式，对所有应用程序执行为期一天的短期运行时漏洞评估。在这种情况下，评估人员可以将自动扫描限制在较少的测试用例中，从而可以显著减少扫描时间(通常约为一个小时)。为此，需要减少每种攻击类型的测试用例的数目，例如10个跨站点脚本攻击、10个SQL注入攻击等等，这一点非常重要。如果采用健康检查法，则需要对扫描结果进行审查和验证，甚至还可能需要花费额外的时间执行有限的手动测试。经验丰富的评估人员根据测试结果可以确定，究竟是优先对该应用程序进行额外的测试，还是将额外测试推迟到风险等级更高的应用程序评估完成之后进行。

　　5、未经身份验证的健康检查法：另一种健康检查方法是不需要提供身份验证凭据，在很短的时间内对所有应用程序执行为期1至2天的短期自动运行时漏洞评估。这种方法类似于脚本小子(script kiddies)和工具小子(bots)所使用的攻击方法，例如一直困扰Web应用程序的、臭名昭著的ASP SQL注入工具。当获得身份验证凭据极为困难或耗时时，可以考虑采用未经身份验证的健康检查法。但需要注意的是，通过身份验证的用户可能导致非常严重的风险，而未经身份验证的扫描将会漏掉所有针对这些漏洞的攻击。

　　那么，究竟采用什么方法最好呢?通过协调应用程序安全评估与业务风险评估，企业可以更好地安排时间和资金。多种方法相结合的方式是最合适的：立即确定风险等级最高的一小部分应用程序(例如公司网站的Web应用程序)，并对其进行全面测试。与此同时，对应用程序风险程度进行分级，以确定应该对哪些应用程序执行进一步的测试。如果测试资源允许的话，在对应用程序风险程度分级的同时，开始执行未经身份验证的健康检查评估。采用这样的评估流程，你可以获得对应用程序的全面分析和快速扫描的客观结果，从而准确了解应用程序的安全性。接下来的评估流程与常规的应用程序风险程度分级法类似：先测试风险等级最高的应用程序，再测试风险等级较低的应用程序。

　　当然，评估只是整个应用程序安全体系的一部分，接下来的重要步骤是漏洞修复。幸运的是，应用程序风险程度分级为确定漏洞修复的优先顺序奠定了基础：从风险等级最高的应用程序中风险最高的漏洞开始，依次解决各个风险等级的应用程序中存在的漏洞。此外，优秀的应用程序安全评估团队还能找出应用程序漏洞的根源，并在软件开发生命周期中提出修复建议，从而使应用程序从源头上更加安全。

　　需要强调的是，无论你采用何种应用程序安全评估方法，都比对不安全的企业应用程序引起的许多风险视而不见要好得多。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。