Security hardening & penetration testing
Microsoft 365 & Azure Security Hardening and Penetration Testing
A structured program to check, correct and continuously verify the security configuration of a Microsoft 365, Entra ID or Azure environment, ending in a controlled attempt to get past what was fixed.
Built for organizations consolidating multiple tenants into one, onboarding a new Microsoft 365 environment, or preparing for a security review, an insurance renewal, or a recognized compliance standard.
When this usually comes up
- A tenant is about to receive one or more other tenants in a consolidation, and it needs to be checked before anything lands in it
- No structured security review of the Microsoft 365 or Azure environment has ever been run
- A cyber-insurance renewal, or a recognized compliance standard, is approaching and nobody can currently answer what it will ask
- A prior assessment — Sunrise’s own or another’s — surfaced findings that point past what a bounded review can close
Where this starts before a consolidation: Migration Readiness Assessment
The three phases
Each phase builds on the one before it. A tenant is not handed to Phase 3 until Phases 1 and 2 have actually closed.
- 1 · Measure and fix
- An outside baseline is established before anything changes. Every item the baseline raises that affects the whole organization is corrected — sign-in rules, administrator accounts, offboarding residue, third-party application access, device compliance, and email protection. Nothing is corrected before its purpose is understood; some configuration that looks wrong from outside turns out to be deliberate.Tools: ScubaGear · Monkey365 · Microsoft Secure Score
- 2 · Make it durable
- A one-time fix drifts back without something watching it. This phase installs automated, ongoing verification the client’s own team can run without this service engaged continuously, and builds the data-governance layer most tenants do not have by default — sensitivity labels, retention, and data-loss prevention extended past whatever narrow set of workloads it started on.Tools: Maester · Microsoft365DSC
- 3 · Test whether it holds
- Everything in Phases 1 and 2 is Sunrise’s own assessment. This phase is the part that is not: a controlled attempt to get into the environment and move through it the way an attacker would, from agreed starting positions, with what is found corrected and then retested. It requires its own written authorization, separate from the rest of the engagement — see below.Tools: BloodHound · AzureHound · MFASweep · ROADtools · GraphRunner
The frameworks this is built on
Not a house methodology invented for this. Every phase maps to a published, recognized standard, so the reasoning can be checked against something external rather than taken on trust.
The NIST Cybersecurity Framework structures the three phases — establish what exists, fix what is found, confirm the fix holds under test. NIST Special Publication 800-115 is the methodology behind Phase 3: define scope, gather information, analyze for weaknesses, attempt to use them, report. CISA's published security baselines for Microsoft 365 and Google Workspace are measured with ScubaGear, the free assessment tool CISA publishes for exactly this purpose. Microsoft's own Cloud Unified Penetration Testing Rules of Engagement cover Microsoft 365, Entra ID and Azure together, and Phase 3 stays inside them throughout — including the obligation to stop and report a genuine Microsoft platform vulnerability rather than continue exploiting it.
Published by NIST: Cybersecurity Framework · SP 800-115
Published by CISA: Secure Cloud Business Applications (SCuBA) project
Published by Microsoft: Cloud Unified Penetration Testing Rules of Engagement
What this is, and what it is not
It is work measured against published, external baselines and conducted under a named set of rules of engagement — checkable by anyone, not taken on trust. It is not a certification, an accreditation, an attestation, or an audit opinion, and Sunrise is not in a position to issue any of those.
A controlled, authorized penetration test tests what it was scoped to test — it does not find every vulnerability, and no engagement can honestly promise that it will. Using a published baseline or a named framework creates no relationship with the organization that published it, and this work does not guarantee an insurance outcome, a premium change, or acceptance by any insurer or regulator.
How changes are rolled out safely
The methodology that makes Phase 1 safe to run against a live, in-use environment, stated as a standing practice rather than assumed.
- A confirmed, working emergency-access account is settled before any rule that applies to everyone is touched, so a misconfiguration during rollout cannot lock out every administrator at once.
- Anything that could affect how someone signs in, or what a device can reach, goes to a small pilot group first, or runs in a mode that only records what it would have done, before it applies to everyone.
- Anything that removes something from a live account — an administrative role, ownership of a group — is done one account at a time, not as a batch.
- If work turns up something that looks like it may already have happened, rather than simply being misconfigured, that is raised and paused rather than treated as more of the same work. Investigating an actual incident is a different discipline and a separate engagement.
Why Phase 3 needs its own authorization
Who this is for
- Organizations consolidating multiple Microsoft 365, Google Workspace or Azure environments into one, who want the destination checked before anything else lands in it.
- Organizations that have never had a structured security review of their Microsoft 365 or Azure environment, and want one grounded in measured fact rather than a generic checklist.
- Organizations considering a recognized security certification at some point, who want to start from a position already close to it rather than from the beginning.
What this does not include
- Investigating whether a security event has already happened is scoped as its own engagement — incident response and forensic work run under a different process than measuring and testing a tenant. If that is the situation, say so and it gets scoped properly rather than folded into this program.
- A formal certification or an auditor’s opinion is not something this program issues — nobody can credibly assess and remediate a tenant and then also be the independent party attesting to the result. What it does produce is the groundwork and evidence an actual certification process would look for.
- No engagement can honestly guarantee a system is secure in an absolute sense. What this one does is measurably reduce the number of ways in, and leave the client with something their own team can re-check on their own schedule, for as long as they keep using it.
- Denial-of-service testing of any kind. Microsoft’s own rules prohibit it outright for Phase 3 — an uncontrolled attempt to overwhelm a live system is indistinguishable from an actual attack, and no authorization changes that. See below if this is what is actually needed.
If DDoS resilience testing is needed
That is a different question from the rest of this program, and it is handled differently. Sunrise does not run it directly — Microsoft's policy restricts DDoS simulation against Azure-hosted public IPs to its own approved testing partners, validated before testing and scoped to a subscription you already own.
Where it is needed, Sunrise coordinates access to one of Microsoft's approved partners — MazeBolt, Red Button, and RedWolf — rather than attempting it directly, sourced and quoted separately from this program.
Published by Microsoft: Azure DDoS Protection simulation testing
Questions people ask before committing
Is this the same as the Security Assessment?
No. The Microsoft 365 Security Assessment is a bounded configuration review — nothing is exploited and nothing is attacked.
This is the deeper program: the same measurement, the fixes applied, automated re-verification handed to your team, and then an authorized attempt to get past what was fixed.
Why does Phase 3 need its own authorization?
Because attempting to gain access to a live system is a different kind of work with a different kind of risk than measuring or fixing its configuration.
Phases 1 and 2 run under the engagement agreement. Phase 3 does not begin until a separate, written authorization for it has been signed.
Does the penetration test find every vulnerability?
No, and no engagement can honestly promise that.
What it tests is defined up front, under Microsoft’s Cloud Unified Penetration Testing Rules of Engagement and NIST SP 800-115 — a controlled, scoped attempt, not an exhaustive one.
Who actually does the testing?
Sunrise, internally — not a subcontracted specialist.
The same team that measures and fixes the configuration in Phases 1 and 2 runs the authorized test in Phase 3.
Know it holds, not just that it was fixed.
A policy document describes what is supposed to be true. This program measures what actually is, fixes what differs, and then tests whether the fix holds under a real attempt to get past it.