ANOMAL service

Cloud and identity hardening: closing the most common misconfigurations

ANOMAL reviews Microsoft 365, Entra ID, Azure and AWS against CIS benchmarks and vendor baselines, focusing on identity. The review covers Conditional Access, MFA, privileged access, session and token controls, and legacy auth. Findings become a prioritised remediation plan we implement together with your IT. The hardened baseline then becomes the detection baseline for the SOC, so deviations turn into alerts.

All

Why default configurations are not enough

Most successful attacks on cloud and M365 environments exploit misconfigurations rather than zero-days. These include missing MFA enforcement, overly broad admin roles, unrestricted legacy protocols and unreviewed app consent. Cloud and identity hardening is a project service that systematically finds and closes these gaps. It addresses them before they lead to a business email compromise or token theft.

Configuration review against CIS benchmarks

  • Microsoft 365 and Entra ID: tenant settings, security defaults, administrative roles, guest access.
  • Azure: resource, network and identity configuration against the CIS benchmark and vendor guidance.
  • AWS: IAM policies, root account protection, logging and network boundaries against the CIS benchmark.
  • Comparison against vendor baselines where they go beyond CIS.

Identity-first: the actual core of hardening

  • Conditional Access design and testing: policies that combine device state, location and risk. Individual isolated rules are insufficient.
  • MFA enforcement with phishing-resistant methods. SMS or push confirmation alone is insufficient.
  • Privileged access and just-in-time roles without permanently active admin rights, aligned with common PAM principles.
  • Session and token controls: lifetime, device/network binding, revocation on risk signals.
  • Disabling legacy auth protocols and reviewing app consent grants.

These measures directly address the two most common threat models in M365 and cloud environments. These are token theft and session hijacking and business email compromise.

Prioritised remediation plan with your IT

The review results in a plan prioritised by risk and implementation effort. ANOMAL implements the plan together with your IT, provides technical guidance and verifies the effect of each change. We can optionally address governance questions around roles and responsibilities through brief accompanying guidance.

From baseline to detection in the SOC

ANOMAL documents the hardened configuration and hands it over as a reference to SOC as a Service Switzerland. Deviations from this baseline trigger alerts. Examples include a newly enabled legacy auth method or an unexpectedly expanded admin role. For M365 environments, SOC Microsoft 365 Sentinel provides this detection; ITDR covers identity attacks more broadly.

How this compares to neighbouring topics

OfferingFocusOutcome
Cloud and identity hardeningConcrete configuration in M365, Entra ID, Azure, AWS against CIS benchmarks.Implemented, verified hardening plus a SOC detection baseline.
Zero Trust and NIST consultingArchitecture and roadmap over multiple years.Strategic target architecture, not individual configuration changes.
Vulnerability ManagementKnown CVEs in systems and software.Ongoing patch and remediation cycle, see Vulnerability Management Switzerland.
Managed ITDR / SOC detectionOngoing operations: real-time detection of identity attacks.24/7 alerting based on the hardened baseline, see ITDR.

Frequently asked questions

Is this a one-off project or an ongoing service?

Cloud and identity hardening is a project: review, prioritised plan, joint implementation. Ongoing protection afterwards runs through [SOC as a Service Switzerland](/en/soc/soc-as-a-service-switzerland), which detects deviations from the hardened baseline.

Which environments are covered?

We cover Microsoft 365, Entra ID, Azure and AWS. We define the scope and depth for each environment during scoping.

How does this differ from Zero Trust consulting?

Hardening delivers concrete, implemented configuration changes. Zero Trust and NIST consulting develops the overarching architecture and roadmap picture into which these changes fit.

Does ANOMAL implement the changes itself?

ANOMAL implements the changes together with your IT. ANOMAL prioritises, provides technical guidance and verifies the effect of each change.

What does cloud and identity hardening cost?

The effort depends on the number of environments and their current state. We provide an individual quote for each customer. General SOC cost context is on [SOC cost Switzerland](/en/soc/soc-cost-switzerland).

Continue reading in this cluster
ITDR: Identity Threat Detection and Response for Switzerland
ITDR (Identity Threat Detection and Response) detects attacks on the identity itself, not just endpoints or networks. Targets are accounts, tokens, sessions, permissions and identity providers such as Entra ID or Okta. ITDR extends EDR and SIEM with signals only visible in the identity layer. These include impossible travel, consent phishing, refresh-token abuse, role abuse and attacks on federation and directory objects. For Swiss organisations running M365, Entra ID and regulated processes, ITDR today is as important as EDR was five years ago.
Detecting and stopping token theft and session hijacking
Token theft means attackers steal the session or refresh token of an already authenticated user and use it to bypass MFA. The classic path is reverse-proxy phishing (adversary-in-the-middle), increasingly also endpoint info-stealers. A SOC detects this from token usage outside the user context, not from the login itself. Defence means phishing-resistant MFA, Continuous Access Evaluation, token binding and detection on refresh-token replay.
Detecting and stopping Business Email Compromise in Microsoft 365
Business Email Compromise (BEC) in Microsoft 365 rarely involves malware. The attack chain involves phishing, session or token theft, inbox rules and OAuth consent abuse. A SOC detects BEC by correlating signals from Entra ID, Exchange Online and Defender for Cloud Apps. The email body alone is insufficient for detection. Responders revoke sessions, remove inbox rules, withdraw OAuth consents and enforce MFA again. They document these actions in line with ISG and insurance requirements.
Zero Trust and SOC: from principle to effective detection
Zero Trust is an architecture principle, not a product category. No network, device or account is trusted implicitly, and every request is continuously authenticated and authorised. For the principle to work you need a SOC that correlates identity, device and network signals and detects violations of the defined policies. Without detection Zero Trust stays a diagram; without a Zero Trust foundation the SOC runs in circles. Frame and operating model in detail on [SOC as a Service Switzerland](/en/soc/soc-as-a-service-switzerland).