Skip to main content

Cloud isn’t “secure by default”: Quick wins to harden Microsoft 365, Google Workspace, AWS & Azure

If you’ve been moving fast with cloud tools, you’re not alone. Most Australian organisations now live in Microsoft 365, Google Workspace, AWS, and Azure—yet many assume baseline settings are “good enough.” They’re not. Small gaps (a legacy protocol left on here, an overly-broad role there) are exactly what attackers look for.

Following our recent announcement about vCISO.One’s Cloud Security Services (if you missed it, you can read the press release here:vCISO.One Announces Cloud Security Services), this post offers a practical, vendor-neutral guide you can use today – whether you DIY an internal clean-up or engage us for an independent review.

The “secure-by-default” myth (and why it persists)

Cloud platforms prioritise usability out of the box. That’s great for collaboration, but risky for security. Default or inherited settings often:

  • Leave legacy authentication methods enabled.

  • Grant more privilege than necessary to speed up provisioning.

  • Don’t enforce MFA consistently (particularly for service and break-glass accounts).

  • Allow broad external sharing and app consent without proper guardrails.

Attackers know this. Most successful cloud breaches aren’t “zero-days”- they’ve just successfully leveraged misconfigurations.

What we typically find (and fix)

Across recent reviews of our clients’ Microsoft 365, Google Workspace, AWS and Azure tenants, we see the same small-but-dangerous gaps repeating. They’re not exotic zero-days – just everyday missteps in identity, permissions, sharing and logging that compound risk.

Here’s a snapshot of some of the issues we most often uncover and the fixes we typically apply.

Microsoft 365 / Entra ID

  • Legacy authentication still enabled; no Conditional Access baselines.

  • Too many Global Admins; no Privileged Identity Management (PIM).

  • Inconsistent MFA (especially for admins and service accounts).

  • Mailbox forwarding rules and OAuth apps enabling silent data exfiltration.

  • External sharing on SharePoint/OneDrive without sensitivity labels or DLP.

Google Workspace

  • MFA not enforced org-wide; app-passwords and IMAP/POP still permitted.

  • Third-party OAuth apps with excessive scopes.

  • Over-permissive Drive sharing (Anyone with the link; external domains).

  • Super Admin used for daily tasks; lack of audit alerting.

AWS

  • Root account with access keys or no MFA; long-lived user keys.

  • Public S3 buckets or missing “Block Public Access” at the account level.

  • Security Groups open to the world (0.0.0.0/0) for RDP/SSH.

  • CloudTrail/GuardDuty not enabled across all regions; logs not centralised.

  • No KMS encryption by default for critical data stores.

Azure

  • Azure AD roles assigned permanently; PIM not in use.

  • Defender for Cloud / Defender for Identity not enabled or tuned.

  • Storage accounts allow public access; no default encryption/customer-managed keys.

  • Missing policy guardrails via Azure Policy/Blueprints; inconsistent logging.

Twelve quick wins you can action this week

Minimising the risk of a cloud breach doesn’t have to be overly complex or overwhelming.

Here are twelve high-impact, low-friction actions to harden Microsoft 365, Google Workspace, AWS and Azure fast. They prioritise identity, access, exposure and detection – the root causes behind most real-world incidents. Work through them in order; most rely on native controls you already have, and each step measurably reduces risk.

  1. Make MFA universal (including admins, service accounts via app passwords/managed identities, and break-glass with strict vaulting and monitoring).

  2. Turn off legacy auth (Basic/POP/IMAP/SMTP AUTH where possible) and block anonymous protocols.

  3. Introduce Conditional Access / context-aware access (geography, device compliance, risk).

  4. Minimise standing privilege with role-based access and PIM/Just-In-Time elevation.

  5. Harden identities for automation (managed identities/Workload Identity Federation; eliminate long-lived keys).

  6. Enforce device compliance (Intune/Endpoint Manager/MDM; minimum OS, encryption, password, and AV/EDR).

  7. Enable and centralise logging (M365 unified audit, Entra ID sign-in logs, AWS CloudTrail/CloudWatch, Azure Activity/Diagnostics) to a SIEM (e.g., Sentinel).

  8. Block public data exposure by default (S3 Block Public Access, Azure Storage “Allow blob public access: Disabled,” tight sharing policies in M365/Google).

  9. Encrypt everything at rest (KMS/CMK/Key Vault) and manage key rotation.

  10. Deploy native detections (Microsoft Secure Score/Defender, Google security dashboard, AWS GuardDuty/Inspector, Azure Defender for Cloud).

  11. Protect email domains with DMARC, SPF, DKIM and a monitored DMARC policy (p=quarantine/ reject once ready).

  12. Prepare for “when,” not “if”: IR runbooks for account takeover, ransomware in SaaS, data-leak scenarios; test a “break-glass” procedure safely.

How to self-assess in 30 minutes (a pragmatic checklist)

Answer Yes/No to each:

  • All admins, service accounts, and break-glass accounts have MFA enforced.

  • Legacy auth is disabled tenant-wide (exceptions documented and time-boxed).

  • Privileged roles use PIM/JIT, not permanent assignment.

  • We have a current inventory of third-party OAuth apps and service principals.

  • External sharing is restricted, labelled, and logged (M365/Google).

  • S3/Blob public access is blocked by default and exceptions are monitored.

  • CloudTrail/Activity Logs are enabled in all regions, immutable, and centralised.

  • GuardDuty/Defender/Workspace alerts are on, with someone accountable to respond.

  • Backups for SaaS (mail, files, SharePoint/Drive) exist and have been tested.

  • DMARC is implemented with an enforced policy and a monitored aggregate report.

If you answered “No” to three or more, you’ve got meaningful, fixable risk.

What “good” looks like

What most people fail to understand is that mature cloud security isn’t a product – it’s a posture:

  • Benchmarks & scoring: Track against CIS Benchmarks, Microsoft Secure Score, and AWS Well-Architected/Azure Advisor, then close the top-impact gaps first.

  • Risk-based roadmap: Prioritise by blast radius and likelihood; fold actions into quarterly plans.

  • Control alignment: Map improvements to the Essential Eight, ISO 27001, and the Australian ISM so your audit and assurance story is clear.

  • Evidence on hand: Screenshots, config exports, policy docs, and alert runbooks ready for insurers, auditors, and boards.

Why this matters to insurance and compliance

Cyber insurers and auditors increasingly expect: enforced MFA, email authentication (DMARC), secure backups, EDR/AV on endpoints, and logging with proof of alert response. Tightening cloud controls pays off twice: lower incident risk and faster renewals/audits with fewer conditions.

DIY vs guided: choose what fits

You can absolutely make strong progress internally with a structured plan and good housekeeping. Where we help is speed and clarity:

  • Independent configuration review across Microsoft 365, Google Workspace, AWS, and Azure.

  • A prioritised remediation roadmap tuned to your environment and risk appetite.

  • Policy development (access control, cloud usage, device management, data handling) and optional implementation support.

  • Ongoing monitoring options once the fundamentals are in place.

This blog is intended as a companion to our recent announcement – not a hard sell. If you just need a second set of eyes to validate your setup, that’s fine too.

Ready for a pragmatic sanity-check?

If you’d like an expert to pressure-test your current posture and give you a clear, prioritised action list, you can book a Cloud Security Review here: https://vciso.one/contact

You focus on collaboration; we’ll make sure the configuration keeps up.

Leave a Reply

Share