在这篇文章中以帮助网络安全分析师了解网络安全架构的组成部分，从如何使用端点信息来增强网络态势感知开始。端点收集了大量对态势感知有价值的信息，但这些信息往往没有得到充分利用。
如果不了解资产正在进行的活动，就无法检测到危害。网络安全分析师可以在两个地方之一查看这些活动，或者有时两者兼而有之——直接在设备上以及在进出设备的通信中(即在网络上)。威胁检测的第一步是了解可以在设备上看到哪些活动，并了解如何检测设备以提供这种可见性。
端点的价值
端点不仅仅是一个闲置在角落里的断开连接的黑匣子。端点通常是有权参与预定义活动的计算平台，例如处理能力、访问资源或与其他端点通信。所有这些端点的存在都是为了向组织提供价值，但要确保这一价值，需要验证它们的行为是否符合组织的预期。有效的态势感知通过定位超出其权限范围的端点来执行策略，并为运营商提供可疑和良性端点行为的整体图景。这种意识支持决策并帮助组织降低风险。
操作系统通过生成日志并将其存储在本地或将其发送到中央日志存储库来监控本地端点。许多组织通过额外的监控来补充此日志记录，在端点上安装客户端以检查处于静止状态、内存中活动状态或正在传输的数据。这些客户端可以测试数据中的恶意代码或确保数据处于已知状态。还可以观察在活动内存中运行的进程，并验证是否以适当的特权级别运行并参与了预期的行为。一些客户走得更远，限制被认为不适当或具有威胁性的行为，例如访问禁止内容或不安全地使用系统调用。这些额外的监控功能获得的可见性是有代价的。监视进程占用内存和处理器周期。一些端点态势感知工具充当应用程序和操作系统之间的“垫片”，尽管这些垫片可能会在正常操作中引入延迟和带宽限制。
在某些配置中，其中许多解决方案会生成大量日志数据，通常通过网络将其发送到中央收集器。归档这些日志所需的存储量可能会迅速增加，尤其是在从数千或数万个端点收集时，并且此活动占用的网络带宽会增加大量网络开销并使低带宽连接饱和，端点可见性的某些方面可以在网络级别实现，允许态势感知收集完全忽略端点提供的重复数据，或者用来自另一个数据集的信息证实一个数据集中的观察结果。
对端点态势感知的常见反对意见
三件事往往会阻止企业充分利用其端点作为网络态势感知工具。
首先，也是最明显的，大多数企业都有很多端点：传统工作站和服务器;移动设备，例如手机、平板电脑和笔记本电脑;以及联网的非传统设备，例如医疗和科学设备、销售点系统、条形码扫描仪，甚至灯泡。配置它们以使态势感知相关信息可用于分析的复杂性似乎是不可能的。幸运的是，大多数组织现在都有强大的程序来定义企业中所有机器应该如何配置的基线策略，以及用于执行这些策略的成熟工具。还要考虑到，即使是不完善的端点可见性也为网络安全防御者提供了重要价值。尽管看起来令人生畏，但实现端点可见性的技术问题可能比想象的要容易得多。
有效端点监测的另一个常见障碍是哲学上的。许多防御者对端点数据感到不舒服，因为控制端点的攻击者可能能够篡改它。这种担忧是一种合理的风险，但有一些方法可以管理它。管理篡改端点的可能性的最有效方法之一是配置应用程序日志记录以将日志消息导出到中央服务器。对于企业服务器，在所有日志消息创建后立即导出它们可能是合适的，但对于其他端点(例如工作站)来说通常是不切实际的，因为工作站数量更多，并且可能并不总是与企业有良好的连接。在这种情况下，要管理网络使用情况，应考虑在创建某些关键消息后立即导出日志，然后则需要定期导出优先级较低的消息(例如，每四个小时或当端点连接回企业网络时)。最后，请记住，即使是被泄露的日志也具有态势感知价值，因为它们可以揭示攻击者希望隐藏的内容，战术、技术和程序。
在许多企业中，端点监控的最大障碍不是技术，而是组织。端点管理通常独立于网络管理进行管理，并且可以进一步细分为对工作站、服务器、云与内部部署等的管理。真正全面的网络态势感知需要组织各部门的协作。建立这些桥梁可能是一项投资，但回报不仅仅是端点可见性，而是一种更全面的网络安全监控和响应方法。
分阶段的方法：从你所在的地方开始
正如我们所说，大多数组织都有大量的端点需要管理和监控，但不需要监控所有端点。可能希望从监控关键的本地服务器基础架构开始，然后将从中学到的东西带到基于云的服务器上，同时与工作站支持一起开发用于检测本地、云和移动端的策略- 用户环境。增量收益将带来增量价值和重要的经验教训。
分析什么数据
当开始计划将端点数据用于网络态势感知时，需要回答一些基本问题，例如
- 组织关心什么数据?
- 组织将如何使其可用于分析?
- 组织以后怎么改变主意?
端点有很多数据。后续部分讨论网络态势感知分析时，将讨论如何识别重要数据。目前，只需说以下类型的数据可能是最重要的数据(大致按此顺序)：
- 无法在其他任何地方获得的数据
- 将该数据与其他数据相关联的数据
- 证实你已经拥有的数据
我们显然对端点优势最感兴趣，我们可以看到在其他任何地方都看不到的东西。因此，首先考虑仅在端点上可用的事件的数据(和元数据)是有意义的。示例包括有关进程创建或端点防火墙阻止的网络连接尝试的信息。虽然这些数据很有用，但当可以将其与其他来源的数据融合时，就会变得非常有用。出于这个原因，第二种最重要的端点数据是可用于将端点数据与其他数据集相关联的信息。例如，网络连接检查可以发现网络连接包含恶意软件，端点数据可以发现主机上打开了哪些进程。有了进程列表和进程打开的网络连接(包括连接的时间戳和目标信息)，就可以确定哪个进程下载了恶意软件。
最后，虽然收集重复网络数据的端点数据似乎是浪费精力，但有时在两个不同的有利位置获得信息支持的推断可能很有价值。这种推论有助于分析师建立对他们结论的信心，并排除(或排除)任何一个传感器可能产生误报的可能性。
在哪里分析端点数据
一个相关的问题是在哪里存储这些数据。选择是
- 在端点
- 在中心位置
- 介于两者之间的东西
通常，将数据从端点移动到中央收集器可以实现更轻松地将数据与来自其他观察域和数据集的信息融合在一起。然而，端点是一个嘈杂的数据源，因此将所有内容发送回中心位置可能需要大量的工程工作。
一种方法是对端点本身进行分析。这种方法有两个主要缺点。首先是现在在一台机器上分析数据，根据定义，我们正在评估妥协的可能性，因此必须相应地调整对我们结果的信心。第二个考虑因素，不存在端点来进行安全分析影响可用性，端点的存在是为了做企业的生意，安全分析不应对可用性产生负面影响。
还有数据保留的问题。同样，在端点上存储大量历史数据会影响最终用户的服务可用性;如果想保留一段时间，则可能必须将其进行备份转移。
端点上的分析和存储以及将其全部移动到中央位置之间的一个可能折衷方案是建立中间收集点，这些收集点靠近(从网络角度)收集数据的端点。这些中间节点可以执行某些类型的分析，并且可以更长时间地存储数据，因为收集和分析数据是其存在的主要目的和价值。端点数据架构的一种特别有效的方法是使用这些收集点来运行管理分析，以确定哪些数据可以丢弃以及哪些数据值得保留。
当讨论网络态势感知工程时，当决定集中收集数据时，大多数工程考虑因素与网络数据的考虑因素相同，以后将更深入地讨论这些问题。现在，将只提及这个数据编排问题中与端点数据特别相关的几个方面：
- 用于将数据发送到中心位置的策略将取决于端点的网络连接，并且与端点的连接是高度可变的。他们将拥有多少带宽?他们什么时候会拥有它?是否需要采取额外措施来保护传输中的数据?由于所有这些考虑因素都会影响最佳策略，并且由于它们在端点之间都存在很大差异，因此可能需要处理关于端点数据的新近度或维度的不同保证。
- 网络检查数据收集通常针对少量相当大容量的数据流进行优化。端点数据收集针对大量相对低容量的数据流进行了优化。最适合一个人的架构可能不适合另一个人。然而，中间收集器可以提供帮助的另一种方法是简化这个问题，因为来自收集器的聚合端点数据看起来更像来自网络监视器的数据流，并且更适合相同的工程方法。
- 端点为企业工作，回程端点数据不应过度干扰可用性。通过端点监控，记住安全性的存在只是为了让任务更有可能成功。
- 接下来，将转向网络网络态势感知工程，讨论网络可见性，为什么除了端点可见性之外还需要它，以及何时在网络级别实施端点可见性的某些方面可能很有价值。
- 网络检查数据收集通常针对少量相当大容量的数据流进行优化。端点数据收集针对大量相对低容量的数据流进行了优化。最适合一个人的架构可能不适合另一个人。然而，中间收集器可以提供帮助的另一种方法是简化这个问题，因为来自收集器的聚合端点数据看起来更像来自网络监视器的数据流，并且更适合相同的工程方法。
- 端点为企业工作，回程端点数据不应过度干扰可用性。通过端点监控，记住安全性的存在只是为了让任务更有可能成功。
接下来，将转向网络网络态势感知工程，讨论网络可见性，为什么除了端点可见性之外还需要它，以及何时在网络级别实施端点可见性的某些方面可能很有价值。
