GuardDuty for SMBs: alert tuning that does not drown your team
Suppress noise, keep critical signals, and connect GuardDuty to a channel someone reads.
GuardDuty enabled on a Puerto Rico SMB AWS account generates 200 alerts the first week — cryptocurrency mining on forgotten dev instance, reconnaissance from known scanner IP, root IAM anomaly. Without tuning, a two-person team ignores everything; with bad tuning, they miss real signal. The AWS Security Blog publishes finding type runbooks — use as base, not spam inbox.
Suppression rules with quarterly review
Documented suppression rules: expected findings from contracted vulnerability scanner, known CI/CD activity in dev account, mainland partners with fixed IP. Each suppression with quarterly expiry review — suppress forever is self-imposed blindness. HIGH and CRITICAL severity never suppressed without ticket.
Integration: EventBridge to SNS, Slack, or Jira — channel someone reviews on business days. For PR without 24/7 SOC, co-managed MSSP can triage GuardDuty findings extended hours. CISA recommends centralizing cloud alerts with on-prem where applicable.
Correlation: GuardDuty on one account is incomplete picture. Organizations with delegated admin centralizes findings from prod, dev, logging account. Multi-account landing zone — even lite — improves signal-to-noise separating noisy sandbox from prod.
Playbooks for each finding type
Playbooks per finding type: S3.PublicAccess → verify intentional, revert if not. CredentialExfiltration → rotate keys, review CloudTrail. Train internal IT on top 10 findings before enabling — GuardDuty without response is expensive log. San Juan SMBs compete with global threats; tuned GuardDuty is affordable radar.
Writes about practical cybersecurity for SMBs in Puerto Rico and the Caribbean — no fluff, just what actually needs to get done.
