(_name = 'GetFederationToken' & _code='AccessDenied')Īlthough AWS documentation is not that clear about this, it seems that Console login failures are logged in us-east-1, whereas successful attempts are logged in the user's region. (_name = 'GetSessionToken' & _code='AccessDenied') || (_name = 'ConsoleLogin' & .ConsoleLogin = 'Failure') || Name: crowdsecurity/aws-cloudtrail-bf-console-loginĭescription: "Detect console login bruteforce"Įvt.Meta.log_type = 'aws-cloudtrail' & ( The scenario itself is quite straightforward: What is interesting when dealing with brute force on the AWS Console is that it will only be triggered with failed logins targeting your org and an existing username, so the risk of false positive is very low. (().String() = 'Saturday' || ().String() = 'Sunday')Īll the timestamps are in UTC, so adapting the proper time is left as an exercise to the reader 🙂 Detecting Console brute force (_name = 'ConsoleLogin' || _name = 'GetSessionToken' || _name = 'GetFederationToken') &Įvt.?.ConsoleLogin = 'Success' & Name: crowdsecurity/aws-cloudtrail-nwo-nwd-console-loginĭescription: "Detect console login outside of office hours" So one of the first things we did was to reimplement the CIS benchmark, this time using CloudTrail:Īs an example, the implementation of the rule Detect AWS CloudTrail configuration change looks like this: Step 1: CIS benchmark with better notificationsĪs I mentioned earlier, when we implemented the support for CIS benchmark internally, the lack of flexibility we faced with the AWS chatbot was the initial reason behind our decision to add support for CloudTrail. This file is available in the AWS collection installable with CSCLI. IsIP() ? : ""Įxpression: Įxpression: Įxpression: Įxpression: .accountId Note: Some events are made global on the AWS side and will be logged in us-east-1 CloudTrail region, so we suggest that you use a multi-region trail.įilter: " = 'aws-cloudtrail'"Įxpression: UnmarshalJSON(, evt.Unmarshaled, 'cloudtrail')Įxpression: Įxpression: .typeĮvt.?.arn ? .userNameĮxpression: Įxpression: Įxpression: Note: This is quite an advanced topic, so I am assuming a certain level of knowledge on the side of the reader, namely on AWS CloudTrail and on the some CrowdSec concepts, such as data sources, parsers, scenarios, exceptions and profiles.ĬrowdSec already supports AWS Kinesis stream, but we added support for AWS S3 bucket, alongside SQS S3 notifications for convenience, as it’s the most common way to log AWS CloudTrail.Īs a bonus, AWS S3 makes the usage of CrowdSec replay mode (which we’ll be using in this article to test our scenarios) a lot easier! Requirements: Retrieving and parsing CloudTrail logs non-working days, non-working hours, etc.) Presenting a couple examples of security (rather than pure compliance) scenarios: Detecting brute force on the AWS Console, and detecting suspicious logins (i.e.Using CrowdSec on top of CloudTrail to cover CIS benchmark compliance, with the addition of exceptions and fine-tuning to limit false positives.In this article, I will be covering the following:
While this project started simply because we were not satisfied with the AWS chatbot (it cannot be described using IaC tools, it is noisy, offers no exceptions etc.), we went a lot further than the original scope of the project. Spoiler alert: We’re doing the same thing with Kubernetes and the support for Kubernetes audit logs.ĪWS CloudTrail has been a recurrent requested feature, so we decided to give it a shot. While we were working on improving the security of our data lake, we faced some limitations in the existing security tooling that looked like a great use case for CrowdSec!ĬrowdSec already effectively protects workloads on AWS - it supports Kinesis as a data source and AWS WAF as a remediation component - we wanted to be able to protect our AWS infrastructure itself.
At CrowdSec, we have a dedicated AWS serverless architecture to process the 20 million signals we receive on a daily basis.
0 kommentar(er)
