AI agents investigate every alert, add context, and prepare cases for response, on a full-stack SecOps platform that captures and correlates all your security data.
Cloud-based SIEM platform providing visibility across all your data sources
Every alert investigated, with a verdict and the evidence behind it
Manage your external footprint, publicly available data, and Dark Web leaks
Log management and threat detection across any of your log sources
Get ultimate assurance that your environment is free from threat actors
Fully featured distrubuted NDR for on-premises and public cloud environments
A SecOps platform purpose-built for industrial and OT environments
Integrated endpoint agent providing deep visibility, response and forensics
Deploy honeypots and honeytokens and stay ahead of threat actors
24x7 security operations from our Australian SOC. AI investigates every alert, and experienced analysts validate findings and contain threats around the clock.
24x7 managed detection and response across endpoint, network, cloud, identity, and log sources
AI investigations and 24x7 MDR on the Microsoft Sentinel you already own
Eyes-on-glass SOC and continuous threat hunting
Expert hunters and AI agents find attacker activity your alerts missed
Quickly recover from cyber attacks and breaches
ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24x7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Monitoring, evidence and a 24x7 SOC in one platform
Compliance monitoring, evidence and board reporting
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
Articles on security operations, AI and compliance
Events, awards and company news
Read what our customers say about us
Solution briefs and datasheets
How we keep your data secure
Technical support and knowledge base
Guides, case studies, and advisories in one place
How AI agents investigate alerts and run security operations
Free ebook: a practical guide to adopting an AI SOC platform
A practical guide to incident response and digital forensics
Where SOAR playbooks fit and where AI agents take over
Free ebook: modern security operations with Microsoft Sentinel
How the framework is structured and what changes from the Essential Eight
November 10, 2026
November 6, 2026
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Embed security operations, threat intelligence and exposure data in your product
Sovereign SOC for Australian MSPs and MSSPs, with onshore analysts and client data
Set the rules for closing alerts automatically, with evidence checks and review
How MSPs deliver branded security monitoring with a SOC partner
ThreatDefence was an official partner of the Cyber Resilience Summit NSW, 29 October 2026 at Hilton Sydney.
Our team was back at BSides Canberra, and our cyber quiz was a hit again.
Two days in Perth with our partner Ever Nimble, on security operations and cyber resilience.
Sponsors of the AUSCERT Cyber Security Conference on the Gold Coast.
Sponsors of the Gartner Security & Risk Management Summit in March.
Sponsors of the Cyber Security for Critical Assets Summit in Perth, February 2026.
Expert conversations with speakers and attendees at CyberCon Melbourne 2025.
The Identity services domain in ASD Essentials covers the enterprise-wide directories, identity providers, authentication services and credential stores that other systems rely on to confirm identity and grant access.
A compromise there could affect access across the organisation, well beyond any single application.
ASD defines the domain as Enterprise-wide identity, credential and access management services such as directories, authentication and authorisation services or credential stores.
Enterprise-wide identity, credential and access management services such as directories, authentication and authorisation services or credential stores.
In the enterprise IT chapter, Identity services sits in priority phase 1 alongside Boundary services. ASD warns that compromise can enable an adversary to gain persistent or privileged access across the enterprise. The protective work is phishing-resistant multi-factor authentication (MFA), credential protection, least privilege and secure administration.
can enable an adversary to gain persistent or privileged access across the enterprise.
Identity threat detection and response (ITDR) adds the detection side: monitoring and investigating suspicious sign-ins, credential misuse and changes to identity infrastructure. ASD Essentials does not ask for a product called ITDR, but several of its principles support detecting and investigating identity compromise.
Reach defines the Identity services domain. A system that others across the enterprise depend on to authenticate users or hold credentials is in scope, whatever the technology or product name.
ASD’s enterprise IT asset scoping guidance, published October 15, 2026, gives these examples:
Microsoft Active Directory Domain Services, Microsoft Entra ID and other platforms that manage enterprise identities and authentication.
Systems that set up authentication trust between identity providers and applications across security boundaries.
Infrastructure that issues and manages certificates used to authenticate systems or users.
Enterprise password managers and secrets vaults holding credentials used across multiple systems.
Human resources systems supporting joiner, mover and leaver processes, where those functions determine account provisioning and access.
An application with its own user database does not automatically qualify. Some platforms belong to more than one domain. A privileged access management platform may also fall within Privileged environments, and a credential vault holding passwords for critical systems within Critical processes and services.
For each identity system, the scoping record lists its function, the services that depend on it and the access an attacker could gain by compromising it. A domain controller, a federation server and a certificate authority may support the same authentication environment and still expose different attack paths: stored credentials in the first, token signing in the second and certificate issuance in the third.
Phishing-resistant MFA applies in every technical domain of ASD Essentials for enterprise IT. It is not limited to internet-facing applications, privileged accounts and remote access gateways.
Action IT.PRO-13.4 reads: Use phishing-resistant MFA for users authenticating to systems, including from untrusted, external or high-risk locations.
Use phishing-resistant MFA for users authenticating to systems, including from untrusted, external or high-risk locations.
A method is phishing-resistant when a fraudulent sign-in cannot capture authentication material and reuse it. A second code or an approved notification does not, by itself, give that protection. In a typical relay attack, a copy of the sign-in page passes the user’s password and one-time code straight to the real service, and the attacker holds the session that comes back.
SMS, voice and push-only MFA appear among ASD’s not effective indicators for phishing-resistant authentication. That makes an MFA deployment report easy to misread. Enrolment can be broad while people still sign in through methods open to phishing or approval manipulation. Check which methods are permitted and which were actually used.
Common gaps in enforcement include:
Users or groups left out of authentication policies with no continuing justification.
Older or separately configured services that do not enforce the intended method.
Accounts allowed to fall back to SMS, voice or push-only authentication.
Protocols that can authenticate without the required MFA controls.
Accounts that need special arrangements but stay restricted, protected and monitored.
Comparing the policy configuration with successful sign-in records brings weaker access through a secondary portal or method to light. A typical find is a group excluded from the policy during a migration and never added back.
ASD’s fully effective indicators expect phishing-resistant MFA to be enforced for all routine interactive authentication to systems in scope, and customer-facing services to offer a phishing-resistant MFA option. The action prescribes no technology. Security keys, passkeys and smart cards are common choices.
Emergency access stays restricted to its purpose, protected, periodically tested and reviewed, with credentials kept separate from routine administration. A break-glass account usually sits outside the normal sign-in policy, so its record is what tells an emergency from misuse: a sign-in that matches neither a dated test nor an incident gets investigated.
A registration report alone cannot show enforcement. An enrolled user may still authenticate through an excluded application, a weaker method or an alternative protocol, and only the sign-in events record which method was used.
ASD action IT.PRO-13.5 is to Disable legacy authentication protocols or, where this is not feasible, restrict and monitor their use, apply compensating controls and establish a time-bound decommissioning plan.
Disable legacy authentication protocols or, where this is not feasible, restrict and monitor their use, apply compensating controls and establish a time-bound decommissioning plan.
Disabling legacy authentication at the primary identity provider helps, but other systems may still accept older methods. Start with an inventory: which protocols are still enabled, which accounts use them and whether a supported alternative exists.
A typical holdout is a scanner that sends mail with a stored password over a protocol that cannot prompt for MFA. Whoever obtains that password signs in without meeting the MFA policy.
For each exception that stays, record:
The application or service that still depends on the protocol.
The accounts, systems and access paths permitted to use it.
Controls limiting where and how authentication can occur.
Events and alerts that identify unauthorised or unexpected use.
Additional protections applied until removal.
The responsible owner, planned replacement and time-bound removal date.
Authentication logs then show whether each exception is still used and whether its use stays within the recorded scope. An exception with no remaining sign-ins can be closed.
Credential uniqueness is a related action. ASD asks for credentials that are unique per system or account, particularly in high-privilege contexts. Where machines share one local administrator password, an attacker who recovers it from a single workstation can sign in to the others. Local administrator passwords shared across machines appear among ASD’s not effective indicators, and managed identities are preferred over shared static credentials where feasible.
unique per system or account, particularly in high-privilege contexts.
A useful credential inventory separates:
Individual identities and the systems they can access.
Credentials supporting system authentication and automated operations.
Application, integration and scheduled workload accounts with identifiable owners.
Administrative credentials and the systems or functions for which they are authorised.
Passwords, keys and tokens held in approved repositories under appropriate access restrictions.
Each identity needs a defined purpose, an owner and access limited to that purpose.
ASD expects organisations to identify and disable or remove default and unused accounts regularly, and to keep an exception only where it is justified, protected and monitored. An inactive account may be a recovery identity, a service account nobody uses any more or an overlooked access path, so find out its purpose before disabling it.
An access review covers employees, administrators and non-person identities, compares permissions with current responsibilities and removes excess access within defined timeframes. An exported account list and a review approval show that someone looked. The permission changes that followed show that excess access was removed.
Authentication keys, secrets and tokens belong in approved secure repositories with access controls, including MFA, and with repository access logged and reviewed. Credentials also get copied outside approved storage during deployment or troubleshooting, such as a key pasted into a script and left there, so check configuration files, scripts and collaboration platforms too.
Administrative account changes, privileged access workflows and controls for systems that broker elevated access are covered in the ASD Essentials Privileged environments guide.
Existing Essential Eight controls are a starting point. ASD’s transition guidance maps them to this domain as follows:
ASD does not define these maturity labels for ASD Essentials. They point to where a gap analysis can start and carry no effectiveness rating. Reused evidence counts only where it covers the identity systems and actions actually being assessed. A patching report for domain controllers says nothing about a federation server or certificate authority, and a privileged account review that left out service accounts and other non-person identities gives only partial coverage.
ASD notes: Logging of successful and unsuccessful authentication events can also contribute evidence for Centralised event logging and the detection of identity and credential misuse.
Logging of successful and unsuccessful authentication events can also contribute evidence for Centralised event logging and the detection of identity and credential misuse.
Moving from the Essential Eight to ASD Essentials explains the transition pathway and wider evidence reuse.
ASD Essentials prescribes no ITDR technology. The capability draws on several of its principles:
The principle includes the objective to support effective detection of identity and credential misuse.
to support effective detection of identity and credential misuse.
Baselines cover identity and credential access activities, privileged access activities, and remote access activities to enable the detection of anomalous or unexpected behaviour.
identity and credential access activities, privileged access activities, and remote access activities
to enable the detection of anomalous or unexpected behaviour.
Detection logic is expected to identify unauthorised changes, anomalous authentication activity and suspicious software execution.
unauthorised changes, anomalous authentication activity and suspicious software execution.
Incident identification uses indicators from across identities, applications, data and infrastructure activity rather than isolated signals.
from across identities, applications, data and infrastructure activity rather than isolated signals.
High-value security events and configuration changes, including authentication activity, are forwarded to protected central storage.
Dedicated ITDR technology, the identity provider’s native detections or a wider monitoring platform may each provide these capabilities. What counts is that suspicious identity activity can be detected and investigated.
ASD associates the ATT&CK technique Valid Accounts with most identity, credential and access management actions. Misuse is hard to recognise because it uses legitimate credentials and normal access mechanisms. A successful authentication therefore provides limited assurance that subsequent activity is authorised.
An attacker holding a privileged identity can assign roles, register credentials or read information through the same interfaces administrators use. Session theft opens a second route. After sign-in, the service issues a token that stands in for the completed authentication, and whoever presents it is treated as the user. The Essential Eight maturity model already recognised that capable adversaries could bypass stronger MFA by stealing authentication tokens.
An identity investigation looks at the whole session:
Which identity authenticated, and what permissions does it hold?
Was the device previously associated with that identity?
Does the source match established access patterns?
Which method or existing session was used?
Which account changes, administrative actions or resource accesses followed authentication?
Token replay shows why. If an attacker reuses the token from a legitimate phishing-resistant sign-in, the original authentication event looks clean, and the signs are in the new session’s location and device context or in later account changes. For example, a security key sign-in from the user’s usual laptop is followed by the same session on an unfamiliar device and network with no fresh sign-in, then by a new MFA method. The investigator’s question is whether the activity fits the identity’s legitimate purpose.
ASD’s transition guide lists credential exposure among the requirements with no direct Essential Eight equivalent. The secrets scanning action belongs to Visibility and response and addresses unsecured keys and credentials in codebases, configuration files, file shares and collaboration platforms. Exposure also shows up outside the organisation: corporate credentials in dark web records, exposed passwords, infostealer records and references to corporate sign-in portals.
A leaked password is a potential risk. An unfamiliar sign-in, a new authentication method or an unexpected privileged action after the leak is evidence of misuse. From that point, investigation and containment follow the organisation’s authorised incident response procedures.
An identity baseline records what normal access looks like for an account, so a departure stands out. DET-04 covers baselining of high-risk access activities at the principle level. Its enterprise IT action deals specifically with software execution, so identity baselines follow the wider principle and are not the wording of that action. A useful identity baseline includes:
Usual countries, networks, VPN connections, proxy ranges and egress addresses.
Expected devices, client applications, authentication methods and protocols.
Normal working patterns, approved access windows and scheduled job activity.
Applications, sensitive data and administrative functions normally accessed.
Expected administrators and procedures for account creation, credential resets and role assignments.
The baseline follows the identity’s purpose. A service account that authenticates from one server on a predictable schedule has a narrow expected pattern, while an employee who travels regularly may legitimately use different countries, devices and networks. A privileged role assignment during an approved maintenance window has an explanation, and the same assignment by an unfamiliar account outside the window still needs one.
Update baselines when legitimate patterns change. A stale baseline fails both ways: new business activity produces repeated alerts, and older unauthorised behaviour comes to be treated as normal.
ASD prescribes no detection list. These signals are general practice examples, shown with the principle or action each supports.
documented, justified, hardened and monitored.
Each event can have an innocent reading: an unfamiliar country may be travel, and a new MFA registration may follow a device replacement. A sequence is stronger evidence. Repeated failures, then a successful sign-in from an unfamiliar source, then a new MFA method point together to possible account takeover.
Test detection rules against representative activity, including legitimate administration and agreed security tests. A suspicious consent grant rule cannot fire if the application events are never collected, and a session replay detection has limited value when device or session information is missing.
Monitor the event sources behind each rule as well, so that a logging failure, an expired collection permission or a missing identity infrastructure record shows up as a gap. Each investigation keeps the original events, account identifiers, timestamps and the reason the activity was flagged.
An unusual sign-in followed by mailbox changes, new application permissions or suspicious endpoint activity may provide evidence for incident identification under DET-03. In general practice, a password reset alone may leave an already stolen session token valid, so session revocation or additional containment may be necessary, depending on the platform and the evidence.
ASD Essentials SOC, MDR and Incident Response explains investigation, escalation and containment responsibilities.
Service accounts, workload identities and application credentials reach systems with no human signing in. They often hold significant privileges, have no interactive MFA and get less review than employee accounts.
ASD’s assessment process guide and its least privilege action both include non-person identities. The action asks organisations to provision user, administrative and non-person accounts with only the minimum access and privileges required to perform defined operational functions.
user, administrative and non-person accounts with only the minimum access and privileges required to perform defined operational functions.
Monitoring follows the account’s operational purpose. Useful signals include:
A service account signs in interactively or authenticates from an unexpected host.
New application secrets or certificates appear outside an approved deployment.
An integration receives additional API permissions or privileged role assignments.
An identity reaches systems or data outside its intended operational purpose.
An identity inventory ties each account to its owner, intended workload, credential type and authorised systems. Without one, an analyst looking at a service account on an unexpected host has nobody to ask whether the host is new or the sign-in is hostile.
ASD’s AI guidance, within its cloud considerations, extends identity controls to AI agents and automation. Each AI agent should use an owned non-person identity restricted to its intended context. Automation with access to SaaS administration or cloud control planes is managed as privileged access, with its actions recorded. An unexplained permission expansion still needs investigation.
The collection methods are common practice rather than ASD requirements. Microsoft Entra ID is the example identity provider.
ASD’s assessment process guide uses Identity services as a worked example. For vulnerability management on identity infrastructure, it states: Evidence may include vulnerability reports, patch compliance data, change records and configuration management records, and explains that the action cannot be rated fully effective while federation servers or certificate authorities are routinely delayed, even when most domain controllers are patched on time.
Evidence may include vulnerability reports, patch compliance data, change records and configuration management records,
Read the policy export and the sign-in records together, because a correctly configured policy may still contain exclusions or miss an alternative path. A complete evidence set shows scope, configuration and operation, along with exceptions and their reasons, corrected weaknesses with dates and systems that lack evidence.
Dated, system-generated records across the assessment period are stronger than one day’s export, a policy statement or a screenshot. A separate directory, federation service or application in scope needs evidence of its own.
Identity log collection, detection rules and triage performance are assessed under Visibility and response. The ASD Essentials Visibility and response guide covers the associated evidence.
An exclusion can keep a weaker access path open long after the stronger control is in place. Priority checks include:
Retire SMS, voice and push-only methods where phishing-resistant MFA is expected for routine sign-ins.
Remove policy exclusions that no longer have a valid operational justification.
Restrict and monitor any authentication protocol that stays, with compensating controls and a time-bound removal plan.
Assign an owner and limit credentials and permissions to the intended integration.
Confirm the accounts remain protected, are periodically tested and generate alerts when used.
Include identity infrastructure in restoration exercises and keep evidence of the results.
Each exception needs an owner, a justification, restrictions and a review process. Approvals are compared with actual activity, because an exclusion granted for one application does not justify weaker authentication elsewhere. Testing confirms that emergency accounts still work and have stayed out of ordinary administration. Monitoring continues for as long as an exception exists, since approval covers the use that was described and later use may be something else.
The enterprise IT actions do not carry over unchanged. Each system is assessed against the chapter that applies to it.
The OT chapter places Identity services in priority phase 2 alongside Privileged environments. Its identity actions emphasise phishing-resistant MFA for access across the OT perimeter, changing default and supplier credentials before commissioning and confirming that emergency access accounts function during isolation.
Remote access session records showing the user, timestamp and target are compared with expected patterns. As a general practice recommendation, use of a break-glass account outside an approved exercise should trigger investigation. Containment decisions take account of the systems and processes that depend on the affected identity, because disabling an account can stop whatever relies on it.
ASD Essentials for OT covers the chapter-specific requirements.
The cloud chapter adds an action for non-person identities and separates the capabilities a cloud provider supplies from those the customer configures and operates. Its MFA action is marked as Supplied. The provider supplies the capability, and the customer stays responsible for enabling, configuring, operating and monitoring it.
The cloud detection action includes anomalous control-plane activity, including consent grants, federation changes and privilege elevations, while the baseline action addresses anomalous use of legitimate identities, services and software.
anomalous control-plane activity, including consent grants, federation changes and privilege elevations,
anomalous use of legitimate identities, services and software.
Cloud providers may perform some detection natively, particularly for SaaS, so work out which detections are supplied and which need customer-managed monitoring. A suspicious consent grant is examined against the application’s permissions, the approving identity and the activity that followed.
ASD Essentials for Cloud explains the shared responsibility markers and applicable actions.
ThreatDefence runs a 24x7 SOC with its team based in Australia and a 3 min average response under guaranteed SLAs. Threat hunting and an incident response retainer are included in the standard service.
Response actions remain within the authority approved by each customer, and case records can be exported for an assessor or at the end of a contract. Australian customers’ data and AI processing stay in Australia.
The ThreatDefence identity threat detection and response module detects risky sign-ins, session token replay, new MFA methods, risky app consents and privileged role changes.
For confirmed alerts, analysts can revoke sessions, remove a rogue MFA method or disable a compromised account within the customer’s approved authority.
Before a formal assessment, the free ASD Essentials Navigator allows organisations to rate each action against their own environment and see how principles and domains roll up. ThreatDefence does not certify organisations. The assessor determines ASD Essentials ratings. Readers new to the framework can start with the five-minute ASD Essentials explainer, which walks through principles, actions, domains, priority phases and ratings.
Open the ASD Essentials Navigator Start the 5-Minute Explainer Explore ASD Essentials Compliance
See how ThreatDefence automates security monitoring, compliance and cyber risk management in one platform.
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
No. ASD’s Indicators of Good Practice list MFA that relies on SMS, voice or push-only authentication among the not effective indicators for phishing-resistant MFA. These methods may add protection over a password alone, but they do not deliver the phishing-resistant outcome the action is after. Security keys, passkeys and smart cards are common alternatives. Check both the methods the policy permits and the methods people actually use to sign in.
Identity services are the enterprise-wide systems that establish identity, manage credentials or authenticate access to other systems. Examples include directories, identity providers, federation services, certificate authorities, enterprise password managers and secrets vaults. Identity lifecycle systems may also qualify when their functions determine access elsewhere. An application with its own user accounts does not automatically fall within the domain unless its identity functions affect other systems.
Essential Eight MFA maps to the Identity, credential and access management principle (PRO-13). There, phishing-resistant MFA sits within a wider set of identity controls covering unused and default accounts, secure credential storage, legacy authentication and unique credentials. The phishing-resistant MFA action applies across all technical domains in enterprise IT. Existing Essential Eight MFA controls can contribute evidence once their coverage has been checked against the applicable ASD Essentials actions.
No. ASD Essentials prescribes no ITDR product and does not identify ITDR as a separate principle. PRO-13 supports detection of identity and credential misuse, DET-04 addresses high-risk access baselines and DET-02 covers anomalous authentication and unauthorised changes. Native identity provider features, dedicated ITDR technology or a broader monitoring platform can each support these outcomes. The assessment concerns how effective the relevant controls and capabilities are, whatever they are called.
The events that matter most are those that could indicate account takeover, credential misuse or unauthorised privilege changes. Examples include new MFA methods, suspicious application consents, privileged role assignments, federation changes, session token replay and unexpected emergency account use. A successful sign-in after repeated failures, legacy authentication and dormant account activity also warrant attention. Read each event against normal account behaviour, approved changes and the available device or network context.
Yes. Cloud identity providers can supply authentication, account administration, application consent and role-change events for investigation. ASD’s cloud chapter addresses audit logging at sufficient tiers and retention and forwarding relevant records to a central capability. Confirm which detections the provider supplies natively and which monitoring the customer has to configure. Then check that licensing, logging settings and retention provide the evidence an investigation needs.
at sufficient tiers and retention
Only as a managed exception where disabling it is not feasible. IT.PRO-13.5 asks organisations to restrict and monitor their use, apply compensating controls and establish a time-bound decommissioning plan. A protocol kept without compensating controls, monitoring or a removal timeline appears among ASD’s not effective indicators. Full effectiveness also expects a maintained inventory of legacy protocol use, with each remaining exception risk reviewed and recorded in the risk register.
restrict and monitor their use, apply compensating controls and establish a time-bound decommissioning plan.
In approved secure repositories. IT.PRO-13.2 states: Store authentication keys, secrets and tokens in approved secure repositories with access controls, including MFA. ASD’s indicators treat routine plaintext, spreadsheet or shared-drive storage as not effective and expect repository access to be logged and reviewed. Scanning codebases, configuration files and collaboration platforms for exposed secrets is a separate action, assessed under Visibility and response.
Store authentication keys, secrets and tokens in approved secure repositories with access controls, including MFA.
Keep break-glass accounts restricted to emergency use, protected against misuse and tested regularly. ASD’s MFA indicators expect arrangements to be periodically tested and reviewed so they stay functional, protected and limited to their intended purpose. The credentials are securely managed and kept out of routine administration. Arrangements that are poorly restricted, monitored, tested or reviewed limit the MFA action to partially effective. Approved break-glass accounts are also the exception to time-bound privilege.
periodically tested and reviewed
ASD Essentials Boundary Services
ASD Essentials Critical Processes and Privileged Environments
ASD Essentials Explained: Framework, Chapters and Enterprise IT