Background
A Sydney-based managed IT services provider (MSP) serving 80+ SME clients across New South Wales engaged CyberneticsPlus for an AWS security assessment. The driver was their ISO 27001 certification project — their certifying body had recommended a cloud security assessment as part of the Annex A.8 technical controls evidence.
The MSP managed client data in AWS across 3 AWS accounts:
- Production: hosting client backups, monitoring data, and managed service tooling
- Staging: replica of production for testing
- Shared services: central logging, billing, and identity management
All three accounts were in scope for the assessment.
Assessment Scope and Approach
Assessment type: White-box (full access to IAM credentials with read permissions across all accounts)
Coverage:
- IAM configuration (users, roles, policies, trust relationships)
- S3 buckets (all 34 buckets across 3 accounts)
- EC2 instances and security groups
- RDS databases
- VPC networking (subnets, NACLs, security groups)
- CloudTrail and logging configuration
- GuardDuty and Security Hub status
Tools used: Prowler, ScoutSuite, custom IAM analysis scripts, manual review
Critical Findings
Critical 1: Public S3 Bucket with Client Backup Data
Finding: The S3 bucket mspcorp-client-backups-prod was publicly readable. The bucket contained encrypted VM backups for 14 client organisations, including backup metadata files that revealed client company names, server names, IP addresses, and backup schedules — in plaintext.
The bucket had been created 18 months earlier with a public ACL set for a brief period (the administrator believed they had removed it). While the ACL was removed, a bucket policy added by a third-party backup tool had granted s3:GetObject to "Principal": "*".
Data exposed:
- 847 GB of encrypted backup files
- 14 unencrypted metadata files containing client infrastructure details
- Directory listings revealing client organisation names and server counts
Risk: The encrypted backup files required client-specific decryption keys (not exposed). However, the metadata files containing client names and infrastructure details represented a significant confidentiality breach — this information could be used for targeted attacks against the MSP’s clients.
Immediate action: Bucket policy updated within 4 hours of finding notification. Block public access enabled at account level. Metadata files reviewed — no decryption keys or credentials present.
Notification: MSP’s legal team assessed the need for client notification under Australian Privacy Act (APPs). Determined that encrypted backup files with no exposed credentials did not meet the threshold for mandatory notification. Metadata exposure documented and incident report filed.
Critical 2: IAM User with AdministratorAccess and Exposed Access Keys
Finding: An IAM user terraform-deploy had AdministratorAccess managed policy attached. The access keys for this user were active and had last been used 6 months earlier. Investigation showed the keys had been committed to a private GitHub repository (now rotated after our notification, but git history retained them).
Risk: The keys, if discovered by a threat actor via repository scanning (a common automated attack), would provide full administrative access to all three AWS accounts — including access to client backup data.
Remediation:
- Access keys immediately deactivated
- IAM role with scoped permissions created for Terraform (using OIDC federation with GitHub Actions)
AdministratorAccessremoved from all non-human IAM users- GitHub repository history scrubbed using git-filter-repo
Critical 3: GuardDuty Disabled in 2 of 3 Accounts
Finding: GuardDuty was enabled only in the production account. The staging and shared-services accounts had GuardDuty disabled. The shared-services account contained the central IAM and billing infrastructure — its compromise would affect all accounts.
Risk: No threat detection capability in two of three accounts. The shared-services account, which held the most sensitive access (cross-account roles, billing), was completely unmonitored.
Remediation: GuardDuty enabled in all three accounts. AWS Organizations-based delegated administrator configured so findings aggregated to a central security account.
High Findings (12 Identified)
- CloudTrail not enabled in 4 regions across the staging and shared-services accounts
- 6 security groups with port 22 open to 0.0.0.0/0
- 3 RDS instances not encrypted at rest
- IMDSv2 not enforced on EC2 instances (IMDSv1 allowed)
- No MFA enforcement on IAM users (8 IAM users without MFA)
- Access keys older than 180 days not rotated (12 keys identified)
- VPC Flow Logs not enabled on any VPC in staging or shared-services accounts
Medium Findings (16 Identified)
- Missing resource tags (cost allocation and ownership)
- S3 versioning not enabled on backup buckets (prevents ransomware deletion)
- CloudWatch alarms not configured for security-relevant events
- Unused IAM roles (14 roles with no activity in 90+ days)
- No SCP (Service Control Policy) preventing security service deletion
- IAM password policy not meeting minimum requirements (no complexity, no rotation)
Remediation and Certification Outcome
CyberneticsPlus worked alongside the client’s DevOps team over 6 weeks to remediate findings:
Week 1–2: Critical findings resolved Week 3–4: High findings resolved Week 5–6: Medium findings resolved, security controls documentation prepared for ISO 27001 audit
ISO 27001 audit outcome: The certification audit (conducted by a BSI-accredited body) covered the cloud security controls in Annex A.8. The auditors reviewed:
- CyberneticsPlus penetration test report
- Remediation evidence (screenshots, configuration exports)
- Updated cloud security policies and procedures
Result: ISO 27001:2022 certification granted — the cloud security work was cited as evidence of effective technical control implementation.
The MSP has since established quarterly cloud security reviews as part of their ISMS (Information Security Management System) surveillance process, with CyberneticsPlus conducting annual assessments.