1. 典型安全验证部署拓扑

-- 红色虚线又假定攻击路线

为了避免影响现网业务，在业务区部署靶机系统，通过对靶机的测试来测试安全设备是否有效。靶机的数量越多，测试情况越准确，靶机类似数量越多，测试情况越准确。

2. 安全设备自身安全漏洞

2.1. 自身设计缺陷-自身产品存在漏洞

风险点：安全产品大多也是采用通用的操作系统、中间件和数据库组成的，其看起来安全的原因是因为开放端口关闭了、漏洞及时升级了、版本号修改了，并不代表其是安全的。

案例：比如某厂商的VPN系统存在一个服务端请求伪造（SSRF）漏洞，该漏洞是由于设备在处理某些消息时校验逻辑存在缺陷，允许攻击者访问某些本来无权限访问的资源。【查看安全企业官网可以看到对应系统的安全漏洞，此部分漏洞一般不包括通用的漏洞】

验证方式：采取各类安全设备已经出现的POC进行验证，通过查看安全验证平台的日志来确认是否存在漏洞。

2.2. 自身设计缺陷-探测机制存在漏洞

风险点：安全设备漏洞扫描的畸形探测包，会引起应用系统的挂死。

验证方式：采取模拟实际环境的特定靶机来进行安全产品的能力测试。

2.3. 自身设计缺陷-运行机制导致不可用

风险点：安全设备系统的防病毒全盘查杀功能，有可能误删正常文件，造成可用性存在问题。或者占用系统性能过高，导致业务系统资源不足等问题。

验证方式：采取模拟实际环境的特定靶机来进行安全产品的能力测试。

3. 安全设备自身性能问题

3.1. 防护能力失效-设备告警存在丢失

风险点：系统在资源利用率过高的情况下，会造成队列堆栈，造成任务丢失、告警丢失的情况。

验证方式1：采取安全设备对接安全设备的接口，查看设备的资源使用情况。

验证方式2：采取多次发送不同的POC验证指令，查看是否发现告警遗漏的问题。

3.2. 防护能力失效-设备达到性能瓶颈

风险点：安全设备一般为硬件设备，存在防护能力上限，可能存在设备挂死问题，在有些场景下，安全设备会通过bapss方式直接放通流量；

验证方式：外部设备存活性探测，包括端口和存活性测试，通过查看安全验证平台的日志来确认是否存在漏洞；

3.3. 审计功能失效-设备审计日志丢失

风险点：安全设备自身功能故障，导致系统自身的操作日志丢失，导