1.2 渗透测试方法
行业里有一些进行渗透测试的建议步骤。第一步是找出项目的起始状态。最常见的用来定义起始状态的术语有黑盒测试 (black box testing)、白盒测试 (white box testing),或是介于二者之间兼具二者特色的灰盒测试 (gray box testing)。
黑盒测试假定渗透测试人员先期对目标网络、公司流程或应用提供的服务没有了解。启动黑盒测试项目需要做大量的侦察,而且还需要长期跟踪。因为现实中的攻击者在发起攻击前可能会对目标进行长期学习。
作为专业安全人员,我们发现在确立渗透测试范围方面,黑盒测试存在一些问题。我们很难估量侦察阶段会持续多长时间,它完全取决于系统和你对环境的熟悉程度。这通常会带来计费问题。大多数情况下,客户都不会同意给你留一张空白支票让你在侦察阶段花费无限时间和资源。但如果没有投入足够的时间,你的渗透测试在开始前就已经失败了。而且这么做也不现实。动机明确的攻击者不可能跟专业的渗透测试人员面对相同的测试范围和计费限制。这也是为什么我们推荐灰盒测试而不是黑盒测试的原因。
白盒测试是当渗透测试人员对系统非常熟悉时采取的方法。白盒渗透测试的目标是明确定义好的,而测试报告的结果通常是有预期的。测试人员会接触目标的详细信息,如网络信息、系统类型、公司流程和服务等。白盒测试通常关注的都是某个特定业务对象(如满足特定需求),而不是普通评估。因此它持续的时间一般较短,具体取决于目标空间的限制。白盒测试任务可以降低信息收集(如侦察服务)的成本,从而降低渗透测试的费用。
公司内部的安全团队通常会执行白盒测试。
灰盒测试介于黑盒和白盒测试之间。它通常出现的情况是,客户或系统所有者同意:在侦察环节中最终会发现一些不确定信息,但渗透测试人员可以忽略这部分信息。渗透测试人员会知道目标的一些基本情况;不过,系统内部工作原理和其他一些受限信息仍然不会公开给渗透测试人员。
真实的攻击者会在对目标实施攻击之前收集目标的一些信息。大多数攻击者(脚本小子或是下载并运行工具来执行攻击的那些人)不会选择随机目标。他们的动机都非常明确,而且他们通常会在尝试攻击之前跟目标进行一定程度的交互。对许多专业安全人员来说,灰盒测试是进行渗透测试的一个很有吸引力的选择,因为它跟攻击者实际采用的方法相似,而且侧重于发现漏洞过程而非侦察过程。
工作范围中定义了如何启动和执行渗透服务。启动渗透测试服务的过程应该包含信息收集的环节——用于记录目标环境并定义任务的界限(以避免不必要的侦察服务或是攻击任务范围外的系统)。完整定义的工作范围能够帮助服务提供商避免范围蔓延(即项目的范围不受控制地变更或是不断地扩大)、在期望时间内开展工作,并能在执行任务时提供更精确的结果。
真实的攻击并没有界限,如时间、资金、道德准则或是工具方面的界限。这也就意味着对渗透测试的范围进行限制可能无法匹配实际的场景。跟限定范围相比,如果渗透测试在攻击到关键的系统之前就已经结束,那么不设定范围可能永远也不会测试到关键漏洞。举个例子,渗透测试人员可能会以截获发往关键系统的用户凭据并成功访问这些系统来收尾,那么他就会漏测这些系统是否容易遭受网络攻击。在工作范围中加上哪些人应该知悉渗透测试也很重要。真实的攻击者可能会随时发起攻击,而且很可能是在人们最放松警惕的时候。
确立渗透测试工作范围的基本条件如下。
目标系统的定义 。用以指定应该测试哪些系统,其中包括目标在网络中的位置、系统的类型以及这些系统的商业用途。
执行工作的时间表 。测试应该何时开始以及何时达到特定目标的时间表。最佳实践是不要将时间范围限制到办公时间内。
如何测试目标 。允许/不允许采用什么类型的测试方法?如扫描或漏洞利用。允许采用特定测试方法会引入什么样的风险?如因渗透测试中的尝试导致系统变得不可用会造成什么影响?例子包括扮成员工使用社交网络,对关键系统实施的拒绝服务攻击,或是在被攻陷的服务器上执行脚本。有些攻击方法可能更容易造成系统破坏。
工具和软件 。在渗透测试过程中会用到哪些工具和软件?这很重要,但依然存在争议。许多专业安全人员认为,如果他们透露了自己的工具,就相当于泄露了自己的秘密武器。我们认为,除非你想采用广泛使用的商业产品并将这些产品输出的报告拼凑之后重新包装,否则就应该将用到的工具告诉客户。某些情况下,如果会利用漏洞,甚至应该告诉用户利用漏洞时使用的工具中对应的命令。这样漏洞利用就可以被重现,从而使得客户可以真正理解系统是如何被攻破的,以及发现该漏洞的利用有多难。
被通知方 。谁知道该项渗透测试?是否提前通知到他们了?他们能在渗透测试开始前准备好吗?对渗透测试的响应是否是测试工作范围内说明的?如果答案是肯定的,那么在渗透测试开始前不通知安全运维团队就合乎情理。在对托管到第三方(如云服务提供商)的Web应用进行渗透测试时,这一点非常重要,因为服务提供商可能会受渗透测试的影响。
初始访问等级 。在开始渗透测试前,你得到的是什么类型的信息和权限?渗透测试人员是通过互联网和/或局域网来访问服务器吗?最开始给你的是什么账户等级的访问权限?这个测试是针对每个目标的黑盒、白盒或灰盒任务吗?
目标空间定义 。它会定义渗透测试中需要覆盖的指定的业务功能。举个例子,对销售使用的某个特定Web应用进行渗透测试,而不要动由同个服务器托管的其他应用。
标识关键运营区域 。定义渗透测试中应该避让的系统,防止渗透测试给其带来负面影响。在用的身份认证服务器超过它的上限了吗?在开始对目标进行渗透测试前,明确关键资产非常重要。
对退出的定义 。说明渗透测试对系统或进程的危害到什么程度很重要。数据应该从网络上删除,还是攻击者只是获取特定层级的非授权访问即可?
交付的结果 。期望的最终报告是什么类型的?客户指定在完成渗透测试服务合约时应该达到什么目标?要确保目标不是无期限的,避免期望的服务出现范围蔓延。数据是分类数据还是为特定人群设定的?最终报告以什么形式交付?跟客户交付一个样板报告或是阶段性更新也很重要,这样在最终报告中就不会存在太大的分歧。
对补救的期望 。记录漏洞时要把可能的补救措施一起记录下来吗?在执行渗透测试的过程中如果导致某个系统不可用了应该通知谁?许多渗透测试服务都不包括针对发现的问题的补救措施。
应该用于定义服务范围的一些服务定义如下所述。
安全审计 。通过一组标准或基线来评测系统或应用的风险等级。标准意为强制规则,而基线意为最低的可接受安全等级。在安全实施中,标准和基线也还是沿用前面的定义,并且都会因行业、技术和过程的不同而不同。
大多数针对审计的安全需求都集中在通过一些官方审计(如准备应对公司或政府的审计)或是证明基线需求已经满足了一组规定的强制规则(如遵循HIPAA和HITECH在保护医疗记录方面的规定)。告诉潜在客户,如果在服务结束后审计未通过,你的审计服务还会附带提供一定的保险或保护,这很重要。还有记录审计服务中包含的补救类型也很重要。换句话说,你是否要在找出问题时提供补救措施方案或是修复问题。合规性审计远不止运行一个安全工具。它非常依赖标准的报告以及是否遵循了对该审计来说是可接受标准的方法。
许多情况中,安全审计会带给客户一种对安全的误解,即安全取决于审计的标准或基线。许多标准和基线的更新过程都会很漫长,以至于无法跟上今天网络世界中发现各种威胁的速度。我们建议你提供的安全服务要超过标准或基线要求的内容,以将目标的安全等级提高到一个能防范现实中威胁的可接受水平。服务还应该包括跟进客户、辅助他们落实补救措施,以将他们的安全水平提高到行业标准或基线之上。
漏洞评估
。在这个过程中,专业安全人员会扫描网络设备、操作系统和应用软件,以便找出已知或未知的漏洞。漏洞可能是空白、错误或薄弱环节,具体取决于系统是如何设计、使用和保护的。如果漏洞被利用了,可能会导致非授权访问、权限提升、对目标系统的拒绝服务攻击,或者其他后果。
漏洞评估通常会在发现漏洞后立即停止,也就是说渗透测试人员不会对其执行攻击以验证它是否真实存在。漏洞评估交付的结果包括跟找到的所有漏洞相关的潜在风险以及可能的补救步骤。有很多解决方案,如Kali Linux。它可用来基于系统/服务器的类型、操作系统、开放的通信端口和其他方法扫描漏洞。漏洞评估可能是白盒、灰盒或黑盒,具体取决于任务的特性。
漏洞扫描仅在计算风险时有用。许多安全审计的缺点在于漏洞扫描的结果会让安全审计的任务加重许多,却没有提供任何实际价值。许多漏洞扫描器会报出假阳性的漏洞,或是找出并不存在的漏洞。出错的原因是它们未能正确识别操作系统,或是只能识别修复漏洞的特定补丁而不能识别累计补丁(聚合多个小补丁的大型补丁)或是软件的修复版本。将风险和漏洞对应起来可以为系统的易攻击性提供一个真实的定义和判断。许多情况中,这意味着自动工具生成的漏洞报告需要人工检查一下再提交。
客户还会想知道跟漏洞关联的风险以及降低发现的风险的预期成本。要想提供具体的成本值,理解如何计算风险很重要。
风险计算
理解如何计算跟找到的漏洞相关联的风险很重要,这样才能做出具体如何处理的决策。多数客户在决定风险的影响时都会参考CISSP的CIA三角。CIA分别指特定系统或应用的机密性(Confidentiality)、完整性(Integrity)和可用性(Availability)。在推算风险的影响时,客户必须将每个模块和漏洞整体独立评估,以此获得对该风险的真实认识,并推算可能造成的影响。
找到漏洞的风险是否可接受,或者把风险降到可接受的水平是否会超出控制成本,应该由客户来决定。客户不会花一百万美元来修复访客打印机上的一个安全风险;不过,他们非常愿意投入两倍的资金来保护存有公司机密数据的系统。
注册信息系统安全师 (CISSP,Certified Information Systems Security Professional)课程中列出了用来计算风险的公式,如下所示。
单一威胁预期损失 (SLE,Single Loss Expectancy)是资产价值 (AV,Asset Value)单次损失的成本。单一威胁造成损失的百分比 (EF,Exposure Factor)是指资产损失对整个组织的影响,比如因连接互联网的服务器当机而对营收造成的影响。客户在计算安全投入时应该计算单个资产的SLE来帮助确认应该投入的资金水平。如果一个SLE会给公司带来一百万美元的损失,在预算中考虑预留资金修复这个漏洞就合情合理。
单一威胁预期损失计算公式:
SLE = AV * EF
下一个重要的公式是指出SLE多长时间会发生一次。如果一个价值一百万美元的SLE一百万年才会发生一次,比如流星从天空坠落,那就没必要投资数百万在总部外面建一个穹型保护体。相反,如果一场火灾可能会造成相当于一百万美元的损失,而且可能每几年就会发生一次,那么投资防火系统就是明智之举。某个资产损失发生的频度我们称为单一威胁年发生率 (ARO,Annual Rate of Occurrence)。
单一威胁年预期损失 (ALE,Annualized Loss Expectancy)表示的是因风险造成的年度预期损失。举个例子,流星坠落的年预期损失非常低(一百年才一次),而火灾发生的概率更大,那么就应该在未来的投资中将后者计算出来用作保护建筑物。
单一威胁年预期损失计算公式:
ALE = SLE * ARO
最后,弄清跟某项资产相关联的风险,用以算出用来控制的投资也同样重要。它可以决定客户是否应该投资修复某项资产中的漏洞进行投资,以及该投资多少。
风险计算公式:
风险 = 资产价值 ×威胁 × 漏洞×影响
客户通常都没有风险管理计算公式中各个变量的值。这些计算公式可以当做指引系统来帮客户更好地理解他们该如何对安全进行投资。在前面的例子中,我把对流星雨和建筑物中火灾的估计值代入了计算公式,应该能用估计的美元值解释为什么投资防火系统要比投资金属穹型保护体来防止坠落物更好。
渗透测试是用类似于真实恶意攻击者采用的手法来攻击系统漏洞的方法。一般来说,在某个系统或网络上花光了用于加固安全的投资后,客户一般就会诉求于渗透测试,以验证各方面的安全投资。渗透测试可以是黑盒、白盒或是灰盒,具体取决于双方达成的工作范围。
渗透测试和漏洞评估的最主要区别在于渗透测试针对的是发现的漏洞,它会验证跟目标相关联的已知风险是否真的降低了。一旦资产所有者授权服务提供商针对目标上发现的漏洞实施攻击,对目标的漏洞评估也就成了渗透测试。通常,渗透测试服务的成本会高一些,因为这类服务需要更昂贵的资源、工具和时间来完成任务。一个常见的误区是认为渗透测试服务能够加强IT安全,因为这类服务的关联成本相比其他类型的安全服务更高。具体说明如下。
渗透测试预期的交付结果也应该在议定工作范围时明确指出。黑盒方法中获取跟目标有关的信息最常见的途径是通过社会工程,也就是通过攻击人群而不是系统。比如先面试一个企业内部的职位,那么一周后就能毫无阻挡地带出这些机密数据。如果客户想知道的是他们的Web应用在遭受远程攻击时的易攻击性怎样,那么他们可能不会认可这类交付的内容。确立一个明确的结尾目标也很重要,这样所有利益方都能理解什么时候可以认为渗透测试服务已经结束。通常,议定的交付内容会起到这个作用。
对服务提供商来说,任务的成功取决于交付渗透测试任务所耗费的时间和服务的盈利能力。如果过程能够更高效和精准,也就意味着用更少的服务获得更好的结果。交付内容的质量越高,服务就越贴近客户的期望,这样才能赢得更好的声誉,在未来才能发展更多的业务。出于这些原因,确立执行渗透测试服务的有效方法并确认如何报告发现的结果也很重要。