云技术的采用正在快速发展，维护这些安全环境的风险和挑战也是如此。大规模地进行这项工作需要广泛地使用自动化和工具。DevSecOps方法也可用于检测和响应威胁，减少响应时间并防止潜在的漏洞。日志记录管道、松弛机器人程序、编排工具和无服务器技术以传统安全操作中心（SOC）无法提供的方式增强操作团队的能力。AWS GuardDuty等服务提供了不可或缺的威胁检测，以持续监控云资源上的恶意活动和未经授权的访问。在Auth0，我们从一开始就拥抱了云，由于我们组织中的众多AWS帐户中都有云资源，因此，大数据的概念，对云中的安全事件进行强有力的防御和及时的响应是我们的首要任务。这就是为什么我们的检测和响应团队采用了自动化云中安全事件响应的技术，以适应我们未来组织的增长。在本博客中，我们将概述已实现的体系结构，用于警报分析、分类、用户通知和自动响应所有AWS帐户上的AWS GuardDuty安全调查结果。AWS保修服务Amazon GuardDuty是一个威胁检测付费服务，它持续监控AWS帐户和工作负载上的恶意活动和未经授权的行为。该服务使用CloudTrail、VPC流和DNS日志，然后使用来自AWS和其他第三方服务（如crowdsteck）的威胁情报丰富它们。GuardDuty还使用机器学习技术来检测AWS帐户上的恶意活动。该服务是区域性的（需要在每个地区启用），并且有30天的免费试用期。在启用服务几分钟后，GuardDuty发现（如果有）将开始填充。在Auth0，我们在所有区域的帐户创建时启用GuardDuty服务。配置遵循主/成员设置，其中每个新的AWS帐户都成为主GuardDuty帐户的新成员。从那里，区域性CloudWatch事件规则和AWS Lambda函数的组合将所有的安全性事件发送到我们的安全信息和事件管理（SIEM）系统中。我们还密切监测这个生态系统的健康状况，因为任何故障都将意味着我们的警报系统出现严重缺口。例如，我们监视特定的GuardDuty API调用（例如Disassociate、StopMonitoring、DeleteDetector等），这些调用可能会篡改我们的基础结构，从而向我们的团队发出页面通知。此外，我们还订阅了GuardDuty Announcements SNS主题，并将警报与我们的bot集成，因此当有新的GuardDuty发现或现有的更新需要我们关注时，我们会收到延迟通知。安全机器人在Auth0，云服务器买，我们严重依赖Slack作为我们的主要通信渠道。除此之外，我们还创建了Slack Bots，它可以自动化我们的常见任务，帮助我们扩展和更好地响应安全事件。其中之一就是SecurityBot，它是由检测和响应团队在我们的安全编排、自动化和响应（SOAR）系统上开发的。Auth0的SecurityBot的灵感来自Slack和Dropbox的安全团队的出色工作。SecurityBot帮助我们完成两个主要任务：作为一个ChatOps函数，我们可以要求bot创建一个事件响应通道，向其中添加所有必要的成员，启动事件文档，或者对特定的ip和域执行调查。作为我们与员工沟通的主要渠道。机器人可以向我们的员工发送通知或查询消息（需要确认），请求MFA确认，甚至在员工对特定事件做出负面反应时呼叫我们的团队。AWS事件响应工具（AWS ir）在处理事件时尤其重要的是要及时做出反应。出于这个原因，我们的团队开发了一个内部工具，使对AWS的调查和响应变得更加简单和可重复。AWS-IR是一个构建在无服务器基础设施上的API，万云，它允许我们的团队在AWS帐户中的特定机器上获取必要的取证工件和响应选项。这些行动主要是：获取实例卷的快照。运行一组osquery命令。进行内存转储。以网络流量的tcpdump为例。隔离实例。我们已经将这个工具与对GuardDuty事件的响应集成在一起，这样我们就可以根据警报的严重性收集工件并执行响应操作。蜂巢项目为所采取的行动和收集的工件保存记录有时是一项"无聊"但却是必要的任务，同时执行对事件的响应。Hive项目是我们用来执行调查的主要票务和工件收集平台。我们依赖它的api来创建警报，将它们提升到案例中，并上传我们自动收集的工件。像专业人士一样自动响应既然我们已经解释了构成体系结构的所有不同元素，让我们看看如何将它们粘在一起。在这方面，我们与安全自动化公司Tines合作。我们的检测堆栈中的每一个警报，无论是来自SIEM、GuardDuty、网络钓鱼，还是我们构建的定制工具，都首先经过tine，然后对其进行丰富、优先排序和标记。我们还使用TINE来自动响应警戒警报。在启用GuardDuty之后，最常见的一个观察结果是，在一开始它可能会令人望而生畏，并且需要大量的时间来调整它，使其适合您的环境。让我们看一下这个调优的几个示例以及一些相关的注意事项：网络负载平衡器：端口探测警报误报接收一个实例的安全事件，该实例有一个随机端口，正被一个恶意IP从互联网上探测到。但是，如果实例没有公共IP，并且位于负载平衡器后面，并且端口443对internet开放，那么情况就发生了变化。这样做的原因是，默认情况下，网络负载平衡器提供"源IP保留"，客户端的源IP地址将保留并提供给您的后端应用程序。下面的公开文章也记录了这一点。稍后，我们将讨论如何克服这个限制，当对负载平衡器进行更改不是一个选项时。对无害的客户提供的域发出警报如果您的服务获取或接收客户提供的域并查询它们（就像我们的情况一样），GuardDuty可以将某些合法活动标记为恶意的。我们遇到了假阳性的"后门和木马"警报，这是由于客户向我们的服务中提供了标记的域。在员工外出时检测异常机器学习是伟大的，大数据公司，我们绝对相信这种技术用于检测目的（为了我们自己的利益，我们希望进一步扩展这项技术）。不过，在一家远程友好型公司，员工们都在流动，微信返利机器人安全吗，不断地改变他们的位置和IP源，这一点并不能很好地应对。已终止的EC2实例的GuardDuty事件我们收到了实例状态为"terminated"的GuardDuty事件（此信息包含在GuardDuty事件中）。在一个短暂的基础设施上，实例是按需启动和拆除的，并且没有长期运行的服务，这可能会限制我们响应事件或执行实时调查的能力。云环境中的可见性差距对于容器/微服务来说，数字取证和事件响应（DFIR）缺乏可见性，尤其是当它们运行在同一个EC2实例上时。警报将来自同一个EC2，并且需要额外的日志/工具来响应这些警报。"了解如何调整GuardDuty，使其适用于您的环境以及相关的注意事项。"在推特上留言因此，让我们更深入地了解我们是如何自动响应这些可靠的发现并克服其中一些挑战的。我们将不同的防范事件及其应对措施分为四类：EC2端口探测器警报IAM用户非严重警报IAM用户关键警报EC2其他警报让我们看一下每个人的回答。PortProbe警报第一组警报涉及入站端口探测，这意味着可能有恶意的IPs探测在互联网上打开的端口。我们有PortProbe类型的事件(侦察：EC2/PortProbeUnprotectedPort)以及这个组中包含的SSH和RDP暴力事件。最初，我们过滤掉已知开放且经常受到攻击的公共端口（例如，端口443）。如负载均衡器后面提到的44个实例，也是我们所说的负载均衡器后面常见的事件。因此，我们构建了一个AWS Step函数，该函数将网络负载平衡器端口映射到实例端口，并将这些信息转储到DynamoDB数据库中。在Tines中，我们查询数据库以过滤掉侦听端口为80或443的网络负载平衡器后面的实例的警报。最后，如果事件没有被过滤并且之前没有被通知，我们通过SecurityBot向资源所有者发送一个通知（基于实例标记）。IAM用户非严重警报在本组中，我们将涵盖我们认为不重要的GuardDuty IAMUser事件。这些事件通常表示AWS主体发出可疑的API调用。我们处理这些警报的主要操作是首先自动确定主体到雇员及其端点计算机的映射。从那里，我们检查他们的设备IP并将其与警报中的IP进行比较。如果有任何不匹配，我们将触发SecurityBot查询消息，要求员工确认他们进行了awsapi调用。我是你