[转载]乙方产品“痛点”思考

年初进入一家乙方安全公司，一进来就进入“小黑屋”开始参与PRS的研发工作。
从一名初创公司的“全栈”转到安全研究和安全开发，也有了很多思考。
安全产品也没有真实使用过太多，仅从其他很多讨论和场景进行我的一些思考。
1.乙方公司缺乏真实数据，仅这一点，从出发点可能就会遗漏，忽视很多重要的思路，全靠自己“脑补”，无论是产品还是背后的逻辑。
2.产品严重依赖正则等规则，一来难以维护，大多都是拿来就用，有没有用自己也不清楚，难以测试，例如Snort中很多规则是非通用性规则，多为针对某一种应用的，但是也许该应用在国内并不常见，或者客户使用的真实场景并不存在该应用；二来规则数量庞大，难以扩展，比如需要和资产模块进行联动，减少正则匹配数量，需要对规则增加资产标签，甚至详细到版本，其他环境等，但是难以增加，导致很“僵”。
3.还是规则的问题，例如PRS，在内网部署，难以识别流量来自外网还是内网，在这种情况下，很多正则其实是不恰当的，比如什么Content Leak或者File Leak类型，或者其他类似场景，若内网情况下并不能算是“受到攻击”；还有问题就是面对庞大的流量和正则，性能上会受到极大的考验。
4.还还还是规则的问题，很多规则的问题，也许规则可以识别到很大程度上的攻击行为，但是如果出现了无论是0day也好，是一些奇奇怪怪的奇技淫巧也好，终归是难以识别到这些真正的高级威胁。
5.漏报，误报，就不说了。
6.其实准确的“报”也是存在问题的，例如“or 1 = 1”,你报还是不报？或者“select * from test”，你报还是不报？第一个确实是攻击行为，但是也许甲方的环境下根本不会造成威胁，类似的还有很多很多，网上扫描器千千万，全都报？那还让不让人用了，每天十几万几十万的报警，全是这种，即使你说可以让用户手动关闭某一条规则，那那么多规则，一条条去关，就算真的全关了，万一在某个特殊环境下又“or 1=1”又可以起到攻击效果了呢？怎么办。因此私以为，攻击行为需要判断他是否造成破坏，或者在甲方环境下的威胁程度，这个可不是一条正则可以判断的了，需要通过返回信息，信任链等等方法去判断了。第二个例子，如果不是用户从前端发送的，看起来并不是攻击行为，但是如果某台server被入侵了呢？然后顺藤摸瓜拿到了db server的密码，开始脱裤呢？这依然是规则无法触及的地方。

我认为，规则是能少就少，而不是像现在很多安全产品公司一样，能多就多，越多越好，应该是行为判断加信任链为主，规则用来判断对于规则来说最有效的，最方便的，用行为难以识别的东西。

现在越来越多的甲方开始选择自己来做安全，自己招人，贴合自己业务开发针对自己痛点的安全产品，因为买来的设备不好用，报了一堆没用的，真正的攻击还识别不到，这就很难过了，况且很多安全问题越来越偏向业务，比如薅羊毛，反垃圾等等，这些对于市面上的安全产品，几乎做不到。

因此将来的安全产品应该是，个性化，可配置，支持二次开发，或者支持自己添加模块，支持多款设备联动，哪怕不仅仅是自家的设备，或许将来会有标准吧，目前来看是不太可能的，对于海量的数据，也可以进行聚合，关联分析，不仅仅可以分析出有攻击向量的payload，还可以分析出更多，从更多维度去分析，频率，来源，响应内容，等等，有学习阶段，可以去在不同的环境下学习生成个性化的模型，我不是说一定就是机器学习，也许可以有更简单的方法实现，再通过配置和模块化开发，联动加上对于业务的敏感，这才是安全产品。

好了，扯淡结束，为了加薪，为了消除贫富差距，为了部落，还是老老实实写代码去吧～

• Post author: E_Bwill
• Post link: http://www.ebwill.com/2017/07/14/048/
• Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 3.0 unless stating additionally.