各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 219 期来了！FB 甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。
话题抢先看
SOAR 平台的建设是要独立建设还是会通过 SOC、SIEM 来集成 SOAR 功能，企业需要在什么安全建设阶段来推动 SOAR 能力的建设？
如果态势感知分析平台误报较高，SOAR 会不会因为误报对业务造成影响，有没有什么规避方法？
目前企业的安全设备厂商都是不相同的，SOAR 对接方法都有哪些，能做到开盒即用吗？
公司门店的数据/信息安全是怎么管理的？
话题一
有这样一个场景，企业的基础安全产品已经建设得差不多了，比如防火墙、WAF、EDR、态势感知、CMDB、漏洞扫描等，但是在某次攻防演练中还是被打的很惨，原因攻击队在完成突防之后就在内网埋了很多后门，通过分析溯源也没能把对方完全踢出去，最后被攻击队拿了标靶，企业的安全负责人想要提高一下各安全设备的联动和自动化响应的能力。
Q：SOAR 平台的建设是要独立建设还是会通过 SOC、SIEM 来集成 SOAR 功能，企业需要在什么安全建设阶段来推动 SOAR 能力的建设？
A1：
可以 SIEM、SOC、SOAR 一起搞吗？
A2：
我们的 SOAR 说是集成了现有的 SOC 以及 HIDS 一起搞的。
A3：
问题来了，自动化只是提高了响应速度，但突防埋后门无法完全踢出去，应该是好多个点都可以做细化的事情吧，具体还是得分析过程。
A4：
对，我觉得最少 SOAR 要放到最后搞，这个是实现自动化的。
A5：
核心问题是提升检测能力，尽快发现边界突破，而不是自动化响应吧。要用态势感知或者 SOC 把各类告警整合起来，提升精准告警能力，并进行处置，不是把各种设备都部署上，每天产生百万、千万告警没人管。
A6：
关键还是看人，产品只是工具，我们单位原来招的一个渗透就把这些工具玩的很溜，安全运营就是从他开始步入实质的，现在所有报警基本都是实时处理的。
A7：
基础差属于存量问题，只有分区分域逐步清理。
A8：
1、独立使用，集成使用均可，无非是效果好坏的问题； 2、SOAR 无论是单独使用还是集成使用的前提都需要企业的信息安全运营发展到一定规模，基础建设较全面，且安全设备给出的数据是有效，SOAR 才能发挥出相应的能力； 3、推荐美团中文师傅的《在企业安全建设中真的需要 SOAR 么？》，知乎可看。
A9：
关于这个问题，非要讨论出来个集成好还是独立好，我觉得基础有效数据要多，才能体现出 SOAR 的能力，理论上 SOC 和 SIEM 数据多，但是按照当前市场上产品的德性，集成不集成差别不大。
A10：
SOAR 就是一个安全自动化平台，是提高效率、增加人均单产的工具，如果告警都没理清楚，事件没处置，流程也很乱，那应该打基础，而不是做自动化。
A11：
对的，SOAR 还有一个最大能力就是提高人效。老板你觉得你们处理太慢了，常见的安全事件处置分析处理效率上不去，那么自动化是个比较好的方式。
A12：
SOAR 更多是提高效率，减少人工操作失误，搞之前要把场景定好，要考虑标准化流程，不然很难用起来。
A13：
通过 SOAR 进行安全告警处置，可以查询 ES，通过扩大时间窗口查询更多数据，对态势告警结果做验证，如果是恶意的直接封禁，判断不准转人工。
A14：
其实要不要上 SOAR 我觉得还要打一个疑问，毕竟安全编排自动化，对于现有安全设备都不能有效利用的企业，难道上 SOAR 效果会更好吗？编排剧本，能有效利用吗？
A15：
其实当前还有个问题，在一些阻断性的操作上，最好不不要用 SOAR，否则你会哭死的。
A16：
是的，一些场景下直接给你自动化阻断，让误报产生的效果直接放大。起码人工运营，还会分析。
A17：
我们的经验是，封禁前过一遍白名单，白名单只报警不封禁。
A18：
还有一个问题，是现有的安全设备能不能支持到自动化，连 API 都没有的话，自动化根本做不起来。
A19：
白名单不一定全的。
A20：
我司白名单已经比较全了，各业务的白名单都收集了几波了。
A21：
但是如果封堵一些遗漏在外的，你们还是会出现的。
A22：
白名单主要是 To B 的，可以通过数据分析自动更新。
A23：
封禁 IP 这种事情，除非你们的业务是不对用户的，且非实时的可以这么搞，如果是金融或者电商这类，我觉得一不小心就是个 P1、P0 级别的事故。
A24：
不是几波的问题，这种只是一种机制，但不能长久搞，更多还是要实际去运营，而不是依靠剧本去完成，剧本可以协助一些简单的告警自动化。
A25：
其实一线运营人员去判断事件，也就是那几个依据，做到 SOAR 里，一样的。
A26：
想要上 SOAR，基础能力就要好，基础能力好的话，也就不会出现溯源不了。如果基础能力不好，那上 SOAR 也就只能说是上了，没有太大的帮助。
A27：
提出这种问题的企业应该建设程度比较高了，我们假设他具备了一切条件，那么 SOAR 建议集成在 SOC，可以节约部署成本，避免数据不一致。 关于建设阶段，总结各位大佬的意见如下，达到如下阶段才可以考虑 SOAR 建设： 1、在不依靠 SOAR 的时候，安全事件能处理，只是慢或者无暇处理； 2、现有环境具备自动化条件，比如设备联动 API 及能使用 API 的人、可以确定置信度高的告警及动作，以免自动编排后影响正常业务。
Q：关于 SOAR 在企业落地到时候有哪些流程步骤，以及如何设计相应的自动化场景？
A28：
1、关于 SOAR 在企业落地到时候有哪些流程步骤： 第一步：有自动化的需求； 第二步：调研自动化及 SOAR； 第三步：测试验证 SOAR，同时形成误处置的回退或 bypass 方案； 第四步：对接部分安全设备应用于生产； 第五步：全面对接； 2、如何设计相应的自动化场景：（1）日常运营积累应急处置场景；（2）形成较为成熟的安全运营 SOP；（3）根据安全运营 SOP 形成 SOAR 处置流程；（4）测试验证 SOAR 的处置能力，形成误处置的回退或 bypass 方案；（5）上线应用。
Q：如果态势感知分析平台误报较高，SOAR 会不会因为误报对业务造成影响，有没有什么规避方法？ A29：
被骂是常态。要你保证承诺下次不会再自动封禁 IP 导致业务无法使用。最终你不得不加白地址，然后循环。
A30：
用 SOAR 可以降低误报啊，我们在事件处置中，对态势感知的告警，很多会用 SOAR 查询 ES 的方式进行二次判断，误报率反而降低了。
A31：
只有确认的情况才会进 SOAR，疑似的都需要判断。有些时候，SOAR 也不一定就是阻断，可以增加一些提示告警，或者增加操作确认。
A32：
本身 SOAR 流程也可以进一步帮忙分析，SOAR 应该帮助标准化的处置流程快速的进行。
Q：目前企业的安全设备厂商都是不相同的，SOAR 对接方法都有哪些，能做到开盒即用吗？ A33：
厂商 A 会把他的安全设备的所有 API 都开放给厂商 B 吗？反过来亦然。这个永远是个童话。就更别说乙方自己都乱糟糟，自己的安全设备接口都给不到自己的其他产品。
A34：
就算给接口了，还要对接，设备类型多了，时间成本也不小。
A35：
对接很大可能不行，防火墙 100 型和防火墙 200 型，接口都不一样，甚至都提供不了。
A36：
互操作性的国标是不是征求意见了？
A37：
很难落实。
A38：
我见过最好的 SOAR，就是微软的安全全家桶了，基本给钱就可以。
A39：
要用 SOAR，人、流程、工具缺一不可，所以卖 SOAR 不能卖产品，只能卖整体方案。
话题二：有没有生产制造业的大佬， 想交流一下公司门店的数据/信息安全是怎么管理的？门店基本都是加盟的，公司没有直营门店，天猫/京东/拼多多倒是公司内部人员管理的
A1：
我们直营店还好管理，合作的经销商比较麻烦，很多约束传递不过去。
A2：
门店终端，统一门户访问。
A3：
突然觉得你们这种很适用 SDP 场景啊。门店终端，同意门户访问你后台进行业务操作，那么用过零信任方案，通过合规基线检测保障终端的安全，通过 SDP 远程接入到内部网络（实时用户行为分析），控制授权至门店进行访问，多支点随时接入。
没有网络改造需求，至于你们平台上的数据安全，这个我碰到过这个问题，你们肯定会把平台上的数据下载下来，到自己平台分析。发货等业务行为，把这套系统管好了就行了，用户授权，日志审计，用户操作审计，数据库数据脱敏反正这些操作也是大佬们都知道的。
A4：
大部分连锁企业都是有自己的系统和平台，加盟/直营用的都是同一套系统，只是后台数据不一样，通用点的就是连锁 ERP 系统，既然系统是自己的，所产生的数据也自然是自己的，这个信息安全的管理也就是集团内部消化了啊。
A5：
如果没有终端的话，仅仅系统，其实各个门店使用系统的模式有点像用 SaaS 服务，数据其实是托管到总部 ERP 系统的，这更侧重对这个 SaaS 系统的防护，当然网络层面最好做好区域隔离啥的，能不对外最好不对外。
A6：
是的，刚好 SDP 还可以做攻击面收敛。
本期观点总结
本期话题中，大家认为建设 SOAR 平台可以独立进行，也可以通过集成现有的 SOC、SIEM 等安全设备。在建设之前，应解决基础问题，如提升检测能力、改进告警整合和处置流程等。在设计自动化场景时，可以结合日常运营经验和 SOP，形成 SOAR 处置流程。对于态势感知平台的误报问题，可以利用 SOAR 查询 ES 进行二次判断，增加确认步骤以规避误报对业务造成影响。而对接不同厂商的安全设备可能需要定制开发，开箱即用的情况较难实现。
关于公司门店的数据/信息安全管理，尤其是加盟门店，可以使用 SDP 技术进行终端安全管理；加强对平台数据的管控。若在没有终端的情况下，则需要重点保护 SaaS 系 统的安全。
近期群内答疑解惑
Q：有个问题问一下，我们之前已经在 APP 或者小程序里面让用户同意了隐私政策了，现在新开发了一个 H5 页面，用来让客户自己修改自己的邮寄地址，这种页面需要让用户重新授权同意隐私政策吗？ A1：
敏感信息收集需要重新授权，其他的在隐私政策里面写清楚就好了。
A2：
原有的协议已经包含这部分信息了，应该可以不需要。
A3：
不是新增或者新场景收集，可以不需要。只是给了编辑信息的功能？
A4：
是的，就是一个变更。
A5：
我个人理解是不需要的，因为邮寄地址填写的时候，如果已经签署的隐私协议，修改应该不需要。如用户注册时，协议已经包含以上场景，也应该不需要。
A6：
注册时肯定是同意过的，场景也没变。
A7：
如果怕不保险，可以在用户首次登录和填写敏感信息的时候，让用户确认一次，双保险。
A8：
你这个是变更邮箱地址，和电商平台变更外卖地址有区别吗？这种场景还得你自己分析一下。
A9：
电商平台他们改地址，是在自己的 APP 或者小程序上面，这种功能在勾选隐私政策时，就已经向用户授权过了，但是我们这个是一个新的页面，没有和 APP 或者小程序绑定在一起，场景还是不一样的。而且就算是我们以后和 APP 或者小程序绑定在一起，你新加了个功能上去，照理说是需要重新向用户授权的，所以也是需要重洗授权一次。
A10：
我们的经验是重新授权。我们的 APP（小程序、H5）每个月都送检。
Q：大家平时用的证书都是用通配的证书，还是按照单个网站单独申请一个证书呢？这两个对于网站的管理风险是否会有区别和影响? A1：
通配符从技术角度没影响，从管理角度只会更方便，从价格方面，有点贵。
A2：
那有没有可能，有人会对通配证书管理上非法操作，影响其他网站的安全性？
A3：
你的二级域名通配符，怎么非法操作，这个角度我还真没考虑过。
A4：
毕竟通配的证书，谁都可以去操作吧，对于管理上是否会有风险？
A5：
泛域名也是可以的、重要是解析是否掌握、否则域名资产就是糊涂账了。
A6：
你说的这个证书是 CA 证书吧，Https 用的那个是吗？
A7：
对，是 CA 证书。
A8：
就一个风险，你的某个二级域名被别人用了，然后别人正好拿到了你的证书，然后盗用，不花钱。可是问题在于，你的二级域名解析也在自己手上，除非监守自盗。
A9：
对，我说的就是监守自盗的情况。所以，从安全角度来说，是否单独 ca 证书会比通配更好？
A10：
是的，但是多花钱。
A11：
单域名证书安全性高，成本也高。
A12：
单价会低一点，但是企业都有一堆二级域名，就整体贵了，而且页面互相调用，增加了开发的证书调用配置复杂性，安全性肯定好多了。
A13：
私钥在服务器上，权限有可能在项目交接中出现问题。
A14：
证书管理的问题吧，个别系统只能证书在系统本地，有负载均衡的话可以挂负载均衡上，统一管理，减少风险，变更起来也容易（一年一换）。
Q：容器资产业务跑在 K8s 上的，资产收集维度是到哪里了？ A1：
蛮难的，容器的生命周期很短，拉起的 IP 会有变化、一般只能关注到 Node 这里，如果有购买容器安全类的产品能管理到。
A2：
Service 是稳定的。
A3：
对，应该对微服务可用性做监控，容器上上下下太频繁。
Q：应用日志当中的敏感数据处理相关的规范或者措施，大家工作中有做过吗？ A1：
您是想说应用日志脱敏么？
A2：
是的，应该就是日志脱敏这个事。
A3：
日志管理系统用的啥？ELK？SPLUNK？
A4：
ELK 怎么脱敏，这个也困扰我，大佬两个能都讲讲吗？
A5：
1、直接在源头脱敏，专项针对重要的应用系统字段进行检查改造，脱敏相关字段；
2、ELK 的话可以在 Logstash 里好像是能配置进行脱敏。
A6：
这个目前是不同的公司不一样是吗？有没有可公开的规范或者有做的比较好的规范文档？
A7：
不是公司的问题，理论上是业务形态的问题，不同业务形态的公司，对于敏感数据的定义重视程度不太一样。公开的没有。
A8：
我们都是把日志统一牵引至审计平台，至于相关规范没怎么关注过。至于如果你需要脱敏，可以找一款商用的日志管理平台，应该可以实现脱敏和管理。
A9：
发现我们是有的，但是没有用，说太影响业务了。
A10：
那就用起来，先测试影响多大，就类似 KMS 加密机之类的，针对一些重要的，就算影响，你该做加密的还是要做的。
A11：
能不能从规范搞起来？
A12：
自己写一套规范，主要如何定义敏感信息是一个大问题。