☝戳链接了解本期征文详情
黄乐
十年网络架构设计经验,五年安全体系建设及管理经验,清流派企业安全沙龙创始人,两个安全公众号主理人。
在央视网主要负责网络安全架构的设计和建设。主要包括攻防对抗技术研究、安全检测及防御体系建设、安全播出管理平台建设、漏洞治理平台研发、威胁感知平台研发、应急响应系统研发等工作。同时,提出了“重检测,轻防御”的安全架构设计理念,并通过“快速及格、逐步迭代”的思路快速落地了央视网安全播出管理平台。
清流派企业安全沙龙是安全行业甲方闭门沙龙,每月邀请各企业安全部门负责人从多个方面探讨企业安全建设及管理的思路和经验。
POC,即Proof of Concept。直译成中文一般可称为“概念验证”,在企业中,技术团队经常通过POC来验证产品功能和性能是否符合预期。由于笔者长期以来一直负责安全工作,所以本文将从企业安全团队的视角看看安全产品的POC应该做到和注意哪些方面。
一般情况下,企业从无到有,采购一款产品一般分为如下几个步骤:
① 技术需求(通点)确认,立项确认采购需求;
② 寻找并确定目标范围;
③ 线上or线下技术交流;
④ 产品测试(POC)
⑤ 采购(单一来源,竞争性谈判,招标等)
⑥ 使用
我们可以看到,POC是采购前最后一个环节。当然,也有些POC会放到采购环节之后(对即将购买的产品进行POC测试)。一般来说,POC是甲方对产品了解和信任的重要环节。但谈论POC还要从上一个环节,也就是技术交流谈起。
大部分情况下,在POC前,甲乙双方一定会进行一次或多次技术交流,以便让甲方对产品有基本的了解。不得不承认,安全行业创造和落地新概念的速度非常快。笔者经常在刚刚了解一个概念后发现,几乎所有厂商都有相关的产品了。但在认真了解后,脑子里仍然有很多问号,比如:
• 态势感知为什么只有威胁感知的能力?
• APT检测为什么只是沙箱的变种?
• SOAR除了联动以外,编排能力如何落地?
• 零信任铺天盖地,在网络层到底能否做到零信任?
……
当然,有些问题确实是笔者才疏学浅无法理解真谛,但诸多安全产品中也不乏一些蹭热点的产品存在。只要稍稍留心,企业安全团队在前期交流时是可以了解产品的真实能力的,主要可以从如下几个方面入手讨论:
① 技术原理:从笔者的经验看,绝大部分产品都不会有很颠覆性的“黑科技”,尤其要符合计算机的基本原理。比如,笔者在交流一款资产管理的产品时了解到,做全端口(1-65535)探测的时间是常用端口(约几十个)探测的时间的几倍而已(具体数字记不清了,但肯定不到10倍)。这就需要详细的了解一下技术细节了,事实证明是售前将数据记错了。所以,越是感觉拥有“黑科技”的产品,在交流时越要沟通一些技术细节,如果真有过人之处,在POC时需要格外留意一下。
② 产品化程度:有一些技术能力很强的团队孵化出的产品,往往具备很强的基础能力,但由于产品化做得不够好。很多厂商对此不以为意,认为核心技术有了,是否拥有漂亮的“皮囊”并不重要。事实上,一个工具到产品的过程并不仅仅是增加了一副“皮囊”,而是要在易用性、稳定性、可读性等多个方面进行优化。产品化做得不够好,意味着企业在使用这些产品时,将付出额外的时间成本,也就是人力成本。这对很多人手本来就紧张的团队来说,是个不可小觑的问题。
在完成前期交流,对产品有了一定了解后,一定会筛掉一些从前期看就不符合要求的产品,剩下的产品就可以进入POC环节了。宏观上区分,测试无非是功能测试和性能测试,我们分别来看看:
2.1 功能测试:
① 基本功能:根据甲乙双方前期的沟通情况,根据功能列表逐条测试,一般情况下比较简单。但检测类的产品涉及到测试数据的准备问题,对于还没有能力准备数据的团队,可以采用厂商准备好的数据,再将多家厂商的数据进行融合,或者干脆交叉测试。
⑦ 效率:前文提到过,产品的使用效率对于企业来说也非常重要。测试团队可以模拟日常工作场景测试产品效率,可以测试的环节可以有:不同功能的点击次数,系统反应时间,功能按钮是否符合一般人使用习惯等。
⑧ 灾难恢复:尤其对于防火墙,WAF,IPS之类串接的产品来说,灾难恢复是一个非常重要的测试环节,无论是主备切换还是bypass,都要进行比较全面的测试。一般来说,设备断电的测试成功率较高,但压力过大切换bypass的策略,各个厂商都有不同的策略,测试的时候应该格外注意。
2.2 性能测试:
对于非管理类的安全产品来说,经常需要处理大量的流量,性能测试是必不可少的。需要注意的是,性能测试前要打开所有未来可能用到的安全组件,以测试极限情况下的产品性能。性能测试常见参数如下:
① 吞吐:这是产品最基本的能力,但吞吐能力采用大包和小包测试的效果会有质的差别(数据包越大,测试结果越高)。所以建议企业根据实际使用情况设置发包大小,如果不确定可以干脆使用小包测试。
② 并发连接是和新建连接数:很多安全产品(如:防火墙,WAF,IPS等),除了测试吞吐外,还需要测试并发和新建连接数。尤其在支撑突发活动的时候,相比保持并发连接占中内存,新建连接的握手需要耗费宝贵的CPU资源,所以一般情况下新建连接数会远小于并发连接数,经常是整个系统的瓶颈。打个比方,并发连接相当于一个房间可以容纳的人数,而每秒新建连接相当于每秒可以进入房间的人数(取决于门的大小)。在极端情况下,房间还没满,但是由于门太小,门口挤满了人还是导致拥堵。所以在测试过程中要尤其关注对新建连接数的测试。(并发连接能力与新建连接能力示意图如下)
写在最后
POC是企业安全团队日常工作之一,但大量的POC测试会极大的占用安全团队的工作时间。所以,笔者一直希望探索一个帮助企业安全团队高效完成测试的方式。目前行业内还没有很成熟的方法,但是已经有很多组织在做不同的尝试。最后,衷心感谢这些组织,为安全行业做出的贡献。
注:本文为原创投稿,获1500元稿费,同时有机会角逐本期征文最终万元大奖。
三月主题:《数据安全面面观》
四月主题:《一个人的安全》
五月主题:《网络安全“值钱”吗》
七月主题:《社工记》
十月主题:《攻防演练实务》
十一月主题:《不会做规划,怎么做安全》
六月主题:《红蓝对抗中的心理博弈》
九~十月主题:《POC轶事》
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论