今天，我们将与不创建和配置安全运营中心（SOC）的人进行讨论，但他们会检查其他人是如何做到的。 检查为您的公司独立或由外部人员构建的SOC的有效性。 该检查回答了以下问题：“ SOC是否完成分配给它的任务，效率如何？”。 毕竟，SOC的存在并不意味着它可以正常工作，并且您知道任何可能的事件和其他安全问题。 我们将介绍我们在项目内不同公司中进行SOC验证的经验。
对于那些已经知道SOC是什么以及醉酒的人，我们建议立即转到本文的第二
部分 。 我们建议您完整阅读本文的其余部分。
第1部分。关于初学者的SOC知识
信息系统的保护在几乎所有行业中都是头等大事。 任何未经授权的信息访问都会给公司带来严重的问题。
任何公司，甚至是最小的公司，其信息系统都是复杂的，并且必须按照相同的原则来保护其所有部分：首先是组织，然后是预防措施，然后是检测异常的监视工具，以及响应工具。 人们处于最后但并非最不重要的威胁威胁阶段，尽管碰巧可以在不涉及人员的情况下解决安全问题，例如，可以通过自动阻塞端口或从共享网络断开计算机的连接来解决。 用来保护系统每个组件的工具因公司而异，但存在一个普遍的趋势-不论规模大小，公司逐渐会想到实施SOC-安全运营中心。
这有几个原因：
- 使用SOC可以减少手动跟踪安全事件的成本
- 系统事件聚集在一个地方，很少会丢失。
- SOC允许您配置规则，以根据特定公司的需求和特征将事件分类为安全事件。
- SOC使您可以最大程度地缩短检测和响应安全事件的时间，从而减少对公司的潜在损害；
- 落入SOC的日志只有一个外观，即使攻击者试图注意到他在系统中的存在痕迹，也可以使您有效地调查安全事件。
SOC是具有许多相互连接的组件的基础结构，其基础是SIEM（安全信息和事件管理）。 SIEM是一个数据收集，标准化和关联系统，可从Web服务器，主机和其他基础结构组件以及安装在组织网络设备上的信息安全工具中收集日志，进行关联和处理以使其恢复正常状态。 这是SIEM的主要任务-将来自不同来源的大量日志转换为一种格式，以便于检测它们之间的关系。 这对于SOC的另一个组成部分是必要的-SOC分析人员必须查看SIEM大量日志，才能自行响应某些事件或将其转移给安全专家。
没有两个完全相同的SOC，因为每个组织的配置都是独立的。 创建SOC的主要阶段如下：
- 在组织和技术上定义受保护的基础架构；
- 安装所有可能/必要的保护和监视手段及其配置；
- 根据公司的特点选择合适的SIEM及其调整；
- 创建事件关联规则；
- SOC团队的选择-将负责监视事件并更正相关规则并响应安全事件的人员。
即使在定义，安装和配置了所有内容之后，也没有人可以保证现在SOC可以按照您希望的方式或SIEM开发人员的精美演示中的说明进行工作。 使用任何保护手段的根本问题在于，几乎没有人知道它们如何有效工作。 重要的是不仅要安装和运行它们，而且要确保所采取的措施有效。 公司在安全性方面的成熟度也非常重要。
由于SOC是一个复杂的多组件结构，因此重要的是要了解在其创建的每个列出的阶段，都有可能出错。 这可能会影响系统的整体安全性和SOC本身的效率。
第2部分。如果您不检查SOC的有效性但将所有内容保持不变，会发生什么？
首先，即使组织的
基础架构发生了很小的
变化 ，也可能会出问题。 而且它们经常发生-有人离开，新来的人，发生故障，硬件和软件得到更新等等。 在这种情况下，应该及时更改SPI和相关规则的设置，但是他们常常会忘记它，并且当他们记住时，为时已晚。
SOC可能发生错误的下一部分是信息进入SIEM
的保护手段 ，可以对其进行错误配置，并从外部跳过针对系统的操作。 而且，如果任何现有的SZI都未检测到攻击者的行为，那么它将不会进入日志，也不会进入SIEM，并且很可能安全服务很快就不会知道。
问题可能出在
SIEM中 。 它可能无法正常工作。 由于关联规则中的错误，落入其中的事件可能未正确关联，这将导致跳过攻击者的操作。 在这里需要说明的是，并非总是有来自一个来源的足够的数据。 在某些情况下，为了确定安全事件，有必要一次组合来自多个来源的数据，以便全面了解系统中正在发生的事情。 但事实证明，该规则已配置为确定事件发生的原因可能不是来自一个源的足够数据，这表明事件已完成。 即 由多个来源的数据组成的难题将无法解决。 同样，某些安全事件的规则可能根本不存在。
在 SIEM中
的事件关联阶段 ，可能会同时出现几个问题。 其中之一可能是某些来源的事件传输延迟，这可能会干扰成功的关联。
SIEM
中将事件分类为事件的规则可能没有正确配置，或者可能不适用于任何事件。 此外，事件通常具有严重性级别，如果不能正确识别，则可能导致严重问题。
与SIEM一起工作的人员（其职责是响应安全事件）也可能导致未命中的攻击以及随后的信息安全问题。 他们可能会错过来自SIEM的某些信号，或者由于各种原因对攻击者的行为做出不正确的反应。 还有一个问题，人们迟早会辞职，新员工需要时间进行培训。
鉴于以上所述，在SOC实施阶段和一段时间内，验证性能的SOC测试都非常重要。 由于我们公司的专家已经在此问题上有经验，因此我们决定描述要点和细微差别。
第3部分。检查SOC的有效性
公司的SOC测试可以在几种情况下进行。 让我们谈谈对我们来说最有效的方法。
SOC测试任务包括通过重现网络犯罪分子固有的典型行为场景进行安全测试。 这些包括：
- 使用蛮力以及使用密码喷射技术遍历其他用户的帐户。 如果您可以通过邮件客户端的通讯录访问系统中现有帐户的列表，则可以使用此技术。 根据我们的经验，密码喷射技术经常被遗忘，因此，SOC规则几乎无法检测到这种攻击。
- 从Web资源（公司Wiki或任务管理器）中抽取数据。 可以进行这种攻击，包括使用各种Web爬网和目录暴力机制。 另外，审核员还要注意API服务及其功能。
- 反复尝试访问攻击者所代表的角色以外的资源或项目。 一个简单的例子是尝试授权一组开发人员使用网络管理员和安全服务的资源。
- 尝试使用旁路过滤技术从公司网络下载大量信息。 这主要是关于dns和icmp隧道的信息，但有时从更简单的检查开始是有意义的，例如，尝试寻找在外部打开的tcp或udp端口以及其他网关。 顺便说一下，要搜索网关，需要对其中一名员工的一种流行工具进行修订。
类似的检查清单可以持续很长时间。 以客户的实际需求和客户执行的检查为指导是最重要的。
SOC测试可以通过两种方式完成：
有关它们的更多详细信息。
首先，应在黑盒测试模式下检查SOC的运行情况。 其实质是SOC部门的员工不了解正在进行的工作，并在战斗模式下对所有事件做出反应。 审核员/测试人员可以访问公司网络，还可以使用公司最广泛使用的服务来提供帐户。
这种模型假定没有任何其他信息的攻击者以未知方式获得了访问公司网络和任何现有帐户的权限。 这种攻击者的行为具有高度的随机性和“噪音”。 他主动扫描网络，遍历目录，帐户，将他已知的所有漏洞利用发送到所有端口，并向XSS，SQLi，RCE，SSTI，NoSQLi等带有向量的Web应用程序抛出异常。 通常，他的行为举止非常积极，希望能破解至少一些东西。 审核过程中的审核员模拟了这种攻击者的行为，保持了一定程度的精神错乱，但是可以随时根据SOC服务的请求或出现技术问题而停止。 顺便说一句，意外和令人愉快的结果可能是在公司基础架构中发现了易受攻击的服务和应用程序。
另一个测试模型是白盒。 在这种情况下，解决了不道德雇员的情况。 通常，在这一点上，审核员对客户网络非常熟悉，可以扮演这样的角色。 在这种情况下，潜在攻击者的行为可以表现为攻击手段和目标的高度选择性。 在这里已经有可能与
APT攻击有一些相似之处。 审核员仅攻击他们认为最弱的位置，并使用经过深思熟虑且针对性很强的攻击媒介，并且还尝试访问其帐户角色权限范围之外的敏感信息，随后尝试将其从安全范围内抽出。 他们试图以公司安全服务未注意到的方式执行所有操作。
经过测试后，通常会开始对审核员获得的结果与SOC员工发现的事件进行分析和比较。 此阶段将提供SOC当前工作有效性的总体情况，并且可以作为所有进一步计划扩展现有检查和方法的起点。
最终，当对被测基础架构的安全性的想法进行编译时，审核员可以使用白盒测试来分析现有规则集以及基于这些规则形成的事件。 审核员和SOC分析人员之间的这种互动可能会非常有成效，并且在咨询过程中将有助于识别SOC组件配置中的逻辑错误和遗漏。 其根源通常是SOC分析人员缺乏对真正的攻击者如何采取行动以及他在系统上可以执行哪些技巧的了解。
结论
需要使用两种模型的入侵者分别测试最值得关注的最关键服务。
一组类似的措施可以使您：
- 大大提高安全管理人员对其基础结构状态的认识；
- 为SOC部门进行军事演习，并有机会征求审计领域专家的意见；
- 检测并更正SOC工作中存在的错误，并通常提高公司的安全性。
对于本文撰写方面的帮助，我感谢
Denis _ttffdd_ Rybin和
Ivan Chalykin 。