各位 Buffer 晚上好,FreeBuf 甲方群话题讨论第 205期来了!FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论,Kiki 群助手每周整理精华、干货讨论内容,为您提供一手价值信息。
![](https://i-blog.csdnimg.cn/blog_migrate/6a97995b3ef82bb23b843a913acb4e6f.jpeg)
话题一:在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。