Realtime alerting for guardduty findings
Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior in your AWS account. There are over 50 scenarios GuardDuty monitors. Examples of these include Recon:EC2/Portscan, Recon:IAMUser/UserPermissions, and Stealth:IAMUser/CloudTrailLoggingDisabled. Oxygen integrates with GuardDuty by capturing any new findings and executing workflow. Our current workflow has been to store all findings data in our database and review for immediate action, false positives, and standard formats. After refining our process, we are now ready to turn on realtime alerting for new GuardDuty findings. Any new finding will generate a support ticket and will be reviewed by Cloudticity support to see if any action is required. Potential actions may include: adding an exception for false positives, archiving, or executing remediation. In all cases, Cloudticity support will communicate the action taken.
Realtime Alerting for Unmanaged Instances
At Cloudticity, we've built an extensive set of management automations using EC2 Systems Manager. This means that the EC2 Systems Manager agent (called the "SSM agent") is a prerequisite for Oxygen to monitor and manage EC2 instances. As with untagged resources, our policy has been to monitor for SSM installation problems and periodically remediate any issues found. This month we are enabling realtime alerting for any instances not reporting as managed in AWS Systems Manager. The alerts show up as support tickets from us, sent to the same technical contact email address used for other Oxygen alerts. The Cloudticity support team will work with you to remediate any issues found.
New Service: Automated AMI updates for AutoScaling
We have identified a use case that may cause Autoscaling Groups (ASGs) to become out of sync with the instances that are running. Once an instance is patched with the latest OS and security updates, it is no longer in sync with the AMI that is driving the ASG. If a scaling event occurs after the OS patching is complete, any new instances will be launched from the prior AMI, and will not have the latest OS patches. The same issue may present itself for CodeDeploy deployments. To resolve this issue, we developed a service that subscribes (using CloudWatch Rules) to a successful SSM OS patching event and a successful CodeDeploy deployment. Once any of the CloudWatch Rules fire, the service automatically creates a new AMI from the latest instance and updates the ASG to use the new AMI. If a scaling event occurs after the OS patching is complete (or CodeDeploy deployment is complete), the newly launched instance will have the latest OS patches and/or code since it was launched from an AMI that was built using an instance that had the most recent OS patches or application code. If you are interested in this service please reach out to Cloudticity support for more details, or to schedule installation.