应该首先保护哪些应用程序

■铁生

应该首先保护哪些应用程序

■铁生

大多数企业IT环境中可能有数百个、乃至数千个应用程序。它们极有可能是在过去10年或20年编写、更新和打上补丁的。你可能对那些应用程序并没有做好足够到位的安全工作，在人们不知不觉当中，安全这笔债很快会堆积如山。

不妨看一看应对这个挑战的若干糟糕战术：

第一个糟糕战术：只保护面向外部的应用程序。

这是最常见的战术之一。由于资源有限，企业的团队专注于面向外部的应用程序，这绝对是采用的最糟糕战术之一。某个应用程序是否暴露在互联网面前，这仅仅是决定应用程序“内在风险”的诸多因素当中的一个。如果这是你唯一要考虑的因素，那么大量的时间和精力就会耗费在对贵企业来说风险不是那么高的应用程序进行深层安全审查的工作上。相反，应该考虑数据的敏感性、业务职能有多关键、用户群体及攻击者群体的数量和技能以及其他风险因素。

第二个糟糕战术：每次只面对一种应用程序。

大多数方法试图每次只面向一种应用程序来处理应用程序的安全。当你对应用程序执行深层安全分析时，许多时间浪费在了很小的安全漏洞上，而这些安全漏洞不太可能让企业倒闭破产。每年，有更多的应用程序和更多的攻击途径需要考虑。所以，每年，安全团队要做的工作越来越多。每次面向一种应用程序这个做法根本不具有可扩展性。相反，应专注于如何杜绝你所有应用程序面临的最重大漏洞。

第三个糟糕战术：进行年度安全测试。

许多企业采用了“每年一次”或“每三年一次”的应用程序安全测试计划表。这种方法需要为新的应用程序、旧的应用程序、云应用程序和产品等制定一套复杂的计划调度流程。如今新的安全漏洞和攻击手法层出不穷，因而这种方法面临极高的风险。新的代码库漏洞可能会让应用程序完全暴露无遗，直到下一次审查才有所发现。新的安全漏洞往往迅速添加到黑客工具中，并成为广泛的扫描活动的一部分。另外，现代化软件开发流程每周或每天在发布代码，而不是每年发布。安全必须加快跟上来。

第四个糟糕战术：只保护关键应用程序。

另一种可能性是仅仅专注于关键业务型应用程序¯¯要是这些应用程序完蛋，业务就会随之瘫痪。考虑可能给业务造成的实际破坏是明智之举，但是这通常仅仅牵涉一小批应用程序。在许多企业，应用程序安全团队不堪重负、人手不足，他们的扫描方法并不具有可扩展性，处理不了任何更多的应用程序。遗憾的是，许多现实世界中的泄密事件是从不太重要的应用程序中招开始的(比如索尼事件)，随后向更重要的系统扩散和蔓延。即使“小册子软件”网站遭到攻击，那也将是需要收拾的烂摊子和公关灾难。

所有上述战术没有一个支持迅速确保应用程序安全这个更广泛的战略，而且与现代软件开发不兼容。我们需要这样一种方法：可以适用于我们的全部应用程序组合，跟得上现代软件开发的步伐，而且首先关注最大的风险。好消息是，我们可以充分利用持续集成和持续交付等诸多理念和技术，打造一种不同的应用程序安全流程，快速、准确、简单。

正确的问题：你的应用程序有安全仪表化机制吗?

仪表化让你可以直接从应用程序收集安全信息，无需扫描、破解或任何其他额外的步骤。如果你的应用程序实现了仪表化，它们可以测试自己，不断报告其状态。这彻底改变了应用程序安全的规模问题。你没必要去扫描所有应用程序，它们会测试自己，不断地报告给你。

下面是证明仪表化魅力的一个例子。比方说，你关注的最重要的安全问题是SQL注入;你已规定，开发人员只可使用参数化查询。很容易用数据库接口中的一些安全仪表化机制来证实这一点。比如说，你可以对MySQL库实现仪表化，报告非参数化查询的使用。只要把类路径(classpath)上的StatementImpl的这个版本放在实际版本前面。

虽然这是个很不起眼的例子，但颇有说服力。把这个仪表化版本推送到你的MySQL库中心，很快你就有了一个完整的图，可显示贵企业中的所有非参数化查询。设想一下：你可以用应用程序组合的安全仪表化来实现什么。

这就是区别。仪表化应用程序会证实自己的安全，并将问题报告给你。最简单的好处是完整的应用程序清单。你还可以证实第三方库是最新的，不存在已知的安全漏洞。仪表化还可以确保配置文件得到了适当的保护。更复杂的仪表化可以查明复杂的安全漏洞，以及你想对企业代码库了解的几乎任何方面。它还持续适用于企业规模。

试图查明先保护哪些应用程序只会浪费资源。相反，应该花时间打造你的安全仪表化能力。下一个Heartbleed或Shellshock出来后，你没必要扫描任何东西。你只要进入到仪表板，搜寻受影响的版本，发送警报给受影响应用程序的项目负责人。你还能看到他们具体何时全部升级。