安全运营视角下的POC测试

企业在做安全产品选型时,POC测试多站在产品功能、性能验证视角,而对后期安全运营视角下的需求关注较少.随着企业安全建设的深入,安全产品作为独立个体”独善其身”的可能性下降,需要更多与其他安全产品、平台集成、联动,POC测试时安全运营需求如果考虑未充分考虑,最后会发现安全产品的能力和功效发挥的一般,甚至造成”食之无味、弃之可惜”的被动局面。

故,笔者从安全运营视角谈一谈POC时的注意点,给大家提供些许参考或指引。

完备性包含2个方面:

一是日志记录完备性，日志记录是否详尽、完善，是否覆盖了常见的功能(含异常操作)场景;

如终端管控产品POC,功能测试U盘拷贝管控功能,虽然拷贝管控正常,但是如果发生拷贝动作时,有权限和没权限的拷贝动作日志仅记录拷贝行为,没记录拷贝的结果(失败OR成功),在安全运营时可能会带来大量的假告警.一个良好的拷贝管控日志记录形式应为:行为日志+方向(拷出/拷入)+结果(失败/成功).这种在功能测试中是很难发现的。

二是产品功能完备性,产品本身是否带有自检机制,是否支持终端客户端版本的统一管理和后台批量升级等；

如Gartner魔力象限某Top3数据防泄漏产品,控制台不支持客户端版本的统一控制、升级和维护.当然通过其他手段也是可以进行软件的推送升级.为保持多终端多版本兼容时,很难想象在运营阶段推送200M客户端升级包时的心情.又如Client与Server通信是否正常,Client工作是否正常,是否被破坏绕过, 在面临终端产品安全运营指标”正常率”评估时的烦恼会接踵而至.产品自身自检机制不健全,谈论管控有效性也就犹如空中楼阁了。

完备性, 在终端安全管理产品POC中尤为重要,是POC测试时最容易忽略的一个内容,也是比较难判断的一个点.实际场景中,可以结合测试用例设置、测试场景模拟和运营维护等维度进行考察。

有效性,重点体现在告警日志的准确度上,POC时除了关注设备性能外,更多还要从告警结果是否真实,是否有效的角度进行验证,不要被日志里面显示的大量拦截或告警日志迷惑。

如某国际TOP级的FW设备,POC验证时产生了大量的告警,显示拦截大量外部、内部攻击,在实际进行告警人工溯源取证时,没有发现任何异常,通过厂商自己FW配套的端点检测工具长时间在线检测也没有发现异常,最终通过多方的验证,原因确认为FW厂商错把微软的国内补丁升级地址作为恶意外联导致.当然类似的案例还有很多,POC如果不深入,告警的有效性未充分验证,在安全运营阶段威胁建模准确度会大打折扣。

有效性,在流量分析类产品POC时需重点考量,不像终端类产品POC效果那么直观,此项需要花费一定的时间和精力去确认.验证的手段有很多种,如告警反查威胁源、人工模拟验证、端点联动检测等.另外建议给POC测试预留充分的时间,一般2-3个月或半年为宜。

开放性重点考量的是安全产品自身功能能力是否开放,是否支持与其他安全产品或系统的联动、集成。

在安全运营阶段,安全人员关注的重点一定是多产品”协同作战”的能力,如通过威胁建模发现主机异常,实时联动网络安全设备(如FW/上网行为设备)拦截,联动终端安全设备(如准入/杀毒)隔离查杀、断网.这时候突然发现安全产品不支持的,安全运营自动化、安全应急快速响应也就无从谈起。

开放性,实质的体现是安全产品接口化(API)或服务化(SDK).POC测试时可以让厂商提供功能能力开放接口化清单、demo测试模拟或者结合自己业务场景提接口化需求等。

安全性,是安全产品最基本的属性,也是最难的属性,具体是指安全产品自身是否有漏洞,是否经过安全测试保障其是安全的、可靠的。

最常见的问题如数据明文传输、接口验证机制缺少、RCE等在安全产品自身上出现的频次也是很高的(HW中频繁暴露的各种漏洞也反映安全公司在自身产品安全性的投入没有想象中那么多)如果按照OWASP TOP10的标准来评估,”惊喜”也不少.安全产品自身不安全,带来的潜在危害更大. 前期多辛苦,强过在安全运营阶段才发现选了一个功能中意但自身安全性差的产品,不时的催着乙方修复漏洞强,国内厂商修复的积极性还好,国外产品也只能吐槽吐槽了。

作为甲方,在POC测试时确实不方便投入太多精力进行产品”安全性”验证(资源丰富的大厂除外),除了后期通过SLA进行安全保证外,对于国内厂商,可以在POC时让对方提供国家专业测评机构出具安全测试报告作为证明.当然,欣喜的看到行业几位大佬也在着力推动将乙方安全公司的SDL建设或是否具备产品安全组织作为甲方安全产品选型的门槛,说明大家也看到了类似的问题。

安全产品是安全运营的基础,安全产品POC选出的不一定是最好的,最适合业务场景和最符合安全运营的才是上策。