关于防范勒索，除了攻击行为监测，在数据层面是否还有其他手段能及时发现？｜总第268周

0x1本周话题

话题一：看到soc，正好最近也在开发soc，目前实现业务系统的web日志收集分析，网络设备syslog日志收集分析，都是c/s结构，因为是自己一人在做这事，所以怕有弯路，想请教一下这个方向对吗？还有哪些事情可以做？

A1：做到哪一步了，用的啥技术？

A2：Python。

A3：一个人的话，建议放弃。

A4：日志收集用rsyslog,存储到kafka,再解析到mysql,再用django和vue做展现和操作，回写设备api做联动控制。

A5：是这样，如果公司有团队维护syslog，有团队维护日志采集的可靠性，有团队维护kafka，有团队维护es的集群高可用，还是可以搞一搞的。一般来说，也应该有。

A6：如果连这些基础监控都没有，我觉得公司还不需要soc……

A7：商业化的产品，不一定满足需求。这样自定义的开发方式，可以很灵活的做生态整合。态势感知和soar其实也是这么玩的。自研在“滚动式开发抓住主要矛盾”上有天然优势。

A8：最早开发的是web日志分析系统，用于攻防演练的日志分析，后来发现这个需求还挺大，就慢慢的做，期间还咨询过一些大厂家的产品，从资金，后期等方面考虑，决定自己开发。

这个开发好了后，又开发了syslog的接收分析系统，有syslog功能的就指向到我这边，没有的就放一个agent收集，这个也做完了，发现可以搞成soc了，所以有这个想法。

我这里场景比较小，数据少，有些问题暂时不需要考虑，甚至数据库还用的嵌入式的。elk之前也考虑过，但不想再解决了这个问题，可能会带来其他问题。还有供应链安全问题。

A9：挺好的，从实际场景出发，解决痛点。如果数据少，问题不体现，但有几个问题是需要有容量预估的，涉及到性能瓶颈，故障监控，延迟和有效性，然后就是结构化，这块你解决了。日志是不是只有你用，如果没别人用，那随便，elk是方便多方生产和消费。

A10：日志没关心的，运维和驻场开发人员。

A11：soc系统难点是要考虑的是后续如何运营。所以如果建设都需要东拼西凑，甚至自己搞，那真不建议弄，搞出来大概率也用不起来。

A12：核心是能用起来，大不了数据多了以后重构。

A13：soc是安全领域的大数据应用，无论是SOAR还是态感等很多上层应用要玩的转，soc底层大数据基座要搭建好，分布式架构要设计合理，流批处理任务要应用起来，运营结果要及时处置流转，基本SOC就运营起来了。

A14：赞同soc就是安全中台，站在安全整体架构视角是必要的，不管走安全监测覆盖率，或者未来的ai赋能研判分析与智能化处置，都需要中台有足够的数据量，难点也是数据量大了，就会伴随的性能问题、稳定性问题。

另外在业务视角上，最关注是如何基于场景采集必要数据（即采集有效日志，受限于成本、性能上限等因素)，但同时需要考虑识别事件带来的影响，又需要大量溯源分析数据（考虑攻击删日志等情况），两者本身又是冲突。

最后可能实现逻辑是分级采集、精准预警、快速响应，需要soar、情报、狩猎等工具链支撑，同时匹配的运营标准规范，及指标约束。

A15：感觉大家对soc的定义差异很大。

A16：从功能方面，感觉传统产品核心就是日志采集、范式化解析、查询，告警规则制定和告警展示。再扩展就是告警闭环处置，流量检测结合，威胁情报关联、资产管理和关联、漏洞管理关联、联动处置、报表生成、大屏展示。

从部署和性能方面，就是分布式采集处理统一展示、系统稳定性、系统扩展性。后续的运营，怎么减少误报漏报，怎么发现误报漏报和优化，有哪些告警的场景规则可以制定。

话题二：传闻国内某大型金融集团刚被勒索了，关于防范勒索，除了攻击行为监测，在数据层面有什么有效的手段及时发现吗？比如弄个类似蜜罐的蜜数或蜜文件，有访问就告警。

A1：安天这个服务的内容比较详细，可以参考，蜜罐是有用的，但不同技术实现的蜜罐，效果上差异很大。

A2：现在是EDR和HIDS产品的标配了，诱饵文件，动了它就告警。数据这块的表现不一样，磁盘数据就变成了文件，而数据库数据的话，加密磁盘不一定有感知，要根据自己的技术路线，实际演练，添加监控，演练很好演，搭环境，配监控，执行加密程序，就行了，能有很多惊喜。

A3：是的，但功能比较有限，比如hids诱饵文件投放不能自定义路径，自定义文件内容等。监测维度需要多方面，比如数据库可以考虑建立蜜表。

关于数据库方面，我们原来也考虑过编写一个脚本对数据库某些数据勾稽关系进行定期检查计算，如发现无法读取或勾稽关系错误则直接告警。

A4：我意思是这可能不是技术路线的问题，而是产品问题。不同服务指定不同路径，自定义文件，都可以的。

A5：关于数据库方面，我们原来也考虑过编写一个脚本对数据库某些数据勾稽关系进行定期检查计算，如发现无法读取或勾稽关系错误则直接告警。

A6：蜜罐反勒索这边建议量力而行，能起作用，但也只是其中一环，如果没有很强的技术团队或者产品支撑，稳定性和可维护性更重要一些，我们内部用虚拟文件蜜罐，玩的比较花，检测效果好，但兼容性压力就比较大。

A7：是，只是一环，我还是建议有的，有监控能有底气不少，不用到处去排查。如果被勒索了就计算不了或计算错误，代表有问题。

A8：经过我们的演练，java程序被加密了立即就无法运行了，健康检查也是立即失败，数据库文件被加密不影响交易，可以直到日切才报错。这应该是个通用共性。

针对这种情况，可能需要建个蜜库监控才有用，因为建蜜表、核算，在被勒索加密时都是无感知的。

A9：蜜表如果被勒索加密，就会存在访问行为，只要有访问就告警。

A10：勒索场景大多数还是针对文件的，不需要进数据库处理单个数据。当然蜜表不影响业务，要做是可以做的。监管有没有说法，不能直接调用公网的大模型服务，如：豆包。

A11：我记得有过提示，大意是在使用过程中要注意信息保护，没有明令禁止，但提示已经做到了，你怎么保证不出问题。

0x2