大多数安全运营中心主要专注于检测。对检测做出响应仅排在第二或第三位。“安全运营中心 一 级（level 1）分析师将接收生成的告警。这是大多数安全运营中心经理的想法。但是，考虑到大量的告警、分析师/告警疲劳问题，这种想法是否依旧是最好的运营方式？或者有更实用的方法？
相信大家应该知道或意识到事故（incident）始于不寻常的事情（event）。event被传送到集中检测环境（通常是SIEM环境）。一旦到达此环境，event将与所有配置的检测规则进行比较（检测规则是实施用例的结果）。一旦与用例完全匹配，用例的动作部分就会启动。默认情况下并且仍然适用于大多数安全运营中心，这个动作是在工具中生成告警。
告警生成后，安全运营中心一级分析师将接收它并根据分析师响应剧本执行所有描述的操作。如果安全运营中心分析师团队使用的是通用响应剧本，那就只能任由分析师摆布，应该希望他/她正在调查所有事情。这也称为每日问题分析师（Analyst-of-the-Day）。在我看来，通用响应剧本是一种糟糕且过时的设计原则。威胁形势过于多样化，无法仅使用一种响应剧本。但是，这并不意味着必须为每个用例设计响应剧本。如果放眼大局并分析设计/实施的用例，可以考虑用例组，因为它们围绕某个威胁类别（例如 (D)DoS、恶意软件、勒索软件等）。对于威胁类别，我们可以定义特定的响应手册。将用例映射到威胁类别的一个附带好处是，与高级管理人员沟通会更容易，因为他们以前可能听说过这些术语（(D)DoS、恶意软件、勒索软件等）。一旦触发检测规则并生成告警，但告警此时仍然未经验证。问题是“应该验证每个生成的告警吗？”。有个词叫“不可否认（Non-repudiation）”，现在让我们给它加上“值得信赖（trustworthy）”这个词。如果用例设计过程正确，则在用例研究和设计期间已经检查了可信度。但这里的“值得信赖”的意思是“我们是否毫无疑问地知道这个事件确实发生了，并且始发设备正确和完全地生成了这个事件”这不仅仅是“不可否认”就能表达的。如果这两个词都可靠，则为事件响应分析和响应自动化打开了大门。这应该已经是我们的用例设计的一部分。记住决策点1。通过在用例设计和实施上投入更多时间，我们确实可以提高安全运营中心的效率和有效性。例如，你有一个涉及恶意软件感染的用例，你的默认响应是隔离主机。此用例的响应部分将有一个先决条件。网络应该能够隔离受感染的主机。对于恶意软件感染，响应时间仍然是一个关键因素。因此，如果只是等待安全运营中心分析师完成他/她的调查结果，就可能已经失去了整个环境。在这个用例中，设计的一个关键部分是在用例被触发时创建一个事件工单，并将工单按事件的严重性分配给适当的解决小组。最重要的是在自动关闭之前包含对引发的告警的评论（自动响应）。但是，当自动关闭告警时，还应该实施一个用例，在短时间内处理由同一用例生成的多个告警。或者，如果有一个安全运营中心分析师团队即时沟通工具，就像在企业微信或钉钉中所做的那样，也可以向团队群组发送通知。通过从告警队列中删除这些类型的告警，安全运营中心分析师可以更多地关注实际重要的告警。这不仅会减少分析师/告警疲劳问题，而且还会使安全运营中心分析师的工作变得更有乐趣。既可以降低员工流失率，又可以提高安全运营中心的整体素质，提升组织的整体安全水平。如果我们仔细分析响应剧本的步骤，会发现许多步骤都围绕数据和/或信息收集。这是几乎所有 SIEM 解决方案都失败的地方。这些解决方案的厂商忘记了响应用例与检测用例同样重要。如果将 SOAR 平台而不是SIEM作为安全运营中心的心脏或大脑中枢，就可以选择自动化收集大多数数据和/或信息的任务。确实应该指示安全运营中心一级分析师团队7x24小时监控 SOAR 平台以获取告警。不但他们将获得更丰富的告警，还将节省宝贵的时间。同样重要的是，还可以协助安全运营中心分析师分析生成的告警。根据收集到的数据，我们可以建议要执行的操作。分析师唯一要做的就是在确认建议的行动之前验证数据和结论。但是，如果我们决定沿着这条路线走下去。就会引入“可能会使安全运营中心分析师变懒”等问题。事实上，这可能是一个比分析师/告警疲劳更重要的问题。尤其是当意识到大多数安全运营中心将聘请初级（很少或没有经验）雇员作为一级分析师时。如果走自动化和/或建议行动的路线，二级分析师处于职业中期并拥有足够的知识和/或经验，那么基本上可以取消安全运营中心的一级分析师职位。如果同时实施自动化和自动工单生成，那么绝对可以让安全运营中心，尤其是事件响应团队大放异彩。换句话说：让他们更聪明。如果响应剧本需要，可以自动验证已关闭的工单。根据事件响应剧本，如果其他团队需要采取其他行动，他们可以自动收到通知。换句话说，这将降低“响应时间”和“修复时间”。通过使用SOAR平台并将 SOAR 平台作为安全运营中心的心脏或大脑，我们可以更灵活地执行检测。如果我们有需要检测的特定签名，SIEM平台仍然是检测的选择。但是，如果我们正在寻找行为偏差，SIEM平台可能不是最佳解决方案。确实许多SIEM平台都在进行行为异常检测。但是这种行为异常检测真的适合我们的安全需求吗？或者我们是否能根据行为异常检测可以提供的内容对用例进行逆向？当你这样做时，如果你处于学习曲线上是可以理解的，因为这与开始使用SIEM平台并打开默认检测规则时所采用的学习曲线相同。可以将其与使用现代反恶意软件检测工具时所经历的相同经历进行比较。现代反恶意软件检测工具同样利用这两种技术（签名和行为检测）。而这些现在相对复杂。因此，通过行为异常检测达到类似的复杂程度只是时间问题。实现这一目标的一种方法是在sprint中运行行为异常检测，并让每个XX sprint都有一个经验教训会话。这将帮助我们完善行为异常检测用例和事件响应。我们经常会遇到有些用例本身不足以生成告警和启动安全运营中心响应流程的情况。例如，由于事件可信度低，或者因为某些事件需要按顺序发生。不要将这些用例标记为过于困难。这仅意味着我们用于检测威胁的当前平台很可能不是正确的平台，或者用例开发人员不具备适当的知识。通过将SOAR作为安全运营中心的心脏或大脑，我们可以选择实施多个检测引擎。当我们在非默认平台上实施用例时，安全运营中心必须了解用例逻辑以及在何处完成检测。通过将SOAR作为安全运营中心的心脏或大脑，实际上可以同时解决多个问题。降低了分析师/告警疲劳问题，降低了“响应时间”和“修复时间”，提高了安全运营中心本身的效率和有效性，最重要的是，提高了安全级别。通过使用正确的SOAR平台，我们不需要一个大的（就员工数量而言）安全运营中心，而是可以获得一个智能的安全运营中心。碳泽信息
专注于下一代安全防御和响应体系
电话：400-1788-258
销售咨询：sales@tanze.net.cn
技术支持：support@tanze.net.cn
官方网站：http://www.tanze.net.cn