各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 205期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

上期精彩内容请点击：如何应对应急响应审计；WebShell检测与控制思路

话题抢先看

1. SIEM/SOC功能是否越多越好，应该从哪些方面考量自身核心需求？

2. 如何丰富SIEM/SOC中的UseCase，同时避免无效的UseCase增加工作量？

3. 个人信息保护认证和dsm认证有没有必要同时弄？

4. 运维总监怒怼开发：你真的需要K8s吗？大家对此如何看待？

话题一：在SIEM、SOC中建设中，乙方往往会强调场景覆盖度、告警准确度、处置自动化程度等，作为甲方，这些功能是否越多越好？应该从哪些方面考量自身的核心需求，并做好持续迭代的过程？

A1:

我们主要看精确度，再来个自动化   主要看自定义的粒度能不能做到很精细。

A2：

关注告警准确度，在不降低漏报率的情况下，尽量优化规则降噪；处置自动化，不知道落地的甲方多不多，我也不敢用。

A3：

这应该是日常运营要做的事情，提高准确率，降低误报率，这是一个对抗的日常，暗链监控和管理，本质上就是流量分析和流量过滤，只有根据自身业务的特性，建立自己的业务流量过滤规则才能逐步减少误报率，比如标记特定的流量、可信的URL、有效的访问、不同IP多次访问相同URL、请求和流量返回值大于指定值为白名单，我目前都是通过日常运营去补充，产品都差不多。

A4：

人家的SOC要是有的功能，你没有，说出去多丢人啊；多多益善，管它好用不好用，反正有运维的。

A5：

功能要和甲方的业务场景、安全需求适配，不然功能越多安全越乱。核心需求要从从业务需求、监管要求、安全发展等方面来看。

A6：

场景覆盖度、告警准确度、处置自动化程度，这些需要跟甲方一起定制化开发，才能更贴切需求，也不是越多越好。
觉得开放性很重要，因为等保里也有建设安全管理中心的需求，能够比较开放的接入各种设备、日志、支持甲方用户进行一些插件化的自开发，更能支持甲方工作。

A7：

场景覆盖度、告警准确度是核心，但这些东西，乙方其实给不了你，乙方能提供你一个工具平台，但要是想着把场景也丢给乙方，其实啥都不重要了，第一步就挂。

A8：

功能多多益善，前提是能落地，同时场景与企业业务相匹配。大部分此类产品，场景并不丰富，多是以少数特定行业的某几个标杆案例作为依据。

甲方缺工具平台，乙方缺场景，这是客观事实。举例，前几年终端准入，某NAC厂商号称瘦终端标识覆盖率99%，实际上应该加上能源行业的定语。

A9：

其实很麻烦的，你有场景了，还得有数据。数据是不是够，是否可以格式化，清洗后入库，还要能支持各种索引下钻，然后才能谈到准不准确，就这一堆活，没个趁手的平台和基础数据能力，其实买啥都无所谓了。

A10：

日志清洗也是个长期工作，中小企业，专门设置一个人做日志清洗，这种岗位公司角度恐怕老板不会批，个人角度也没人想一直做这种重复性工作。

A11：

我们倒不是设置一个人做日志清洗，这样干着干着就跑了。我们是每个人对场景负责，从数据采集到清洗，一直到最后出告警准确率，都是他一个人，每人负责若干个场景，除非是公用基础数据，那就指派一个人来建设。这样的好处是他从头到尾，自己能拿成绩。

A12：

功能是否越多越好？答案是否定的——就算把市场上所有的安全产品都买了，全也不一定搞得好，所以这不是功能多少的问题。

针对后一个问题，从哪些方面考量自身核心需求，并持续做好迭代过程？——个人思路是：核心需求的考虑，应该从企业本身出发，安全是依托于业务和场景的，首先梳理下当前的业务，业务中的资源有哪些？这些资源的最低安全标准是什么？安全场景是什么？需求是什么？-经过以上工作，可以定义公司的安全战略/策略，有了安全策略，才知道往哪个方向走，也明白了核心需求是什么（个人感觉很多公司都有这个问题，安全一直在做，但是安全策略或安全目标是什么却没有一点概念）；持续迭代就根据业务需求的变化/场景变化去迭代就行了，前提是符合既定的安全战略（当然安全战略是需要定期评估的）。

A13：

做好核心需求的情况下，又不影响业务效率，有用的功能越多就越好，但目前应该处在能解决核心需求先，锦上添花的功能暂时不要做太多的好。

核心需求上，覆盖是基本的，告警准确度是越高越好，自动化智能化处置的前提，必须要依赖准确度。

Q：SIEM、SOC中默认的的UseCase（用例）往往并不能解决实际需求，该如何丰富UseCase，同时避免无效的UseCase增加工作量？

A14:

见过一个企业让每个系统负责人提交一定数量的UseCase，比如每个系统要提交十个或者二十个，然后实际使用中慢慢调整优化。也就是先解决有没有，再解决好不好。

A15：

安全不能闭门造车，还是要认清服务业务这个路，UseCase的无效是没分清楚优先级和不了解业务过程。先解决救火问题立竿见影的问题，从设置这些UseCase开始，然后挑选重点业务条线让业务列Top3的安全痛点问题（别贪多），再形成UseCase。
大致思路应该是聚沙成塔，不是全面撒网，产品其实每家都差不多，就看适不适合自己公司。

话题二：个人信息保护认证和dsm认证，大家觉得有没有必要同时弄？

A1：

还是不一样的，一个是数据认证，一个是个人信息认证，可以同时弄。

A2：

前者作为基础，优先吧，可以问问开发人员有没有解决方案。

A3：

可是，个人信息是属于数据的一部分，个人信息都搞定了，是不是意味着数据也OK？

A4：

信息用途不一致啊，而且数据安全包含个人信息，但是个人信息肯定不包含数据安全。

如果你们的个人信息有一定商业用途，譬如根据收集到的个人信息做用户画像，那么生成的画像也是作为公司大数据精准推送的商业用途，那么这个产出还是客观的，如果不作为商业用途，那遵照最小化收集就好，数据就包含太广了，本质你公司所有产生的数据都是，通过分类分级保护管理，这个对于有些公司是必要项，所以是必须要做，至于认证，只是增加检验审计得一道机制还有一个公信力，通过第三方检查结果来判断是否达到一定要求水平。

A5：

其实具体到单位，这个认证一个给监管或外审看的，也与企业业务开展挂钩，因为有提供SaaS服务业务，公众可信度企业形象能有提升。

Q：没有现成的工具可以通过分析代码拿到一个数据衍生路径的？举个例子，用身份证号解析出了生日，身份证号作为源数据，生日作为衍生数据，有工具可以找到这样的映射（Id→Birthday）关系么？

A6：

只要能找到这样的映射关系，数据通过正则匹配可以吗？

A7：

主要是找字段的映射关系，字段名不标准化，某些数据（尤其是衍生数据）不一定有标准格式。正则的前提是你知道有哪些衍生数据以及其命名或数据格式了。

A8：

不知道有没有现成工具，但思路上是不是可以代码或函数的输入输出来判断呢？输入身份证号且输出生日信息，就可以很大程度判定是有衍生关系了。

话题三：最近在某乎上看到一个问题觉得比较有意思，运维总监怒怼开发：你真的需要 K8s 吗？想问问大家对这个问题的看法。

A1：

不需要，我们都是让运维总监一个个去操作Docker的。

A2：

K8s可以快速部署环境，更好地剥削运维，1个运维可以干10个运维的活，起到降本增效的作用。

只知道这个，其他都不知道了。我们有个很少人的部门，1000多个产研，才配4个运维，没K8s应该是顶不住。

A3：

有弹性可以扩缩容需求的可以上K8s，比如腾讯云上的漏扫，据我所知就运行K8s里，根据负载的容量自动扩缩容，节省成本。一些API Service之类的，用K8s也很合适，挂了自动重启，前面放一个Ingress处理负载均衡的问题，再设置一下自动阔缩容，运维成本少了很多。还有一些特性，比如灰度上线，版本回滚之类的。基于K8s也很方便。

玩这些的前提是有开箱即用的K8s平台（比如公有云的服务），如果自己养团队去维护和定制K8s，那就是另外一回事情了。

A4：

K8s云原生，就是最大限度压榨服务器资源利用率。

A5：

未必，Java这种大内存的业务，最终结果就是内存占满，但是CPU利用率依然上不去。

A6：

前司我在的时候就是用的传统部署模式，反正交付一套环境给测试部门是要一个多星期的，要申请服务器、数据库等资源，准备域名，开通端口，还要排查故障解决依赖问题等杂七杂八的事。现在上了K8s应该是2、3天一套环境。

A7：

K8s就是大家想赶个时髦，实际上以国内大多数公司的工程水平，用不到K8s的优点。最终的结果就是剩下一堆很久没升级，无人维护的K8s集群。在干掉运维这个方向上，K8s倒是不错，就是可能要累死安全了。

A8：

这个说法我认可，核心业务都不会上K8s，都是无关紧要的拿来做做试验那些。

A9：

我这边倒是纯K8s，核心业务也是K8s。

A10：

我这边的经验就是的确部署会很省心，然后Pod自动拉起也很省心，但并不省钱，然后监控方向上更加不省心。

A11：

就是监控不好做，还有流量管控需要借助Isito，K8s自带的东西不太好用。

Q：那问题来了，到底K8s给企业带来的效益和传统虚拟化相比，具体增加的效益是什么？能举个例子说明吗 ？

A12：

提升资源利用率，灵活弹性缩容扩容。

A13：

弹性这个吧。Node节点你得先弹性了，这个能做到多少？能做到Node的弹性的，其实也不需要K8s来弹性。Pod级别的自愈这个没说的，的确做到了。

A14：

Pod的和Supervisor有区别么，是程序自恢复么？

A15：

不太一样。因为Supervisor也会挂，跟Systemd倒是可以比拼一下，但是你得处理服务器挂掉的情况。用了托管Node节点的，托管K8s就能解决这个问题了。Node节点服务挂了会自动补上去。Pod挂了，K8s会帮你拉起。

但是国内云有托管Node节点组的吗？ AWS是有的，这个比较省心。

不过我说的前提都是托管，如果都是自建，其实差不多，还不如Supervisor简单可控。

FreeBuf 观点总结

甲方企业在购买安全产品及服务时，始终是要依托自身业务和场景，为自身需求服务，而并非一定功能越多越好。即使在需求不是特别明确的情况下，告警准确度、处置自动化仍是十分必要的基础需求。至于其中的UseCase，无论是先积累、再优化，还是先聚焦立竿见影的问题，无论如何最终的结果都是要聚沙成塔，逐渐丰富切实有用的UseCase。

虽然近些年热门的K8s理论上可以让应用的部署和运维更加方便，但在大家的实际运用中K8s作用到底几何，答案似乎因企业技术架构和具体业务而异，并没有标准结果，但落脚点也很清晰，就是在没有水平或业务的情况下，不要为了K8s而K8s。

本期话题讨论到此结束啦~此外，FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！

【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】

注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf2022，备注：甲方会员