专家主导的进攻性安全服务

发现弱点。
理解影响。

漏洞评估 / 渗透测试与红队服务

以攻击者视角开展专家主导的测试,立足于您的系统与业务背景。AI 协助关联证据,让团队获得可落实的发现。

测试仅在系统所有者书面授权及双方同意的规则与行动准则(ROE)基础上启动。

授权攻击者视角模拟
范围审核关卡先取得书面许可
攻击者专家主导的模拟
应用程序范围内的 Web/API
身份检查访问边界
证据使用测试数据验证
行动计划确定修复优先级并复测

概念流程:授权 → 测试 → 验证 → 修复。本页面不进行实际系统测试。

发现与验证将弱点与影响关联交付清晰的修复计划

选对问题,开展合适的测试

从您需要解答的问题出发。

各服务回答不同问题。根据团队需求,匹配广度、深度和目标。

01

VA

漏洞评估

应优先处理哪些弱点?

对约定资产中的漏洞和配置进行全面评估,对发现进行分类并优先处理风险。

基线与定期评估
您将获得

经研判的发现与修复优先级

02

渗透测试

渗透测试

弱点实际会造成哪些影响?

专家验证发现及其关联路径,测试业务逻辑和授权访问,范围严格限定在授权范围内。

关键系统、上线与重大变更
您将获得

影响证据、修复措施与约定复测范围

03

红队

目标导向演练

能否阻止并检测到目标行为?

在ROE框架下模拟既定的业务目标,评估预防措施、可见性及协调响应能力。

适合已准备好共同演练防御的团队
您将获得

攻击过程、证据、检测缺口与复盘

已知信息改变测试视角

黑盒或灰盒。
不同的起点。

两者均须获得授权。区别在于向测试人员提供的信息与访问权限,而非保证某种安全水平。

从外到内

从外部开始。
没有内部账户。

测试人员知道授权目标与边界,但不会获得测试账户或内部细节。测试从外部用户可见的信息开始,沿发现的路径在 ROE 范围内开展。

  • 公开 Web、API 与暴露服务
  • 检查登录前的访问与输入界面
  • 适合评估外部人员视角

部分已知信息

使用测试账户。
探索业务背景。

测试人员获得账户与有限背景信息,例如角色或 API 文档,以检查跨用户访问与业务逻辑。这并不意味着能访问全部源代码或内部信息。

  • 使用提供的账户检查角色与访问权限
  • 检查数据与交易流程
  • 适合多角色或多租户系统

以客户门户为例。
黑盒 检查登录前的攻击面。
灰盒 增加账户 A/B,以测试隔离。

黑盒/灰盒实验模拟
范围与交战规则(ROE)已明确授权目标
无内部账户从外部上下文开始
攻击者授权测试人员
公共表面外部暴露的网页 / API
验证发现的路径展示范围内的影响
经验证的证据团队可据以行动的证据

范围与ROE → 起始上下文 → 攻击者 → 测试表面 → 验证 → 证据

范围内测试提供的背景信息经验证的证据

选择图示中的任意步骤暂停查看。播放过程中,说明文字保持不变。

明确目标、授权路径、共同学习。

红队从目标出发。
并非统计漏洞数量。

确定一个场景,然后利用证据说明哪些路径被阻止、哪些内容可见以及团队如何响应。

身份/角色 — 检查已授权的测试账户是否能在授权角色和系统内意外获得额外权限。

网络分段 — 检查已授权的测试主机是否能跨区域访问测试目标,记录可到达和被阻断的路径。

目标导向的红队演练模拟
测试数据访问测试区域内的合成数据
授权测试路径系统、时间窗口与停止条件
红队在 ROE 内选择方法
应用 → 数据测试访问边界
目标达成证据记录结果,包括被阻断的路径
蓝队复盘将证据与日志/告警对比

指向蓝队的虚线路径 = 可能的信号需审查。警报和目标达成并不保证。

默认不包含: 社会工程、物理安全、拒绝服务(DoS)以及第三方测试需要独立的风险评估和授权。

围绕您的系统确定范围

围绕您的关键系统确定范围。

共同确定资产、测试环境和测试深度。并非每个项目都涵盖所有领域。

Web 与 API

使用约定的测试账号和数据,审查身份验证、授权、会话和业务逻辑。

客户门户 · API · 管理后台

基础设施

在授权的IP地址范围和测试时段内,评估暴露的服务、配置和网络边界。

外部/内部网络

身份与云

在约定的环境中审查角色、权限和信任关系,但需符合云服务提供商的政策。

IAM · 云配置 · 访问权限

人工判断,AI 辅助深入分析。

由专家作出判断。
AI 协助关联证据。

有效测试依赖相关假设、谨慎的影响验证,以及团队可实际使用的修复指引。工具用于辅助,最终判断仍由人员作出。

关联攻击路径理解业务逻辑依据证据验证
AI 辅助

在边界内分析

整理发现、关联授权证据、提出后续问题建议,并起草报告,以减少重复的信息处理工作。

↓ 分析结果等待专家审查 ↓
专家验证

核实、决策、承担责任

专家选择测试方法、核查误报、验证证据与影响,并依据组织背景确定修复优先级。

您的团队将获得

风险分析和建议具有可追溯性,并与您的系统相关联,同时明确原始工具输出缺乏上下文的局限性。

输入 AI 的数据受范围与数据处理约定限制。工作开始前明确脱敏、保留期与允许使用的工具,全程由专家监督。

行动前先明确控制措施

深入测试。
遵守明确的操作边界。

行动准则(Rules of Engagement)规定了谁可以测试什么内容、使用何种方法、何时允许测试以及何时必须停止。

  1. 01

    授权与范围

    在测试前,确认书面的所有权授权、资产、IP地址、域名、排除项以及第三方权限。

  2. 02

    测试窗口与停止条件

    约定时间窗口与允许的方法。如发生服务中断或越界情况,应停止并通过约定联系人升级处理。

  3. 03

    证据与数据最小化

    尽可能使用测试数据,仅收集必要证据,对敏感细节脱敏,并约定传输、保留与删除方式。

  4. 04

    清理与交付

    审查测试账号、文件和临时访问权限的移除情况,确认是否按约定执行,然后确认剩余待办事项和责任人。

让证据推动行动

让管理层清晰理解。
让工程师能够落实。

通过观察到的影响、前提条件、证据及测试限制说明风险,让团队能够决策并跟踪工作。

  • 高层摘要风险概览、已测试目标与待作决策
  • 技术发现受影响的资产、前提条件、屏蔽的证据以及推荐的修复方案
  • 修复工作坊与所有相关方共同回顾发现结果,并在约定范围内优先处理工作内容
  • 复测结果在重新测试窗口内重新验证已确认的修复措施,并记录修复情况、部分修复情况或仍待处理状态

从首次沟通到复测

从您的安全问题
到可追踪的修复周期。

  1. 01

    了解需求

    识别关键系统、近期变更以及需要验证的内容

  2. 02

    达成约定

    确认范围、ROE、联系人、费用与交付成果。

  3. 03

    测试与验证

    按计划执行,并通过约定渠道上报重大发现

  4. 04

    报告与修复

    与系统所有者共同审查结果,并跟踪修复进展

  5. 05

    复测

    在提案中定义的范围内和时间内重新验证修复情况

开始之前

测试开始之前。

您的提案明确了资产范围、方法、时间表、报告要求及重新测试安排

应从漏洞评估、渗透测试还是红队开始?

建立初始风险待办清单可考虑漏洞评估;深入验证影响可采用渗透测试;已准备好共同评估防御能力的团队可采用目标导向的红队演练。我们可依据您的系统与问题协助选择。

黑盒测试是否意味着不给测试人员任何信息?

仍须明确目标、边界、排除的系统与 ROE。按约定不提供的是内部背景或账户。黑盒测试并不等于可以测试任何内容。

可以在生产环境中测试吗?

须先评估适用性,并明确时间窗口、限制、停止流程与联系人。部分活动可在预发布环境开展。系统所有者须同意可接受的风险。

AI Agent 是否会独立测试或发送数据?

AI 使用受专家、范围及数据处理约定管控。工作开始前明确允许的工具与输入。AI 无权授权测试,也不会独立扩大范围。

测试是否保证完全安全?

结果反映已测试的范围、时间与条件,不保证发现所有弱点或实现完全防护。系统变化时应修复、复测并重新评估。

如何确定费用、时间与复测安排?

费用与安排取决于资产数量、复杂度、账户与角色、黑盒/灰盒方法或红队目标。工作开始前,在方案中明确价格、时间表与复测次数或范围。

一起确定合适的测试

从最关键的系统开始。
共同规划合适的测试。

请提供系统类型、资产数量、相关角色、目标及首选时间窗口。我们协助确定范围与方法。

概念参考

以下参考资料用于规划、测试与报告的概念依据。实际服务范围以您的方案与 ROE 为准。

NIST SP 800-115 ↗OWASP WSTG ↗NIST:交战规则 ↗CISA:红队洞见 ↗