本期话题抢先看
1. SOAR平台的建设是要独立建设还是会通过SOC、SIEM来集成SOAR功能，企业需要在什么安全建设阶段来推动SOAR能力的建设？
2. 如果态势感知分析平台误报较高，SOAR会不会因为误报对业务造成影响，有没有什么规避方法？
3. 目前企业的安全设备厂商都是不相同的，SOAR对接方法都有哪些，能做到开盒即用吗？
4. 公司门店的数据/信息安全是怎么管理的？
有这样一个场景，企业的基础安全产品已经建设得差不多了，比如防火墙、WAF、EDR、态势感知、CMDB、漏洞扫描等，但是在某次攻防演练中还是被打的很惨，原因攻击队在完成突防之后就在内网埋了很多后门，通过分析溯源也没能把对方完全踢出去，最后被攻击队拿了标靶，企业的安全负责人想要提高一下各安全设备的联动和自动化响应的能力。
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的人、可以确定置信度高的告警及动作，以免自动编排后影响正常业务。
A28：
1. 关于SOAR在企业落地到时候有哪些流程步骤：
第一步：有自动化的需求；
第二步：调研自动化及SOAR；
第三步：测试验证SOAR，同时形成误处置的回退或bypass方案；
第四步：对接部分安全设备应用于生产；
第五步：全面对接；
2. 如何设计相应的自动化场景：
（1）日常运营积累应急处置场景；
（2）形成较为成熟的安全运营SOP；
（3）根据安全运营SOP形成SOAR处置流程；
（4）测试验证SOAR的处置能力，形成误处置的回退或bypass方案；
（5）上线应用。
A29：
被骂是常态。要你保证承诺下次不会再自动封禁IP导致业务无法使用。最终你不得不加白地址，然后循环。
A30：
用SOAR可以降低误报啊，我们在事件处置中，对态势感知的告警，很多会用SOAR查询ES的方式进行二次判断，误报率反而降低了。
A31：
只有确认的情况才会进SOAR，疑似的都需要判断。有些时候，SOAR也不一定就是阻断，可以增加一些提示告警，或者增加操作确认。
A32：
本身SOAR流程也可以进一步帮忙分析，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还可以做攻击面收敛。
关于公司门店的数据/信息安全管理，尤其是加盟门店，可以使用SDP技术进行终端安全管理；加强对平台数据的管控。若在没有终端的情况下，则需要重点保护SaaS系统的安全。
A1：
敏感信息收集需要重新授权，其他的在隐私政策里面写清楚就好了。
A2：
原有的协议已经包含这部分信息了，应该可以不需要。
A3：
不是新增或者新场景收集，可以不需要。只是给了编辑信息的功能？
A4：
是的，就是一个变更。
A5：
我个人理解是不需要的，因为邮寄地址填写的时候，如果已经签署的隐私协议，修改应该不需要。如用户注册时，协议已经包含以上场景，也应该不需要。
A6：
注册时肯定是同意过的，场景也没变。
A7：
如果怕不保险，可以在用户首次登录和填写敏感信息的时候，让用户确认一次，双保险。
A8：
你这个是变更邮箱地址，和电商平台变更外卖地址有区别吗？这种场景还得你自己分析一下。
A9：
电商平台他们改地址，是在自己的APP或者小程序上面，这种功能在勾选隐私政策时，就已经向用户授权过了，但是我们这个是一个新的页面，没有和APP或者小程序绑定在一起，场景还是不一样的。而且就算是我们以后和APP或者小程序绑定在一起，你新加了个功能上去，照理说是需要重新向用户授权的，所以也是需要重洗一次授权。
A10：
我们的经验是重新授权。我们的APP（小程序、H5）每个月都送检。
A1：
通配符从技术角度没影响，从管理角度只会更方便，从价格方面，有点贵。
A2：
那有没有可能，有人会对通配证书管理上非法操作，影响其他网站的安全性？
A3：
你的二级域名通配符，怎么非法操作，这个角度我还真没考虑过。
A4：
毕竟通配的证书，谁都可以去操作吧，对于管理上是否会有风险？
A5：
泛域名也是可以的、重要是解析是否掌握、否则域名资产就是糊涂账了。
A6：
你说的这个证书是CA证书吧，Https用的那个是吗？
A7：
对，是CA证书。
A8：
就一个风险，你的某个二级域名被别人用了，然后别人正好拿到了你的证书，然后盗用，不花钱。可是问题在于，你的二级域名解析也在自己手上，除非监守自盗。
A9：
对，我说的就是监守自盗的情况。所以，从安全角度来说，是否单独ca证书会比通配更好？
A10：
是的，但是多花钱。
A11：
单域名证书安全性高，成本也高。
A12：
单价会低一点，但是企业都有一堆二级域名，就整体贵了，而且页面互相调用，增加了开发的证书调用配置复杂性，安全性肯定好多了。
A13：
私钥在服务器上，权限有可能在项目交接中出现问题。
A14：
证书管理的问题吧，个别系统只能证书在系统本地，有负载均衡的话可以挂负载均衡上，统一管理，减少风险，变更起来也容易（一年一换）。
A1：
蛮难的，容器的生命周期很短，拉起的IP会有变化、一般只能关注到Node这里，如果有购买容器安全类的产品能管理到。
A2：
Service是稳定的。
A3：
对，应该对微服务可用性做监控，容器上上下下太频繁。
A1：
您是想说应用日志脱敏么？
A2：
是的，应该就是日志脱敏这个事。
A3：
日志管理系统用的啥？ELK？SPLUNK？
A4：
ELK怎么脱敏，这个也困扰我，大佬两个能都讲讲吗？
A5：
1. 直接在源头脱敏，专项针对重要的应用系统字段进行检查改造，脱敏相关字段；
2. ELK的话可以在Logstash里好像是能配置进行脱敏。
A6：
这个目前是不同的公司不一样是吗？有没有可公开的规范或者有做的比较好的规范文档？
A7：
不是公司的问题，理论上是业务形态的问题，不同业务形态的公司，对于敏感数据的定义重视程度不太一样。公开的没有。
A8：
我们都是把日志统一牵引至审计平台，至于相关规范没怎么关注过。至于如果你需要脱敏，可以找一款商用的日志管理平台，应该可以实现脱敏和管理。
A9：
发现我们是有的，但是没有用，说太影响业务了。
A10：
那就用起来，先测试影响多大，就类似KMS加密机之类的，针对一些重要的，就算影响，你该做加密的还是要做的。
A11：
能不能从规范搞起来？
A12：
自己写一套规范，主要如何定义敏感信息是一个大问题。
上期话题回顾：
活动回顾：
活动预告：
2023史诗级漏洞/后门曝光！存在长达几十年，美国或用于监听全球
IBM：2023 年数据泄露的平均成本将达到 445 万美元
FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！
【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】
注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf1024，备注：甲方会员
“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1200+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。
文章引用微信公众号"FreeBuf",如有侵权,请联系管理员删除!
