讨论1：企业对安全厂商高危漏洞爆出事件怎么看？

1、听说某TY的产品架构存在漏洞，这个洞应该在某T手上，主要问题是出在主机灰度上，好像可以未授权访问，然后Agent是root权限，据说还没法改，懂得都懂。

2、关于第一点0day问题，我有一点不太一样的看法，之前有收到信息，某些厂商对某XF VPN设备做了拆解，破解，对某TY HIDS进行反编译<该条不细说，没具体证据>。由于安全圈子太小，人员流动大，增加了破解的便利性，所有要打市场的厂家，都会对潜在的竞争对手进行分析，对竞品做破解，这是中国企业商业竞争的传统了，我们也能理解。所以没有对出0day的安全厂商过多苛责。

3、作为甲方，我们会立即要求厂商过来修补，修补后，并验证poc是否有效。如果合同付款方式为3331 or 361，可能会依据合同内容进行扣除——+1，我这边确实也在考虑是否在合同里注明有未知0day应急预案。

4、我的一些思考：

（1）正视漏洞存在的客观性；
（2）和服务商进行沟通，确保有业务保障的应急方案；
（3）和运维团队（如果可能的话）一起评估风险，并制定紧急干预措施（如果可行）；
（4）事后复盘，评估服务商的综合能力。

5、我说下我的观点：我能够接受安全产品，因为是干安全这一行的，知道没有绝对的安全。但是我会比较关注厂商的响应情况，会不会主动联系修复漏洞、漏洞修复要多久等等，并且相关内容我们会希望能在合同里进行约束。另外补充一句，有点接受不了一些很简单很愚蠢的漏洞，证明厂商的产品体系是有问题的。

6、大佬们你们安全建设已经到如此高的地步了吗，关注安全产品自身安全性，我只想搞定弱口令和互联网暴露面。

7、产品有漏洞是正常的，主要是厂商要正视自己的漏洞，别遮遮掩掩，给人爆料之后态度还不积极，给甲方造成实际损失。规避的方法只有在采购的时候约束好出现问题后的响应速度，修复时间等措施，不要给自己留坑。——其实就算是自研，也没法避免漏洞，而且应该比成熟厂商的产品问题更多。

8、有一些设备和产品肯定要做好安全加固，把访问控制那些限制好了——但是很多安全设备的确是要权限的，而且要权限越多的设备，出漏洞的概率更高，这样演练中被盯上的可能性也更高。

9、安全产品本身是特权类的设备，更应该优先控制呀。而且如果因为安全产品管理不当，导致的安全风险和事件，就很尴尬了啊，会把在公司内部的权威性降低很多。

10、其实所有的问题都围绕着一个主题，增加攻击成本。如果增加攻击成本的系统本身出了问题。那么他就处于这个网络攻击链环之中了。

11、同一款安全产品这么多漏洞，反反复复的话，这一点我是会评估的。证明产品确实有些问题。

12、去年我还在乙方钓鱼钓到的甲方防守方案，邮箱是重点攻击目标。

13、企业对安全厂商爆出高危漏洞事件这样看，一方面越来越缺不了安全设备，一方面又束手无策，目前来说只能是又爱又恨。说实话安全厂商的研发能力总体不如软件公司，而且很多产品还有实习生参与，现阶段不能奢望安全设备自身的安全性有多强，和互联网公司比又没有留人的竞争力 一些老产品甚至都没人在维护了。

14、安全厂商爆漏洞是不可避免的，毕竟很多安全厂商的研发人员也不是做安全的，做出来的安全产品也一定会有安全问题，内部也不全是安全SDL流程。怕就怕供应商反应慢，厂商不承认，通知不到位。

讨论2：面对这类问题，企业是否会考虑在重点安全建设方面转向自研之路或者采取其他方式减轻0day事件带来的影响？

1、其实就算是自研，也没法避免漏洞，而且应该比成熟厂商的产品问题更多。

2、0day 目前建议有足够数量的安全人员的企业做。先把基础安全做好并优化以后，干的事情。毕竟需要人力和财力支持，一般企业重点还是把基础安全做好，策略规则优化监控告警为主。并不建议投入太多人力自研安全产品或者系统。应该往加大并优化监控范围（内部事件和告警、外部威胁情报等），以及自动化处理事件方向投入更多的时间，通过加快响应时间和处理效率，这种方式“曲线救国”。

3、在我们这边的话自研的可能性为零，但是会考虑采取其他方式减轻风险和影响，例如组网调整隔离，限制受影响的设备或服务的网络可达范围避免影响其他业务。

4、现在好多内网安全设备都启用了HTTPS如何监控它们没被搞？

——HTTPS的都把证书给到NTA设备做解密

——有一些设备和产品肯定要做好安全加固，把访问控制那些限制好了

5、其实为什么不做应用运行时自我保护。RASP就是一个很好的解决方案——但之前有些安全产品的漏洞都是些很基础的，可能还达不到RASP程度的漏洞。

6、其实现在安全产品走向容器化部署，本身就是个大势所趋——容器化就算产品有漏洞。你也只能拿到容器内的权限。

7、不能这么算，虚拟机还有逃逸呢，本地提权只是一种形式，还有网络层扩散的问题呢。

8、说实话，现在最怕服务器杀毒、pc杀毒这种强制人人都装的东西出问题，一出问题太容易闹大了。

9、关于第二个问题，我们对自研安全有一定的需求，但是没能力，所以短期不会上，合作研发，外包研发可能会有，之前提到某单位和某单位合作研发单兵作战工具就是例子，我们也期待这样的合作。短期我们解决0day的方式，是增加apt设备，对攻击行为进行识别，毕竟0day不具备可预见性，但是攻击行为是有一定模式的，目前部分厂商搞得攻击模型，机器学习等产品，我们都很感兴趣。

10、现在稍微有点钱的企业已经开始重金挖人，自研安全设备只是对内安全建设的任务之一，哪怕是重复造轮子，出了事好歹能自己修复，不然只能等厂家更新，甚至厂家会甩锅。而且只要造轮子的时候指纹不要抄的那么明显，那么被发现漏洞的几率会大大降低。毕竟大家都知道白盒能挖到比黑盒更多的漏洞。

11、发表一下关于第二个问题的个人观点：
（1）对于企业来说是否要自研安全产品，更重要的应该是安全团队是否有能力做这个事情，因为你至少要专门招几个专职做这些事情的人，在HC这方面或许就实现不了。
（2）产品自研成功后，便需要专人进行维护，假设之前产品的研发者离职了，于是需要重新招人，然后重新熟悉代码，再进行专职维护更新。
（3）假设是从0到1开始的，我觉得还是先买商业化产品，然后等安全团队稳定了，上面两个条件都满足了，再考虑是否自研。
（4）如果安全团队完全有能力，那么肯定还是要自研。

12、对甲方而言，肯定自建的产品最靠谱可控，有大厂已经在做或者投资安全公司在搞了，但是绝大部分企业没有这个能力，当前阶段能把基础的安全设施和体系建起来的公司就已经相当不错了。要减轻0day的影响考虑威胁情报和漏洞响应与管理这两块更现实一点。

13、目前很多厂家内部展开代码审计工作以及内部SRC。对于主打产品基本已经完成审计。安全随着产品审计员的技术而形成瓶颈。对外部而言，没有形成或者无法形成统一的安全等级要求标准，缺少相关的评测。

14、自研并不能解决出现漏洞、BUG的问题。关键还得看安全厂商的响应速度。火眼，卡巴，palo alto、checkpoint这些大厂没少出问题，态度很关键。安全开发、DevSecOps，说起来容易做起来难，微软不也沦陷了吗。

15、非头部企业很难自研，毕竟没有积累成本太高，且很多企业业务发展等不及你自建安全能力，采用成熟产品依然是多数企业的选择，对于供应商的安全要求，除了合同协议，服务质量也要求更高，技术支持最起码要专业到位及时响应，叫不动人的供应商还不如没有

FreeBuf甲方交流分享群

纯甲方：囊括金融、政府、运营商、医疗、互联网企业等多行业甲方安全从业人员，具备严格的入群审核机制，非甲方安全从业人员拒绝进群

真实有料：从甲方企业CSO到安全工程师，从安全方案应用到产品技术应用，社群定期组织相关主题话题讨论，共同交流最真实有趣有料的甲方安全建设经验

专属权益：一旦认证成为FreeBuf甲方会员，即可享受FreeBuf报告在线免费阅读权益，同时参与社群话题讨论便有机会获得FVIP月卡奖励。更多权益，期待解锁ing~

FreeBuf甲方群进群方式

扫码填写申请表单，通过审核后即可入群：