SIEM技术已经存在并使用了超过25年。起初，它只是被一些海外和国内的龙头企业用来解决数据孤岛、安全事件分析、运维管理等问题。由于技术原因，一开始不太好服，甚至花钱买。但随着技术的不断发展和实际需求，它又重新回到了我们的视线。本文将带您了解SIEM，并为SIEM建设提供一些建议。SIEM定义Securityinformationandeventmanagement(SIEM)安全信息和事件管理，通过多维度的日志采集和场景分析，实现实时和历史事件分析，旨在帮助企业提高事前预测、事中检测并在事后调查取证的同时，配合企业内部工作流程，实现信息安全事件的闭环执行，提高信息安全防御水平，提升信息化能力。安全管理。SIEM技术成熟度在Gartner发布的2021年安全运营技术成熟度曲线中（如下图），分析了主流的安全运营技术。其中，SIEM已进入稳步发展和成熟阶段。这一分析也符合目前的市场情况，很多企业已经将SIEM（或态势感知）作为安全运营中的主要实施平台。知识点补充：技术成熟度曲线指出技术的发展需要经历：萌芽期、扩张期、低谷期、恢复期、成熟期（对应上图横轴上的五个阶段）.判断的时候，先看报告出具年份①，再看你关心的技术成熟度②。根据标记的浅蓝色③，可以看出还有多少年才能达到成熟。以SIEM为例是2021+2~5年，2023-2026年是SIEM技术完全成熟的时候。SIEM价值展示1.外在驱动无论是国家最高领导人重要精神讲话中提到的态势感知，还是安全2.0中“一个安全管理中心+三重防护”的要求，都可以与之相匹配SIEM。2、内部驱动以SIEM为切入点，帮助企业内部各级人员进行安全运维。领导力：可以对安全状态和决策有一个概览：这里特指CIO级别。他们一般都非常熟悉业务，懂一些技术。他们的职责是规划信息化建设，组建IT团队，向上级汇报，获得老板的支持，为企业降本增效，体现个人价值。一个运行良好的SIEM可以帮助CIO判断现有的安全状态，如安全态势展示、攻击溯源、工作负载可视化等。运维层：集中管理，舒适运维：运维人员考虑保障各项服务安全稳定运行，及时发现可能的安全事件。他们的重点是保证业务对老板负责，同时尽可能让运维方便和自动化。通过SIEM可以解决去中心化日志的管理，解决各种安全产品的多控制台接口查询，解决设备之间的联动，告警事件工单的流转，可以依托这个平台进行攻防演练，提升自身应急处置能力。业务层安全：业务更关注系统的可用性，业务数据分析和挖掘为其带来创收机会。SIEM收集业务埋点数据采集，分析业务关注的指标点，并基于场景给出一些建议和提醒（不能替代风控产品）。SIEM输入输出如果你问这个方案贵不贵？答案是它会比其他安全产品稍微贵一点。但是这个投资主要看怎么衡量。如果购买只是为了让安全团队“玩”（产品定位重安全，再看定义），那么只有一小部分人在使用，它的价值没有得到充分发挥。由于实施前充分评估，尤其是跨部门、跨团队的场景协作（最初应该定位为安全场景用例），用的人越多，参与的需求就越大，性价比就越高.SIEM架构SIEM的整体架构大致如上图所示。以Windows系统登录日志为例，走一遍所有流程。1、日志收集当用户成功登录Windows电脑时，会产生一条EventID4624的日志，系统会记录很多信息，包括但不限于时间、IP地址、系统版本、登录类型（本地或远程）、用户名、注销状态。2.SIEM中的归一化是将整个系列的原始日志进行拆分，根据厂商定义或企业自己定义的指令丰富标签内容。3.事件过滤合并，就是对同一类型的日志进行分类。比如windows和linux的日志格式其实是不一样的，可以归为两类。并过滤掉暂时不关注的字段，提炼出需要关注的内容。4.关联分析这部分是SIEM的精髓所在。如何制定策略来降低误报率并产生有价值的用例是所有相关方的关键考虑因素。当然，场景开发的优劣与日志源的质量、分析师的经验等因素密不可分。继续上面的例子，你可以定义张三在30分钟内登录了多少次。5、报警如果30分钟内有上百次登录行为，那么我们要判断电脑是否可能被入侵了？如果30分钟内有5次左右的登录，张三是不是在钓鱼？（频繁接水、频繁移动、频繁登录）？具体的告警阈值以及对结果的判断由您自行想象或根据实际情况确定。6、安全事件的运维是对产生的告警进行判断和处理。可到现场或电话人工确认情况。如果确定为高危行为，还可以联动相关产品进行实时封禁操作。7、可视化显示和设置预制报表，定期发布统计结果。以上事件的结果也可以直接在大屏上展示，比如攻击事件+1或者钓鱼事件+1（UEBA用户实体行为分析更偏向于这方面的内容分析）底层数据的收集和管理SIEM关键技术指标是我个人认为是最重要的内容。如果最基本的日志采集和管理不稳定，那么上层的分析和告警肯定会受到影响。至少应该支持日常TB级的数据采集和管理能力。日志来源包括内部本地和云环境日志。架构和部署主要是指系统的横向扩展能力。如果一个大型企业涉及多个分支机构，架构应该能够适应异地的扩展和日志的同步。分析检索产品应支持统计模型和AI算法（ML机器学习、NLP自然语言处理）能力。异构产品与其他安全产品之间的协作能力。如果采购的SIEM产品只支持与同一厂商的安全设备联动互联，后期的自动编排联动会造成制约。易用性产品界面的易用性设计对于操作者的体验也非常重要。技术栈产品各模块实现所采用的技术栈是否稳定、安全、主流也是需要考虑的问题。实施者SIEM项目的建设还需要考虑项目团队的实施经验和能力。一个经验丰富的实施团队对于项目的完美交付绝对起着至关重要的作用。能够快速准确地理解客户需求，整合人、技术、流程进行合理的系列化设计，擅长解决疑难问题。SIEM建设建议1.在开始SIEM之旅之前，需要有一定的安全建设基础。这里的安全建设是指安全产品的部署，如杀毒软件、终端控制、网络接入、VPN、上网行为控制、数据泄露防护、IDPS、防火墙、WAF、流量探针、主机安全、蜜罐、微-隔离、EDR、威胁情报、漏洞扫描、邮件安全网关、堡垒机等。并不是说SIEM的建设离不开这些设备，而是SIEM更多的考虑的还是威胁方向的发现。如果没有足够的上下文和数据源关联，就无法充分利用SIEM。出于同样的原因，CMDB、应用程序服务器和系统日志同样重要。例如，可以通过应用服务器访问日志判断攻击WAF或IDPS是否成功。如果没有相关数据，SIEM的判断也是不准确的。2、在建设之初就做好统筹规划，包括工程范围和预期产值。范围是指定义最终交付场景的方向。一般分为威胁方向、合规方向、业务方向。根据范围考虑每个方向的输出值：威胁类别：它是企业安全团队的优先事项。可能是结合现有的安全产品和系统日志级别，发现互联网侧和内网侧的可疑攻击风险。可以做得更好的是结合威胁情报和ATT&CK框架来观察和发现攻击者的TTP（Technology,TacticsandProcess）。合规类：更多可以与内部合规团队沟通，在输出中体现他们的审计要求，比如防止内部人员数据泄露，运维人员异常操作等。业务类：业务赋能的优先级会是低于前两者，但不影响建设前期的协作参与讨论。如针对特定业务场景的风控指标监控、重复上报工作的优化等。以上方向可在充分考虑优先级和资源投入的基础上，分阶段进行规划。3、现有安全产品的性能考虑开启安全日志分析后产品的资源利用率，例如CPU、内存、I/O、存储的增加是否会影响现有产品输出内容的质量.另外，这些安全日志是否可以读取，是否有不对外提供接口的技术限制，这些都是建设前需要考察和考虑的问题。如果已经有中心化的日志管理平台，建议先从中获取数据。注意：SIEM和集中式日志管理平台还是有区别的。SIEM收集和存储的每条日志应该是更有价值的或者经过初步研究和判断后的日志，用于发现威胁、获取证据或遵守法规。如果已经有集中式的日志管理平台，还需要考虑其使用场景以及与SIEM的定位。4、不要试图一次性将所有可访问的日志源导入SIEM平台，而忽略了未来日志输出和后续的价值，如场景、操作、报告、展示等。建议：围绕场景着手，优先考虑安全团队、合规团队、业务团队最关心的场景。从投资少、展示价值高的场景入手。例如，安全团队原本需要登录多个安全平台排查的问题，会被优先处理。例如，合规团队过去定期关注的报告自动显示。比如业务团队比较关心的某个监控指标。充分讨论建设初期的这些场景，以及满足这些场景所需的日志源。这些研究和头脑风暴是非常有价值的，它们是项目初期成功的关键，也可以有效地展示商业产品。这将比直接使用开箱即用的场景更有价值。当然，这些开箱即用的场景都可以作为思路。5.场景创建将您最关注的各安全平台的日志威胁呈现在SIEM中（单一策略不链接多个场景），减少跨平台监控的工作量。建立有价值的场景，例如上面的场景，其中以最小化满意度的方式插入策略细节。例如，不要试图将杀毒管理控制台中的所有告警日志都发送到SIEM平台，而是考虑引入未部署的杀毒软件终端数量和IP地址，或者在SIEM中显示离线杀毒终端信息，以便后续操作跟进。如果觉得单靠杀毒管理控制台的离线数据无法判断，可以考虑网络层数据和终端人员是否离职、下线等信息，进一步改善“无杀毒软件”的场景安装”。这个场景的设计虽然不合理，但是因为杀毒软件会ping终端是否存活，不一定需要网络层的日志，人员离职和不安装杀毒软件的关系也不是特别很好，但是我想在这里表达的核心思想是尽量减少日志访问，不要试图访问所有可能与场景相关的日志，这只会产生很多噪音和误报。只有当现有的日志不符合场景时，才会陆续连接可能有助于产生最终效果的日志，并陆续调优。不要试图一次调整多个策略。首先，策略的准确性需要一定的时间来验证和优化，这可能是由人工模拟或真实的安全事件触发的。告警触发到最终SIEM平台的实时性和误报性可能需要进行判断和调优。其次，在安全事件落地的闭环过程中，也需要制定和调整人员和流程。在系统、网络、业务人员的配合下，正常的运营人员一天只能处理并最终确认2-3个事件，不排除复杂及时的反馈情况。因此，SIEM实施过程中的人员和流程也需要提前考虑和设计。此外，某些场景下的策略涉及到模型的学习时间，在部署初期并不是特别准确，需要持续跟进来验证策略的有效性。创建多个临时监控指标（watchlist）作为黑白名单知识库参数，并将这些黑白名单库嵌套在后续其他场景的创建中，以提高研判的准确性，杜绝误报。例如，从WAF攻击行为中提取攻击IP地址，保存为黑名单池，并与其他攻击场景或防火墙日志进行关联。当匹配到该黑名单IP池时，判断为高危安全事件。再比如，读取某业务系统产生的白名单用户列表，与已有的“风险用户列表”场景匹配，作为排除指标，减少误报。如果一些日志源难以在SIEM平台处理或者会增加现有SIEM平台的性能开销，可以考虑暂时将这些日志导入到一个独立的服务器上，在这个服务器上使用批处理或者脚本来处理数据。二次加工后，进入SIEM进行协作。梳理一个场景规则从生成到最终人员落地的封闭运行流程，与相关合作者顺利排练后，再进入新场景的搭建。如果有分公司，建议在分公司演练这个场景。这样做的好处一是让大家知道有这样一个平台，二来大家每个场景都精通，工作量可以接受。如果项目前期所有场景都投入使用，没有相关的运营支持，最终的处理人员会手忙脚乱，压力很大。不仅操作没有优化，反而会增加很多额外的工作量，让合作人员对平台产生抵触情绪。只有持续运营优化场景优化策略，解决相关方的根本需求，才能吸引更多人参与。创建场景跟踪列表，明确列出需求方和目的、创建时间、使用的日志源、策略优先级、策略场景分类、策略阶段（研究、新建、调优、生产）、策略运营商、策略更新记录等6.报表展示部分主要是对分析的指标进行展示。在这个过程中，需要考虑报告的对象是管理、运维、安全、合规或业务利益相关者关注的指标所带来的价值。从数值、直方图、饼图、趋势图、百分比图、TopX等多个角度和维度分析和呈现数据，针对不同的对象，以可接受和易懂的方式呈现。如果企业对SIEM提供商提供的展示不满意，想要优化展示界面，还需要考虑提前从团队内外招聘前端工程师和UI设计师，完善相关工作。7、维修工作。成功的SIEM部署需要专业的人才库。一旦有任何威胁警报，就不可避免地要对发现的事件做出响应。人员需要根据环境的变化不断调整和维护，包括威胁、合规性要求和数据源获取本身。在项目开始之前，你至少需要考虑以下3种人才：因此，你不仅需要具备足够知识的员工来管理和维护SIEM，还需要为SIEM带来的额外工作做好心理准备.需要审查和处理事件，需要制定流程，并且需要考虑与其他部门和团队的协作。这些都是需要提前准备和思考的任务，而不是寻找三个合适的员工。此过程不排除员工事假和病假等其他因素。如果需要7*24小时的安全事件监控操作，人数需要增加一倍。最佳实践：控制项目范围并聘请外部服务提供商SIEM是使特定工作和场景更高效、更有价值的有效工具，但它不会单独运行。以下两条建议可供参考：限制项目范围，就是在项目初期就控制好项目的范围和目的，使项目规模与资源的可行性相匹配。根据实际风险和企业风险偏好制定优先级，或围绕场景、日志源、报告、流程和输出值来实施项目。并且在接下来的几年里，还会通过二期、三期项目不断迭代拓展。聘请外部安全服务商如果企业有一定的规模和合适的人才，经过仔细分析和考虑，完全可以进行建设工作。如果企业缺乏内部资源或专业人才，可以考虑采用统一SaaS部署+安全管理服务（MSS）的组合方式来实施此类项目，通过外部力量帮助企业显着提升安全能力，而不需要大量的软件、硬件和人员。投资、交付包括持续运营和管理，企业自身更关注安全场景和业务需求。托管安全服务提供商(MSSP)通过他们自己的SIEM解决方案提供对安全事件和日志收集的实时监控和分析，以进行报告和调查。注意：托管安全服务(MSS)是希望更多地减轻网络安全责任的企业的一种选择。借助MSS，值得信赖的合作伙伴将协助完成公司的部分或全部安全流程，并且MSS可以在内部或远程进行。公司获得MSS合作伙伴的分析师和运营工程师的经验和技能，可以提供从安装到威胁检测再到响应的一系列服务。8、对云上SIEM的思考近年来，疫情改变了很多企业的战略方向，尤其是云计算的可扩展性、弹性计算、安全组件，让很多企业不愿尝试云计算。企业已经转变为积极拥抱云，思考云架构、云安全、云运维、云原生等问题。SIEM云端运行可能需要考虑的问题：带宽：云端SIEM需要一定的带宽来获取企业内部数据和访问云端用户界面。如果本地带宽不足以让基于云的SIEM提供所需的日志文件并访问SIEM的用户界面。不会享受到云的可扩展性和弹性优势，反而会带来一些网络问题，需要考虑和评估。数据安全：虽然SIEM的常见角色之一是合规性和满足监管要求，但在选择云SIEM解决方案时，也可能存在监管、数据安全和法律约束。基于以上原因，很多企业都在采用混合云管理。就是将企业内部的计算、存储、服务与公有云中的服务连接起来。混合云允许企业保留对本地敏感数据的控制，同时利用SaaS的相关优势。这种设计可以解决很多监管问题，让SIEMonthecloud更加可行。可以考虑将SIEM部署在私有云（下图红色图标），或者云上的专用云（下图绿色图标），通过采集器和云接口将数据同步到一个地方，再进行汇总分析。9.SIEMontheCloud中的角色和职责对于不想在SIEM上投入太多资源的企业，由托管安全服务提供商(MSSP)执行是一个不错的选择。但首先，需要清楚地了解角色和职责。这里将使用RACI矩阵来直观地阐明企业、云SIEM提供商和MSSP之间的关系。注：WhoisresponsibleR=Responsible，即负责执行任务的角色，具体负责操纵项目和解决问题。WhoapprovesA=Accountable，即对任务完全负责的角色，只有在他同意或签字后才能进行。WhotoconsultC=Consulted，拥有完成项目所需信息或能力的人。WhotoinformI=Informed，即有特权，应该及时通知结果的人，但不必向他咨询或征求意见的人。通常，云SIEM供应商更多地负责初始构建部署并解决自身产品的功能更新问题。MSSP更多的是负责中后期的场景优化和事件追踪。这种模式下的企业更多的是需求的提出和确认。总结：在SIEM建设前期确定项目范围和预期价值。过程中围绕场景、日志、流程进行推进，每个场景都实现到位，演练到位，再进入新的场景。根据企业合规和资源投入，考虑部署本地数据中心或云端SIEM。人员方面，需要提前规划和准备或寻找MSSP合作伙伴协助落地。
