SyntheticSun

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

你睡在碎玻璃中
映着你的倒影，
但你是否感到鲜活？
是啊，让我问你，
你是否感到鲜活？
_{- Norma Jean, 2016}

概述

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

描述

SyntheticSun 围绕恶意软件信息共享平台（MISP）和 Anomali 的 LIMO 构建，两者都是社区驱动的威胁情报平台（TIP），提供各种类型的入侵指标（IoC）。标准化并去重后的威胁情报会被近乎实时地查询，以快速识别各类网络流量中的已知威胁。为了更有动态性地识别潜在威胁，我们部署了 IP Insights 模型来发现 IP 地址与实体（如 IAM 主体 ID、用户代理等）配对中的异常（以及其中的潜在威胁）；同时也在 Elasticsearch 中使用原生 RCF 检测器，在安全遥测数据流式进入 Kibana 时近乎实时地发现异常。为了让安全团队更普遍地使用和微调机器学习模型，我们提供了作为核心解决方案附加组件的 IP Insights 模型训练工具。

为了执行编排和自动化，以及将安全遥测数据提取、转换和加载（ETL）到 Kibana，我们使用了各种 AWS 无服务器技术，如 AWS Lambda、Amazon DynamoDB 和 AWS CodeBuild。之所以使用此类无服务器技术，是因为它们具有可扩展性、易用性，并且相对于厚重的 MapReduce 或 Glue ETL 解决方案成本较低。解决方案的大部分通过 CloudFormation 部署，并在各个阶段提供了 Python 和 Shell 辅助脚本，以促进采用以及潜在的在持续集成流水线中的部署。

为了使解决方案的“核心”尽可能精简，基本的 Python 模块如 boto3、requests、json、ipaddress、socket 和 re 执行了大部分的下游服务 ETL 操作。由于所有地理位置信息由 ip-api.com 提供，它不需要账户或付费层级，并且拥有一个很棒的 API，在其响应头中包含了限流信息。大部分 Elasticsearch 和 Kibana 依赖项（索引、映射、可视化等）也以代码形式提供，以避免繁琐的手动配置。

设置

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

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

SyntheticSun 毕竟是你在 GitHub 上找到的东西，它是一个概念验证，因此我在首次发布时并没有额外花费精力来进行绝对强化。假设你阅读这段文字时我还没有做出必要的更改，那么在将此解决方案部署到生产环境（或任何安全性要求较高的环境）之前，请考虑以下几点。我会将这些事项列入路线图，并适时更新。

1. 使用附录 A 中的示例训练你自己的 IP Insights 模型。使用你自己的数据并持续重新训练模型，有助于提高发现结果的准确性。
2. 将你的 CodeBuild 项目、MISP 服务器和 Elasticsearch Service 域部署在 VPC 中，以强化抵御来自互联网的攻击。考虑使用 AWS 的 Client VPN、AWS Site-to-Site VPN、DirectConnect、Amazon WorkSpaces 和 AppStream 2.0，或者（如果实在没办法）反向代理来访问 VPC 内的 MISP 控制台和 Kibana。
3. 考虑使用 Cognito 为 Kibana 进行身份验证。更进一步，可以将你的用户池与公司 IdP 联合。
4. 考虑为 MISP 烘焙你自己的 AMI，或者使用 Fargate 来托管它。我还建议将 Suricata 和 Amazon CloudWatch Agent 预先烘焙到未来的构建中，以帮助在您的资产范围内扩展代理和 HIDPS 的部署。
5. 修改你的 Suricata 配置，以满足查看日志的 SecOps 团队的需求，因为本解决方案只负责将日志存储进去。你也可以考虑编写自己的规则或导入其他来源，以强化主机抵御攻击。

前提条件

• 对 AWS 账户的管理员访问权限（如果在多账户部署中使用，你必须在主账户或委托管理主账户所在的账户中操作）
• 至少带有一个目标实例且启用了访问日志的 Application Load Balancer (ALB)
• 账户中已启用 CloudTrail 日志记录
• 一个 VPC，至少包含一个私有子网（路由到 NATGW）、一个公有子网（路由到 IGW），并且 VPC Flow Logs 已启用并发布到 CloudWatch Logs

第一阶段从这里开始

FAQ

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

SyntheticSun 是开始使用网络威胁情报和机器学习来保护 AWS 云上边缘安全的简单方法，无需投资于一个或多个商业工具，也无需为您的安全团队雇佣数据科学家（尽管理想情况下您应该这样做）。经过初始配置后，此解决方案完全自动化，让您能够以机器速度识别和响应威胁。最后，此解决方案为您的应急响应团队提供了可用于威胁响应的基本可视化，例如允许的入站或出站连接，或者对被视为恶意的 IP 地址或域名的 DNS 查询。解决方案的核心依赖于非常轻量级的自动化和数据工程流水线，理论上这些流水线可以重用于其他需要多阶段标准化和丰富化，或者需要定期快速批处理作业的场景。

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

首先，如果您正在使用 Amazon GuardDuty 和/或 AWS WAF，评估此解决方案可能是有意义的，但这也是一个必要条件。明显可以利用它的角色是那些负责保护其全栈产品、但缺乏资金或专业知识来建模、训练和部署机器学习算法，或者无法有意义地运营网络威胁情报源的产品团队。这些角色可能是安全工程、SecOps / SOC 分析师和工程师，或者 DevSecOps 工程师；不过这个列表并不详尽，他们不一定非得是产品/应用导向的，中央团队也可以使用。另一个用途是那些在中央团队工作、希望为防火墙和入侵防御系统创建动态阻止列表的同等角色（SecOps、安全工程），CodeBuild 项目可以重用于将 CSV 或平面文件输出到几乎任何位置（例如 Palo Alto 防火墙、Squid 正向代理 URL 过滤器等）。

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

SyntheticSun 目前缺乏对所有主要日志源的全面覆盖——即 S3 Access Logs 和 CloudFront Access Logs，而这两者对于许多人提供服务（尤其是基于 S3 存储桶的 SPA）至关重要。异常检测尚未扩展到 WAF、API Gateway Access Logs 或 CloudTrail 之外，因为我痴迷于 IP Insights，而且完全没有接受过数据科学训练（说真的，我甚至不知道如何使用 pandas 或 numpy）。除了尝试在日志中匹配原始威胁情报 IoC 之外，没有对其做任何深入分析。

4. 除了 AWS 安全服务的主账户之外，组织级部署还有哪些考虑因素？

在组织中部署此解决方案的最简单方法是将其部署在集中的安全服务账户中。对于较低级别的遥测数据，如 VPC Flow Logs 和 WAF Logs，您应考虑通过 AWS Service Catalog 提供辅助脚本或 CloudFormation 模板，以促进在较低环境中的启用。您需要评估 Elasticsearch Service 的分片消耗和索引轮转，以及如果您要跨账户发布 Kinesis Data Firehose 投递流到集中位置时的权限。我在自己的个人沙箱账户中构建了这个解决方案，因此没有将上述任何考虑因素融入到解决方案中，我很乐意处理以此为目的的 PR，也可能在未来自己进行修改。

截至 2020 年 7 月 31 日，AWS Firewall Manager 策略支持跨账户聚合 WAF 日志记录，这让你离减少痛苦又近了一步……

5. 什么是 IP Insights 算法？我这样用真的是它的本意吗？

警告：我不是数据科学家，而且这会是一个很长的答案。简而言之：它是一个异常发现器，而且我认为是这样使用的？

鉴于我远非数据科学家，也没有接受过任何训练，你最好阅读文档来了解它。话虽如此，以下是我从外行角度对其进行的尝试解释：IP Insights 是一种无监督机器学习算法，它学习 IPv4 地址与实体（例如账户号、用户名、用户代理）之间的关系。然后 IP Insights 尝试确定该实体使用该 IPv4 地址的可能性有多大。在 IP Insights 背后是一个神经网络，它学习这些实体和 IPv4 地址的潜在向量表示。这些向量化表示之间的距离体现了实体与 IPv4 地址关联（例如从该 IP 发送请求）的异常（或不异常）程度。

神经网络几乎就像听起来那样；它们形成了一种旨在模仿人脑行为的机器学习系统，拥有计算机化的神经元和突触。在无监督机器学习中，该算法可以通过查看所有 IPv4 地址与其配对实体之间的关联，来找出什么是“好”（即真阴性）以及什么是“坏”（即真阳性）。通过评估这种关联来识别哪些向量与其他向量相似，依据是它们的“距离”。在 IP Insights 中，提供了一个预构建的编码器，用于搜索 IPv4 地址，然后将所有实体哈希成簇。然后它使用向量化技术对其进行迭代。向量化是一种以矩阵方式执行计算的方法，而不是逐个循环（想象一下对包含数千万个值的列表执行“For”循环）。

当你训练 IP Insights 模型时，它实际上会通过将 IPv4 地址与距离很远（即高度异常）且不太可能在现实中出现的实体配对，来为自己制造假阳性；这样模型现在可以区分真阳性、假阳性和真阴性。这样做是为了防止另一个疯狂术语“交叉熵”（又名“对数损失”，好像这样更好理解），并引入了另一个术语“二元分类”。IP Insights 本质上是在问：“这个 IP 地址与这个实体配对是异常的概率是多少？”这就是它成为二元分类的原因，我认为，所以是“是，它是坏的”或“不，它不是坏的”。概率表示为一个介于 0 和 1 之间的值；所有机器学习模型的目标是让这个值尽可能接近 0，因此对实际为 1 的事物（已知真阳性）预测值为 0.01 会导致非常高的对数损失。因此，通过制造故意的不良数据，IP Insights 帮助在训练期间减少这种对数损失（即不良预测）。

这就引出了端点的输出。当你查询它时（无论是在批处理中还是使用 InvokeEndpoint API 实时查询），响应是一个无界浮点数，可以是负数也可以是正数。它高于 0 越多，就越可能是异常的，这就是你工作的起点。对于这个解决方案，我选择了任何高于 0.03 的值，这很大程度上是理论上的；为了更接近真相，你应该向端点提供真阳性，看看你的响应是什么。基于这些发现，你可以配置一个分层方法，例如应用程序可能发出第二因素挑战、发出警报或根据得分直接阻止。关于问题的后半部分，答案是“是的，我认为是这样”，用用户代理与 IP 配对来训练模型实际上相当冒险。但对于其他不那么易变的实体（账户号、用户名、IAM 用户），感觉这是预期的用法。

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

在解决方案中，我提供了一些你应该使用的示例源，有些非常明显，如网络犯罪域名源、Emerging Threats 和 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 Gateway Access Logs，也许还有一些基于主机的日志。

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

我其实更倾向于使用 Kinesis Data Agent，但我发现了很多问题：它默认不包含在 Amazon Linux 2 中，而且现在 Ubuntu 18.04 LTS AMI 预装了 Java 11，我遇到了 Agent 的向后兼容性问题，因为它要求 OpenJDK 8 或 9 才能成功构建。安装 CloudWatch Agent 要容易得多，因为它经常更新新功能，并且有 Systems Manager Document 支持配置；它甚至有一个安装向导。如果 AWS 未来能像对待 CloudWatch Agent 那样认真对待 Kinesis Data Agent 的支持，我可能会切换到它，因为我更希望对于某些基于主机的日志（Suricata、Squid、Nginx、Apache）直接发布到 Kinesis Data Firehose，而不是使用 CloudWatch Logs 作为中介。

贡献

我很乐意接受针对 Issues 或 Project Board 中标记为“Help Wanted”的项目的 PR。如果其他提议的 PR 符合项目精神，我也会审查。

早期贡献者

特别感谢 David Dorsey 和 Ryan Nolette，他们提供了宝贵的反馈、测试和贡献，帮助调整了 SyntheticSun。

许可证

本库根据 GNU General Public License v3.0 (GPL-3.0) 许可证进行授权。详见 LICENSE 文件。