规划渗透测试的范围

规划范围是渗透测试中的很重要的一部分,这会决定你是否能做好这份工作：

定义一个应用测试范围最好的方法就是进行大量的测试来知道你已经花费了多少时间以及这时间是否足够

显然你能周复一周的进行重复的工作以及尝试去找一些0-day，但大多数客户不像会希望为此付费

在规划一个应用渗透测试范围的时候有大量的因素需要考虑：

应用的危险程度。个人博客所需的安全性不同于在线银行应用程序。
在哪里进行测试（现场/非现场）。不在场可以让你更有效率，因为你可以从你的团队获得帮助。除此之外，这种类型的工作更容易安排时间。
大概的IP地址数量，相关的系统，网站的页面和参数… 一切可以给你测试量的想法。
防火墙/入侵检测会使你的渗透测试慢下来。
如果渗透测试必须在生产的环境中执行（你得更小心，避免使用自动化工具）。
更新的数量需要送到客户和会议。每天减少一小时会减慢你的渗透测试进度。每天花一个小时开会，每周就相当于失去了一整天的测试时间（如果你考虑到准备会议、开会、发送更新、重新调整注意力这些因素的话）。
…

另一件要考虑的事情是，如果测试是针对第三方基础架构（Amazon EC2，Hosting公司）进行的。这可能会增加更多时间花费。

基于你对客户的一些了解，增加一些缓冲时间能帮你及时完成工作。比如，如果你知道环境在测试的第一天还没准备好，那就得保证把这段时间也包含在时间的规划中。

确保你保存着所有的信息，并把它提供给渗透测试工程师（可能那不是你）。用于访问应用程序的帐户也可能会被重复使用，而且你不希望别人测试这个应用程序，告诉你的客户这些：

一些好的客户（在接受请求之后）在测试过程中有时可能容忍一下…在这一步找到bug通常可以帮助你保持合约（然而你不想去破坏它）。

规划范围的会议

有时，规划时间范围有时会作为“规划范围的会议”的一部分被完成。如果这发生了，你需要做好准备：找到你能找到的任何文件，并仔细阅读。

这些会议也是提出尽可能多的问题的好机会：

许多客户认为，渗透测试人员是一群键盘牛仔（原文keyboard cow-boys）。看起来有组织且结构化将有助于让他们相信你：“他们正是适合这份工作的人”应该在你离开的时候留在他们的脑海里。

你还需要看起来聪明（不是自大，是聪明…），这是你正在尝试自我营销。你很聪明，你将会发现更多的bug，做得更好。当你销售渗透测试时，你就是销售你的脑力劳动时间。

如果你知道一些信息，可以尝试考虑威胁。如果你知道应用程序在做什么，想想所以你可以利用的恶意方式，并在会议里面讨论这些。

如果您掌握了所使用技术的相关信息，请确保您了解该技术，了解它，并了解影响该它的常见问题。如果在测试范围里他们有一个JBoss服务器，知道这个服务器最常见的问题是什么，你将会检查（他们也可能会问你）。

让我们看一个简单的例子，给你一个你怎样能/应该如何为给定的测试规划范围的主意…

让我们来找一个小公司的脆弱的网站。该网站很小，用于向客户提供信息，并允许他们通过contact form搜索网站和请求信息。这个应用程序非常简单，基于Drupal。有限的测试需要在网络层面进行，只有应用在测试范围内。

要进行这种测试，你需要2到3天的时间与一个人一起写报告来保证质量。这种渗透测试不能真正算两个人之间合作（但是它总是一个好主意，让其他人快速浏览一下，以确保你没有缺少什么明显的东西）。

如果你在Web应用程序发现和通用框架的指纹识别方面进行了一些自动化处理，就可以加快这种类型的测试（并缩短天数）。所以2或3天应该没问题。

开始你可以在渗透测试的时候做个列表：

一旦你练习几个月，可以要求做些“非官方”的范围规划。当一个客户出现时，在老练的渗透测试工程师正在做真正的范围规划时，自己进行范围规划（价格/天数）。然后比较这些数据并解释你是如何得出这个数据的。最后问问前辈是怎么得出这些数据的。

有时候，你还需要“教导客户”。尽管客户“永远是对的”，但一些客户并不总是对威胁有清晰的认识（或者这是他们的第一次购买渗透测试）。[如果你对客户很了解]，通常意味着需要采用不同的方法来看待测试。

例如，你的客户想要一个“Red Team”测试一个月。而且你知道，他们使用的没打补丁的系统到处都是，没有网络隔离，以及2009年用PHP编写的面向外网的应用程序。这或许意味着可以使用另一种测试的方法。举个例子，通过五天的渗透测试，关键系统和SOE图片5/10天的内部审计，并从这儿入手。

我希望这篇文章能够给你一些关于规划渗透测试范围的“艺术”的内容。当你开始你的职业生涯时，这似乎是一个非常艰巨的任务，但是可以通过练习变得越来越容易。