用于云服务和应用程序的网络安全可编程性的数据日志管理

0x01摘要

近年来，考虑到网络攻击的复杂性和多样化，安全设备正变得更加重要和严峻。当前的解决方案非常笨拙，无法在虚拟服务和物联网(IoT)设备中运行。 因此，有必要发展到更优秀的模型，该模型从大量的异构源中收集与安全相关的数据，以进行集中分析和校正。 在本文中，我们提出了用于访问安全上下文的灵活抽象层概念。它旨在通过部署在云应用程序和IoT设备中的轻量级检查和执行挂钩来编程和收集数据。 通过回顾主要软件组件及其作用，我们对其实现进行了描述。 最后，我们通过对PoC实施的性能评估来测试此抽象层，以评估从虚拟服务和IoT收集数据/日志以进行集中式安全性分析的有效性。

0x02简介

​ 通过云范式中的虚拟化，可以在构建和运行信息与通信技术(ICT)服务中实现敏捷性和成本效益。 但是，与当前的旧版部署不同，它们带来了更多的安全问题。

​ 物理和虚拟服务类似于相同的开发结构。 在基础设施即服务(IaaS)模型中，常见的做法是将每个软件应用程序部署在不同的虚拟化环境中，虚拟化环境可以是虚拟机，也可以是软件容器。然后通过虚拟网络链接将它们互连。 这样，单个虚拟机的故障就不必影响整个服务。 应用程序可以轻松打包并以云映像形式交付。

​ 虚拟化基础架构中安全机制的局限性，例如分布式防火墙和安全组; 在跨云部署中协调它们的难度; 第三方提供的信任安全服务的典型差异促使人们越来越倾向于在虚拟服务的拓扑结构中插入遗留的安全设备。 与此相反，这种方法有几个问题：i)每个设备都有自己的检查钩; ii)由于协议和应用程序的数量和复杂性，检测需要大量的计算资源; iii)复杂的安全设备无法抵抗错误和漏洞。

​ 考虑到这些方面，需要新的体系结构范例来建立虚拟服务的态势感知。 这样，通过将细粒度的信息与有效的处理，弹性与鲁棒性，自主性与交互性相结合，就可以克服上述局限性。 因此，有必要从独立的安全设备过渡到更协作的模型。 对于协作模型，我们指的是一种集中式体系结构，其中从给定域内的多个来源收集安全信息，数据和事件，以进行公共分析和关联。 对于所有主要的网络安全应用程序供应商而言，这是当今的趋势，这些供应商正越来越多地为企业开发安全事件和信息管理以及安全分析软件，并利用机器学习和其他人工智能技术进行数据关联和识别攻击。 它们被设计为现有安全应用程序的集成工具，并要求在每个主机上运行重量级的进程。 因此，它们不适用于虚拟服务。 另外，集中式体系结构提高了检测率，同时减少了每个终端的开销。 另一方面，由于上下文不断变化，因此服务图的安全性管理是一项艰巨的任务。 将安全设备集成到服务图设计中并不是最佳解决方案，因为它需要手动操作。 取而代之的是，应该通过定义描述要求的内容而不是如何实现的策略和约束来抽象地描述安全性。

​ 在本文中，我们描述了抽象层的定义，以为检测逻辑提供对虚拟化服务的异构安全上下文的统一和双向访问。 我们工作的新颖性在于在内核或系统库中抽象了轻量级的可编程钩子，而无需在VM内部署复杂而繁琐的安全设备或在整体服务图中将其部署为单独的组件。 对安全性上下文的收集和强制性规则的配置(这是双向访问的手段)进行编程的能力，只是对已经作为商业或开源实现可用的log 7收集工具的数量的重大改进。 本文的其余部分安排如下。 我们将在第2节中描述整个ASTRID体系结构。然后，在第3节中详细说明抽象层的概念及其体系结构设计，同时在第4节中讨论当前的实现，并对所选技术进行详尽的描述。 然后，在第5节中，我们提供了概念验证实施的功能验证和广泛的性能评估，包括与本地监视/执行代理的集成。

0x03 ASTRID结构

​ 图1显示了组织ASTRID多层体系结构的三个互补平面。 尽管我们的体系结构与网络运营商没有直接关系，但我们使用网络术语。 ASTRID是一种多层体系结构，在该体系结构中，公用，可编程且普及的数据平面可提供一组强大的多供应商检测和分析算法(业务逻辑)。 一方面，挑战在于通过实时收集来自多个毛细血管来源的大量事件，在多个站点上集合广泛的知识，同时保持诸如转发速度，可伸缩性，自治性，可用性，容错性之类的基本属性。 ，抵制妥协和响应能力。 另一方面，其目标是通过空间和时间上的域间和域内数据关联来支持更好和更可靠的态势感知，以便及时检测和响应甚至更复杂的多矢量和跨学科网络攻击 。

图1 ASTRID结构

​ 数据平面是虚拟化环境中部署的体系结构的唯一部分。 它收集安全上下文，即包括事件，日志，措施的知识库，可用于检测已知攻击或识别新威胁。

​ 通用控制平面的主要优点之一是可以从不同子系统(磁盘，网络，内存，I / O)获得数据，而不是像如今的通用做法那样依赖单一信息源。 由于从多个来源收集数据很容易导致过多的网络开销，因此根据实际需要调整检查，监视和收集过程非常重要。 因此，数据平面必须支持单个组件的重新配置及其虚拟化环境的编程，才能更改报告行为，包括每个应用程序特征的参数(日志，事件)，网络流量，系统调用，远程过程调用 (RPC)指向远程应用程序。 编程还包括将轻量级聚合和处理任务卸载到每个虚拟环境的功能，从而减少了带宽需求和延迟。

​ 对执行环境进行编程的灵活性有望潜在地导致所收集数据的种类和详细程度上的巨大异质性。 例如，某些虚拟功能可能报告详细的数据包统计信息，而其他功能可能仅报告应用程序日志。 另外，对于每个执行环境，报告的频率和粒度可能有所不同。 数据在时间和空间维度上的相关性自然会导致针对不同的时刻和功能并发请求相同类型的信息。 最后，最后一个要求是执行快速查找和查询的能力，还包括某些形式的数据融合。 应该允许客户端定义所需数据的结构，并从服务器返回完全相同的数据结构，从而防止返回过多的数据。 当需要了解不断变化的情况并识别攻击的能力要求检索和关联超出典型查询模式的数据时，这可能会变得有用。

​ 控制平面是逻辑上和集中式算法的集合，用于检测攻击和识别新威胁。 每种算法都从公共数据平面检索所需的数据。 这代表了所提出的框架背后的一项主要创新：的确，每种算法都对整个系统具有完全的可见性，而无需在每个虚拟功能中部署本地代理，这些代理通常执行相同或类似的检查操作。 控制平面还应包括编程功能，以将本地处理任务配置和卸载到数据平面，从而有效地平衡检查深度与所产生的开销。

​ 除了单纯地(重新)实现性能和效率方面的传统设备之外，ASTRID方法还专门为通过结合检测方法(基于规则，机器学习)而为新一代检测智能铺平了道路。 大数据技术; 目的是在图形及其组件中定位漏洞，识别可能的威胁，并及时检测正在进行的攻击。对来自多个交织域的安全日志，事件和网络流量的组合分析可以极大地增强检测能力 能力，特别是在大型多向量攻击的情况下。 在这方面，机器学习和人工智能的应用将有助于检查和关联大量数据，事件和度量，这些数据，事件和度量必须进行分析才能可靠地检测和识别甚至复杂的多矢量攻击。

​ 管理平面的构想是使人员处于循环中。它会通知检测到的攻击和异常情况，以便在检查过程中需要人员专门知识来补充人工智能时，可以访问整个上下文。 管理平面通过定义高级策略来支持快速有效的补救措施，然后将这些策略从控制平面转换为特定的数据平面配置。 管理平面还与业务流程工具无缝集成，业务流程工具有望广泛用于自动化虚拟服务的部署和生命周期操作。

0x04 数据平面的抽象层

​ 抽象层的主要目的是提供对底层数据平面功能的统一访问。 根据第2节中的一般描述，数据平面由异构检查，测量和实施挂钩组成，它们在虚拟化环境中实现。

​ 这些挂钩包括程序员在其软件中开发的日志记录和事件报告，以及内核和系统库中内置的监视和检查功能，这些功能可检查网络流量和系统调用。 它们是可编程的，因为它们可以在运行时进行配置，从而根据不断发展的环境来调整系统行为。 这意味着可以有选择地在本地调整数据包筛选器，事件报告的类型和频率以及日志记录的详细程度，以获取准确的知识量，而不会因不必要的信息而使整个系统不知所措。 目的是在检测到可能表示攻击的异常或网络安全团队发出有关刚刚发现的新威胁和漏洞的警告时，获取关键或易受攻击组件的更多详细信息。 这种方法即使在并行发现和缓解的情况下，也可以在风险较低的情况下以较低的开销进行轻量级的操作，同时在异常和可疑活动的情况下切换到更深入的检查和更大的事件关联性。 即使对于最大的服务，这也可以随着系统复杂性进行扩展。

​ 抽象层涵盖两个主要方面：i)隐藏监视钩的技术异质性; ii)抽象整个服务图和每个节点的功能。

​ 图2为预想的抽象的示意图。 在本地，在每个虚拟化框中，本地安全代理(LSA)为不同的钩子提供了公共接口。 然后，将整个图拓扑抽象为中心辐射图。 在此模型中，每个节点代表一个虚拟功能，每个节点链接一条通信路径。 节点的附属节点是安全属性; 它们既包括监视/检查功能(可以收集，测量和检索的内容)，也包括相关数据(度量，事件，日志)。 同样，链接也具有与加密机制和利用率度量有关的属性(尽管未在图中明确显示)。

图2 抽象示意图

​ 为了提供综合指标，还可以将数据融合作为整体抽象框架的一部分。 基本数据的预处理和聚合可以通过相同的查询完成，因此可以优化抽象模型中的查找。 抽象层还包括存储功能，因此可以为在线和离线分析提供实时和历史信息。 在这种抽象中，总体拓扑和安全功能由协调器设置，而安全数据由LSA馈送。

0x05 实现

​ 如上一节所述，数据平面是体系结构中负责差异操作的部分：i)收集安全上下文(就事件，日志，度量等而言)，以及ii)实施安全策略(就术语而言) 数据包过滤，执行环境的重新配置等)。

​ ELK堆栈提供的集中式日志记录可在中心位置搜索所有数据。 它是开放源代码软件工具的多功能集合，这些软件工具是基于分布式日志收集器方法实现的，该方法可从数据更轻松地收集见解。 简而言之，ELK堆栈由三个核心项目组成：i)作为搜索和分析引擎的Elasticsearch，ii)用于数据处理和转换管道的Logstash，以及iii)Kibana Web UI以可视化数据。 它们共同构成了缩写ELK。 之后，Elastic启动了第四个项目Beats(轻量级和单用途数据托运人)，并决定将所有项目的组合重命名为简单的Elastic Stack。

​ 图3显示了概念验证(PoC)实施的体系结构。 生成各种类型的数据，例如系统日志文件，数据库日志文件，消息队列生成的日志以及其他中间件。 这些数据由安装在所有虚拟功能(服务)上的Beats收集。 Beats以固定的时间间隔将日志发送到Logstash的本地实例。 然后，Logstash在进行一些轻量数据处理之后，将处理后的输出发送到Context Broker(CB)，后者是收集数据并保存以进行集中分析和关联的集中节点。 在CB内部，Kafka将数据发送到Logstash的本地实例。 在处理之后，Logstash将数据发送到Elasticsearch，Elasticsearch将对该数据进行索引和存储。 最后，Kibana提供了用于搜索和分析数据的可视界面。

图3 实现结构

0x06 结论

​ 在本文中，我们概述了抽象层的主要功能和初步设计，这些抽象层提供了对异构信息和源集合的双向访问。 这种方法使大数据集可用于机器学习和其他人工智能机制的应用，而机器学习和其他人工智能机制目前是新一代威胁检测算法的主要研究领域。 与现有方法不同，我们的目标是公开执行环境的可编程功能，这些功能可用于对本地检查和监视任务进行编程。

​ 我们将详细描述基于与Kafka消息代理集成的ELK堆栈的体系结构，以及如何满足收集用于网络安全分析的日志的需求。 我们提供PoC实施的功能验证和广泛的性能评估，包括与本地监控/执行代理的集成。 结果表明，考虑到容量，该架构能够在不使用最大资源的情况下立即收集数据。 在所用资源的限制下(当每秒的事件数等于1000，并且独立于轮询间隔值时)，虚拟函数中的拍子无法在不引入明显延迟的情况下收集数据。