SIEM该技术已经存在和使用了25年多，最初仅用于海外和国内的一些龙头企业，以解决数据岛、安全事件分析、运维管理等问题。由于技术原因，一开始并不容易服务，甚至花钱买内疚。但随着技术的不断发展和实际需求，它又回到了我们的视线中。本文将带您了解SIEM并提供SIEM建议。
SIEM定义
Security information and event management (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计算机时，会产生一个Event ID 4624日志，系统会记录很多信息，包括但不限于时间IP地址、系统版本、登录类型(本地或远程)、用户名、登录状态。
2.范式化
在SIEM其中，根据制造商定义的说明或企业自身定义，拆分整串原始日志，丰富标签内容。
3.事件过滤归
也就是对同类型的日志进行分类，比如windows、Linux其实登录日志的格式是不一样的，可以分为两类。并筛选去除暂时不注意的字段，提取需要注意的内容。
4.关联分析
这部分是SIEM如何制定策略，使误报率低，产生有价值的场景(usecase)每个使用者都需要关注它。当然，场景的优缺点与日志源的质量、分析师的经验和其他因素密不可分。继续以上为例，您可以定义在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(技术、战术和过程)。
合规类：
更多可与内部合规团队沟通，在输出中体现其审计要求，如防止内部人员数据泄露、运维人员异常操作等。
业务类：
与前两者相比，业务授权优先级较低，但不影响施工初期的协调参与和讨论。如监控特定业务场景的风险控制指标，优化重复报告。
在充分考虑优先级和资源投入的基础上，可以分阶段规划上述方向。
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部署需要专业的人才储备。一旦发生任何威胁警告，发现的事件将不可避免地得到响应。人员需要配合环境变化进行持续的优化和维护，包括威胁、合规要求和数据源收集本身。在项目开始之前，您至少需要考虑以下三种人才：
因此，不仅需要有足够知识的员工来管理和维护SIEM，而且需要为SIEM做好额外工作的心理准备。事件需要审查和处理，过程需要制定，并考虑与其他部门和团队的合作。这些都是需要提前准备和思考的工作，而不是找到三名合适的员工。如果需要的话，员工的事假、病假等额外因素并不排除在这个过程中7*24小时监控安全事件，人数需要翻倍。
最佳实践：控制项目范围，聘请外部服务供应商
SIEM它是一种有效、易于使用的工具，可以更有效地执行和显示特定的工作和场景的价值，但它不会完全自己运行。建议参考以下两个方面：
- 限制项目范围
是在项目开始时控制项目的范围和需要实现的目的，匹配项目规模和资源的可行性。根据实际风险和企业风险偏好制定优先级，或围绕场景、日志源、报告、流程和输出价值实施项目。并在接下来的几年里继续通过第二阶段和第三阶段的项目进行迭代和扩展。
- 聘请外部安全服务提供商
如果企业有一定的规模和合适的人才，建设工作可以在分析和考虑后进行。如果企业缺乏内部资源或专业人员，可以考虑SaaS 安全管理服务(MSS) 结合实施此类项目，帮助企业显著提高安全能力，无需大量的软硬件和人员投资。交付包括可持续的运营和管理，企业本身更关注安全场景和业务需求。托管安全服务提供商(MSSP)通过自己的方式，提供安全事件的实时监控和分析SIEM收集日志并应用于报告和调查的解决方案。
注：管理安全服务(MSS)这是为那些希望减少更多网络安全责任的企业提供的选择。MSS，可信的合作伙伴将协助处理公司的部分或全部安全流程，MSS可在内部或远程进行。公司获得了MSS从安装到威胁检测到响应，合作伙伴的分析师和运维工程师的经验和技能。
8.云上SIEM的思考
近年来，疫情的普及改变了很多企业的战略方向，尤其是云计算的可扩展性、弹性计算、云安全组件等优势，让更多不愿意尝试云的企业转变为主动拥抱云，思考云架构、云安全、云运维、云原生等问题。SIEM您可能需要考虑在云上运行的问题：
带宽：
云上SIEM需要一定的带宽来获取企业内部数据以及访问云上的用户界面。如果企业内部没有足够的带宽为基于云上的SIEM提供
它需要日志文件和访问SIEM用户界面。云上的可扩展性和弹性优势不会被享受，但会带来一些网络问题，需要考虑和评估。
数据安全：
虽然SIEM合规和满足监管要求的常见作用之一是选择云SIEM在解决方案时，也可能有监管、数据安全和法律限制。
由于上述原因，许多企业正在使用混合云管理。它是将企业内部的计算、存储和服务与公共云中的服务联系起来。混合云允许企业保持对内部敏感数据的控制，同时使用它SaaS相关优势。这种设计可以解决许多监管问题，使云SIEM变化更可行。
你可以考虑一下SIEM在总结和分析之前，部署在私有云中(下图标红)，或部署在云上的专属云中(下图标绿)，并通过收集器和云接口将数据同步到一个地方。
9.云上SIEM角色和责任
对于不想在SIEM对于投资过多资源的企业，托管安全服务提供商(MSSP)执行是个不错的选择。但首先，我们需要清楚地了解角色和责任。它将在这里使用RACI直观明确企业和云矩阵SIEM供应商和MSSP关系。
注：谁负责R = Responsible,也就是说，负责执行任务，具体负责控制项目，解决问题。谁批准了？A = Accountable,也就是说，对任务负全部责任的角色只有在他同意或签署后才能执行。C = Consulted ，有完成项目所需信息或能力的人员。通知谁 I =Informed ，即有特权的人，应及时通知结果，但不需要咨询或征求意见。
总的来说，云SIEM供应商更多的职责是围绕自己产品的功能更新进行初步建设和部署。MSSP更多的职责是中后期的场景优化和事件跟踪处理。在这种模式下，企业更多的是需求提出和确认决策。
总结：在SIEM在施工初期确认项目范围和预期价值。在此过程中，我们将围绕场景、日志和流程进行推广，并在进入新场景之前对每个场景进行演练。根据企业合规性和资源投资，考虑当地数据中心或云SIEM部署。人员需要提前计划或寻找MSSP合作伙伴协助着陆。