客户为什么需要这个？
当网络安全不再能够手动维护时，SIEM、SOAR 和 SGRC 就变得很重要：事件太多、基础设施是分布式的、有云、分支机构、外部服务、关键业务应用程序、个人数据、CII、GIS、财务交易或内部审计要求。在这种情况下，管理层不仅需要“安装一个系统”，还需要控制：正在发生的事情、关键的事情、谁在做出反应、哪些风险存在以及哪些已经解决。
对于客户来说，价值在于网络安全不再是一组不相关的工具。 SIEM 可帮助您查看和连接事件，SOAR 可帮助您更快地做出响应，SGRC 可帮助您管理流程、控制、风险和报告。它们共同为 SOC、成熟的网络安全功能以及向业务、审计和监管机构展示的可管理性提供了基础。
解码缩写
| 缩写 | 这是什么意思 | 它关闭什么任务？ |
|---|---|---|
| SIEM | 安全信息和事件管理 - 信息和安全事件的管理。 | 从系统中收集日志和事件，将它们标准化，将它们链接在一起，识别可疑链并帮助分析人员查看事件。 |
| SOAR | 安全编排、自动化和响应 - 对网络安全事件的编排、自动化和响应。 | 自动执行典型操作：创建事件、丰富数据、检查指标、阻止帐户、启动剧本、通知责任人员。 |
| SGRC | 安全治理、风险和合规性 - 网络安全、风险和合规性管理。 | 帮助在一个流程中维护政策、控制、风险、要求、审查、任务、例外、审计和管理报告。 |
| SOC | 安全运营中心是网络安全事件监控和响应的中心。 | 人员、流程和 SIEM/SOAR/SGRC 工具协同工作的组织模型：监控、分类、调查、响应和报告。 |
| MSSP | 托管安全服务提供商 - 托管网络安全服务的外部或内部提供商。 | 根据 SLA 将监控、响应或部分 SOC 流程转移给专门团队或服务承包商的模型。 |
什么时候需要 SIEM？
当公司希望看到的安全事件不是针对单个服务器、网络设备和应用程序，而是作为风险的单一图片时，就需要 SIEM。这对于银行、电信、工业、公共部门、零售、拥有个人数据的公司、CII、许多分支机构、外部服务和关键业务应用程序尤其重要。
事件源
服务器、工作站、网络设备、NGFW、WAF、VPN、EDR/XDR、AD/LDAP、数据库、应用程序、Kubernetes、云和业务系统。
相关性
SIEM 将事件相互连接：可疑登录、权限更改、网络活动、保护激活、应用程序异常和用户操作。
优先顺序
重要的不是每一篇日记条目，而是风险。配置规则、严重性、资产关键性、异常情况以及将事件路由至负责人。
审计与调查
存储事件用于调查、审计、事件回顾、报告和证明 IT 和网络安全团队的操作。
什么时候需要SOAR？
当已经有很多事件和事件，并且手动处理会减慢响应速度时，就需要 SOAR。它的任务不是取代分析师，而是减轻可重复的负载：丰富事件、检查指标、创建任务、运行阻塞脚本、通知系统所有者并记录结果。
| 情况 | SOAR 提供什么？ |
|---|---|
| 许多类似的触发器 | Playbook 自动收集上下文，消除噪音，并将已准备好的事件传输给分析师。 |
| 响应取决于多个系统 | SOAR 连接 SIEM、EDR/XDR、NGFW、IAM/PAM、ITSM、邮件、即时消息、威胁情报和内部目录。 |
| 有必要遵守响应SLA | 每一步都会被记录：谁收到了事件、做了什么、延迟在哪里、做出了什么决定以及何时关闭。 |
| 我们需要减少人为因素 | 典型动作是根据商定的场景执行的，危险操作需要得到负责的专家的确认。 |
什么时候需要SGRC？
当网络安全团队不仅要管理事件，而且要管理整个控制系统（要求、策略、风险、所有者、截止日期、例外、审计、审查、安全措施和向管理层报告）时，就需要 SGRC。对于受监管的行业、公司集团、分布式基础设施和组织来说尤其如此，其中网络安全必须为企业所理解。
Governance
谁是流程的所有者、制定了哪些政策、谁负责控制、如何接受例外情况以及如何记录决策。
Risk
哪些风险是开放的，哪些资产是关键的，哪些措施可以降低风险，哪些任务过期了，哪些需要管理层关注。
Compliance
如何满足 152-FZ、187-FZ、FSTEC、FSB、行业标准、内部政策和审核程序的要求。
Reporting
报告网络安全环境的事件、风险、控制、解决状态、异常、SLA、审计和成熟度。
他们如何一起工作
SIEM、SOAR 和 SGRC 最好被视为单个运营链。 SIEM 查看事件并帮助了解发生的情况。 SOAR 协调响应并自动执行可重复的操作。 SGRC 将事件和漏洞与风险、控制、责任、时间表和管理报告联系起来。
来源
系统、应用程序、网络、网络安全、云、数据库、AD、DevOps、端点和关键业务服务发送事件。
SIEM
事件被标准化、丰富、关联、指定严重性并转化为警报或事件。
Triage
检查触发器：资产关键性、用户、上下文、可重复性、误报或真实攻击。
SOAR
启动 Playbook：丰富、阻止、通知、任务创建、确认请求或升级。
ITSM 和团队
该事件将发送给具有 SLA、状态和责任的系统、IT、网络安全、DevOps 或承包商的所有者。
SGRC
事件与风险、控制、策略、例外、审计或风险缓解活动相关。
报告
管理层看到的不是日志流，而是风险、事件、SLA、消除、可重复性和流程成熟度的动态。
改进
关联规则、剧本、控制、角色、培训和安全架构都会定期调整。
RESTART 承担什么责任？
| 客户的任务 | 我们做什么 |
|---|---|
| 了解从哪里开始 | 我们进行调查：事件来源、资产、网络安全、当前事件、角色、法规、报告要求、限制和 SOC/SOC 就绪目标模型。 |
| 选择架构和平台 | 我们设计 HLD/LLD，定义 SIEM、SOAR 和 SGRC 的角色，比较供应商，检查集成、拥有成本、数据和运营要求。 |
| 收集来源和规则 | 我们连接关键来源，设置标准化、关联规则、用例、仪表板、路由和基本调查场景。 |
| 自动回复 | 我们设计并实施 SOAR-playbook，与 ITSM、EDR/XDR、NGFW、IAM/PAM、威胁情报、邮件和通知渠道集成。 |
| 使风险和控制易于管理 | 我们建立 SGRC 流程：政策、控制、风险、所有者、例外、任务、截止日期、状态、审计和管理报告。 |
| 将环境投入运行 | 我们准备法规、角色矩阵、分析师说明、用例开发计划、指标、SLA 和发布后支持。 |
SOC 准备情况和 MSSP 视角
将 SIEM/SOAR/SGRC 不仅视为产品实现，而且视为成熟监控模型的准备是有意义的。即使您还不需要自己的 SOC，公司构建 SOC 就绪环境也是有用的：清晰的事件源、基本场景、角色、SLA、升级规则、剧本、报告以及连接内部团队或 MSSP 合作伙伴的能力。
这种方法降低了“你买了一个平台，但它不起作用”的风险：即使在实施之前，人员、流程、来源、用例、分析师工作量、事件存储要求、支持模型和性能标准都会被记录下来。
合作伙伴平台 SOC、GRC 和响应
对于SIEM、SOAR和SGRC赛道，RESTART不是根据“最大产品”原则来选择平台，而是根据客户的成熟度来选择：已经存在哪些事件源、谁来处理事件、需要哪些法规、管理层和监管机构需要哪些报告、是否可以自动化响应以及启动后如何支持赛道。
Positive Technologies
VM、SIEM、AppSec、NDR、WAF、网络弹性
R-Vision
SOAR, SGRC, VM, TIP, UEBA, SIEM
Security Vision
SOAR, NG SOAR, SGRC, SIEM, VM, TIP, UEBA
UserGate
NGFW, SUMMA, SIEM, LogAn, Client, SecaaS
F6
threat intelligence, DRP, anti-fraud, XDR, ASM
Kaspersky
endpoint, EDR/XDR, KATA, threat intelligence
合作伙伴被列为解决方案类的技术骨干。产品的具体构成、版本、许可证、证书和交付条件均在项目前确定。
与人工智能、漏洞和合规性的联系
SIEM、SOAR 和 SGRC 在与网络安全的其他领域连接时得到加强。漏洞管理显示哪些资产需要关注。 DevSecOps 提供有关安全开发和管道的活动。 KII、152-FZ 和 GIS 设定了控制和报告要求。安全与合规人工智能可以帮助专家快速了解政策、事件、清单和报告，但最终决定权仍由负责的专家做出。
客户得到什么？
- 事件源、关键资产、保护系统、角色和当前网络安全流程的地图；
- 目标SIEM/SOAR/SGRC架构和实施计划，而不会使团队超负荷；
- 一组按优先顺序排列的用例、关联规则、剧本和报告；
- 与网络安全、ITSM、EDR/XDR、NGFW、IAM/PAM、DevOps、威胁情报和内部目录集成；
- 风险、控制、政策、例外、审计和管理报告的 SGRC 模型；
- 分析师工作规定、SLA、升级路线、SOC 就绪指标和成熟度开发计划。
第一步实践
最好不要从选择供应商开始，而是从诊断开始：需要收集哪些事件、哪些资产至关重要、已经发生哪些事件、谁将做出响应、需要哪些报告、适用哪些监管要求以及哪些流程已经到位。之后，你可以有意识地选择是否只需要SIEM，是否需要SOAR，先启动哪个SGRC流程，以及哪个MVP会快速生效。
RESTART 通常以调查和设计会议的形式提供第一阶段：架构、来源、用例、角色、路线图、试点环境和工业运营要求。
常见问题
是否可以只从 SIEM 开始？
是的。如果公司还没有统一的事件图景，那么从 SIEM、关键源和基本用例开始，并在流程成熟时连接 SOAR 和 SGRC 是合理的。
每个人都需要SOAR吗？
不会。在存在可重复响应脚本、多个工具、SLA 要求以及愿意按照剧本工作的团队的情况下，SOAR 特别有用。
SGRC 仅适用于监管机构吗？
不会。即使没有外部审查，SGRC 也是有用的：它可以帮助管理层以清晰的管理形式了解风险、所有者、控制状态、例外情况、目标和网络安全成熟度。
让我们讨论一下您的环境
描述任务、当前系统、约束和预期结果。我们将提供实用的第一步：诊断、试点、审计、路线图或项目团队。
