SIEM/SOC核心需求匹配；K8s的作用到底几何？| FB甲方群话题讨论

▎各位 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，备注：甲方会员

FreeBuf甲方群成员（因篇幅限制仅展现部分行业成员）：

金融行业：贝宝金融 安全负责人、成都农商银行 信息安全负责人、晋商银行 安全负责人、北京银行 安全负责人、君龙人寿 技术负责人、合合信息 合规负责人、合生 信息安全负责人、航天产业投资基金IT负责人、工银金融 信息安全负责人、前海联合基金 信息安全负责人、天弘基金 安全负责人、阳光保险 信息安全部负责人、南京证券 安全负责人、宝马金融 信息安全经理  

运营商：中国联通 网络安全主管、中国电信 信息安全技术主管、上海电信 网络安全主管、天津电信SOC主管、太平洋电信 研发总监

互联网：云畅游戏 信息安全总监、飞点网络 技术总监、聚水潭科技 信息安全总监、诺亚控股 业务安全中心总监、哥伦比亚中国 信息安全总监非夕科技信息安全总监、赫基国际 信息安全部负责人、熵通科技 信息安全负责人、建发集团 信息安全经理 

其他：大学长教育 数据安全与合规总监、温州城市大学 信息技术服务中心科长、作业帮 安全负责人、同程艺龙 安全总监、新奥集团 安全总监、中译语通 安全总监、集贤科技 安全总监、德邦快递 安全总监、盒子科技 安全总监、猎豹移动 安全总监、蚂蚁集团 实验室负责人、结行科技 数据安全负责人、苏宁 网络安全经理、新浪 网络安全经理、吉利汽车 信息安全经理 

精彩推荐