Repository navigation
chore(monitoring): tune GuardDuty and Security Hub to verified-benign patterns - #164
Conversation
Terraform Plan🚧 Changes detected — Plan: 31 to add, 0 to change, 0 to destroy. Plan outputLLM ReviewRisk: 🟢 LOW Plan creates 31 monitoring/Security Hub/GuardDuty configuration resources in module.monitoring with no changes or destroys; it suppresses some findings and disables certain security controls, but none of the changes are dangerous on their own.
|
Terraform Plan🚧 Changes detected — Plan: 30 to add, 0 to change, 0 to destroy. Plan outputLLM ReviewRisk: 🟢 LOW Plan creates 30 Security Hub/GuardDuty monitoring resources (suppression rules, control disablements, and a GuardDuty archive filter) with no changes or destruction to existing infrastructure.
|
… patterns Archive filters for the team-provisioner Cognito sync and team SSO roles reading their own SSM params; disable inapplicable CIS/FSBP controls with reasons; suppress accepted RDS.2/RDS.46 (dbmoresleep) and ELB.18 (redirect-only listener). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The team permission set does not limit SSM reads to the team's path, and the archived finding type is what stolen SSO credentials produce. One of the two live findings came from Hungary. Leave it alerting. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
adfd4a0 to
b4ae6a3
Compare
Terraform Plan🚧 Changes detected — Plan: 30 to add, 0 to change, 0 to destroy. Plan outputLLM ReviewRisk: 🟢 LOW Plan creates 30 monitoring/Security Hub/GuardDuty configuration resources in the monitoring module (0 changes, 0 destroys); all are suppression, association, or filter resources with no network, IAM, or data-plane changes.
|
Why
Security Hub and GuardDuty keep sending findings to
javabin-securitythat the audit verified as benign or as accepted risk. They drown out the real signal:Impact:IAMUser/AnomalousBehavior(sev 8):javabin-team-provisionercallscognito-idp:UpdateGroupduring its scheduled group sync. CloudTrail confirms the caller is the Lambda.CredentialAccess:IAMUser/AnomalousBehavior(sev 5) on team SSOssm:GetParameteris deliberately NOT filtered. The team permission set isAction "*"scoped byStringEqualsIfExists aws:ResourceTag/team, so it does not limit reads to the team's path, and this is the finding a stolen SSO session produces. One of the two live findings (jzwatch) came from Hungary. A comment indetection-tuning.tfand the docs records why.aws_securityhub_accountdefaultsenable_default_standardsto true. Its 14 CloudWatch.* metric-filter controls need CloudTrail to send logs to CloudWatch Logs, which the platform does not do (cost).dbmoresleepis public on purpose (RDS.2, RDS.46). The platform ALB's port-80 listener only redirects to HTTPS (ELB.18).What
New
monitoring/detection-tuning.tf. Every entry states its reason in code.GuardDuty ARCHIVE filters
team-provisioner-cognito-sync: matches that finding type, that principal andcognito-idponly.Security Hub controls disabled, each with
updated_reasonSecurity Hub automation rules (set to SUPPRESSED with a note)
dbmoresleep. EC2.18 and EC2.19 on its security group stay open on purpose, because narrowing that group is still an open audit item.http_listener_arnis passed into monitoring for this.Docs: a new "Detection tuning" section in
docs/platform-modules.mdlists every suppression and its reason.The RDS
MaliciousIPCallerfindings on dbmoresleep are not suppressed. They are real signal.How verified
terraform fmt -recursive -checkandterraform validatepass. Pytest passes (107).list-security-control-definitionsfor both enabled standards.resource.accessKeyDetails.userName=javabin-team-provisioner, servicecognito-idp.amazonaws.com, apiUpdateGroup.Review fixes
team-sso-own-ssm-paramsfilter: its justification about the permission set was false, and it would archive the stolen-SSO-session signal regardless of source country.Follow-ups
Merge after feat(monitoring): enable account security guardrails #163 and rebase: both edit the monitoring section of
docs/platform-modules.md.GuardDuty filters only apply to new findings. After apply, archive the existing provisioner finding once in the console. Confirm the two team-SSO GetParameter findings with their users (jzwatch: Hungary, 2026-10-24 10:19 UTC) before archiving them.
Re-enable the matching controls if CloudTrail later goes to CloudWatch Logs, or if VPC endpoints or Macie are adopted.
🤖 Generated with Claude Code