第一步定义出威胁用例,然后思考目前的日志是否有支持威胁用例的所有参数,然后结合规则语法进行编写,再进行测试,在实际环境中逐渐优化。 如果目前公司没有明确的威胁场景,关于威胁用例的设计可以从几个方面考虑:威胁类型:
传统的SIEM主要用的是基于规则的关联分析。现在SIEM厂商也逐渐得引入了大数据分析和机器学习等技术。比如,好多SIEM平台已经有了UEBA功能。不过我认为,现阶段要使用SOC的话,还是应该先基于规则,再考虑大数据分析。
个人觉得缩小范围放低预期从威胁的根本去思考SIEM的价值,有效利用现有资源做出实际的案例,帮助企业及时发现威胁和漏洞,逐步在企业中建立其重要度是一条比较可行的道路。简单说,我觉得SOC和SIEM这种就像是内功,而一般的安
个人经验:优点:架构成熟稳定,支持快速部署,可扩展性比较好,有不少默认规则,提供较丰富的API,可使用第三方开发的APP增强功能,当然如果能力足够强的话也可以自己开发APP。缺点:本地支持能力有限。默认规则往往需要做较大调整才
个人认为除了基本的专业知识之外,安全分析人员最需要有的应该是逻辑分析能力,好奇心和专研精神,这个应该是先天要求。在实际运维中,一个清晰定义的处理流程(明确责任),一个结构明了的知识管理平台(包括定义各类威胁用力的细节
目前实践过程中主要尝试对于普通级别告警进行聚合,找出关键特征,比如源或者目标IP,IP位置,用户名等。理解告警触发的原因,最好回溯到原始日志事件,确认告警触发的真实性。随后根据关键特征,由点及面,从更高的维度掌握其发生的
这个是一个真实情况下一定会碰到的问题,SIEM本来就会接入大量不同的日志,并定义大量威胁用例,伴随而来的一定是大量的告警。其中一定混杂着真实的告警和误报。除了通过调优规则来减少误报之外,剩下的告警可能依然数量非常
设计威胁用例主要考虑:1. 企业面临的主要威胁是什么。 2. 现有的并接入SIEM系统的日志能帮助发现哪些威胁。3. 通过主体,对象,地点,时间,动作等多个方面定义出违例的场景。设计完威胁用例后,需要考虑如何在规则引擎中实现
必须考虑的问题:项目范围 – A. 整个企业,还是总部或者某个分公司,或是某个具体系统。B. 希望通过SIEM可以实现哪些威胁监控目标 C. 需要接入哪些日志或者网络流量实施周期 – 多久完成系统建设上线?多久完成主要日志接入
目前我们的环境用的是某商用产品。现在主流的SIEM产品主要是基于NOSQL数据库的,是厂商自己开发的,并不是主流NOSQL平台。因为实际需求对于SIEM系统要求处理的数据量和可扩展性要求都很高,传统用ORACLE数据库的方案渐渐显
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30