Closed rfuelsh closed 11 months ago
latacora suggested some things to look into:
Guard Duty’s runtime monitoring for EKS - I think you said you had this enabled, but if not, very useful for EKS Overview:
https://docs.aws.amazon.com/guardduty/latest/ug/features-kubernetes-protection.html#guardduty_runtime-monitoring In-depth documentation:
https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-eks-runtime-monitoring.html
Exporting findings to s3 - extremely useful as you’ll want to keep logs for later examination in the event of an IR https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_exportfindings.html
Cloud Watch: this is more for things like “Hey, this thing is suddenly using full CPU when it only uses 30%, we should look into that”
Generic anomaly detection: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html How to create an alarm https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html How to write metric math rule https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html
AWS Network Firewall can also assist with intrusions, as it utilizes Suricata
Rule engine explanation, links to Suricata documentation (open source intrusion prevention system): https://aws.amazon.com/blogs/security/how-you-can-use-amazon-guardduty-to-detect-suspicious-activity-within-your-aws-account/
In-depth rule evaluation documentation https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-rule-evaluation-order.html
working on a POC for falco in DEV
Installed falco on fuel-dev: https://falco.org/docs/getting-started/falco-kubernetes-quickstart/
$ kubectl get pods NAME READY STATUS RESTARTS AGE falco-ct9jk 2/2 Running 0 2m57s falco-falcosidekick-7bf6c5799c-2rts5 1/1 Running 0 2m57s falco-falcosidekick-7bf6c5799c-dnr82 1/1 Running 0 2m57s falco-w4zs9 2/2 Running 0 2m57s falco-x9sd8 2/2 Running 0 2m57s
Alerts going to slack
Our tooling covers this:
Our cloud and k8s tooling is constantly monitoring your environment for misconfigurations, exposed resources, etc. We have a process in place by which we raise any significant findings to you via Slack.
Our network monitoring picks up on any new exposed resources. These are then manually triaged, and if we notice anything out of place we again bring this up via Slack. intrusions, events in our AWS Guard Duty provides baseline monitoring for this type of activity.
There's some coverage in Guard Duty, but if you want something more comprehensive we'd recommend setting up https://falco.org/ to monitor your k8s workloads.
Take into account that the more tooling you have in place, the more effort is required in order to tweak, review, triage, and follow up on their output. It's important to tailor your monitoring to your capabilities, otherwise it's easy to get inundated in alerts.
We've partnered with Panther, and are currently Panther's only "MSSP": meaning: we're the only org that operates Panthers on behalf of other organizations. This is part of a bigger Latacora push towards increased capabilities, which includes managed SOC and even DFIR.
In the immediacy, what that means is that we'd be able to get you a Panther up and running. We've been using Panther for about as long as Panther has existed, and even ran its precursor tool, Streamalert, on behalf of clients.