SyntheticSun 是一个深度防御安全自动化和监控框架，它利用威胁情报、机器学习、托管 AWS 安全服务和无服务器技术来持续预防、检测和响应威胁。

你睡在碎玻璃里
带着你的倒影，
但是你觉得还活着吗？
是的，我问你，
你觉得还活着吗？

概要

• 使用基于事件和时间的无服务器自动化（例如 AWS CodeBuild、AWS Lambda）来收集、规范化、丰富和关联 Kibana 中的安全遥测数据
• 利用威胁情报、地理位置数据、开源情报、机器学习 (ML) 支持的异常检测和 AWS API 来进一步丰富安全遥测并识别潜在威胁
• 利用 Random Cut Forests (RCF) 和 IP Insights 无监督 ML 算法分别识别时间序列和 IP-实体对数据中的异常。 提供无服务器、容器编排的资源来随意训练和部署新的 IP Insights 端点。
• 动态更新 AWS WAFv2 IP 集和 Amazon GuardDuty 威胁情报集，以加强保护您的账户和基础设施免受已知威胁

描述

SyntheticSun 是围绕恶意软件信息共享平台 (MISP) 和 Anomali 的 LIMO 构建的，它们是社区驱动的威胁情报平台 (TIP)，可提供各种类型的妥协指标 (IoC)。 近乎实时地查找标准化和去重的威胁情报，以快速识别各种类型的网络流量中的已知威胁。 为了增加识别潜在威胁的活力，部署了 IP Insights 模型以发现 IP 地址和实体（例如 IAM 主体 ID、用户代理等）配对之间的异常（以及其中的潜在威胁），本地 RCF 检测器是在 Elasticsearch 中也用于在近实时安全遥测中发现异常，因为它被流式传输到 Kibana。 为了在安全团队中普及 ML 模型的使用和微调，提供了用于训练 IP Insights 模型的实用程序作为核心解决方案的附加组件。

为了在 Kibana 中执行编排和自动化以及安全遥测的提取、转换和加载 (ETL)，使用了各种 AWS 无服务器技术，例如 AWS Lambda、Amazon DynamoDB 和 AWS CodeBuild。 与基于 MapReduce 或 Glue ETL 的重型解决方案相比，此类无服务器技术因其可扩展性、易用性和相对便宜的成本而被使用。 大多数解决方案通过 CloudFormation 部署，并在各个阶段提供 Python 和 shell 中的帮助脚本，以促进持续集成管道中的采用和潜在部署。

使解决方案的“胆量”尽可能精简基本 Python 模块，例如boto3,requests,json,ipaddress,socket和re将大部分提取、转换和加载 (ETL) 执行到下游服务中。 因为所有地理位置信息都由 ip-api.com ，所以它不需要帐户或付费层级，并且有一个很棒的 AP​​I，其中包括响应标头中的限制信息。 大多数 Elasticsearch 和 Kibana 依赖项也在代码中提供（索引、映射、可视化等），以避免繁重的手动配置。

配置

由于解决方案的大小和所需的依赖关系，SyntheticSun 分布在三个阶段。 所有架构和安装说明（以及适当的常见问题解答）都存在于它们自己的阶段中。 还提供了附加模块（称为附录）来扩展功能，这些模块具有自己的体系结构和本地化安装说明。

开始之前：生产部署的注意事项

SyntheticSun 是你在 GitHub 上找到的东西，它是一个概念验证，因此我没有为第一个版本付出额外的努力来绝对强化一切。 如果您在我没有进行必要更改的时间点阅读本文，请在将此解决方案部署到生产环境（或任何具有更高安全需求的环境）之前考虑以下事项。 我会将这些项目放在路线图上，并在适当时对其进行更新。

1. 中提供的示例训练您自己的 IP 洞察模型 附录 A 。 使用您自己的数据，并不断重新训练模型，将有助于准确发现结果。
2. 在 VPC 中部署您的 CodeBuild 项目、MISP 服务器和 Elasticsearch Service 域，以加强抵御互联网传播的攻击。 考虑使用 AWS 的客户端 VPN、AWS Site-to-Site VPN、DirectConnect、Amazon Workspaces 和 AppStream 2.0 或（如果您绝对必须）使用反向代理来访问 VPC 中的 MISP 控制台和 Kibana。
3. 考虑使用 Cognito 将 AuthN 用于 Kibana。 更进一步，将您的用户池与您的公司 IdP 联合起来。
4. 考虑为 MISP 烘焙您自己的 AMI 或使用 Fargate 来托管它。 我还会考虑将 Suricata 和 Amazon CloudWatch 代理预烘焙到未来的构建中，以帮助在您的资产中扩展代理和 HIDPS 的部署。
5. 修改您的 Suricata 配置以满足您的 SecOps 团队查看日志的需求，因为该解决方案所做的只是将它们转储。您还可以考虑编写自己的规则或导入其他源来强化您的主机免受攻击。

先决条件

• 对 AWS 账户的管理员访问权限（如果您在多账户部署中使用此账户，您必须在您的 Master 或 Delegated Admin Master 所在的账户中）
• 至少启用一个目标实例和访问日志的应用程序负载均衡器 (ALB)
• 在您的帐户中启用 CloudTrail 日志记录
• 一个 VPC，至少有一个私有子网（路由到 NATGW）、一个公有子网（路由到 IGW），并且启用了 VPC 流日志并发布到 CloudWatch Logs

第一阶段从这里开始

常问问题

1. 为什么要使用这个解决方案？

SyntheticSun 是一种开始在 AWS 云上为您的边缘保护安全用例使用网络威胁情报和机器学习的简单方法，而无需投资购买一个或多个商业工具，或为您的安全团队聘请数据科学家（尽管理想情况下您应该做后者）。 该解决方案在初始配置后是完全自动化的，允许您以机器速度识别和响应威胁。 最后，此解决方案为您的事件响应团队提供基本的可视化，以用于威胁响应，例如允许的入站或出站连接或与被视为恶意的 IP 地址或域之间的 DNS 查询。 该解决方案的核心依赖于非常轻量级的自动化和数据工程管道，理论上，这些管道可以重用于需要多阶段规范化和丰富或计划的、快节奏的批处理作业的其他目的。

2. 谁应该使用这个解决方案？

首先，如果您使用 Amazon GuardDuty 和/或 AWS WAF，评估此解决方案可能是有意义的，但这也是一项要求。 可以利用的明显角色是负责保护其完整堆栈的产品团队，并且缺乏资本或专业知识来建模、训练和部署机器学习算法或有意义地操作网络威胁情报源。 上述角色可能是安全工程、SecOps / SOC 分析师和工程师，或 DevSecOps 工程师； 但是，此列表并不详尽，它们不需要与产品/应用程序保持一致，因为中央团队也可以使用它。 另一种用法是为集中式团队工作并希望为防火墙和入侵防御系统创建动态阻止列表的相同角色（SecOps、安全工程），CodeBuild 项目可以重新用于将 CSV 或平面文件拖放到几乎任何位置（例如 Palo Alto 防火墙、Squid 转发代理 URL 过滤器等）。

3. 这个解决方案有哪些差距？

SyntheticSun 目前缺乏对所有主要日志源的全面覆盖——即 S3 访问日志和 CloudFront 访问日志，它们是许多人交付服务方式不可或缺的一部分（尤其是对于 S3 存储桶上的 SPA）。 由于我对 IP Insights 的痴迷和完全缺乏任何数据科学培训（说真的，我什至不知道如何使用pandas要么numpy）。 除了尝试在日志中匹配它之外，没有对原始威胁情报 IoC 的任何深入分析。

4. 除了 AWS 安全服务大师之外，组织部署还有哪些注意事项？

为组织部署此解决方案的最简单方法是将其部署在集中式安全服务帐户中。 对于 VPC 流日志等较低级别的遥测 和 WAF 日志 ，您应该考虑通过 AWS Service Catalog 提供帮助程序脚本或 CloudFormation 模板，以促进在较低环境中的启用。 如果您要将跨账户 Kinesis Data Firehose 传输流发布到集中位置，则需要评估 Elasticsearch Service 的分片消耗和索引轮换以及权限。 我在我的个人沙盒帐户中构建了这个解决方案，因此为什么我没有将上面的任何考虑因素纳入解决方案，我很乐意考虑到这一点来进行 PR，并且将来可能会自己做。

自 2020 年 7 月 31 日起，AWS Firewall Manager 策略支持 WAF 日志记录的多账户聚合，这让您离减少痛苦更近了一步……

5. 什么是 IP Insights 算法？ 你的使用真的是它的用途吗？

警告 ：我不是数据科学家，这将是一个很长的答案。 Tl;博士：我认为这是一个异常发现者？

鉴于我与数据科学家的距离并不遥远，也没有接受过任何培训，因此最好 阅读有关这方面的文档 。 也就是说，这是我的门外汉的尝试：IP Insights 是一种无监督机器学习算法，可以学习 IPv4 地址和实体（例如帐号、用户名、用户代理）之间的关系。 然后，IP Insights 会尝试确定该实体使用该 IPv4 地址的可能性有多大。 IP Insights 的幕后是一个学习这些实体和 IPv4 地址的潜在向量表示的神经网络。 这些向量化表示之间的距离象征着实体与 IPv4 地址相关联（例如从其发送请求）的异常（或不异常）。

神经网络几乎和听起来一模一样； 它们形成了一个机器学习系统，其行为类似于人类大脑，配有计算机化的神经元和突触。 在无监督机器学习中，算法可以通过查看所有 IPv4 地址及其配对实体之间的关联来判断“好”（即真阴性）与“坏”（即真阳性）的外观。 评估这种关联是为了通过它们的“距离”来识别哪些向量与其他向量相似。 在 IP Insights 的案例中，提供了一个预构建的编码器，用于搜索 IPv4 地址，然后将所有实体散列到集群中。 然后它使用矢量化对它们进行迭代。 矢量化是一种将计算作为矩阵执行而不是在它们上循环的方法（想想包含数千万个值的列表的“For”循环）。

当您训练 IP Insights 模型时，它实际上会通过将 IPv4 地址与距离较远（即高度异常）且不太可能在现实中实际发生的实体配对来创建自己的误报； 该模型现在可以区分真阳性、假阳性和真阴性。 这样做是为了防止另一个称为“交叉熵”的疯狂术语（也称为“对数损失”，好像这样可以使它更好），并引入了另一个术语，二元分类。 IP Insights 本质上是在问：“与​​该实体配对的 IP 地址异常的可能性有多大？” 我认为这就是使它成为二进制的原因，所以“是的，它很糟糕”或“不是的，它不是”。 概率表示为介于 0 和 1 之间的值，所有机器学习模型的目标是使其尽可能接近 0，因此对于真正为 1（已知为真阳性）的事物预测值 0.01 将导致非常高的对数损失。 因此，尽管如此，IP Insights 通过故意制作垃圾数据有助于减少训练期间的日志丢失（即错误预测）。

这将我们带到端点的输出。 当您查询它时（通过批处理或近乎实时的使用InvokeEndpointAPI）响应是一个无界的浮点数，可以是负数也可以是正数。 高于 0 的值越高，异常的可能性就越大，这就是你的工作开始的地方。 对于这个解决方案，我选择了高于 0.03 的任何值，这在很大程度上是概念性的，为了更接近真相，您应该向端点提供 True Positives 并查看您的响应是什么。 根据这些发现，您可以配置一种分层方法，您的应用程序可能会根据分数发出第二个因素挑战、发出警报或直接阻止它。 问题第二部分的答案是“是的，我想是的”，使用与 IP 配对的用户代理来训练模型实际上非常粗略。 现在，对于其他波动性较小的实体（帐号、用户名、IAM 用户）来说，感觉就像是预期的用途。

6. 我应该使用哪些威胁情报源？ 如果有重复怎么办？

在解决方案中，我提供了一些您应该使用的示例提要，其中一些非常明显，例如网络犯罪域提要、新兴威胁和 CI-badguys。 在我的实际工作中，我与全世界最有才华的网络威胁情报专家之一合作（不是开玩笑，她很棒！），他们也影响了选择。 就像机器学习模型和您将构建的任何其他东西一样，您应该定制您的威胁情报源和聚合以匹配您当前的威胁环境。 重复项在 MISP 中被识别，并且在 DynamoDB 表中仅指定一个哈希键以强制唯一性，因此即使有 5 个提要报告同一 IPv4 地址，也只有一个会出现在表中。

您还可以将自己的商业威胁英特尔平台和信息源（例如 InfoBlox 或 Recorded Future）引入此解决方案，方法是将它们指向具有类似语法的 DynamoDB 表。

7. 我查看了 S3 中的原始日志源，但没有看到 Elasticsearch 中的条目； 为什么是这样？

大多数来自 AWS 的日志交付都是“尽力而为”，因此没有发布官方的 SLA； 但是，我假设它在 99.5 – 99.9% 左右，最后 0.5 – 0.1% 的任何东西都不会交付。 “生产”流量在 AWS 中也是一流的； 如果存在网络带宽限制，它将默认将连接传递回客户端，而不是发送日志。 更有可能的事件是原始日志文件太大，Lambda 无法及时处理整个事情； 当您被来自同一个客户端 IP 的 DOS 或爬虫所困扰时，您会经常看到这一点。 WAF 和 ALB 由调用者捆绑日志文件（据我所知），因此如果您吸收数百个请求，日志文件可能会非常大。

8. 我在 VPC 中有一个现有的 Elasticsearch Service 域； 这个解决方案会起作用吗？

可以，但是您需要执行以下操作之一：

• 将 Lambda 函数放入 VPC 并为 S3、DynamoDB 和 CloudWatch Logs 附加 VPC 终端节点。
• 或者，修改解决方案以将最终格式化日志发布到 Kinesis Data Firehose 并将它们指向您在 VPC 中的 ES 域。

这需要额外的费用。 VPC 中的 Lambda，尤其是对于数十个并发调用，可能会导致更多问题，因为 ENI 仍然存在并占用您的 RFC1918 空间。 除非您绝对必须隔离 VPC 内的所有流量以满足合规性要求，否则我不会走这条路。

9. 我可以将这些日志源发布到 Splunk 吗？

是的，这可以通过修改解决方案以将最终格式化日志发布到 Kinesis Data Firehose 并将它们指向 Splunk 来实现。

10. 你会支持任何其他的日志源吗？

希望能支持 Route 53 DNS Logs, S3 Access Logs, CloudFront Access Logs 和 API 网关访问日志 将来可能还会有其他一些基于主机的日志。

一种

11. 为什么使用 CloudWatch 代理而不是 Kinesis Data Agent？

老实说，我更愿意使用 Kinesis Data Agent，但我发现它存在很多问题：Amazon Linux 2 默认不包含它，现在 Ubuntu 18.04 LTS AMI 预装了 Java 11，我正在运行除非您有 OpenJDK 8 或 9，否则它会导致与代理的向后兼容性问题，因为它会导致构建失败。安装 CloudWatch 代理要容易得多，因为它经常使用新功能进行更新，并且有用于配置的 Systems Manager 文档支持； 它甚至有一个安装向导。 如果 AWS 曾经像 CloudWatch 代理一样重视 Kinesis Data Agent 支持，我可能会切换到它，因为我更愿意将某些基于主机的日志（Suricata、Squid、Nginx、Apache）直接发布到 Kinesis Data Firehose，而不是使用 CloudWatch Logs作为中介。

https://github.com/jonrau1/SyntheticSun