渗透测试框架

A小辣椒
101 阅读42分钟

渗透测试框架是一种结构化的方法论，它指导安全专业人员完成整个测试过程的每个阶段，从初始规划和范围界定到漏洞利用、报告生成和修复验证。

这好比建筑检查员按照规范检查清单进行检查：检查员不会漫无目的地在建筑物内闲逛，希望发现问题。相反，他们会遵循一套系统化的流程，确保每个结构构件、电气系统和消防安全措施都按照既定标准进行评估。渗透测试框架在安全评估中也发挥着同样的作用。

采用结构化的方法具有多重益处。它能确保工作的全面性，避免遗漏关键环节；促进一致性，使同一团队的不同测试人员能够得出可比的结果；通过使评估符合监管要求来支持合规性；此外，它还能改善沟通，因为客户、审计人员及利益相关方能够理解并信任基于公认标准的流程。

目前有很多渗透测试框架被广泛使用，每个框架都有其自身的理念、优势和理想应用场景。

OSSTMM

识别构成组织完整攻击面的五个安全渠道。

OSSTMM（目前版本为 3）由安全与开放方法论研究所（ISECOM）开发，将科学方法应用于安全测试。其显著特点是“以指标为重，而非主观意见”：OSSTMM 不提供主观的风险判断，而是生成可量化、可验证且可重复的测试结果。

OSSTMM 围绕五个安全渠道组织测试，体现了“安全不仅仅是网络问题”这一理念：

  • 人员安全 (HUMSEC)：社会工程学及人为因素相关的漏洞。
  • 物理安全 (PHYSSEC)：物理访问控制，涵盖从门禁读卡器到尾随进入等各种场景。
  • 无线通信 (SPECSEC)：Wi-Fi、蓝牙、RFID 及其他电磁信号。
  • 电信系统 (COMSEC)：电话系统、VoIP、传真及调制解调器基础设施。
  • 数据网络 (DATASEC)：网络服务、防火墙及应用层协议。

HUMSEC

社会工程学、针对服务台的借口欺诈、针对内部人员的胁迫手段——相比利用“零日漏洞”，打一通自信满满的电话往往成本更低。

PHYSSEC

翻找垃圾箱、绕过围栏、从吸烟区入口搭便车。攻击面从地界线开始。

尾随、克隆门卡、绕过门锁。所有网络控制都基于“这扇门始终关闭”的假设。 即便一个组织拥有完美的防火墙规则，如果攻击者能够尾随进入机房（物理安全）或通过社会工程学手段重置凭 （人员安全），那么这些网络控制措施也就失去了意义。这五个通道确保了测试过程无遗漏。

SPECSEC

涉及配对攻击、BLE 嗅探及恶意外部设备。任何无线设备均在涵盖范围内。

COMSEC

VoIP 拦截、通话欺诈，以及传真和调制解调器等传统通信路径——这些威胁依然存在，且仍被利用。

DATASEC

端点利用、横向移动、服务滥用。这是大多数渗透测试人员默认采用的途径。

涉及服务器端遭入侵、数据库访问及服务枚举。如果攻击路径是数字化的，即便攻击者在物理上靠近机架，也不属于物理安全（PHYSSEC）范畴。

隔离的测试环境、开发系统和实验室网络。在成熟的IT环境中，实验室与生产环境之间的边界往往是遭受攻击利用最多的薄弱环节之一。

OSSTMM 量化方法的核心在于风险评估值（RAV）。RAV 用于衡量总攻击面（暴露程度）与保护该攻击面的控制措施之间的平衡状况。正值的 RAV 表示存在残余风险；接近零的 RAV 则表明控制措施与暴露程度相匹配。这种数值化输出意味着，两名测试人员在评估同一目标时应得出相当的结果，就像两名工程师测量同一根梁时会计算出相似的应力承受极限一样。

OSSTMM RAV（风险评估值）为安全态势提供了一个量化评分。它并非简单的“通过/不通过”评级，而是一个用于衡量变化的基准。当客户询问“我们安全吗？”时，RAV 让你可以这样回答：“我们的安全度为 73%，以下是导致这一数值变化的关键因素。”

OSSTMM 测试周期包含四个阶段。

阶段 1：引导（Induction）—— 涵盖枚举与验证。你需要梳理现有资产并确认其真实性。在 FinVault 案例中，你查询 DNS、审查证书透明度日志，并发现了诸如 vpn.finvault-corp.thm 和 mail.finvault-corp.thm 之类的子域名。随后，验证每个资产是否处于活动状态并能正常响应。此阶段的产出是目标环境经确认的资产清单。

阶段 2：交互（Interaction）—— 涵盖定性与定量分析。你主动探测已验证的资产并评估其相关性。在 FinVault 案例中，你连接到各项服务，识别其技术指纹，并量化暴露情况：共有 8 台主机提供 12 项可从外部访问的服务，其中 4 项服务接受未经身份验证的连接。这些发现将直接用于计算攻击面。

阶段 3：探究（Inquiry）—— 涵盖权限提升与验证升级。你测试已测定的暴露点是否可转化为未经授权的访问。在 FinVault 案例中，你在客户门户中发现了一个 IDOR（不安全直接对象引用）漏洞，该漏洞允许已通过身份验证的用户读取其他客户的账户对账单。通过“验证升级”步骤，确认了影响范围：可读取 12,000 个账户的信息，但无写入权限。

阶段 4：干预（Intervention）—— 涵盖隔离、审计与诱导。你针对发现的问题采取措施，并审查更广泛的控制环境。在 FinVault 案例中，存在漏洞的端点受到限制。同时，开发了相应的补丁（隔离），审查了更广泛的访问控制模型以查找类似缺陷（审计），并部署了金丝雀令牌（canary token）以测试内部检测能力（诱导）。

OSSTMM 规定了安全测试审计报告（STAR）的交付格式，旨在确保一致性并实现跨团队的可比性。

其科学严谨性既是最大的优势，也是主要的实施门槛。OSSTMM 框架使测试结果具备可审计性和可比性，这在渗透测试领域是难能可贵的。然而，OSSTMM 的学习曲线较为陡峭，全面实施可能耗时较长，且相比接受过 OWASP 或 NIST 方法论培训的人员，经验丰富的 OSSTMM 从业者也更难寻觅。OSSTMM 最适合那些需要可重复、可审计的安全评估，并愿意投入精力掌握该方法论的组织。

OWASP WSTG

假设你正在测试一个在线零售商的 Web 应用程序，该程序涵盖了用户注册、产品搜索、购物车、支付处理和订单追踪等功能。你应该从哪里着手呢？是先测试登录表单、搜索栏，还是支付 API？由于单个 Web 应用程序往往存在数十个潜在的攻击面，测试人员很容易出现重复测试某些内容，或者完全遗漏某类漏洞的情况。

开放式 Web 应用程序安全项目（OWASP） 通过发布《Web 安全测试指南》（WSTG）来解决这一问题。尽管 OWASP 最广为人知的是其列出关键 Web 漏洞的“OWASP Top 10”榜单，但 WSTG 的内容要深入得多：它是一个由社区驱动的综合性框架，将 Web 应用程序测试组织为归属于十二大类别的 90 多个独立测试用例。

这十二大类别涵盖了现代 Web 应用程序的完整攻击面，包括：信息收集、配置与部署管理、身份管理、身份验证、授权、会话管理、输入验证、错误处理、加密技术、业务逻辑、客户端测试以及 API 测试。每个类别都包含编号的测试用例（例如，针对反射型跨站脚本攻击的 WSTG-INPV-01），并提供关于测试内容和测试方法的详细分步指导。

WSTG 采用基于风险的方法：漏洞的优先级是根据其可利用性和影响程度来确定的，而不仅仅是简单的罗列。这种方法有助于测试人员将精力集中在最关键的领域。

WSTG 与许多渗透测试框架的不同之处在于，它并不将安全视为单一的孤立事件。相反，它将测试工作贯穿于软件开发生命周期（SDLC） 的五个阶段，从而将安全要素融入从最初规划到上线后维护的全过程。

让我们以正在构建新客户门户网站的在线零售商 ShopSecure Inc. 为例，看看 WSTG 是如何运作的。

阶段 1：开发开始前。预先确立安全需求与合规义务。对于 ShopSecure 而言，这意味着明确该门户网站必须符合 PCI DSS 标准（因为它涉及支付处理），并设定可量化的指标，例如修复漏洞所允许的最长时限。

阶段 2：定义与设计阶段。在编写任何代码之前，先审查应用程序架构是否存在安全缺陷。ShopSecure 团队针对支付流程构建威胁模型，识别出结账 API 是高价值攻击目标，并从一开始就设计了速率限制和输入验证等控制措施。

阶段 3：开发阶段。通过代码走查（walkthroughs）和审查来验证代码质量。ShopSecure 的开发人员对照 WSTG 中关于凭证处理的测试用例（WSTG-ATHN）审查身份验证模块，发现了一个密码重置令牌不会过期的安全缺陷。

阶段 4：部署阶段。在生产环境中验证安全控制措施。ShopSecure 团队对预发布（staged）的应用程序进行渗透测试，确认已更改默认凭证、TLS 配置正确，且未暴露调试端点。

阶段 5：维护与运营阶段。上线后通过定期健康检查（特别是在更新之后）来维护安全性。当 ShopSecure 在三个月后推出新产品推荐功能时，会重新执行相关的 WSTG 测试用例，以确保此次更新未引入新的漏洞。

WSTG 最大的优势在于其详尽且务实的覆盖范围。它包含 90 多个测试用例，每个用例都列出了具体步骤和预期结果，为测试人员提供了切实可行的操作指南，而非抽象的原则。此外，得益于全球安全专业人士社区的持续更新，它能紧跟新兴漏洞类型以及 SPA（单页应用）和微服务等现代架构的发展步伐。

其不足之处在于，对于资源有限的团队而言，全面执行每一个测试用例可能不太现实。某些测试需要密码分析或业务逻辑测试等领域的专业知识。此外，还存在陷入“清单式思维”的风险，即测试人员机械地执行测试用例，而未能退一步评估应用程序的整体风险状况。优秀的从业者会以 WSTG 为基础，同时运用批判性思维，超越清单本身的局限。

NIST SP 800-115

设想以下场景：你是政府机构或与联邦政府签订合同的大型企业的安全分析师。你的组织需要进行安全评估，但评估结果必须满足审计人员的要求，符合联邦指南，并且在监管调查中能够站得住脚。一份充斥着非正式评论和主观风险评级的渗透测试报告是远远不够的。你需要一种联邦监管机构认可和信任的方法。

NIST 特别出版物 800-115正是为了满足这一需求而编写的，它题为《信息安全测试与评估技术指南》。该文档由美国国家标准与技术研究院 (NIST) 出版，为系统地评估信息系统的安全态势提供了一个基础框架。虽然它起源于美国联邦政府，但其原则具有广泛的适用性，并在私营部门得到广泛应用，尤其是在那些重视结构化、可重复流程的组织中。

NIST SP 800-115 并非狭义上的渗透测试框架。它涵盖范围更广：从文档审查和日志分析到漏洞扫描和全面渗透测试，囊括了所有安全测试和评估技术。它将渗透测试视为多种技术之一，所有这些技术都旨在验证安全控制措施是否按预期运行。

该框架由三个核心目标驱动。首先，识别系统、网络和应用程序中的漏洞。其次，通过测试安全控制措施在对抗条件下是否按预期运行来验证其有效性。第三，通过模拟真实世界的攻击场景来评估可利用性，以确定威胁行为者是否能够真正利用已识别的弱点。

NIST SP 800-115 将测试分为三个阶段。你的团队受命评估 GovNet 的安全性，GovNet 是一个中型联邦机构的内部网络，覆盖 500 台主机、3 个数据中心和一个面向公众的公民服务门户。

阶段 1：规划（Planning）。在任何测试开始之前，目标、范围和测试规则都将被正式定义并记录下来。对于 GovNet 而言，这意味着要明确哪些网络段在测试范围内（公民门户及其后端支持），哪些网络段被排除在外（机密安全区）。此外，还需建立通信协议：例如，如果在测试过程中发现关键漏洞，应通知谁；允许的测试时间；以及紧急停止测试的条件是什么。规划阶段会生成一份正式的测试计划，并由所有利益相关者签字确认。

阶段 2：执行（Execution）。这是进行实际测试的阶段。NIST SP 800-115 将执行活动分为四类技术：

  • 审查技术 Review techniques：检查文档、策略、系统配置和规则集。在 GovNet 中，这包括审查防火墙规则和访问控制列表是否存在配置错误。

  • 目标识别和分析 Target identification and analysis：发现并识别活动主机、开放端口和正在运行的服务。在 GovNet 中，需要扫描公民门户的基础架构，并识别 12 项面向互联网的服务。

  • 目标漏洞验证 Target vulnerability validation：确认已识别的弱点是真实存在的且可被利用的，而非误报。在 GovNet 系统中，扫描结果显示门户网站的搜索功能存在潜在的 SQL 注入漏洞；需要手动编写一个测试查询来验证该漏洞，该查询会返回数据库版本信息。

  • 渗透测试 Penetration testing：模拟对抗性攻击，以测试可能的利用深度。在 GovNet 系统中，将已确认的 SQL 注入漏洞与数据库服务器上的权限提升攻击相结合，以证明外部攻击者可以访问内部公民记录。

请注意 NIST SP 800-115 如何将这些攻击视为从被动到主动、从低影响到高影响的渐进过程。并非每次评估都需要进行渗透测试；有时，审查和漏洞验证就足以达到评估目标。

阶段 3：测试后阶段（Post-Testing）。重点转移到分析结果、确定风险优先级以及制定可行的补救策略。对于 GovNet 系统而言，这意味着按严重程度对发现的漏洞进行分类（SQL 注入链至关重要；缺少 HTTP 安全标头属于低风险），将每个漏洞映射到它绕过的特定控制，并提供具体的补救步骤。 NIST SP 800-115 强调，安全发现必须具有可操作性：仅仅告知客户“你们存在 SQL 注入漏洞”是不够的；标准做法是解释哪个参数存在漏洞、哪些数据面临风险以及如何修复漏洞。

NIST SP 800-115 的优势在于其灵活性和机构权威性。它能够适应各种不同的环境，从传统数据中心到云基础设施和物联网部署，因为它定义的是技术类别，而不是指定具体的工具。它与 NIST 的关联也赋予了它更高的权威性。

PETS

你已经了解了侧重于科学指标（OSSTMM）、Web 应用程序覆盖范围（OWASP WSTG）以及符合政府标准的评估技术（NIST SP 800-115）的各类框架。但这里有一个值得思考的问题：如果明天你受聘对企业网络进行一次标准的渗透测试，那么从最初与客户沟通到最终交付报告，哪一个框架最能反映你实际遵循的工作流程？

对于许多在职渗透测试人员来说，答案是“渗透测试执行标准”（Penetration Testing Execution Standard，简称 PTES）。PTES 可在 pentest-standard.org 网站上获取，它由一群经验丰富的安全从业者制定，旨在明确真正的端到端渗透测试究竟包含哪些内容。与其他侧重于测试内容或衡量指标的框架不同，PTES 关注的是整个测试项目从始至终的运作流程。

PTES 将工作划分为七个阶段，这些阶段与渗透测试项目的生命周期直接对应。这种方式对于初级测试人员而言极具实用价值，因为它解答了许多框架中未明确说明的问题：“合同已经签好了，接下来第一天、第二天以及后续每一天我该做什么？”

一家名为 MedGuard Health 的医疗保健公司聘请了你的团队，对其实体网络和患者记录门户网站进行全面的渗透测试。

阶段 1：参与前沟通（Pre-Engagement Interactions）。这是测试开始前进行的所有准备工作。你与 MedGuard 的 IT 总监共同确定测试范围：企业局域网（10.10.0.0/16）、位于 records.medguard-health.thm 的患者门户网站以及总部大楼的无线网络。记录下“交战规则”（rules of engagement），包括测试时间窗口（仅限工作日夜间，以避免干扰临床业务）、紧急联系人信息，以及一份授权测试的“免责函”（即“免责通行证”）。PTES 在此环节特别详尽，因为范围界定不清是渗透测试中引发法律和职业纠纷的首要原因。

阶段 2：情报收集（Intelligence Gathering）。利用被动和主动技术收集有关 MedGuard 的信息。被动侦察包括从 LinkedIn 收集员工电子邮件地址、通过证书透明度日志发现子域名，以及查阅透露技术栈信息的招聘启事（例如“招聘具备 Oracle 19c 经验的数据库管理员”）。主动侦察则涉及在商定范围内的 DNS 枚举和网络扫描。PTES 区分了这些侦察层级，因为情报收集的深度直接决定了后续阶段的质量。

阶段 3：威胁建模（Threat Modeling）。利用收集到的情报，确定最有价值的目标和最可能的攻击路径。在 MedGuard，患者记录数据库是价值最高的资产。威胁模型确定了两条主要攻击路径：通过 Web 漏洞直接攻破患者门户网站，或者在攻破员工工作站后，以此为跳板渗透企业局域网。该阶段确保你的测试工作遵循攻击者逻辑，而非盲目的随机扫描。

阶段 4：漏洞分析（Vulnerability Analysis）。你系统地识别可能促成威胁模型中攻击路径的弱点。在 MedGuard，漏洞扫描显示患者门户网站运行着过时的 Apache Tomcat 版本，该版本存在已知的反序列化漏洞。在内部网络中，几台工作站缺失关键补丁。PTES 强调，漏洞分析既包括自动扫描，也包括人工验证，以排除误报。

阶段 5：漏洞利用（Exploitation）。你尝试利用已确认的漏洞。在 MedGuard，你利用 Tomcat 反序列化漏洞在门户服务器上获取了 Shell 访问权限。在内部测试环节，你利用网络钓鱼手段（在授权范围内）将攻击载荷（payload）投递至员工工作站。PTES 强调，利用漏洞的行为应具有明确目的：目标是展示业务影响，而非仅仅为了“攻陷系统”而进行攻击。

阶段 6：利用后阶段（Post-Exploitation）。在获得访问权限后，你需评估实际的业务影响。你可以从被攻陷的门户服务器（portal server）横向移动至后端数据库，并确认具备读取患者记录的权限；同时，从员工工作站提取缓存的域凭据，并演示如何横向移动至存储财务数据的文件服务器。PTES 将此阶段视为将技术发现转化为业务风险评估的关键环节：“我们访问了 5 万条患者记录”这一结论，其重要性远超“我们获取了系统 Shell 权限”。

阶段 7：报告撰写。你将测试结果汇总为一份结构化报告，并兼顾两类受众的需求。执行摘要部分使用通俗易懂的语言向 MedGuard 管理层阐述业务风险：患者数据处于可被访问状态，面临重大的 HIPAA 合规风险，且亟需采取修复措施。技术报告则提供了 MedGuard IT 团队复现并修复各项问题所需的详细信息，包括具体的攻击步骤、受影响的主机、证据截图以及按优先级排序的修复建议。

PTES 最大的优势在于其务实且涵盖全流程的架构。它读起来就像是一份关于渗透测试实际开展过程的操作指南，对于正在培养工作流程直觉的初级测试人员而言，是一个极佳的学习框架。其中关于“项目启动前交互”的详尽阐述尤为可贵；许多其他框架往往对界定测试范围（scoping）和获取法律授权这些环节轻描淡写，而恰恰是在这些环节，缺乏经验的测试人员最容易犯下代价高昂的错误。

其不足之处在于，PTES 已有数年未进行正式更新，其中的技术指导部分引用了一些过时的工具与技术。尽管其方法论和阶段划分依然合理有效，但测试人员在参考其针对具体工具的指导时，应结合最新的官方文档进行补充。此外，PTES 缺乏像 OSSTMM 那样的量化指标体系，因此测试结果在很大程度上取决于测试人员个人的判断。

ISSAF

按顺序排列攻击者从侦察到实现持久化及隐蔽行动的九个步骤。

你是否曾研读过一本老旧的教科书，却发现尽管年代久远，其核心逻辑依然经得起时间的考验？在网络安全领域，各类工具和漏洞利用手段往往“保质期”很短，但设计精良的方法论却能历久弥新，其生命力远超当初用于测试的具体技术。信息系统安全评估框架（ISSAF）便是一个典型的例子。

ISSAF 由开放信息系统安全小组（OISSG Open Information Systems Security Group）开发，是一个用于评估网络、系统及应用程序安全性的开源渗透测试框架。该框架的最新版本（v0.2.1）发布于 2006 年左右，目前已停止维护。虽然官方下载链接已不复存在，但仍可通过网络存档找到其草案版本。了解这一背景至关重要：ISSAF 的方法论和阶段划分至今仍具指导意义，但其中针对具体工具的指导建议已然过时，不应作为当前安全评估工作的依据。

那么，为什么要研究一个早已停止维护的框架呢？因为 ISSAF 提出的九步评估模型，极其清晰地展示了攻击者在目标环境中的行动轨迹。它模拟了高级持续性威胁（APT）的攻击逻辑，即从初始侦察到建立持久访问，再到清除痕迹，整个过程循序渐进、井然有序。这种攻击演进路径你应该不会感到陌生——它正是本模块早先在“网络杀伤链（Cyber Kill Chain）”专题中所详细探讨的“杀伤链”思维模式。

ISSAF 涵盖了广泛的安全领域，包括网络基础设施、主机系统、Web 应用程序、数据库以及社会工程学。该框架采用基于风险的方法，优先关注那些高影响且可被利用的漏洞，而非仅仅关注低严重性的发现。

ISSAF 将评估过程分为三个阶段。让我们结合一个场景来了解这些阶段：你的团队正在评估 TechBridge Solutions 的安全性，这是一家拥有 200 名员工、配备内部 Git 服务器及面向客户的项目管理门户网站的软件开发公司。

阶段 1：规划与准备（Planning and Preparation）。此阶段用于设定评估工作的边界。你与 TechBridge 的首席技术官（CTO）会面，以明确评估范围（包括企业网络、Git 服务器和项目管理门户）、确立升级流程与紧急联系人、识别限制条件（例如，生产环境的 Git 服务器在工作时间内不得中断服务），并商定适合此次评估的工具集。

阶段 2：评估（Assessment）。这是 ISSAF 的核心部分，也是其“九步模型”的实施阶段。每个步骤都建立在前一步的基础上，模拟真实攻击者在目标环境中的行动轨迹。

  • 1. 信息收集（Information gathering）：收集有关 TechBridge 的公开数据。DNS 记录、WHOIS 数据、LinkedIn 上的员工资料以及招聘启事中提及的技术要求（如“需具备 Jenkins 和 GitLab CI 使用经验”）等，都有助于你加深对目标的了解。
  • 2. 网络映射（Network mapping）：绘制实时网络拓扑结构。你发现 TechBridge 的外部 IP 地址段托管着项目门户、VPN 网关和邮件服务器。内部扫描（在授权范围内）揭示了 Git 服务器、Jenkins 构建服务器以及多台开发人员工作站的存在。
  • 3. 漏洞识别（Vulnerability identification）：扫描已映射的资产以查找弱点。项目门户运行着一个过时的内容管理系统（CMS），该系统存在已知的身份验证绕过漏洞；Jenkins 服务器的管理控制台则处于未受身份验证保护的暴露状态。
  • 4. 渗透（Penetration）：尝试进行初始利用。利用未受保护的 Jenkins 控制台在构建服务器上执行系统命令。
  • 5. 获取访问权限与提权（Gaining access and privilege escalation）：从初始访问权限提升至更高权限。你从 Jenkins 服务器中获取了用于将代码部署到生产环境的服务账户凭据，该账户在 Git 服务器上拥有管理权限。
  • 6. 进一步枚举（Enumerating further）：利用提升后的访问权限，枚举当前可访问的资源。从 Git 服务器中，发现了包含 API 密钥、数据库连接字符串以及客户项目源代码的代码仓库。
  • 7. 攻陷远程用户/站点（横向移动）（Compromise remote users/sites (lateral movement)）：横向移动至其他系统。利用获取的凭据，你访问了多台开发人员工作站以及内部邮件服务器。
  • 8. 维持访问权限（Maintaining access）：建立持久访问权限，以证明真实的攻击者能够保持其立足点。你需要记录（无需实际部署）如何在 CI/CD 流水线中植入后门，使其在系统重启和部署过程中依然保持有效。
  • 9. 掩盖踪迹（Covering tracks）：演示攻击者如何清除证据。你需要记录哪些日志捕获了你的活动，并指出 TechBridge 日志记录机制中的不足之处——这些漏洞可能让真正的攻击者在不被察觉的情况下进行操作。

注意其中的演进过程：每一步都加深了攻击者在环境中的立足程度。第 1 至 3 步涉及侦察与分析，第 4 至 7 步涉及主动入侵，而第 8 至 9 步则关注持久化与隐蔽性。

阶段 3：报告与清理（Reporting and Cleanup）。你需要将发现的问题汇总成一份结构化报告，并根据业务影响程度对问题进行优先级排序。其中，未经身份验证即可访问的 Jenkins 控制台被标记为“严重”级别，因为它提供了最初的立足点，进而导致了对源代码的访问权限。清理工作包括移除所有测试产物、撤销测试期间创建的临时账户，并与 TechBridge 团队确认其环境中未残留任何测试痕迹。

ISSAF 的九步模型是其留给业界的宝贵遗产。从信息收集、横向移动到清除痕迹的演进过程，为理解现实世界中的攻击如何展开提供了一个清晰的思维模型；尽管该框架本身已不再维护，但它依然是一个极佳的教育工具。

然而，缺乏维护确实是一个不容忽视的局限。其中针对具体工具的指导内容所引用的软件版本已严重滞后（有的甚至已过时十余年），且缺乏社区力量来更新相关文档。研究 ISSAF 时，应侧重于其方法论和攻击者逻辑，而非具体的技术操作步骤。若需获取针对当前工具的指导，建议结合 PTES、OWASP WSTG 或相关工具的官方文档等资源进行补充。

MITRE ATT&CK

使用标准化术语，将攻防演练的发现结果映射到 MITRE ATT&CK 战术。

请设想这样一种情况：你刚刚依据 PTES 标准完成了一次渗透测试任务，并在报告中记录了以下过程：通过钓鱼邮件获取初始访问权限，利用配置错误的服务提升权限，使用窃取的凭据进行横向移动，最后通过加密通道外泄数据。客户在阅读报告后提出了一个看似简单却难以回答的问题：“与现实世界中威胁行为者的实际行动相比，我们的暴露风险处于什么水平？”

仅凭渗透测试框架很难回答这个问题。像 PTES 和 OSSTMM 这样的框架虽然能规范测试流程，却无法系统性地梳理现实世界中的攻击者所采用的具体战术与技术。而 MITRE ATT&CK 正是用来填补这一空白的。

ATT&CK 代表“对抗战术、技术与常识”（Adversarial Tactics, Techniques, and Common Knowledge）。它由 MITRE 公司开发和维护，并非传统的渗透测试框架，而是一个基于对威胁行为者实际行动的观察而构建的攻击者行为知识库。它详细记录了攻击者的行为，并以一种结构化的方式进行组织，供安全专业人员用于威胁情报分析、检测工程、红队演练，以及丰富渗透测试的发现结果。

ATT&CK 框架以矩阵形式组织，可以将其想象成一张大型表格。其中的列代表“战术”（Tactics），即攻击者的高层目标，也就是行动背后的意图。目前的“企业级矩阵”（Enterprise matrix）包含 14 种战术，涵盖了从初始访问（Initial Access）到执行（Execution）、持久化（Persistence）、权限提升（Privilege Escalation）、防御规避（Defense Evasion）、凭据访问（Credential Access）、发现（Discovery）、横向移动（Lateral Movement）、收集（Collection）、命令与控制（Command and Control）、数据外传（Exfiltration）以及影响（Impact） 的全过程。

在每个战术列中，行项目列出了“技术”（Techniques），即攻击者为实现该战术目标而采取的具体手段或方法。例如，在“初始访问”战术下，你会看到诸如钓鱼攻击（Phishing，T1566）、利用面向公众的应用程序（Exploit Public-Facing Application，T1190）和使用有效账户（Valid Accounts，T1078）等技术。许多技术还可以进一步细分为“子技术”（Sub-techniques）。以“钓鱼攻击”为例，它包含针对附件的鱼叉式钓鱼（T1566.001）、针对链接的鱼叉式钓鱼（T1566.002）以及通过服务进行的鱼叉式钓鱼（T1566.003）等子技术。

ATT&CK 知识库中的每一项技术条目都包含详细描述、曾使用该技术的现实威胁组织案例、检测建议以及缓解措施。正是这些内容使ATT&CK 超越了单纯的分类体系，成为一个与实际观察到的攻击者行为紧密关联的动态参考资源。

本节的关键在于理解：ATT&CK 并不指导如何执行渗透测试。它不定义测试阶段、范围界定流程或报告格式。相反，无论采用何种框架进行测试，ATT&CK 都提供了一种通用语言，用于描述测试过程中发现的问题。

不妨将医学词典与诊断流程做个类比。PTES 就像诊断流程：它指导医生在检查过程中应遵循哪些步骤。而 ATT&CK 就像医学词典：它为医生观察到的现象提供了标准化的命名和分类术语。两者缺一不可，但用途各异。

实操演练：将发现的问题映射到 ATT&CK

让我们看看这在实践中是如何运作的。回想一下 PTES 中针对 MedGuard Health 的渗透测试项目。以下是将该项目中的关键发现映射到 ATT&CK 技术 ID 的具体情况：

渗透测试发现（Engagement Finding）ATT&CK 战术（Tactic）ATT&CK 技术（Technique）
通过钓鱼邮件向员工工作站投递恶意载荷（Payload）初始访问（Initial Access）钓鱼攻击：鱼叉式钓鱼附件（Phishing: Spearphishing Attachment，T1566.001）
利用患者门户（Patient Portal）上的 Tomcat 反序列化漏洞 获取访问权限初始访问（Initial Access）利用面向公众的应用程序（Exploit Public-Facing Application，T1190）
从员工工作站提取缓存的域凭据（Domain Credentials）凭据访问（Credential Access）操作系统凭据转储（OS Credential Dumping，T1003）
使用窃取的凭据从员工工作站横向移动到文件服务器横向移动（Lateral Movement）使用替代身份验证材料（Use Alternate Authentication Material，T1550）
从已被攻陷的患者门户服务器访问患者记录数据库数据收集（Collection）从信息存储库收集数据（Data from Information Repositories，T1213）

通过在 PTES 报告中标注 ATT&CK 技术 ID，测试人员为 MedGuard 安全团队提供了超越单纯修复单个漏洞的可操作见解。客户现在可以在 ATT&CK 知识库中查询各项技术，查阅检测指南，并针对这些特定行为构建或验证检测规则。讨论的重点也随之转变：从“修复这个漏洞”变成了“我们能否检测到这类攻击者行为？”

ATT&CK 的优势在于它充当了攻击者行为的“通用语言”。它让渗透测试人员、威胁情报分析师、检测工程师和事件响应人员能够使用统一的术语进行交流。对于渗透测试人员而言，将测试发现映射到 ATT&CK 框架，能使报告从单纯的漏洞列表升华为基于真实威胁行为的分析叙述。

其他框架

WASC威胁分类由Web 应用程序安全联盟 (WASC) 开发，是一种用于对 Web 应用程序漏洞和攻击类型进行分类的分类体系。它将威胁分为身份验证不足、信息泄露和功能滥用等类别。虽然它在 2000 年代中期影响深远，并帮助规范了业界讨论 Web 威胁的方式，但此后它已被 Web 安全联盟 (WASC) 的分类体系所取代。OWASPTop Ten 和 WSTG 是目前主流的网络安全参考资料。你可能仍然会在一些较旧的文档或合规性框架中看到它们的身影。

CSA 云控制矩阵 (CCM)该框架由云安全联盟 (CSA) 发布，提供了一个专门为云计算环境设计的网络安全控制框架。它将控制措施映射到 17 个领域，包括数据安全、身份和访问管理以及基础设施安全，并使其与 ISO 27001 等主要标准保持一致。美国国家标准与技术研究院， 和PCI DSSCCM并非渗透测试方法，而是一种治理和合规工具，旨在帮助组织评估其云服务提供商和配置是否满足安全要求。当客户需要进行云安全态势评估而非传统的渗透测试时，你就会遇到它。

OWASP移动应用安全测试指南 (MASTG)是 WSTG 的移动版本。由MASTG维护，提供针对Android 和 iOS 应用安全的详细测试用例，涵盖数据存储、加密实现、网络通信、平台交互和代码质量等领域。如果你的项目涉及测试移动银行应用、医疗保健患者门户应用或任何面向客户的移动应用，MASTG 是你的首选参考资料。它与以下工具配合使用：OWASP移动应用安全验证标准 (MASVS) 定义了 MASTG 测试所依据的安全要求。

PCI DSS渗透测试指南在支付卡行业数据安全标准中定义，具体见要求 11.4 (PCI DSSv4.0）。与之前介绍的通用框架不同，这些指南是监管要求：任何处理、存储或传输持卡人数据的组织都必须进行符合以下要求的渗透测试。PCI DSS标准。指南明确规定，测试必须涵盖外部边界和内部网络，必须至少每年进行一次，并在基础设施发生重大变更后进行测试，并且必须验证网络。分割控制权。当你的客户是零售商、支付处理商或支付卡生态系统中的任何实体时，PCI DSS需求将决定你参与项目的范围和报告格式。

CBEST框架CBEST是由英格兰银行与英国金融业合作开发的。它是一个以威胁情报为主导的渗透测试框架， 专为英国金融机构（包括银行、保险公司和金融市场基础设施提供商）设计。CBEST项目首先进行定制化的威胁情报分析，识别与特定机构最相关的威胁行为者和攻击场景，随后的渗透测试则模拟这些真实的威胁场景。CBEST的显著特点在于其将威胁情报与实际测试紧密结合，并获得了英国金融业的监管支持。

对比表

框架主域名类型积极维护何时使用？
WASC威胁分类Web应用程序威胁分类学否（已被取代）OWASP）前期参考资料；历史背景
CSA云控制矩阵云环境治理/合规控制是的云安全态势评估
OWASP移动应用安全测试指南 (MASTG)移动应用（Android/iOS）测试指南是的移动应用渗透测试
PCI DSS渗透测试指南支付卡环境监管指令是的（当前：PCI DSSv4.0）任何涉及持卡人数据的活动
CBEST英国金融业基于威胁情报的渗透测试是的与英国金融机构的互动

这项调查的主要结论是，框架的选择取决于具体情况。客户的行业、监管义务、技术平台和地理管辖范围都会影响适用的框架。例如，为英国银行工作的渗透测试人员必须了解 CBEST 框架。而评估移动健康应用程序的测试人员则会选择其他框架。OWASPMASTG。与支付处理商合作的测试人员无法避免PCI DSS需求。了解整体情况意味着你可以识别出特定项目需要哪种框架，即使你需要在那时进行详细研究。

选择合适的框架

现在你已经掌握了几种渗透测试框架的基本知识，每种框架都有其自身的理念、结构和优势。但是，了解每个框架的功能并不意味着你就能自动知道应该使用哪一个。实际上，框架选择是渗透测试人员在收到项目简报后需要做的首要决定之一，而这一决定往往受到多种因素的影响，这些因素常常相互制约。

不妨以机械师的工具箱为例。机械师不会在每次维修时都使用所有工具；他们会根据车辆、问题以及客户的期望来选择工具。渗透测试人员的工作方式也类似。“正确”的框架取决于客户所在的行业、被测系统的类型、监管环境以及项目的目标。

在实际应用中，框架的选择始终受到以下四个因素的影响。

项目范围和目标类型是最直接的筛选条件。Web应用程序评估符合以下条件：OWASPWSTG。移动应用互动需要OWASPMASTG。全频谱网络渗透测试与 PTES 或 OSSTMM 天然契合。如果测试范围涵盖多个通道，包括物理和人为因素，则 OSSTMM 的五通道模型尤为适用。

监管和合规要求可以完全凌驾于个人偏好之上。如果客户处理支付卡数据，PCI DSS渗透测试指南并非可有可无。如果客户是受英格兰银行监管的英国金融机构，则可能强制要求其遵守 CBEST 标准。美国国家标准与技术研究院SP 800-115 在美国政府和联邦承包商环境中具有重要意义。当法规要求时，测试人员会做出相应调整。

当涉及多位评估人员或需要比较不同时间段的结果时，可量化、可重复的结果至关重要。OSSTMM 的 RAV 指标正是为此而设计的。如果客户表示：“我们希望衡量自去年测试以来，我们的安全态势是否有所提升”，OSSTMM 提供的衡量框架可以客观地回答这个问题。

团队专业知识和可用资源是容易被忽视的实际限制因素。完整的 OSSTMM 实施需要对指标体系有深入的了解。CBEST 则需要威胁情报能力。对于执行标准企业网络评估的小型团队而言，PTES 提供了一个实用且结构良好的工作流程，无需使用更专业的框架，从而避免了额外的开销。

情景一：

一家地区医院聘请你的团队测试其面向患者的网络门户及其连接的内部网络。该医院必须遵守以下规定：HIPAA但不受以下限制：PCI DSS（该公司将支付处理业务外包）。他们需要一份结构化的、端到端的评估报告，并向董事会提供一份清晰的执行摘要。

PTES 最适合此需求。它提供了医院所需的端到端参与架构，其报告阶段明确地生成了管理层和技术方面的交付成果，并且它在一个方法论框架内涵盖了 Web 应用程序和网络测试。OWASPWSTG 可以专门补充网络门户测试，并将测试结果映射到MITREATT&CK 技术ID将报告内容与现实世界的威胁行为联系起来，可以增强报告的说服力。

对象：区域性医院

主要框架：PTES

补充框架：针对门户网站采用 OWASP WSTG

理由：采用 PTES 构建整体框架，针对门户网站使用 OWASP WSTG，并利用 MITRE ATT&CK 将发现的问题映射到攻击者行为，从而撰写报告。

情景二：

一家总部位于伦敦的跨国银行需要进行渗透测试，以满足其英国监管要求。这项工作必须首先针对该机构进行威胁情报评估。

CBEST 显然是最佳选择。它专为英国金融机构设计，强制要求进行定制化的威胁情报阶段，并获得英格兰银行的认可。任何通用框架都无法单独满足这些要求。

对象：英国零售银行

主要框架：CBEST

补充框架：针对任何 Web 组件采用 OWASP WSTG

理由：CBEST 规范了此次评估工作；OWASP WSTG 为 Web 组件提供了详细的方法论。结合 MITRE ATT&CK 框架进行映射，增强了最终交付报告的质量。

情景三：

一个SaaS这家初创公司希望在未来两年内委托两家不同的安全公司独立测试其平台，并直接比较测试结果以追踪改进情况。该平台完全基于Web。

OSSTMM 的 RAV 指标能够实现客户所要求的跨团队、跨时间的直接比较。OWASPWSTG 将指导特定于 Web 的测试用例，而 OSSTMM 提供定量测量层，使逐年比较变得有意义。

情景 4：

一家金融科技公司邀请你测试他们的安卓和iOS手机银行应用程序，这两个应用程序都可以处理信用卡交易。

这种合作需要两个框架协同运作。OWASPMASTG 为两个平台上的移动应用程序安全提供了测试用例。PCI DSS由于这些应用程序会处理持卡人数据，因此必须遵循渗透测试指南。测试人员需要同时满足移动端特定的测试方法和监管要求。

适用对象：金融科技移动应用

主要框架：OWASP MSTG

补充参考：PCI DSS 渗透测试指南

理由：由于这些应用程序处理持卡人数据，因此必须遵循 PCI DSS 标准；而仅凭任何单一的移动应用测试方法都无法满足该监管要求。

总结

框架（Framework）适用范围（Scope）核心优势（Key Strength）局限性（Limitation）最佳应用场景（Best For）
OSSTMM多渠道（5 个安全测试通道）可量化的安全指标（RAV，风险评估值）学习曲线陡峭，较难掌握需要可重复、可审计的安全评估
OWASP WSTGWeb 应用程序提供 90 多个结构化测试用例容易让测试者流于“检查清单”式测试Web 应用渗透测试
NIST SP 800-115系统、网络、应用程序权威性高（美国政府标准），测试技术分类灵活仅提供指导，不具强制性政府机构及企业安全评估
PTES端到端渗透测试实用、按阶段组织的渗透测试流程长时间未更新标准的网络和应用渗透测试
ISSAF网络、系统、应用程序清晰的九阶段攻击流程已停止维护学习攻击方法论的参考资料
MITRE ATT&CK攻击者行为与战术技术描述攻击者行为的通用语言不是渗透测试方法论为任何测试框架的发现结果提供 ATT&CK 映射
OWASP MSTG移动应用（Android / iOS）提供针对平台的移动应用测试用例仅适用于移动应用移动应用安全测试
PCI DSS Guidelines支付卡数据环境（Cardholder Data Environment，CDE）支付行业法规要求，具有合规性适用范围较窄涉及银行卡持卡人数据的渗透测试
CSA CCM云环境云安全治理控制，与多个国际标准对应不是渗透测试方法论云安全
avatar
文章
阅读
粉丝