读懂SIEM创建？看这篇就够了！
发布时间：2022-03-31 03:17:19 所属栏目：安全 来源：互联网
导读：SIEM技术已经存在并被使用了25年以上，起初只是在海外和国内部分头部企业使用，用以解决数据孤岛、安全事件分析、运维管等问题。鉴于技术原因起初的它并不好伺候，甚至是花钱买罪受。但随着技术的不断发展和实际需求，它又再次回归我们的视线。本文将带您
|
SIEM技术已经存在并被使用了25年以上，起初只是在海外和国内部分头部企业使用，用以解决数据孤岛、安全事件分析、运维管等问题。鉴于技术原因起初的它并不好伺候，甚至是花钱买罪受。但随着技术的不断发展和实际需求，它又再次回归我们的视线。本文将带您了解SIEM并提供SIEM建设的一些建议。 知识点补充： 技术成熟度曲线中指出技术的发展需要经历：萌芽期、膨胀期、低谷期、恢复期、成熟期(对应上图横轴的5个阶段)。在判断时先看报告的出具年份①，其次查看您关注的技术成熟度②，根据标注的淡蓝色③来看还有多少年到达成熟期。以SIEM为例就是2021+2~5年，在2023-2026年是SIEM技术彻底成熟的时候。 SIEM价值体现 1.外部驱动 不管是国家一把手在重要精神讲话中提到态势感知，还是等保2.0中的“一个安全管理中心+三重防护”的要求，都可以与SIEM进行契合。 2.内部驱动 以SIEM为抓手，帮助企业内部各层面人员开展安全运营工作。 领导层： 可纵览安全现状和决策：这里特指CIO这个层面，他们普遍对于业务非常熟悉，也懂部分技术。他们的职责是规划信息化建设，搭建IT团队，向上层汇报获得老板的支持，为企业降本增效和体现个人价值。那一个运营良好的SIEM可以帮助CIO判断现有安全现状，如安全态势展现、攻击可溯源、工作量可视化。 SIEM的整体架构大致如上图所示，以一条Windows系统登录日志为例，来过一遍经过的所有流程。 1.日志采集 当用户成功登录windows电脑时，会产生一条Event ID 4624的日志，系统会记录下很多信息，包括但不仅限于时间、IP地址、系统版本、登录类型(本地或远程)、用户名、登出状态。 2. 可视化展现 设定预制报表，定期出具一份统计结果。也可直接在大屏展示以上事件的结果，如攻击事件+1 或 摸鱼事件+1 (UEBA用户实体行为分析更偏向此块内容分析) SIEM关键技术指标 底层数据的收集和管理 这块个人觉得是最重要的内容，如果最基础的日志收集和管理都不稳定，那上层的分析和告警必定会受到影响，至少应该支持每日TB级的数据收集和管理能力。日志来源包括内部本地和云环境的日志。 异构产品协作 与其它安全产品的协作能力，如果选购的SIEM产品只支持同厂商的安全设备联动和对接，后期涉及自动化编排和联动等都会造成约束。 实施人员 SIEM项目的建设同样需要考虑项目团队的实施经验和能力，一个具有丰富经验的实施团队，对于项目的完美交付绝对起着至关重要的作用，他们能快速准确的理解客户需求，将人、技术、流程进行合理串联设计，并擅长疑难问题的排错。 SIEM建设建议 1.需要有一定的安全建设基础才开始SIEM之旅。 这里的安全建设指安全产品的部署，如杀毒软件、终端管控、网络准入、VPN、上网行为管控、数据防泄漏、IDPS、防火墙、WAF、流量探针、主机安全、蜜罐、微隔离、EDR、威胁情报、漏洞扫描、邮件安全网关、堡垒机等。并不是说没有这些设备不能开始SIEM的建设，但是SIEM更多的还是考虑威胁方向的发现。如果没有足够的上下文和数据源关联，SIEM就不能被充分利用。同样的道理CMDB、应用服务器和系统日志也同样重要，比如应用服务器访问日志可以用来确定WAF或者IDPS上的攻击是否成功，如果没有相关数据SIEM的判断也是不精准的。 2.建设之初做好整体规划，包括项目的范围和期望输出价值。 范围指的是定义好最终交付场景的方向。一般分为威胁类方向、合规类方向、业务类方向。根据范围考虑每个方向输出的价值： 业务类： 为业务赋能相对于前两者的优先级会靠后一些，但不影响在建设初期协同参与讨论。如针对特定业务场景的风险控制指标的监控，重复报表工作的优化等。 以上的这些方向可以分阶段、在充分考虑优先级和资源投入的基础上做一个统筹规划。 3.现有安全产品的性能考虑 在开启安全日志分析后产品的资源利用率，比如CPU、内存、I/O、存储的增加是否会影响现有产品输出内容的质量。 另外这些安全日志是否可以被读取到，是否存在技术限制不对外提供接口，这些都是在建设前需要调研和考虑的问题。如果已经有集中日志管理平台，建议从它入手优先获取数据。 注：SIEM和集中日志管理平台还是有区别的，SIEM收集和存储的每条日志应该是更有价值的或者说经过初次研判后的日志，用以发现威胁、取证或者合规等方面。如果已经有集中日志管理平台，那他与SIEM的使用场景和定位也是需要考虑的。 4.不要试图一次性将所有可接入的日志源导入SIEM平台，而忽略思考日志未来产出的价值和后续跟进，如场景、运营、报告、展现等方面。 建议：围绕场景展开工作，将安全团队、合规团队、业务团队最关心的场景做个优先级排序。从那些投入小但展现价值高的场景入手。 比如，安全团队原来要登录多个安全平台排查的问题将优先考虑。比如，合规团队以往定期关注的报表自动化展现。比如，业务团队关心的某个监控指标。建设初期充分讨论这些场景，以及为了满足这些场景所需要的日志源。 这些调研和头脑风暴是真正有价值，是项目初期成功的关键，也能有效的论证商业产品。会比直接使用开箱即用的场景更具价值，当然这些开箱即用的场景可以作为引发思路。 5.场景创建 把您最关注的各类安全平台日志威胁在SIEM中呈现(单一策略未做多场景联动)，减轻跨平台监控的工作量。 建立如上那些有价值的场景，这些场景中的策略明细以最小化满足的方式接入。比如，不要试图把杀毒管理控制台中的所有告警日志都发送到SIEM平台，而考虑把未部署的杀毒软件终端数量和IP地址引入，或者把离线的杀毒终端信息在SIEM中展现，以便后续的运营跟进处理。 如果您觉得仅从杀软管理控制台的离线数据不能判断，那可以考虑网络层的数据和这台终端人员是否离职注销等信息来进一步完善这个“未安装杀毒软件”的场景。 虽然这个场景的设计是不合理的，因为杀软会ping这台终端是否存活，不一定需要网络层的日志，人员离职与未安装杀软的关系也不是特别大，但是这边想要表达的核心思想是最小化日志接入，不要试图把可能与该场景有关的所有日志接入，这样只会产生大量的噪声和误报。只有当现有的日志不满足场景时才陆续将可能辅助产生最终效果的日志接入，并陆续调优。 （编辑：应用网_丽江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330468号