This rule identifies when an AWS RDS snapshot is created. Attackers can use this as a means to evade defenses by bypassing audit controls. For example, they could create a snapshot of a running instance and then create a new instance from that snapshot and make it publicly accessible or share it directly with another AWS account that they control. Snapshots can also be used to hide attacker behavior. An attacker could create the snapshot before accessing the instance and then revert the instance back to its previous state in order to cover their tracks. Snapshots are very common in RDS, they are sometimes created in an automated fashion for backup purposes which would make this a noisy rule. This is why I created this as a BBR rule as it should be correlated with other rules for a more accurate picture of threat behavior. I could consider creating a new_terms rule for Snapshot creation for an intance that has never had a snapshot, which would be more suspicious.
Issues
Summary
This rule identifies when an AWS RDS snapshot is created. Attackers can use this as a means to evade defenses by bypassing audit controls. For example, they could create a snapshot of a running instance and then create a new instance from that snapshot and make it publicly accessible or share it directly with another AWS account that they control. Snapshots can also be used to hide attacker behavior. An attacker could create the snapshot before accessing the instance and then revert the instance back to its previous state in order to cover their tracks. Snapshots are very common in RDS, they are sometimes created in an automated fashion for backup purposes which would make this a noisy rule. This is why I created this as a BBR rule as it should be correlated with other rules for a more accurate picture of threat behavior. I could consider creating a new_terms rule for Snapshot creation for an intance that has never had a snapshot, which would be more suspicious.