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.
Network detection and response (NDR) gives an ASD Essentials assessment a record of what crossed the network: which systems communicated, across which boundaries and with which internet destinations. Firewall configurations show what was permitted and system logs show what each device reported. Network telemetry adds the connections observed at monitored points.ASD Essentials does not require an NDR product. Its actions on segmentation, lateral movement, content filtering and asset discovery are the ones network monitoring supports most directly.
The clearest link between NDR and ASD Essentials is the Network segmentation and segregation principle (PRO-18). Its first action is to Isolate systems within network zones based on business criticality and trust level, and restrict and monitor inbound and outbound access to explicitly approved pathways and services.
Isolate systems within network zones based on business criticality and trust level, and restrict and monitor inbound and outbound access to explicitly approved pathways and services.
The action asks for restriction and for monitoring. Firewalls and other access controls do the restricting. Network telemetry records the connections seen at monitored points. Comparing those records with the approved pathways turns up unexpected access, configuration changes and traffic that warrants investigation.
Network monitoring also supports the Visibility and response domain. System logs describe activity as each device or application reports it. Traffic records are collected from outside the device, which helps most with appliances, unmanaged devices and systems with limited logging.
As evidence, NDR has a limit. It can show that a connection occurred. It cannot show by itself that the connection was authorised or that an access restriction worked. Those conclusions rest on approved pathway records, preventive control configurations and technical validation.
Network evidence does different work for different ASD Essentials actions. For one action it is a flow record at a zone boundary. For another it is a list of devices missing from the inventory.
The table covers the enterprise IT actions where NDR is most relevant.
Both PRO-18 actions and the outbound inspection action apply across Boundary services, Identity services, Critical processes and services, Privileged environments and Business systems. The malicious destination blocking action applies to Boundary services and Critical processes and services.
That scoping means network visibility is assessed domain by domain. An organisation-wide statement that the network is monitored does not match how the actions are applied.
For example, an NDR sensor at the internet firewall shows outbound connections and traffic entering through that boundary. It will not necessarily see a workstation connecting directly to another workstation inside the same network segment.
Evidence also has to match the action being assessed. Network flows can support a segmentation review, but proof that a pathway is blocked comes from technical testing. In the same way, an observed outbound connection says nothing about whether content inspection took place.
Segmentation that has never been tested counts against the rating. ASD’s Indicators of Good Practice for PRO-18.1 identify segmentation that has not been validated through technical assessment. among the not effective indicators.
has not been validated through technical assessment.
The fully effective indicators describe deny-by-default rules between segments and documented validation with identified gaps remediated. They also describe approved pathways reviewed on a defined cycle, with unjustified pathways removed.
Validating network segmentation therefore draws on the approved communication pathways, the observed traffic, the enforced access controls and documented technical test results. A practical review works through these activities:
Export traffic crossing monitored boundaries and compare each source, destination and service with the approved pathway register. Investigate connections without a matching authorisation.
Identify traffic between zones that are meant to have limited interaction. Confirm whether the connection is an approved dependency, an overly permissive rule or another issue.
Find approved routes that show no traffic during the review period. Review their business purpose and ownership before deciding whether they stay available.
Compare traffic before and after firewall changes. Check that approved connections still work and previously prohibited communications remain restricted.
Run authorised connection tests against pathways expected to be blocked. Record the test source, target, service, expected outcome and observed result.
Keep the results, identified gaps, corrective changes and subsequent validation so an assessor can follow the outcome.
The pathway register gives the business reason for each exception in terms a reviewer can follow. A typical case is a rule opened for an application migration that has since finished. The review checks whether anything still uses the rule before it is kept.
Passive monitoring cannot prove that an unused pathway is blocked. A missing flow might mean nobody attempted the connection, the sensor could not see the traffic, or the connection was prevented.
The strongest evidence joins the approved design, the access control configuration, the observed communications and the test results. The design says what was intended and the configuration says what is enforced. The traffic shows what happened, and the tests show what is blocked.
Lateral movement can stay inside one segment and never cross a firewall or a zone boundary. The second PRO-18 action covers that case. It reads: Limit lateral movement between, and within, network segments to explicitly approved pathways and services, based on business requirements and trust levels.
Limit lateral movement between, and within, network segments to explicitly approved pathways and services, based on business requirements and trust levels.
ASD maps the action to the ATT&CK techniques Remote Services and Lateral Tool Transfer.
The reference to movement within segments carries through to the indicators. A partially effective indicator describes controls that limit movement between segments while no controls operate within segments.
no controls operate within segments.
A common network design shows how that happens. Restrictive firewalls sit between the server, user and management zones, while workstations inside the user segment can reach each other freely. Monitoring only the zone boundaries leaves those workstation-to-workstation connections unseen.
Useful NDR detections for internal movement include:
Ordinary workstations initiating remote desktop, remote management or SMB administrative-share connections to systems they do not normally administer.
Hosts connecting to servers, workstations or other devices they have not contacted before.
One device contacting numerous internal systems on the same port within a short period, which can indicate network discovery.
Executable files or other suspicious content moving between internal hosts over supported file-sharing protocols.
Each detection is a starting point for investigation, and none of them proves compromise on its own.
A new remote desktop session may be approved maintenance. The same session followed by suspicious authentication, unexpected process execution or further connections to sensitive systems gives stronger grounds for escalation.
Network telemetry is most useful for devices that cannot run endpoint security agents, including printers, appliances and building systems.
Endpoint records name the account and process behind a connection. Network observations identify the communication itself and, where the relevant traffic is visible, its relationships with other systems.
Read together, the records help analysts tell legitimate administration from suspicious internal movement.
All of this depends on coverage. A sensor monitoring a zone boundary may never see traffic exchanged directly between devices on an unmonitored internal network.
The Content filtering principle (PRO-09) has no direct equivalent in the Essential Eight. The ASD Essentials Boundary services guide explains its outbound inspection and malicious destination blocking actions.
Outbound network monitoring works beside those controls and does not stand in for them. Firewalls, proxies and content inspection systems provide the preventive enforcement and inspection. Network telemetry picks out suspicious external connections and transfers, and gives an investigator a record of which communications occurred.
Detection patterns worth running on outbound traffic include:
Repeated connections to an external destination at regular intervals, which can indicate command and control activity.
A device transferring substantially more data than its normal baseline, particularly outside expected operating periods.
Data moving through DNS queries or protocols carrying unusual content or volumes.
Connections to recently registered domains or external infrastructure that the organisation has not previously contacted.
An unfamiliar destination does not show malicious activity by itself. The investigation weighs the originating device, the expected business use, the connection history and any supporting security alerts.
Repeated beaconing from a workstation is worth examining alongside endpoint process activity. For a large outbound transfer, the analyst checks whether the application, destination and timing match an authorised business process.
Match NDR findings with firewall, proxy and content inspection records.
An outbound alert may identify a suspicious destination, but the investigation has to separate a blocked connection attempt from a completed session. A traffic-volume anomaly may justify examining possible exfiltration, but flow metadata does not show what content was transferred.
The outbound inspection action concerns detecting unauthorised transfer of sensitive or high-value data. Network metadata points to transfers worth examining, and inspection records show what the preventive controls actually inspected.
The fully effective indicator for the malicious destination blocking action describes controls applied across in-scope systems, egress paths, services and network boundaries. Detections from a single monitored egress point say little about the other paths, so the filtering records for each path are still needed.
The Asset identification principle (IDE-01) includes the action to Use an approved asset inventory mechanism that supports automated discovery to detect new and changed physical and non-physical assets. Passive network discovery contributes by finding the devices that communicate and checking them against the organisation’s approved inventory.
Use an approved asset inventory mechanism that supports automated discovery to detect new and changed physical and non-physical assets.
The indicators describe partial effectiveness when the inventory does not cover all network segments or asset types, or when reconciliation with discovery results is manual or inconsistent. Fully effective coverage includes all applicable assets and segments, with new and changed assets reconciled.
does not cover all network segments or asset types,
Passive sensors identify devices from the communications they observe and send no probes. They can reveal unmanaged endpoints, network appliances and other communicating systems that agent-based inventory tools may miss.
A workable reconciliation process covers:
Identify communicating systems without a matching inventory record, then confirm their purpose and owner.
Review known devices using new addresses, services or communication relationships.
Assign unfamiliar devices to the appropriate team for validation before treating any discovery as an unauthorised asset.
Record the segments monitored and identify locations where passive observations are unavailable.
Document which devices were confirmed, added to the inventory, corrected or referred for investigation.
For example, an unfamiliar device communicating with a management server may be a newly commissioned appliance or a system that was never recorded. The observation leads to a check against network administration and asset ownership records.
Passive discovery has a limit of its own. Silent devices produce no traffic for sensors to observe. Unmonitored segments and incomplete traffic mirroring leave further gaps.
A network discovery report is a useful input to an asset inventory. It does not show that the inventory is complete.
ASD does not prescribe an NDR deployment order. Sensor placement follows from the network boundaries, systems and internal communications that the relevant ASD Essentials actions call for monitoring.
A common approach is to begin with the higher-priority enterprise IT domains and extend coverage as the network architecture and monitoring needs are validated.
Boundary services and Identity services are in priority phase 1 of the enterprise IT chapter. Critical processes and services and Privileged environments are in phase 2.
Place monitoring where internet traffic leaves the organisation and where remote access traffic enters.
These locations give visibility of outbound communications, suspicious external destinations and connections involving Boundary services.
Confirm the actual egress paths before relying on the sensor. A typical gap is a secondary internet link that some systems use and the primary firewall never sees. Monitoring coverage follows the network design and the traffic routes observed.
Monitor communications to and from domain controllers, federation servers and certificate services.
These systems support authentication and trust relationships across the environment. Unexpected directory queries, unusual connection sources and legacy authentication protocols all give useful investigation leads.
Correlate network detections with authentication and administrative logs to find which accounts and activities were involved.
Extend monitoring to the boundaries around systems in the Critical processes and services and Privileged environments domains.
These phase 2 domains contain systems where unauthorised communications may have significant operational consequences.
Prioritise connections crossing trust boundaries, unexpected access to management services and communications between systems that are meant to have restricted relationships.
Add visibility inside segments where devices communicate directly without crossing a monitored boundary.
These are the locations where lateral movement between workstations, servers or other internal hosts becomes visible.
Non-production networks belong in the plan as well, because the enterprise IT chapter brings them into scope. Base the monitoring design on observed communications, and test any assumption that development or test systems are isolated.
For each sensor, document its location, monitored segments, applicable domains and commissioning date.
The record separates a sensor that is installed from one that is receiving the expected traffic. Sensor health, traffic mirroring and collection gaps all affect the evidence available. For example, a sensor can stay online after a change to the mirror port has cut off the traffic it was placed to see.
Review coverage when services, assets or network architecture change. Reviews under the Detection capability efficacy principle (DET-05) can then pick up new segments or communication paths that need monitoring.
Network telemetry shows which weak communication protocols are still in use, including ones that configuration records say were disabled.
The Secure configuration management principle (PRO-04) calls for baselines that disable or remove unsupported or weak communication protocols.
unsupported or weak communication protocols.
The legacy authentication action (PRO-13.5) is related. Its not effective indicators include authentication mechanisms that transmit credentials in cleartext or use weak cryptographic primitives, where they remain enabled without action to disable them.
Network observations worth reviewing include:
Connections negotiating TLS 1.0 or 1.1, including the servers that continue to accept them.
Services offering or negotiating weak cryptography where handshake information is available.
Authentication exchanges over protocols that expose credentials without transport encryption.
Certificates outside the organisation’s expected certificate management arrangements, where certificate details are visible.
For each finding, the investigation identifies the systems involved, the protocol observed and whether the connection is an active business dependency.
A configuration change does not by itself show that weak communication has stopped.
After remediation, repeat the network review and check whether the affected systems still negotiate weak protocols. Compare observations before and after the change and investigate any remaining sessions.
Network history shows where a documented baseline and actual operating behaviour differ. A typical case is a server the change did not reach, which keeps accepting the old protocol after the baseline says it is gone.
Visibility depends on the protocol and the telemetry available. Encrypted connections may expose timing, destinations and selected handshake characteristics while concealing application data, authentication details or certificate information.
For that reason network evidence is read together with configuration checks and technical validation.
Network evidence for an assessment covers where monitoring operated, what traffic crossed the relevant boundaries and whether segmentation controls worked when tested. The collection methods are common practice rather than ASD requirements.
A dated export covering the assessment period is stronger evidence than a dashboard screenshot. Flow records, sensor health histories and reconciliation results let the assessor examine the underlying observations, where a screenshot offers only a summary.
Screenshots still help when they show the date, the relevant system or tenant and the monitoring scope.
Sensor installation records show that equipment was deployed. They do not show that the sensor observed every relevant connection or that segmentation was effective.
An assessor separates traffic observed on an approved pathway from traffic observed outside one, and both from a prohibited pathway shown to be blocked through technical testing. An absence of traffic cannot show the last of these.
The OT chapter and the cloud chapter both involve network visibility, but the telemetry available and the way it is collected differ from enterprise IT.
The OT chapter is particularly explicit about network visibility. It includes continuous traffic capture on both sides of every OT-connected demilitarised zone boundary.
Passive sensors observe communications without actively probing controllers or other operational equipment. Sensor placement and any change to monitoring infrastructure follow the site’s operational procedures.
Monitoring at the OT boundary and monitoring inside the operational environment are different coverage, and the coverage record keeps them apart. OT network detection and response covers passive collection and industrial monitoring in more detail.
The cloud chapter addresses SaaS and PaaS environments, where organisations may not operate their own network infrastructure.
Its segmentation action is marked Customer for PaaS and Provider for SaaS. The network evidence available depends on the platform and on who holds responsibility under the service model.
In these environments, visibility typically comes from supported provider flow and firewall logs rather than customer-installed packet sensors.
The practical task is to list which network records are available, which communications they cover and where the customer relies on provider-operated controls.
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.
The ThreatDefence network detection and response module monitors traffic across enterprise IT and OT networks. Its detections cover reconnaissance, command and control beaconing, lateral movement and exfiltration.
Response actions stay within the authority each customer approves. Network design and firewall changes remain the responsibility of the organisation’s teams.
Case records can be exported for an assessor or at the end of a contract. Australian customers’ data and AI processing stay in Australia.
ThreatDefence does not certify organisations. The assessor determines ASD Essentials ratings based on the evidence and effectiveness of the relevant controls.
Organisations can also use the free ASD Essentials Navigator to rate their environment action by action, with principle and domain results that update as they go. 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 Essentials defines security actions and expected outcomes and does not mandate a network detection and response product. NDR can support segmentation monitoring, lateral movement detection, outbound traffic investigation and asset discovery. The OT chapter is more explicit about network monitoring, including continuous traffic capture at OT-connected DMZ boundaries. The useful question for an organisation is which telemetry and controls show that each applicable action is working. Deploying NDR does not answer that by itself.
Yes, when monitoring is passive and deployment follows the site’s operational procedures. Sensors connected through switch mirror ports or network taps inspect copies of industrial traffic and send no inspection packets to controllers. The operations team approves sensor placement and related network changes. Coverage includes the relevant DMZ boundaries, and the monitoring design accounts for operational constraints and traffic visibility.
Yes. NDR can identify many suspicious communication patterns without decrypting application content. Timing, session frequency, traffic volume, destinations and available TLS metadata may reveal beaconing, unusual transfers or unexpected relationships. Protocol versions, certificates and client fingerprints can also be available, depending on the traffic and the sensor. The encrypted content itself stays out of reach without appropriate decryption, which needs separate privacy and legal consideration.
No. NDR shows traffic observed at monitored locations, and passive monitoring alone cannot prove an unused pathway is blocked. The connection may never have been attempted, or its traffic may have missed the sensor. ASD’s indicators for IT.PRO-18.1 identify segmentation that has not been validated through technical assessment. as not effective. Strong evidence combines observed flows, approved pathway records, firewall configurations and documented connection tests.
Yes. The second segmentation action asks organisations to Limit lateral movement between, and within, network segments to explicitly approved pathways and services. A partially effective indicator describes controls that restrict movement between segments while no controls operate within segments. Internal host-to-host communications deserve the same attention as traffic between zones. ASD maps the action to Remote Services and Lateral Tool Transfer, which gives monitoring and investigation a set of behaviours to start from.
Limit lateral movement between, and within, network segments
Yes, where the devices communicate across monitored network segments. Passive discovery can identify unfamiliar endpoints, appliances and other systems without actively probing them. The IDE-01 action addresses automated discovery of new and changed assets, and its indicators identify an inventory that does not cover all network segments or asset types, as partially effective. Silent devices, incomplete traffic mirroring and unmonitored networks remain potential gaps, so each discovery is reconciled with the approved inventory.
No. NDR complements content filtering but does not replace the inline controls that inspect content or block malicious destinations. Network detections can highlight beaconing, tunnelling, unusual transfer volumes and first-seen destinations. Flow metadata cannot show that sensitive content was inspected. Assessors need firewall, proxy and content inspection records alongside the relevant NDR findings. The malicious destination blocking action applies to Boundary services and Critical processes and services.
ASD does not prescribe a sensor deployment sequence. A common approach begins at internet egress and remote access points for Boundary services, then adds monitoring around domain controllers, federation servers and certificate services for Identity services. Coverage can then extend to critical and privileged zones and to internal segments where lateral movement would otherwise go unseen. Record each sensor’s location, monitored segments, applicable domains and commissioning date.
Usually not in the form of customer-installed packet sensors. The ASD Essentials cloud chapter covers SaaS and PaaS environments where the customer may not operate the underlying network. Its segmentation action assigns responsibility to the Customer for PaaS and the Provider for SaaS. Network evidence typically comes from the provider flow and firewall logs that are available. The work for the organisation is to find out what each service exposes and how those records support the applicable actions.
ASD Essentials for OT and Critical Infrastructure
ASD Essentials Boundary Services
ASD Essentials Visibility and Response