A baseline is the minimum you can see and defend
Without a baseline, a compromised account may run for weeks before anyone notices. Typical signs appear in the bill first: a burst of instances in an unfamiliar region, or unusual data transfer. By then, the attacker has been through the account. A baseline gives you eyes: audit logs that cannot be edited, threat detection watching those logs, configuration rules noticing risky changes, and one dashboard that gathers everything.
It sits alongside the preventive controls we cover in Organizations and SCP guardrails, and it is part of our wider cloud setup service. For continuous monitoring and response afterwards, see SRE and incident response.
What each service is for
CloudTrail records API activity. An organisation trail covers all accounts, writes to the log archive, and has log file validation enabled. Without it, nothing else matters.
AWS Config records configuration changes to resources and evaluates them against rules, for example “no security group allows 0.0.0.0/0 on port 22”. It answers “what did this look like last Tuesday?”
GuardDuty analyses activity for threats using AWS’s managed detection logic. Typical findings include use of credentials from an unexpected network, calls from known malicious addresses, DNS requests to suspicious domains, and unusual behaviour in S3 or EKS where those protections are enabled.
Security Hub collects findings from GuardDuty, Config, Inspector, Access Analyzer and others. It also evaluates controls from standards, giving a posture view you can track over time.
IAM Access Analyzer finds resources shared outside the organisation and unused access, which is a cheap, high-value addition.
What good looks like
- Every account, including new ones, has the services enabled automatically.
- Findings aggregate in a security account, in one home region with cross-region aggregation.
- Standards are chosen deliberately, with each disabled control justified.
- High-severity findings reach a person within minutes.
- Accepted findings are suppressed with a recorded reason and review date.
- The configuration is code.
How it works in practice
Delegating administration
From the management account, you register the security account as delegated administrator for each service, then enable auto-enrolment for new accounts. This keeps routine security work out of the management account. In Terraform:
resource "aws_guardduty_organization_admin_account" "this" {
admin_account_id = var.security_account_id
}
resource "aws_securityhub_organization_admin_account" "this" {
admin_account_id = var.security_account_id
}
Then, from the security account, you create a detector, configure organisation auto-enable, and enable the standards. The detail differs slightly between provider versions, so we test the exact sequence in a scratch organisation.
Choosing standards
The AWS Foundational Security Best Practices standard is a good default. CIS AWS Foundations adds a widely recognised checklist that auditors understand. Enabling every standard produces duplicate findings for the same issue, so we select the ones you need and disable controls that do not apply, for example controls about services you do not use.
Tuning
This is where baselines succeed or fail. A freshly enabled Security Hub on a console-built estate can show hundreds of failed controls. We triage them into three groups: fix now (public buckets, missing MFA), fix in a planned sprint (encryption defaults, logging gaps), and accept with reason (a deliberately public website bucket). Suppression rules automate the third group so the dashboard shows what still needs work. Findings also feed the ClickOps inventory, since many failures point to resources that were created by hand.
Routing alerts
Findings are emitted through EventBridge. A rule matching high and critical severity sends to SNS, which can reach chat, email or an on-call tool:
{
"source": ["aws.securityhub"],
"detail-type": ["Security Hub Findings - Imported"],
"detail": {
"findings": {
"Severity": { "Label": ["HIGH", "CRITICAL"] },
"Workflow": { "Status": ["NEW"] },
"RecordState": ["ACTIVE"]
}
}
}
We then run a test: generate a sample GuardDuty finding and watch it travel to a human. An alert path that was never exercised is not a control.
Azure
On Azure, Microsoft Defender for Cloud provides a secure score and recommendations against the Microsoft cloud security benchmark, with plans for servers, storage, databases and containers. Findings are exported to Sentinel or a ticketing system if you use them. We enable plans selectively, since each is priced per resource type, and manage policy assignments through management groups.
Decisions and trade-offs
Everything on, or selective? Protection plans such as S3, EKS audit logs, runtime monitoring and malware scanning add cost with usage. Enable those that match your workloads rather than all of them by default.
Who responds? A small team may route to a shared channel during working hours and page only on critical findings. Round-the-clock response needs on-call, which our Managed DevOps service can provide if you want it.
Third-party tools. Commercial CSPM and SIEM products add depth and cost. For most startups the native services are enough at first.
When not to expand. If you cannot act on the findings you already have, more tooling makes things worse. Fix the backlog first.
Common failure modes
- Enabled but unread. Findings accumulate in a console nobody opens.
- Single-region blind spots. Attackers like regions you do not watch, which regional deny guardrails help close.
- Alert fatigue. Hundreds of low-severity notifications train people to ignore all of them.
- Management account excluded. It is the highest-value target, and it needs coverage too.
- Costs unseen. Log-heavy services can grow, so we put them under the budgets described in billing alerts.
Delivery and handover
We deliver Terraform for the whole baseline, a findings triage document, the suppression rules with reasons, and a short response guide that says who looks at what and when. Your team joins a walkthrough where we trigger sample findings together. We also record the compliance coverage so that audits start from evidence rather than screenshots.
How to tell it is working
- Every account reports to the security account, and new accounts appear automatically.
- The open high-severity finding count trends down and stays low.
- A sample finding reaches the right person within minutes.
- You can answer “who did this and when?” from logs that nobody can alter.
To have a baseline built or reviewed, contact us.